[dpdk-dev] [PATCH v5 7/8]i40e:support VxLAN Tx checksum offload

2014-10-11 13:55, Jijiang Liu: > 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 [...] > + > + /* fields to support tunnelling packet TX offloads */ I know that previous

[dpdk-dev] filter_ctl PMD API idea

> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Friday, October 17, 2014 12:07 AM > To: Wu, Jingjing > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] filter_ctl PMD API idea > > 2014-09-08 15:06, Wu, Jingjing: > > Any comments or advises? > > >

[dpdk-dev] [PATCH v5 0/8]Support VxLAN on Fortville

This test report brings a lot of details. It's a good thing but we should find a way to remove the "administrative words". It should start with the tested-by line to allow copy paste in the commit log. 2014-10-11 07:56, Liu, Yong: > Patch name: Support VxLAN on Fortville > Brief

[dpdk-dev] [PATCH v5 4/8]librte_ether:add a common filter API

I don't review the common API as it should be done in an unique place and there are many copies in different patchsets. Let's focus on tunnels. 2014-10-11 13:55, Jijiang Liu: > +/ TUNNEL FILTER DATA DEFINATION *** */ We cannot miss this comment :) > +#define ETH_TUNNEL_FILTER_OMAC 0x01 >

[dpdk-dev] [PATCH v5 3/8]app/test-pmd:test VxLAN packet identification

2014-10-11 13:55, Jijiang Liu: > - "tx_checksum set mask (port_id)\n" > + "tx_checksum set (mask) (port_id)\n" > "Enable hardware insertion of checksum offload with" > - " the 4-bit mask, 0~0xf, in packets sent

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

> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Alan Carew > Sent: Tuesday, October 14, 2014 1:19 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH] librte_eal: FreeBSD contigmem prevent > possible buffer overrun during module unload. > > The maximum

[dpdk-dev] [PATCH v5 1/8]i40e:support VxLAN packet identification in librte_ether

2014-10-11 13:55, Jijiang Liu: > Add data structures and APIs in librte_ether for supporting tunneling UDP > port configuration on i40e, > Currently, only VxLAN is implemented, which include > - VxLAN UDP port initialization > - Add APIs to configure VxLAN UDP port Please could you explain

[dpdk-dev] [v2 20/23] librte_cfgfile: interpret config files

Hi Cristian, 2014-06-04 19:08, Cristian Dumitrescu: > This library provides a tool to interpret config files that have standard > structure. > > It is used by the Packet Framework examples/ip_pipeline sample application. > > It originates from examples/qos_sched sample application and now it

[dpdk-dev] [PATCH v4 04/10] VM Power Management application and Makefile.

> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Alan Carew > Sent: Sunday, October 12, 2014 8:36 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v4 04/10] VM Power Management application > and Makefile. > > For launching CLI thread and Monitor thread

[dpdk-dev] [PATCH v2 6/6] i40e: Add full VMDQ pools support

From: "Chen Jing D(Mark)" 1. Function i40e_vsi_* name change to i40e_dev_* since PF can contains more than 1 VSI after VMDQ enabled. 2. i40e_dev_rx/tx_queue_setup change to have capability of setup queues that belongs to VMDQ pools. 3. Add queue mapping. This will do

[dpdk-dev] [PATCH v2 5/6] i40e: macaddr add/del enhancement

From: "Chen Jing D(Mark)" Change i40e_macaddr_add and i40e_macaddr_remove functions to support multiple macaddr add/delete. In the meanwhile, support macaddr ops on different pools. Signed-off-by: Chen Jing D(Mark) --- lib/librte_pmd_i40e/i40e_ethdev.c | 89

[dpdk-dev] [PATCH v2 4/6] i40e: add VMDQ support

From: "Chen Jing D(Mark)" The change includes several parts: 1. Get maximum number of VMDQ pools supported in dev_init. 2. Fill VMDQ info in i40e_dev_info_get. 3. Setup VMDQ pools in i40e_dev_configure. 4. i40e_vsi_setup change to support creation of VMDQ VSI.

[dpdk-dev] [PATCH v2 3/6] ixgbe: change for VMDQ arguments expansion

From: "Chen Jing D(Mark)" Assign new VMDQ arguments with correct values. Signed-off-by: Chen Jing D(Mark) --- lib/librte_pmd_ixgbe/ixgbe_ethdev.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c

