[dpdk-dev] [PATCH v4 0/4] NIC filters support for generic filter

[Cao, Waterman]

Tested-by: Waterman Cao 

This patch includes 4 files, and has been tested by Intel.
Please see test environment information as the following:
Fedora 20 x86_64, Linux Kernel 3.11.10-301, GCC 4.8.2  Intel Xeon CPU E5-2680 
v2 @ 2.80GHz
NIC: Intel Niantic 82599, Intel i350, Intel 82580 and Intel 82576
We verified ethertype filter, 2-tuple filter, 5-tuple filter, flex filter and 
SYN filter with above NICs.
 Total casesPassed   Failed   
 27   25   2
Failures were caused by HW issues, no impact on functionality.
Please see example: how to distribute specific packet to assigned queue.
  Firstly, launch testpmd firstly, then run the following command:
  ---add syn filter ---
  testpmd> add_syn_filter (port_id) priority (high|low) queue (queue_id)
  ---get syn filter info ---
  testpmd> get_syn_filter (port_id)
  ---remove syn filter ---
  testpmd> remove_syn_filter (port_id)

[dpdk-dev] [PATCH] kni: compatibility with RHEL 7

[Cao, Waterman]

Hi Thomas,

OK, we will verify this patch tomorrow.

Waterman 
>
>-Original Message-
>From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] 
>Sent: Wednesday, June 25, 2014 6:05 PM
>To: Cao, Waterman
>Cc: dev at dpdk.org; Hiroshi Shimamoto; Hayato Momma
>Subject: Re: [dpdk-dev] [PATCH] kni: compatibility with RHEL 7
>
>Hi Waterman,
>
>2014-06-12 09:35, Hiroshi Shimamoto:
>> 2014-06-12 09:18, Cao, Waterman:
>> >   Can you give details about Linux Kernel version and complier version?
>> >   Because we tried to build code in the Redhat 7.0 before, but we don't
>> >   meet this issue. Please see information as the following:
>> >   Linux kernel 3.10.0-54.0.1.el7.x86_64
>> >   RHEL70BETA_64GCC 4.8.2  ICC: 14.0.0
>> 
>> Yes,
>> 
>> Linux REHEL7RC-1 3.10.0-121.el7.x86_64 #1 SMP Tue Apr 8 10:48:19 EDT 
>> 2014
>> x86_64 x86_64 x86_64 GNU/Linux gcc version 4.8.2 20140120 (Red Hat
>> 4.8.2-16) (GCC)
>> 
>> I got the below error;
>> /path/to/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h:3851:1: error:
>> conflicting types for ?skb_set_hash? skb_set_hash(struct sk_buff *skb,
>> __u32 hash, __always_unused int type)
>> 
>> /usr/src/kernels/3.10.0-121.el7.x86_64/include/linux/skbuff.h:762:1: note:
>> previous definition of ?skb_set_hash? was here skb_set_hash(struct 
>> sk_buff *skb, __u32 hash, enum pkt_hash_types type)
>
>Could you confirm this fix is needed and acknowledge it?
>Thanks
>
>
>> > -Original Message-
>> > 
>> > >From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Hiroshi 
>> > >Shimamoto
>> > >Sent: Thursday, June 12, 2014 4:10 PM
>> > >To: dev at dpdk.org
>> > >Cc: Hayato Momma
>> > >Subject: [dpdk-dev] [PATCH] kni: compatibility with RHEL 7
>> > >
>> > >From: Hiroshi Shimamoto 
>> > >
>> > >Compilation in RHEL7 is failed. This fixes the build issue.
>> > >
>> > >RHEL7 has skb_set_hash, the kernel version is 3.10 though.
>> > >Don't define skb_set_hash for RHEL7.
>> > >
>> > >Signed-off-by: Hiroshi Shimamoto 
>> > >Reviewed-by: Hayato Momma 
>> > >---
>> > >
>> > > lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h | 5 +
>> > > 1 file changed, 5 insertions(+)
>> > >
>> > >diff --git a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
>> > >b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h index
>> > >4c27d5d..b4de6e2 100644
>> > >--- a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
>> > >+++ b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
>> > >@@ -3843,6 +3843,9 @@ static inline struct sk_buff 
>> > >*__kc__vlan_hwaccel_put_tag(struct sk_buff *skb,  #endif /* >= 
>> > >3.10.0>
>> > */
>> > 
>> > > #if ( LINUX_VERSION_CODE < KERNEL_VERSION(3,14,0) )
>> > >
>> > >+
>> > >+#if (!(RHEL_RELEASE_CODE && RHEL_RELEASE_CODE >=
>> > >+RHEL_RELEASE_VERSION(7,0)))
>> > >+
>> > >
>> > > #ifdef NETIF_F_RXHASH
>> > > #define PKT_HASH_TYPE_L3 0
>> > > static inline void
>> > >
>> > >@@ -3851,6 +3854,8 @@ skb_set_hash(struct sk_buff *skb, __u32 hash, 
>> > >__always_unused int type)> >
>> > >  skb->rxhash = hash;
>> > > 
>> > > }
>> > > #endif /* NETIF_F_RXHASH */
>> > >
>> > >+#endif /* < RHEL7 */
>> > >+
>> > >
>> > > #endif /* < 3.14.0 */
>> > > 
>> > > #endif /* _KCOMPAT_H_ */
>> > >
>> > >--
>> > >1.9.1
>
>
>--
>Thomas
>

[dpdk-dev] [PATCH] kni: compatibility with RHEL 7

[Cao, Waterman]

Hi Hiroshi,

  Helin submitted one patch to fix compilation error in the redhat 6.4 and 6.5.
  Patch title is [dpdk-dev] [PATCH] kni: fix compile errors on Oracle Linux6.4 
and RHEL6.5
  With this patch, we don't meet this compilation error in latest RHEL 7.0 
  Can you download latest DPDK code, and try to compile with this patch in RHEL 
7.0 again?

Thanks
Waterman 


>-Original Message-
>From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] 
>Sent: Wednesday, June 25, 2014 6:05 PM
>To: Cao, Waterman
>Cc: dev at dpdk.org; Hiroshi Shimamoto; Hayato Momma
>Subject: Re: [dpdk-dev] [PATCH] kni: compatibility with RHEL 7
>
>Hi Waterman,
>
>2014-06-12 09:35, Hiroshi Shimamoto:
>> 2014-06-12 09:18, Cao, Waterman:
>> >   Can you give details about Linux Kernel version and complier version?
>> >   Because we tried to build code in the Redhat 7.0 before, but we don't
>> >   meet this issue. Please see information as the following:
>> >   Linux kernel 3.10.0-54.0.1.el7.x86_64
>> >   RHEL70BETA_64GCC 4.8.2  ICC: 14.0.0
>> 
>> Yes,
>> 
>> Linux REHEL7RC-1 3.10.0-121.el7.x86_64 #1 SMP Tue Apr 8 10:48:19 EDT 
>> 2014
>> x86_64 x86_64 x86_64 GNU/Linux gcc version 4.8.2 20140120 (Red Hat
>> 4.8.2-16) (GCC)
>> 
>> I got the below error;
>> /path/to/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h:3851:1: error:
>> conflicting types for ?skb_set_hash? skb_set_hash(struct sk_buff *skb,
>> __u32 hash, __always_unused int type)
>> 
>> /usr/src/kernels/3.10.0-121.el7.x86_64/include/linux/skbuff.h:762:1: note:
>> previous definition of ?skb_set_hash? was here skb_set_hash(struct 
>> sk_buff *skb, __u32 hash, enum pkt_hash_types type)
>
>Could you confirm this fix is needed and acknowledge it?
>Thanks
>
>
>> > -Original Message-
>> > 
>> > >From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Hiroshi 
>> > >Shimamoto
>> > >Sent: Thursday, June 12, 2014 4:10 PM
>> > >To: dev at dpdk.org
>> > >Cc: Hayato Momma
>> > >Subject: [dpdk-dev] [PATCH] kni: compatibility with RHEL 7
>> > >
>> > >From: Hiroshi Shimamoto 
>> > >
>> > >Compilation in RHEL7 is failed. This fixes the build issue.
>> > >
>> > >RHEL7 has skb_set_hash, the kernel version is 3.10 though.
>> > >Don't define skb_set_hash for RHEL7.
>> > >
>> > >Signed-off-by: Hiroshi Shimamoto 
>> > >Reviewed-by: Hayato Momma 
>> > >---
>> > >
>> > > lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h | 5 +
>> > > 1 file changed, 5 insertions(+)
>> > >
>> > >diff --git a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
>> > >b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h index
>> > >4c27d5d..b4de6e2 100644
>> > >--- a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
>> > >+++ b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
>> > >@@ -3843,6 +3843,9 @@ static inline struct sk_buff 
>> > >*__kc__vlan_hwaccel_put_tag(struct sk_buff *skb,  #endif /* >= 
>> > >3.10.0>
>> > */
>> > 
>> > > #if ( LINUX_VERSION_CODE < KERNEL_VERSION(3,14,0) )
>> > >
>> > >+
>> > >+#if (!(RHEL_RELEASE_CODE && RHEL_RELEASE_CODE >=
>> > >+RHEL_RELEASE_VERSION(7,0)))
>> > >+
>> > >
>> > > #ifdef NETIF_F_RXHASH
>> > > #define PKT_HASH_TYPE_L3 0
>> > > static inline void
>> > >
>> > >@@ -3851,6 +3854,8 @@ skb_set_hash(struct sk_buff *skb, __u32 hash, 
>> > >__always_unused int type)> >
>> > >  skb->rxhash = hash;
>> > > 
>> > > }
>> > > #endif /* NETIF_F_RXHASH */
>> > >
>> > >+#endif /* < RHEL7 */
>> > >+
>> > >
>> > > #endif /* < 3.14.0 */
>> > > 
>> > > #endif /* _KCOMPAT_H_ */
>> > >
>> > >--
>> > >1.9.1
>
>
>--
>Thomas

[dpdk-dev] [PATCH] kni: compatibility with RHEL 7

[Cao, Waterman]

Hi Hiroshi,

We found that there is a little difference between your environment and ours.
Our Env:
Linux RHEL-7.0-64 3.10.0-54.0.1.el7.x86_64 #1 SMP Tue Nov 26 16:51:22 EST 2013 
x86_64 x86_64 x86_64 GNU/Linux gcc : gcc version 4.8.2 20131106 (Red Hat 
4.8.2-3) (GCC)
Your Env:
Linux RHEL7-1 3.10.0-123.el7.x86_64 #1 SMP Mon May 5 11:16:57 EDT 2014 x86_64 
x86_64 x86_64 GNU/Linux $ gcc -v gcc version 4.8.2 20140120 (Red Hat 4.8.2-16) 
(GCC)

We verified RHEL7 beta version already, and will download latest RHEL7 and try 
it again.

Waterman 

