from:"Cao, Waterman"

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

2015-11-11 Thread 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.

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

2015-11-09 Thread 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, >device_in_use); @@ -112,14 
+124,33 @@ static __net_init int kni_init_net(struct net *net)
init_rwsem(>kni_list_lock);
INIT_LIST_HEAD(>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   = _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(_net_ops);
+#else
+   rc = register_pernet_gen_subsys(_net_id, _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(_net_ops);
+#else
+   register_pernet_gen_subsys(_net_id, _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(_misc);
+#if LINUX_VERSION_CODE > KERNEL_VERSION(2, 6, 32)
unregister_pernet_subsys(_net_ops);
+#else
+   register_pernet_gen_subsys(_net_id, _net_ops); #endif /* 
+LINUX_VERSION_CODE > KERNEL_VERSION(2, 6, 32) */
KNI_PRINT("### DPDK kni module unloaded  ###\n");  }

--
1.8.1.4

[dpdk-dev] tools brainstorming

2015-03-23 Thread 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] Testing Summary about DPDK R2.0 RC1

2015-03-13 Thread 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

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

2014-12-18 Thread 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] [PATCH 0/5] vmxnet3 pmd fixes/improvement

2014-11-05 Thread 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

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

2014-10-22 Thread 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] vmxnet3 pmd dev restart

2014-10-10 Thread 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] [RFT] vmxnet3 testing needed

2014-08-26 Thread 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 v3] lib/librte_vhost: user space vhost driver library

2014-08-07 Thread 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] Build failure on Ubuntu 14.04

2014-07-08 Thread 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] Build failure on Ubuntu 14.04

2014-07-07 Thread 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

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

2014-07-02 Thread 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] [PATCH] test: Remove NULL snprintf tests in cmdline unit test

2014-07-01 Thread Cao, Waterman

Tested-by: Waterman Cao 

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

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

2014-06-30 Thread 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] kni: compatibility with RHEL 7

2014-06-30 Thread 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.org] On B

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

2014-06-26 Thread 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

2014-06-25 Thread 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 v4 0/4] NIC filters support for generic filter

2014-06-16 Thread 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

2014-06-12 Thread 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 1/2] rte_tailq.h: Fix compilation under FreeBSD

2014-06-10 Thread 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] IMPORTANT: feature freeze for version 1.7.0

2014-06-09 Thread 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:

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

2014-06-06 Thread 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] fix for eth_pcap_tx() can cause mbuf corruption

2014-06-06 Thread Cao, Waterman

Tested-by: Waterman Cao

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

2014-06-05 Thread 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] [v2 00/23] Packet Framework

2014-06-05 Thread 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 0/3] Support setting link up and link down

2014-06-04 Thread 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/4] NIC filters support for generic filter

2014-06-04 Thread 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 v5 1/7] ethdev: add additional ieee1588 support functions

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

[dpdk-dev] tools brainstorming

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

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

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

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

[dpdk-dev] vmxnet3 pmd dev restart

[dpdk-dev] [RFT] vmxnet3 testing needed

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

[dpdk-dev] Build failure on Ubuntu 14.04

[dpdk-dev] Build failure on Ubuntu 14.04

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

28 matches

Site Navigation

Mail list logo

Footer information