[dpdk-dev] [PATCH v2 04/13] ethdev: support of multiple sizes of redirection table

2014-09-25 16:40, Helin Zhang: > To support possible different sizes of redirection table, > structures and functions need to be redefined. In detail, > * 'struct rte_eth_rss_reta' has been redefined. > * 'uint16_t reta_size' has been added into > 'struct rte_eth_dev_info'. > * Updating/querying

[dpdk-dev] [PATCH v2 1/4] app/test: unit test for rx and tx cycles/packet

> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman > Sent: Tuesday, October 21, 2014 2:38 PM > To: Richardson, Bruce > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2 1/4] app/test: unit test for rx and tx > cycles/packet > > On Tue, Oct

[dpdk-dev] [PATCH v2 03/13] ethdev: add more annotation

2014-09-25 16:40, Helin Zhang: > Add more annotation, to clearly tell the 'rte_eth_dev_info_get()' > users that the buffer should be cleared first. Since commit http://dpdk.org/browse/dpdk/commit/?id=a30268e9a2 (ethdev: reset whole dev info structure before filling), this patch is now useless.

[dpdk-dev] [PATCH v2 03/13] ethdev: add more annotation

Hi Thomas OK. Good to know that. I will rework my patch based on latest master branch. Thank you very much! Regards, Helin > -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Wednesday, October 22, 2014 4:39 AM > To: Zhang, Helin > Cc: dev at

[dpdk-dev] nic loopback