-Original Message-
>From: Hiroshi Shimamoto [mailto:h-shimamoto at ct.jp.nec.com] 
>Sent: Monday, June 30, 2014 12:46 PM
>To: Hiroshi Shimamoto; Cao, Waterman; Thomas Monjalon; dev at dpdk.org; Hayato 
>Momma
>Subject: RE: [dpdk-dev] [PATCH] kni: compatibility with RHEL 7
>
>Hi,
>
>> Subject: Re: [dpdk-dev] [PATCH] kni: compatibility with RHEL 7
>> 
>> Hi,
>> 
>> > Subject: RE: [dpdk-dev] [PATCH] kni: compatibility with RHEL 7
>> >
>> > Hi Hiroshi,
>> >
>> >   Helin submitted one patch to fix compilation error in the redhat 6.4 and 
>> > 6.5.
>> >   Patch title is [dpdk-dev] [PATCH] kni: fix compile errors on Oracle 
>> > Linux6.4 and RHEL6.5
>> >   With this patch, we don't meet this compilation error in latest RHEL 7.0
>> >   Can you download latest DPDK code, and try to compile with this patch in 
>> > RHEL 7.0 again?
>> 
>> okay, I will try the latest code.
>
>I still see the same error with the latest code, which includes
>
>commit f35fb0cfef52318f8ef53b1d6f562e8ba4034d10
>Author: Helin Zhang 
>Date:   Wed Jun 11 21:43:38 2014 +0800
>
>kni: fix build on Oracle Linux 6.4 and RHEL 6.5
>
>
>$ git branch -v
>* master 6e81eb5 version: 1.7.0-rc2
>
>$ uname -a
>Linux RHEL7-1 3.10.0-123.el7.x86_64 #1 SMP Mon May 5 11:16:57 EDT 2014 x86_64 
>x86_64 x86_64 GNU/Linux $ gcc -v gcc version 4.8.2 20140120 (Red Hat 4.8.2-16) 
>(GCC)
>
>$ make install -j 8 T=x86_64-ivshmem-linuxapp-gcc
>   :
>/path/to/dpdk/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h:3852:1: error: 
>conflicting types for ?skb_set_hash?
> skb_set_hash(struct sk_buff *skb, __u32 hash, __always_unused int type)
>
>thanks,
>Hiroshi
>
>> 
>> thanks,
>> Hiroshi
>> 
>> >
>> > Thanks
>> > Waterman
>> >
>> >
>> > >-Original Message-
>> > >From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
>> > >Sent: Wednesday, June 25, 2014 6:05 PM
>> > >To: Cao, Waterman
>> > >Cc: dev at dpdk.org; Hiroshi Shimamoto; Hayato Momma
>> > >Subject: Re: [dpdk-dev] [PATCH] kni: compatibility with RHEL 7
>> > >
>> > >Hi Waterman,
>> > >
>> > >2014-06-12 09:35, Hiroshi Shimamoto:
>> > >> 2014-06-12 09:18, Cao, Waterman:
>> > >> >   Can you give details about Linux Kernel version and complier 
>> > >> > version?
>> > >> >   Because we tried to build code in the Redhat 7.0 before, but we 
>> > >> > don't
>> > >> >   meet this issue. Please see information as the following:
>> > >> >   Linux kernel 3.10.0-54.0.1.el7.x86_64
>> > >> >   RHEL70BETA_64   GCC 4.8.2  ICC: 14.0.0
>> > >>
>> > >> Yes,
>> > >>
>> > >> Linux REHEL7RC-1 3.10.0-121.el7.x86_64 #1 SMP Tue Apr 8 10:48:19 
>> > >> EDT
>> > >> 2014
>> > >> x86_64 x86_64 x86_64 GNU/Linux gcc version 4.8.2 20140120 (Red 
>> > >> Hat
>> > >> 4.8.2-16) (GCC)
>> > >>
>> > >> I got the below error;
>> > >> /path/to/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h:3851:1: 
>> > >> error:
>> > >> conflicting types for ?skb_set_hash? skb_set_hash(struct sk_buff 
>> > >> *skb,
>> > >> __u32 hash, __always_unused int type)
>> > >>
>> > >> /usr/src/kernels/3.10.0-121.el7.x86_64/include/linux/skbuff.h:762:1: 
>> > >> note:
>> > >> previous definition of ?skb_set_hash? was here 
>> > >> skb_set_hash(struct sk_buff *skb, __u32 hash, enum pkt_hash_types 
>> > >> type)
>> > >
>> > >Could you confirm this fix is needed and acknowledge it?
>> > >Thanks
>> > >
>> > >
>> > >> > -Original Message-
>> > >> >
>> > >> > >From: dev [mailto:dev-bounces at dpdk

[dpdk-dev] [PATCH] kni: compatibility with RHEL 7

[Cao, Waterman]

Hi Thomas,

 We tested this patch with latest RHEL 7. (3.10.0-123) on RC2.
 It fixed compilation error in KNI.
 Please merge this patch in the RC3.
 Although We don't meet this compilation in RHEL 7 beta version, but Hiroshi 
caught it in latest version.
 It seems that there are a difference between Kernel 3.10.0-54 and 3.10.0-123

Thanks

Waterman 

-Original Message-
>From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] 
>Sent: Wednesday, June 25, 2014 6:05 PM
>To: Cao, Waterman
>Cc: dev at dpdk.org; Hiroshi Shimamoto; Hayato Momma
>Subject: Re: [dpdk-dev] [PATCH] kni: compatibility with RHEL 7
>
>Hi Waterman,
>
>2014-06-12 09:35, Hiroshi Shimamoto:
>> 2014-06-12 09:18, Cao, Waterman:
>> >   Can you give details about Linux Kernel version and complier version?
>> >   Because we tried to build code in the Redhat 7.0 before, but we don't
>> >   meet this issue. Please see information as the following:
>> >   Linux kernel 3.10.0-54.0.1.el7.x86_64
>> >   RHEL70BETA_64GCC 4.8.2  ICC: 14.0.0
>> 
>> Yes,
>> 
>> Linux REHEL7RC-1 3.10.0-121.el7.x86_64 #1 SMP Tue Apr 8 10:48:19 EDT 
>> 2014
>> x86_64 x86_64 x86_64 GNU/Linux gcc version 4.8.2 20140120 (Red Hat
>> 4.8.2-16) (GCC)
>> 
>> I got the below error;
>> /path/to/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h:3851:1: error:
>> conflicting types for ?skb_set_hash? skb_set_hash(struct sk_buff *skb,
>> __u32 hash, __always_unused int type)
>> 
>> /usr/src/kernels/3.10.0-121.el7.x86_64/include/linux/skbuff.h:762:1: note:
>> previous definition of ?skb_set_hash? was here skb_set_hash(struct 
>> sk_buff *skb, __u32 hash, enum pkt_hash_types type)
>
>Could you confirm this fix is needed and acknowledge it?
>Thanks
>
>
>> > -Original Message-
>> > 
>> > >From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Hiroshi 
>> > >Shimamoto
>> > >Sent: Thursday, June 12, 2014 4:10 PM
>> > >To: dev at dpdk.org
>> > >Cc: Hayato Momma
>> > >Subject: [dpdk-dev] [PATCH] kni: compatibility with RHEL 7
>> > >
>> > >From: Hiroshi Shimamoto 
>> > >
>> > >Compilation in RHEL7 is failed. This fixes the build issue.
>> > >
>> > >RHEL7 has skb_set_hash, the kernel version is 3.10 though.
>> > >Don't define skb_set_hash for RHEL7.
>> > >
>> > >Signed-off-by: Hiroshi Shimamoto 
>> > >Reviewed-by: Hayato Momma 
>> > >---
>> > >
>> > > lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h | 5 +
>> > > 1 file changed, 5 insertions(+)
>> > >
>> > >diff --git a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
>> > >b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h index
>> > >4c27d5d..b4de6e2 100644
>> > >--- a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
>> > >+++ b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
>> > >@@ -3843,6 +3843,9 @@ static inline struct sk_buff 
>> > >*__kc__vlan_hwaccel_put_tag(struct sk_buff *skb,  #endif /* >= 
>> > >3.10.0>
>> > */
>> > 
>> > > #if ( LINUX_VERSION_CODE < KERNEL_VERSION(3,14,0) )
>> > >
>> > >+
>> > >+#if (!(RHEL_RELEASE_CODE && RHEL_RELEASE_CODE >=
>> > >+RHEL_RELEASE_VERSION(7,0)))
>> > >+
>> > >
>> > > #ifdef NETIF_F_RXHASH
>> > > #define PKT_HASH_TYPE_L3 0
>> > > static inline void
>> > >
>> > >@@ -3851,6 +3854,8 @@ skb_set_hash(struct sk_buff *skb, __u32 hash, 
>> > >__always_unused int type)> >
>> > >  skb->rxhash = hash;
>> > > 
>> > > }
>> > > #endif /* NETIF_F_RXHASH */
>> > >
>> > >+#endif /* < RHEL7 */
>> > >+
>> > >
>> > > #endif /* < 3.14.0 */
>> > > 
>> > > #endif /* _KCOMPAT_H_ */
>> > >
>> > >--
>> > >1.9.1
>
>
>--
>Thomas

[dpdk-dev] [PATCH 0/4] Link Bonding Library

[Cao, Waterman]

Hi declan,

  Do you send out Patch 1,2, 3 for link bonding?
  Only see patch 0 and 4.

Thanks
Waterman 

-Original Message-
From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of declan.dohe...@intel.com
Sent: Wednesday, May 28, 2014 11:32 PM
To: dev at dpdk.org; dev at dpdk.org
Subject: [dpdk-dev] [PATCH 0/4] Link Bonding Library

From: Declan Doherty 

Initial release of Link Bonding Library (lib/librte_bond) with support for 
bonding modes :
 0 - Round Robin
 1 - Active Backup
 2 - Balance l2 / l23 / l34
 3 - Broadcast

patches split:
 1 - library + makefile changes
 2 - Unit test suite, including code to generate packet bursts for
testing rx and tx functionality of bonded device and a
virtual/stubbed out ethdev for use as slave ethdev in testing
 3 - Link bonding integration into testpmd, including :
 - Includes the ability to  create new bonded devices.
 - Add /remove bonding slave devices. 
 - Interogate bonded device stats/configuration
 - Change bonding modes and select balance transmit polices
 4 - Add Link Bonding Library to Doxygen


 app/test-pmd/cmdline.c|  550 +
 app/test-pmd/parameters.c |4 +-
 app/test-pmd/testpmd.c|   28 +-
 app/test-pmd/testpmd.h|2 +
 app/test/Makefile |3 +
 app/test/commands.c   |3 +
 app/test/packet_burst_generator.c |  276 +++
 app/test/packet_burst_generator.h |   85 +
 app/test/test.h   |1 +
 app/test/test_link_bonding.c  | 4007 +
 app/test/virtual_pmd.c|  580 ++
 app/test/virtual_pmd.h|   74 +
 config/common_bsdapp  |5 +
 config/common_linuxapp|5 +
 doc/doxy-api-index.md |1 +
 doc/doxy-api.conf |1 +
 lib/Makefile  |1 +
 lib/librte_bond/Makefile  |   28 +
 lib/librte_bond/rte_bond.c| 1679 
 lib/librte_bond/rte_bond.h|  228 +++
 mk/rte.app.mk |5 +
 21 files changed, 7564 insertions(+), 2 deletions(-)  create mode 100644 
app/test/packet_burst_generator.c  create mode 100644 
app/test/packet_burst_generator.h  create mode 100644 
app/test/test_link_bonding.c  create mode 100644 app/test/virtual_pmd.c  create 
mode 100644 app/test/virtual_pmd.h  create mode 100644 lib/librte_bond/Makefile 
 create mode 100644 lib/librte_bond/rte_bond.c  create mode 100644 
lib/librte_bond/rte_bond.h

--
1.8.5.3

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

[Cao, Waterman]

Hi Yong,

We tested your patch with VMWare ESX 5.5.
It works fine with R1.8 RC1. 
You can find more details from Xiaonan's reports.

Regards

Waterman 
>-Original Message-
>From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Yong Wang
>Sent: Tuesday, October 14, 2014 5:00 AM
>To: Thomas Monjalon
>Cc: dev at dpdk.org
>Subject: Re: [dpdk-dev] [PATCH 0/5] vmxnet3 pmd fixes/improvement
>
>Only the last one is performance related and it merely tries to give hints to 
>the compiler to hopefully make branch prediction more efficient.  It also 
>moves a constant assignment out of the pkt polling loop.
>
>We did performance evaluation on a Nehalem box with 4cores at 2.8GHz x 2 
>socket:
>On the DPDK-side, it's running some l3 forwarding apps in a VM on ESXi with 
>one core assigned for polling.  The client side is pktgen/dpdk, pumping 64B 
>tcp packets at line rate.  Before the patch, we are seeing ~900K PPS with 65% 
>cpu of a core used for DPDK.  After the patch, we are seeing the same pkt rate 
>with only 45% of a core used.  CPU usage is collected factoring our the idle 
>loop cost.  The packet rate is a result of the mode we used for vmxnet3 (pure 
>emulation mode running default number of hypervisor contexts).  I can add 
>these info in the review request.
>
>Yong
>
>From: Thomas Monjalon 
>Sent: Monday, October 13, 2014 1:29 PM
>To: Yong Wang
>Cc: dev at dpdk.org
>Subject: Re: [dpdk-dev] [PATCH 0/5] vmxnet3 pmd fixes/improvement
>
>Hi,
>
>2014-10-12 23:23, Yong Wang:
>> This patch series include various fixes and improvement to the
>> vmxnet3 pmd driver.
>>
>> Yong Wang (5):
>>   vmxnet3: Fix VLAN Rx stripping
>>   vmxnet3: Add VLAN Tx offload
>>   vmxnet3: Fix dev stop/restart bug
>>   vmxnet3: Add rx pkt check offloads
>>   vmxnet3: Some perf improvement on the rx path
>
>Please, could describe what is the performance gain for these patches?
>Benchmark numbers would be appreciated.
>
>Thanks
>--
>Thomas

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Yong Wang
Sent: Tuesday, October 14, 2014 5:00 AM
To: Thomas Monjalon
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH 0/5] vmxnet3 pmd fixes/improvement

Only the last one is performance related and it merely tries to give hints to 
the compiler to hopefully make branch prediction more efficient.  It also moves 
a constant assignment out of the pkt polling loop.

We did performance evaluation on a Nehalem box with 4cores at 2.8GHz x 2 socket:
On the DPDK-side, it's running some l3 forwarding apps in a VM on ESXi with one 
core assigned for polling.  The client side is pktgen/dpdk, pumping 64B tcp 
packets at line rate.  Before the patch, we are seeing ~900K PPS with 65% cpu 
of a core used for DPDK.  After the patch, we are seeing the same pkt rate with 
only 45% of a core used.  CPU usage is collected factoring our the idle loop 
cost.  The packet rate is a result of the mode we used for vmxnet3 (pure 
emulation mode running default number of hypervisor contexts).  I can add these 
info in the review request.

Yong

From: Thomas Monjalon 
Sent: Monday, October 13, 2014 1:29 PM
To: Yong Wang
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH 0/5] vmxnet3 pmd fixes/improvement

Hi,

2014-10-12 23:23, Yong Wang:
> This patch series include various fixes and improvement to the
> vmxnet3 pmd driver.
>
> Yong Wang (5):
>   vmxnet3: Fix VLAN Rx stripping
>   vmxnet3: Add VLAN Tx offload
>   vmxnet3: Fix dev stop/restart bug
>   vmxnet3: Add rx pkt check offloads
>   vmxnet3: Some perf improvement on the rx path

Please, could describe what is the performance gain for these patches?
Benchmark numbers would be appreciated.

Thanks
--
Thomas

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

[Cao, Waterman]

Hi Thomas,

Yes. Xiaonan just want to confirm if yong's patch doesn't impact 
original functionality and regression test cases under VMware.
Xiaonan will check with yong and see if we can add some test in the 
regression to new changes.

Waterman 