[dpdk-dev] [PATCH v2 1/6] ether: enhancement for VMDQ support

From: "Chen Jing D(Mark)" The change includes several parts: 1. Clear pool bitmap when trying to remove specific MAC. 2. Define RSS, DCB and VMDQ flags to combine rx_mq_mode. 3. Use 'struct' to replace 'union', which to expand the rx_adv_conf arguments to better support

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

From: "Chen Jing D(Mark)" v2: - Fix a few typos. - Add comments for RX mq mode flags. - Remove '\n' from some log messages. - Remove 'Acked-by' in commit log. v1: Define extra VMDQ arguments to expand VMDQ configuration. This also includes change in igb and ixgbe PMD

[dpdk-dev] filter_ctl PMD API idea

2014-09-08 15:06, Wu, Jingjing: > Any comments or advises? > > Thanks! > > Fortville Filter features' development will be started based on this design > this week. Thanks Jingjing for explaining your plan before working on it. There were no comment for 1 month so we'll assume everybody is OK.

[dpdk-dev] [PATCH 1/4] lib/librte_ether: new filter APIs definition

2014-10-10 07:28, De Lara Guarch, Pablo: > > > > > Define new APIs to support configure multi-kind filters using same > > > > > APIs > > > > > - rte_eth_dev_filter_supported > > > > > - rte_eth_dev_filter_ctrl > > > > > > > > > > As to the implemetation discussion, please refer to > > > > >

[dpdk-dev] [PATCH v4 00/10] VM Power Management

Hi Thomas, > > However with a DPDK solution it would be possible to re-use the message bus > > to pass information like device stats, application state, D-state requests > > etc. to the host and allow for management layer(e.g. OpenStack) to make > > informed decisions. > > I think that

[dpdk-dev] [PATCH v5 4/8]librte_ether:add a common filter API

> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jijiang Liu > Sent: Saturday, October 11, 2014 6:56 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v5 4/8]librte_ether:add a common filter API > > Introduce a new filter framewok in librte_ether. As to

[dpdk-dev] Possibility to unbind interface by DPDK

I have a question regarding unbinding Linux interface from EAL. This feature was present up to dpdk 1.4 and next it was removed. It was available under RTE_EAL_UNBIND_PORTS flag. Is there a possibility to get this feature back in the next releases? Unbinding interfaces from EAL makes possible

[dpdk-dev] [PATCH 02/12] Add atomic operations for IBM Power architecture

Konstantin, In my understanding, compiler barrier is a kind of software barrier which prevents the compiler from moving memory accesses across the barrier. This should be architecture-independent. And the "sync" instruction is a hardware barrier which depends on PowerPC architecture. So I

[dpdk-dev] [PATCH 02/12] Add atomic operations for IBM Power architecture

> -Original Message- > From: Richardson, Bruce > Sent: Thursday, October 16, 2014 10:43 AM > To: Chao CH Zhu; Ananyev, Konstantin > Cc: dev at dpdk.org > Subject: RE: [dpdk-dev] [PATCH 02/12] Add atomic operations for IBM Power > architecture > > > -Original Message- > > From:

[dpdk-dev] [PATCH 02/12] Add atomic operations for IBM Power architecture

> > > From: Chao CH Zhu [mailto:bjzhuc at cn.ibm.com] > Sent: Thursday, October 16, 2014 4:14 AM > To: Ananyev, Konstantin > Cc: dev at dpdk.org > Subject: RE: [dpdk-dev] [PATCH 02/12] Add atomic operations for IBM Power > architecture > > Konstantin, > > In my understanding, compiler

[dpdk-dev] kernel panic when stop my test demo

On 2014/10/15 18:08, Richardson, Bruce wrote: > > >> -Original Message- >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Lilijun >> Sent: Wednesday, October 15, 2014 10:43 AM >> To: dev at dpdk.org; stephen at networkplumber.org >> Subject: Re: [dpdk-dev] kernel panic when stop

[dpdk-dev] [PATCH v5 2/8]i40e:support VxLAN packet identification in librte_pmd_i40e

> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of De Lara Guarch, > Pablo > Sent: Monday, October 13, 2014 5:13 PM > To: Liu, Jijiang; dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v5 2/8]i40e:support VxLAN packet > identification in librte_pmd_i40e > >