21/10/2014 18:54, Alex Markuze :, > unfortunately these patches are only valid a pf*. This is also evident from > the ixgbe pmd code which is the only one looking at this bit (lpbk_mode). > The ixgbevf functions are agnostic to this capability. And did you try testpmd with PORT_TOPOLOGY_LOOP (2nd

[dpdk-dev] [PATCH 0/5] vmxnet3 pmd fixes/improvement

Rashmin/Stephen, Since you have worked on vmxnet3 pmd drivers, I wonder if you can help review this set of patches. Any other reviews/test verifications are welcome of course. We have reviewed/tested all patches internally. Yong From: dev on behalf

[dpdk-dev] Why do we need iommu=pt?

IMHO, if memory protection with IOMMU is needed or not really depends on how you use and deploy your DPDK based applications. For Telco network middle boxes, which adopts a "close model" solution to achieve extremely high performance, the entire system including HW, software in kernel and

[dpdk-dev] nic loopback

Thanks Thomas, unfortunately these patches are only valid a pf*. This is also evident from the ixgbe pmd code which is the only one looking at this bit (lpbk_mode). The ixgbevf functions are agnostic to this capability. *

[dpdk-dev] development/integration branch?

On Tue, 21 Oct 2014 11:14:43 +0200 Marc Sune wrote: > On 21/10/14 10:46, Thomas Monjalon wrote: > > My balance is different because I have a simpler solution for Marc's > > problem: > > git fetch && git merge $(git tag | grep -v -- -rc | tail -n1) > Thomas, > > We all know we _can_ do

[dpdk-dev] nic loopback

How can I set/query this bit (LLE(PFVMTXSW[n]), intel 82599 ) on ESX, or any other friendlier environment like Linux? On Tue, Oct 21, 2014 at 4:18 AM, Liang, Cunming wrote: > > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Alex Markuze > > Sent:

[dpdk-dev] [PATCH v5] KNI: use a memzone pool for KNI alloc/release

2014-10-21 12:46, Marc Sune: > The previous implementation of rte_kni_alloc() was allocating memzones with a > name composed of a fixed string and the interface name. When an application > was > allocating and deallocating multiple interfaces with different names, memzones > were quickly

[dpdk-dev] nic loopback

2014-10-20 19:24, Alex Markuze: > I'm trying to send packets from an application to it self, meaning smac == > dmac. > I'm working with intel 82599 virtual function. But it seems that these > packets are lost. > > Is there a software/hw limitation I'm missing here (some additional >

[dpdk-dev] [PATCH v6 5/9] librte_ether:add data structures of VxLAN filter

2014-10-21 16:46, Jijiang Liu: > +#define RTE_TUNNEL_FILTER_TO_QUEUE 1 /**< point to an queue by filter type */ Sorry, I don't understand what is this value for? > +#define RTE_TUNNEL_FILTER_IMAC_IVLAN (ETH_TUNNEL_FILTER_IMAC | \ > + ETH_TUNNEL_FILTER_IVLAN) >

[dpdk-dev] [PATCH v6 9/9] app/testpmd:test VxLAN Tx checksum offload

Add test cases in testpmd to test VxLAN Tx Checksum offload, which include - IPv4 and IPv6 packet - outer L3, inner L3 and L4 checksum offload for Tx side. Signed-off-by: Jijiang Liu Acked-by: Helin Zhang Acked-by: Jingjing Wu Acked-by: Jing Chen --- app/test-pmd/cmdline.c | 13 ++-

[dpdk-dev] [PATCH v6 8/9] i40e:support VxLAN Tx checksum offload

Support VxLAN Tx checksum offload, which include - outer L3(IP) checksum offload - inner L3(IP) checksum offload - inner L4(UDP, TCP and SCTP) checksum offload Signed-off-by: Jijiang Liu Acked-by: Helin Zhang Acked-by: Jingjing Wu Acked-by: Jing Chen --- lib/librte_mbuf/rte_mbuf.h

[dpdk-dev] [PATCH v6 7/9] app/testpmd:test VxLAN packet filter

Add the tunnel_filter command in testpmd to test the API of VxLAN packet filter. Signed-off-by: Jijiang Liu Acked-by: Helin Zhang Acked-by: Jingjing Wu Acked-by: Jing Chen --- app/test-pmd/cmdline.c | 152 1 files changed, 152 insertions(+),

[dpdk-dev] [PATCH v6 6/9] i40e:implement API of VxLAN packet filter in librte_pmd_i40e

The implementation of VxLAN tunnel filter in librte_pmd_i40e, which include - add the i40e_tunnel_filter_handle() function. - add the i40e_dev_tunnel_filter_set() function. Signed-off-by: Jijiang Liu Acked-by: Helin Zhang Acked-by: Jingjing Wu Acked-by: Jing Chen ---

[dpdk-dev] [PATCH v6 5/9] librte_ether:add data structures of VxLAN filter

Add definations of the data structures of tunneling packet filter in the rte_eth_ctrl.h file. Signed-off-by: Jijiang Liu Acked-by: Helin Zhang Acked-by: Jingjing Wu Acked-by: Jing Chen --- lib/librte_ether/rte_eth_ctrl.h | 64 +++

[dpdk-dev] [PATCH v6 4/9] app/test-pmd:test VxLAN packet identification

Add two commands to test VxLAN packet identification, which include - use commands to add/delete VxLAN UDP port. - use rxonly mode to receive VxLAN packet. Signed-off-by: Jijiang Liu Acked-by: Helin Zhang Acked-by: Jingjing Wu Acked-by: Jing Chen --- app/test-pmd/cmdline.c| 65

[dpdk-dev] [PATCH v6 3/9] i40e:support VxLAN packet identification in librte_pmd_i40e

Implement configuration of VxLAN destination UDP port number in librte_pmd_i40e. Signed-off-by: Jijiang Liu Acked-by: Helin Zhang Acked-by: Jingjing Wu Acked-by: Jing Chen --- lib/librte_pmd_i40e/i40e_ethdev.c | 164 + lib/librte_pmd_i40e/i40e_ethdev.h |

[dpdk-dev] [PATCH v6 2/9] librte_ether:add VxLAN packet identification API in librte_ether

There are "some" destination UDP port numbers that have unque meaning. In terms of VxLAN, "IANA has assigned the value 4789 for the VXLAN UDP port, and this value SHOULD be used by default as the destination UDP port. Some early implementations of VXLAN have used other values for the destination

[dpdk-dev] [PATCH v6 1/9] librte_mbuf:the rte_mbuf structure changes

Remove the "reserved2" field and add the "packet_type" and the "inner_l2_l3_len" fields in the rte_mbuf structure. The packet type field is used to indicate ordinary L2 packet format and also tunneling packet format such as IP in IP, IP in GRE, MAC in GRE and MAC in UDP. The inner L2 length

[dpdk-dev] [PATCH v6 0/9] Support VxLAN on Fortville

The patch set supports VxLAN on Fortville based on latest rte_mbuf structure. It includes: - Support VxLAN packet identification by configuring UDP tunneling port. - Support VxLAN packet filters. It uses MAC and VLAN to point to a queue. The filter types supported are listed below: 1.

[dpdk-dev] [PATCH] librte_ip_frag: Disable ipv4/v6 fragmentation if RTE_MBUF_REFCNT=n

Ipv4/v6 fragmentation libraries depends on refcnt. There was a compilation error if RTE_MBUF_REFCNT was disabled, so those libraries have been disabled in that situation. Signed-off-by: Pablo de Lara --- lib/librte_ip_frag/Makefile |4 +++- lib/librte_ip_frag/rte_ip_frag.h |5 -

[dpdk-dev] [PATCH] ixgbe: Fix compilation issue in vpmd

Fix the compilation issue in vector PMD when macro RTE_MBUF_REFCNT is disabled. Signed-off-by: Changchun Ouyang --- lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c

[dpdk-dev] [PATCH v6 0/9] Support VxLAN on Fortville

Tested-by: Yong Liu - Tested Commit: 455d09e54b92a4626e178b020fe9c23e43ede3f7 - OS: Fedora20 3.15.8-200.fc20.x86_64 - GCC: gcc version 4.8.3 20140624 - CPU: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz - NIC: Intel Corporation Ethernet Controller XL710 for 40GbE QSFP+ [8086:1583] - Default

[dpdk-dev] [PATCH v6 1/9] librte_mbuf:the rte_mbuf structure changes

> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Tuesday, October 21, 2014 6:26 PM > To: Liu, Jijiang > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v6 1/9] librte_mbuf:the rte_mbuf structure > changes > > Hi Jijiang, > > 2014-10-21