-Original Message-
>From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
>Sent: Wednesday, November 5, 2014 6:50 AM
>To: Zhang, XiaonanX
>Cc: dev at dpdk.org
>Subject: Re: [dpdk-dev] [PATCH 0/5] vmxnet3 pmd fixes/improvement
>
>Hi,
>
>These tests don't seem related to the patchset.
>It would be more interesting to test vlan, stop/restart, Rx checks and Rx 
>performance improvement.
>
>--
>Thomas
>
>
>2014-11-04 05:57, Zhang, XiaonanX:
>> Tested-by: Xiaonan Zhang 
>> 
>> - Tested Commit: Yong Wang
>> - 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 82599ES 10-Gigabit SFI/SFP+ Network Connection 
>> [8086:10fb]
>> - Default x86_64-native-linuxapp-gcc configuration
>> - Total 6 cases, 6 passed, 0 failed
>> - Test Environment setup
>> 
>> - Topology #1: Create 2VMs (Fedora 20, 64bit);for each VM, pass through one 
>> physical port(Niantic 82599) to VM, and also create one virtual device: 
>> vmxnet3 in VM. Between two VMs, use one vswitch to connect 2 vmxnet3. In 
>> summary, PF1 
>>and vmxnet3A are in VM1; PF2 and vmxnet3B are in VM2.The 
>> traffic flow for l2fwd/l3fwd is as below:
>>Ixia -> PF1 -> vmxnet3A -> vswitch -> vmxnet3B -> PF2 -> 
>> Ixia. 
>> - Topology #2: Create 1VM (Fedora 20, 64bit), on this VM, created 2 vmxnet3, 
>> called vmxnet3A, vmxnet3B; create 2 vswitch, vswitchA connecting PF1 and 
>> vmxnet3A, while vswitchB connecting PF2 and vmxnet3B. The traffic flow is as 
>> below:
>>Ixia -> PF1 -> vswitchA -> vmxnet3A -> vmxnet3B -> vswitchB 
>> -> PF2 -> Ixia.
>> 
>> - Test Case1: L2fwd with Topology#1 
>>   Description: Set up topology#1(in prerequisite session), and bind PF1, 
>> PF2, Vmxnet3A, vmxnet3B to DPDK poll-mode driver (igb_uio).
>>Increase the flow at line rate (uni-directional traffic), 
>> send the flow at different packet size (64bytes, 128bytes, 256bytes, 
>> 512bytes, 1024bytes, 1280bytes and 1518bytes) and check the received 
>> packets/rate to see  
>>if any unexpected behavior, such as no receives after N 
>> packets. 
>>   Command / instruction:
>> To run the l2fwd example in 2VMs:
>> ./build/l2fwd -c f -n 4 -- -p 0x3
>> - Test IXIA Flow prerequisite: Ixia port1 sends 5 packets to PF1, and the 
>> flow should have PF1's MAC as destination MAC. Check if ixia port2 have 
>> received the 5 packets.
>>   Expected test result:
>> Passed
>> 
>> - Test Case2: L3fwd-VF with Topology#1
>>   Description: Set up topology#1(in prerequisite session), and bind PF1, 
>> PF2, Vmxnet3A, vmxnet3B to DPDK poll-mode driver (igb_uio)
>>Increase the flow at line rate (uni-directional traffic), 
>> send the flow at different packet size (64bytes, 128bytes, 256bytes, 
>> 512bytes, 1024bytes, 1280bytes and 1518bytes) and check the received 
>> packets/rate to see  
>>if any unexpected behavior, such as no receives after N 
>> packets.
>>   Command / instruction:
>> To run the l3fwd-vf example in 2VMs:
>> ./build/l3fwd-vf -c 0x6 -n 4 -- -p 0x3 
>> --config "(0,0,1),(1,0,2)"
>> - Test IXIA Flow prerequisite: Ixia port1 sends 5 packets to PF1, and the 
>> flow should have PF1's MAC as destination MAC and have 2.1.1.x as 
>> destination IP. Check if ixia port2 have received the 5 packets.
>>   Expected test result:
>> Passed
>> 
>> - Test Case3: L2fwd with Topology#2
>>   Description: Set up topology#2(in prerequisite session), and bind vmxnet3A 
>> and vmxnet3B to DPDK poll-mode driver (igb_uio).
>>Increase the flow at line rate (uni-directional traffic), 
>> send the flow at different packet size (64bytes, 128bytes, 256bytes, 
>> 512bytes, 1024bytes, 1280bytes and 1518bytes) and check the received 
>> packets/rate to see  
>>if any unexpected behavior, such as no receives after N 
>> packets.
>>   Command / instruction:
>> To run the l2fwd example in VM1:
>> ./build/l2fwd -c f -n 4 -- -p 0x3
>> - Test IXIA Flow prerequisite: Ixia port1 sends 5 packets to port0 
>> (vmxnet3A), and the flow should have port0's MAC as destination MAC. Check 
>> if ixia port2 have received the 5 packets. Similar things need to be done at 
>> ixia port2.
>>   Expected test result:
>> Passed
>> 
>> - Test Case4: L3fwd-VF with Topology#2
>>   Description: Set up topology#2(in prerequisite session), and bind vmxnet3A 
>> and vmxnet3B to DPDK poll-mode driver (igb_uio).

[dpdk-dev] [PATCH v3] lib/librte_vhost: user space vhost driver library

[Cao, Waterman]

Tested-by: Waterman Cao  

This patch facilitates integration with DPDK vSwitch, and is ready to integrate 
into DPDK.org.

-Original Message-
>From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Huawei Xie
>Sent: Tuesday, August 5, 2014 11:54 PM
>To: dev at dpdk.org
>Subject: [dpdk-dev] [PATCH v3] lib/librte_vhost: user space vhost driver 
>library
>
>This user space vhost library is provided aiming to facilitate integration 
>with DPDK accelerated vswitch. 
>
>Huawei Xie (1):
>  vhost library support to facilitate integration with DPDK accelerated 
> vswitch.
>
> config/common_linuxapp   |7 +
> lib/Makefile |1 +
> lib/librte_vhost/Makefile|   48 ++
> lib/librte_vhost/eventfd_link/Makefile   |   39 +
> lib/librte_vhost/eventfd_link/eventfd_link.c |  194 +
> lib/librte_vhost/eventfd_link/eventfd_link.h |   40 +
> lib/librte_vhost/rte_virtio_net.h|  192 +
> lib/librte_vhost/vhost-net-cdev.c|  363 ++
> lib/librte_vhost/vhost-net-cdev.h|  109 +++
> lib/librte_vhost/vhost_rxtx.c|  292 
> lib/librte_vhost/virtio-net.c| 1002 ++
> 11 files changed, 2287 insertions(+)
> create mode 100644 lib/librte_vhost/Makefile  create mode 100644 
> lib/librte_vhost/eventfd_link/Makefile
> create mode 100644 lib/librte_vhost/eventfd_link/eventfd_link.c
> create mode 100644 lib/librte_vhost/eventfd_link/eventfd_link.h
> create mode 100644 lib/librte_vhost/rte_virtio_net.h  create mode 100644 
> lib/librte_vhost/vhost-net-cdev.c  create mode 100644 
> lib/librte_vhost/vhost-net-cdev.h  create mode 100644 
> lib/librte_vhost/vhost_rxtx.c  create mode 100644 
> lib/librte_vhost/virtio-net.c
>
>--
>1.8.1.4
>

[dpdk-dev] [PATCH 0/3] vhost example based on user space vhost library.

[Cao, Waterman]

Tested-by: Waterman Cao  
This patch implements a simple vswitch by user vhost library, and is ready to 
integrate into DPDK.org.

-Original Message-
>From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Huawei Xie
>Sent: Tuesday, August 5, 2014 11:58 PM
>To: dev at dpdk.org
>Subject: [dpdk-dev] [PATCH 0/3] vhost example based on user space vhost 
>library.
>
>This vhost example implements a simple vswitch using DPDK user space vhost 
>library(lib/librte_vhost) and VMDQ to demonstrate vhost's performance.
>- Each virtio device is bound to a VMDQ pool and each pool is assigned the 
>mac/vlan of the virtio device.
>- Packets arriving at a pool after l2 classifier will be moved to the virtio 
>device.
>- Packets whose destination is a local virtio device will be delivered either 
>by a)software switching mode b)hardware l2 switch.
>- zero copy is supported and could be configured through command line.
>
>Huawei Xie (3):
>  remove old vhost example
>  add lib/librte_vhost support in mk/rte.app.mk
>  add new vhost example
>
> examples/vhost/Makefile|   10 +-
> examples/vhost/eventfd_link/Makefile   |   39 -
> examples/vhost/eventfd_link/eventfd_link.c |  205 -
> examples/vhost/eventfd_link/eventfd_link.h |   79 --
> examples/vhost/libvirt/qemu-wrap.py|5 +-
> examples/vhost/main.c  | 1101 +-
> examples/vhost/main.h  |   85 +-
> examples/vhost/vhost-net-cdev.c|  367 -
> examples/vhost/vhost-net-cdev.h|   83 --
> examples/vhost/virtio-net.c| 1165 
> examples/vhost/virtio-net.h|  147 
> mk/rte.app.mk  |5 +
> 12 files changed, 585 insertions(+), 2706 deletions(-)  delete mode 100644 
> examples/vhost/eventfd_link/Makefile
> delete mode 100644 examples/vhost/eventfd_link/eventfd_link.c
> delete mode 100644 examples/vhost/eventfd_link/eventfd_link.h
> delete mode 100644 examples/vhost/vhost-net-cdev.c  delete mode 100644 
> examples/vhost/vhost-net-cdev.h  delete mode 100644 
> examples/vhost/virtio-net.c  delete mode 100644 examples/vhost/virtio-net.h
>
>--
>1.8.1.4
>

[dpdk-dev] [RFT] vmxnet3 testing needed

[Cao, Waterman]

Hi Stephen,

  We have tested intel VMXNet3 driver before.
  If your patch is based on Intel DPDK VMXNet3 driver, we can try it in my 
platform.

Regards
Waterman 

>-Original Message-
>From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen Hemminger
>Sent: Tuesday, August 26, 2014 8:43 AM
>To: dev at dpdk.org
>Subject: [dpdk-dev] [RFT] vmxnet3 testing needed

>I have 7 patches for vmxnet3 but don't have time/infrastructure to test them 
>before 1.7.1 freeze this Friday. Anybody want to give them a working over?

[dpdk-dev] [PATCH] xenvirt: Fix build break on cmdline_parse_etheraddr call

[Cao, Waterman]

Hi Neil,

Can you let me know what configuration you used for XEN Domain U?
Do you able to run some test cases on XEN Domain U?
So far, we met some issues on xenvirt (Domain U). 

Thanks

Waterman 

[dpdk-dev] DPDK Test Suite 1.0 Release

[Cao, Waterman]

DPDK Test Suite 1.0 Release Announcement

We are very pleased to announce that DPDK Test Suite 1.0 (DTS) is released 
by intel now. DTS is an automation test tool for DPDK software, a python-base 
library. It can run on remote tester machine, and communicate/manage test device
by SSH connection. This tool also supports different kinds of traffic 
generators,
including DPDK-based PacketGen, third-party professional tester equipment(IXIA).

DTS is composes of one set of test cases and automation test framework. Since 
Based on DTS, DPDK developers and testers can build their test cases and 
verify their patches with these function test. It only requires less effort 
to maintain test cases once merged into DTS. Since DPDK Test Suite is an open 
source test tool, Everyone can utilize DTS to measure performance and 
functionality for features. 

In the future, we will continue to upgrade DPDK Test Suite to support DPDK 
software package based on DPDK release timeline, and provide stable version 
for each DPDK formal release. Currently, DPDK Test Suite 1.0 will support 
the latest DPDK release version 1.8. 

You can download latest DPDK test suite from the following link:
http://dpdk.org/git/tools/dts 

In addition, one mailing list was created as dts at dpdk.org. This mailing list 
is 
used to post regression test report for DPDK software, answer questions 
about DTS, and receive patches for DPDK Test Suite. Also you can discuss 
issues and seek for validate solution of DPDK features with this mailing list.
Marvin Liu(Yong.liu at intel.com)from Intel will maintain DPDK Test Suite code, 
and responsible for code merge. We are very welcome that other volunteers who 
interested in DPDK Validation can join in us to maintain this tool.

Since DPDK Test Suite includes some generic test suites, plans and one test 
framework. Please see features list as the followings.

DTS features:
- Support SSH connection and manager tester, test device and IXIA generator
- Automatically discover network topology
- Automatically deploy DPDK on DUT (Device under Test) which installed 
  Fedora18/20, Ubuntu12/14, FreeBSD 10, etc.
- Support Wind River DPDK-based software traffic generators and IXIA 
  traffic generator
- Able to transmit, capture and analyze packets by Scapy
- Provide solution to develop user-defined test suite and test plan
- Provide customized configuration file
- Export validation results as RST format and excel format
- Support logging system to track automation execution.

Example Test Suites:
- Blacklist/Whitelist: EAL whitelist/blacklist feature
- Command line   : RTE command line interface
- Multi process  : DPDK share information between process
- Timer  : EAL timer feature
- Testpmd: Poll Mode driver packet integrity, packet checksum, 
   performance benchmark
- L2fwd  : layer-2 (L2) forwarding application
- L3fwd  : Layer-3 Forwarding application
- Jumbo Frame: Poll Mode Drivers for jumbo frames feature
- Ieee1588   : IEEE1588 Precise Time Protocol offload feature
- Checksum offload   : RX/TX L3/L4 checksum offload feature
- Flow direction : NIC flow director feature
- VLAN   : NIC VLAN offload feature
- Link flowctrl  : NIC link flow control feature
- Link bonding   : Poll mode driver link bonding feature
- IP fragment: IPv4 and IPV6 fragmentation feature
- Packet framework   : IP pipeline by DPDK packet framework feature

Finally, DTS is open to everyone. Everyone is welcomed to use this tool, 
submit test cases and share knowledge with community. 
We hope that DTS can help to improve quality of open source patch and 
leverage effort with every members in community.

Best Regards

Intel DPDK Validation Team

[dpdk-dev] [PATCH] test: Remove NULL snprintf tests in cmdline unit test

[Cao, Waterman]

Tested-by: Waterman Cao 

This patch updated Cmdline unit test, and is ready to integrate into DPDK.org.