[dpdk-dev] [PATCH 02/12] Add atomic operations for IBM Power architecture

> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Chao CH Zhu > Sent: Thursday, October 16, 2014 4:14 AM > To: Ananyev, Konstantin > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH 02/12] Add atomic operations for IBM Power > architecture > > Konstantin,

[dpdk-dev] kernel panic when stop my test demo

> -Original Message- > From: Lilijun [mailto:jerry.lilijun at huawei.com] > Sent: Thursday, October 16, 2014 3:40 AM > To: Richardson, Bruce; dev at dpdk.org; stephen at networkplumber.org > Subject: Re: [dpdk-dev] kernel panic when stop my test demo > > On 2014/10/15 18:08, Richardson,

[dpdk-dev] [PATCH v2 7/7] Split CPU flags operations to architecture specific

This patch splits CPU flags related operations from DPDK and push them to architecture specific arch directories, so that other processor architecture can implement it's own CPU flag functions to support DPDK. Signed-off-by: Chao Zhu --- lib/librte_eal/common/Makefile |4

[dpdk-dev] [PATCH v2 6/7] Split memcpy operation to architecture specific

This patch splits the SSE based memory copy function from DPDK and push them to architecture specific arch directories. Other processor architecture can implement it's own vector based memory copy functions. Signed-off-by: Chao Zhu --- lib/librte_eal/common/Makefile |4 +-

[dpdk-dev] [PATCH v2 5/7] Split spinlock operations to architecture specific

This patch splits the spinlock operations from DPDK and push them to architecture specific arch directories, so that other processor architecture to support DPDK can be easily adopted. Signed-off-by: Chao Zhu --- lib/librte_eal/common/Makefile |4 +-

[dpdk-dev] [PATCH v2 4/7] Split prefetch operations to architecture specific

This patch splits the prefetch operations from DPDK and push them to architecture specific arch directories, so that other processor architecture to support DPDK can implement their own functions. Signed-off-by: Chao Zhu --- lib/librte_eal/common/Makefile |4 +-

[dpdk-dev] [PATCH v2 3/7] Split CPU cycle operation to architecture specific

This patch splits the CPU TSC read operations from DPDK and push them to architecture specific arch directories, so that other processors that don't have tsc register can be can implement its'own functions. Signed-off-by: Chao Zhu --- lib/librte_eal/common/Makefile |4 +-

[dpdk-dev] [PATCH v2 2/7] Split byte order operations to architecture specific

This patch splits the byte order operations from DPDK and push them to architecture specific arch directories, so that other processor architecture to support DPDK can be easily adopted. Signed-off-by: Chao Zhu --- lib/librte_eal/common/Makefile |4 +-

[dpdk-dev] [PATCH v2 1/7] Split atomic operations to architecture specific

This patch first add architecture specific directories to eal header file directory. Then split the atomic operations to architecture specific and generic files. Architecture specific files are put into the corresponding architecture directory and common header are put into generic directory.

[dpdk-dev] [PATCH v2 0/7] Patches to split architecture specific operations from DPDK

The set of patches split x86 architecture specific operations from DPDK and put them to the arch directories of i686 and x86_64 architecture. This will make the adpotion of DPDK much easier on other computer architecture. For a new architecture, just add an architecture specific directory and

[dpdk-dev] to the intel dpdk engineers and all contributors

On Oct 15, 2014, at 1:46 PM, daniel chapiesky wrote: > I just watched the closing remarks by Tim Driscol at the dpdk summit > > http://youtu.be/r-JA5NBybrs > > At time 4:30, he mentioned the "shock to the system" of developers > expecting a pat on the back and instead receiving critiques

[dpdk-dev] i40e: Steps and required configurations of how to achieve the best performance!

Hi Thomas Yes, your proposal it the perfect one, also the most complicated one. I was thinking of that one as well, but we did not have enough time for that in our 1.8 timeframe. In the long run, I agree with you to implement EAL function to access PCI config space directly. I will try to put

[dpdk-dev] [PATCH 02/12] Add atomic operations for IBM Power architecture

Hi, > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Chao Zhu > Sent: Friday, September 26, 2014 10:36 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH 02/12] Add atomic operations for IBM Power > architecture > > The atomic operations implemented