[dpdk-dev] VMDQ DCB

Hi, Would like to know whether VMDQ_DCB is well tested and supported in release v1.3.1 ? Thanks, Sunil

[dpdk-dev] [PATCH v6 2/9] librte_ether:add VxLAN packet identification API in librte_ether

> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Tuesday, October 21, 2014 6:51 PM > To: Liu, Jijiang > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v6 2/9] librte_ether:add VxLAN packet > identification API in librte_ether > >

[dpdk-dev] [PATCH] ixgbe: Fix compilation issue in vpmd

> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > Sent: Tuesday, October 21, 2014 9:36 AM > To: Ouyang, Changchun; De Lara Guarch, Pablo > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH] ixgbe: Fix compilation issue in vpmd > >

[dpdk-dev] virtio UIO / PMD issues in default Ubuntu Cloud Images

Hi Matthew, > -Original Message- > From: Matthew Hall [mailto:mhall at mhcomputing.net] > Sent: Friday, October 17, 2014 9:57 AM > To: Gonzalez Monroy, Sergio > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] virtio UIO / PMD issues in default Ubuntu Cloud > Images > [...] > The virtio non

[dpdk-dev] [PATCH v2 1/4] app/test: unit test for rx and tx cycles/packet

> -Original Message- > From: Neil Horman [mailto:nhorman at tuxdriver.com] > Sent: Tuesday, October 21, 2014 6:33 PM > To: Liang, Cunming > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2 1/4] app/test: unit test for rx and tx > cycles/packet > > On Sun, Oct 12, 2014 at

[dpdk-dev] [PATCH v4] KNI: use a memzone pool for KNI alloc/release

Thomas, v5: commit message arranged, all warnings from checkpatch.pl fixed except: WARNING: Macros with flow control statements should be avoided #104: FILE: lib/librte_kni/rte_kni.c:62: +#define KNI_MEM_CHECK(cond) do { if (cond) goto kni_fail; } while (0) a) This MACRO was there before, I

[dpdk-dev] [PATCH v6 2/9] librte_ether:add VxLAN packet identification API in librte_ether

2014-10-21 16:46, Jijiang Liu: > There are "some" destination UDP port numbers that have unque meaning. > In terms of VxLAN, "IANA has assigned the value 4789 for the VXLAN UDP port, > and this value > SHOULD be used by default as the destination UDP port. Some early > implementations of VXLAN >

[dpdk-dev] [PATCH v5] KNI: use a memzone pool for KNI alloc/release

The previous implementation of rte_kni_alloc() was allocating memzones with a name composed of a fixed string and the interface name. When an application was allocating and deallocating multiple interfaces with different names, memzones were quickly exhausted, even though memzones from deallocated

[dpdk-dev] [PATCH v6 1/9] librte_mbuf:the rte_mbuf structure changes

Hi Jijiang, 2014-10-21 16:46, Jijiang Liu: > Remove the "reserved2" field and add the "packet_type" "Remove and add" can be said "Replace". > and the "inner_l2_l3_len" fields in the rte_mbuf structure. Please explain that you are using 2 bytes of the second cache line for TX offloading of

[dpdk-dev] development/integration branch?