[dpdk-dev] Compilation errors in FreeBSD and OR Linux (Kerne 2.6.39l

[Cao, Waterman]

Hi Thomas,

We defected two compilation errors in RC3:

-
One from FreeBSD 10:

target: x86_64-native-bsdapp-gcc

== Build lib/librte_eal/bsdapp/eal
  CC eal.o
/jenkins/workspace/DPDK_AUTO_IDT_VM_FreeBSD10.0_64_BUILD/DPDK/lib/librte_eal/bsdapp/eal/eal.c:
 In function 'rte_eal_init':
/jenkins/workspace/DPDK_AUTO_IDT_VM_FreeBSD10.0_64_BUILD/DPDK/lib/librte_eal/bsdapp/eal/eal.c:877:2:
 error: implicit declaration of function 'rte_eal_dev_init' 
[-Werror=implicit-function-declaration]
  if (rte_eal_dev_init(PMD_INIT_PRE_PCI_PROBE) < 0)
  ^
/jenkins/workspace/DPDK_AUTO_IDT_VM_FreeBSD10.0_64_BUILD/DPDK/lib/librte_eal/bsdapp/eal/eal.c:877:2:
 error: nested extern declaration of 'rte_eal_dev_init' [-Werror=nested-externs]
/jenkins/workspace/DPDK_AUTO_IDT_VM_FreeBSD10.0_64_BUILD/DPDK/lib/librte_eal/bsdapp/eal/eal.c:877:23:
 error: 'PMD_INIT_PRE_PCI_PROBE' undeclared (first use in this function)
  if (rte_eal_dev_init(PMD_INIT_PRE_PCI_PROBE) < 0)
   ^
/jenkins/workspace/DPDK_AUTO_IDT_VM_FreeBSD10.0_64_BUILD/DPDK/lib/librte_eal/bsdapp/eal/eal.c:877:23:
 note: each undeclared identifier is reported only once for each function it 
appears in
/jenkins/workspace/DPDK_AUTO_IDT_VM_FreeBSD10.0_64_BUILD/DPDK/lib/librte_eal/bsdapp/eal/eal.c:914:23:
 error: 'PMD_INIT_POST_PCI_PROBE' undeclared (first use in this function)
  if (rte_eal_dev_init(PMD_INIT_POST_PCI_PROBE) < 0)
   ^
cc1: all warnings being treated as errors
gmake[7]: *** [eal.o] Error 1
gmake[6]: *** [eal] Error 2
gmake[5]: *** [bsdapp] Error 2
gmake[4]: *** [librte_eal] Error 2
gmake[3]: *** [lib] Error 2
gmake[2]: *** [all] Error 2
gmake[1]: *** [x86_64-native-bsdapp-gcc_install] Error 2
gmake: *** [install] Error 2

---
The other from ORACLELINUX64_32 (Linux Kernel 2.6.39)

>>>i686-native-linuxapp-gcc%CONFIG_RTE_LIBRTE_PMD_PCAP=y at 
>>>CONFIG_RTE_NIC_BYPASS=y<<<
== Installing i686-native-linuxapp-gcc
gmake[5]: Nothing to be done for `depdirs'.
Configuration done
== Build scripts
== Build scripts/testhost
== Build lib
== Build lib/librte_eal
== Build lib/librte_eal/common
== Build lib/librte_eal/linuxapp
== Build lib/librte_eal/linuxapp/igb_uio
  Building modules, stage 2.
  MODPOST 1 modules
== Build lib/librte_eal/linuxapp/eal
== Build lib/librte_malloc
== Build lib/librte_ring
== Build lib/librte_mempool
== Build lib/librte_mbuf
== Build lib/librte_timer
== Build lib/librte_cfgfile
== Build lib/librte_cmdline
== Build lib/librte_ether
== Build lib/librte_net
== Build lib/librte_pmd_e1000
== Build lib/librte_pmd_ixgbe
== Build lib/librte_pmd_i40e
== Build lib/librte_kvargs
== Build lib/librte_pmd_bond
  CC rte_eth_bond_api.o
In file included from /usr/include/stdlib.h:320,
 from 
/jenkins/workspace/DPDK_AUTO_IDT_VM_ORACLELINUX64_32_BUILD/DPDK/i686-native-linuxapp-gcc/include/rte_mempool.h:63,
 from 
/jenkins/workspace/DPDK_AUTO_IDT_VM_ORACLELINUX64_32_BUILD/DPDK/i686-native-linuxapp-gcc/include/rte_mbuf.h:61,
 from 
/jenkins/workspace/DPDK_AUTO_IDT_VM_ORACLELINUX64_32_BUILD/DPDK/lib/librte_pmd_bond/rte_eth_bond_api.c:37:
/usr/include/sys/types.h:61: error: conflicting types for 'dev_t'
/usr/include/linux/types.h:22: note: previous declaration of 'dev_t' was here
/usr/include/sys/types.h:66: error: conflicting types for 'gid_t'
/usr/include/linux/types.h:52: note: previous declaration of 'gid_t' was here
/usr/include/sys/types.h:71: error: conflicting types for 'mode_t'
/usr/include/linux/types.h:24: note: previous declaration of 'mode_t' was here
/usr/include/sys/types.h:76: error: conflicting types for 'nlink_t'
/usr/include/linux/types.h:25: note: previous declaration of 'nlink_t' was here
/usr/include/sys/types.h:81: error: conflicting types for 'uid_t'
/usr/include/linux/types.h:51: note: previous declaration of 'uid_t' was here
In file included from /usr/include/sys/types.h:133,
 from /usr/include/stdlib.h:320,
 from 
/jenkins/workspace/DPDK_AUTO_IDT_VM_ORACLELINUX64_32_BUILD/DPDK/i686-native-linuxapp-gcc/include/rte_mempool.h:63,
 from 
/jenkins/workspace/DPDK_AUTO_IDT_VM_ORACLELINUX64_32_BUILD/DPDK/i686-native-linuxapp-gcc/include/rte_mbuf.h:61,
 from 
/jenkins/workspace/DPDK_AUTO_IDT_VM_ORACLELINUX64_32_BUILD/DPDK/lib/librte_pmd_bond/rte_eth_bond_api.c:37:
/usr/include/time.h:104: error: conflicting types for 'timer_t'
/usr/include/linux/types.h:31: note: previous declaration of 'timer_t' was here
In file included from /usr/include/sys/types.h:220,
 from /usr/include/stdlib.h:320,
 from 
/jenkins/workspace/DPDK_AUTO_IDT_VM_ORACLELINUX64_32_BUILD/DPDK/i686-native-linuxapp-gcc/include/rte_mempool.h:63,
 from 
/jenkins/workspace/DPDK_AUTO_IDT_VM_ORACLELINUX64_32_BUILD/DPDK/i686-native-linuxapp-gcc/include/rte_mbuf.h:61,

[dpdk-dev] Build failure on Ubuntu 14.04

[Cao, Waterman]

Hi Keith,

we built the newest dpdk code on my machine, it seems OK,
please see UB14.04 info in my computer. 
System: Ubuntu14.04
Kernel: 3.13.0-24 X86_64
Compiler:   GCC 4.8.2 x86_64

Can you let me know which kernel version you use?
Thanks
Waterman 

Original Message-
>From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wiles, Roger Keith
>Sent: Saturday, July 5, 2014 11:50 PM
>To: 
>Subject: Re: [dpdk-dev] Build failure on Ubuntu 14.04
>
>Made sure I was up to date with Ubuntu patches, but still had the same problem.
>
>I modified the kcompat.h file to allow the compile to continue, not sure this 
>is a fix per say.
>
>dpdk.org/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
> around line 3853
>
># Changed the next line from (3,14,0) to (3,13,0) #if ( LINUX_VERSION_CODE 
>< KERNEL_VERSION(3,13,0) ) #if (!(RHEL_RELEASE_CODE && RHEL_RELEASE_CODE >= 
>RHEL_RELEASE_VERSION(7,0))) #ifdef NETIF_F_RXHASH #define PKT_HASH_TYPE_L3 0 
>static inline void skb_set_hash(struct sk_buff *skb, __u32 hash, 
>__always_unused int type) {
>skb->rxhash = hash;
>}
>#endif /* NETI
F_F_RXHASH */
>#endif /* < RHEL7 */
>#endif /* < 3.14.0 */
>
>Keith Wiles, Principal Technologist with CTO office, Wind River mobile 
>972-213-5533
>
>[Powering 30 Years of Innovation]
>
>On Jul 5, 2014, at 10:28 AM, Wiles, Roger Keith windriver.com> wrote:
>
>Forgot the uname -a:
>
>Linux keithw-W2600CR 3.13.0-30-generic #54-Ubuntu SMP Mon Jun 9 22:45:01 UTC 
>2014 x86_64 x86_64 x86_64 GNU/Linux
>
>Keith Wiles, Principal Technologist with CTO office, Wind River mobile 
>972-213-5533
>
>[Powering 30 Years of Innovation]
>
>On Jul 5, 2014, at 10:27 AM, Wiles, Roger Keith windriver.comwindriver.com>> wrote:
>
>Hi All,
>
>I got a build failure on :
>
>[10:20][keithw at keithw-W2600CR:umf(dev)]$ lsb_release -a No LSB modules are 
>available.
>Distributor ID: Ubuntu
>Description:Ubuntu 14.04 LTS
>Release:14.04
>Codename:   trusty
>
>Looks like the skb_set_hash() function changed from:
>
>static inline void
>skb_set_hash(struct sk_buff *skb, __u32 hash, __always_unused int type) {
>  skb->rxhash = hash;
>}
>
>To:
>
>static inline void
>skb_set_hash(struct sk_buff *skb, __u32 hash, enum pkt_hash_types type) {
>  skb->l4_rxhash = (type == PKT_HASH_TYPE_L4);
>  skb->rxhash = hash;
>}
>
>Compile line: 'make install T=x86_64-native-linuxapp-gcc'
>...
>CC [M]  
>/home/keithw/projects/dpdk/dpdk.org/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/kni/e1000_82575.o
>In file included from 
>/home/keithw/projects/dpdk/dpdk.org/lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_osdep.h:41:0,
>   from 
> /home/keithw/projects/dpdk/dpdk.org/lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_hw.h:31,
>   from 
> /home/keithw/projects/dpdk/dpdk.org/lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_api.h:31,
>   from 
> /home/keithw/projects/dpdk/dpdk.org/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/kni/e1000_82575.c:38:
>/home/keithw/projects/dpdk/dpdk.org/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h:3853:1:
> error: conflicting types for a??skb_set_hasha?? skb_set_hash(struct sk_buff 
>*skb, __u32 hash, __always_unused int type) ^ In file included from 
>/usr/src/linux-headers-3.13.0-30-generic/include/linux/if

[dpdk-dev] Build failure on Ubuntu 14.04

[Cao, Waterman]

Thanks Keith.
we will try to enable CentOS in our daily build test.
But I has a little concern about Ubuntu 14.
We enabled latest UB14 with kernel 3.13.0-24 at this may.
It seems that UB LTS will upgrade Linux kernel to 3.13.0-30.
But we don't know when it upgrade, and it will cost a lot of effort to upgrade 
environment.
Can we indicate specific version for Ubuntu 14.04?
Btw, we met the same issue in RedHat 7.0 Beta version.

Waterman

From: Wiles, Roger Keith [mailto:keith.wi...@windriver.com]
Sent: Monday, July 7, 2014 10:42 PM
To: De Lara Guarch, Pablo
Cc: Cao, Waterman; 
Subject: Re: [dpdk-dev] Build failure on Ubuntu 14.04

Someone compiling on CentOS kernel 3.13.7 needed the original code. Looks like 
some other type of ifdef change needs to be done to the kcompat.h file to allow 
it to compile on Ubuntu 14.04 with kernel 3.13.0-30.

Keith Wiles, Principal Technologist with CTO office, Wind River
mobile 972-213-5533

[Powering 30 Years of Innovation]<http://www.windriver.com/announces/wr30/>

On Jul 7, 2014, at 3:39 AM, De Lara Guarch, Pablo mailto:pablo.de.lara.guarch at intel.com>> wrote:



Hi Keith,

we built the newest dpdk code on my machine, it seems OK,
please see UB14.04 info in my computer.
System:   Ubuntu14.04
Kernel:   3.13.0-24 X86_64
Compiler: GCC 4.8.2 x86_64

Can you let me know which kernel version you use?

Apparently, it is this one: 3.13.0-30-generic, from uname -a


Thanks
Waterman

[dpdk-dev] [PATCH v2 0/4] NIC filters support for generic filter

[Cao, Waterman]

Tested-by: Waterman Cao 

This patch includes 4 files, and has been tested by Intel.
Please see information as the following:
 Fedora 20 x86_64, Linux Kernel 3.11.10-301, GCC 4.8.2
 Intel Xeon CPU E5-2680 v2 @ 2.80GHz
 NIC: Intel Niantic 82599, Intel i350, Intel 82580 and Intel 82576
 We verified ethertype filter, 2-tuple filter, 5-tuple filter, 
 flex filter and SYN filter with different NICs.

 Total casesPassed   Failed   
 18   16   2

 Failure only related to priority of filter, no impact on functionality.
 Example: Show how to distribute specific packet to assigned queue 
 Please launch testpmd firstly, then run the following command:
  ---add syn filter ---
  testpmd> add_syn_filter (port_id) priority (high|low) queue (queue_id)
  ---get syn filter info ---
  testpmd> get_syn_filter (port_id)
  ---remove syn filter ---
  testpmd> remove_syn_filter (port_id)

[dpdk-dev] [PATCH 0/2] L3FWD sample optimisation

[Cao, Waterman]

Tested-by: Waterman Cao 

This patch has been tested by Intel. We performed l3fwd performance test. 
Test result shows that l3fwd performance with this ?lpm optimization? patch is 
much higher than that without this patch. 
Test environment: Fedora 20, Linux Kernel 3.11.10, GCC 4.8.2, Intel Xeon 
processor E5-2680 v2, with 2 ports on 2 Niantic (all at socket 0)
Please refer performance data from the separate email?
http://dpdk.org/ml/archives/dev/2014-May/002703.html  

[dpdk-dev] [PATCH 00/29] Packet Framework

[Cao, Waterman]

Tested-by: Waterman Cao 

Totally this patch is composed of 30 files including cover letter, and has been 
tested by Intel. 
We verified packet framework patch with ip pipeline example and unit test, all 
cases passed.
Please see test result as the following:  
  test_flow_management   Passed
  test_frame_sizes   Passed
  test_incremental_ipPassed
  test_route_management  Passed   
  test_hash_tables   Passed
  test_lpm_table Passed
  test_none_tablePassed
Test environment: Fedora 20, Linux Kernel 3.13.6-200, GCC 4.8.2, Intel Xeon 
processor E5-2680 v2, with Intel Niantic 82599.

[dpdk-dev] [PATCH 0/3] *** Upgrade NIC share codes ***

[Cao, Waterman]

Tested-by: Waterman Cao 

Totally this patch is composed of 4 files including cover letter, and has been 
tested by Intel. 
We verified latest NIC share code with different kind of NICs, please see the 
list as the followings:
Type Product Name
1G  Powerville (Intel Ethernet Controller I350 - T4)
1G  Springville(Intel Ethernet Controller I210 1x1000BASE-T)
1G  Intel 82576 1G  1000BASE-T
10G Intel 82599 10Gb Ethernet Controller - X520 - SR2 
10G Intel 82599 10Gb Ethernet Controller - X520 - T2  
10G Intel 82599 10Gb Ethernet Controller 4 x 10GbE - SFP+
10G Intel Ethernet Controller X540 2x10GBASE-T
All basic NIC function test are passed with latest NIC share code, including 
PMD, Flow Direction, L2 FWD, Dual vlan, ip reassembly, etc.
Test environment: Fedora 20, Linux Kernel 3.12.11, GCC 4.8.2, Intel Xeon 
processor E5-2680 v2.

[dpdk-dev] [PATCH v2 0/3] Support setting link up and link down

[Cao, Waterman]

Tested-by: Waterman Cao 

This patch is used to fix bug, and has been tested by Intel.
We verified API by testpmd, it passed.
Please see test steps as the following:
1. In the host machine, set the DPDK environment as usual and start testpmd:
  ./app/test-pmd/testpmd -c f -n 4 -- -i
2. Start packet forwarding on both ports.
3. In the tester/traffic generator, send the packet with destine MAC to any 
port on host.
4. Then launch testpmd on host, use the following command to set link up/down 
to the port:
   testpmd> set link-up port 0(or 1)
   testpmd> set link-down port 0(or 1)
5. Then check port status

See test environment information as the following:
  Fedora 20 x86_64, Linux Kernel 3.13.9-200, GCC 4.8.2
  Intel Xeon CPU E5-2680 v2 @ 2.80GHz
  NIC: Intel Niantic 82599, Intel i350, Intel 82580 and Intel 82576

[dpdk-dev] [PATCH v2 0/5] New library: rte_distributor

[Cao, Waterman]

Tested-by: Waterman Cao 

This patch is composed of 5 files including cover letter. 
All files have been tested by Intel.
We performed function and performance test on new Distributor patch.
Total Cases  Passed  Failed
10   10   0
Please see example as the following:
cd /root/dpdk/app/test
make
./test -n 4 -c 0xC
./distributor_autotest

Test Environment: 
Fedora 20 x86_64, Linux Kernel 3.13.6-200, GCC 4.8.2
Intel Xeon CPU E5-2680 v2 @ 2.80GHz,Intel Niantic 82599
Based off commit 41d9a8250dc8d35bcd4499ba8e59809be943e712.

[dpdk-dev] [v2 00/23] Packet Framework

[Cao, Waterman]

Tested-by: Waterman Cao 

Totally this patch is composed of 24 files including cover letter, and has been 
tested by Intel. 
We verified packet framework patch with ip pipeline example and unit test, all 
cases passed.
Please see test result as the following:  
  test_flow_management   Passed
  test_frame_sizes   Passed
  test_incremental_ipPassed
  test_route_management  Passed   
  test_hash_tables   Passed
  test_lpm_table Passed
  test_none_tablePassed
Test environment: Fedora 20, Linux Kernel 3.13.6-200, GCC 4.8.2, Intel Xeon 
processor E5-2680 v2, with Intel Niantic 82599.

[dpdk-dev] [PATCH v2]xen:reserve memory at installing dom0_mm kernel module

[Cao, Waterman]

Tested-by: Waterman Cao 
This patch has been tested by Intel.
Test Environment:
Fedora 16 with kernel 3.10.0 and Red Hat 5.0 with kernel 2.6.32 pvops.
Linux kernel has the following features enabled: Huge page support, UIO, HPET 
,Xen support.
Enable PCI passthrough by add intel_iommu=on iommu=pt in kernel grub
XEN should be version 4.0.1 on Red Hat and 4.2.3 on Fedora 16.

[dpdk-dev] [PATCH v2 0/3] Support setting TX rate for queue and VF

[Cao, Waterman]

Tested-by: Waterman Cao 

This patch bug fix has been tested by Intel.
Please see information as the following:
Fedora 20 x86_64, Linux Kernel 3.13.9-200, GCC 4.8.2
Intel Xeon CPU E5-2680 v2 @ 2.80GHz
NIC: Intel Niantic 82599, Intel i350, Intel 82580 and Intel 82576

[dpdk-dev] [PATCH v2 0/4] Link Bonding Library

[Cao, Waterman]

Tested-by: Waterman Cao 

This patch is updated version for Link Bonding library.
It's compose of 5 files including cover letter, tested by Intel.
Please see environment information:
Fedora 20 x86_64, Linux Kernel 3.11.10-301, GCC 4.8.2  
Intel Xeon CPU E5-2680 v2 @ 2.80GHz NIC: Intel Niantic 82599
Total casesPassed   Failed   
   1818  0

Please see test Case list as the following:
Case1: Basic bonding--Create bonded devices and slaves 
Case2: Basic bonding--MAC Address Test 
Case3: Basic bonding--Device Promiscuous Mode Test
Case4: Mode 0(Round Robin) TX/RX test 
Case5: Mode 0(Round Robin) Bring one slave link down 
Case6: Mode 0(Round Robin) Bring all slave links down
Case7: Mode 1(Active Backup) TX/RX Test 
Case8: Mode 1(Active Backup) Change active slave, RX/TX test 
Case9: Mode 1(Active Backup) Link up/down active eth dev 
Case10: Mode 1(Active Backup) Bring all slave links down
Case11: Mode 2(Balance XOR) TX Load Balance test 
Case12: Mode 2(Balance XOR) TX Load Balance Link down 
Case13: Mode 2(Balance XOR) Bring all slave links down 
Case14: Mode 2(Balance XOR) Layer 3+4 forwarding 
Case15: Mode 2(Balance XOR) RX test
Case16: Mode 3(Broadcast) TX/RX Test 
Case17: Mode 3(Broadcast) Bring one slave link down 
Case18: Mode 3(Broadcast) Bring all slave links down

[dpdk-dev] [PATCH] fix for eth_pcap_tx() can cause mbuf corruption

[Cao, Waterman]

Tested-by: Waterman Cao 

[dpdk-dev] [PATCHv2 0/5] ACL library

[Cao, Waterman]

Tested-by: Waterman Cao 

This patch has been tested by Intel.
Basic functional test has been performed about 'l3fwd-acl', all cases are 
passed.
It includes test_l3fwdacl_acl_rule, test_l3fwdacl_exact_route, 
test_l3fwdacl_lpm_route, test_l3fwdAcl_Scalar and test_l3fwdacl_invalid.
There is one known issue about 'acl rule problem with protocol', Konstantin 
will apply one minor patch to fix it later.
Test Environment:
Fedora 20 x86_64, Linux Kernel 3.11.10-301, GCC 4.8.2 Intel Xeon CPU E5-2680 v2 
@ 2.80GHz

[dpdk-dev] [PATCH v2 0/2] 10G PMD: vectorized RX and TX functions

[Cao, Waterman]

Tested-by: Waterman Cao 

This patch set has been tested by Intel.
We performed L2FWD, L3FWD and PMD test suite on new library, all cases passed.
Also we run performance test, result met our design expectation.
Please see test environment and configuration:
Each of the 10Gb Ethernet* ports of the DUT is directly connected in
full-duplex to a different port of the peer traffic generator.
The core configuration description is:
- 2C/1T: 2 Physical Cores, 1 Logical Core per physical core using core #2 and 
#4 (socket 0, 2nd and 3rd physical cores).

[dpdk-dev] [PATCH 00/13] IPv4/IPv6 fragmentation/reassembly library

[Cao, Waterman]

Tested-by: Waterman Cao 
This patch includes 13 files, ip_fragmentation and ip_reassembly app have been 
tested by Intel.
We verified IP fragmentation/reassembly library with IPv4 and IPv6 . All cases 
passed.
Please see test guidance as the following:
IP reassembly:
1. ./examples/ip_reassembly/build/ip_reassembly -c f -n 3 -- -p 0x30
2. Configure Scapy setting
   Ether() / IPv6() / IPv6ExtHdrFragment() / TCP() / ("X" * 3000)
   packet[IPv6].dst = 'fe80::92e2:baff:fe48:81b5'
   sendp(ptks,iface="eth5")
3. Use Wireshark to capture file and confirm its correction.

IP Fragment:
  ./ip_fragmentation -c  -n 4 -- [-P] -p PORTMASK
  -q 

See the test environment information as the following :
Fedora 20 x86_64, Linux Kernel 3.11.10-301, GCC 4.8.2
Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz NIC: Niantic 82599

[dpdk-dev] IMPORTANT: feature freeze for version 1.7.0

[Cao, Waterman]

>---Original Message-
>From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
>Sent: Friday, May 30, 2014 9:12 PM
>To: dev at dpdk.org
>Subject: [dpdk-dev] IMPORTANT: feature freeze for version 1.7.0
>
>Hello all,
>
>We have a lot of new features mostly ready for DPDK 1.7.0.
>It's now time to be sure that they are well reviewed and integrated.
>Then release candidate should be tagged in mid-June in order to have some 
>validation tests before end of June (planned released date).
>
>So requests for integration of features which have not yet been sent will be 
>delayed to next version. Only reworks or small fixes of pending patches should 
>be accepted.
>
>A new branch "rebased-next" will be created for patches which are reviewed and 
>waiting next version. This branch will be regularly rebased on master HEAD.
>
>Being currently on vacation, I won't be very active until Monday, 9th.
>During this time, I'd like to see some reviews/acknowledgements for these
>patches:
>- socket id detection fallback
>   http://dpdk.org/ml/archives/dev/2014-April/001987.html
>- fix rte_free run time in O(n) free blocks
>   http://dpdk.org/ml/archives/dev/2014-May/002296.html 
>- fix mbuf corruption in pcap_tx
>   http://dpdk.org/ml/archives/dev/2014-May/002919.html
>- igb_uio fixes
>   http://dpdk.org/ml/archives/dev/2014-May/002428.html
>- vfio
>   http://dpdk.org/ml/archives/dev/2014-May/002914.html
>- ethernet enhancements
>   http://dpdk.org/ml/archives/dev/2014-May/002436.html
>- splitted statistics
>   http://dpdk.org/ml/archives/dev/2014-May/002707.html
>- mtu/flow control
>   http://dpdk.org/ml/archives/dev/2014-May/002752.html
>- link up/down
>   http://dpdk.org/ml/archives/dev/2014-May/002660.html
>- Tx rate limitation
>   http://dpdk.org/ml/archives/dev/2014-May/002696.html
>- lpm optimization
>   http://dpdk.org/ml/archives/dev/2014-May/002703.html
>- generic filter
>   http://dpdk.org/ml/archives/dev/2014-May/002740.html
>   http://dpdk.org/ml/archives/dev/2014-May/002577.html
>- ip_frag
>   http://dpdk.org/ml/archives/dev/2014-May/002930.html
>- distributor
>   http://dpdk.org/ml/archives/dev/2014-May/002598.html
>- link bonding
>   http://dpdk.org/ml/archives/dev/2014-May/002922.html
>- acl
>   http://dpdk.org/ml/archives/dev/2014-May/002945.html
>- packet framework
>   http://dpdk.org/ml/archives/dev/2014-May/002820.html
>
>Thanks for your participation
>--
>Thomas


Hi Thomas,

  Just Let you know that we have tested the following patches for R1.7 base on 
DPDK.org.
  They already passed our testing.
  You can find our tested-by message from the URL.
  If you want to know details , please let me know.

  Thanks
Waterman 


- Generic NIC Filter
   Patch URL: http://dpdk.org/ml/archives/dev/2014-May/002740.html  
   Tested-by URL : http://www.dpdk.org/ml/archives/dev/2014-June/003039.html 

- Fortville
   Patch URL: http://www.dpdk.org/ml/archives/dev/2014-June/003088.html 
   Tested-by URL : http://www.dpdk.org/ml/archives/dev/2014-June/003088.html 

- Packet Framework
   Patch URL: http://dpdk.org/ml/archives/dev/2014-May/002820.html 
 http://dpdk.org/ml/archives/dev/2014-June/003059.html 
   Tested-by URL : http://www.dpdk.org/ml/archives/dev/2014-June/003122.html 

- Virtio-Net Zero-Copy
   Patch URL: http://dpdk.org/ml/archives/dev/2014-May/002588.html 
   Tested-by URL : http://dpdk.org/ml/archives/dev/2014-May/002588.html 

- Virtio-Net Multi-queue
   Patch URL: http://dpdk.org/ml/archives/dev/2014-May/002958.html  
   Tested-by URL : http://dpdk.org/ml/archives/dev/2014-May/002957.html 

- Upgrade Latest ND Drivers
   Patch URL: http://dpdk.org/ml/archives/dev/2014-May/002447.html 
   Tested-by URL : http://www.dpdk.org/ml/archives/dev/2014-June/003044.html 

- Packet Distributor
   Patch URL: http://www.dpdk.org/ml/archives/dev/2014-May/002967.html 
   Tested-by URL : http://www.dpdk.org/ml/archives/dev/2014-June/003084.html 

- IPv6 Fragmentation & reassembly
   Patch URL: http://dpdk.org/ml/archives/dev/2014-May/002940.html 
   Tested-by URL : http://www.dpdk.org/ml/archives/dev/2014-June/003162.html 

- Link Bonding
   Patch URL: http://www.dpdk.org/ml/archives/dev/2014-June/003051.html  
   Tested-by URL : http://dpdk.org/ml/archives/dev/2014-June/003143.html 

- 10G PMD: vectorized RX and TX functions
   Patch URL: http://dpdk.org/ml/archives/dev/2014-May/002348.html  
   Tested-by URL : http://www.dpdk.org/ml/archives/dev/2014-June/003147.html 

-  ACL
   Patch URL: http://dpdk.org/ml/archives/dev/2014-May/002945.html 
   Tested-by URL : http://dpdk.org/ml/archives/dev/2014-June/003145.html 

- fix mbuf corruption in pcap_tx
   Patch URL: http://dpdk.org/ml/archives/dev/2014-May/002919.html 
   Tested-by URL : http://dpdk.org/ml/archives/dev/2014-June/003144.html 

- link up/down
   Patch URL: http://dpdk.org/ml/archives/dev/2014-May/0

[dpdk-dev] [PATCH 1/2] rte_tailq.h: Fix compilation under FreeBSD

[Cao, Waterman]

Tested-by: Waterman Cao 

This patch is to fix compilation error in the FreeBSD 10.0 like the followings:
.. /include/rte_tailq.h:177:21: error: unknown type name 'FILE' void 
rte_dump_tailq(FILE *f);
../include/rte_memory.h:146:30: error: unknown type name 'FILE' void 
rte_dump_physmem_layout(FILE *f);

After merged this patch with last dpdk.org, compilation can pass without error 
in FreeBSD 10.0

[dpdk-dev] [PATCH] kni: compatibility with RHEL 7

[Cao, Waterman]

Hi Shimamoto,

  Can you give details about Linux Kernel version and complier version?
  Because we tried to build code in the Redhat 7.0 before, but we don't meet 
this issue.
  Please see information as the following:
  Linux kernel 3.10.0-54.0.1.el7.x86_64
  RHEL70BETA_64 GCC 4.8.2  ICC: 14.0.0

Thanks

Waterman 

-Original Message-
>From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Hiroshi Shimamoto
>Sent: Thursday, June 12, 2014 4:10 PM
>To: dev at dpdk.org
>Cc: Hayato Momma
>Subject: [dpdk-dev] [PATCH] kni: compatibility with RHEL 7
>
>From: Hiroshi Shimamoto 
>
>Compilation in RHEL7 is failed. This fixes the build issue.
>
>RHEL7 has skb_set_hash, the kernel version is 3.10 though.
>Don't define skb_set_hash for RHEL7.
>
>Signed-off-by: Hiroshi Shimamoto 
>Reviewed-by: Hayato Momma 
>---
> lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h | 5 +
> 1 file changed, 5 insertions(+)
>
>diff --git a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h 
>b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
>index 4c27d5d..b4de6e2 100644
>--- a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
>+++ b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
>@@ -3843,6 +3843,9 @@ static inline struct sk_buff 
>*__kc__vlan_hwaccel_put_tag(struct sk_buff *skb,  #endif /* >= 3.10.0 */
> 
> #if ( LINUX_VERSION_CODE < KERNEL_VERSION(3,14,0) )
>+
>+#if (!(RHEL_RELEASE_CODE && RHEL_RELEASE_CODE >= 
>+RHEL_RELEASE_VERSION(7,0)))
>+
> #ifdef NETIF_F_RXHASH
> #define PKT_HASH_TYPE_L3 0
> static inline void
>@@ -3851,6 +3854,8 @@ skb_set_hash(struct sk_buff *skb, __u32 hash, 
>__always_unused int type)
>   skb->rxhash = hash;
> }
> #endif /* NETIF_F_RXHASH */
>+#endif /* < RHEL7 */
>+
> #endif /* < 3.14.0 */
> 
> #endif /* _KCOMPAT_H_ */
>--
>1.9.1
>

[dpdk-dev] [PATCH] ixgbe: fix compile error with gcc4.4 (used RHEL 6)

[Cao, Waterman]

Hi Thomas,

 I will work with team to see if we can improve test report.
 Because intel validation team will continue to upgrade test cases to verify 
feature,
 I think that it's still worth to verify patch or features even it has already 
integrated branch.

 Thanks
Waterman 

>-Original Message-
>From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
>Sent: Thursday, September 25, 2014 3:02 PM
>To: Tang, HaifengX
>Cc: dev at dpdk.org
>Subject: Re: [dpdk-dev] [PATCH] ixgbe: fix compile error with gcc4.4 (used 
>RHEL 6)
>
>2014-09-25 02:13, Tang, HaifengX:
>> Tested-by: Haifeng Tang
>> 
>> This patch just  includes one file, and has been tested by Intel.
>> Please see the detail information from the attachment.
>
>Attachment is filtered out. Please do not try to attach some files for the 
>mailing list.
>
>By the way, this patch has already been integrated. So this test report is not 
>really useful anymore.
>
>--
>Thomas

[dpdk-dev] Testing Summary about DPDK R2.0 RC1

[Cao, Waterman]

Hi Thomas,

We are test RC1 package with full test suite in last two weeks.
Since there are compilation errors in RC1, we have to verify latest
DPDK mater branch.
Till now, there are the following issues in master branch.
Please help to prioritize to merge fixed patches.

Thanks
waterman

Issues List:

Issue #1 (Priority H)
- Descriptions :  Errors in Centos 6.5 , Kenerl 2.6.32-431, GCC
4.4.7 / OracleLinux6.4, Kernel 2.6.39, GCC 4.4.7, ICC 14.0.0 /
RedHat6.5, Kenerl 2.6.32, GCC 4.4.7
  CC test_hash.o
cc1: warnings being treated as errors

/jenkins/workspace/DPDK_AUTO_IDT_VM_CENTOS65_64_BUILD/DPDK/app/test/test_hash.c:
In function ?test_crc32_hash_alg_equiv?:

/jenkins/workspace/DPDK_AUTO_IDT_VM_CENTOS65_64_BUILD/DPDK/x86_64-native-linuxapp-gcc/include/rte_hash_crc.h:554:
error: dereferencing pointer ?p64.354? does break strict-aliasing rules

/jenkins/workspace/DPDK_AUTO_IDT_VM_CENTOS65_64_BUILD/DPDK/x86_64-native-linuxapp-gcc/include/rte_hash_crc.h:554:
note: initialized from here

/jenkins/workspace/DPDK_AUTO_IDT_VM_CENTOS65_64_BUILD/DPDK/x86_64-native-linuxapp-gcc/include/rte_hash_crc.h:558:
error: dereferencing pointer ?p64.354? does break strict-aliasing rules

/jenkins/workspace/DPDK_AUTO_IDT_VM_CENTOS65_64_BUILD/DPDK/x86_64-native-linuxapp-gcc/include/rte_hash_crc.h:558:
note: initialized from here

/jenkins/workspace/DPDK_AUTO_IDT_VM_CENTOS65_64_BUILD/DPDK/x86_64-native-linuxapp-gcc/include/rte_hash_crc.h:554:
error: dereferencing pointer ?p64.354? does break strict-aliasing rules

/jenkins/workspace/DPDK_AUTO_IDT_VM_CENTOS65_64_BUILD/DPDK/x86_64-native-linuxapp-gcc/include/rte_hash_crc.h:554:
note: initialized from here

/jenkins/workspace/DPDK_AUTO_IDT_VM_CENTOS65_64_BUILD/DPDK/x86_64-native-linuxapp-gcc/include/rte_hash_crc.h:558:
error: dereferencing pointer ?p64.354? does break strict-aliasing rules

/jenkins/workspace/DPDK_AUTO_IDT_VM_CENTOS65_64_BUILD/DPDK/x86_64-native-linuxapp-gcc/include/rte_hash_crc.h:558:
note: initialized from here

/jenkins/workspace/DPDK_AUTO_IDT_VM_CENTOS65_64_BUILD/DPDK/x86_64-native-linuxapp-gcc/include/rte_hash_crc.h:554:
error: dereferencing pointer ?p64.354? does break strict-aliasing rules

/jenkins/workspace/DPDK_AUTO_IDT_VM_CENTOS65_64_BUILD/DPDK/x86_64-native-linuxapp-gcc/include/rte_hash_crc.h:554:
note: initialized from here

/jenkins/workspace/DPDK_AUTO_IDT_VM_CENTOS65_64_BUILD/DPDK/x86_64-native-linuxapp-gcc/include/rte_hash_crc.h:558:
error: dereferencing pointer ?p64.354? does break strict-aliasing rules

/jenkins/workspace/DPDK_AUTO_IDT_VM_CENTOS65_64_BUILD/DPDK/x86_64-native-linuxapp-gcc/include/rte_hash_crc.h:558:
note: initialized from here
gmake[5]: *** [test_hash.o] Error 1


Issue #2 (Priority H)
- Descriptions :  Errors in Suse11 , Kernel 3.0.13-0, GCC 4.3.4
 == Build lib/librte_eal/linuxapp/eal
gmake[7]: Warning: File
`/jenkins/workspace/DPDK_AUTO_IDT_VM_SUSE11SP2_64_BUILD/DPDK/mk/internal/rte.depdirs-post.mk'
has modification time 2.9e+04 s in the future
  CC eal.o
  CC eal_hugepage_info.o
  CC eal_memory.o
 CC eal_thread.o
  CC eal_log.o
  CC eal_pci.o
  CC eal_pci_uio.o
cc1: warnings being treated as errors

/jenkins/workspace/DPDK_AUTO_IDT_VM_SUSE11SP2_64_BUILD/DPDK/lib/librte_eal/linuxapp/eal/eal_pci_uio.c:
In function ?pci_uio_set_bus_master?:

/jenkins/workspace/DPDK_AUTO_IDT_VM_SUSE11SP2_64_BUILD/DPDK/lib/librte_eal/linuxapp/eal/eal_pci_uio.c:62:2:
error: implicit declaration of function ?pread?

/jenkins/workspace/DPDK_AUTO_IDT_VM_SUSE11SP2_64_BUILD/DPDK/lib/librte_eal/linuxapp/eal/eal_pci_uio.c:62:2:
error: nested extern declaration of ?pread?

/jenkins/workspace/DPDK_AUTO_IDT_VM_SUSE11SP2_64_BUILD/DPDK/lib/librte_eal/linuxapp/eal/eal_pci_uio.c:75:2:
error: implicit declaration of function ?pwrite?

/jenkins/workspace/DPDK_AUTO_IDT_VM_SUSE11SP2_64_BUILD/DPDK/lib/librte_eal/linuxapp/eal/eal_pci_uio.c:75:2:
error: nested extern declaration of ?pwrite?
gmake[7]: *** [eal_pci_uio.o] Error 1
gmake[6]: *** [eal] Error 2
gmake[5]: *** [linuxapp] Error 2
gmake[4]: *** [librte_eal] Error 2
gmake[3]: *** [lib] Error 2
gmake[2]: *** [all] Error 2

Issue #3 (Priority L)
- Descriptions :  Errors in OracleLinux6.4 32Bit OS
CC rte_eth_af_packet.o

/jenkins/workspace/DPDK_AUTO_IDT_VM_ORACLELINUX64_32_BUILD/DPDK/lib/librte_pmd_af_packet/rte_eth_af_packet.c:
In function ?eth_af_packet_rx?:

/jenkins/workspace/DPDK_AUTO_IDT_VM_ORACLELINUX64_32_BUILD/DPDK/lib/librte_pmd_af_packet/rte_eth_af_packet.c:146:
error: dereferencing pointer to incomplete type

/jenkins/workspace/DPDK_AUTO_IDT_VM_ORACLELINUX64_32_BUILD/DPDK/lib/librte_pmd_af_packet/rte_eth_af_packet.c:155:
error: dereferencing pointer to incomplete type

/jenkins/workspace/DPDK_AUTO_IDT_VM_ORACLELINUX64_32_B

[dpdk-dev] tools brainstorming

[Cao, Waterman]

On 2015/3/20 22:52, Thomas Monjalon wrote:
> Hi,
>
> As you probably know, a MAINTAINERS file is being filled, which is a great
> help to request patch reviews and discuss design with the knowledgeable people
> of this young DPDK community:
>   http://dpdk.org/browse/dpdk/tree/MAINTAINERS
>
> The next step is to clearly define what are the guidelines to review a patch
> and accept it. So let's write a new document CONTRIBUTING (or another
> capitalized file ;). It will help contributors to do the right checks
> before submitting, and will help reviewers.
>
> As we are lazy developers, writing guidelines is not enough. It must be
> coupled with the integration of some tools. Let's work on these ones:
>   - make autotests easier and faster to run for smoke testing
>   - automated basic testpmd check
>   - build check with various options combinations
>   - abi check (started with validate-abi.sh)
>   - static analyze (clang, free online coverity)
>   - comment check (doxygen, codespell, kerspell)
>   - format check (customized checkpatch)
>
> I'm sure this last item will trigger a lot of debate.
> Actually, format checking can be of two kinds:
>   - commit message formatting (how to write the title, how and when adding
>   Fixes tag, Signed-off-by tag, etc);
>   - coding style might deserve its own document.
>
> At the end, we should be able to pass a "make check" on the whole code and
> a "make checkpatch" before submitting.
> Then the result of these tools could be automatically checked and displayed
> in patchwork or in an adapted version of qemu's patchew. But this is
> obviously a later step.
> When all automatic lights are green and human design review is properly done,
> the patch can be acknowledged by one or many reviewers. Speaking about that,
> it would be helpful to have a column in our patchwork to summarize the counts
> of tests, reviews and acknowledgements.
>
> Comments and contributions are more than welcome!
>
Hi Thomas,

 That's good idea to check patch before merging it into branch.
 We can perform basic test per each patch and improve the quality of
