[dpdk-dev] [dpdk-announce] DPDK 16.11 released
Thomas, it's great to hear that DPDK16.11 released just in time. As prospect for 17.02, our intel validation team have some concern about the release date. The official day off for Chinese Sprint Festival holiday will be from 27th Jan to 3th Feb. Most of our members may ask for more days leave either before or after the official day off. >From our previous experience, it will take 3~4 weeks to do the full function >and performance test. If the first candidate release in the middle of Jan, we can do first round of validation and raise issues to developers. And after the holiday, we can keep on the validation process and finish in two weeks. If release date is after Feb, it will be hard for us to cover all cases in release window. Thanks, DPDK STV team > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > Sent: Monday, November 14, 2016 6:23 AM > To: announce at dpdk.org > Subject: [dpdk-dev] [dpdk-announce] DPDK 16.11 released > > The new features for the 17.02 cycle must be submitted before December 4. > There is a long list of expected works: > http://dpdk.org/dev/roadmap > It means we will have a huge workload to properly review all the new stuff > before the end of the year. Do not forget to help reviewing patches from > others if we want to have a chance to integrate everything in time. > > > Thanks everyone
[dpdk-dev] [PATCH v2 0/2] add aes-sha384-hmac support to Intel QAT driver
Tested-by: Yong Liu - Tested Branch: dpdk-next-crypto/master - Tested Commit: 3e329d659b62097d15ec86ff92acc8effaf28cd2 - OS: Fedora20 3.11.10-301.fc20.x86_64 - GCC: gcc version 4.8.3 20140911 - CPU: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz - NIC: Intel Corporation Device Fortville [8086:1583] - QAT: Intel Corporation Coleto Creek PCIe Endpoint [8086:0435] - Default x86_64-native-linuxapp-gcc configuration - Prerequisites: - Total 2 cases, 2 passed, 0 failed - Prerequisites command / instruction: Enable CONFIG_RTE_LIBRTE_PMD_QAT in config/common_base and rebuild dpdk Bind QAT VF devices to igb_uio - Case: Description: SHA384_HMAC authentication unit test Command / instruction: Start test application with normal eal parameter. ./$RTE_TARGET/app/test -c f -n 4 -- -i Run crypto QAT unit test suite and verify SHA384_HMAC cases passed - Case: Description: l2fwd_crypto with SHA384_HMAC authentication test Command / instruction: Start l2fwd_crypto with QAT technology enable. Authentication method is SHA384_HMAC, auth key is also inputted in. Authentication key length for SHA384_HMAC should be 128 bytes. ./examples/l2fwd-crypto/build/app/l2fwd-crypto -c0xf -n4 -- -p0x1 \ --chain HASH_ONLY --cdev_type ANY --auth_algo SHA384_HMAC \ --auth_op GENERATE --auth_key $auth_key Send 65 packets with random 64 bytes payload and capture forwarded packets. Check all forwarded packets contained of 48 bytes hashed value. Check hash values are same as calculated value. > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Deepak Kumar Jain > Sent: Tuesday, September 13, 2016 3:51 AM > To: dev at dpdk.org > Cc: De Lara Guarch, Pablo; Jain, Deepak K > Subject: [dpdk-dev] [PATCH v2 0/2] add aes-sha384-hmac support to Intel > QAT driver > > This patchset adds support of aes-sha384-hmac in Intel(R) QuickAssist > Technology driver. > > This patchset depends on following patchset: > "crypto/qat: add aes-sha224-hmac capability to Intel QAT driver" > (http://dpdk.org/dev/patchwork/patch/15776/) > > > Jain, Deepak K (2): > crypto/qat: add aes-sha384-hmac capability to Intel QAT driver > app/test: add test cases for aes-sha384-hmac for Intel QAT driver > > Changes from V1: > * Added new feature information in release_16_11.rst file. > * Added information about sha384-hmac in capabilities. > > app/test/test_cryptodev_aes.c| 6 +++-- > doc/guides/cryptodevs/qat.rst| 1 + > doc/guides/rel_notes/release_16_11.rst | 1 + > drivers/crypto/qat/qat_adf/qat_algs_build_desc.c | 33 > > drivers/crypto/qat/qat_crypto.c | 31 > +++--- > 5 files changed, 66 insertions(+), 6 deletions(-) > > -- > 2.5.5
[dpdk-dev] [PATCH v3 0/2] add aes-sha224-hmac support to Intel QAT driver
Tested-by: Yong Liu - Tested Branch: dpdk-next-crypto/master - Tested Commit: 3e329d659b62097d15ec86ff92acc8effaf28cd2 - OS: Fedora20 3.11.10-301.fc20.x86_64 - GCC: gcc version 4.8.3 20140911 - CPU: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz - NIC: Intel Corporation Device Fortville [8086:1583] - QAT: Intel Corporation Coleto Creek PCIe Endpoint [8086:0435] - Default x86_64-native-linuxapp-gcc configuration - Prerequisites: - Total 2 cases, 2 passed, 0 failed - Prerequisites command / instruction: Enable CONFIG_RTE_LIBRTE_PMD_QAT in config/common_base and rebuild dpdk Bind QAT VF devices to igb_uio - Case: Description: SHA224_HMAC authentication unit test Command / instruction: Start test application with normal eal parameter. ./$RTE_TARGET/app/test -c f -n 4 -- -i Run crypto QAT unit test suite and verify SHA224_HMAC cases passed - Case: Description: l2fwd_crypto with SHA224_HMAC authentication test Command / instruction: Start l2fwd_crypto with QAT technology enable. Authentication method is SHA224_HMAC, auth key is also inputted in. Authentication key length for SHA224_HMAC should be 64 bytes. ./examples/l2fwd-crypto/build/app/l2fwd-crypto -c0xf -n4 -- -p0x1 \ --chain HASH_ONLY --cdev_type ANY --auth_algo SHA224_HMAC \ --auth_op GENERATE --auth_key $auth_key Send 65 packets with random 64 bytes payload and capture forwarded packets. Check all forwarded packets contained of 28 bytes hashed value. Check hash values are same as automatic calculated value. > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Deepak Kumar Jain > Sent: Friday, September 16, 2016 12:27 AM > To: dev at dpdk.org > Cc: De Lara Guarch, Pablo; Jain, Deepak K > Subject: [dpdk-dev] [PATCH v3 0/2] add aes-sha224-hmac support to Intel > QAT driver > > This patchset adds support of aes-sha224-hmac in Intel(R) QuickAssist > Technology driver. > > This patchset depends on following patchset: > "crypto/qat: add MD5 HMAC capability to Intel QAT driver" > (http://dpdk.org/dev/patchwork/patch/15754/) > > Jain, Deepak K (2): > crypto/qat: add aes-sha224-hmac capability to Intel QAT driver > app/test: add test cases for aes-sha224-hmac for Intel QAT driver > > Changes in v3: > * Cover letter updated with correct information about sha224-hmac. > > Changes in v2: > * Added new feature information in release_16_11.rst file. > * Added information about sha224-hmac in capabilities. > > app/test/test_cryptodev_aes.c| 6 +++-- > doc/guides/cryptodevs/qat.rst| 1 + > doc/guides/rel_notes/release_16_11.rst | 1 + > drivers/crypto/qat/qat_adf/qat_algs_build_desc.c | 33 > > drivers/crypto/qat/qat_crypto.c | 25 +- > 5 files changed, 63 insertions(+), 3 deletions(-) > > -- > 2.5.5
[dpdk-dev] [PATCH v2 0/2] Add HMAC_MD5 to Intel QuickAssist Technology driver
Tested-by: Yong Liu - Tested Branch: dpdk-next-crypto/master - Tested Commit: 3e329d659b62097d15ec86ff92acc8effaf28cd2 - OS: Fedora20 3.11.10-301.fc20.x86_64 - GCC: gcc version 4.8.3 20140911 - CPU: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz - NIC: Intel Corporation Device Fortville [8086:1583] - QAT: Intel Corporation Coleto Creek PCIe Endpoint [8086:0435] - Default x86_64-native-linuxapp-gcc configuration - Prerequisites: - Total 2 cases, 2 passed, 0 failed - Prerequisites command / instruction: Enable CONFIG_RTE_LIBRTE_PMD_QAT in config/common_base and rebuild dpdk Bind QAT VF devices to igb_uio - Case: Description: HMAC_MD5 authentication unit test Command / instruction: Start test application with normal eal parameter. ./$RTE_TARGET/app/test -c f -n 4 -- -i Run crypto QAT unit test suite and verify MD5_HMAC cases passed - Case: Description: l2fwd_crypto with HMAC_MD5 authentication test Command / instruction: Start l2fwd_crypto with QAT technology enable. Authentication method is MD5_HMAC, auth key is also inputted in. l2fwd-crypto -c 0xf -n4 -- -p0x1 --chain HASH_ONLY --cdev_type HW \ --auth_algo MD5_HMAC --auth_op GENERATE \ --auth_key 00:01:02:03:04:05:06:07:08:09:0a:0b:0c:0d:0e:0f Send 65 packets with random 64 bytes payload and capture forwarded packets. Check all forwarded packets contained of 16 bytes hashed value. Check hash values are same as automatic calculated value. > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Deepak Kumar Jain > Sent: Friday, September 09, 2016 11:45 PM > To: dev at dpdk.org > Cc: De Lara Guarch, Pablo; Jain, Deepak K > Subject: [dpdk-dev] [PATCH v2 0/2] Add HMAC_MD5 to Intel QuickAssist > Technology driver > > This patchset add capability to use HMAC_MD5 hash algorithm to Intel > QuickAssist Technology driver and test cases to cryptodev test files. > > This patchset depends on the following patches/patchsets: > > "crypto/qat: make the session struct variable in size" > (http://dpdk.org/dev/patchwork/patch/15125/) > > Arkadiusz Kusztal (2): > crypto/qat: add MD5 HMAC capability to Intel QAT driver > app/test: add test cases for MD5 HMAC for Intel QAT driver > > Changes from v1: > * Added new feature information in release_16_11.rst file. > > app/test/test_cryptodev.c| 185 > +++ > app/test/test_cryptodev_hmac_test_vectors.h | 121 +++ > doc/guides/cryptodevs/qat.rst| 1 + > doc/guides/rel_notes/release_16_11.rst | 5 + > drivers/crypto/qat/qat_adf/qat_algs_build_desc.c | 34 + > drivers/crypto/qat/qat_crypto.c | 28 +++- > 6 files changed, 372 insertions(+), 2 deletions(-) > create mode 100644 app/test/test_cryptodev_hmac_test_vectors.h > > -- > 2.5.5
[dpdk-dev] [PATCH] mk: gcc -march support for intel processors code names
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pattan, Reshma > Sent: Monday, August 22, 2016 7:46 PM > To: Thomas Monjalon > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH] mk: gcc -march support for intel > processors code names > > > > > -Original Message- > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > Sent: Monday, August 22, 2016 12:25 PM > > To: Pattan, Reshma > > Cc: dev at dpdk.org > > Subject: Re: [dpdk-dev] [PATCH] mk: gcc -march support for intel > processors > > code names > > > > 2016-08-15 16:02, Reshma Pattan: > > > The GCC 4.9 -march option supports the intel code names for > > > processors, for example -march=silvermont, -march=broadwell. > > > The RTE_MACHINE config flag can be used to pass code name to the > > > compiler as -march flag. Also old gcc versions compatibility code for > > > the intel platform is removed from > > > mk/toolchain/gcc/rte.toolchain-compat.mk > > > > Do you mean to not support GCC < 4.9 ? > > Yes. > > Reshma, In our regression plan, lots of distribution's default gcc version are < 4.9. This patch will block gcc related test on the OSs listed below. Ubuntu 12.04/14.04 Fedora18/20 Suse11SP2/Suse12SP3 RHEL7.0/7.2, CentOS7.0 FreeBSD10.0/10.3
[dpdk-dev] [PATCH] examples/distributor: fix Rx thread logic for zero packets
Tested-by: Marvin Liu
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Reshma Pattan
> Sent: Thursday, July 14, 2016 11:49 PM
> To: dev at dpdk.org
> Cc: Pattan, Reshma
> Subject: [dpdk-dev] [PATCH] examples/distributor: fix Rx thread logic for
> zero packets
>
> From: Reshma Pattan
>
> Zero packets can be returned by rte_eth_rx_burst() and
> rte_distributor_returned_pkts() inside lcore_rx(), so
> for zero packet scenario instead of proceeding to
> next operations we should continue to the next iteration of the
> loop to avoid unnecessary processing overhead which is causing
> rx packets to be dropped and hence distributor failing to forward the
> packets.
>
> Fixes: 07db4a97 ("examples/distributor: new sample app")
>
> Signed-off-by: Reshma Pattan
> ---
> examples/distributor/main.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/examples/distributor/main.c b/examples/distributor/main.c
> index 24857f2..537cee1 100644
> --- a/examples/distributor/main.c
> +++ b/examples/distributor/main.c
> @@ -221,14 +221,22 @@ lcore_rx(struct lcore_params *p)
> struct rte_mbuf *bufs[BURST_SIZE*2];
> const uint16_t nb_rx = rte_eth_rx_burst(port, 0, bufs,
> BURST_SIZE);
> + if (unlikely(nb_rx == 0)) {
> + if (++port == nb_ports)
> + port = 0;
> + continue;
> + }
> app_stats.rx.rx_pkts += nb_rx;
>
> rte_distributor_process(d, bufs, nb_rx);
> const uint16_t nb_ret = rte_distributor_returned_pkts(d,
> bufs, BURST_SIZE*2);
> app_stats.rx.returned_pkts += nb_ret;
> - if (unlikely(nb_ret == 0))
> + if (unlikely(nb_ret == 0)) {
> + if (++port == nb_ports)
> + port = 0;
> continue;
> + }
>
> uint16_t sent = rte_ring_enqueue_burst(r, (void *)bufs,
> nb_ret);
> app_stats.rx.enqueued_pkts += sent;
> --
> 2.5.0
[dpdk-dev] [PATCH] examples/vm_power_manager: fix build with libvirt version < 0.9.3
Thanks Thomas, I'll send v2 for it.
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Monday, April 11, 2016 3:24 PM
> To: Liu, Yong
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] examples/vm_power_manager: fix build with
> libvirt version < 0.9.3
>
> 2016-04-11 11:45, Marvin Liu:
> > vm_power_manager utilize libvirt API virDomainGetVcpuPinInfo for
> > retrieve domU vcpu information. This API implemented from version 0.9.3.
> > Suse11 SP3 32bit default libvirt version is 0.8.8, so there'll be build
> > error. Add judgement in sample Makefile to skip unsupport environment.
> >
> > examples/vm_power_manager/channel_manager.c: In function
> > ?update_pcpus_mask?:
> > channel_manager.c:117:3: error: implicit declaration of function
> > ?virDomainGetVcpuPinInfo?
> >
> > Fixes: 2e099bc5d104 ("fix split of compiler and linker options")
>
> I think the issue has always been there:
> Fixes: e8ae9b662506 ("examples/vm_power: channel manager and monitor in
> host")
>
> > +LIBVIRT_COMMON = libvirt-common.h
> > +LIBVIRT_HEADER = libvirt.h
> > +INCLUDE_PATH = /usr/include/libvirt/
>
> You cannot assume it will be installed in this directory.
> Please check the version with the standard pkg-config:
> pkg-config --atleast-version=0.9.3 libvirt
> It can work even in cross compilation environment thanks to
> PKG_CONFIG_PATH.
[dpdk-dev] [PATCH v2] testpmd: fix build on FreeBSD
> -Original Message-
> From: Qiu, Michael
> Sent: Tuesday, March 22, 2016 5:05 PM
> To: Liu, Yong; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2] testpmd: fix build on FreeBSD
>
> On 3/22/2016 2:51 PM, Marvin Liu wrote:
> > Build log:
> > /root/dpdk/app/test-pmd/cmdline.c:6687:45: error: no member named
> > 's6_addr32' in 'struct in6_addr'
> > rte_be_to_cpu_32(res->ip_value.addr.ipv6.s6_addr32[i]);
> >
> > This is caused by macro "s6_addr32" not defined on FreeBSD and testpmd
> > swap big endian parameter to host endian. Move the swap action to i40e
> > ethdev will fix this issue.
> >
> > Fixes: 7b1312891b69 ("ethdev: add IP in GRE tunnel")
> >
> > Signed-off-by: Marvin Liu
> >
> > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
> > index 9d52b8c..4f3d1e4 100644
> > --- a/app/test-pmd/cmdline.c
> > +++ b/app/test-pmd/cmdline.c
> > @@ -6678,14 +6678,12 @@ cmd_tunnel_filter_parsed(void *parsed_result,
> >
> > if (res->ip_value.family == AF_INET) {
> > tunnel_filter_conf.ip_addr.ipv4_addr =
> > - rte_be_to_cpu_32(res->ip_value.addr.ipv4.s_addr);
> > + res->ip_value.addr.ipv4.s_addr;
> > tunnel_filter_conf.ip_type = RTE_TUNNEL_IPTYPE_IPV4;
> > } else {
> > - int i;
> > - for (i = 0; i < 4; i++) {
> > - tunnel_filter_conf.ip_addr.ipv6_addr[i] =
> > - rte_be_to_cpu_32(res->ip_value.addr.ipv6.s6_addr32[i]);
> > - }
> > + memcpy(&(tunnel_filter_conf.ip_addr.ipv6_addr),
> > + &(res->ip_value.addr.ipv6),
> > + sizeof(struct in6_addr));
> > tunnel_filter_conf.ip_type = RTE_TUNNEL_IPTYPE_IPV6;
> > }
> >
> > diff --git a/drivers/net/i40e/i40e_ethdev.c
> b/drivers/net/i40e/i40e_ethdev.c
> > index 10e0d38..43c2d5c 100644
> > --- a/drivers/net/i40e/i40e_ethdev.c
> > +++ b/drivers/net/i40e/i40e_ethdev.c
> > @@ -6015,6 +6015,7 @@ i40e_dev_tunnel_filter_set(struct i40e_pf *pf,
> > uint8_t add)
> > {
> > uint16_t ip_type;
> > + uint32_t ipv4_addr;
> > uint8_t i, tun_type = 0;
> > /* internal varialbe to convert ipv6 byte order */
> > uint32_t convert_ipv6[4];
> > @@ -6040,14 +6041,15 @@ i40e_dev_tunnel_filter_set(struct i40e_pf *pf,
> > pfilter->inner_vlan = rte_cpu_to_le_16(tunnel_filter->inner_vlan);
> > if (tunnel_filter->ip_type == RTE_TUNNEL_IPTYPE_IPV4) {
> > ip_type = I40E_AQC_ADD_CLOUD_FLAGS_IPV4;
> > + ipv4_addr = rte_be_to_cpu_32(tunnel_filter-
> >ip_addr.ipv4_addr);
>
> As I checked "ipv4_addr" is the host Endian, so does it need to covert
> again? Maybe I'm wrong.
>
Michael,
This logic is for i40e API required little endian. Variable "ipv4_addr" parsed
by cmdline library has been in big endian.
To fulfill the special requirement of admin queue, i40e drive will do the swap.
> Thanks,
> Michael
> > rte_memcpy(>ipaddr.v4.data,
> > - _cpu_to_le_32(tunnel_filter-
> >ip_addr.ipv4_addr),
> > + _cpu_to_le_32(ipv4_addr),
> > sizeof(pfilter->ipaddr.v4.data));
> > } else {
> > ip_type = I40E_AQC_ADD_CLOUD_FLAGS_IPV6;
> > for (i = 0; i < 4; i++) {
> > convert_ipv6[i] =
> > - rte_cpu_to_le_32(tunnel_filter->ip_addr.ipv6_addr[i]);
> > + rte_cpu_to_le_32(rte_be_to_cpu_32(tunnel_filter-
> >ip_addr.ipv6_addr[i]));
> > }
> > rte_memcpy(>ipaddr.v6.data, _ipv6,
> > sizeof(pfilter->ipaddr.v6.data));
[dpdk-dev] [PATCH v5 0/2] fm10k: enable FTAG based forwarding
Tested-by: Yong Liu - Tested Branch: dpdk-next-net/rel_16_04 - Tested Commit: 4ac366ba647909c3b71818f9be9db86ba5e871da - OS: Fedora20 3.11.10-301.fc20.x86_64 - GCC: gcc version 4.8.3 20140911 - CPU: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz - NIC: Intel Corporation Device RedrockCanyou [8086:15a4] - Default x86_64-native-linuxapp-gcc configuration - Prerequisites: - Total 1 cases, 1 passed, 0 failed - Prerequisites command / instruction: Apply fm_ftag unit test patch. export Port0 and Port1's GLORT ID to environment variables export PORT1_GLORT=0x4200 export PORT0_GLORT=0x4000 - Case: Ftag forwarding unit test Description: check fm10k nic can forwarding packets based on FTAG Command / instruction: Start test application and run fm10k_ftag_autotest test -c f -n 4 -w 83:00.0,enable_ftag=1 -w 85:00.0,enable_ftag=1 RTE>>fm10k_ftag_autotest Send packet to Port0 and verify packet forwarded to Port1 Receive 1 packets on port 0 test for FTAG RX passed Send out 1 packets with FTAG on port 0 Receive 1 packets on port 1 test for FTAG TX passed Test OK > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wang Xiao W > Sent: Wednesday, March 02, 2016 7:19 PM > To: Chen, Jing D > Cc: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v5 0/2] fm10k: enable FTAG based forwarding > > v5: > * Used kvargs api to parse the devargs parameter. > * Put release note into the driver patch. > > v4: > * Removed the build time config option, used devargs to config FTAG. > * Rebased on head of dpdk-next-net/rel_16_04 branch. > > v3: > * Removed "\n" in PMD_INIT_LOG. > * Returned "-ENOTSUP" instead of -1 in VF FTAG use case. > > v2: > * Gave an error message for VF FTAG use case. > * Added a notice in the doc to emphasize that application should ensure > an appropriate FTAG for every frame in FTAG based forwarding mode. > > Wang Xiao W (2): > fm10k: enable FTAG based forwarding > doc: add introduction for fm10k FTAG based forwarding > > doc/guides/nics/fm10k.rst | 16 - > doc/guides/rel_notes/release_16_04.rst | 2 ++ > drivers/net/fm10k/fm10k.h | 2 ++ > drivers/net/fm10k/fm10k_ethdev.c | 65 > +- > drivers/net/fm10k/fm10k_rxtx.c | 15 > drivers/net/fm10k/fm10k_rxtx_vec.c | 3 ++ > 6 files changed, 101 insertions(+), 2 deletions(-) > > -- > 1.9.3
[dpdk-dev] [PATCH v7 0/5] Support VxLAN & NVGRE checksum off-load on X550
Sorry, sent to incorrect mail thread. Please ignore this tested-by email. > -Original Message- > From: Liu, Yong > Sent: Friday, March 04, 2016 1:45 PM > To: Lu, Wenzhuo; dev at dpdk.org > Subject: RE: [dpdk-dev] [PATCH v7 0/5] Support VxLAN & NVGRE checksum > off-load on X550 > > Tested-by: Yong Liu > > - Tested Branch: dpdk-next-net > - Tested Commit: 5fa83b5398e26af7537b09605432fcb3d0cc1d41 > - OS: Fedora21 3.17.4-301.fc21.x86_64 > - GCC: gcc version 4.9.2 20150212 > - CPU: Intel(R) Xeon(R) CPU D-1540 @ 2.00GHz > - NIC: Intel Corporation Device Sageville [8086:15ad] > - Default x86_64-native-linuxapp-gcc configuration > - Total 4 cases, 4 passed, 0 failed > > - Prerequisites command / instruction: > Bound PF device to igb_uio > ./tools/dpdk_nic_bind.py --bind=igb_uio 03:00.0 > Create 2VF devices from PF device. > echo 2 > /sys/bus/pci/devices/\:03\:00.0/max_vfs > Detach VFs from the host, bind them to pci-stub driver > virsh # nodedev-dettach pci__03_10_0 > virsh # nodedev-dettach pci__03_10_2 > Passthrough VF 03:10.0 & 03:10.2 to vm0 and start vm0 > /usr/bin/qemu-system-x86_64 -name vm0 -enable-kvm \ > -cpu host -smp 4 -m 2048 -drive file=/home/image/fedora20.img -vnc :1 > \ > -device pci-assign,host=03:10.0 \ > -device pci-assign,host=03:10.2 > Login vm0 and them bind VF devices to igb_uio driver. > ./tools/dpdk_nic_bind.py --bind=igb_uio 00:04.0 00:05.0 > Bind PF to vfio-pci and start testpmd in host > testpmd -c f -n 3 -- -i > Config to rxonly mode and enable verbose output > testpmd> set fwd rxonly > testpmd> set verbose 1 > testpmd> start > Start testpmd in guest, configured to mac forward mode > testpmd -c 0x3 -n 1 -- -i --txqflags=0x0 > testpmd> set fwd mac > testpmd> start > > - Case: E-tag tunnel filter > Description: check that E-tag tunnel filter can work as expected > Command / instruction: > Enable E-tag l2 tunnel support means enabling ability of parsing E- > tag > packet. This ability should be enabled before we enable filtering, > forwarding, offloading for this specific type of tunnel > host testpmd> port config 0 l2-tunnel E-tag enable > Send 802.1BR packet to PF and VFs, check packet normally received > > - Case: E-tag filter and forwarding > Description: check that E-tag forwarding work as expected > Command / instruction: > Enable E-tag packet forwarding and enable E-tag 1000 packet forward > to VF0 > testpmd> E-tag set forwarding on port 0 > testpmd> E-tag set filter add e-tag-id 1000 dst-pool 0 port 0 > Send E-tag packet with broadcast mac and check packet only received > on VF0 > > Set E-tag with ID 1000 forwarding to VF1 > testpmd> E-tag set filter add e-tag-id 1000 dst-pool 1 port 0 > Send 802.1BR packet with broadcast mac and check packet only received > on VF1 > > Set E-tag with ID 1000 PF0 > testpmd> E-tag set filter add e-tag-id 1000 dst-pool 2 port 0 > Send 802.1BR packet with broadcast mac and check packet only received > on PF > > Remove E-tag > testpmd> E-tag set filter del e-tag-id 1000 port 0 > Send 802.1BR packet with broadcast mac and check packet not received > > - Case: E-tag insertion > Description: check that E-tag insertion feature can work as expected > Command / instruction: > Enable E-tag insertion in VF0 > testpmd> E-tag set insertion on port-tag-id 1000 port 0 vf 0 > Send normal packet to VF1 and check forwarded packet contain E-tag > Remove E-tag insertion in VF0 > testpmd> E-tag set insertion off port 0 vf 0 > Send normal packet to VF1 and check forwarded packet not include E- > tag > > - Case: E-tag strip > Description: check that E-tag strip feature can work as expected > Enable E-tag strip on PF > testpmd> E-tag set filter add e-tag-id 1000 dst-pool 0 port 0 > testpmd> E-tag set stripping on port 0 > Send 802.1BR packet to VF and check forwarded packet without E-tag > Disable E-tag strip on PF > testpmd> E-tag set stripping off port 0 > Send 802.1BR packet and check forwarded packet with E-tag. > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wenzhuo Lu > > Sent: Friday, March 04, 2016 10:35 AM > > To: dev at dpdk.org > > Subject: [dpdk-dev] [PATCH v7 0/5] Support VxLAN & NVGRE checksum off- > > load on X550 > > > > This patch set add the VxLAN & NVGRE checksum off-load support. > > Both RX and TX checksum off-lo
[dpdk-dev] [PATCH v4 0/7] support E-tag offloading and forwarding on Intel X550 NIC
Tested-by: Yong Liu - Tested Branch: dpdk-next-net - Tested Commit: 5fa83b5398e26af7537b09605432fcb3d0cc1d41 - OS: Fedora21 3.17.4-301.fc21.x86_64 - GCC: gcc version 4.9.2 20150212 - CPU: Intel(R) Xeon(R) CPU D-1540 @ 2.00GHz - NIC: Intel Corporation Device Sageville [8086:15ad] - Default x86_64-native-linuxapp-gcc configuration - Total 4 cases, 4 passed, 0 failed - Prerequisites command / instruction: Bound PF device to igb_uio ./tools/dpdk_nic_bind.py --bind=igb_uio 03:00.0 Create 2VF devices from PF device. echo 2 > /sys/bus/pci/devices/\:03\:00.0/max_vfs Detach VFs from the host, bind them to pci-stub driver virsh # nodedev-dettach pci__03_10_0 virsh # nodedev-dettach pci__03_10_2 Passthrough VF 03:10.0 & 03:10.2 to vm0 and start vm0 /usr/bin/qemu-system-x86_64 -name vm0 -enable-kvm \ -cpu host -smp 4 -m 2048 -drive file=/home/image/fedora20.img -vnc :1 \ -device pci-assign,host=03:10.0 \ -device pci-assign,host=03:10.2 Login vm0 and them bind VF devices to igb_uio driver. ./tools/dpdk_nic_bind.py --bind=igb_uio 00:04.0 00:05.0 Bind PF to vfio-pci and start testpmd in host testpmd -c f -n 3 -- -i Config to rxonly mode and enable verbose output testpmd> set fwd rxonly testpmd> set verbose 1 testpmd> start Start testpmd in guest, configured to mac forward mode testpmd -c 0x3 -n 1 -- -i --txqflags=0x0 testpmd> set fwd mac testpmd> start - Case: E-tag tunnel filter Description: check that E-tag tunnel filter can work as expected Command / instruction: Enable E-tag l2 tunnel support means enabling ability of parsing E-tag packet. This ability should be enabled before we enable filtering, forwarding, offloading for this specific type of tunnel host testpmd> port config 0 l2-tunnel E-tag enable Send 802.1BR packet to PF and VFs, check packet normally received - Case: E-tag filter and forwarding Description: check that E-tag forwarding work as expected Command / instruction: Enable E-tag packet forwarding and enable E-tag 1000 packet forward to VF0 testpmd> E-tag set forwarding on port 0 testpmd> E-tag set filter add e-tag-id 1000 dst-pool 0 port 0 Send E-tag packet with broadcast mac and check packet only received on VF0 Set E-tag with ID 1000 forwarding to VF1 testpmd> E-tag set filter add e-tag-id 1000 dst-pool 1 port 0 Send 802.1BR packet with broadcast mac and check packet only received on VF1 Set E-tag with ID 1000 PF0 testpmd> E-tag set filter add e-tag-id 1000 dst-pool 2 port 0 Send 802.1BR packet with broadcast mac and check packet only received on PF Remove E-tag testpmd> E-tag set filter del e-tag-id 1000 port 0 Send 802.1BR packet with broadcast mac and check packet not received - Case: E-tag insertion Description: check that E-tag insertion feature can work as expected Command / instruction: Enable E-tag insertion in VF0 testpmd> E-tag set insertion on port-tag-id 1000 port 0 vf 0 Send normal packet to VF1 and check forwarded packet contain E-tag Remove E-tag insertion in VF0 testpmd> E-tag set insertion off port 0 vf 0 Send normal packet to VF1 and check forwarded packet not include E-tag - Case: E-tag strip Description: check that E-tag strip feature can work as expected Enable E-tag strip on PF testpmd> E-tag set filter add e-tag-id 1000 dst-pool 0 port 0 testpmd> E-tag set stripping on port 0 Send 802.1BR packet to VF and check forwarded packet without E-tag Disable E-tag strip on PF testpmd> E-tag set stripping off port 0 Send 802.1BR packet and check forwarded packet with E-tag. > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wenzhuo Lu > Sent: Thursday, February 18, 2016 10:46 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v4 0/7] support E-tag offloading and > forwarding on Intel X550 NIC > > This patch set adds the support of E-tag offloading and forwarding > on X550. > The offloading means E-tag can be inserted and stripped by HW. > And E-tag packets can be recognized and forwarded to specific pools > based on GRP and E-CID_base in E-tag. > > E-tag is defined in IEEE802.1br. Please reference > http://www.ieee802.org/1/pages/802.1br.html. > > V2: > * Add the introduction for E-tag. > > V3: > * Add the hlep info for the new CLIs. > * Update the doc for testpmd. > * Update the E-tag insertion setting. Should insert different tunnel > id for every VF, not a common one for all. > > V4: > * Fix strippig is not working issue. > * Update the filter adding function. Make sure there's only one filter > entry for one tunnel entry. > * Update the release note to add some info about how to use this feature. > > Wenzhuo Lu (7): > ixgbe: select pool by MAC when using double VLAN > lib/librte_ether: support l2 tunnel config > ixgbe: support l2 tunnel config > app/testpmd: add
[dpdk-dev] [PATCH v7 0/5] Support VxLAN & NVGRE checksum off-load on X550
Tested-by: Yong Liu - Tested Branch: dpdk-next-net - Tested Commit: 5fa83b5398e26af7537b09605432fcb3d0cc1d41 - OS: Fedora21 3.17.4-301.fc21.x86_64 - GCC: gcc version 4.9.2 20150212 - CPU: Intel(R) Xeon(R) CPU D-1540 @ 2.00GHz - NIC: Intel Corporation Device Sageville [8086:15ad] - Default x86_64-native-linuxapp-gcc configuration - Total 4 cases, 4 passed, 0 failed - Prerequisites command / instruction: Bound PF device to igb_uio ./tools/dpdk_nic_bind.py --bind=igb_uio 03:00.0 Create 2VF devices from PF device. echo 2 > /sys/bus/pci/devices/\:03\:00.0/max_vfs Detach VFs from the host, bind them to pci-stub driver virsh # nodedev-dettach pci__03_10_0 virsh # nodedev-dettach pci__03_10_2 Passthrough VF 03:10.0 & 03:10.2 to vm0 and start vm0 /usr/bin/qemu-system-x86_64 -name vm0 -enable-kvm \ -cpu host -smp 4 -m 2048 -drive file=/home/image/fedora20.img -vnc :1 \ -device pci-assign,host=03:10.0 \ -device pci-assign,host=03:10.2 Login vm0 and them bind VF devices to igb_uio driver. ./tools/dpdk_nic_bind.py --bind=igb_uio 00:04.0 00:05.0 Bind PF to vfio-pci and start testpmd in host testpmd -c f -n 3 -- -i Config to rxonly mode and enable verbose output testpmd> set fwd rxonly testpmd> set verbose 1 testpmd> start Start testpmd in guest, configured to mac forward mode testpmd -c 0x3 -n 1 -- -i --txqflags=0x0 testpmd> set fwd mac testpmd> start - Case: E-tag tunnel filter Description: check that E-tag tunnel filter can work as expected Command / instruction: Enable E-tag l2 tunnel support means enabling ability of parsing E-tag packet. This ability should be enabled before we enable filtering, forwarding, offloading for this specific type of tunnel host testpmd> port config 0 l2-tunnel E-tag enable Send 802.1BR packet to PF and VFs, check packet normally received - Case: E-tag filter and forwarding Description: check that E-tag forwarding work as expected Command / instruction: Enable E-tag packet forwarding and enable E-tag 1000 packet forward to VF0 testpmd> E-tag set forwarding on port 0 testpmd> E-tag set filter add e-tag-id 1000 dst-pool 0 port 0 Send E-tag packet with broadcast mac and check packet only received on VF0 Set E-tag with ID 1000 forwarding to VF1 testpmd> E-tag set filter add e-tag-id 1000 dst-pool 1 port 0 Send 802.1BR packet with broadcast mac and check packet only received on VF1 Set E-tag with ID 1000 PF0 testpmd> E-tag set filter add e-tag-id 1000 dst-pool 2 port 0 Send 802.1BR packet with broadcast mac and check packet only received on PF Remove E-tag testpmd> E-tag set filter del e-tag-id 1000 port 0 Send 802.1BR packet with broadcast mac and check packet not received - Case: E-tag insertion Description: check that E-tag insertion feature can work as expected Command / instruction: Enable E-tag insertion in VF0 testpmd> E-tag set insertion on port-tag-id 1000 port 0 vf 0 Send normal packet to VF1 and check forwarded packet contain E-tag Remove E-tag insertion in VF0 testpmd> E-tag set insertion off port 0 vf 0 Send normal packet to VF1 and check forwarded packet not include E-tag - Case: E-tag strip Description: check that E-tag strip feature can work as expected Enable E-tag strip on PF testpmd> E-tag set filter add e-tag-id 1000 dst-pool 0 port 0 testpmd> E-tag set stripping on port 0 Send 802.1BR packet to VF and check forwarded packet without E-tag Disable E-tag strip on PF testpmd> E-tag set stripping off port 0 Send 802.1BR packet and check forwarded packet with E-tag. > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wenzhuo Lu > Sent: Friday, March 04, 2016 10:35 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v7 0/5] Support VxLAN & NVGRE checksum off- > load on X550 > > This patch set add the VxLAN & NVGRE checksum off-load support. > Both RX and TX checksum off-load can be used for VxLAN & NVGRE. > And the VxLAN port can be set, it's implemented in this patch > set either. > > v2: > - Update release note. > > v3: > - Update RX/TX offload capability. > - Reuse PKT_RX_EIP_CKSUM_BAD but not add a new one. > - Correct the tunnel len for TX, and remove the useless out_l2_len. > - Don't set the tunnel type for TX, and remove the unused ol_flag_nvgre. > > v4: > - Fix the issue that not setting the MAC length correctly. > > v5: > - Change the behavior of VxLAN port add/del to make it align with i40e. > > v6: > - Fix x86_64-native-linuxapp-gcc-shared compile error. > > v7: > - Change the return value from hardcode to macro. > > Wenzhuo Lu (5): > lib/librte_ether: change function name of tunnel port config > i40e: rename the tunnel port config functions > ixgbe: support UDP tunnel port config > ixgbe: support VxLAN & NVGRE RX checksum off-load > ixgbe: support
[dpdk-dev] [PATCH v6 0/6] interrupt mode for fm10k
Thanks Thomas, found it. > -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Thursday, March 03, 2016 5:11 PM > To: Liu, Yong > Cc: He, Shaopeng; dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v6 0/6] interrupt mode for fm10k > > 2016-03-03 08:36, Liu, Yong: > > Hi Thomas, > > In patchwork website, this patch set seem that has been applied. > > http://dpdk.org/dev/patchwork/patch/10381/ > > > > But I can't find it neither in dpdk repo nor in dpdk-next-net repo. > > Could you check with that? > > It's here: > http://dpdk.org/browse/next/dpdk-next-net/log/?h=rel_16_04=50 >
[dpdk-dev] [PATCH v6 0/6] interrupt mode for fm10k
Hi Thomas, In patchwork website, this patch set seem that has been applied. http://dpdk.org/dev/patchwork/patch/10381/ But I can't find it neither in dpdk repo nor in dpdk-next-net repo. Could you check with that? > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Shaopeng He > Sent: Friday, February 05, 2016 12:58 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v6 0/6] interrupt mode for fm10k > > This patch series adds interrupt mode support for fm10k, > contains four major parts: > > 1. implement rx_descriptor_done function in fm10k > 2. add rx interrupt support in fm10k PF and VF > 3. make sure default VID available in dev_init in fm10k > 4. fix a memory leak for non-ip packet in l3fwd-power, >which happens mostly when testing fm10k interrupt mode. > > v6 changes: > - add fixes line > - relocate version change message in individual patch > after the --- separator > > v5 changes: > - remove one unnecessary NULL check for rte_free > - fix a wrong error message > - add more clean up when memory allocation fails > - split line over 80 characters to 2 lines > - update interrupt mode limitation in fm10k.rst > > v4 changes: > - rebase to latest code > - update release 2.3 note in corresponding patches > > v3 changes: > - rebase to latest code > - macro renaming according to the EAL change > > v2 changes: > - reword some comments and commit messages > - split one big patch into three smaller ones > > Shaopeng He (6): > fm10k: implement rx_descriptor_done function > fm10k: setup rx queue interrupts for PF and VF > fm10k: remove rx queue interrupts when dev stops > fm10k: add rx queue interrupt en/dis functions > fm10k: make sure default VID available in dev_init > l3fwd-power: fix a memory leak for non-ip packet > > doc/guides/nics/fm10k.rst| 7 ++ > doc/guides/rel_notes/release_2_3.rst | 8 ++ > drivers/net/fm10k/fm10k.h| 6 ++ > drivers/net/fm10k/fm10k_ethdev.c | 174 > --- > drivers/net/fm10k/fm10k_rxtx.c | 25 + > examples/l3fwd-power/main.c | 3 +- > 6 files changed, 211 insertions(+), 12 deletions(-) > > -- > 1.9.3
[dpdk-dev] [PATCH v7 0/4] Add tunnel filter support for IP in GRE on i40e
Tested-by: Yong Liu - Tested Branch: dpdk-next-net - Tested Commit: 5fa83b5398e26af7537b09605432fcb3d0cc1d41 - OS: Fedora20 3.11.10-301.fc20.x86_64 - GCC: gcc version 4.8.3 20140911 - CPU: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz - NIC: Intel Corporation Device RedrockCanyou [8086:15a4] - Default x86_64-native-linuxapp-gcc configuration - Prerequisites: - Total 4 cases, 4 passed, 0 failed - Prerequisites command / instruction: Intel(r) X710 (Fortville) NIC plugged in - Case: GRE ipv4 packet detect Description: check IPGRE packet can be normally detected Command / instruction: Start testpmd and enable rxonly forwarding mode testpmd -c -n 4 -- -i --txqflags=0x0 testpmd> set fwd rxonly testpmd> set verbose 1 testpmd> start Send ipv4+GRE+ipv4 packet and check testpmd log match packet type - Case: GRE ipv6 packet detect Description: check IPGRE packet can be normally detected Command / instruction: Start testpmd and enable rxonly forwarding mode testpmd -c -n 4 -- -i --txqflags=0x0 testpmd> set fwd rxonly testpmd> set verbose 1 testpmd> start Send ipv6+GRE+ipv4 packet and check testpmd log match packet type Send ipv6+GRE+ipv6 packet and check testpmd log match packet type - Case: GRE packet filter Description: check IPGRE cloud filter work as expected Command / instruction: Start testpmd with multi queues testpmd -c ff -n 3 -- -i --rxq=4 --txq=4 --txqflags=0x0 testpmd> set fwd rxonly testpmd> set nbcore 4 testpmd> set verbose 1 testpmd> start Add GRE filter that forward inner ip address 0.0.0.0 packets to queue 3 testpmd> tunnel_filter add 0 XX:XX:XX:XX:XX:XX YY:YY:YY:YY:YY:YY \ 0.0.0.0 1 ipingre iip 0 3 Send packet inner ip address matched and check packet recevied by queue 3. Remove tunnel filter and check same packet recevied by queue 0 testpmd> tunnel_filter rm 0 XX:XX:XX:XX:XX:XX YY:YY:YY:YY:YY:YY \ 0.0.0.0 1 ipingre iip 0 3 Add GRE filter that forward outer ip address 0.0.0.0 to queue 3 testpmd> tunnel_filter add 0 XX:XX:XX:XX:XX:XX YY:YY:YY:YY:YY:YY \ 0.0.0.0 1 ipingre oip 0 3 Send packet outer ip address matched and check packet recevied by queue 3. Remove tunnel filter and check same packet recevied by queue 0. testpmd> tunnel_filter rm 0 XX:XX:XX:XX:XX:XX YY:YY:YY:YY:YY:YY \ 0.0.0.0 1 ipingre iip 0 3 - Case: GRE packet chksum offload Description: check IPGRE packet's checksum can be offloaded Command / instruction: Start testpmd with hardware checksum offload enabled:: testpmd -c ff -n 3 -- -i --txqflags=0x0 --enable-rx-cksum testpmd> set verbose 1 testpmd> set fwd csum testpmd> csum set ip hw 0 testpmd> csum set udp hw 0 testpmd> csum set sctp hw 0 testpmd> csum set outer-ip hw 0 testpmd> csum set tcp hw 0 testpmd> csum parse_tunnel on 0 testpmd> start Send packet with wrong outer IP checksum and check forwarded packet IP checksum is correct. Send packet with wrong inner IP checksum and check forwarded packet IP checksum is correct. Send packet with wrong inner TCP checksum and check forwarded packet TCP checksum is correct. Send packet with wrong inner UDP checksum and check forwarded packet UDP checksum is correct. Send packet with wrong inner SCTP checksum and check forwarded packet SCTP checksum is correct. > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Xutao Sun > Sent: Tuesday, March 01, 2016 4:41 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v7 0/4] Add tunnel filter support for IP in > GRE on i40e > > This patch set adds tunnel filter support for IP in GRE on i40e. > > v2 changes: > Fix the byte order problem. > > v3 changes: > Remove the deprecation notice and update the release notes. > > v4 changes: > Modify the mistakes in cmdline.c in the old patch. > > v5 changes: > Fix type errors and update the testpmd documentation. > > v6 changes: > Use internal variables to convert byte order. > > v7 changes: > Modify the mistakes of code style. > > Xutao Sun (4): > lib/ether: optimize the'rte_eth_tunnel_filter_conf' structure > lib/ether: add IP in GRE type > driver/i40e: implement tunnel filter for IP in GRE > app/test-pmd: test tunnel filter for IP in GRE > > app/test-pmd/cmdline.c | 38 --- > - > doc/guides/rel_notes/deprecation.rst| 5 > doc/guides/rel_notes/release_16_04.rst | 2 ++ > doc/guides/testpmd_app_ug/testpmd_funcs.rst | 35 -- > drivers/net/i40e/i40e_ethdev.c | 45 +++ > -- > lib/librte_ether/rte_eth_ctrl.h | 5 ++-- > 6 files changed, 94 insertions(+), 36 deletions(-) > > -- > 1.9.3
[dpdk-dev] [PATCH 1/2 v2] fm10k: Add Atwood Channel Support
Tested-by: Marvin Liu > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Michael Qiu > Sent: Thursday, February 04, 2016 4:36 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH 1/2 v2] fm10k: Add Atwood Channel Support > > Atwood Channel is intel 25G NIC, and this patch add the support > in DPDK. > > Signed-off-by: Michael Qiu > Acked-by: John McNamara > --- > drivers/net/fm10k/base/fm10k_osdep.h| 4 > lib/librte_eal/common/include/rte_pci_dev_ids.h | 2 ++ > 2 files changed, 6 insertions(+) > > diff --git a/drivers/net/fm10k/base/fm10k_osdep.h > b/drivers/net/fm10k/base/fm10k_osdep.h > index 6852ef0..9cb46ff 100644 > --- a/drivers/net/fm10k/base/fm10k_osdep.h > +++ b/drivers/net/fm10k/base/fm10k_osdep.h > @@ -48,6 +48,10 @@ POSSIBILITY OF SUCH DAMAGE. > #define BOULDER_RAPIDS_HW > #endif > > +#ifndef ATWOOD_CHANNEL_HW > +#define ATWOOD_CHANNEL_HW > +#endif > + > #define STATIC static > #define DEBUGFUNC(F)DEBUGOUT(F "\n"); > #define DEBUGOUT(S, args...)PMD_DRV_LOG_RAW(DEBUG, S, ##args) > diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h > b/lib/librte_eal/common/include/rte_pci_dev_ids.h > index e31b934..cb0d177 100644 > --- a/lib/librte_eal/common/include/rte_pci_dev_ids.h > +++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h > @@ -530,9 +530,11 @@ RTE_PCI_DEV_ID_DECL_I40E(PCI_VENDOR_ID_INTEL, > I40E_DEV_ID_10G_BASE_T_X722) > > #define FM10K_DEV_ID_PF 0x15A4 > #define FM10K_DEV_ID_SDI_FM10420_QDA2 0x15D0 > +#define FM10K_DEV_ID_SDI_FM10420_DA2 0x15D5 > > RTE_PCI_DEV_ID_DECL_FM10K(PCI_VENDOR_ID_INTEL, FM10K_DEV_ID_PF) > RTE_PCI_DEV_ID_DECL_FM10K(PCI_VENDOR_ID_INTEL, > FM10K_DEV_ID_SDI_FM10420_QDA2) > +RTE_PCI_DEV_ID_DECL_FM10K(PCI_VENDOR_ID_INTEL, > FM10K_DEV_ID_SDI_FM10420_DA2) > > /** Virtual IGB devices from e1000_hw.h > **/ > > -- > 1.9.3
[dpdk-dev] [PATCH 0/3] fm10k: enable FTAG based forwarding
Tested-by: Yong Liu - Tested Commit: a38e5ec15e3fe615b94f3cc5edca5974dab325ab - OS: Fedora20 3.11.10-301.fc20.x86_64 - GCC: gcc version 4.8.3 20140911 - CPU: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz - NIC: Intel Corporation Device RedrockCanyou [8086:15a4] - Default x86_64-native-linuxapp-gcc configuration - Prerequisites: - Total 1 cases, 1 passed, 0 failed - Prerequisites command / instruction: Apply FM10k ftag unit test patch. Turn on CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD setting. export Port0 and Port1's GLORT ID to environment variables export PORT1_GLORT=0x4200 export PORT0_GLORT=0x4000 - Case: Ftag forwarding unit test Description: check fm10k nic can forwarding packets based on FTAG Command / instruction: Start test application and run fm10k_ftag_autotest. ./x86_64-native-linuxapp-gcc/app/test -c f -n 4 RTE>>fm10k_ftag_autotest Send packet to Port0 and verify packet forwarded to Port1. Receive 1 packets on port 0 test for FTAG RX passed Send out 1 packets with FTAG on port 0 Receive 1 packets on port 1 test for FTAG TX passed Test OK > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wang Xiao W > Sent: Monday, January 25, 2016 4:07 PM > To: Chen, Jing D > Cc: dev at dpdk.org > Subject: [dpdk-dev] [PATCH 0/3] fm10k: enable FTAG based forwarding > > This patch set adds support for FTAG based forwarding in fm10k. This > feature > is a particularity of fm10k, so I add an introduction for it in fm10k.rst. > A FTAG unit test is kept internally for feature testing, it's not included > in the patch set due to the particularity. > > Wang Xiao W (3): > fm10k: enable FTAG based forwarding > doc: add introduction for fm10k FTAG based forwarding > doc: update release note for fm10k FTAG support > > config/common_bsdapp | 1 + > config/common_linuxapp | 1 + > doc/guides/nics/fm10k.rst| 15 ++- > doc/guides/rel_notes/release_2_3.rst | 1 + > drivers/net/fm10k/fm10k_ethdev.c | 8 > drivers/net/fm10k/fm10k_rxtx.c | 17 + > drivers/net/fm10k/fm10k_rxtx_vec.c | 9 + > 7 files changed, 51 insertions(+), 1 deletion(-) > > -- > 1.9.3
[dpdk-dev] [PATCH v9 0/3] User-space ethtool sample application
Tested-by: Yong Liu - Tested Commit: 4522eca1352d8ed7c0823e328e2a68c2ba6459ab - OS: Fedora20 3.11.10-301.fc20.x86_64 - GCC: gcc version 4.8.3 20140911 - CPU: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz - NIC: Intel Corporation Device 82599ES [8086:10fb] - Default x86_64-native-linuxapp-gcc configuration - Prerequisites: - Total 9 cases, 9 passed, 0 failed - Prerequisites command / instruction: Build userspace ethtool sample make -C examples/ethtool - Case: ethtool_dump_driver_info Description: check userspace sample can dump driver information and port statistics Command / instruction: Start userspace ethtool sample with two ports bound ethtool -c f -n 4 Wait for the sample start up and shown prompt EthApp> Use "drvinfo" command to dump driver information and check it's correct. EthApp> drvinfo Port 0 driver: rte_ixgbe_pmd (ver: RTE 2.2.0-rc1) Port 1 driver: rte_ixgbe_pmd (ver: RTE 2.2.0-rc1) Change tester port link down and check link status can be detected. EthApp> link Port 0: Down Port 1: Down Send packets to port0 and port1 and check port statistic correct. EthApp> Port 0 stats In: 1 (64 bytes) Out: 1 (64 bytes) Err: 0 - Case: ethtool_vlan Description: check userspace sample can configure port vlan setting Command / instruction: Enable port vlan filer in main file cfg_port.rxmode.hw_vlan_filter=1 Rebuild sample and start userspace ethtool sample with two ports bound ethtool -c f -n 4 Add random vlan on port and send packet with same vlan EthApp> vlan 0 add 2997 Check packet normally forwarded and port statistic correct EthApp> Port 0 stats In: 1 (64 bytes) Out: 1 (64 bytes) Err: 0 Send packet with wrong vlan and check packet not forwarded EthApp> Port 0 stats In: 1 (64 bytes) Out: 1 (64 bytes) Err: 0 Remove the random vlan on port and send packet with same vlan EthApp> vlan 0 remove 2997 Check packet not forwarded EthApp> Port 0 stats In: 1 (64 bytes) Out: 1 (64 bytes) Err: 0 - Case: ethtool_mac_address Description: check userspace sample can configure port mac address Command / instruction: Start userspace ethtool sample with two ports bound ethtool -c f -n 4 Add random vlan on port and send packet with same vlan EthApp> vlan 0 add 2997 Changed port mac address and "macaddr" command can dump new mac EthApp> macaddr 0 00:10:00:00:00:00 EthApp> macaddr 0 Port 0 MAC Address: 00:10:00:00:00:00 Send packet and check forwarded packet source mac changed - Case: ethtool_port_config Description: check userspace sample can start/stop port Command / instruction: Start userspace ethtool sample with two ports bound ethtool -c f -n 4 Stop port and check forwarding cannot work EthApp> stop 0 Restart port and check packet can be normally forwarded - Case: ethtool_retrieve_eeprom Description: check userspace sample can retrieve port eerprom file Command / instruction: Start userspace ethtool sample with two ports bound ethtool -c f -n 4 Retrieve port eeprom file and saved for later compare EthApp> eeprom 0 eeprom_0.bin Bound port back to default kernel driver and dump eeprom by ethtool ethtool --eeprom-dump p1p3 raw on > ethtool_eeprom_0.bin Check userspace ethool and linux ethtool dumped file md5 are the same md5sum eeprom_0.bin md5sum ethtool_eeprom_0.bin - Case: ethtool_retrieve_register Description: check userspace sample can retrieve port register file Command / instruction: Start userspace ethtool sample with two ports bound ethtool -c f -n 4 Retrieve port register file EthApp> regs 0 regs_0.bin User linux ethtool dump this file and check information correct ethtool -d p1p3 raw off file regs_0.bin - Case: ethtool_ring_parameter Description: check userspace sample can configure pending entries of Rx/Tx ring Command / instruction: Start userspace ethtool sample with two ports bound ethtool -c f -n 4 Use command "ringparam" dump port pending entries EthApp> ringparam 0 Port 0 ring parameters Rx Pending: 128 (4096 max) Tx Pending: 256 (4096 max) Changed pending entries of Rx/Tx ring to max value EthApp> ringparam 0 4096 4096 Check that packet can be normally forwarded EthApp> portstats 0 Port 0 stats In: 1 (64 bytes) Out: 1 (64 bytes) Err: 0 - Case: ethtool_rx_pause Description: check userspace sample can configure port rx pause setting Command / instruction: Start userspace ethtool sample with two ports bound ethtool -c f -n 4 Enable port 0 handle rx pause frame EthApp> pause 0 rx Based on 50% line rate, calculate how many
[dpdk-dev] |ERROR| pw 9018 ethdev: add a missing sanity check for nb_tx_desc during txq setup
Yuanhan, First three reports is for patch sets in the same email thread. I think patchwork scanned the mail and strip all of them out. So the patch names did not change any more. For the failure one, it caused by validation environment. We're trying to find the root cause. > -Original Message- > From: Yuanhan Liu [mailto:yuanhan.liu at linux.intel.com] > Sent: Monday, November 23, 2015 3:42 PM > To: Liu, Yong > Cc: dev at dpdk.org; Felix Marti; Kumar Sanghvi; Nirranjan Kirubaharan > Subject: Re: [dpdk-dev] |ERROR| pw 9018 ethdev: add a missing sanity check > for nb_tx_desc during txq setup > > On Mon, Nov 23, 2015 at 07:36:38AM +, Liu, Yong wrote: > > Yuanhan, > > The validation system is based on dpkdk.org patchwork, all patch sets > recorded by patchwork should be validated. > > Can you supply the patch Id or just patch name? Thus, we can check out > what happened. > > Sure, here you go: > > 589 T Nov 18 sys_stv at intel.c ( 19) |SUCCESS| pw 8988 vhost: avoid > buffer overflow in update_secure_len > 733 r T Nov 17 sys_stv at intel.c ( 19) |SUCCESS| pw 8965 vhost: avoid > buffer overflow in update_secure_len > 863 T Nov 17 sys_stv at intel.c ( 19) |SUCCESS| pw 8960 vhost: avoid > buffer overflow in update_secure_len > 1230 r T Nov 11 sys_stv at intel.c ( 87) |ERROR| pw 8870 vhost: reset > device properly > > --yliu > > > > > > -Original Message- > > > From: Yuanhan Liu [mailto:yuanhan.liu at linux.intel.com] > > > Sent: Monday, November 23, 2015 3:27 PM > > > To: Liu, Yong > > > Cc: dev at dpdk.org; Felix Marti; Kumar Sanghvi; Nirranjan Kirubaharan > > > Subject: Re: [dpdk-dev] |ERROR| pw 9018 ethdev: add a missing sanity > check > > > for nb_tx_desc during txq setup > > > > > > On Mon, Nov 23, 2015 at 07:06:45AM +, Liu, Yong wrote: > > > > Hi Rahul, > > > > Your patch passed "checksum_offload_with_vlan" after rerun this case. > > > Please ignore this error report. > > > > > > I got a same report few weeks ago. And my patch was very vhost-user > > > specific, touching nothing else. Even though, I sent a report for > > > double check, and got no reply. > > > > > > I also got several "report" while replying to the same patch (not from > > > me). I sent another report, yet no reply received. > > > > > > > > > --yliu > > > > > > > > > > > > -Original Message- > > > > > From: Rahul Lakkireddy [mailto:rahul.lakkireddy at chelsio.com] > > > > > Sent: Friday, November 20, 2015 9:37 PM > > > > > To: dev at dpdk.org > > > > > Cc: Liu, Yong; Kumar Sanghvi; Nirranjan Kirubaharan; Felix Marti > > > > > Subject: Re: |ERROR| pw 9018 ethdev: add a missing sanity check > for > > > > > nb_tx_desc during txq setup > > > > > > > > > > Hi all, > > > > > > > > > > I received this auto email regarding 'Unexpected Packets Drop' and > > > > > it is referring to my patch. I don't think I've changed anything > that > > > > > could cause this. Kindly advise. > > > > > > > > > > Thanks, > > > > > Rahul > > > > > > > > > > On Friday, November 11/20/15, 2015 at 03:14:51 -0800, > > > sys_stv at intel.com > > > > > wrote: > > > > > > Test-Label: Intel Niantic on Fedora > > > > > > Test-Status: ERROR > > > > > > Patchwork: http://www.dpdk.org/dev/patchwork/patch/9018/ > > > > > > > > > > > > DPDK git baseline: e64833f2273ac67becbca10d9f2f1598872dc99e > > > > > > Patchwork ID: 9018 > > > > > > http://www.dpdk.org/dev/patchwork/patch/9018/ > > > > > > Submitter: Rahul Lakkireddy > > > > > > Date: Fri, 20 Nov 2015 15:56:37 +0530 > > > > > > > > > > > > Source Compilation: > > > > > > OS: fedora > > > > > > Nic: niantic > > > > > > i686-native-linuxapp-gcc: compile pass > > > > > > x86_64-native-linuxapp-gcc: compile pass > > > > > > > > > > > > DTS validation: > > > > > > OS: fedora > > > > > > Nic: Niantic > > > > > > TestType: auto > > > > > > GCC: 4 > > > > > > x8
[dpdk-dev] |ERROR| pw 9018 ethdev: add a missing sanity check for nb_tx_desc during txq setup
Yuanhan, The validation system is based on dpkdk.org patchwork, all patch sets recorded by patchwork should be validated. Can you supply the patch Id or just patch name? Thus, we can check out what happened. > -Original Message- > From: Yuanhan Liu [mailto:yuanhan.liu at linux.intel.com] > Sent: Monday, November 23, 2015 3:27 PM > To: Liu, Yong > Cc: dev at dpdk.org; Felix Marti; Kumar Sanghvi; Nirranjan Kirubaharan > Subject: Re: [dpdk-dev] |ERROR| pw 9018 ethdev: add a missing sanity check > for nb_tx_desc during txq setup > > On Mon, Nov 23, 2015 at 07:06:45AM +, Liu, Yong wrote: > > Hi Rahul, > > Your patch passed "checksum_offload_with_vlan" after rerun this case. > Please ignore this error report. > > I got a same report few weeks ago. And my patch was very vhost-user > specific, touching nothing else. Even though, I sent a report for > double check, and got no reply. > > I also got several "report" while replying to the same patch (not from > me). I sent another report, yet no reply received. > > > --yliu > > > > > > -Original Message- > > > From: Rahul Lakkireddy [mailto:rahul.lakkireddy at chelsio.com] > > > Sent: Friday, November 20, 2015 9:37 PM > > > To: dev at dpdk.org > > > Cc: Liu, Yong; Kumar Sanghvi; Nirranjan Kirubaharan; Felix Marti > > > Subject: Re: |ERROR| pw 9018 ethdev: add a missing sanity check for > > > nb_tx_desc during txq setup > > > > > > Hi all, > > > > > > I received this auto email regarding 'Unexpected Packets Drop' and > > > it is referring to my patch. I don't think I've changed anything that > > > could cause this. Kindly advise. > > > > > > Thanks, > > > Rahul > > > > > > On Friday, November 11/20/15, 2015 at 03:14:51 -0800, > sys_stv at intel.com > > > wrote: > > > > Test-Label: Intel Niantic on Fedora > > > > Test-Status: ERROR > > > > Patchwork: http://www.dpdk.org/dev/patchwork/patch/9018/ > > > > > > > > DPDK git baseline: e64833f2273ac67becbca10d9f2f1598872dc99e > > > > Patchwork ID: 9018 > > > > http://www.dpdk.org/dev/patchwork/patch/9018/ > > > > Submitter: Rahul Lakkireddy > > > > Date: Fri, 20 Nov 2015 15:56:37 +0530 > > > > > > > > Source Compilation: > > > > OS: fedora > > > > Nic: niantic > > > > i686-native-linuxapp-gcc: compile pass > > > > x86_64-native-linuxapp-gcc: compile pass > > > > > > > > DTS validation: > > > > OS: fedora > > > > Nic: Niantic > > > > TestType: auto > > > > GCC: 4 > > > > x86_64-native-linuxapp-gcc: total 79, passed 78, failed 1. > > > > Failed Case List: > > > > Target: x86_64-native-linuxapp-gcc > > > > OS: fedora > > > > Failed DTS case: > > > > checksum_offload_with_vlan: > > > > http://dpdk.org/browse/tools/dts/tree/test_plans/checksum_offload_test_pla > > > n.rst > > > > > > > > DTS Validation Error: > > > > > > > > == > > > == > > > > > > > > == > > > == > > > > TEST SUITE : TestChecksumOffload > > > > > > > > > > > > --- > > > > Begin: Test Casetest_checksum_offload_with_vlan > > > > -- > > > > FAILED 'Unexpected Packets Drop' > > > > -- > > > > [ SUITE_DUT_CMD] ./x86_64-native-linuxapp-gcc/app/testpmd -c 0x6 > -n 4 > > > -- -i --portmask=0x3 --disable-hw-vlan --enable-rx-cksum --crc-strip - > - > > > txqflags=0 > > > > [ SUITE_DUT_CMD] set verbose 1 > > > > [ SUITE_DUT_CMD] set fwd csum > > > > [ SUITE_DUT_CMD] csum set ip hw 0 > > > > [ SUITE_DUT_CMD] csum set udp hw 0 > > > > [ SUITE_DUT_CMD] csum set tcp hw 0 > > > > [ SUITE_DUT_CMD] csum set sctp hw 0 > > > > [ SUITE_DUT_CMD] csum set ip hw 1 > > > > [ SUITE_DUT_CMD] csum set udp hw 1 > > > > [ SUITE_DUT_CMD] csum set tcp hw 1 > > > > [ SUITE_DUT_C
[dpdk-dev] |ERROR| pw 9018 ethdev: add a missing sanity check for nb_tx_desc during txq setup
Hi Rahul,
Your patch passed "checksum_offload_with_vlan" after rerun this case. Please
ignore this error report.
> -Original Message-
> From: Rahul Lakkireddy [mailto:rahul.lakkireddy at chelsio.com]
> Sent: Friday, November 20, 2015 9:37 PM
> To: dev at dpdk.org
> Cc: Liu, Yong; Kumar Sanghvi; Nirranjan Kirubaharan; Felix Marti
> Subject: Re: |ERROR| pw 9018 ethdev: add a missing sanity check for
> nb_tx_desc during txq setup
>
> Hi all,
>
> I received this auto email regarding 'Unexpected Packets Drop' and
> it is referring to my patch. I don't think I've changed anything that
> could cause this. Kindly advise.
>
> Thanks,
> Rahul
>
> On Friday, November 11/20/15, 2015 at 03:14:51 -0800, sys_stv at intel.com
> wrote:
> > Test-Label: Intel Niantic on Fedora
> > Test-Status: ERROR
> > Patchwork: http://www.dpdk.org/dev/patchwork/patch/9018/
> >
> > DPDK git baseline: e64833f2273ac67becbca10d9f2f1598872dc99e
> > Patchwork ID: 9018
> > http://www.dpdk.org/dev/patchwork/patch/9018/
> > Submitter: Rahul Lakkireddy
> > Date: Fri, 20 Nov 2015 15:56:37 +0530
> >
> > Source Compilation:
> > OS: fedora
> > Nic: niantic
> > i686-native-linuxapp-gcc: compile pass
> > x86_64-native-linuxapp-gcc: compile pass
> >
> > DTS validation:
> > OS: fedora
> > Nic: Niantic
> > TestType: auto
> > GCC: 4
> > x86_64-native-linuxapp-gcc: total 79, passed 78, failed 1.
> > Failed Case List:
> > Target: x86_64-native-linuxapp-gcc
> > OS: fedora
> > Failed DTS case:
> > checksum_offload_with_vlan:
> http://dpdk.org/browse/tools/dts/tree/test_plans/checksum_offload_test_pla
> n.rst
> >
> > DTS Validation Error:
> >
> ==
> ==
> >
> ==
> ==
> > TEST SUITE : TestChecksumOffload
> >
> >
> ---
> > Begin: Test Casetest_checksum_offload_with_vlan
> > --
> > FAILED 'Unexpected Packets Drop'
> > --
> > [ SUITE_DUT_CMD] ./x86_64-native-linuxapp-gcc/app/testpmd -c 0x6 -n 4
> -- -i --portmask=0x3 --disable-hw-vlan --enable-rx-cksum --crc-strip --
> txqflags=0
> > [ SUITE_DUT_CMD] set verbose 1
> > [ SUITE_DUT_CMD] set fwd csum
> > [ SUITE_DUT_CMD] csum set ip hw 0
> > [ SUITE_DUT_CMD] csum set udp hw 0
> > [ SUITE_DUT_CMD] csum set tcp hw 0
> > [ SUITE_DUT_CMD] csum set sctp hw 0
> > [ SUITE_DUT_CMD] csum set ip hw 1
> > [ SUITE_DUT_CMD] csum set udp hw 1
> > [ SUITE_DUT_CMD] csum set tcp hw 1
> > [ SUITE_DUT_CMD] csum set sctp hw 1
> > [ SUITE_DUT_CMD] start
> > [SUITE_TESTER_CMD] scapy
> > [SUITE_TESTER_CMD] sys.path.append("./")
> > [SUITE_TESTER_CMD] from sctp import *
> > [SUITE_TESTER_CMD] p =
> Ether(dst="90:e2:ba:4a:54:81")/IPv6(src="::2")/UDP()/("X"*46)
> > [SUITE_TESTER_CMD] p.show2()
> > [SUITE_TESTER_CMD] p =
> Ether(dst="90:e2:ba:4a:54:81")/IP(src="127.0.0.2")/SCTP()/("X"*48)
> > [SUITE_TESTER_CMD] p.show2()
> > [SUITE_TESTER_CMD] p =
> Ether(dst="90:e2:ba:4a:54:81")/IPv6(src="::2")/TCP()/("X"*46)
> > [SUITE_TESTER_CMD] p.show2()
> > [SUITE_TESTER_CMD] p =
> Ether(dst="90:e2:ba:4a:54:81")/IP(src="127.0.0.2")/UDP()/("X"*46)
> > [SUITE_TESTER_CMD] p.show2()
> > [SUITE_TESTER_CMD] p =
> Ether(dst="90:e2:ba:4a:54:81")/IP(src="127.0.0.2")/TCP()/("X"*46)
> > [SUITE_TESTER_CMD] p.show2()
> > [SUITE_TESTER_CMD] exit()
> > [SUITE_TESTER_CMD] echo -n '' > scapyResult.txt
> > [SUITE_TESTER_CMD] scp sniff.py root at 10.239.128.80:~/
> > [SUITE_TESTER_CMD] SCAPY Receive setup:
> > [SUITE_TESTER_CMD] scapy
> > [SUITE_TESTER_CMD] subprocess.call("scapy -c sniff.py &", shell=True)
> > [SUITE_TESTER_CMD] sys.path.append("./")
> > [SUITE_TESTER_CMD] import sctp
> > [SUITE_TESTER_CMD] from sctp import *
> > [SUITE_TESTER_CMD]
> sendp([Ether(dst="90:e2:ba:4a:54:81")/IPv6(src="::1")/UDP(chksum=0xf)/("X"
> *46)], iface="p785p2")
> > [SUITE_TESTER_CMD]
> sendp([Ether(dst="90:e2:ba:4a:54:81")/IP(chksum=0x0)/SCTP(chksum=0xf)/("X"
> *48)], iface="p785p2")
> > [SUITE_TESTER_CMD]
> sendp([Ether(dst="90:e2:ba:4a:54:81")/IPv6(src="::1")/TCP(chksum=0xf)/("X"
> *46)], iface="p785p2")
> > [SUITE_TESTER_CMD]
> sendp([Ether(dst="90:e2:ba:4a:54:81")/IP(chksum=0x0)/UDP(chksum=0xf)/("X"*
> 46)], iface="p785p2")
> > [SUITE_TESTER_CMD]
> sendp([Ether(dst="90:e2:ba:4a:54:81")/IP(chksum=0x0)/TCP(chksum=0xf)/("X"*
> 46)], iface="p785p2")
> > [SUITE_TESTER_CMD] exit()
> > [SUITE_TESTER_CMD] cat scapyResult.txt
> > [SUITE_TESTER_CMD] SCAPY Result:
> > End test_checksum_offload_with_vlan
> >
> ---
> > [SUITE_DUT_CMD] quit
> >
> >
> >
> > DPDK STV team
[dpdk-dev] [PATCH 1/2] ixgbe: fix vfio ioctl SET_IRQS error
Tested-by: Yong Liu
> -Original Message-
> From: Liang, Cunming
> Sent: Friday, November 13, 2015 10:50 AM
> To: dev at dpdk.org
> Cc: Liu, Yong; Liang, Cunming
> Subject: [PATCH 1/2] ixgbe: fix vfio ioctl SET_IRQS error
>
> The vector number may change during 'dev_start'. Before enabling a new
> vector mapping,
> it's necessary to disable/unmap the previous setting.
>
> Fixes: 7ab8500037f6 ("ixgbe: fix VF start with PF stopped")
>
> Reported-by: Yong Liu
> Signed-off-by: Cunming Liang
> ---
> drivers/net/ixgbe/ixgbe_ethdev.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index 19ddb52..c2be264 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -1976,6 +1976,9 @@ ixgbe_dev_start(struct rte_eth_dev *dev)
> return -EINVAL;
> }
>
> + /* disable uio/vfio intr/eventfd mapping */
> + rte_intr_disable(intr_handle);
> +
> /* stop adapter */
> hw->adapter_stopped = 0;
> ixgbe_stop_adapter(hw);
> --
> 2.4.3
[dpdk-dev] [PATCH v5 1/7] ethdev: add additional ieee1588 support functions
Hi Thomas& John, Some update from validation team. > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Mcnamara, John > Sent: Tuesday, November 10, 2015 10:12 PM > To: Thomas Monjalon > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v5 1/7] ethdev: add additional ieee1588 > support functions > > > -Original Message- > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > Sent: Tuesday, November 10, 2015 11:58 AM > > To: Mcnamara, John > > Cc: Mrzyglod, DanielX T; dev at dpdk.org > > Subject: Re: [dpdk-dev] [PATCH v5 1/7] ethdev: add additional ieee1588 > > support functions > > > > 2015-11-10 11:36, Mcnamara, John: > > > From: Thomas Monjalon > > > > I'll try to fix it now to be sure it will be one of the first series > > > > ready for the 2.3 cycle. > > > > > > These comments are minor and could be fixed now. > > > > After having a closer look in the drivers change, it seems to be > > restricted to the PTP functions of the Intel drivers. > > So you can ask to the Intel validation team if they are OK to add it in > > RC2. > > I think it would be a wrong idea because we need to stop moving the > ethdev > > and drivers code, and focus on other DPDK areas for the RC2. > > Hi Thomas, > > Ok. I'll ask the validation team to evaluate the effect of the patches. > > For our validation team's view, in this patch set implemented some APIs which used to support Precision Time Protocol. The sample based those APIs can work as real ptp client. We have verified it work fine with linux ptp server.
[dpdk-dev] |ERROR| pw 8279-8293 maintainers: claim responsibility for ARMv7
Hi Viktorin, After check with our engineer, this commit is checked out from temporary branch. We're still looking for root issue. This error is only in the temporary branch and I have validated your patch set on master branch. There's only one applied issue in "doc/guides/rel_notes/release_2_2.rst". > -Original Message----- > From: Liu, Yong > Sent: Sunday, November 01, 2015 8:31 PM > To: 'Jan Viktorin'; dev at dpdk.org > Cc: Cao, Waterman; Mo, YufengX; Hunt, David; David Marchand > Subject: RE: |ERROR| pw 8279-8293 maintainers: claim responsibility for > ARMv7 > > Hi Viktorin, > I think the error is not related to your patch. Let me check it first. > > > -Original Message- > > From: Jan Viktorin [mailto:viktorin at rehivetech.com] > > Sent: Saturday, October 31, 2015 4:38 PM > > To: dev at dpdk.org > > Cc: Cao, Waterman; Liu, Yong; Mo, YufengX; Hunt, David; David Marchand > > Subject: Fw: |ERROR| pw 8279-8293 maintainers: claim responsibility for > > ARMv7 > > > > ?Hello, > > > > Again, I cannot see any relation with the arm patchset and this failure. > > It shouldn't affect other (x86) code at all. > > > > From where can I get the affc455438f4cbd3b14e2d9a24fbc154e22d68d3 commit? > > Can somebody do a bisect or something? Is it a bug in the niantic driver? > > I am confused...? > > > > Jan?Viktorin > > RehiveTech > > Sent?from?a?mobile?device > > > > ? P?vodn? zpr?va > > Od: sys_stv at intel.com > > Odesl?no: sobota, 31. ??jna 2015 6:53 > > Komu: test-report at dpdk.org; viktorin at rehivetech.com > > P?edm?t: |ERROR| pw 8279-8293 maintainers: claim responsibility for > ARMv7 > > > > Test-Label: Intel Niantic on Fedora > > Test-Status: ERROR > > Patchwork: http://www.dpdk.org/dev/patchwork/patch/8293/ > > > > DPDK git baseline: affc455438f4cbd3b14e2d9a24fbc154e22d68d3 > > Patchwork ID: 8279-8293 > > http://www.dpdk.org/dev/patchwork/patch/8293/ > > Submitter: Jan Viktorin > > Date: Fri, 30 Oct 2015 01:25:42 +0100 > > > > Source Compilation: > > OS: fedora > > Nic: niantic > > i686-native-linuxapp-gcc: compile pass > > x86_64-native-linuxapp-gcc: compile pass > > > > DTS validation: > > OS: fedora > > Nic: Niantic > > TestType: auto > > GCC: 4 > > x86_64-native-linuxapp-gcc: total 75, passed 74, failed 1. > > Failed Case List: > > Target: x86_64-native-linuxapp-gcc > > OS: fedora > > Failed DTS case: > > checksum_checking: > > http://dpdk.org/browse/tools/dts/tree/test_plans/pmd_test_plan.rst > > > > DTS Validation Error: > > > == > > == > > > == > > == > > TEST SUITE : TestPmd > > > > > -- > > - > > Begin: Test Casetest_checksum_checking > > -- > > FAILED 'packet pass assert error, expected 60 RX bytes, actual 0' > > -- > > [ SUITE_DUT_CMD] ./x86_64-native-linuxapp-gcc/app/testpmd -c > 0x1f > > -n 4 -- -i --coremask=0x2 --portmask=0x3 --nb-cores=2 --enable-rx-cksum > -- > > disable-hw-vlan --disable-rss --crc-strip --rxd=1024 --txd=1024 -- > > rxfreet=0 --txqflags=0 > > [ SUITE_DUT_CMD] set fwd csum > > [ SUITE_DUT_CMD] start > > [ SUITE_DUT_CMD] show port stats 0 > > [ SUITE_DUT_CMD] show port stats 1 > > [SUITE_TESTER_CMD] echo -n '' > scapyResult.txt > > [SUITE_TESTER_CMD] killall scapy 2>/dev/null; echo tester > > [SUITE_TESTER_CMD] scapy > > [SUITE_TESTER_CMD] nutmac="90:e2:ba:4a:54:81" > > [SUITE_TESTER_CMD] sendp([Ether(dst=nutmac, > > src="52:00:00:00:00:00")/IP(len=46)/UDP(chksum=0x0)/Raw(load="P"*18)], > > iface="p785p2") > > [SUITE_TESTER_CMD] exit() > > [ SUITE_DUT_CMD] show port stats 0 > > [ SUITE_DUT_CMD] show port stats 1 > > [ SUITE_DUT_CMD] stop > > [ SUITE_DUT_CMD] quit > > [ SUITE_DUT_CMD] ./x86_64-native-linuxapp-gcc/app/testpmd -c > 0x1f > > -n 4 -- -i --coremask=0x2 --portmask=0x3 --nb-cores=2 --enable-rx-cksum > -- > > disable-hw-vlan --disable-rss --crc-strip --rxd=1024 --txd=1024 -- > > rxfreet=8 --txqflags=0 > > [ SUITE_DUT_CMD] set fwd csum > > [ SUITE_DUT_CMD] start
[dpdk-dev] |ERROR| pw 8279-8293 maintainers: claim responsibility for ARMv7
Hi Viktorin, I think the error is not related to your patch. Let me check it first. > -Original Message- > From: Jan Viktorin [mailto:viktorin at rehivetech.com] > Sent: Saturday, October 31, 2015 4:38 PM > To: dev at dpdk.org > Cc: Cao, Waterman; Liu, Yong; Mo, YufengX; Hunt, David; David Marchand > Subject: Fw: |ERROR| pw 8279-8293 maintainers: claim responsibility for > ARMv7 > > ?Hello, > > Again, I cannot see any relation with the arm patchset and this failure. > It shouldn't affect other (x86) code at all. > > From where can I get the affc455438f4cbd3b14e2d9a24fbc154e22d68d3 commit? > Can somebody do a bisect or something? Is it a bug in the niantic driver? > I am confused...? > > Jan?Viktorin > RehiveTech > Sent?from?a?mobile?device > > ? P?vodn? zpr?va > Od: sys_stv at intel.com > Odesl?no: sobota, 31. ??jna 2015 6:53 > Komu: test-report at dpdk.org; viktorin at rehivetech.com > P?edm?t: |ERROR| pw 8279-8293 maintainers: claim responsibility for ARMv7 > > Test-Label: Intel Niantic on Fedora > Test-Status: ERROR > Patchwork: http://www.dpdk.org/dev/patchwork/patch/8293/ > > DPDK git baseline: affc455438f4cbd3b14e2d9a24fbc154e22d68d3 > Patchwork ID: 8279-8293 > http://www.dpdk.org/dev/patchwork/patch/8293/ > Submitter: Jan Viktorin > Date: Fri, 30 Oct 2015 01:25:42 +0100 > > Source Compilation: > OS: fedora > Nic: niantic > i686-native-linuxapp-gcc: compile pass > x86_64-native-linuxapp-gcc: compile pass > > DTS validation: > OS: fedora > Nic: Niantic > TestType: auto > GCC: 4 > x86_64-native-linuxapp-gcc: total 75, passed 74, failed 1. > Failed Case List: > Target: x86_64-native-linuxapp-gcc > OS: fedora > Failed DTS case: > checksum_checking: > http://dpdk.org/browse/tools/dts/tree/test_plans/pmd_test_plan.rst > > DTS Validation Error: > == > == > == > == > TEST SUITE : TestPmd > > -- > - > Begin: Test Casetest_checksum_checking > -- > FAILED 'packet pass assert error, expected 60 RX bytes, actual 0' > -- > [ SUITE_DUT_CMD] ./x86_64-native-linuxapp-gcc/app/testpmd -c 0x1f > -n 4 -- -i --coremask=0x2 --portmask=0x3 --nb-cores=2 --enable-rx-cksum -- > disable-hw-vlan --disable-rss --crc-strip --rxd=1024 --txd=1024 -- > rxfreet=0 --txqflags=0 > [ SUITE_DUT_CMD] set fwd csum > [ SUITE_DUT_CMD] start > [ SUITE_DUT_CMD] show port stats 0 > [ SUITE_DUT_CMD] show port stats 1 > [SUITE_TESTER_CMD] echo -n '' > scapyResult.txt > [SUITE_TESTER_CMD] killall scapy 2>/dev/null; echo tester > [SUITE_TESTER_CMD] scapy > [SUITE_TESTER_CMD] nutmac="90:e2:ba:4a:54:81" > [SUITE_TESTER_CMD] sendp([Ether(dst=nutmac, > src="52:00:00:00:00:00")/IP(len=46)/UDP(chksum=0x0)/Raw(load="P"*18)], > iface="p785p2") > [SUITE_TESTER_CMD] exit() > [ SUITE_DUT_CMD] show port stats 0 > [ SUITE_DUT_CMD] show port stats 1 > [ SUITE_DUT_CMD] stop > [ SUITE_DUT_CMD] quit > [ SUITE_DUT_CMD] ./x86_64-native-linuxapp-gcc/app/testpmd -c 0x1f > -n 4 -- -i --coremask=0x2 --portmask=0x3 --nb-cores=2 --enable-rx-cksum -- > disable-hw-vlan --disable-rss --crc-strip --rxd=1024 --txd=1024 -- > rxfreet=8 --txqflags=0 > [ SUITE_DUT_CMD] set fwd csum > [ SUITE_DUT_CMD] start > [ SUITE_DUT_CMD] show port stats 0 > [ SUITE_DUT_CMD] show port stats 1 > [SUITE_TESTER_CMD] echo -n '' > scapyResult.txt > [SUITE_TESTER_CMD] killall scapy 2>/dev/null; echo tester > [SUITE_TESTER_CMD] scapy > [SUITE_TESTER_CMD] nutmac="90:e2:ba:4a:54:81" > [SUITE_TESTER_CMD] sendp([Ether(dst=nutmac, > src="52:00:00:00:00:00")/IP(len=46)/UDP(chksum=0x0)/Raw(load="P"*18)], > iface="p785p2") > [SUITE_TESTER_CMD] exit() > [ SUITE_DUT_CMD] show port stats 0 > [ SUITE_DUT_CMD] show port stats 1 > [ SUITE_DUT_CMD] stop > [ SUITE_DUT_CMD] quit > [ SUITE_DUT_CMD] ./x86_64-native-linuxapp-gcc/app/testpmd -c 0x1f > -n 4 -- -i --coremask=0x2 --portmask=0x3 --nb-cores=2 --enable-rx-cksum -- > disable-hw-vlan --disable-rss --crc-strip --rxd=1024 --txd=1024 -- > rxfreet=16 --txqflags=0 > [ SUITE_DUT_CMD] set fwd csum > [ SUITE_DUT_CMD] start > [ SUITE_DUT_CMD] show port stats 0 > [ SUITE_DUT_CMD] show port stats 1 > [SUITE_TESTER_CMD] echo -n '' > scapyResult.txt > [SUITE_TESTER_CMD] killall sca
[dpdk-dev] [PATCH v4 0/7] e1000: add rx interrupt support
Thanks Thomas. > -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Friday, October 30, 2015 2:19 AM > To: Liu, Yong > Cc: dev at dpdk.org; Mcnamara, John > Subject: Re: [dpdk-dev] [PATCH v4 0/7] e1000: add rx interrupt support > > 2015-10-29 23:56, Yong Liu: > > This patch set will enable interrup for physical and emulated e1000 > device. > > Rx queue interrupt will work with uio driver or vfio driver with msi > mode. > > l3fwd-power will disable interrupt immediately when wake-up for that > e1000 not > > support interrupt auto clear. > > LSC and rxq interrupt will be seperated for e1000 can only support one > > interrupt cause in the same time. > > Don't you think it should be explained in a doc? > doc/guides/nics/e1000em.rst Yes, will update those information in the doc. > I'm especially confused by the need of changing an example for this PMD. > Does it mean the API behaviour must be changed? > After return back from sleep, Rx interrupt should always disabled until return to sleep. Some NICs like Niantic and Fortville support interrupt auto disable, so it worked normally. But e1000 not support that, so add rte_eth_dev_rx_intr_disable here to disable related interrupt. > [...] > > Marvin Liu (7): > > e1000: add rx interrupt support > > e1000: separate lsc and rxq interrupt disable function > > e1000: add ethdev rxq enable and disable function > > e1000: add rxq interrupt handler > > e1000: check lsc and rxq not enable in the same time > > e1000: lsc interrupt setup function only enable itself > > l3fwd-power: disable interrupt when wake up from sleep > > Announcing a support in first patch and making it work later > is a strange logic to review. > > You forgot to keep the Acked-by: Cunming Liang > > Applied in this order: > e1000: restrict link interrupt setup scope > e1000: separate link and Rx interrupt disabling > e1000: support Rx interrupt setup > e1000: add Rx interrupt handler > l3fwd-power: disable Rx interrupt when waking up > Thanks
[dpdk-dev] dpdk pre-patch testing introduction
Dear all, Our validation team is working on pre-patch testing to support contiguous integration in DPDK community. I'd like to share the latest status and some details of our solution to you. The main target of pre-patch testing is supplement the health of each patch set as soon as possible. It will help both submitter and maintainer to know the status of patch set before it's merged. Some of you have received the email which was generated by this tool. Let me introduce it to you. Example email subject: |SUCCESS| pw 8162 ixgbe: remove useless fields in tx_offload on TCP checksum request The first item is the overall status of this patch set. The second item is the patchwork ID and its commit log. There are 4 status to report as the following: Malformed patch: Patch's format doesn't incorrect, not applied in latest branch SUCCESS : Pass all testing. ERROR : fail in some testing, error information can be found in report Not run : Failed to compile, not able to perform functional testing Email content included more detailed information of this patch set, like build failure log and failed cases log. If patch set modified files for document, the content will also include the status of "Doc Compilation". So far, we only enabled one platform to run automatic testing. This platform installed Fedora 20 with Linux 3.18.9 and Intel Niantic NIC. Currently the patch testing only run unit test and basic function test on this platform. It can make sure that new patch doesn't break original code and functions. Due to coverage limitation, it can't verify the functionality of new patch. If you want to verify your patch's new function, you need to check with tester and perform specific testing on it. Since platform limitation, we are not able to verify regression test on other NIC, Linux kernel. We plan to add more platforms and support different NIC and kernels in the future. Best regards, DPDK validation team
[dpdk-dev] dpdk 1.8.0 disable burst problem
Hi Wei, We can't reproduce your issue in our environment. Below is our steps. 1. disable vector and change burst size CONFIG_RTE_IXGBE_INC_VECTOR=n Define PACKET_READ_SIZE to 1 in client_server_mp/mp_server/main.c. Define PKT_READ_SIZE to 1 in client_server_mp/mp_client/client.c. 2. Run mp_server with one client. mp_server -n 4 -c 0xf -- -p 0x3 -n 1 Rx function: Rx Burst Bulk Alloc Tx function: simple tx code path mp_client -n 4 -c 0xf0 --proc-type=secondary -- -n 0 3. Send packets to port0 and port1. Packets normally forwarded by client. PORTS - Port 0: '90:e2:ba:36:99:3c' Port 1: '90:e2:ba:36:99:3d' Port 0 - rx: 5000 tx: 1000 Port 1 - rx: 1000 tx: 5000 CLIENTS --- Client 0 - rx: 6000, rx_drop: 0 tx: 6000, tx_drop: 0 > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of ?? > Sent: Thursday, September 10, 2015 9:54 PM > To: dev at dpdk.org > Subject: [dpdk-dev] dpdk 1.8.0 disable burst problem > > Hi all, > > > I am using the dpdk example dpdk- > 1.8.0/examples/multi_process/client_server_mp on ubuntu 14.04. I need to > disable the batch. At first, I just change the macro in mp_server/main.c > and mp_client/client.c > #define PACKET_READ_SIZE 32 to 1 > The server and the client can not receive any packets. Almost of the > packets are counted to err from the port stat. > > Port:0, rx:511, rx_err:33011882, rx_nombuf:0, tx:0, tx_err:0 > > Port:0, rx_rate:0, rx_err_rate:782253,rx_nombuf_rate:0, tx_rate:0, > tx_err_rate:0 > > However, DPDK 1.4.1 works only changing the batch size from 32 to 1 in > server and client. > > What I did in the next step is > > disable the vector PMD burst on DPDK 1.8.0 version. > > disable the macro from config file > > CONFIG_RTE_IXGBE_INC_VECTOR=n > > However, nothing is changed. Port still reports packets errs. > > Can anyone help to look at this problem? I will be very appreciated. > > BTW, why DPDK 1.4.1 can not be compiled on ubuntu 14.04?
[dpdk-dev] [PATCH 0/2] Warn user if system has more than 64 cores when using VM power manager
Tested-by: Marvin Liu > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara > Sent: Thursday, August 06, 2015 7:08 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH 0/2] Warn user if system has more than 64 cores > when using VM power manager > > Pablo de Lara (2): > examples/vm_power_mgr: show warning when using systems with more than > 64 cores > doc: add known issue regarding VM power mgr in release notes > > doc/guides/rel_notes/known_issues.rst | 24 > examples/vm_power_manager/channel_manager.c | 11 +-- > 2 files changed, 29 insertions(+), 6 deletions(-) > > -- > 2.4.2
[dpdk-dev] [PATCH v2 1/1] bonding: fix error handling in rte_eth_bond_create()
Tested-by: Marvin Liu
> -Original Message-
> From: Iremonger, Bernard
> Sent: Wednesday, August 05, 2015 8:37 PM
> To: dev at dpdk.org
> Cc: Jastrzebski, MichalX K; Liu, Yong; Iremonger, Bernard
> Subject: [PATCH v2 1/1] bonding: fix error handling in
> rte_eth_bond_create()
>
> if the name parameter to rte_eth_bond_create() was NULL,
> there was a segmentation fault because eth_dev was also NULL.
>
> Signed-off-by: Bernard Iremonger
> ---
> drivers/net/bonding/rte_eth_bond_api.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/bonding/rte_eth_bond_api.c
> b/drivers/net/bonding/rte_eth_bond_api.c
> index 4ca26dd..0681d1a 100644
> --- a/drivers/net/bonding/rte_eth_bond_api.c
> +++ b/drivers/net/bonding/rte_eth_bond_api.c
> @@ -239,6 +239,10 @@ rte_eth_bond_create(const char *name, uint8_t mode,
> uint8_t socket_id)
>
> eth_dev->data->mac_addrs = rte_zmalloc_socket(name, ETHER_ADDR_LEN,
> 0,
> socket_id);
> + if (eth_dev->data->mac_addrs == NULL) {
> + RTE_BOND_LOG(ERR, "Unable to malloc mac_addrs");
> + goto err;
> + }
>
> eth_dev->data->dev_started = 0;
> eth_dev->data->promiscuous = 0;
> @@ -285,8 +289,10 @@ rte_eth_bond_create(const char *name, uint8_t mode,
> uint8_t socket_id)
> err:
> rte_free(pci_dev);
> rte_free(internals);
> - rte_free(eth_dev->data->mac_addrs);
> -
> + if (eth_dev != NULL) {
> + rte_free(eth_dev->data->mac_addrs);
> + rte_eth_dev_release_port(eth_dev);
> + }
> return -1;
> }
>
> --
> 1.9.1
[dpdk-dev] [PATCH] i40e:remove unlikely check in i40e_xmit_pkts for checksum offload
Acked-by: Marvin Liu
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jijiang Liu
> Sent: Tuesday, August 04, 2015 3:57 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] i40e:remove unlikely check in i40e_xmit_pkts
> for checksum offload
>
> The i40e_xmit_pkts() is called, which often means HW offload is used here,
> so we had better remove 'unlikely' check for checksum offload.
>
> Signed-off-by: Jijiang Liu
> ---
> drivers/net/i40e/i40e_rxtx.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
> index 6cc069b..eae4ab0 100644
> --- a/drivers/net/i40e/i40e_rxtx.c
> +++ b/drivers/net/i40e/i40e_rxtx.c
> @@ -1917,12 +1917,12 @@ i40e_xmit_pkts(void *tx_queue, struct rte_mbuf
> **tx_pkts, uint16_t nb_pkts)
>
> /* Enable checksum offloading */
> cd_tunneling_params = 0;
> - if (unlikely(ol_flags & I40E_TX_CKSUM_OFFLOAD_MASK)) {
> + if (ol_flags & I40E_TX_CKSUM_OFFLOAD_MASK) {
> i40e_txd_enable_checksum(ol_flags, _cmd, _offset,
> tx_offload, _tunneling_params);
> }
>
> - if (unlikely(nb_ctx)) {
> + if (nb_ctx) {
> /* Setup TX context descriptor if required */
> volatile struct i40e_tx_context_desc *ctx_txd =
> (volatile struct i40e_tx_context_desc *)\
> --
> 1.7.7.6
[dpdk-dev] [PATCH] app test: fix mempool cache_size not match limited cache_size
Thanks Thomas. > -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Monday, August 03, 2015 5:27 AM > To: Liu, Yong > Cc: dev at dpdk.org; olivier.matz at 6wind.com; Wu, Jingjing > Subject: Re: [dpdk-dev] [PATCH] app test: fix mempool cache_size not match > limited cache_size > > 2015-07-29 11:22, Yong Liu: > > In previous setting, mempool size and cache_size are both 32. > > This is not satisfied with cache_size checking rule by now. > > Cache size should less than CONFIG_RTE_MEMPOOL_CACHE_MAX_SIZE and > mempool size / 1.5. > > Sorry I don't really understand this explanation. > This information is stripped from the description for parameter cache_size of function rte_mempool_create. Now rte_mempool_create function will check cache_size value less than mempool size /1.5. In test_sched.c, mempool size and cache size are all 32 and not match mempool cache size checking rule. This will cause sched_autotest not work. > > #define NB_MBUF 32 > > #define MBUF_DATA_SZ (2048 + RTE_PKTMBUF_HEADROOM) > > -#define PKT_BURST_SZ 32 > > +#define PKT_BURST_SZ 0 > > #define MEMPOOL_CACHE_SZ PKT_BURST_SZ > > Shouldn't be MEMPOOL_CACHE_SZ to set to 0? Macro PKT_BURST_SZ not used in this file, MEMPOOL_CACHE_SZ should be set to 0.
[dpdk-dev] [PATCH v3] doc: announce abi change for interrupt mode
Acked-by: Marvin Liu > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Cunming Liang > Sent: Thursday, July 30, 2015 1:05 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v3] doc: announce abi change for interrupt mode > > The patch announces the planned ABI changes for interrupt mode. > > Signed-off-by: Cunming Liang > --- > v3 change: >- reword for CONFIG_RTE_NEXT_ABI > > v2 change: >- rebase to recent master > > doc/guides/rel_notes/deprecation.rst | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index 5330d3b..d36d267 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -35,3 +35,8 @@ Deprecation Notices > * The following fields have been deprecated in rte_eth_stats: >imissed, ibadcrc, ibadlen, imcasts, fdirmatch, fdirmiss, >tx_pause_xon, rx_pause_xon, tx_pause_xoff, rx_pause_xoff > + > +* The ABI changes are planned for struct rte_intr_handle, struct > rte_eth_conf > + and struct eth_dev_ops to support interrupt mode feature from release > 2.1. > + Those changes may be enabled in the upcoming release 2.1 > + with CONFIG_RTE_NEXT_ABI. > -- > 1.8.1.4
[dpdk-dev] [PATCH] i40e: correct the private data size for i40e vf driver
Tested-by: Marvin Liu
> -Original Message-
> From: Wu, Jingjing
> Sent: Tuesday, July 28, 2015 9:14 AM
> To: dev at dpdk.org
> Cc: Wu, Jingjing; Zhang, Helin; Chen, Jing D; Liu, Yong
> Subject: [PATCH] i40e: correct the private data size for i40e vf driver
>
> The patch fixes the i40e VF crash issue. The issue's root cause is that
> the dev_private_size in i40e virtual function driver struct
> rte_i40evf_pmd was set incorrectly.
>
> Signed-off-by: jingjing.wu
> ---
> drivers/net/i40e/i40e_ethdev_vf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/i40e/i40e_ethdev_vf.c
> b/drivers/net/i40e/i40e_ethdev_vf.c
> index f3470e6..b694400 100644
> --- a/drivers/net/i40e/i40e_ethdev_vf.c
> +++ b/drivers/net/i40e/i40e_ethdev_vf.c
> @@ -1248,7 +1248,7 @@ static struct eth_driver rte_i40evf_pmd = {
> },
> .eth_dev_init = i40evf_dev_init,
> .eth_dev_uninit = i40evf_dev_uninit,
> - .dev_private_size = sizeof(struct i40e_vf),
> + .dev_private_size = sizeof(struct i40e_adapter),
> };
>
> /*
> --
> 2.4.0
[dpdk-dev] [PATCH v2 1/1] ixgbe: Fix phy errors in stats->ierrors
Tested-by: Marvin Liu > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Lu, Wenzhuo > Sent: Tuesday, July 21, 2015 1:41 PM > To: Tahhan, Maryam; dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2 1/1] ixgbe: Fix phy errors in stats- > >ierrors > > Hi, > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Maryam Tahhan > > Sent: Monday, July 20, 2015 8:28 PM > > To: dev at dpdk.org > > Subject: [dpdk-dev] [PATCH v2 1/1] ixgbe: Fix phy errors in stats- > >ierrors > > > > Fixes: f6bf669b990004dc69231476d9fcf0b80574e568. Bug fix to remove > > (rxnfgpc - hw_stats->gprc) which does not account for phy errors. > > hw_stats->gprc is the Number of good (non-erred) Rx packets (from the > > network) that pass L2 filtering and has a legal length as defined by > > LongPacketEnable. While rxnfgpc is the Number of good (non-erred with > legal > > length) Rx packets (from the network) regardless of packet filtering and > receive > > enablement. Thus hw_stats->gprc can be > rxnfgpc and this calculation > should > > be removed from the calculation of ierrors. > > Validated with testpmd by sending packets to the interface without > forwarding > > enabled - packets should be dropped and the error counters incremented. > > > > v2: > > - specified the commit that this bug fix fixes. > > > > Signed-off-by: Maryam Tahhan > Acked-by: Wenzhuo Lu
[dpdk-dev] [PATCH] doc/testpmd_app_ug:add a comment for outer-ip option in csum
Acked-by: Marvin Liu > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jijiang Liu > Sent: Friday, July 17, 2015 4:13 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH] doc/testpmd_app_ug:add a comment for outer-ip > option in csum > > Add a comment for outer-ip option in csum command. > > Set outer-ip option only when the packet is a IPv4 packet. > > Signed-off-by: Jijiang Liu > --- > doc/guides/testpmd_app_ug/testpmd_funcs.rst |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst > b/doc/guides/testpmd_app_ug/testpmd_funcs.rst > index 4652962..c8baa76 100644 > --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst > +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst > @@ -541,7 +541,7 @@ csum set (ip|udp|tcp|sctp|outer-ip) (hw|sw) (port_id) > > - ip|udp|tcp|sctp always concern the inner layer. > > -- outer-ip concerns the outer IP layer in case the packet is recognized > +- outer-ip concerns the outer IP layer(only for IPv4) in case the packet > is recognized >as a tunnel packet by the forward engine (vxlan, gre and ipip are >supported). See "csum parse-tunnel" command. > > -- > 1.7.7.6
[dpdk-dev] [PATCH 0/3] fix the issue sctp flow cannot be matched in FVL FDIR
Hi, > -Original Message- > From: Wu, Jingjing > Sent: Tuesday, July 07, 2015 3:58 PM > To: dev at dpdk.org > Cc: Wu, Jingjing; Liu, Yong; Xu, HuilongX > Subject: [PATCH 0/3] fix the issue sctp flow cannot be matched in FVL FDIR > > This patch set fixes the issue SCTP flow cannot be matched by FVL's flow > director. The issue's root cause is that due to the NIC's firmware update, > the input set of sctp flow are changed to source IP, destination IP, > source port, destination port and Verification-Tag, which are source IP, > destination IP and Verification-Tag previously. > And because this fix will affect the struct rte_eth_fdir_flow, use > RTE_NEXT_ABI to avoid ABI breaking. > > Jingjing Wu (3): > ethdev: change the input set of sctp flow > i40e: make sport and dport of sctp flow involved in match > testpmd: add sport and dport configuration for sctp flow > > app/test-pmd/cmdline.c | 12 > drivers/net/i40e/i40e_fdir.c| 18 ++ > lib/librte_ether/rte_eth_ctrl.h | 8 > 3 files changed, 38 insertions(+) > > -- > 1.9.3 Tested-by: Marvin Liu
[dpdk-dev] [PATCH v2] doc/sample_app_ug:add a VXLAN sample guide
Hi,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jijiang Liu
> Sent: Friday, July 03, 2015 2:58 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2] doc/sample_app_ug:add a VXLAN sample guide
>
> Add a VXLAN sample guide in the sample_app_ug directory.
>
> It includes:
>
> - Add the overlay networking picture with svg format.
>
> - Add the TEP termination framework picture with svg format.
>
> - Add the tep_termination.rst file
>
> - Change the index.rst file for the above pictures index.
>
> Signed-off-by: Jijiang Liu
> Signed-off-by: Thomas Long
>
> v2 changes:
> optimize the two pictures
> add tep_termination index in index.rst file
> fix a typo and a command line
>
> ---
> .../sample_app_ug/img/overlay_networking.svg | 786
>
> .../sample_app_ug/img/tep_termination_arch.svg | 548 ++
> doc/guides/sample_app_ug/index.rst |3 +
> doc/guides/sample_app_ug/tep_termination.rst | 321
> 4 files changed, 1658 insertions(+), 0 deletions(-)
> create mode 100644 doc/guides/sample_app_ug/img/overlay_networking.svg
> create mode 100644 doc/guides/sample_app_ug/img/tep_termination_arch.svg
> create mode 100644 doc/guides/sample_app_ug/tep_termination.rst
>
> diff --git a/doc/guides/sample_app_ug/img/overlay_networking.svg
> b/doc/guides/sample_app_ug/img/overlay_networking.svg
> new file mode 100644
> index 000..2ce440d
> --- /dev/null
> +++ b/doc/guides/sample_app_ug/img/overlay_networking.svg
> @@ -0,0 +1,786 @@
> +
> + "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd;>
> +
> +http://www.w3.org/2000/svg;
> xmlns:xlink="http://www.w3.org/1999/xlink;
> xmlns:ev="http://www.w3.org/2001/xml-events;
> +
> xmlns:v="http://schemas.microsoft.com/visio/2003/SVGExtensions/;
> width="8.5in" height="11in" viewBox="0 0 612 792"
> + xml:space="preserve" color-interpolation-filters="sRGB"
> class="st29">
> +
> +
> + v:val="VT4(Rectangle)"/>
> +
> +
> +
> +
> +
> +
> + + .st1 {visibility:visible}
> + .st2 {fill:#b2b2b2;fill-opacity:0.5;stroke:#b2b2b2;stroke-
> linecap:round;stroke-linejoin:round;stroke-opacity:0.5}
> + .st3 {fill:#d8d8d8;fill-opacity:0.7;stroke:#404040;stroke-
> linecap:round;stroke-linejoin:round;stroke-width:0.25}
> + .st4 {fill:#00;font-family:Calibri;font-size:1.1em}
> + .st5 {fill:#cdcdcd;fill-opacity:0.5;stroke:#cdcdcd;stroke-
> linecap:round;stroke-linejoin:round;stroke-opacity:0.5}
> + .st6 {fill:#6b9bc7;stroke:#404040;stroke-linecap:round;stroke-
> linejoin:round;stroke-width:0.25}
> + .st7 {fill:#00;font-family:Calibri;font-size:0.86em}
> + .st8 {fill:#f6d5b9;stroke:#404040;stroke-linecap:round;stroke-
> linejoin:round;stroke-width:0.25}
> + .st9 {fill:#00;font-family:Calibri;font-size:0.75em}
> + .st10 {fill:url(#grad0-21);stroke:#404040;stroke-
> linecap:round;stroke-linejoin:round;stroke-width:0.25}
> + .st11 {fill:#00;font-family:Calibri;font-size:1.1em}
> + .st12 {fill:#00b0f0;fill-opacity:0.8;stroke:#404040;stroke-
> linecap:round;stroke-linejoin:round;stroke-width:0.25}
> + .st13 {fill:#00b0f0;stroke:#404040;stroke-
> linecap:round;stroke-linejoin:round;stroke-width:0.25}
> + .st14 {fill:#7030a0;fill-opacity:0.6;stroke:#404040;stroke-
> linecap:round;stroke-linejoin:round;stroke-width:0.25}
> + .st15 {fill:url(#grad0-121)}
> + .st16 {stroke:#0070c0;stroke-linecap:round;stroke-
> linejoin:round;stroke-width:1}
> + .st17 {fill:url(#grad0-128)}
> + .st18 {stroke:#d26d19;stroke-linecap:round;stroke-
> linejoin:round;stroke-width:1}
> + .st19 {stroke:#cdcdcd;stroke-linecap:round;stroke-
> linejoin:round;stroke-opacity:0.5;stroke-width:1.5}
> + .st20 {stroke:#d26d19;stroke-linecap:round;stroke-
> linejoin:round;stroke-width:1.5}
> + .st21 {stroke:#0070c0;stroke-linecap:round;stroke-
> linejoin:round;stroke-width:1.5}
> + .st22 {stroke:#7030a0;stroke-linecap:round;stroke-
> linejoin:round;stroke-width:1.5}
> + .st23 {stroke:#43365a;stroke-linecap:round;stroke-
> linejoin:round;stroke-width:1.5}
> + .st24 {stroke:#404040;stroke-linecap:round;stroke-
> linejoin:round;stroke-width:1.5}
> + .st25 {stroke:#00;stroke-linecap:round;stroke-
> linejoin:round;stroke-width:1.5}
> + .st26 {fill:url(#grad0-236)}
> + .st27 {stroke:#7030a0;stroke-linecap:round;stroke-
> linejoin:round;stroke-width:1}
> + .st28 {fill:#8fa350;stroke:#404040;stroke-
> linecap:round;stroke-linejoin:round;stroke-width:0.5}
> + .st29
[dpdk-dev] [PATCH v8 00/18] unified packet type
Tested-by: Yong Liu - Tested Commit: 7e1fa1de8a536c68f6af76cf8d222a9e948c93ba - OS: Fedora20 3.15.5 - GCC: gcc version 4.8.3 20140911 - CPU: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz - NIC: Intel Corporation XL710 10-Gigabit SFI/SFP+ [8086:1572] - NIC: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ [8086:10fb] - NIC: Intel Corporation I350 Gigabit Network Connection [8086:1521] - Default x86_64-native-linuxapp-gcc configuration - Prerequisites: Enable CONFIG_RTE_NEXT_ABI in dpdk configuration Disable CONFIG_RTE_IXGBE_INC_VECTOR in dpdk configuration - Total 10 cases, 10 passed, 0 failed - Case: L2 packet type detect Description: check L2 only packet can be normally detected by Fortville Command / instruction: Start testpmd and enable rxonly verbose mode ./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 -- -i --txqflags=0x0 set fwd rxonly set verbose 1 start Send time sync packet and verify Timesync packet detected Send ARP packet and verify ARP packet detected Send LLDP packet and verify LLDP packet detected - Case: IPv4 packet type detect Description: check L3 and L4 packet can be normally detected Fortville did not detect whether packet contian ipv4 header options, so L3 type will be shown as IPV4_EXT_UNKNOWN Command / instruction: Start testpmd and enable rxonly verbose mode Send IP only packet and verify L3 packet detected Send IP+UDP packet and verify L3 packet detected Send IP+TCP packet and verify L3 packet detected Send IP+SCTP packet and verify L3 packet detected Send IP+ICMP packet and verify L3 packet detected Send IP fragment+TCP packet and verify L3 packet detected - Case: IPv6 packet type detect Description: check IPv6 and L4 packet can be normally detected Fortville did not detect whether packet contian ipv6 extension options, so L3 type will be shown as IPV6_EXT_UNKNOWN Command / instruction: Start testpmd and enable rxonly verbose mode Send IPv6 only packet and verify L3 packet detected Send IPv6+UDP packet and verify L3 packet detected Send IPv6+TCP packet and verify L3 packet detected Send IPv6 fragment+TCP packet and verify L3 packet detected - Case: IP in IPv4 tunnel packet type detect Description: check tunnel packet can be normally detected by Fortville Command / instruction: Send IPv4+IPv4 fragment packet and verify tunnel packet detected Send IPv4+IPv4 packet and verify tunnel packet detected Send IPv4+IPv4+UDP packet and verify tunnel packet detected Send IPv4+IPv4+TCP packet and verify tunnel packet detected Send IPv4+IPv4+SCTP packet and verify tunnel packet detected Send IPv4+IPv4+ICMP packet and verify tunnel packet detected Send IPv4+IPv6 fragment packet and verify tunnel packet detected Send IPv4+IPv6 packet and verify tunnel packet detected Send IPv4+IPv6+UDP packet and verify tunnel packet detected Send IPv4+IPv6+TCP packet and verify tunnel packet detected Send IPv4+IPv6+SCTP packet and verify tunnel packet detected Send IPv4+IPv6+ICMP packet and verify tunnel packet detected - Case: IPv6 in IPv4 tunnel packet type detect by niantic Description: check tunnel packet can be normally detected by Niantic Niantic only can detect few types of ip in ip tunnel packets, this case designed to test them. Command / instruction: Send IPv4+IPv6 packet and verify tunnel packet detected Send IPv4+IPv6_EXT packet and verify tunnel packet detected Send IPv4+IPv6+UDP packet and verify tunnel packet detected Send IPv4+IPv6+TCP packet and verify tunnel packet detected Send IPv4+IPv6_EXT+UDP packet and verify tunnel packet detected Send IPv4+IPv6_EXT+TCP packet and verify tunnel packet detected - Case: IP in IPv6 tunnel packet type detect Description: check tunnel packet can be normally detected by Fortville Command / instruction: Send IPv6+IPv4 fragment packet and verify tunnel packet detected Send IPv6+IPv4 packet and verify tunnel packet detected Send IPv6+IPv4+UDP packet and verify tunnel packet detected Send IPv6+IPv4+TCP packet and verify tunnel packet detected Send IPv6+IPv4+SCTP packet and verify tunnel packet detected Send IPv6+IPv4+ICMP packet and verify tunnel packet detected Send IPv6+IPv6 fragment packet and verify tunnel packet detected Send IPv6+IPv6 packet and verify tunnel packet detected Send IPv6+IPv6+UDP packet and verify tunnel packet detected Send IPv6+IPv6+TCP packet and verify tunnel packet detected Send IPv6+IPv6+SCTP packet and verify tunnel packet detected Send IPv6+IPv6+ICMP packet and verify tunnel packet detected - Case: NVGRE tunnel packet type detect Description: check tunnel packet can be normally detected by Fortville Fortville did not distinguish GRE/Teredo/Vxlan packets, all those types will be displayed as GRENAT Command / instruction: Send IPv4+NVGRE
[dpdk-dev] [PATCH] doc/sample_app_ug:add a VXLAN sample guide
Hi Jijiang,
After build out dpdk doc, vxlan sample section not included in the contents of
"Sample Applications User Guide".
And in chapter "Running the Sample Code", vhost cuse command look like no
difference from vhost use command.
We may need to inform user that the difference between cuse and vhost is about
qemu command line.
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jijiang Liu
> Sent: Thursday, June 25, 2015 11:09 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] doc/sample_app_ug:add a VXLAN sample guide
>
> Add a VXLAN sample guide in the sample_app_ug directory.
>
> It includes:
>
> - Add the overlay networking picture with svg format.
>
> - Add the TEP termination framework picture with svg format.
>
> - Add the tep_termination.rst file
>
> - Change the index.rst file for the above pictures index.
>
> Signed-off-by: Jijiang Liu
> Signed-off-by: Thomas Long
>
> ---
> .../sample_app_ug/img/overlay_networking.svg | 820
>
> .../sample_app_ug/img/tep_termination_arch.svg | 551 +
> doc/guides/sample_app_ug/index.rst |2 +
> doc/guides/sample_app_ug/tep_termination.rst | 319
> 4 files changed, 1692 insertions(+), 0 deletions(-)
> create mode 100644 doc/guides/sample_app_ug/img/overlay_networking.svg
> create mode 100644 doc/guides/sample_app_ug/img/tep_termination_arch.svg
> create mode 100644 doc/guides/sample_app_ug/tep_termination.rst
>
> diff --git a/doc/guides/sample_app_ug/img/overlay_networking.svg
> b/doc/guides/sample_app_ug/img/overlay_networking.svg
> new file mode 100644
> index 000..e16b5ac
> --- /dev/null
> +++ b/doc/guides/sample_app_ug/img/overlay_networking.svg
> @@ -0,0 +1,820 @@
> +
> + "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd;>
> +
> +http://www.w3.org/2000/svg;
> xmlns:xlink="http://www.w3.org/1999/xlink;
> xmlns:ev="http://www.w3.org/2001/xml-events;
> +
> xmlns:v="http://schemas.microsoft.com/visio/2003/SVGExtensions/;
> width="8.5in" height="11in" viewBox="0 0 612 792"
> + xml:space="preserve" color-interpolation-filters="sRGB"
> class="st31">
> +
> +
> + v:val="VT4(Rectangle)"/>
> +
> +
> +
> +
> +
> +
> + + .st1 {visibility:visible}
> + .st2 {fill:#b2b2b2;fill-opacity:0.5;stroke:#b2b2b2;stroke-
> linecap:round;stroke-linejoin:round;stroke-opacity:0.5}
> + .st3 {fill:#d8d8d8;fill-opacity:0.7;stroke:#404040;stroke-
> linecap:round;stroke-linejoin:round;stroke-width:0.25}
> + .st4 {fill:#00;font-family:Calibri;font-size:1.1em}
> + .st5 {fill:#cdcdcd;fill-opacity:0.5;stroke:#cdcdcd;stroke-
> linecap:round;stroke-linejoin:round;stroke-opacity:0.5}
> + .st6 {fill:#6b9bc7;stroke:#404040;stroke-linecap:round;stroke-
> linejoin:round;stroke-width:0.25}
> + .st7 {fill:#00;font-family:Calibri;font-size:0.86em}
> + .st8 {fill:#f6d5b9;stroke:#404040;stroke-linecap:round;stroke-
> linejoin:round;stroke-width:0.25}
> + .st9 {fill:#00;font-family:Calibri;font-size:0.75em}
> + .st10 {fill:url(#grad0-21);stroke:#404040;stroke-
> linecap:round;stroke-linejoin:round;stroke-width:0.25}
> + .st11 {fill:#00;font-family:Calibri;font-size:1.1em}
> + .st12 {fill:#00b0f0;fill-opacity:0.8;stroke:#404040;stroke-
> linecap:round;stroke-linejoin:round;stroke-width:0.25}
> + .st13 {fill:#00b0f0;stroke:#404040;stroke-
> linecap:round;stroke-linejoin:round;stroke-width:0.25}
> + .st14 {fill:#7030a0;fill-opacity:0.6;stroke:#404040;stroke-
> linecap:round;stroke-linejoin:round;stroke-width:0.25}
> + .st15 {fill:url(#grad0-121)}
> + .st16 {stroke:#0070c0;stroke-linecap:round;stroke-
> linejoin:round;stroke-width:1}
> + .st17 {fill:url(#grad0-128)}
> + .st18 {stroke:#d26d19;stroke-linecap:round;stroke-
> linejoin:round;stroke-width:1}
> + .st19 {stroke:#cdcdcd;stroke-linecap:round;stroke-
> linejoin:round;stroke-opacity:0.5;stroke-width:1.5}
> + .st20 {stroke:#d26d19;stroke-linecap:round;stroke-
> linejoin:round;stroke-width:1.5}
> + .st21 {stroke:#0070c0;stroke-linecap:round;stroke-
> linejoin:round;stroke-width:1.5}
> + .st22 {stroke:#7030a0;stroke-linecap:round;stroke-
> linejoin:round;stroke-width:1.5}
> + .st23 {stroke:#43365a;stroke-linecap:round;stroke-
> linejoin:round;stroke-width:1.5}
> + .st24 {stroke:#404040;stroke-linecap:round;stroke-
> linejoin:round;stroke-width:1.5}
> + .st25 {stroke:#00;stroke-linecap:round;stroke-
> linejoin:round;stroke-width:1.5}
> + .st26 {fill:url(#grad0-234);stroke:#404040;stroke-
>
[dpdk-dev] [PATCH v3 00/10] Add a VXLAN sample
Tested-by: Yong Liu - Tested Commit: c1715402df8f7fdb2392e12703d5b6f81fd5f447 - OS: Fedora20 3.15.5 - GCC: gcc version 4.8.3 20140911 - CPU: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz - NIC: Intel Corporation Device XL710 [8086:1584] Firmware 4.33 - Default x86_64-native-linuxapp-gcc configuration - Prerequisites: set up dpdk vhost-user running environment allocate enough hugepages for both vxlan sample and virtual machine - Total 5 cases, 5 passed, 0 failed - Prerequisites command / instruction: Update qemu-system-x86_64 to version 2.2.0 which support hugepage based memory Prepare vhost-use requested modules modprobe fuse modprobe cuse insmod lib/librte_vhost/eventfd_link/eventfd_link.ko Allocate 4096*2M hugepages for vm and dpdk echo 4096 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages - Case: vxlan_sample_encap Description: check vxlan sample encap function work fine Command / instruction: Start vxlan sample with only encapsulation enable tep_termination -c 0xf -n 3 --socket-mem 2048,2048 -- -p 0x1 \ --udp-port 4789 --nb-devices 2 --filter-type 3 --tx-checksum 0 \ --encap 1 --decap 0 Wait for vhost-net socket device created and message dumped. VHOST_CONFIG: bind to vhost-net Start virtual machine with hugepage based memory and two vhost-user devices qemu-system-x86_64 -name vm0 -enable-kvm -daemonize \ -cpu host -smp 4 -m 4096 \ -object memory-backend-file,id=mem,size=4096M,mem-path=/mnt/huge,share=on \ -numa node,memdev=mem -mem-prealloc \ -chardev socket,id=char0,path=./dpdk/vhost-net \ -netdev type=vhost-user,id=netdev0,chardev=char0,vhostforce \ -device virtio-net-pci,netdev=netdev0,mac=00:00:20:00:00:20 \ -chardev socket,id=char1,path=./dpdk/vhost-net \ -netdev type=vhost-user,id=netdev1,chardev=char1,vhostforce \ -device virtio-net-pci,netdev=netdev1,mac=00:00:20:00:00:21 \ -drive file=/storage/vm-image/vm0.img -vnc :1 Login into virtual machine and start testpmd with additional arguments testpmd -c f -n 3 -- -i --txqflags=0xf00 --disable-hw-vlan Start packet forward of testpmd and transit several packets for mac learning testpmd> set fwd mac testpmd> start tx_first Make sure virtIO port registered normally. VHOST_CONFIG: virtio is now ready for processing. VHOST_DATA: (1) Device has been added to data core 56 VHOST_DATA: (1) MAC_ADDRESS 00:00:20:00:00:21 and VNI 1000 registered VHOST_DATA: (0) MAC_ADDRESS 00:00:20:00:00:20 and VNI 1000 registered Send normal udp packet to PF device and packet dmac match PF device Verify packet has been recevied in virtIO port0 and forwarded by port1 testpmd> show port stats all Verify encapsulated packet received on PF device - Case: vxlan_sample_decap Description: check vxlan sample decap function work fine Command / instruction: Start vxlan sample with only de-capsulation enable tep_termination -c 0xf -n 3 --socket-mem 2048,2048 -- -p 0x1 \ --udp-port 4789 --nb-devices 2 --filter-type 3 --tx-checksum 0 \ --encap 0 --decap 1 Start vhost-user test environment like case vxlan_sample_encap Send vxlan packet Ether(dst=PF mac)/IP/UDP/vni(1000)/ Ether(dst=virtIO port0)/IP/UDP to PF device Verify that packet received by virtIO port0 and forwarded by virtIO port1. testpmd> show port stats all Verify that PF received packet just the same as inner packet Send vxlan packet Ether(dst=PF mac)/IP/UDP/vni(1000)/ Ether(dst=virtIO port1)/IP/UDP to PF device Verify that packet received by virtIO port1 and forwarded by virtIO port0. testpmd> show port stats all Make sure PF received packet received inner packet with mac reversed. - Case: vxlan_sample_encap_and_decap Description: check vxlan sample decap work fine in the same time Command / instruction: Start vxlan sample with only de-capsulation enable tep_termination -c 0xf -n 3 --socket-mem 2048,2048 -- -p 0x1 \ --udp-port 4789 --nb-devices 2 --filter-type 3 --tx-checksum 0 \ --encap 1 --decap 1 Start vhost-user test environment like case vxlan_sample_encap Ether(dst=PF mac)/IP/UDP/vni(1000)/ Ether(dst=virtIO port0)/IP/UDP Send vxlan packet Ether(dst=PF mac)/IP/UDP/vni(1000)/ Ether(dst=virtIO port0)/IP/UDP to PF device Verify that packet received by virtIO port0 and forwarded by virtIO port1. testpmd> show port stats all Verify encapsulated packet received on PF device. Verify that inner packet src and dst mac address have been conversed. - Case: vxlan_sample_chksum Description: check vxlan sample transmit checksum work fine Command / instruction: Start vxlan sample with only decapsulation enable tep_termination -c 0xf -n 3 --socket-mem 2048,2048 -- -p 0x1 \
[dpdk-dev] [PATCH v2 00/10] Add a VXLAN sample
Tested-by: Yong Liu - Tested Commit: 7c4c66bf666b8059ed0ad2f2478ef349b3272f51 - OS: Fedora20 3.15.5 - GCC: gcc version 4.8.3 20140911 - CPU: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz - NIC: Intel Corporation Device XL710 [8086:1584] Firmware 4.33 - Default x86_64-native-linuxapp-gcc configuration - Prerequisites: set up dpdk vhost-user running environment allocate enough hugepages for both vxlan sample and virtual machine - Total 5 cases, 5 passed, 0 failed - Prerequisites command / instruction: Update qemu-system-x86_64 to version 2.2.0 which support hugepage based memory Prepare vhost-use requested modules modprobe fuse modprobe cuse insmod lib/librte_vhost/eventfd_link/eventfd_link.ko Allocate 4096*2M hugepages for vm and dpdk echo 4096 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages - Case: vxlan_sample_encap Description: check vxlan sample encap function work fine Command / instruction: Start vxlan sample with only encapsulation enable tep_termination -c 0xf -n 3 --socket-mem 2048,2048 -- -p 0x1 \ --udp-port 4789 --nb-devices 2 --filter-type 3 --tx-checksum 0 \ --encap 1 --decap 0 Wait for vhost-net socket device created and message dumped. VHOST_CONFIG: bind to vhost-net Start virtual machine with hugepage based memory and two vhost-user devices qemu-system-x86_64 -name vm0 -enable-kvm -daemonize \ -cpu host -smp 4 -m 4096 \ -object memory-backend-file,id=mem,size=4096M,mem-path=/mnt/huge,share=on \ -numa node,memdev=mem -mem-prealloc \ -chardev socket,id=char0,path=./dpdk/vhost-net \ -netdev type=vhost-user,id=netdev0,chardev=char0,vhostforce \ -device virtio-net-pci,netdev=netdev0,mac=00:00:20:00:00:20 \ -chardev socket,id=char1,path=./dpdk/vhost-net \ -netdev type=vhost-user,id=netdev1,chardev=char1,vhostforce \ -device virtio-net-pci,netdev=netdev1,mac=00:00:20:00:00:21 \ -drive file=/storage/vm-image/vm0.img -vnc :1 Login into virtual machine and start testpmd with additional arguments testpmd -c f -n 3 -- -i --txqflags=0xf00 --disable-hw-vlan Start packet forward of testpmd and transit several packets for mac learning testpmd> set fwd mac testpmd> start tx_first Make sure virtIO port registered normally. VHOST_CONFIG: virtio is now ready for processing. VHOST_DATA: (1) Device has been added to data core 56 VHOST_DATA: (1) MAC_ADDRESS 00:00:20:00:00:21 and VNI 1000 registered VHOST_DATA: (0) MAC_ADDRESS 00:00:20:00:00:20 and VNI 1000 registered Send normal udp packet to PF device and packet dmac match PF device Verify packet has been recevied in virtIO port0 and forwarded by port1 testpmd> show port stats all Verify encapsulated packet received on PF device - Case: vxlan_sample_decap Description: check vxlan sample decap function work fine Command / instruction: Start vxlan sample with only de-capsulation enable tep_termination -c 0xf -n 3 --socket-mem 2048,2048 -- -p 0x1 \ --udp-port 4789 --nb-devices 2 --filter-type 3 --tx-checksum 0 \ --encap 0 --decap 1 Start vhost-user test environment like case vxlan_sample_encap Send vxlan packet Ether(dst=PF mac)/IP/UDP/vni(1000)/ Ether(dst=virtIO port0)/IP/UDP to PF device Verify that packet received by virtIO port0 and forwarded by virtIO port1. testpmd> show port stats all Verify that PF received packet just the same as inner packet Send vxlan packet Ether(dst=PF mac)/IP/UDP/vni(1000)/ Ether(dst=virtIO port1)/IP/UDP to PF device Verify that packet received by virtIO port1 and forwarded by virtIO port0. testpmd> show port stats all Make sure PF received packet received inner packet with mac reversed. - Case: vxlan_sample_encap_and_decap Description: check vxlan sample decap work fine in the same time Command / instruction: Start vxlan sample with only de-capsulation enable tep_termination -c 0xf -n 3 --socket-mem 2048,2048 -- -p 0x1 \ --udp-port 4789 --nb-devices 2 --filter-type 3 --tx-checksum 0 \ --encap 1 --decap 1 Start vhost-user test environment like case vxlan_sample_encap Ether(dst=PF mac)/IP/UDP/vni(1000)/ Ether(dst=virtIO port0)/IP/UDP Send vxlan packet Ether(dst=PF mac)/IP/UDP/vni(1000)/ Ether(dst=virtIO port0)/IP/UDP to PF device Verify that packet received by virtIO port0 and forwarded by virtIO port1. testpmd> show port stats all Verify encapsulated packet received on PF device. Verify that inner packet src and dst mac address have been conversed. - Case: vxlan_sample_chksum Description: check vxlan sample transmit checksum work fine Command / instruction: Start vxlan sample with only decapsulation enable tep_termination -c 0xf -n 3 --socket-mem 2048,2048 -- -p 0x1 \
[dpdk-dev] [PATCH v10 00/13] Interrupt mode PMD
l3fwd-power -c 0x6 -n 3 -- -p 0x3 -P --config="(0,0,1),(1,0,2)" Verify packet interrupt can be normally handled like previous case pf_rxq_on_vfio_msix. - Case: pf_rxq_on_uiopcigeneric Description: check when pf bound to uio_pci_generic, receive packet interrupt can be normally handled Command / instruction: Insmod uio_pci_generic driver and bind pf device on it. ./tools/dpdk_nic_bind.py --bind=uio_pci_generic 08:00.0 08:00.1 Start l3fwd-power with 2 ports and 2 cores. l3fwd-power -c 0x6 -n 3 -- -p 0x3 -P --config="(0,0,1),(1,0,2)" Verify packet interrupt can be normally handled like previous case pf_rxq_on_vfio_msix. - Case: pf_lsc_on_uiopcigeneric Description: check when pf bound to uio_pci_generic, link status changed interrupt can be normally handled Command / instruction: Insmod uio_pci_generic driver and bind pf device on it. ./tools/dpdk_nic_bind.py --bind=uio_pci_generic 08:00.0 08:00.1 Start l3fwd-power with 2 ports and 2 cores. l3fwd-power -c 0x6 -n 3 -- -p 0x3 -P --config="(0,0,1),(1,0,2)" Change tester port0 link down and verify link down detected on dut port0 Port 0: link down Change tester port0 link up and verify link up detected on dut port0 Port 0: link up Change tester port1 link down and verify link down detected on dut port1 Port 1: link down Change tester port1 link up and verify link up detected on dut port1 Port 1: link up Change port config to lsc enable and rxq enable in l3fwd-power/main.c Build l3fwd-power and start l3fwd-power with 2 ports l3fwd-power -c 0x6 -n 3 -- -p 0x3 -P --config="(0,0,1),(1,0,2)" Verify lsc disabled for can't enable lsc and rxq in the same time when pf bound to uio_pci_generic lsc won't enable because of no intr multiplex - Case: vf_in_vm_rxq Description: check when vf bound to igb_uio in virtual machine, receive packet interrupt can be normally handled Only support niantic by now. Command / instruction: Create vf devices and bound into virtual machine echo 1 > /sys/bus/pci/devices/\:08\:00.0/sriov_numvfs echo 1 > /sys/bus/pci/devices/\:08\:00.1/sriov_numvfs virsh virsh # nodedev-dettach pci__08_10_0 virsh # nodedev-dettach pci__08_10_1 Start virtual machine and bind vf devices to driver igb_uio. ./tools/dpdk_nic_bind.py --bind=igb_uio eth1 eth2 Change port config to lsc disable and rxq enable in l3fwd-power/main.c Start l3fwd-power with 2 ports and 2 cores. l3fwd-power -c 0x6 -n 3 -- -p 0x3 -P --config="(0,0,1),(1,0,2)" Send packet from tester port0 with promisc mac and verify vm core1 wakeup and then sleep. lcore 1 is waked up from rx interrupt on port 0 queue 0 lcore 1 sleeps until interrupt triggers Send packet from tester port1 with promisc mac and verify vm core2 wakeup and then sleep. lcore 2 is waked up from rx interrupt on port 1 queue 0 lcore 2 sleeps until interrupt triggers - Case: vf_in_host_rxq Description: check when vf bound to vfio with msix mode, receive packet interrupt can be normally handled Only support niantic by now. Command / instruction: Create vf devices and bound to vfio echo 1 > /sys/bus/pci/devices/\:08\:00.0/sriov_numvfs echo 1 > /sys/bus/pci/devices/\:08\:00.1/sriov_numvfs modprobe vfio modprobe vfio-pci ./tools/dpdk_nic_bind.py --bind=vfio-pci 08:10.0 08:10.1 Start l3fwd-power with 2 ports and 2 cores. l3fwd-power -c 0x6 -n 3 -- -p 0x3 -P --config="(0,0,1),(1,0,2)" Send packet from tester port0 with promisc mac and verify dut core1 wakeup and then sleep. lcore 1 is waked up from rx interrupt on port 0 queue 0 lcore 1 sleeps until interrupt triggers Send packet from tester port1 with promisc mac and verify dut core2 wakeup and then sleep. lcore 2 is waked up from rx interrupt on port 1 queue 0 lcore 2 sleeps until interrupt triggers > -Original Message- > From: Liang, Cunming > Sent: Tuesday, June 02, 2015 2:53 PM > To: dev at dpdk.org > Cc: shemming at brocade.com; david.marchand at 6wind.com; > thomas.monjalon at 6wind.com; Zhou, Danny; Wang, Liang-min; Richardson, Bruce; > Liu, Yong; nhorman at tuxdriver.com; Liang, Cunming > Subject: [PATCH v10 00/13] Interrupt mode PMD > > v10 changes > - code rework to return actual error code > - bug fix for lsc when using uio_pci_generic > > v9 changes > - code rework to fix open comment > - bug fix for igb lsc when both lsc and rxq are enabled in vfio-msix > - new patch to turn off the feature by defalut so as to avoid v2.1 abi > broken > > v8 changes > - remove condition check for only vfio-msix > - add multiplex intr support when only one intr
[dpdk-dev] [PATCH v9 01/12] eal/linux: add interrupt vectors support in intr_handle
0.0 08:00.1 Start l3fwd-power with 2 ports and 2 cores. l3fwd-power -c 0x6 -n 3 -- -p 0x3 -P --config="(0,0,1),(1,0,2)" Verify packet interrupt can be normally handled like previous case pf_rxq_on_vfio_msix. - Case: pf_rxq_on_uiopcigeneric Description: check when pf bound to uio_pci_generic, receive packet interrupt can be normally handled Command / instruction: Insmod uio_pci_generic driver and bind pf device on it. ./tools/dpdk_nic_bind.py --bind=uio_pci_generic 08:00.0 08:00.1 Start l3fwd-power with 2 ports and 2 cores. l3fwd-power -c 0x6 -n 3 -- -p 0x3 -P --config="(0,0,1),(1,0,2)" Verify packet interrupt can be normally handled like previous case pf_rxq_on_vfio_msix. - Case: pf_lsc_on_uiopcigeneric Description: check when pf bound to uio_pci_generic, link status changed interrupt can be normally handled Command / instruction: Insmod uio_pci_generic driver and bind pf device on it. ./tools/dpdk_nic_bind.py --bind=uio_pci_generic 08:00.0 08:00.1 Start l3fwd-power with 2 ports and 2 cores. l3fwd-power -c 0x6 -n 3 -- -p 0x3 -P --config="(0,0,1),(1,0,2)" Change tester port0 link down and verify link down detected on dut port0 Port 0: link down Change tester port0 link up and verify link up detected on dut port0 Port 0: link up Change tester port1 link down and verify link down detected on dut port1 Port 1: link down Change tester port1 link up and verify link up detected on dut port1 Port 1: link up Change port config to lsc enable and rxq enable in l3fwd-power/main.c Build l3fwd-power and start l3fwd-power with 2 ports l3fwd-power -c 0x6 -n 3 -- -p 0x3 -P --config="(0,0,1),(1,0,2)" Verify lsc disabled for can't enable lsc and rxq in the same time when pf bound to uio_pci_generic lsc won't enable because of no intr multiplex - Case: vf_in_vm_rxq Description: check when vf bound to igb_uio in virtual machine, receive packet interrupt can be normally handled Only support niantic by now. Command / instruction: Create vf devices and bound into virtual machine echo 1 > /sys/bus/pci/devices/\:08\:00.0/sriov_numvfs echo 1 > /sys/bus/pci/devices/\:08\:00.1/sriov_numvfs virsh virsh # nodedev-dettach pci__08_10_0 virsh # nodedev-dettach pci__08_10_1 Start virtual machine and bind vf devices to driver igb_uio. ./tools/dpdk_nic_bind.py --bind=igb_uio eth1 eth2 Change port config to lsc disable and rxq enable in l3fwd-power/main.c Start l3fwd-power with 2 ports and 2 cores. l3fwd-power -c 0x6 -n 3 -- -p 0x3 -P --config="(0,0,1),(1,0,2)" Send packet from tester port0 with promisc mac and verify vm core1 wakeup and then sleep. lcore 1 is waked up from rx interrupt on port 0 queue 0 lcore 1 sleeps until interrupt triggers Send packet from tester port1 with promisc mac and verify vm core2 wakeup and then sleep. lcore 2 is waked up from rx interrupt on port 1 queue 0 lcore 2 sleeps until interrupt triggers - Case: vf_in_host_rxq Description: check when vf bound to vfio with msix mode, receive packet interrupt can be normally handled Only support niantic by now. Command / instruction: Create vf devices and bound to vfio echo 1 > /sys/bus/pci/devices/\:08\:00.0/sriov_numvfs echo 1 > /sys/bus/pci/devices/\:08\:00.1/sriov_numvfs modprobe vfio modprobe vfio-pci ./tools/dpdk_nic_bind.py --bind=vfio-pci 08:10.0 08:10.1 Start l3fwd-power with 2 ports and 2 cores. l3fwd-power -c 0x6 -n 3 -- -p 0x3 -P --config="(0,0,1),(1,0,2)" Send packet from tester port0 with promisc mac and verify dut core1 wakeup and then sleep. lcore 1 is waked up from rx interrupt on port 0 queue 0 lcore 1 sleeps until interrupt triggers Send packet from tester port1 with promisc mac and verify dut core2 wakeup and then sleep. lcore 2 is waked up from rx interrupt on port 1 queue 0 lcore 2 sleeps until interrupt triggers > -Original Message- > From: Liang, Cunming > Sent: Friday, May 29, 2015 4:45 PM > To: dev at dpdk.org > Cc: shemming at brocade.com; david.marchand at 6wind.com; > thomas.monjalon at 6wind.com; Zhou, Danny; Wang, Liang-min; Richardson, Bruce; > Liu, Yong; nhorman at tuxdriver.com; Liang, Cunming > Subject: [PATCH v9 01/12] eal/linux: add interrupt vectors support in > intr_handle > > The patch adds interrupt vectors support in rte_intr_handle. > 'vec_en' is set when interrupt vectors are detected and associated event > fds are set. > Those event fds are stored in efds[]. > 'intr_vec' is reserved for device driver to initialize the vector mapping > table. > When the event fds add to a specified epoll instance, 'eptrs' w
[dpdk-dev] [PATCH] e1000: modify mac type checking before flex filter is programmed
> -Original Message- > From: Wu, Jingjing > Sent: Thursday, March 26, 2015 12:53 PM > To: dev at dpdk.org > Cc: Wu, Jingjing; Liu, Yong > Subject: [PATCH] e1000: modify mac type checking before flex filter is > programmed > > This patch changes MAC_TYPE_FILTER_SUP to MAC_TYPE_FILTER_SUP_EXT in > flex filter handling function. It will remove NIC 82576 from flex filter > support. > > Signed-off-by: Jingjing Wu > --- > lib/librte_pmd_e1000/igb_ethdev.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lib/librte_pmd_e1000/igb_ethdev.c > b/lib/librte_pmd_e1000/igb_ethdev.c > index 49843c1..79ad267 100644 > --- a/lib/librte_pmd_e1000/igb_ethdev.c > +++ b/lib/librte_pmd_e1000/igb_ethdev.c > @@ -2908,7 +2908,7 @@ eth_igb_flex_filter_handle(struct rte_eth_dev *dev, > struct rte_eth_flex_filter *filter; > int ret = 0; > > - MAC_TYPE_FILTER_SUP(hw->mac.type); > + MAC_TYPE_FILTER_SUP_EXT(hw->mac.type); > > if (filter_op == RTE_ETH_FILTER_NOP) > return ret; > -- > 1.9.3 Acked-by: Marvin Liu
[dpdk-dev] [PATCH] ixgbe: fix the issue second 5tuple filter overwrites the first one
> -Original Message- > From: Wu, Jingjing > Sent: Wednesday, March 25, 2015 12:47 PM > To: dev at dpdk.org > Cc: Wu, Jingjing; Liu, Yong > Subject: [PATCH] ixgbe: fix the issue second 5tuple filter overwrites the > first one > > This patch corrects the index to fix the issue that is second 5tuple > filter > overwrites the first one. > > Signed-off-by: Jingjing Wu Acked-by: Marvin Liu > --- > lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c > b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c > index 92d75db..5caee22 100644 > --- a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c > +++ b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c > @@ -3882,10 +3882,10 @@ ixgbe_add_5tuple_filter(struct rte_eth_dev *dev, > ftqf |= IXGBE_FTQF_POOL_MASK_EN; > ftqf |= IXGBE_FTQF_QUEUE_ENABLE; > > - IXGBE_WRITE_REG(hw, IXGBE_DAQF(idx), filter->filter_info.dst_ip); > - IXGBE_WRITE_REG(hw, IXGBE_SAQF(idx), filter->filter_info.src_ip); > - IXGBE_WRITE_REG(hw, IXGBE_SDPQF(idx), sdpqf); > - IXGBE_WRITE_REG(hw, IXGBE_FTQF(idx), ftqf); > + IXGBE_WRITE_REG(hw, IXGBE_DAQF(i), filter->filter_info.dst_ip); > + IXGBE_WRITE_REG(hw, IXGBE_SAQF(i), filter->filter_info.src_ip); > + IXGBE_WRITE_REG(hw, IXGBE_SDPQF(i), sdpqf); > + IXGBE_WRITE_REG(hw, IXGBE_FTQF(i), ftqf); > > l34timir |= IXGBE_L34T_IMIR_RESERVE; > l34timir |= (uint32_t)(filter->queue << > -- > 1.9.3 Acked-by: Marvin Liu
[dpdk-dev] [PATCH] fix the net device bugs and add some funcs to generate vfs in net_device
On 3/19/2015 11:17 AM, Yong Liu wrote:
Mistook sending, please ignore this patch.
> From: sjiajiax
>
> add some codes to test the vf actions
>
> diff --git a/tools/DTF/framework/dut.py b/tools/DTF/framework/dut.py
> index 02c7639..2b85f23 100644
> --- a/tools/DTF/framework/dut.py
> +++ b/tools/DTF/framework/dut.py
> @@ -10,7 +10,7 @@ from ssh_connection import SSHConnection
> from crb import Crb
> from net_device import NetDevice
> from logger import getLogger
> -
> +import pdb
>
> class Dut(Crb):
>
> @@ -390,7 +390,8 @@ class Dut(Crb):
>
> for (pci_bus, pci_id) in self.pci_devices_info:
>
> -if not dts.accepted_nic(pci_id):
> +#if not dts.accepted_nic(pci_id):
> +if pci_id == '1106:3119':
> self.logger.info("DUT: [000:%s %s] %s" % (pci_bus, pci_id,
>skipped))
> continue
> @@ -488,25 +489,31 @@ class Dut(Crb):
> """
> Generate SRIOV VFs with default driver it is bound now or specifid
> driver.
> """
> -pci_bus = self.port_info[port_id]['pci']
> -port = self.port_info[port_id]['port']
> -
> -bus_id = pci_bus.split(':')[0]
> -devfun_id = pci_bus.split(':')[1]
> -port_driver = self.get_dev_driver(bus_id, devfun_id)
> +port = self.ports_info[port_id]['port']
> +port_driver = port.get_nic_driver()
>
> if driver == 'default':
> -if not port_dirver:
> +if not port_driver:
> self.logger.info("No driver on specified port, can not
> generate SRIOV VF.")
> return None
> else:
> if port_driver != driver:
> -self.bind_interfaces_linux(driver, pci_bus)
> +port.bind_driver(driver)
> port.generate_sriov_vfs(vf_num)
>
> -sriov_vfs_pci = port.get_sriov_vfs_pci(bus_id, devfun_id)
> +sriov_vfs_pci = port.get_sriov_vfs_pci()
> self.ports_info[port_id]['sriov_vfs_pci'] = sriov_vfs_pci
>
> +def destroy_sriov_vfs_by_port(self, port_id):
> +port = self.ports_info[port_id]['port']
> +port_driver = port.get_nic_driver()
> +
> +if not port_driver:
> +self.logger.info("No driver on specified port, skip destroy
> SRIOV VF.")
> +else:
> +sriov_vfs_pci = port.destroy_sriov_vfs()
> +self.ports_info[port_id]['sriov_vfs_pci'] = ''
> +
> def get_vm_core_list(self):
> return VMCORELIST[self.crb['VM CoreList']]
>
> diff --git a/tools/DTF/framework/net_device.py
> b/tools/DTF/framework/net_device.py
> index 9186ad6..1a99f68 100644
> --- a/tools/DTF/framework/net_device.py
> +++ b/tools/DTF/framework/net_device.py
> @@ -1,3 +1,5 @@
> +import os
> +import re
> from functools import wraps
> import pdb
>
> @@ -12,19 +14,21 @@ class NetDevice(object):
> self.crb = crb
> self.bus_id = bus_id
> self.devfun_id = devfun_id
> +self.default_driver = self.get_nic_driver()
> self.intf_name = self.get_interface_name()
>
> def __send_expect(self, cmds, expected, timeout=TIMEOUT,
> alt_session=False):
> return self.crb.send_expect(cmds, expected, timeout=TIMEOUT,
> alt_session=False)
>
> def __get_os_type(self):
> -return self.crb.__get_os_type()
> +return self.crb.get_os_type()
>
> def nic_has_driver(func):
> @wraps(func)
> -def wrapper(self, *args, **kwargs):
> -self.current_driver = self.get_nic_driver()
> -if not self.current_driver:
> +def wrapper(*args, **kwargs):
> +nic_instance = args[0]
> +nic_instance.current_driver = nic_instance.get_nic_driver()
> +if not nic_instance.current_driver:
> return ''
> return func(*args, **kwargs)
> return wrapper
> @@ -201,17 +205,17 @@ class NetDevice(object):
> generic_driver = 'generic'
> get_sriov_vfs_pci_linux = getattr(self,
> 'get_sriov_vfs_pci_linux_%s' % generic_driver)
>
> -return get_sriov_vfs_pci_linux(intf, bus_id, devfun_id)
> +return get_sriov_vfs_pci_linux(bus_id, devfun_id)
>
> def get_sriov_vfs_pci_linux_generic(self, bus_id, devfun_id):
> sriov_numvfs = self.__send_expect("cat
> /sys/bus/pci/devices/\:%s\:%s/sriov_numvfs" %
> (bus_id, devfun_id), "# ")
> sriov_vfs_pci = []
> -if sriov_numvfs == 0:
> +if int(sriov_numvfs) == 0:
> pass
> else:
> try:
> -virtfns = self.send_exepct("ls -d
> /sys/bus/pci/devices/\:%s\:%s/virtfn*" %
> +virtfns = self.__send_expect("ls -d
> /sys/bus/pci/devices/\:%s\:%s/virtfn*" %
> (bus_id, devfun_id),
[dpdk-dev] [PATCH] fix build warning and failure in Suse11
Hi Thomas, I'll separated this patch set into several patches and send them out later. I think this patch can also fix some issue on gcc 44. > -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Wednesday, March 18, 2015 6:51 PM > To: Liu, Yong > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH] fix build warning and failure in Suse11 > > Hi Yong, > > Thanks for working on these important fixes. > > 2015-03-18 15:10, Yong Liu: > > Suse11 SP3 default gcc version is 4.3.4, some options not support on > this version. > > I guess some of these errors are not only specific to Suse-11? > Maybe that 1 patch per issue would be easier to read and could provide a > more > accurate description. > > > error: implicit declaration of function ?_mm_alignr_epi8? > > solution: include tmmintrin.h when enable SSE3 > > > > error: unrecognized command line option "-Wno-unused-but-set-variable" > > solution: add version check in fm10k Makefile > > > > error: enic_main.c:845: error: initialized field overwritten > > solution: change struct initialization code > > > > error: ?testfn_pci_cmd? defined but not used > > solution: add __attribute__((unused)) before function definition > > Please could you explain more the problem? > There are other constructors in DPDK which don't need the unused attribute. > > > > > error: unrecognized command line option "-fno-var-tracking-assignments" > > solution: add version check in app/test/Makefile > > > > error: implicit declaration of function ?pread? > > solution: add _GNU_SOURCE flag when compile eal_pci_uio and > eal_interrupts > > > > signed-off-by: Marvin Liu > > Please use -s git option to have an automatic well formatted Signed-off. > Your previous contributions were signed "Yong Liu". Do you prefer Marvin > Liu? Thanks Thomas, "Marvin" the name I used in DTS branch. For my major task is in DTS project, I preferred to use "Marvin Liu":)
[dpdk-dev] [PATCH 1/3 v3] librte_hash: Fix unsupported instruction `crc32' in i686 platform
Michael & Thomas,
Should we use software crc function replace of hardware crc function in
'crc32c_sse42_u64' when arch is i686?
Thus application still can use CRC32_SSE42_x64 algorithm for crc calculation
when build with i686 configuration.
This may helpful for simplify application code.
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Michael Qiu
> Sent: Monday, March 09, 2015 1:58 PM
> To: dev at dpdk.org
> Cc: yerden.zhumabekov at sts.kz
> Subject: [dpdk-dev] [PATCH 1/3 v3] librte_hash: Fix unsupported
> instruction `crc32' in i686 platform
>
> CC rte_hash.o
> Error: unsupported instruction `crc32'
>
> The root cause is that i686 platform does not support 'crc32q'
> Need make it only available in x86_64 platform
>
> Signed-off-by: Michael Qiu
> Acked-by: Yerden Zhumabekov
> ---
> v3 --> v2:
> Add sub function for #else which returns 0
> v2 --> v1:
> Make crc32 instruction only works in X86 platform
>
> lib/librte_hash/rte_hash_crc.h | 46 +
> -
> 1 file changed, 36 insertions(+), 10 deletions(-)
>
> diff --git a/lib/librte_hash/rte_hash_crc.h
> b/lib/librte_hash/rte_hash_crc.h
> index d28bb2a..f1dbded 100644
> --- a/lib/librte_hash/rte_hash_crc.h
> +++ b/lib/librte_hash/rte_hash_crc.h
> @@ -47,6 +47,7 @@ extern "C" {
> #include
> #include
> #include
> +#include
>
> /* Lookup tables for software implementation of CRC32C */
> static const uint32_t crc32c_tables[8][256] = {{
> @@ -364,6 +365,7 @@ crc32c_2words(uint64_t data, uint32_t init_val)
> return crc;
> }
>
> +#if defined(RTE_ARCH_I686) || defined(RTE_ARCH_X86_64)
> static inline uint32_t
> crc32c_sse42_u32(uint32_t data, uint32_t init_val)
> {
> @@ -375,16 +377,6 @@ crc32c_sse42_u32(uint32_t data, uint32_t init_val)
> }
>
> static inline uint32_t
> -crc32c_sse42_u64(uint64_t data, uint64_t init_val)
> -{
> - __asm__ volatile(
> - "crc32q %[data], %[init_val];"
> - : [init_val] "+r" (init_val)
> - : [data] "rm" (data));
> - return init_val;
> -}
> -
> -static inline uint32_t
> crc32c_sse42_u64_mimic(uint64_t data, uint64_t init_val)
> {
> union {
> @@ -397,6 +389,40 @@ crc32c_sse42_u64_mimic(uint64_t data, uint64_t
> init_val)
> init_val = crc32c_sse42_u32(d.u32[1], init_val);
> return init_val;
> }
> +#else
> +static inline uint32_t
> +crc32c_sse42_u32(__rte_unused uint32_t data,
> + __rte_unused uint32_t init_val)
> +{
> + return 0;
> +}
> +
> +static inline uint32_t
> +crc32c_sse42_u64_mimic(__rte_unused uint32_t data,
> +__rte_unused uint32_t init_val)
> +{
> + return 0;
> +}
> +#endif
> +
> +#ifdef RTE_ARCH_X86_64
> +static inline uint32_t
> +crc32c_sse42_u64(uint64_t data, uint64_t init_val)
> +{
> + __asm__ volatile(
> + "crc32q %[data], %[init_val];"
> + : [init_val] "+r" (init_val)
> + : [data] "rm" (data));
> + return init_val;
> +}
> +#else
> +static inline uint32_t
> +crc32c_sse42_u64(__rte_unused uint64_t data,
> + __rte_unused uint64_t init_val)
> +{
return crc32c_2words(data, init_val);
> + return 0;
> +}
> +#endif
>
> #define CRC32_SW(1U << 0)
> #define CRC32_SSE42 (1U << 1)
> --
> 1.9.3
[dpdk-dev] [PATCH 00/10] eal: rte_tailq api cleanup
Hi David, I have verified this patch working with ivshmem and vfio driver. Testing environment: Commit: 0a530f0d58b0304d3f7515bb14f81fd2b6e6931e OS: Fedora20(3.11.10-301.fc20.x86_64) GCC: gcc version 4.8.3 20140911 QEMU: 1.5.2 with additional ivshmem patch NIC: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of David Marchand > Sent: Thursday, March 12, 2015 1:44 PM > To: Tetsuya Mukawa; Mcnamara, John > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH 00/10] eal: rte_tailq api cleanup > > Hello John, Tetsuya, > > On Thu, Mar 12, 2015 at 3:05 AM, Tetsuya Mukawa wrote: > > > On 2015/03/12 7:25, Mcnamara, John wrote: > > > Here we go, it is pretty vanilla but I sure you will get other data > > points by morning: > > > > > > $ uname -a > > > Linux sie-lab-214-036.ir.intel.com 3.6.10-4.fc18.x86_64 > > > #1 SMP Tue Dec 11 18:01:27 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux > > > > > > UIO with testpmd and skeleton forwarding app > > > > I've checked the patch on following environments, and make sure it works > > fine. > > > > - igb_uio: > > - vfio: > > - uio_pci_generic > > Tested on Ubuntu14.04 (3.13.0-30-generic) with e1000 PMD. > > > > - nic_uio > > Tested on FreeBSD 10.1-RELEASE #0 r274401 with e1000 PMD. > > > > Ok, good. > Big thanks to both of you :-). > > The only case remaining would be ivshmem. > > > -- > David Marchand
[dpdk-dev] [PATCH v8 00/10] 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 x86_64-native-linuxapp-gcc configuration - Total 6 cases, 6 passed, 0 failed - Case: vxlan_ipv4_detect Description: Check testpmd can receive and detect vxlan packet Command / instruction: Start testpmd with vxlan enabled and rss disabled testpmd -c -n 4 -- -i --tunnel-type=1 --disable-rss --rxq=4 --txq=4 --nb-cores=8 --nb-ports=2 Enable VxLAN on both ports and UDP dport setting to 4789 testpmd>rx_vxlan_port add 4789 0 testpmd>rx_vxlan_port add 4789 1 Set forward type to rxonly and enable detail log output testpmd>set fwd rxonly testpmd>set verbose 1 testpmd>start Send packets with udp/tcp/sctp inner L4 data Expected test result: testpmd can receive the vxlan packet with different inner L4 data and detect whether the packet is vxlan packet - Case: vxlan_ipv6_detect Description: Check testpmd can receive and detect ipv6 vxlan packet Command / instruction: Start testpmd with vxlan enabled and rss disabled testpmd -c -n 4 -- -i --tunnel-type=1 --disable-rss --rxq=4 --txq=4 --nb-cores=8 --nb-ports=2 Enable VxLAN on both ports and UDP dport setting to 4789 testpmd>rx_vxlan_port add 4789 0 testpmd>rx_vxlan_port add 4789 1 Set forward type to rxonly and enable detail log output testpmd>set fwd rxonly testpmd>set verbose 1 testpmd>start Send vxlan packets with outer IPv6 header and inner IPv6 header. Expected test result: testpmd can receive the vxlan packet with different inner L4 data and detect whether the packet is IPv6 vxlan packet - Case: vxlan_ipv4_checksum_offload Description: Check testpmd can offload vxlan checksum and forward the packet Command / instruction: Start testpmd with vxlan enabled and rss disabled. testpmd -c -n 4 -- -i --tunnel-type=1 --disable-rss --rxq=4 --txq=4 --nb-cores=8 --nb-ports=2 Enable VxLAN on both ports and UDP dport setting to 4789 testpmd>rx_vxlan_port add 4789 0 testpmd>rx_vxlan_port add 4789 1 Set csum packet forwarding mode and enable verbose log. testpmd>set fwd csum testpmd>set verbose 1 testpmd>start Enable outer IP,UDP,TCP,SCTP and inner IP,UDP checksum offload when inner L4 protocal is UDP. testpmd>tx_checksum set 0 0xf3 Enable outer IP,UDP,TCP,SCTP and inner IP,TCP,SCTP checksum offload when inner L4 protocal is TCP or SCTP. testpmd>tx_checksum set 0 0xfd Send ipv4 vxlan packet with invalid outer/inner l3 or l4 checksum. Expected test result: testpmd can forwarded vxlan packet and the checksum is corrected. The chksum error counter also increased. - Case: vxlan_ipv6_checksum_offload Description: Check testpmd can offload ipv6 vxlan checksum and forward the packet Command / instruction: Start testpmd with vxlan enabled and rss disabled. testpmd -c -n 4 -- -i --tunnel-type=1 --disable-rss --rxq=4 --txq=4 --nb-cores=8 --nb-ports=2 Enable VxLAN on both ports and UDP dport setting to 4789 testpmd>rx_vxlan_port add 4789 0 testpmd>rx_vxlan_port add 4789 1 Set csum packet forwarding mode and enable verbose log. testpmd>set fwd csum testpmd>set verbose 1 testpmd>start Enable outer IP,UDP,TCP,SCTP and inner IP,UDP checksum offload when inner L4 protocal is UDP. testpmd>tx_checksum set 0 0xf3 Enable outer IP,UDP,TCP,SCTP and inner IP,TCP,SCTP checksum offload when inner L4 protocal is TCP or SCTP. testpmd>tx_checksum set 0 0xfd Send ipv6 vxlan packet with invalid outer/inner l3 or l4 checksum. Expected test result: testpmd can forwarded vxlan packet and the checksum is corrected. The chksum error counter also increased. - Case: tunnel_filter Description: Check FVL vxlan tunnel filter function work with testpmd. Command / instruction: Start testpmd with vxlan enabled and rss disabled. testpmd -c -n 4 -- -i --tunnel-type=1 --disable-rss --rxq=4 --txq=4 --nb-cores=8 --nb-ports=2 Enable VxLAN on both ports and UDP dport setting to 4789 testpmd>rx_vxlan_port add 4789 0 testpmd>rx_vxlan_port add 4 Set rxonly forwarding mode and enable verbose log. testpmd>set fwd rxonly testpmd>set verbose
[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 x86_64-native-linuxapp-gcc configuration - Total 6 cases, 6 passed, 0 failed - Case: vxlan_ipv4_detect Description: Check testpmd can receive and detect vxlan packet Command / instruction: Start testpmd with vxlan enabled and rss disabled testpmd -c -n 4 -- -i --tunnel-type=1 --disable-rss --rxq=4 --txq=4 --nb-cores=8 --nb-ports=2 Enable VxLAN on both ports and UDP dport setting to 4789 testpmd>rx_vxlan_port add 4789 0 testpmd>rx_vxlan_port add 4789 1 Set forward type to rxonly and enable detail log output testpmd>set fwd rxonly testpmd>set verbose 1 testpmd>start Send packets with udp/tcp/sctp inner L4 data Expected test result: testpmd can receive the vxlan packet with different inner L4 data and detect whether the packet is vxlan packet. - Case: vxlan_ipv6_detect Description: Check testpmd can receive and detect ipv6 vxlan packet Command / instruction: Start testpmd with vxlan enabled and rss disabled testpmd -c -n 4 -- -i --tunnel-type=1 --disable-rss --rxq=4 --txq=4 --nb-cores=8 --nb-ports=2 Enable VxLAN on both ports and UDP dport setting to 4789 testpmd>rx_vxlan_port add 4789 0 testpmd>rx_vxlan_port add 4789 1 Set forward type to rxonly and enable detail log output testpmd>set fwd rxonly testpmd>set verbose 1 testpmd>start Send vxlan packets with outer IPv6 header and inner IPv6 header. Expected test result: testpmd can receive the vxlan packet with different inner L4 data and detect whether the packet is IPv6 vxlan packet. - Case: vxlan_ipv4_checksum_offload Description: Check testpmd can offload vxlan checksum and forward the packet Command / instruction: Start testpmd with vxlan enabled and rss disabled. testpmd -c -n 4 -- -i --tunnel-type=1 --disable-rss --rxq=4 --txq=4 --nb-cores=8 --nb-ports=2 Enable VxLAN on both ports and UDP dport setting to 4789 testpmd>rx_vxlan_port add 4789 0 testpmd>rx_vxlan_port add 4789 1 Set csum packet forwarding mode and enable verbose log. testpmd>set fwd csum testpmd>set verbose 1 testpmd>start Enable outer IP,UDP,TCP,SCTP and inner IP,UDP checksum offload when inner L4 protocal is UDP. testpmd>tx_checksum set 0 0xf3 Enable outer IP,UDP,TCP,SCTP and inner IP,TCP,SCTP checksum offload when inner L4 protocal is TCP or SCTP. testpmd>tx_checksum set 0 0xfd Send ipv4 vxlan packet with invalid outer/inner l3 or l4 checksum. Expected test result: testpmd can forwarded vxlan packet and the checksum is corrected. The chksum error counter also increased. - Case: vxlan_ipv6_checksum_offload Description: Check testpmd can offload ipv6 vxlan checksum and forward the packet Command / instruction: Start testpmd with vxlan enabled and rss disabled. testpmd -c -n 4 -- -i --tunnel-type=1 --disable-rss --rxq=4 --txq=4 --nb-cores=8 --nb-ports=2 Enable VxLAN on both ports and UDP dport setting to 4789 testpmd>rx_vxlan_port add 4789 0 testpmd>rx_vxlan_port add 4789 1 Set csum packet forwarding mode and enable verbose log. testpmd>set fwd csum testpmd>set verbose 1 testpmd>start Enable outer IP,UDP,TCP,SCTP and inner IP,UDP checksum offload when inner L4 protocal is UDP. testpmd>tx_checksum set 0 0xf3 Enable outer IP,UDP,TCP,SCTP and inner IP,TCP,SCTP checksum offload when inner L4 protocal is TCP or SCTP. testpmd>tx_checksum set 0 0xfd Send ipv6 vxlan packet with invalid outer/inner l3 or l4 checksum. Expected test result: testpmd can forwarded vxlan packet and the checksum is corrected. The chksum error counter also increased. - Case: tunnel_filter Description: Check FVL vxlan tunnel filter function work with testpmd. Command / instruction: Start testpmd with vxlan enabled and rss disabled. testpmd -c -n 4 -- -i --tunnel-type=1 --disable-rss --rxq=4 --txq=4 --nb-cores=8 --nb-ports=2 Enable VxLAN on both ports and UDP dport setting to 4789 testpmd>rx_vxlan_port add 4789 0 testpmd>rx_vxlan_port add 4 Set rxonly forwarding mode and enable verbose log. testpmd>set fwd rxonly testpmd>set
[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 GCC: gcc version 4.8.3 20140911 CPU: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz NIC: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] Commit ID: 455d09e54b92a4626e178b020fe9c23e43ede3f7 Detailed Testing information DPDK SW Configuration: Default x86_64-native-linuxapp-gcc configuration Test Result Summary:Total 2 cases, 2 passed, 0 failed Test Case - name: Continuous Mode Performance Test Case - Description: Measure continuous mode cycles/packet in NIC loopback mode Test Case -command / instruction: Set stream control mode to continuous RTE>>set_rxtx_sc continuous Choose rx/tx pair between vector|scalar|full|hybrid RTE>>set_rxtx_mode vector Start pmd performance measurement RTE>>pmd_perf_autotest Test Case - expected test result: Test result is OK and output cycle number for each packet. Test Case - name: Burst Mode Performance Test Case - Description: Measure burst mode cycles/packet in NIC loopback mode Test Case -command / instruction: Start unit test sample Set stream control mode to poll_before_xmit or poll_after_xmit RTE>>set_rxtx_sc poll_before_xmit Start pmd performance measurement RTE>>pmd_perf_autotest Start pmd performance measurement RTE>>pmd_perf_autotest Test Case - expected test result: Test result is OK and output cycle number for each packet. > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Cunming Liang > Sent: Monday, October 20, 2014 4:14 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v3 0/2] app/test: unit test to measure cycles per > packet > > v3 update: > # Codes refine according to the feedback. > 1. add ether_format_addr to rte_ether.h > 2. fix typo in code comments. > 3. %lu to %PRIu64, fixing 32-bit targets compilation err > # merge 2 small incremental patches to the first one. > The whole unit test as a single patch in [PATCH v3 2/2] > # rebase code to the latest master > > v2 update: > Rebase code to the latest master branch. > > Tested-by: Zhaochen Zhan > This patch has been verified on ixgbe and it is ready to be integrated to > dpdk.org. > For e1000 and i40e, lacking loopback supporting, this patch can't support > them for now. > > -- > > It provides unit test to measure cycles/packet in NIC loopback mode. > It simply gives the average cycles of IO used per packet without test > equipment. > When doing the test, make sure the link is UP. > > There's two stream control mode support, one is continues, another is burst. > The former continues to forward the injected packets until reaching a certain > amount of number. > The latter one stop when all the injected packets are received. > In burst stream, now measure two situations, with or without desc. cache > conflict. > By default, it runs in continues stream mode to measure the whole rxtx. > > Usage Example: > 1. Run unit test app in interactive mode > app/test -c f -n 4 -- -i > 2. Set stream control mode, by default is continuous > set_rxtx_sc [continuous|poll_before_xmit|poll_after_xmit] > 3. If choose continuous stream, there are another two options can configure > 3.1 choose rx/tx pair, default is vector > set_rxtx_mode [vector|scalar|full|hybrid] > Note: To get acurate scalar fast, plz choose 'vector' or 'hybrid' > without > INC_VEC=y in config > 3.2 choose the area of masurement, default is rxtx > set_rxtx_anchor [rxtx|rxonly|txonly] > 4. Run and wait for the result > pmd_perf_autotest > > For who simply just want to see how much cycles cost per packet. > Compile DPDK, Run 'app/test', and type 'pmd_perf_autotest', that's it. > Nothing else needs to configure. > Using other options when you understand and what to measures more. > > *** BLURB HERE *** > > Cunming Liang (2): > app/test: allow to create packets in different sizes > app/test: measure the cost of rx/tx routines by cycle number > > app/test/Makefile |1 + > app/test/commands.c | 111 + >
[dpdk-dev] [PATCH v4 00/10] VM Power Management
Verify the frequency of physical CPU has been scaled up correctly vmpower> get_cpu_freq 1 Check other CPUs' frequency is not affected by actions above Check if the other VM works fine (if they use different CPUs) Repeat above actions several times Test Case - expected test result: Frequency for VM's core can be scaling up normally Test Case - name: VM Scale CPU Frequency to Min Test Case - Description: Check vm power management support VM configure self cores frequency to minimum Test Case -command / instruction: Setup VM power management environment Send cpu frequency scale to minimum hints vmpower(guest)> set_cpu_freq 0 min Verify the frequency of physical CPU has been scale to min correctly vmpower> get_cpu_freq 1 Core 1 frequency: 120 Check other CPUs' frequency is not affected by actions above check if the other VM works fine (if they use different CPUs) Test Case - expected test result: Frequency for VM's core can be scaling to minimum normally Test Case - name: VM Scale CPU Frequency to Max Test Case - Description: Check vm power management support VM configure self cores frequency to maximum Test Case -command / instruction: Setup VM power management environment Send cpu frequency scale to maximum hints vmpower(guest)> set_cpu_freq 0 max Verify the frequency of physical CPU has been scale to max correctly vmpower> get_cpu_freq 1 Core 1 frequency: 280 Check other CPUs' frequency is not affected by actions above check if the other VM works fine (if they use different CPUs) Test Case - expected test result: Frequency for VM's core can be scaling to maximum normally Test Case - name: VM Power Management Multi VMs Test Case - Description: Check vm power management support multiple VMs Test Case -command / instruction: Setup VM power management environment for VM1 Setup VM power management environment for VM2 Run power-manager in Host ./build/vm_power_mgr -c 0x3 -n 4 Startup VM1 and VM2 Add VM1 in host and check vm_power_mgr can get frequency normally vmpower> add_vm vmpower> add_channels all vmpower> get_cpu_freq Add VM2 in host and check vm_power_mgr can get frequency normally vmpower> add_vm vmpower> add_channels all vmpower> get_cpu_freq Check VM1 and VM2 cpu frequency can by modified by guest_cli Poweroff VM2 and remove VM2 from host vm_power_mgr vmpower> rm_vm Test Case - expected test result: VM power management supported multiple VMs add and remove > -Original Message- > From: Carew, Alan > Sent: Monday, October 13, 2014 3:36 AM > To: dev at dpdk.org > Cc: Liu, Yong > Subject: [PATCH v4 00/10] VM Power Management > > Virtual Machine Power Management. > > The following patches add two DPDK sample applications and an alternate > implementation of librte_power for use in virtualized environments. > The idea is to provide librte_power functionality from within a VM to address > the lack of MSRs to facilitate frequency changes from within a VM. > It is ideally suited for Haswell which provides per core frequency scaling. > > The current librte_power affects frequency changes via the acpi-cpufreq > 'userspace' power governor, accessed via sysfs. > > General Overview:(more information in each patch that follows). > The VM Power Management solution provides two components: > > 1)VM: Allows for the a DPDK application in a VM to reuse the librte_power > interface. Each lcore opens a Virto-Serial endpoint channel to the host, > where the re-implementation of librte_power simply forwards the requests > for > frequency change to a host based monitor. The host monitor itself uses > librt
[dpdk-dev] [PATCH v5 0/8]Support VxLAN on Fortville
0 0xfd Send ipv6 vxlan packet with invalid outer/inner l3 or l4 checksum first. Then check forwarded packet checksum is corrected and there's chksum error counter increased. Test Case - expected test result: testpmd can forwarded vxlan packet and the checksum is corrected. The chksum error counter also increased. Test Case - name: tunnel_filter Test Case - Description: Check FVL vxlan tunnel filter function work with testpmd. Test Case -command / instruction: Start testpmd with vxlan enabled and rss disabled. testpmd -c -n 4 -- -i --tunnel-type=1 --disble-rss --rxq=4 --txq=4 --nb-cores=8 --nb-ports=2 Set rxonly forwarding mode and enable verbose log. testpmd>set fwd rxonly testpmd>set verbose 1 testpmd>start Add cloud filter with specified inner dst mac and inner vlan. testpmd>tunnel_filter add 0 11:22:33:44:55:66 00:00:20:00:00:01 192.168.2.2 1 vxlan imac-ivlan 1 3 Add cloud filter with specified inner dst mac,inner vlan and tunnel id. testpmd>tunnel_filter add 0 11:22:33:44:55:66 00:00:20:00:00:01 192.168.2.2 1 vxlan imac-ivlan-tenid 1 3 Add cloud filter with specified inner dst mac and tunnel id. testpmd>tunnel_filter add 0 11:22:33:44:55:66 00:00:20:00:00:01 192.168.2.2 1 vxlan imac-tenid 1 3 Add cloud filter with specified inner dst mac. testpmd>tunnel_filter add 0 11:22:33:44:55:66 00:00:20:00:00:01 192.168.2.2 1 vxlan imac 1 3 Add cloud filter with specified outer dst mac, inner dst mac and tunnel id. testpmd>tunnel_filter add 0 11:22:33:44:55:66 00:00:20:00:00:01 192.168.2.2 1 vxlan omac-imac-tenid 1 3 Send vxlan packet matched the specified fields. Test Case - expected test result: testpmd can received the vxlan packet on the assigned queue 3. Test Case - name: tunnel_filter_invalid Test Case - Description: Check FVL vxlan tunnel filter invalid command cannot accepted by testpmd Test Case -command / instruction: Start testpmd with vxlan enabled and rss disabled. testpmd -c -n 4 -- -i --tunnel-type=1 --disble-rss --rxq=4 --txq=4 --nb-cores=8 --nb-ports=2 Add Clould filter with invalid Mac address. Add Clould filter with invalid ip address. Add Clould filter with invalid vlan. Add Clould filter with invalid vni. Add Clould filter with invalid queue id. Test Case - expected test result: testpmd will report the parameter is invalid. > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Liu, Yong > Sent: Saturday, October 11, 2014 3:29 PM > To: Liu, Jijiang; dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v5 0/8]Support VxLAN on Fortville > > Basic Information > Patch name Support VxLAN on Fortville > Brief description about test purposeVerify vxlan checksum > detect/offload and tunnel filter work fine. > Test Flag Tested-by > Tester name yong.liu at intel.com > Test environment > - OS Environment > - Compilation (GCC) > - Hardware Info (CPU & NIC) > - Virtualization environment /Configure 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] > > > > Test Tool Chain information N/A > Commit ID ee1a5470faa751c1fd07d23b86659fe7a68fd251 > Detailed Testing informationDPDK SW Configuration Default x86_64- > native-linuxapp-gcc configuration > Test Result Summary Total 6 cases, 6 passed, 0 failed > Test Case - namevxlan_ipv4_detect > Test Case - Description Check testpmd can receive and detect vxlan > packet > Test Case -test sample/application Start testpmd with vxlan > enabled > and rss disabled. > testpmd -c -n 4 -- -i --tunnel-type=1 --disble-rss --rxq=4 --txq=4 --nb- > cores=8 --nb-ports=2 > > Set forward type to rxonly and enable verbose log. > testpmd>set fwd rxonly > testpmd>set verbose 1 > testpmd>start > > Send vxlan packets with udp|tcp|sctp inner L4 data > Test Ca
[dpdk-dev] [PATCH v5 0/8]Support VxLAN on Fortville
Basic Information Patch name Support VxLAN on Fortville Brief description about test purposeVerify vxlan checksum detect/offload and tunnel filter work fine. Test Flag Tested-by Tester name yong.liu at intel.com Test environment - OS Environment - Compilation (GCC) - Hardware Info (CPU & NIC) - Virtualization environment /Configure 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] Test Tool Chain information N/A Commit ID ee1a5470faa751c1fd07d23b86659fe7a68fd251 Detailed Testing informationDPDK SW Configuration Default x86_64-native-linuxapp-gcc configuration Test Result Summary Total 6 cases, 6 passed, 0 failed Test Case - namevxlan_ipv4_detect Test Case - Description Check testpmd can receive and detect vxlan packet Test Case -test sample/application Start testpmd with vxlan enabled and rss disabled. testpmd -c -n 4 -- -i --tunnel-type=1 --disble-rss --rxq=4 --txq=4 --nb-cores=8 --nb-ports=2 Set forward type to rxonly and enable verbose log. testpmd>set fwd rxonly testpmd>set verbose 1 testpmd>start Send vxlan packets with udp|tcp|sctp inner L4 data Test Case -command / instruction Test Case - expected test resulttestpmd can receive the vxlan packet with different inner L4 data and detect whether the packet is vxlan packet Test Case - namevxlan_ipv6_detect Test Case - Description Check testpmd can receive and detect ipv6 vxlan packet Test Case -test sample/application Start testpmd with vxlan enabled and rss disabled. testpmd -c -n 4 -- -i --tunnel-type=1 --disble-rss --rxq=4 --txq=4 --nb-cores=8 --nb-ports=2 Set forward type to rxonly and enable verbose log. testpmd>set fwd rxonly testpmd>set verbose 1 testpmd>start Send vxlan packets with outer IPv6 header and inner IPv6 header. Test Case -command / instruction Test Case - expected test resulttestpmd can receive the vxlan packet with different inner L4 data and detect whether the packet is IPv6 vxlan packet Test Case - namevxlan_ipv4_checksum_offload Test Case - Description Check testpmd can offload vxlan checksum and forward the packet Test Case -test sample/application Start testpmd with vxlan enabled and rss disabled. testpmd -c -n 4 -- -i --tunnel-type=1 --disble-rss --rxq=4 --txq=4 --nb-cores=8 --nb-ports=2 Set csum packet forwarding mode and enable verbose log. testpmd>set fwd csum testpmd>set verbose 1 testpmd>start Enable outer IP,UDP,TCP,SCTP and inner IP,UDP checksum offload when inner L4 protocal is UDP. testpmd>tx_checksum set 0 0xf3 Enable outer IP,UDP,TCP,SCTP and inner IP,TCP,SCTP checksum offload when inner L4 protocal is TCP or SCTP. testpmd>tx_checksum set 0 0xfd Send ipv4 vxlan packet with invalid outer/inner l3 or l4 checksum first. Then check forwarded packet checksum is corrected and there's chksum error counter increased. Test Case -command / instruction Test Case - expected test resulttestpmd can forwarded vxlan packet and the checksum is corrected. The chksum error counter also increased. Test Case - namevxlan_ipv6_checksum_offload Test Case - Description Check testpmd can offload ipv6 vxlan checksum and forward the packet Test Case -test sample/application Start testpmd with vxlan enabled and rss disabled. testpmd -c -n 4 -- -i --tunnel-type=1 --disble-rss --rxq=4 --txq=4 --nb-cores=8 --nb-ports=2 Set csum packet forwarding mode and enable verbose log. testpmd>set fwd csum testpmd>set verbose 1 testpmd>start Enable outer IP,UDP,TCP,SCTP and inner IP,UDP checksum offload when inner L4 protocal is UDP. testpmd>tx_checksum set 0 0xf3 Enable outer IP,UDP,TCP,SCTP and inner IP,TCP,SCTP checksum offload when inner L4 protocal is TCP or SCTP. testpmd>tx_checksum set 0 0xfd Send ipv6 vxlan packet with invalid outer/inner l3 or l4 checksum first. Then check forwarded packet checksum is corrected and there's chksum error counter increased. Test Case -command / instruction Test Case - expected test resulttestpmd can forwarded vxlan packet and the checksum is corrected. The chksum error counter also increased. Test Case - nametunnel_filter Test Case - Description Check FVL vxlan tunnel filter function work on testpmd Test Case -test sample/application Start testpmd with vxlan enabled and rss disabled. testpmd -c -n 4 -- -i --tunnel-type=1 --disble-rss --rxq=4 --txq=4 --nb-cores=8 --nb-ports=2 Set rxonly forwarding mode and enable verbose log. testpmd>set fwd rxonly testpmd>set verbose 1 testpmd>start Add cloud filter with
[dpdk-dev] [PATCH 0/5]support filter of unicast and multicast MAC address for VF on Fortville
Tested-by: Liu Yong This patch set has been tested by Intel. Please see information as the following: Host: OS : Fedora 20 x86_64 Kernel : 3.11.10-301 GCC: 4.8.3 CPU: Intel Xeon CPU E5-2680 v2 @ 2.80GHz NIC : 2*40G (8086:1583) Qemu: 1.6.2 libvirt : 1.1.3 Guest: OS : Fedora 20 x86_64 Kernel : 3.11.10-301 GCC : 4.8.3 We verified perfect and hash match filter of unicast and multicast MAC address for VF work normally on FVL. > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jijiang Liu > Sent: Tuesday, September 23, 2014 11:30 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH 0/5]support filter of unicast and multicast MAC > address for VF on Fortville > > The patch set enhances MACVLAN filter configurability and supports perfect > and hash match filter of unicast > and multicast MAC address for VF on Fortville. > > It mainly includes: > - Use new filter mechanism discussed at > http://dpdk.org/ml/archives/dev/2014-September/005179.html. > - Enhance MACVLAN filter to be configurable. Now the following options are > configurable: >1. Perfect match of MAC address >2. Perfect match of MAC address and VLAN ID >3. Hash match of MAC address >4. Hash match of MAC address and perfect match of VLAN ID >5. To Queue: use MAC and VLAN to point to a queue > - Support perfect and hash match of unicast and multicast MAC address for > VF for i40e > > > jijiangl (5): > Use new filter framework > Add new definations for MACVLAN filter enhancement in rte_eth_ctrl.h file > Change parameters of MAC/VLAN filter to be configurable > Add VF MACVLAN filter handle for i40e > Test VF MACVLAN filter for i40e > > app/test-pmd/cmdline.c| 115 +- > lib/librte_ether/Makefile |1 + > lib/librte_ether/rte_eth_ctrl.h | 104 > lib/librte_ether/rte_ethdev.c | 33 > lib/librte_ether/rte_ethdev.h | 48 ++- > lib/librte_pmd_i40e/i40e_ethdev.c | 321 > - > lib/librte_pmd_i40e/i40e_ethdev.h | 18 ++- > lib/librte_pmd_i40e/i40e_pf.c |7 +- > 8 files changed, 601 insertions(+), 46 deletions(-) > create mode 100644 lib/librte_ether/rte_eth_ctrl.h > > -- > 1.7.7.6
[dpdk-dev] [PATCH v2 00/10] VM Power Management
Tested-by: Liu Yong This patch set has been tested by Intel. Please see information as the following: Host: OS : Fedora 20 x86_64 Kernel : 3.11.10-301 GCC: 4.8.3 CPU: Intel Xeon CPU E5-2680 v2 @ 2.80GHz NIC : Intel Niantic 82599 Qemu: 1.6.2 Libvirt:1.1.3 Guest: OS : Fedora 20 x86_64 Kernel : 3.11.10-301 GCC: 4.8.3 We verified vm power management by unit test and function test. The detail information is listed below. vm power unit test Passed vm power channel connected Passed vm power frequency max Passed vm power frequency min Passed vm power frequency up Passed vm power frequency down Passed vm power l3fwd-powerPassed > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Alan Carew > Sent: Thursday, September 25, 2014 1:26 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v2 00/10] VM Power Management > > Virtual Machine Power Management. > > The following patches add two DPDK sample applications and an alternate > implementation of librte_power for use in virtualized environments. > The idea is to provide librte_power functionality from within a VM to address > the lack of MSRs to facilitate frequency changes from within a VM. > It is ideally suited for Haswell which provides per core frequency scaling. > > The current librte_power affects frequency changes via the acpi-cpufreq > 'userspace' power governor, accessed via sysfs. > > General Overview:(more information in each patch that follows). > The VM Power Management solution provides two components: > > 1)VM: Allows for the a DPDK application in a VM to reuse the librte_power > interface. Each lcore opens a Virto-Serial endpoint channel to the host, > where the re-implementation of librte_power simply forwards the requests > for > frequency change to a host based monitor. The host monitor itself uses > librte_power. > Each lcore channel corresponds to a > serial device '/dev/virtio-ports/virtio.serial.port.poweragent.' > which is opened in non-blocking mode. > While each Virtual CPU can be mapped to multiple physical CPUs it is > recommended that each vCPU should be mapped to a single core only. > > 2)Host: The host monitor is managed by a CLI, it allows for adding qemu/KVM > virtual machines and associated channels to the monitor, manually changing > CPU frequency, inspecting the state of VMs, vCPU to pCPU pinning and > managing > channels. > Host channel endpoints are Virto-Serial endpoints configured as AF_UNIX file > sockets which follow a specific naming convention > i.e /tmp/powermonitor/., > each channel has an 1:1 mapping to a VM endpoint > i.e. /dev/virtio-ports/virtio.serial.port.poweragent. > Host channel endpoints are opened in non-blocking mode and are monitored > via epoll. > Requests over each channel to change frequency are forwarded to the > original > librte_power. > > Channels must be manually configured as qemu-kvm command line arguments > or > libvirt domain definition(xml) e.g. > > > > >path='/tmp/powermonitor/.'/> > > > > Where multiple channels can be configured by specifying multiple > elements, by replacing , . > (port number) should be incremented by 1 for each new channel > element. > More information on Virtio-Serial can be found here: > http://fedoraproject.org/wiki/Features/VirtioSerial > To enable the Hypervisor creation of channels, the host endpoint directory > must be created with qemu permissions: > mkdir /tmp/powermonitor > chown qemu:qemu /tmp/powermonitor > > The host application runs on two separate lcores: > Core N) CLI: For management of Virtual Machines adding channels to Monitor > thread, > inspecting state and manually setting CPU frequency [PATCH 02/09] > Core N+1) Monitor Thread: An epoll based infinite loop that waits on channel > events > from VMs and calls the corresponding librte_power functions. > > A sample application is also provided to run on Virtual Machines, this > application provides a CLI to manually set the frequency of a > vCPU[PATCH 08/09] > > The current l3fwd-power sample application can also be run on a VM. > > Changes in V2: > Runtime selection of librte_power implementations. > Updated Unit tests to cover librte_power changes. > PATCH[0/3] was sent twice, again as PATCH[0/4] > Miscellaneous fixes. > > Alan Carew (10): > Channel Manager and Monitor for VM Power Management(Host). > VM Power Management CLI(Host). > CPU Freque
[dpdk-dev] [PATCH v2 0/7]]Support VxLAN on Fortville
Tested-by: Liu, Yong < yong.liu at intel.com> This patch set has been verified and ready to integrated into dpdk.org. Please refer to following information: Board: CrownPass OS: Fedora20 Kenrel: 3.15.8-200.fc20.x86_64 GCC: gcc version 4.8.3 NIC: Fortville Spirit Falls VxLAN cases Result tunnel_filter PASSED tunnel_filter_invalid PASSED vxlan_ipv4_checksum_offload PASSED vxlan_ipv4_detect PASSED vxlan_ipv6_checksum_offload PASSED vxlan_ipv6_detect PASSED > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jijiang Liu > Sent: Tuesday, August 26, 2014 3:31 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v2 0/7]]Support VxLAN on Fortville > > The patch set supports VxLAN on Fortville based on current mbuf structure. > When Bruce's new mbuf structure is done, there will be minor changes later. > > It includes: > - Support VxLAN packet identification by configuring tunneling UDP port. > - Support VxLAN packet filters. It uses MAC and VLAN to point >to a queue. The filter types supported include below: >1. Inner MAC and Inner VLAN ID >2. Inner MAC address, inner VLAN ID and tenant ID. >3. Inner MAC and tenant ID >4. Inner MAC address >5. Outer MAC address, tenant ID and inner MAC > - Support VxLAN TX checksum offload, which include outer L3(IP), inner L3(IP) > and inner L4(UDP,TCP and SCTP) > > Change notes: > > v2) > *Split the implementation of tunnel filter API into two patches. > *Change the name of the API rte_eth_dev_cloud_filter_set() as the > rte_eth_dev_tunnel_filter_set(). > > jijiangl (7): > Add VxLAN packet identification > Test VxLAN packet identification in testpmd > Add tunneled packet filter API > Test tunneled packet filter API in testpmd > Add VxLAN Tx checksum offload > Test VxLAN Tx checksum offload > > app/test-pmd/cmdline.c| 225 ++- > app/test-pmd/config.c |6 +- > app/test-pmd/csumonly.c | 194 +-- > app/test-pmd/parameters.c | 13 ++ > app/test-pmd/rxonly.c | 49 ++ > app/test-pmd/testpmd.c|8 + > app/test-pmd/testpmd.h|5 + > lib/librte_ether/rte_ethdev.c | 113 ++ > lib/librte_ether/rte_ethdev.h | 148 ++ > lib/librte_ether/rte_ether.h | 10 ++ > lib/librte_mbuf/rte_mbuf.h|4 + > lib/librte_pmd_i40e/i40e_ethdev.c | 311 > - > lib/librte_pmd_i40e/i40e_ethdev.h |5 + > lib/librte_pmd_i40e/i40e_rxtx.c | 58 +++- > 14 files changed, 1124 insertions(+), 25 deletions(-) > > -- > 1.7.7.6