Thomas, On 21/10/14 11:28, Thomas Monjalon wrote: > 2014-10-21 11:14, Marc Sune: >> On 21/10/14 10:46, Thomas Monjalon wrote: >>> My balance is different because I have a simpler solution for Marc's >>> problem: >>> git fetch && git merge $(git tag | grep -v -- -rc | tail -n1) >> We all know

[dpdk-dev] development/integration branch?

2014-10-21 11:14, Marc Sune: > On 21/10/14 10:46, Thomas Monjalon wrote: > > My balance is different because I have a simpler solution for Marc's > > problem: > > git fetch && git merge $(git tag | grep -v -- -rc | tail -n1) > > We all know we _can_ do this. But is it really necessary? We

[dpdk-dev] [PATCH] Fix warnings if DPDK is used with C++1x: Format macro constants for fixed width integer types need a space after the preceding string literal.

Hi, Thank you for the patch. Not a lot of people use DPDK with C++, so we probably need some fixes. Please, could you send a v2 of this patch with a shorter title, an explanation in commit log and a signed-off? Guidelines are explained here: http://dpdk.org/dev#send 2014-10-21 10:38,

[dpdk-dev] [PATCH v5 5/5] app/testpmd: add commands to support hash filter

To demonstrate the hash filter control, commands are added. They are - get_sym_hash_ena_per_port - set_sym_hash_ena_per_port - get_sym_hash_ena_per_pctype - set_sym_hash_ena_per_pctype - get_filter_swap - set_filter_swap - get_hash_function - set_hash_function Signed-off-by: Helin Zhang ---

[dpdk-dev] [PATCH v5 4/5] i40e: add hardware initialization

As global registers will be reset only after a whole chip reset, those registers might not be in an initial state after each launching a physical port. The hardware initialization is added to put specific global registers into an initial state. Signed-off-by: Helin Zhang ---

[dpdk-dev] [PATCH v5 3/5] i40e: add hash filter control implementation

Hash filter control has been implemented for i40e. It includes getting/setting, - hash function type - symmetric hash enable per pctype (packet classification type) - symmetric hash enable per port - filter swap configuration Signed-off-by: Helin Zhang --- lib/librte_pmd_i40e/i40e_ethdev.c |

[dpdk-dev] [PATCH v5 2/5] ethdev: add enum type and relevant structures for hash filter control

enum type and relevant structures are added in rte_eth_ctrl.h to support hash filter control. Signed-off-by: Helin Zhang --- lib/librte_ether/rte_eth_ctrl.h | 75 + 1 file changed, 75 insertions(+) v5 changes: * Integrated with filter API defined

[dpdk-dev] [PATCH v5 1/5] i40e: Use constant random hash keys

To be simpler, and remove the race condition, it uses prepared constant random hash keys to replace runtime generating the hash keys. Signed-off-by: Helin Zhang --- lib/librte_pmd_i40e/i40e_ethdev.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git

[dpdk-dev] [PATCH v5 0/5] Support configuring hash functions

These patches mainly support configuring hash functions. In detail, - It can get or set hash functions. - It can configure symmetric hash functions. * Get/set symmetric hash enable per port. * Get/set symmetric hash enable per 'PCTYPE'. * Get/set filter swap configurations. - Six

[dpdk-dev] development/integration branch?

On 21/10/14 10:46, Thomas Monjalon wrote: > My balance is different because I have a simpler solution for Marc's problem: > git fetch && git merge $(git tag | grep -v -- -rc | tail -n1) Thomas, We all know we _can_ do this. But is it really necessary? We should be all as lazy as possible

[dpdk-dev] development/integration branch?

2014-10-21 08:36, Richardson, Bruce: > From: Marc Sune > > Some DPDK users, including myself, use a clone of the git repository to > > compile DPDK for their applications, instead of downloading the tarball > > of each release. > > > > In my opinion, it would be useful for such users that the

[dpdk-dev] [PATCH v2 1/4] app/test: unit test for rx and tx cycles/packet

> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman > Sent: Tuesday, October 21, 2014 11:33 AM > To: Liang, Cunming > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2 1/4] app/test: unit test for rx and tx > cycles/packet > > > > > > > > +

[dpdk-dev] [PATCH] Fix warnings if DPDK is used with C++1x: Format macro constants for fixed width integer types need a space after the preceding string literal.

From: Matthias Bartelt --- lib/librte_eal/common/include/rte_pci.h |4 ++-- lib/librte_mempool/rte_mempool.h|8 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/lib/librte_eal/common/include/rte_pci.h

[dpdk-dev] [PATCH] ixgbe: Fix compilation issue in vpmd