patch.

As you knew, currently Intel DPDK test team maintained automation
test tool to perform build check and smoke test on a lot of mainstream
platforms.
It will a good chance to share these knowledge with whole DPDK
community.

- Daily Build Test
 So far, Intel test team run daily build test on CentOS6.5, Fedora
18/20/21, RedHat 6.5/7.0, SUSE 11 SP2/SP3, Ubuntu 12/14, Oracle Linux
6.4 and FreeBSD 10.
 In addition, we also verified with different compilers, kernels and
DPDK build options.
 Since Our daily build test is focus on master branch and only
monitor latest code changes.
 Maybe we don't need to check so much OS per each patch, just make
quick build check with short list.
 We can share our build script with contributors/maintainer. they
can use it to verify their patch set.

- Automated Smoke Test
   Based on DTS (DPDK test suite), we already built up automated smoke
test on FC16/18/20/21/ , Ubuntu and Redhat. it's composed of unit test
and function test for dpdk sample application.
I think that it's easy to build up automated smoke test based on
patch, we just need to define which test cases should include in the
list, and make sure if it can achieve at shortest time.

- Bug Tracking
During our test cycle, we found some defects in release candidates. 
But it's difficult to track/report them without public bug tool.
It's really helpful to get one formal tool to manage these
information and speed up bug fixing.

