> -Original Message-
> From: Guo, Jia
> Sent: Thursday, March 23, 2017 1:44 PM
> To: Zhang, Helin ; Wu, Jingjing
>
> Cc: dev@dpdk.org; Guo, Jia ; sta...@dpdk.org
> Subject: [dpdk-dev v3 3/3] test: enable HW CRC strip by default
>
> Since VF has no ability to disable/enable HW CRC strip
> -Original Message-
> From: Guo, Jia
> Sent: Thursday, March 23, 2017 1:44 PM
> To: Zhang, Helin ; Wu, Jingjing
>
> Cc: dev@dpdk.org; Guo, Jia ; sta...@dpdk.org
> Subject: [dpdk-dev v3 2/3] app: enable HW CRC strip by default
>
> Since VF has no ability to disable/enable HW CRC strip f
> -Original Message-
> From: Guo, Jia
> Sent: Thursday, March 23, 2017 1:44 PM
> To: Zhang, Helin ; Wu, Jingjing
>
> Cc: dev@dpdk.org; Guo, Jia ; sta...@dpdk.org
> Subject: [dpdk-dev v3 1/3] examples: enable HW CRC strip by default
>
> Since VF has no ability to disable/enable HW CRC st
Since VF has no ability to disable/enable HW CRC strip for non-DPDK PF
drivers, and for most case of kernel driver default enable HW CRC strip,
if disable HW CRC strip in app's rxmode, VF driver will return fail and
result the VF launch failure. So this patch default to enable HW CRC strip
to let V
Since VF has no ability to disable/enable HW CRC strip for non-DPDK PF
drivers, and for most case of kernel driver default enable HW CRC strip,
if disable HW CRC strip in example app's rxmode, VF driver will return
fail and result the VF launch failure. So this patch default to enable
HW CRC strip
Since VF has no ability to disable/enable HW CRC strip for non-DPDK PF
drivers, and for most case of kernel driver default enable HW CRC strip,
if disable HW CRC strip in test app's rxmode, VF driver will return fail and
result the VF launch failure. So this patch default to enable HW CRC strip
to
On Tue, Mar 21, 2017 at 12:33:30PM +, Ferruh Yigit wrote:
> On 3/2/2017 11:32 AM, Shijith Thotton wrote:
> > Added doc/guides/nics/liquidio.rst and
> > doc/guides/nics/features/liquidio.ini. Updated release notes.
> >
> > Signed-off-by: Shijith Thotton
> > Signed-off-by: Jerin Jacob
> > Sign
On Tue, Mar 21, 2017 at 02:09:44PM +, Ferruh Yigit wrote:
> On 3/21/2017 1:56 PM, Shijith Thotton wrote:
> > On Tue, Mar 21, 2017 at 01:01:58PM +, Ferruh Yigit wrote:
> >> On 3/21/2017 12:53 PM, Shijith Thotton wrote:
> >>> On Tue, Mar 21, 2017 at 12:24:49PM +, Ferruh Yigit wrote:
> >>>
Accept that, and will send v3 to fix it. Thanks for review.
Best regards,
Jeff Guo
-Original Message-
From: Wu, Jingjing
Sent: Wednesday, March 22, 2017 8:27 PM
To: Guo, Jia ; Zhang, Helin
Cc: dev@dpdk.org; sta...@dpdk.org
Subject: RE: [dpdk-dev v2 3/3] test: enable HW CRC strip by def
Since VF has no ability to disable/enable HW CRC strip for non-DPDK PF
drivers, and for most case of kernel driver default enable HW CRC strip,
if disable HW CRC strip in app's rxmode, VF driver will return fail and
result the VF launch failure. So this patch default to enable HW CRC strip
to let V
Since VF has no ability to disable/enable HW CRC strip for non-DPDK PF
drivers, and for most case of kernel driver default enable HW CRC strip,
if disable HW CRC strip in example app's rxmode, VF driver will return
fail and result the VF launch failure. So this patch default to enable
HW CRC strip
Since VF has no ability to disable/enable HW CRC strip for non-DPDK PF
drivers, and for most case of kernel driver default enable HW CRC strip,
if disable HW CRC strip in test app's rxmode, VF driver will return fail and
result the VF launch failure. So this patch default to enable HW CRC strip
to
Hello All,
I have two NICs in my server, intel x520 and x540. I am interested in
performance(throughput) of the application when we change the batching
factor at NIC and in application.
I can change the batch size in the DPDK application, but I am not sure how
to do at the NIC. What needs to be
> -Original Message-
> From: Yigit, Ferruh
> Sent: Wednesday, March 22, 2017 10:29 PM
> To: Wu, Jingjing ; dev@dpdk.org
> Cc: Zhang, Helin ; Xing, Beilei
> Subject: Re: [dpdk-dev] [PATCH 0/7] net/i40e: base code update
>
> On 3/22/2017 9:24 AM, Jingjing Wu wrote:
> > Base code update wi
Thank you Furruh,
A new patch series has been uploaded.
Ed.
* Flesh out device configuration
* Add links dev_ops
* allow dynamic extension loading
Signed-off-by: Shepard Siegel
Signed-off-by: John Miller
Signed-off-by: Ed Czeck
---
drivers/net/ark/ark_ethdev.c | 712 ++-
drivers/net/ark/ark_ext.h| 79 +
* Core RX packet moving functions
Signed-off-by: Ed Czeck
---
drivers/net/ark/Makefile| 1 +
drivers/net/ark/ark_ethdev_rx.c | 681
drivers/net/ark/ark_ethdev_rx.h | 67
3 files changed, 749 insertions(+)
create mode 100644 drivers/net/ar
* Core TX packet moving functions
* Flesh out ark_adapter struct to support TX code
(not all fields used at this patch
Signed-off-by: Ed Czeck
---
drivers/net/ark/Makefile| 1 +
drivers/net/ark/ark_ethdev.c| 15 ++
drivers/net/ark/ark_ethdev.h| 2 +-
drivers/net/ark/ark_ethd
Provide C-level interface for Arkville's internal HW resources
pktgen and pktchk modules
Signed-off-by: Ed Czeck
---
drivers/net/ark/Makefile | 3 +-
drivers/net/ark/ark_pktchkr.c | 472
drivers/net/ark/ark_pktchkr.h | 114 ++
drivers/net/a
Provide C-level interface for Arkville's internal HW resources
mpu, pktdir, and rqp modules
Signed-off-by: Ed Czeck
---
drivers/net/ark/Makefile | 4 +
drivers/net/ark/ark_mpu.c| 181 +++
drivers/net/ark/ark_mpu.h| 143 +++
Provide C-level interface for Arkville's internal HW resources
ddm and udm modules
Signed-off-by: Ed Czeck
---
drivers/net/ark/Makefile | 3 +-
drivers/net/ark/ark_ddm.c | 151 +++
drivers/net/ark/ark_ddm.h | 154 +++
drivers/net/ark/ark
Enable Arkville on supported configurations
Add overview documentation
Minimum driver support for valid compile
Arkville PMD is not supported on ARM or PowerPC at this time
v4:
* Address issues report from review
* Add internal comments on driver arg
* provide a bare-biones dev init to avoid compi
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Tuesday, March 14, 2017 10:00 AM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH] doc: add maintainer role about replying
> questions
>
> The first line of the MAINTAINERS file are:
> "
>
For now, exit the init. It's likely that even aborting the initialization
is premature in this case, as it may be possible to proceed even if one
bus or another is not available.
Signed-off-by: Aaron Conole
---
lib/librte_eal/bsdapp/eal/eal.c | 14 ++
lib/librte_eal/linuxapp/eal/e
The rte_eal_init function will now pass failure reason hints to the
application. To help app developers deciper this, add some brief
information about what the codes are indicating.
Signed-off-by: Aaron Conole
Acked-by: Bruce Richardson
---
lib/librte_eal/common/include/rte_eal.h | 27
Plugins are useful and important. However, it seems crazy to abort
everything just because they don't initialize properly.
Signed-off-by: Aaron Conole
---
lib/librte_eal/bsdapp/eal/eal.c | 2 +-
lib/librte_eal/linuxapp/eal/eal.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff -
There could be some confusion as to why the call failed - this change
will always reflect the value of the error in rte_error.
When initializing the interrupt thread, there are a number of possible
reasons for failure - some of which are correctable by the application.
Do not panic() needlessly, a
Even if one vdev should fail, there's no need to prevent further
processing. Log the error, and reflect it to the higher levels to
decide.
Seems like it's possible to continue. At least, the error is reflected
properly in the logs. A user could then go and correct or investigate
the situation.
Some devices may be inaccessible for a variety of reasons, or the
PCI-bus may be unavailable causing the whole thing to fail. Still,
better to continue attempts at probes.
Since PCI isn't neccessarily required, it may be possible to simply log
the error and continue on letting the user check the
After code inspection, there is no way for eal_timer_init() to fail. It
simply returns 0 in all cases. As such, this test could either go-away
or stay here as 'future-proofing'.
Signed-off-by: Aaron Conole
---
lib/librte_eal/bsdapp/eal/eal.c | 7 +--
lib/librte_eal/linuxapp/eal/eal.c | 7
When log initialization fails, it's generally because the fopencookie
failed. While this is rare in practice, it could happen, and it is
likely because of memory pressure. So, flag the error, and allow the
user to retry.
Memory init can only fail when access to hugepages (either as primary or
se
It's possible that the application could take a corrective action here,
and either prompt the user for different arguments, or at least perform
a better logging. Exiting this early prevents any useful information
gathering from the application layer.
Signed-off-by: Aaron Conole
---
lib/librte_e
Signed-off-by: Aaron Conole
---
lib/librte_eal/bsdapp/eal/eal.c | 7 +--
lib/librte_eal/linuxapp/eal/eal.c | 5 -
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c
index a71566c..ea76d40 100644
--- a/lib/libr
When memzone initialization fails, report the error to the calling
application rather than panic(). Without a good way of detaching /
releasing hugepages, at this point the application will have to restart.
Signed-off-by: Aaron Conole
---
lib/librte_eal/bsdapp/eal/eal.c | 7 +--
lib/librt
When attempting to scan hugepages, signal to the eal that an error has
occurred, rather than performing a panic.
If we fail to acquire hugepage information, simply signal an error to
the application. This clears the run_once counter, allowing the user or
application to take a corrective action an
In many cases, it's enough to simply let the application know that the
call to initialize DPDK has failed. A complete halt can then be
decided by the application based on error returned (and the app could
even attempt a possible re-attempt after some corrective action by the
user or application).
There may be no way to gracefully recover, but the application
should be notified that a failure happened, rather than completely
aborting. This allows the user to proceed with a "slow-path" type
solution.
After this change, the EAL CPU NUMA node resolution step can no longer
emit an rte_panic.
This adds a new API to check for the eal cpu versions.
It's now possible to gracefully exit the application, or for
applications which support non-dpdk datapaths working in concert with
DPDK datapaths, there no longer is the possibility of exiting for
unsupported CPUs.
Signed-off-by: Aaron Conole
On Thu, 2017-03-16 at 19:13 +0100, Thomas Monjalon wrote:
> 2017-01-12 15:43, Christian Ehrhardt:
> > On Mon, Dec 19, 2016 at 4:15 PM, Thomas Monjalon > wind.com>
> > wrote:
> >
> > > Thanks for sending your Debian/Ubuntu work.
> > >
> > > 2016-12-13 16:47, Luca Boccassi:
> > > > From: Christian
On 3/21/2017 9:43 PM, Ed Czeck wrote:
> Enable Arkville on supported configurations
> Add overview documentation
> Minimum driver support for valid compile
>
>
> Signed-off-by: Ed Czeck
> ---
> MAINTAINERS | 8 +
> config/common_base |
Hi Olivier,
> > > > > > Another thing that doesn't look very convenient to me here -
> > > > > > We can have 2 different values of timestamp (both normalized and
> > > > > > not)
> > > > > > and there is no clear way for the application to know which one is
> > > > > > in
> > > > > > use right
From: Alex Zelezniak
Signed-off-by: Alex Zelezniak
---
drivers/net/ixgbe/ixgbe_ethdev.c | 33 +
drivers/net/ixgbe/rte_pmd_ixgbe.h | 14 ++
2 files changed, 47 insertions(+)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethd
On Wed, Mar 22, 2017 at 09:58:00AM -0500, Gage Eads wrote:
> From: "Eads, Gage"
>
> This commit adds rte_errno return values to rte_event_enqueue_burst() and
> rte_event_dequeue_burst().
>
> These return values allows user software to differentiate between an
> invalid argument (such as an inval
Commit 30e6399892276 ("mempool: support non-EAL thread") added the capability
for non-EAL threads to use the mempool library. This commit removes the note
indicating that the mempool library cannot be used safely by non-EAL threads.
Also, fix a typo.
Signed-off-by: Gage Eads
---
v2: Changed comm
On Fri, Mar 03, 2017 at 04:10:49PM +, Pablo de Lara wrote:
> Remove DPDK QAT sample app, in favour of the newer applications
> that use the cryptodev library: ipsec-gw and l2fwd-crypto,
> which has support for Intel QuickAssist devices.
>
> Signed-off-by: Pablo de Lara
Acked-by: Bruce Richard
On Wed, Mar 15, 2017 at 03:01:49PM +0100, Thomas Monjalon wrote:
> clang error below:
>
> 2017-03-07 11:32, Bruce Richardson:
> > + union {
> > + uint32_t sp_enqueue; /**< True, if single producer. */
> > + uint32_t sc_dequeue; /**< True, if single consumer. */
>
On 3/22/2017 10:00 PM, De Lara Guarch, Pablo wrote:
Hi Akhil,
-Original Message-
From: Akhil Goyal [mailto:akhil.go...@nxp.com]
Sent: Wednesday, March 22, 2017 9:50 AM
To: Mcnamara, John; dev@dpdk.org
Cc: thomas.monja...@6wind.com; Doherty, Declan; De Lara Guarch, Pablo;
nhor...@tuxdri
Hi Akhil,
> -Original Message-
> From: Akhil Goyal [mailto:akhil.go...@nxp.com]
> Sent: Wednesday, March 22, 2017 9:50 AM
> To: Mcnamara, John; dev@dpdk.org
> Cc: thomas.monja...@6wind.com; Doherty, Declan; De Lara Guarch, Pablo;
> nhor...@tuxdriver.com; hemant.agra...@nxp.com
> Subject:
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monja...@6wind.com]
> Sent: Thursday, March 09, 2017 8:20 PM
> To: Trahe, Fiona; De Lara Guarch, Pablo; Jain, Deepak K
> Cc: dev@dpdk.org; Mcnamara, John
> Subject: Re: [dpdk-dev] [PATCH] doc: fix crypto overview matrix for missi
AESNI MB supports MD5 and AES XCBC, but it wasn't reflected
in the driver documentation.
Signed-off-by: Pablo de Lara
---
doc/guides/cryptodevs/aesni_mb.rst | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/doc/guides/cryptodevs/aesni_mb.rst
b/doc/guides/cryptodevs/aesni_mb
Follow the approach in the network devices overview,
for the feature matrix, so it improves readibility
and maintainability.
Signed-off-by: Pablo de Lara
---
.gitignore | 4 +
doc/guides/conf.py | 47 +++--
doc/guides/cryptodevs/feat
Hi Jerin,
Please note the checkpatch issues for this patch:
http://dpdk.org/ml/archives/test-report/2017-March/012577.html
Thanks,
Gage
From: "Eads, Gage"
This commit adds rte_errno return values to rte_event_enqueue_burst() and
rte_event_dequeue_burst().
These return values allows user software to differentiate between an
invalid argument (such as an invalid queue_id or sched_type in an enqueued
event) and backpressure from the
On 3/22/2017 7:50 AM, Nélio Laranjeiro wrote:
> On Tue, Mar 21, 2017 at 10:50:51AM -0700, Yongseok Koh wrote:
>> When configuring Rx/Tx queue, if queue already exists, it is reused. But if
>> the queue size is changed, it must be resized to not access/overwrite
>> invalid memory.
>>
>> Fixes: 2e229
HI list
I'm using two processes in our program.
The primary process to load config, init data
The secondary process to receive and forward the package from NIC
In order to reduce the cpu usage, we decide to use interrupt + poll
mode.
But I fi
On 3/22/2017 8:39 AM, Wenzhuo Lu wrote:
> VLAN filter is not working on i40e because driver need to
> disable the VLAN promiscuous mode and set the VLAN filter
> table.
>
> Fixes: 5f2b0e3f7656 (net/i40e: set VF VLAN filter from PF)
>
> Signed-off-by: Wenzhuo Lu
Applied to dpdk-next-net/master,
This patchset refactor the dpdk-devbind.py script to
1) Optimize the bind and status operation delay(It is noticeable
when the system has fairly large number of PCIe device. For instance,
OCTEONTX system has around 170 PCIe devices and it takes around
19 seconds to bind devices. With this patch it
Hi Stephen,
The issue is not ordering or synchronizing IO read and write operations, so
memory barriers are not the solution and will not address the compile
optimizations which the volatile qualifier avoids. The linux kernel guide
states: "The volatile storage class was originally meant for memo
On 3/22/2017 9:24 AM, Jingjing Wu wrote:
> Base code update with main changes:
> - new AQ commands for Pipeline Personalization Profile
> - new AQ commands for cloud filter
> - reduce wait time for adminq command completion
>
> Jingjing Wu (7):
> net/i40e/base: define bit for HW ATR evict con
On 3/22/2017 12:23 AM, al...@att.com wrote:
> From: Alex Zelezniak
>
Hi Alex,
Thank you for the patch.
Can you please send a new version of the patch with a sign-off?
More details related sign-off:
http://dpdk.org/doc/guides/contributing/patches.html#commit-messages-body
Overall DPDK contri
> On Mar 22, 2017, at 4:48 AM, Pascal Mazon wrote:
>
> This series add support for the flow API in tap PMD.
>
> It enables filtering specific packets incoming on the tap netdevice, to
> process only desired ones. Under the hood, it uses kernel TC (traffic
> control), which takes place very earl
From: Guduri Prathyusha
get_nic_details() and get_crypto_details() shares a lot of common code.
Created a new unified get_device_details() function get the device details.
Signed-off-by: Guduri Prathyusha
Signed-off-by: Jerin Jacob
---
usertools/dpdk-devbind.py | 115 +++--
From: Guduri Prathyusha
Signed-off-by: Guduri Prathyusha
Signed-off-by: Jerin Jacob
---
usertools/dpdk-devbind.py | 6 ++
1 file changed, 6 insertions(+)
diff --git a/usertools/dpdk-devbind.py b/usertools/dpdk-devbind.py
index 4ea0adf..87e1d30 100755
--- a/usertools/dpdk-devbind.py
+++ b/
From: Guduri Prathyusha
Signed-off-by: Guduri Prathyusha
Signed-off-by: Jerin Jacob
---
usertools/dpdk-devbind.py | 6 ++
1 file changed, 6 insertions(+)
diff --git a/usertools/dpdk-devbind.py b/usertools/dpdk-devbind.py
index 87e1d30..bb4d536 100755
--- a/usertools/dpdk-devbind.py
+++ b/
From: Guduri Prathyusha
This patch creates the framework to define the DPDK PCI functional
device by specifying the pci attributes like Vendor ID, Device ID,
Sub Vendor ID, Sub Device ID and Class.This enables a flexible way to
add DPDK function devices based on PCI attributes.
Crypto devices ca
From: Guduri Prathyusha
lspci invoked twice over all the pci devices in the system.
The first pass is to extract Numeric IDs and second pass to get extended
device details.
As an optimization, Used lspci with -nn option in get_device_details()
to obtain Numeric ID and extended device details in
From: Guduri Prathyusha
The current device bind model uses /sys/bus/pci/driver/new_id scheme to
bind devices to the driver. This scheme has following operations to bind
a device to the driver.
1) Write device ID and vendor ID to /sys/bus/pci/driver/new_id
2) Write PCI BDF number to /sys/bus/pci/d
From: Guduri Prathyusha
Identified and parameterized the common code in show_status() function as
show_device_status().This will enable to avoid code duplication when
additional devices added to the script.
Signed-off-by: Guduri Prathyusha
Signed-off-by: Jerin Jacob
---
usertools/dpdk-devbind
> On Mar 22, 2017, at 3:40 AM, Pascal Mazon wrote:
>
> Reflect device link status according to the state of the tap netdevice
> and the remote netdevice (if any). If both are UP and RUNNING, then the
> device link status is set to ETH_LINK_UP, otherwise ETH_LINK_DOWN.
>
> Signed-off-by: Pascal
> On Mar 22, 2017, at 3:40 AM, Pascal Mazon wrote:
>
> As tap is a virtual device, there's no physical way a link can be cut.
> However, it has an associated kernel netdevice and possibly a remote
> netdevice too. These netdevices link status may change outside of the
> DPDK scope, through an ex
On 3/22/2017 9:48 AM, Pascal Mazon wrote:
> Supported flow rules are now mapped to TC rules on the tap netdevice.
> The netlink message used for creating the TC rule is stored in struct
> rte_flow. That way, by simply changing a metadata in it, we can require
> for the rule deletion without further
Hi Alejandro,
Just a general comment, I think there's now a rule to not split error messages
onto multiple lines
even if going above the 80 char limit, to make grepping easier.
> Current device hotplug is just when using UIO. This patch adds
> same functionality with VFIO.
>
> It has been valid
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Fiona Trahe
> Sent: Thursday, March 9, 2017 7:21 PM
> To: dev@dpdk.org; De Lara Guarch, Pablo ;
> Kusztal, ArkadiuszX
> Cc: Jain, Deepak K ; Trahe, Fiona
> ; Griffin, John
> Subject: [dpdk-dev] [PATCH v2 3/3] do
Hi Fiona,
Thanks for the improvements to the doc. Some minor comments below.
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Fiona Trahe
> Sent: Thursday, March 9, 2017 7:21 PM
> To: dev@dpdk.org; De Lara Guarch, Pablo ;
> Kusztal, ArkadiuszX
> Cc: Jain, Deepa
> -Original Message-
> From: Wu, Jingjing
> Sent: Wednesday, March 22, 2017 7:53 PM
> To: Guo, Jia ; Zhang, Helin
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: RE: [dpdk-dev v2 1/3] examples: enable HW CRC strip by default
>
>
>
> > -Original Message-
> > From: Guo, Jia
> > S
> -Original Message-
> From: Guo, Jia
> Sent: Monday, March 20, 2017 5:58 PM
> To: Zhang, Helin ; Wu, Jingjing
> Cc: dev@dpdk.org; Guo, Jia ; sta...@dpdk.org
> Subject: [dpdk-dev v2 3/3] test: enable HW CRC strip by default
>
> Since VF has no ability to disable/enable HW CRC strip for
> -Original Message-
> From: Wu, Jingjing
> Sent: Wednesday, March 22, 2017 8:22 PM
> To: Guo, Jia ; Zhang, Helin
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: RE: [dpdk-dev v2 2/3] app: enable HW CRC strip by default
>
>
>
> > -Original Message-
> > From: Guo, Jia
> > Sent:
> -Original Message-
> From: Guo, Jia
> Sent: Monday, March 20, 2017 5:58 PM
> To: Zhang, Helin ; Wu, Jingjing
> Cc: dev@dpdk.org; Guo, Jia ; sta...@dpdk.org
> Subject: [dpdk-dev v2 2/3] app: enable HW CRC strip by default
>
> Since VF has no ability to disable/enable HW CRC strip for n
On 03/21/2017 04:41 PM, Sergio Gonzalez Monroy wrote:
The DPDK will still try to allocate contiguous hugepages.
Since DPDK v16.07 the mempool library is able to create a mempool with multiple
chunks of memory.
You would still have the contig memory restriction for any other DPDK library
or app.
> -Original Message-
> From: Guo, Jia
> Sent: Monday, March 20, 2017 5:58 PM
> To: Zhang, Helin ; Wu, Jingjing
> Cc: dev@dpdk.org; Guo, Jia ; sta...@dpdk.org
> Subject: [dpdk-dev v2 1/3] examples: enable HW CRC strip by default
>
> Since VF has no ability to disable/enable HW CRC strip
On 3/22/2017 10:03 AM, Andrew Rybchenko wrote:
> Fixes: 1eb4d2e4b360 ("net/sfc: make VLAN insertion a datapath-dependent
> feature")
>
> Signed-off-by: Andrew Rybchenko
> ---
> It would be good if the fix is squashed into corresponding patch.
Done, squashed into 1eb4d2e4b360
On 3/22/2017 9:39 AM, Jerin Jacob wrote:
> On Tue, Mar 21, 2017 at 02:53:29PM +, Ferruh Yigit wrote:
>> On 3/21/2017 2:38 PM, Jerin Jacob wrote:
>>> On Tue, Mar 21, 2017 at 02:31:41PM +, Ferruh Yigit wrote:
On 3/20/2017 2:10 PM, Jerin Jacob wrote:
> - bgx_link_status mbox definitio
This RFC contains specifications for asymmetric crypto algorithms.
Asymmetric crypto algorithms are essential part of protocols such as
SSL/TLS. As the current DPDK crypto library lacks support for asymmetric
crypto algorithms, this RFC is an attempt to address it.
Cavium offers PCI hardware acc
Fixes: 1eb4d2e4b360 ("net/sfc: make VLAN insertion a datapath-dependent
feature")
Signed-off-by: Andrew Rybchenko
---
It would be good if the fix is squashed into corresponding patch.
drivers/net/sfc/sfc_tx.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/sfc/sfc_tx.c b/drivers
> Super trivial comment inline:
Thanks, I'll add those and do a v2. I'll wait a bit in case there are more
comments.
Thanks,
Anatoly
On 3/8/2017 11:47 PM, Mcnamara, John wrote:
-Original Message-
From: Akhil Goyal [mailto:akhil.go...@nxp.com]
Sent: Friday, March 3, 2017 7:50 PM
To: dev@dpdk.org
Cc: thomas.monja...@6wind.com; Doherty, Declan ;
De Lara Guarch, Pablo ; Mcnamara, John
; nhor...@tuxdriver.com; hemant.agra..
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monja...@6wind.com]
> Sent: Monday, March 20, 2017 5:14 PM
> To: Zhang, Helin
> Cc: Zhang, Qi Z; techbo...@dpdk.org; dev@dpdk.org; Wu, Jingjing; Yigit,
> Ferruh; Liang, Cunming; Fastabend, John R
> Subject: Re: [dpdk-dev] [PATCH]
Supported flow rules are now mapped to TC rules on the tap netdevice.
The netlink message used for creating the TC rule is stored in struct
rte_flow. That way, by simply changing a metadata in it, we can require
for the rule deletion without further parsing.
Supported items:
- eth: src and dst (wi
The flow API provides the ability to classify packets received by a tap
netdevice.
This patch only implements skeleton functions for flow API support, no
patterns are supported yet.
Signed-off-by: Pascal Mazon
Acked-by: Olga Shern
---
doc/guides/nics/features/tap.ini | 1 +
drivers/net/tap/M
Each kernel netdevice may have queueing disciplines set for it, which
determine how to handle the packet (mostly on egress). That's part of
the TC (Traffic Control) mechanism.
Through TC, it is possible to set filter rules that match specific
packets, and act according to what is in the rule. This
In the next patch, access to struct pmd_internals will be necessary in
tap_flow.c to store the flows.
Signed-off-by: Pascal Mazon
Acked-by: Olga Shern
---
drivers/net/tap/Makefile | 1 +
drivers/net/tap/rte_eth_tap.c | 36 ++---
drivers/net/tap/rte_eth_tap.h | 75 +
This series add support for the flow API in tap PMD.
It enables filtering specific packets incoming on the tap netdevice, to
process only desired ones. Under the hood, it uses kernel TC (traffic
control), which takes place very early in the stack, and supports most
common pattern items and actions
On Tue, Mar 21, 2017 at 02:53:29PM +, Ferruh Yigit wrote:
> On 3/21/2017 2:38 PM, Jerin Jacob wrote:
> > On Tue, Mar 21, 2017 at 02:31:41PM +, Ferruh Yigit wrote:
> >> On 3/20/2017 2:10 PM, Jerin Jacob wrote:
> >>> - bgx_link_status mbox definition was changed in Linux
> >>> commit 1cc70259
This patch demonstrates the usage of the TCP IPv4 GRO library in testpmd.
Currently, only the iofwd mode supports this feature. By default, TCP
IPv4 GRO is turned off. The command, "gro tcp4 on", turns on this
feature; the command, "gro tcp4 off", turns off it.
Once the feature is turned on, all r
Generic Receive Offload (GRO) is a widely used SW offloading technique,
which reassemble small packets into large ones, to reduce processing
overheads for upper layer applications in receiving side, like networking
stack. Therefore, we propose to add GRO support in DPDK.
DPDK GRO is implemented as
Introduce two new functions to support TCP IPv4 GRO:
- rte_gro_tcp4_tbl_create: create a lookup table for TCP IPv4 GRO.
- rte_gro_tcp4_reassemble_burst: reassemble a bulk of TCP IPv4 packets
at a time.
rte_gro_tcp4_reassemble_burst works in burst-mode, which processes a bulk
of packets at a time.
Add new admin queue function and extended fields for cloud filter:
- Add admin queue function for Replace filter command (Opcode: 0x025F)
- Define big buffer for extended general fields in Add/Remove
Cloud filters command
Signed-off-by: Store Laura
Signed-off-by: Iremonger Bernard
Signed-of
This patch adds:
- ENCAP offload negotiation flag. Use the existing ENCAP_CSUM offload
flag to negotiate GSO_UDP_TUNNEL_CSUM capability and create new ENCAP
flag for negotiating offloads for encapsulated packets
- RX_ENCAP_CSUM offload negotiation flag for VF to negotiate RX
checksum cap
When sending an adminq command, we wait for the command to complete in
a loop. This loop waits for an entire millisecond, when in practice the
adminq command is processed often much faster.
Change the loop to use i40e_usec_delay instead, and wait for 50 usecs
each time instead. This appears to be
Add admin queue functions for Pipeline Personalization Profile AQ
commands defined in DCR 287:
- Write Recipe Command buffer (Opcode: 0x0270)
- Get Applied Profiles list (Opcode: 0x0271)
Signed-off-by: Beilei Xing
Signed-off-by: Jingjing Wu
---
drivers/net/i40e/base/i40e_adminq_cmd.h | 34 ++
1 - 100 of 116 matches
Mail list logo