2014-10-21 08:28, Ouyang, Changchun: > From: De Lara Guarch, Pablo > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > > > 2014-10-21 14:59, Ouyang Changchun: > > > > Fix the compilation issue in vector PMD when macro RTE_MBUF_REFCNT > > > > is disabled. > > > > > > > >

[dpdk-dev] Why do we need iommu=pt?

DPDK uses a 1:1 mapping and doesn't support IOMMU. IOMMU allows for simpler VM physical address translation. The second role of IOMMU is to allow protection from unwanted memory access by an unsafe devise that has DMA privileges. Unfortunately this protection comes with an extremely high

[dpdk-dev] [PATCH v4] KNI: use a memzone pool for KNI alloc/release

Hi Marc, 2014-10-18 00:51, Marc Sune: > This patch implements the KNI memzone pool in order to prevent > memzone exhaustion when allocating/deallocating KNI interfaces. > > It adds a new API call, rte_kni_init(max_kni_ifaces) that shall > be called before any call to rte_kni_alloc() if KNI is

[dpdk-dev] development/integration branch?

Good morning, Some DPDK users, including myself, use a clone of the git repository to compile DPDK for their applications, instead of downloading the tarball of each release. In my opinion, it would be useful for such users that the master branch contains only stable releases, to prevent

[dpdk-dev] Memory corruption in librte_ether?

Pablo, I've only tried with the kni-autotest but it seems to work fine. Thanks! Btw, at least in my development VM the kni-autotest in the current head (455d09e i40e: generic filter control), but also in v1.7.1, fails: RTE>>kni_autotest master lcore: 0 count: 2 PMD: eth_em_rx_queue_setup():

[dpdk-dev] [PATCH] ixgbe: Fix compilation issue in vpmd

2014-10-21 14:59, Ouyang Changchun: > Fix the compilation issue in vector PMD when macro RTE_MBUF_REFCNT is > disabled. > > Signed-off-by: Changchun Ouyang Acked-by: Thomas Monjalon Applied Thanks -- Thomas

[dpdk-dev] Why do we need iommu=pt?

Hi, Thank you for all the replies. I am trying to understand the impact of this on DPDK. What will be the repercussions of disabling "iommu=pt" on the DPDK performance? On Tue, Oct 21, 2014 at 12:32 AM, Alex Markuze wrote: > DPDK uses a 1:1 mapping and doesn't support IOMMU. IOMMU allows for

[dpdk-dev] development/integration branch?

On Tue, Oct 21, 2014 at 11:38:34AM +0200, Marc Sune wrote: > Thomas, > > On 21/10/14 11:28, Thomas Monjalon wrote: > >2014-10-21 11:14, Marc Sune: > >>On 21/10/14 10:46, Thomas Monjalon wrote: > >>>My balance is different because I have a simpler solution for Marc's > >>>problem: > >>> git

[dpdk-dev] [PATCH v2 1/4] app/test: unit test for rx and tx cycles/packet

On Tue, Oct 21, 2014 at 10:43:03AM +, Richardson, Bruce wrote: > > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman > > Sent: Tuesday, October 21, 2014 11:33 AM > > To: Liang, Cunming > > Cc: dev at dpdk.org > > Subject: Re: [dpdk-dev]

[dpdk-dev] development/integration branch?

> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Marc Sune > Sent: Tuesday, October 21, 2014 9:23 AM > To: > Subject: [dpdk-dev] development/integration branch? > > Good morning, > > Some DPDK users, including myself, use a clone of the git repository to >

[dpdk-dev] [PATCH] ixgbe: Fix compilation issue in vpmd

Hi Pablo > -Original Message- > From: De Lara Guarch, Pablo > Sent: Tuesday, October 21, 2014 4:19 PM > To: Thomas Monjalon; Ouyang, Changchun > Cc: dev at dpdk.org > Subject: RE: [dpdk-dev] [PATCH] ixgbe: Fix compilation issue in vpmd > > Hi Thomas, > > > -Original Message- > >

[dpdk-dev] [PATCH] ixgbe: Fix compilation issue in vpmd

Hi Thomas, > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > Sent: Tuesday, October 21, 2014 9:04 AM > To: Ouyang, Changchun > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH] ixgbe: Fix compilation issue in vpmd > > 2014-10-21 14:59,

[dpdk-dev] [PATCH v2] pmd: Add generic support for TCP TSO (Transmit Segmentation Offload)