In addition, I think that patchwork is a good tool, which provides a
place to show test result for each patch.
But patchwork is focus on patch level, we need to think how to test
latest code branch in package level.
Finally, we are eager to share our experience of validation with DPDK
community.
We would like to contribute tool and script,  and help to improve
quality of DPDK release.

regards

Waterman

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

[Cao, Waterman]

Hi Thomas,

I think that you can integrate this patch firstly.
We will update our regression to cover new features.
Currently, Xiaonan is checking with yong and try to understand how to 
verify new features.

Thanks
Waterman 

-Original Message-
>From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] 
>Sent: Friday, November 14, 2014 6:07 AM
>To: Cao, Waterman
>Cc: dev at dpdk.org; Yong Wang; Zhang, XiaonanX
>Subject: Re: [dpdk-dev] [PATCH v2 0/6] vmxnet3 pmd fixes/improvement
>
>Hi Waterman,
>
>You wanted to update your regression tests:
>   http://dpdk.org/ml/archives/dev/2014-November/007598.html
>Should I wait a test report before integrating these patches?
>
>Is there someone else reviewing these patches?
>
>-- 
>Thomas
>
>
>2014-11-04 17:49, Yong Wang:
>> This patch series include various fixes and improvement to the
>> vmxnet3 pmd driver.
>> 
>> V2:
>> - Add more commit descriptions
>> - Add a new patch that improve tx performance for small packet
>> 
>> Yong Wang (6):
>>   vmxnet3: Fix VLAN Rx stripping
>>   vmxnet3: Add VLAN Tx offload
>>   vmxnet3: Fix dev stop/restart bug
>>   vmxnet3: Add rx pkt check offloads
>>   vmxnet3: Perf improvement on the rx path
>>   vmxnet3: Leverage data_ring on tx path