From: Miroslaw Walukiewicz The NICs supported by DPDK have a possibility to accelerate TCP traffic by sergnention offload. The application preprares a packet with valid TCP header with size up to 64K and NIC makes packet segmenation generating valid checksums and

[dpdk-dev] [PATCH v2 1/4] app/test: unit test for rx and tx cycles/packet

On Sun, Oct 12, 2014 at 11:10:39AM +, Liang, Cunming wrote: > Hi Neil, > > Very appreciate your comments. > I add inline reply, will send v3 asap when we get alignment. > > BRs, > Liang Cunming > > > -Original Message- > > From: Neil Horman [mailto:nhorman at tuxdriver.com] > >

[dpdk-dev] [PATCH v4] KNI: use a memzone pool for KNI alloc/release

> This patch implements the KNI memzone pool in order to prevent memzone > exhaustion when allocating/deallocating KNI interfaces. > > It adds a new API call, rte_kni_init(max_kni_ifaces) that shall be called > before > any call to rte_kni_alloc() if KNI is used. > > v2: Moved KNI fd opening to

[dpdk-dev] [PATCH] examples/vmdq: support i40e in vmdq example

Tested-by: Min Cao This patch has been verified on fortville and it is ready to be integrated to dpdk.org. -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Huawei Xie Sent: Wednesday, September 24, 2014 6:54 PM To: dev at dpdk.org Subject: [dpdk-dev] [PATCH]

[dpdk-dev] [PATCH 0/6] i40e VMDQ support

Tested-by: Min Cao This patch has been verified on fortville and it is ready to be integrated to dpdk.org. -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Chen Jing D(Mark) Sent: Tuesday, September 23, 2014 9:14 PM To: dev at dpdk.org Subject: [dpdk-dev] [PATCH

[dpdk-dev] [PATCH v2 0/6] i40e VMDQ support

Tested-by: Min Cao This patch has been verified on fortville and it is ready to be integrated to dpdk.org. -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Chen Jing D(Mark) Sent: Thursday, October 16, 2014 6:07 PM To: dev at dpdk.org Subject: [dpdk-dev] [PATCH

[dpdk-dev] [PATCH v3 0/2] app/test: unit test to measure cycles per packet

Patch name: PMD performance unit test Brief description: unit test to measure cycles per packet Test Flag: Tested-by Tester name:yong.liu at intel.com Test environment: OS: Fedora20 3.11.10-301.fc20.x86_64

[dpdk-dev] nic loopback

> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Alex Markuze > Sent: Tuesday, October 21, 2014 12:24 AM > To: dev at dpdk.org > Subject: [dpdk-dev] nic loopback > > Hi, > I'm trying to send packets from an application to it self, meaning smac == > dmac. >

[dpdk-dev] [PATCH v2 0/2] new filter APIs definition

2014-10-20 13:40, Jingjing Wu: > new filter APIs definition in ethdev > define filter_ctrl ops in i40e driver > > v2 changes: > remove OP from the name of filter opeartions > add API implementation in i40e. > correct comments > > Jingjing Wu (2): > librte_ether: new filter APIs

[dpdk-dev] [PATCH v3 0/3] add i40e RSS support in VF

> > As hardware supports RSS in VF, the patches add that support in driver. In > > addition, minor improvements are added for defining macro with constant. > > > > v2 changes: > > * Removed support of updating/querying redirection table, as it > > will be implemented in another patches later. >

[dpdk-dev] [PATCH] ethdev: Fixed memory corruption in rte_eth_rx_queue_setup and rte_eth_tx_queue_setup

2014-10-20 18:26, Pablo de Lara:> Commit fbde27f1 (ethdev: get default Rx/Tx configuration from dev info), > introduced a bug, which caused memory corruption in dev_info. > To get RX/TX configuration, both rx/tx queue setup functions were calling > dev_info_get from PMDs, so dev_info structure

[dpdk-dev] [PATCH] librte_eal: FreeBSD contigmem prevent possible buffer overrun during module unload.

> > The maximum mount contiguous memory regions for FreeBSD is limited by > > RTE_CONTIGMEM_MAX_NUM_BUFS, a pointer to each region is stored in > > static void * contigmem_buffers[RTE_CONTIGMEM_MAX_NUM_BUFS] > > > > A user can specify a greater amount via hw.contigmem.num_buffers, > > while the

[dpdk-dev] community collaboration

Hello readers, We are currently targetting a new release (1.8.0) in few weeks. It would be good to have most of the important pending patches in. But writing and sending code is only the first part. After come the reviews. Before integration, we need to validate the design of the new features,