[dpdk-dev] vmxnet3 pmd dev restart

[Cao, Waterman]

Hi Rashmin,

 We found similar issue when we start/stop vmnet dev several time. (> 3 times)
 It happens kernel panic, and sometimes kernel will occur core dump.
 Let me know if you want to submit patch to fix it.

Thanks
Waterman 

-Original Message-
>From: Patel, Rashmin N 
>Sent: Friday, October 10, 2014 6:07 AM
>To: Navakanth M; stephen at networkplumber.org; Cao, Waterman
>Cc: dev at dpdk.org
>Subject: RE: vmxnet3 pmd dev restart
>
>I just quickly looked into the code and instead of releasing memory or simply 
>set it to NULL (patch: 
> http://thread.gmane.org/gmane.comp.networking.dpdk.devel/4683), you can zero 
> it out and it should work perfectly, you can give it a quick try.
>
>//rte_free(ring->buf_info);
>memset(ring->buf_info, 0x0, ring->size*sizeof(vmxnet3_buf_info_t));
>
>This will not free the memory from heap but just wipe it out to 0x0, provided 
>that we freed all the mbuf(s) pointed by each buf_info->m pointers. Hence you 
>won't need to reallocate it when you start device after this stop.
>
>Thanks,
>Rashmin
>
>-Original Message-
>From: Navakanth M [mailto:navakanthdev at gmail.com]
>Sent: Wednesday, October 08, 2014 10:11 PM
>To: stephen at networkplumber.org; Patel, Rashmin N; Cao, Waterman
>Cc: dev at dpdk.org
>Subject: Re: vmxnet3 pmd dev restart
>
>I had tried with Stephen's patch but after stop is done and when we call start 
>it crashed at vmxnet3_dev_start()->
>vmxnet3_dev_rxtx_init()->vmxnet3_post_rx_bufs() as buf_info is freed and is 
>not allocated again. buf_info is allocated in
>vmxnet3_dev_rx_queue_setup() which would be called once at the initialization 
>only.
>I also tried not freeing buf_info in stop but then i see different issue after 
>start, packets are not received due to check while (rcd->gen == 
>rxq->comp_ring.gen) { in vmxnet3_recv_pkts()
>
>Waterman, Have you got chance to test stop and start of vmnet dev if so did 
>you notice any issue similar to this?
>
>Thanks
>Navakanth
>
>On Thu, Oct 9, 2014 at 12:46 AM, Patel, Rashmin N intel.com> wrote:
>> Yes I had a local copy working with couple of lines fix. But someone else, I 
>> think Stephen added a fix patch for the same, and I assume if it's been 
>> merged, should be working, so did not follow up later.
>>
>> I don't have a VMware setup handy at moment but I think Waterman would have 
>> more information about testing that patch if he has found any issue with it.
>>
>> Thanks,
>> Rashmin
>>
>> -Original Message-
>> From: Navakanth M [mailto:navakanthdev at gmail.com]
>> Sent: Wednesday, October 08, 2014 4:14 AM
>> To: dev at dpdk.org; Patel, Rashmin N
>> Subject: Re: vmxnet3 pmd dev restart
>>
>> Hi Rashmin
>>
>> I have come across your reply in following post that you have worked on this 
>> problem and would submit the patch for it.
>> Can you please share information on the changes you worked on or patch log 
>> if you had submitted any for it?
>> http://thread.gmane.org/gmane.comp.networking.dpdk.devel/4683
>>
>> Thanks
>> Navakanth
>>
>> On Tue, Sep 30, 2014 at 1:44 PM, Navakanth M  
>> wrote:
>>> Hi
>>>
>>> I am using DPDKv1.7.0 running on Vmware Esxi 5.1 and am trying to 
>>> reset the port which uses pmd_vmnet3 library functions from below 
>>> function calls.
>>> rte_eth_dev_stop
>>> rte_eth_dev_start
>>>
>>> Doing this, i face panic while rte_free(ring->buf_info) in 
>>> Vmxnet3_cmd_ring_release().
>>> I have gone through following thread but the patch mentioned didn't 
>>> help rather it crashed in start function while accessing buf_info in 
>>> vmxnet3_post_rx_bufs. I see this buf_info is allocated in queue setup 
>>> functions which are called at initialization.
>>> http://thread.gmane.org/gmane.comp.networking.dpdk.devel/4683
>>>
>>> I tried not freeing it and then rx packets are not received due to 
>>> mismatch in while (rcd->gen == rxq->comp_ring.gen) in
>>> vmxnet3_recv_pkts()
>>>
>>> To reset the device port, is this the right way what i am doing?
>>> Or do I have to call vmxnet3_dev_tx_queue_setup()
>>> vmxnet3_dev_rx_queue_setup() once stop is called? I have checked 
>>> recent patches and threads but did not get much information on this.
>>>
>>> Thanks
>>> Navakanth

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

[Cao, Waterman]

Hi Yong,

We verified your patch with VMWare ESXi 5.5 and found VMware L2fwd and 
L3fwd cmd can't run.
But We use DPDK1.7_rc1 package to validate VMware regression, It works fine.
. 
1.[Test Environment]:
 - VMware ESXi 5.5;
 - 2 VM
 - FC20 on Host / FC20-64 on VM
 - Crown Pass server (E2680 v2 ivy bridge )
 - Niantic 82599

2. [Test Topology]:
Create 2VMs (Fedora 18, 64bit) .
We pass through one physical port(Niantic 82599) to each VM, and also 
create one virtual device: vmxnet3 in each VM. 
To connect with two VMs, we use one vswitch to connect two vmxnet3 
interface.
Then, PF1 and vmxnet3A are in VM1; PF2 and vmxnet3B are in VM2.
The traffic flow for l2fwd/l3fwd is as below::
Ixia -> PF1 -> vmxnet3A -> vswitch -> vmxnet3B -> PF2 -> Ixia. (traffic 
generator)

3.[ Test Step]:

tar dpdk1.8.rc1 ,compile and run;

L2fwd:  ./build/l2fwd -c f -n 4 -- -p 0x3
L3fwd:  ./build/l3fwd-vf -c 0x6 -n 4 -- -p 0x3 -config "(0,0,1),(1,0,2)"

4.[Error log]:

---VMware L2fwd:---

EAL:   :0b:00.0 not managed by UIO driver, skipping
EAL: PCI device :13:00.0 on NUMA socket -1
EAL:   probe driver: 8086:10fb rte_ixgbe_pmd
EAL:   PCI memory mapped at 0x7f678ae6e000
EAL:   PCI memory mapped at 0x7f678af34000
PMD: eth_ixgbe_dev_init(): MAC: 2, PHY: 17, SFP+: 5
PMD: eth_ixgbe_dev_init(): port 0 vendorID=0x8086 deviceID=0x10fb
EAL: PCI device :1b:00.0 on NUMA socket -1
EAL:   probe driver: 15ad:7b0 rte_vmxnet3_pmd
EAL:   PCI memory mapped at 0x7f678af33000
EAL:   PCI memory mapped at 0x7f678af32000
EAL:   PCI memory mapped at 0x7f678af3
Lcore 0: RX port 0
Lcore 1: RX port 1
Initializing port 0... PMD: ixgbe_dev_rx_queue_setup(): sw_ring=0x7f670b0f5580 
hw_ring=0x7f6789fe5280 dma_addr=0x373e5280
PMD: ixgbe_dev_rx_queue_setup(): Rx Burst Bulk Alloc Preconditions are 
satisfied. Rx Burst Bulk Alloc function will be used on port=0, queue=0.
PMD: ixgbe_dev_rx_queue_setup(): Vector rx enabled, please make sure RX burst 
size no less than 32.
PMD: ixgbe_dev_tx_queue_setup(): sw_ring=0x7f670b0f3480 hw_ring=0x7f671b820080 
dma_addr=0x100020080
PMD: ixgbe_dev_tx_queue_setup(): Using simple tx code path
PMD: ixgbe_dev_tx_queue_setup(): Vector tx enabled.
done: 
Port 0, MAC address: 90:E2:BA:4A:33:78

Initializing port 1... EAL: Error - exiting with code: 1
  Cause: rte_eth_tx_queue_setup:err=-22, port=1

---VMware L3fwd:---

EAL: TSC frequency is ~2793265 KHz
EAL: Master core 1 is ready (tid=9f49a880)
EAL: Core 2 is ready (tid=1d7f2700)
EAL: PCI device :0b:00.0 on NUMA socket -1
EAL:   probe driver: 15ad:7b0 rte_vmxnet3_pmd
EAL:   :0b:00.0 not managed by UIO driver, skipping
EAL: PCI device :13:00.0 on NUMA socket -1
EAL:   probe driver: 8086:10fb rte_ixgbe_pmd
EAL:   PCI memory mapped at 0x7f079f3e4000
EAL:   PCI memory mapped at 0x7f079f4aa000
PMD: eth_ixgbe_dev_init(): MAC: 2, PHY: 17, SFP+: 5
PMD: eth_ixgbe_dev_init(): port 0 vendorID=0x8086 deviceID=0x10fb
EAL: PCI device :1b:00.0 on NUMA socket -1
EAL:   probe driver: 15ad:7b0 rte_vmxnet3_pmd
EAL:   PCI memory mapped at 0x7f079f4a9000
EAL:   PCI memory mapped at 0x7f079f4a8000
EAL:   PCI memory mapped at 0x7f079f4a6000
Initializing port 0 ... Creating queues: nb_rxq=1 nb_txq=1...  
Address:90:E2:BA:4A:33:78, Allocated mbuf pool on socket 0
LPM: Adding route 0x01010100 / 24 (0)
LPM: Adding route 0x02010100 / 24 (1)
LPM: Adding route 0x03010100 / 24 (2)
LPM: Adding route 0x04010100 / 24 (3)
LPM: Adding route 0x05010100 / 24 (4)
LPM: Adding route 0x06010100 / 24 (5)
LPM: Adding route 0x07010100 / 24 (6)
LPM: Adding route 0x08010100 / 24 (7)
txq=0,0,0 PMD: ixgbe_dev_tx_queue_setup(): sw_ring=0x7f071f6f3c80 
hw_ring=0x7f079e5e5280 dma_addr=0x373e5280
PMD: ixgbe_dev_tx_queue_setup(): Using simple tx code path
PMD: ixgbe_dev_tx_queue_setup(): Vector tx enabled.

Initializing port 1 ... Creating queues: nb_rxq=1 nb_txq=1...  
Address:00:0C:29:F0:90:41, txq=1,0,0 EAL: Error - exiting with code: 1
  Cause: rte_eth_tx_queue_setup: err=-22, port=1


Can you help to recheck this patch with latest DPDK code?

Regards
Waterman 

-Original Message-
>From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Yong Wang
>Sent: Wednesday, October 22, 2014 6:10 AM
>To: Patel, Rashmin N; Stephen Hemminger
>Cc: dev at dpdk.org
>Subject: Re: [dpdk-dev] [PATCH 0/5] vmxnet3 pmd fixes/improvement
>
>Rashmin/Stephen,
>
>Since you have worked on vmxnet3 pmd drivers, I wonder if you can help review 
>this set of patches.  Any other reviews/test verifications are welcome of 
>course.  We have reviewed/tested all patches internally.
>
>Yong
>
>From: dev  on behalf of Yong Wang vmware.com>
>Sent: Monday, October 13, 2014 2:00 PM
>To: Thomas Monjalon
>Cc: dev at dpdk.org
>Subject: Re: [dpdk-dev] [PATCH 0/5] vmxnet3 pmd fixes/improvement
>
>Only the last one is performance related and it merely tries to give hints to 
>the compiler to hopefully make branch prediction more efficient.  It also 
>

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

[Cao, Waterman]

Hi Yong,

Let us recheck it again with your instruction.
I will response your questions once we get result.

Thanks
Waterman 


>-Original Message-
>From: Yong Wang [mailto:yongwang at vmware.com] 
>Sent: Wednesday, October 29, 2014 3:59 AM
>To: Thomas Monjalon
>Cc: dev at dpdk.org; Cao, Waterman
>Subject: RE: [dpdk-dev] [PATCH 0/5] vmxnet3 pmd fixes/improvement
>
>Thomas/Waterman,
>
>I couldn't reproduce the reported issue on v1.8.0-rc1 and both l2fwd and l3fwd 
>works fine using the same command posted.
>
># dpdk_nic_bind.py --status
>
>Network devices using DPDK-compatible driver 
>
>:0b:00.0 'VMXNET3 Ethernet Controller' drv=igb_uio unused=
>:13:00.0 'VMXNET3 Ethernet Controller' drv=igb_uio unused=
>
>Network devices using kernel driver
>===
>:02:00.0 '82545EM Gigabit Ethernet Controller (Copper)' if=eth2 drv=e1000 
>unused=igb_uio *Active*
>
>Other network devices
>=
>
>
>#  ./build/l3fwd-vf -c 0x6 -n 4 -- -p 0x3 -config "(0,0,1),(1,0,2)"
>...
>EAL: TSC frequency is ~2800101 KHz
>EAL: Master core 1 is ready (tid=ee3c6840)
>EAL: Core 2 is ready (tid=de1ff700)
>EAL: PCI device :02:00.0 on NUMA socket -1
>EAL:   probe driver: 8086:100f rte_em_pmd
>EAL:   :02:00.0 not managed by UIO driver, skipping
>EAL: PCI device :0b:00.0 on NUMA socket -1
>EAL:   probe driver: 15ad:7b0 rte_vmxnet3_pmd
>EAL:   PCI memory mapped at 0x7f8bee3dd000
>EAL:   PCI memory mapped at 0x7f8bee3dc000
>EAL:   PCI memory mapped at 0x7f8bee3da000
>EAL: PCI device :13:00.0 on NUMA socket -1
>EAL:   probe driver: 15ad:7b0 rte_vmxnet3_pmd
>EAL:   PCI memory mapped at 0x7f8bee3d9000
>EAL:   PCI memory mapped at 0x7f8bee3d8000
>EAL:   PCI memory mapped at 0x7f8bee3d6000
>Initializing port 0 ... Creating queues: nb_rxq=1 nb_txq=1...  
>Address:00:0C:29:72:C6:7E, Allocated mbuf pool on socket 0
>LPM: Adding route 0x01010100 / 24 (0)
>LPM: Adding route 0x02010100 / 24 (1)
>LPM: Adding route 0x03010100 / 24 (2)
>LPM: Adding route 0x04010100 / 24 (3)
>LPM: Adding route 0x05010100 / 24 (4)
>LPM: Adding route 0x06010100 / 24 (5)
>LPM: Adding route 0x07010100 / 24 (6)
>LPM: Adding route 0x08010100 / 24 (7)
>txq=0,0,0
>Initializing port 1 ... Creating queues: nb_rxq=1 nb_txq=1...  
>Address:00:0C:29:72:C6:88, txq=1,0,0 
>
>Initializing rx queues on lcore 1 ... rxq=0,0,0 Initializing rx queues on 
>lcore 2 ... rxq=1,0,0
>done: Port 0
>done: Port 1
>L3FWD: entering main loop on lcore 2
>L3FWD:  -- lcoreid=2 portid=1 rxqueueid=0
>L3FWD: entering main loop on lcore 1
>L3FWD:  -- lcoreid=1 portid=0 rxqueueid=0
>
>I don't have the exact setup but I suspect this is related as the errors looks 
>like a tx queue param used is not supported by vmxnet3 backend.  The patchset 
>does not touch the txq config path so it's not clear how it breaks 
>rte_eth_tx_queue_setup().  So my question to Waterman:
>(1) Is this a regression on the same branch, i.e. running the unpatched build 
>works but failed with the patch applied?
>(2) By any chance did you change the following struct in main.c for those 
>sample programs to a different value, in particular txq_flags?
>
>static const struct rte_eth_txconf tx_conf = {
>.tx_thresh = {
>.pthresh = TX_PTHRESH,
>.hthresh = TX_HTHRESH,
>.wthresh = TX_WTHRESH,
>},
>.tx_free_thresh = 0, /* Use PMD default values */
>.tx_rs_thresh = 0, /* Use PMD default values */
>.txq_flags = (ETH_TXQ_FLAGS_NOMULTSEGS |   <== any changes here?
>  ETH_TXQ_FLAGS_NOVLANOFFL |
>  ETH_TXQ_FLAGS_NOXSUMSCTP |
>  ETH_TXQ_FLAGS_NOXSUMUDP |
>  ETH_TXQ_FLAGS_NOXSUMTCP) };
>
>Thanks,
>Yong
>
>From: Thomas Monjalon 
>Sent: Tuesday, October 28, 2014 7:40 AM
>To: Yong Wang
>Cc: dev at dpdk.org; Cao, Waterman
>Subject: Re: [dpdk-dev] [PATCH 0/5] vmxnet3 pmd fixes/improvement
>
>Hi Yong,
>
>Is there any progress with this patchset?
>
>Thanks
>--
>Thomas
>
>2014-10-22 07:07, Cao, Waterman:
>> Hi Yong,
>>
>>   We verified your patch with VMWare ESXi 5.5 and found VMware L2fwd and 
>> L3fwd cmd can't run.
>> But We use DPDK1.7_rc1 package to validate VMware regression, It works 
>> fine.
>> .
>> 1.[Test Environment]:
>>  - VMware ESXi 5.5;
>>  - 2 VM
>>  - FC20 on Host / FC20-64 on VM
>>  - Crown Pass server (E2680 v2 ivy bridge )
>>  - Niantic 82599
>&

[dpdk-dev] [PATCH] kni: fix compile issue on different kernel versions

[Cao, Waterman]

Hi Haifeng,

Can you verify helin's patch and acknowledge it if it works fine?

Thanks
Waterman 

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Helin Zhang
Sent: Monday, November 9, 2015 2:26 PM
To: dev at dpdk.org
Subject: [dpdk-dev] [PATCH] kni: fix compile issue on different kernel versions

It fixes the compile issue on kernel version 2.6.32 or old ones.

Error logs:
lib/librte_eal/linuxapp/kni/kni_misc.c:121: error: unknown field id specified 
in initializer
lib/librte_eal/linuxapp/kni/kni_misc.c:121: error: excess elements in struct 
initializer
lib/librte_eal/linuxapp/kni/kni_misc.c:121: error: (near initialization for 
kni_net_ops)
lib/librte_eal/linuxapp/kni/kni_misc.c:122: error: unknown field size specified 
in initializer
lib/librte_eal/linuxapp/kni/kni_misc.c:122: error: excess elements in struct 
initializer
lib/librte_eal/linuxapp/kni/kni_misc.c:122: error: (near initialization for 
kni_net_ops)

Fixes: 72a7a2b2469e ("kni: allow per-net instances")

Signed-off-by: Helin Zhang 
---
 lib/librte_eal/linuxapp/kni/kni_misc.c | 47 --
 1 file changed, 45 insertions(+), 2 deletions(-)

diff --git a/lib/librte_eal/linuxapp/kni/kni_misc.c 
b/lib/librte_eal/linuxapp/kni/kni_misc.c
index 635e18f..f5f18f0 100644
--- a/lib/librte_eal/linuxapp/kni/kni_misc.c
+++ b/lib/librte_eal/linuxapp/kni/kni_misc.c
@@ -22,6 +22,7 @@
  *   Intel Corporation
  */

+#include 
 #include 
 #include 
 #include 
@@ -102,9 +103,20 @@ struct kni_net {
struct list_head kni_list_head;
 };

-static __net_init int kni_init_net(struct net *net)
+static int __net_init kni_init_net(struct net *net)
 {
+#if LINUX_VERSION_CODE > KERNEL_VERSION(2, 6, 32)
struct kni_net *knet = net_generic(net, kni_net_id);
+#else
+   struct kni_net *knet;
+   int ret;
+
+   knet = kmalloc(sizeof(struct kni_net), GFP_KERNEL);
+   if (!knet) {
+   ret = -ENOMEM;
+   return ret;
+   }
+#endif /* LINUX_VERSION_CODE > KERNEL_VERSION(2, 6, 32) */

/* Clear the bit of device in use */
clear_bit(KNI_DEV_IN_USE_BIT_NUM, &knet->device_in_use); @@ -112,14 
+124,33 @@ static __net_init int kni_init_net(struct net *net)
init_rwsem(&knet->kni_list_lock);
INIT_LIST_HEAD(&knet->kni_list_head);

+#if LINUX_VERSION_CODE > KERNEL_VERSION(2, 6, 32)
return 0;
+#else
+   ret = net_assign_generic(net, kni_net_id, knet);
+   if (ret < 0)
+   kfree(knet);
+
+   return ret;
+#endif /* LINUX_VERSION_CODE > KERNEL_VERSION(2, 6, 32) */ }
+
+static void __net_exit kni_exit_net(struct net *net) { #if 
+LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 32)
+   struct kni_net *knet = net_generic(net, kni_net_id);
+
+   kfree(knet);
+#endif /* LINUX_VERSION_CODE > KERNEL_VERSION(2, 6, 32) */
 }

 static struct pernet_operations kni_net_ops = {
.init = kni_init_net,
-   .exit = NULL,
+   .exit = kni_exit_net,
+#if LINUX_VERSION_CODE > KERNEL_VERSION(2, 6, 32)
.id   = &kni_net_id,
.size = sizeof(struct kni_net),
+#endif /* LINUX_VERSION_CODE > KERNEL_VERSION(2, 6, 32) */
 };

 static int __init
@@ -134,7 +165,11 @@ kni_init(void)
return -EINVAL;
}

+#if LINUX_VERSION_CODE > KERNEL_VERSION(2, 6, 32)
rc = register_pernet_subsys(&kni_net_ops);
+#else
+   rc = register_pernet_gen_subsys(&kni_net_id, &kni_net_ops); #endif /* 
+LINUX_VERSION_CODE > KERNEL_VERSION(2, 6, 32) */
if (rc)
return -EPERM;

@@ -152,7 +187,11 @@ kni_init(void)
return 0;

 out:
+#if LINUX_VERSION_CODE > KERNEL_VERSION(2, 6, 32)
unregister_pernet_subsys(&kni_net_ops);
+#else
+   register_pernet_gen_subsys(&kni_net_id, &kni_net_ops); #endif /* 
+LINUX_VERSION_CODE > KERNEL_VERSION(2, 6, 32) */
return rc;
 }

@@ -160,7 +199,11 @@ static void __exit
 kni_exit(void)
 {
misc_deregister(&kni_misc);
+#if LINUX_VERSION_CODE > KERNEL_VERSION(2, 6, 32)
unregister_pernet_subsys(&kni_net_ops);
+#else
+   register_pernet_gen_subsys(&kni_net_id, &kni_net_ops); #endif /* 
+LINUX_VERSION_CODE > KERNEL_VERSION(2, 6, 32) */
KNI_PRINT("### DPDK kni module unloaded  ###\n");  }

--
1.8.1.4

[dpdk-dev] [PATCH v5 1/7] ethdev: add additional ieee1588 support functions

[Cao, Waterman]

Hi Thomas,

Marvin has already tested the patches with a recent HEAD release of DPDK and 
are ready to test them as part of RC2. As you say the changes are localized to 
the Intel drivers and from our review they look like low risk of breaking 
anything else.

Thanks
Waterman

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Liu, Yong
Sent: Tuesday, November 10, 2015 11:18 PM
To: Mcnamara, John; Thomas Monjalon
Cc: dev at dpdk.org
Subject: Re: [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.