[dpdk-users] Problem building DPDK libraries

[Pavey, Nicholas]

I don?t install in the default path. I do something like this:


  export RTE_SDK=/dpdk-16.04
  export DESTDIR=/install"
  export RTE_TARGET=x86_64-native-linuxapp-gcc

  make clean install

That normally works for me on an Ubuntu 14.04 based machine.

Nick


From: David Aldrich <david.aldr...@emea.nec.com>
Date: Thursday, November 17, 2016 at 12:02 PM
To: "Wiles, Keith" 
Cc: "Pavey, Nicholas" , Thomas Monjalon , "users at dpdk.org" 
Subject: RE: [dpdk-users] Problem building DPDK libraries

You are all very helpful. Thank you.

I'm afraid 'make install' isn't working:

# make install
make[1]: Nothing to be done for 'pre_install'.
== Installing /usr/local/
cp: cannot stat 'build/lib/*': No such file or directory
/root/dpdk-2.2.0/mk/rte.sdkinstall.mk:116: recipe for target 'install-runtime' 
failed
make[3]: *** [install-runtime] Error 1

David

-Original Message-
From: Wiles, Keith [mailto:keith.wi...@intel.com]
Sent: 17 November 2016 17:00
To: David Aldrich mailto:David.Aldrich at 
EMEA.NEC.COM>>
Cc: Pavey, Nicholas mailto:npavey at akamai.com>>; Thomas 
Monjalon
mailto:thomas.monjalon at 6wind.com>>; users at 
dpdk.org<mailto:users at dpdk.org>
Subject: Re: [dpdk-users] Problem building DPDK libraries
> On Nov 17, 2016, at 10:56 AM, David Aldrich
mailto:David.Aldrich at EMEA.NEC.COM>> wrote:
>
> Thanks.
>
> Do I need to do ?make install? or is ?make? sufficient?
I do not really install DPDK, but use it from the source tree. If you want to 
install
it then look at the docs, it talks about install the binaries. The install is 
handy
with the T= option only to make sure you build the correct version and ignore
the warning at the end.
>
> David
>
> From: Pavey, Nicholas [mailto:npavey at akamai.com]
> Sent: 17 November 2016 16:55
> To: David Aldrich mailto:David.Aldrich at 
> EMEA.NEC.COM>>; Wiles, Keith
> mailto:keith.wiles at intel.com>>
> Cc: Thomas Monjalon mailto:thomas.monjalon at 
> 6wind.com>>; users at dpdk.org<mailto:users at dpdk.org>
> Subject: Re: [dpdk-users] Problem building DPDK libraries
>
> Yes, I?ve found that ?j causes problems too.
>
> I believe I?ve used both the T= and the environment variable version
without problems, as long as :
>
> ?You don?t use parallel make (-j)
> ?You completely remove the target directory before building (this has 
> the
same name as ?T?)
> o   I don?t recall exactly the problem this addressed, but I did find that 
> doing a
completely clean build is sometimes necessary.
>
> Thanks,
>
>
> Nick
>
>
> From: David Aldrich mailto:David.Aldrich at 
> EMEA.NEC.COM>>
> Date: Thursday, November 17, 2016 at 11:47 AM
> To: David Aldrich mailto:David.Aldrich at 
> EMEA.NEC.COM>>, "Wiles, Keith"
> mailto:keith.wiles at intel.com>>
> Cc: Thomas Monjalon mailto:thomas.monjalon at 
> 6wind.com>>, "users at dpdk.org<mailto:users at dpdk.org>"
> mailto:users at dpdk.org>>
> Subject: Re: [dpdk-users] Problem building DPDK libraries
>
> Hi
>
> I find that:
>
>   make
>
> succeeds.
>
> But I've been advised to run:
>
>   make -j T=x86_64-native-linuxapp-gcc install
>
> I think '-j' was causing the compiler problems, so I can drop that.
>
> Do I need the 'T=' part?
>
> How would I do:
>
>   make install
>
> ? That doesn't work currently for me.
>
> David
>
> -Original Message-
> From: David Aldrich
> Sent: 17 November 2016 16:29
> To: 'David Aldrich' mailto:David.Aldrich at 
> emea.nec.com>>; Wiles, Keith
> mailto:keith.wiles at intel.com>>
> Cc: Thomas Monjalon mailto:thomas.monjalon at 
> 6wind.com>>; users at dpdk.org<mailto:users at dpdk.org>
> Subject: RE: [dpdk-users] Problem building DPDK libraries The
> allocation for /tmp is 7.9G, which is almost entirely unused.
> David
> > -Original Message-
> > From: users [mailto:users-bounces at dpdk.org] On Behalf Of David
> > Aldrich
> > Sent: 17 November 2016 16:25
> > To: Wiles, Keith mailto:keith.wiles at intel.com>>
> > Cc: Thomas Monjalon mailto:thomas.monjalon at 
> > 6wind.com>>; users at dpdk.org<mailto:users at dpdk.org>
> > Subject: Re: [dpdk-users] Problem building DPDK libraries
> >
> > Hi
> >
> > I'm using:
> >
> > # gcc --version
> > gcc (Wind River Linux 5.2.0-8.0-intel-haswell-64) 5.2.0
> >
> > I'll consider the tmp space.
> >
> > Thanks
> >
> > David
> >
> > > -Original Message-
> > > From: Wiles, Keith [mailto:keith.wiles at intel.com]
> > > Se

[dpdk-users] Problem building DPDK libraries

[Pavey, Nicholas]

Yes, I?ve found that ?j causes problems too.

I believe I?ve used both the T= and the environment variable version without 
problems, as long as :


? You don?t use parallel make (-j)

? You completely remove the target directory before building (this has 
the same name as ?T?)

oI don?t recall exactly the problem this addressed, but I did find that 
doing a completely clean build is sometimes necessary.

Thanks,


Nick


From: David Aldrich 
Date: Thursday, November 17, 2016 at 11:47 AM
To: David Aldrich , "Wiles, Keith" 
Cc: Thomas Monjalon , "users at dpdk.org" 
Subject: Re: [dpdk-users] Problem building DPDK libraries

Hi

I find that:

  make

succeeds.

But I've been advised to run:

  make -j T=x86_64-native-linuxapp-gcc install

I think '-j' was causing the compiler problems, so I can drop that.

Do I need the 'T=' part?

How would I do:

  make install

? That doesn't work currently for me.

David

-Original Message-
From: David Aldrich
Sent: 17 November 2016 16:29
To: 'David Aldrich' mailto:David.Aldrich at 
emea.nec.com>>; Wiles, Keith
mailto:keith.wiles at intel.com>>
Cc: Thomas Monjalon mailto:thomas.monjalon at 
6wind.com>>; users at dpdk.org
Subject: RE: [dpdk-users] Problem building DPDK libraries
The allocation for /tmp is 7.9G, which is almost entirely unused.
David
> -Original Message-
> From: users [mailto:users-bounces at dpdk.org] On Behalf Of David Aldrich
> Sent: 17 November 2016 16:25
> To: Wiles, Keith mailto:keith.wiles at intel.com>>
> Cc: Thomas Monjalon mailto:thomas.monjalon at 
> 6wind.com>>; users at dpdk.org
> Subject: Re: [dpdk-users] Problem building DPDK libraries
>
> Hi
>
> I'm using:
>
> # gcc --version
> gcc (Wind River Linux 5.2.0-8.0-intel-haswell-64) 5.2.0
>
> I'll consider the tmp space.
>
> Thanks
>
> David
>
> > -Original Message-
> > From: Wiles, Keith [mailto:keith.wiles at intel.com]
> > Sent: 17 November 2016 16:10
> > To: David Aldrich mailto:David.Aldrich at 
> > EMEA.NEC.COM>>
> > Cc: Thomas Monjalon mailto:thomas.monjalon at 
> > 6wind.com>>; users at dpdk.org
> > Subject: Re: [dpdk-users] Problem building DPDK libraries
> >
> >
> > > On Nov 17, 2016, at 10:05 AM, David Aldrich
> > mailto:David.Aldrich at EMEA.NEC.COM>> wrote:
> > >
> > > Thanks, I thought I had installed the kernel headers, but I had
> > > done it
> > incorrectly.  Now fixed.
> > >
> > > But make is still failing:
> > >
> > >  CC ixgbe_rxtx_vec_sse.o
> > > gcc: internal compiler error: Killed (program cc1) Please submit a
> > > full bug report, with preprocessed source if appropriate.
> > > See mailto:support at windriver.com>> for 
> > > instructions.
> > > /root/dpdk-stable-16.07.1/mk/internal/rte.compile-pre.mk:138:
> > > recipe for target 'rte_eth_af_packet.o? failed
> >
> > What version of GCC?
> >
> > When I see this type of error it is sometimes not enough tmp space
> > to compile the file, just a thought.
> >
> > > make[6]: *** [rte_eth_af_packet.o] Error 4
> > > /root/dpdk-stable-16.07.1/mk/rte.subdir.mk:61: recipe for target
> > > 'af_packet' failed
> > > make[5]: *** [af_packet] Error 2
> > > make[5]: *** Waiting for unfinished jobs
> > >
> > > Best regards
> > >
> > > David
> > >
> > >> -Original Message-
> > >> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > >> Sent: 17 November 2016 16:00
> > >> To: David Aldrich mailto:David.Aldrich at 
> > >> EMEA.NEC.COM>>
> > >> Cc: users at dpdk.org
> > >> Subject: Re: [dpdk-users] Problem building DPDK libraries
> > >>
> > >> 2016-11-17 15:51, David Aldrich:
> > >>> make[6]: *** /lib/modules/4.1.21-rt13-WR8.0.0.10_preempt-rt/build:
> > >>> No such
> > >> file or directory.  Stop.
> > >>
> > >> You need the kernel headers, or just disable compilation of kernel
modules:
> > >>sed -ri 's,(KNI_KMOD=).*,\1n,' build/.config
> > >>sed -ri 's,(IGB_UIO=).*,\1n,' build/.config
> > >>
> > >>
> > >>
> > >> Click
> > >>
> >
>
https://www.mailcontrol.com/sr/4ZSg1SI7T87GX2PQPOmvUstiqgZjxB51m1JQqZ
> > >> njH0BFwQAIYudV!69Vnv0C8JC0YknPHNppj5zLq66BGWNXYg==  to report
> this
> > >> email as spam.
> >
> > Regards,
> > Keith

[dpdk-users] Is DPDK compatible with C++11 threads?

[Pavey, Nicholas]

Yes, agreed. We only use the STL in general purpose code, not the DPDK fast 
path.

Nick

From: Anupam Kapoor <anupam.kap...@gmail.com>
Date: Wednesday, November 9, 2016 at 11:14 PM
To: "Wiles, Keith" 
Cc: David Aldrich , "Pavey, Nicholas" , "users at dpdk.org" 
Subject: Re: [dpdk-users] Is DPDK compatible with C++11 threads?


On Thu, Nov 10, 2016 at 2:30 AM, Wiles, Keith mailto:keith.wiles at intel.com>> wrote:
Also look at one of the DPDK examples as it uses a lthread on top of pthreads 
and it may give you some ideas as to how multiple threads can work. I am trying 
to remember which example and my dev machine is down at this time, but just 
search for lthread.

?this one: 
?http://dpdk.org/doc/guides/sample_app_ug/performance_thread.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__dpdk.org_doc_guides_sample-5Fapp-5Fug_performance-5Fthread.html=DgMFaQ=96ZbZZcaMF4w0F4jpN6LZg=ssgET6RyiWLuSGT5U4X0s-CtLYP5dr-AKGa5XH84zdM=7hZrbWDcflak8oiYezM8ikKmkjXi6bqa-uc-Tj8hzsE=Q6FKkqcR_EKo71KN5FKQYQEJGU--5ZdNjkqs5hLKk34=>

one more thing that you probably need to watch out for would be libc 
interactions within your C++11 application e.g. usage of stl containers might 
exact a severe performance penalty...

--
kind regards
anupam


In the beginning was the lambda, and the lambda was with Emacs, and Emacs was 
the lambda.

[dpdk-users] Is DPDK compatible with C++11 threads?

[Pavey, Nicholas]

I?ve built the DPDK along with code in both C and C++. It works fine as long as 
you get the linkage between the languages correct and make sure that you don?t 
pass C++ headers into files compiled with the C compiler.

I did try building the DPDK itself with the ?g++? compiler (v4.8.4, Ubuntu 
14.04, 64bit), and I wasn?t able to get that working out of the box. I got 
hundreds of warnings, but I didn?t take the time to debug it ? it?s possible 
that a few point fixes in the build system / DPDK code might yield a clean 
compile.

Thanks,


Nick

From: "Wiles, Keith" 
Date: Tuesday, November 8, 2016 at 12:04 PM
To: David Aldrich 
Cc: "users at dpdk.org" 
Subject: Re: [dpdk-users] Is DPDK compatible with C++11 threads?


On Nov 8, 2016, at 5:12 AM, David Aldrich mailto:David.Aldrich at EMEA.NEC.COM>> wrote:
Hi
As a beginner with DPDK, I want to consider how we can convert an existing 
Linux application from using the kernel network stack to using DPDK.
This existing app is multi-threaded, using the C++11 thread, mutex etc. 
classes.  We assign threads to cores by calling pthread_setaffinity_np().
I have looked at the DPDK helloworld application and see that it launches 
threads using the DPDK API:
   /* call lcore_hello() on every slave lcore */
   RTE_LCORE_FOREACH_SLAVE(lcore_id) {
  rte_eal_remote_launch(lcore_hello, NULL, 
lcore_id);
   }
If we use DPDK, can we retain our existing C++11 threads or are we obliged to 
use the DPDK threading APIs exclusively?

You should be able to use the standard C++11 threads I believe, in DPDK we are 
just using pthreads and set affinity to lock a thread to a core. You can still 
use pthreads in your application.

Perhaps a more basic question is applicable: is DPDK compatible with C++?

I believe building DPDK with C++ code does work,  but I have not tried it 
myself.

Best regards
David
Best regards
David

Regards,
Keith

[dpdk-users] GCC compile errors from 'rte_memcpy.h' in stand-alone environment

[Pavey, Nicholas]

Hi Folks,

I?m developing a benchmarking environment for some code that I?ll eventually 
link with the DPDK. However, at the moment it?s not integrated with the DPDK 
because it makes testing and debug easier.

I?d like to use the ?rte_memcpy? function, since it?s a good implementation 
using non-temporal instructions. The DPDK version is a lot better than 
something I hack together ;-)

When I compile the code I?m getting a lot of errors along the lines of this:

c_src/rte_memcpy.h:870:2: error: incompatible type for argument 2 of 
'_mm_storeu_si128'
In file included from c_src/main.h:23:0,
 from c_src/main.c:1:
/usr/lib/gcc/x86_64-linux-gnu/4.8/include/emmintrin.h:700:1: note: expected 
'__m128i' but argument is of type 'int'
 _mm_storeu_si128 (__m128i *__P, __m128i __B)
 ^
In file included from c_src/main.h:33:0,
 from c_src/main.c:1:
c_src/rte_memcpy.h:870:2: error: incompatible type for argument 2 of 
'_mm_storeu_si128'
  MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
  ^
In file included from c_src/main.h:23:0,
 from c_src/main.c:1:
/usr/lib/gcc/x86_64-linux-gnu/4.8/include/emmintrin.h:700:1: note: expected 
'__m128i' but argument is of type 'int'
 _mm_storeu_si128 (__m128i *__P, __m128i __B)
 ^
In file included from c_src/main.h:33:0,
 from c_src/main.c:1:
c_src/rte_memcpy.h:870:2: error: incompatible type for argument 2 of 
'_mm_storeu_si128'
  MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
  ^
In file included from c_src/main.h:23:0,
 from c_src/main.c:1:
/usr/lib/gcc/x86_64-linux-gnu/4.8/include/emmintrin.h:700:1: note: expected 
'__m128i' but argument is of type 'int'
 _mm_storeu_si128 (__m128i *__P, __m128i __B)

(There are an awful lot of these?)


The compile command line is:

  gcc -O3 --no-omit-frame-pointer -Wall -m64 -std=c99 -g 
?I/include/path/to/libhugetlbfs ?I/include/path/to/libnuma -Ic_src -Icpp_src -c 
c_src/main.c -o c_objs/main.o

The compiler version is:

  gcc -v
  Using built-in specs.
  COLLECT_GCC=gcc
  COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
  Target: x86_64-linux-gnu
  Configured with: ../src/configure -v --with-pkgversion='Ubuntu 
4.8.4-2ubuntu1~14.04.1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs 
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-4.8 --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls 
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap 
--enable-plugin --with-system-zlib --disable-browser-plugin 
--enable-java-awt=gtk --enable-gtk-cairo 
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home 
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
  Thread model: posix
  gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.1) 

OS distribution : Ubuntu 14.04
Kernel version : 3.13.0-85-generic

Processor type : Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz
Processor flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm 
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc 
aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 
cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave 
avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi 
flexpriority ept vpid fsgsbase smep erms


Can anyone suggest what I can do to make ?rte_memcpy? compile correctly outside 
of the complete build environment?

Thanks,


Nick

[dpdk-users] Unable to see incoming packets with example KNI application

[Pavey, Nicholas]

Hi Sakthivel, Andriy,

Thanks for the email.

I?m still having trouble, although things do seem to be working better than 
before.

It seems that the MAC address suggestion and also the IPs on the same class B 
network aren?t the root cause.


Current symptoms


I rebooted my machine, and took a note of the MAC addresses as the machine 
started up. It turns out that the KNI virtual interfaces actually did 
initialize with the correct MAC addresses.

I also reconfigured the virtual interfaces to be using different network 
classes, so that should no longer be a problem.

Something has improved because I?m able to see traffic on the KNI virtual 
interface with tcpdump, which I was not able to do previously.

Unfortunately, even though tcpdump is able to see the traffic correctly, it 
seems that the networking stack isn?t working as I would expect.



Outbound


Ping


I can see outbound ?pings? (with initial ARP requests) with ?tcpdump', and I 
can see a response coming back. However, the ?ping? application reports 100% 
packet loss.

The ARP traffic is definitely getting out, because I see the IP address 
registered in the router?s ARP cache. Likewise, I see a response to the 
original ?ping? packet, so the outbound direction seems to be working.


Inbound
===

The problems seem to be on the inbound side. As we saw above, the outbound side 
appears to be working reasonably, but I don?t appear to be able to capture 
inbound packets.

TCP
---

For example, if I set up a simple ?netcat? listener (using TCP for transport) 
on the target server:

  nc ?l 172.25.48.200 9876

And then attempt to connect to it from another machine, as follows:

  nc 172.25.48.200 9876


?tcpdump? on the target server will show me the incoming ?syn? and a ?syn? 
retransmission, but there are no outbound ?ack? packets. 


UDP
---

Similarly, inbound UDP traffic never appears to be routed to the user space 
application.

I can counters incrementing on the virtual interface with ?sar ?n DEV 1 100?. 
?tcpdump? also shows me the incoming data.

However, if I look at the UDP stats with ?sar ?n UDP 1 100?, I?m not seeing any 
packets arriving, even with ?no port? or ?idgmerr?, which I?d normally expect 
if there?s no listening application bound to the IP address.


Next steps
==

It almost seems as if the receive side of the network stack simply isn?t seeing 
the inbound data (regardless of whether it?s ICMP, TCP or UDP) and therefore 
isn?t sending responses.


The thing I?m confused about here is how ?tcpdump? is able to see the traffic - 
after all, if it?s able to see the inbound traffic, then a good part of the RX 
side of the stack must be working. I?d have thought that if ?tcpdump? can see 
the traffic, then the rest of the stack should be working too.

It makes me wondering whether perhaps I?m misunderstanding the purpose of the 
KNI system?

My interpretation is that it?s supposed to route traffic from the DPDK into the 
regular Linux network stack, where it can be used as if it were regular 
traffic. Do I have that right?



Do you have any ideas? 

Thanks,


Nick


From:  SAKTHIVEL ANAND S <anand.s...@gmail.com>
Date:  Wednesday, May 11, 2016 at 3:30 AM
To:  "Pavey, Nicholas" 
Subject:  Re: [dpdk-users] Unable to see incoming packets with example KNI 
application


Hi

When you try to send echo packets(outbound), your PC will try to resolve ARP, 
which it could not complete properly .. due to random mac generation for KNI 
interface(your KNI interface having different MAC than actual interface).


After starting KNI app write your hardware address on KNI by doing, "ifconfig 
 hw ether " and try ping. Let me know the results.


use  "tcpdump -n -i vEth** -e | grep " 

Regards

Sakthivel S OM

[dpdk-users] Unable to see incoming packets with example KNI application

[Pavey, Nicholas]

Good afternoon,

I?m a new user of the DPDK library - this is my first post to this list.

I?ve been experimenting with the various example applications, including 
?skeleton? and ?kni?.

I have been able to get ?skeleton? to work correctly, and observed good 
forwarding performance from it. I have been unable to get ?kni? to work however.

The symptom appears to be that incoming packets are not received correctly and 
are not forwarded to the KNI stack. Likewise, it appears that outbound ICMP 
?ping? packets sent via the traditional linux ?ping? command on the KNI 
interface are not sent (see observations, below).

I?ve searched the mail archives and have seen several people with what sounds 
like similar problems. I don?t believe I saw a problem resolution there, 
however.

Here?s a fair amount of detail about my environment. Please let me know if I?m 
missing something - I?ll happily provide extra details.

Does anyone have any suggestions about what might be going on here?

Regards,



Nick Pavey



Networking environment
==

  * DPDK machine has dual 10Gbps NICs
- Intel 82599EB 10Gbps NIC
  * DPDK machine is directly connected to an Ixia load generator
- SFP+ Direct Attached Copper (DAC) cabling
- Running BreakingPoint load generation software
  * The linux kernel is unaware of the 10Gbps interfaces, so the DPDK can 
attach correctly
  * The control interface is an Intel I350 1Gbps copper NIC
- This has a statically assigned IP address
- I control the machine through this NIC

DPDK versions
=

I have tried the ?kni? application with two versions of the DPDK:

  * DPDK-16.04, unpacked from tarball
  * DPDK cloned from git. Head commit is 
db340cf2ef71af231af67be8e42fd603e4bab0ac
- "i40e: fix VLAN stripping from inner header? by JingJing Wu, 5/4/2016

Machine details
===

Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz

Dual socket, 8 core, hyperthreaded. 32 total execution contexts.
64GB RAM
NICS are dual Intel 82599EB 10Gbps

OS/compiler details
===

The machine is running a modified version of the Kernel. IIRC, it?s derived 
from Ubuntu 12.04.

The kernel version is reported as 3.14.43. Unfortunately I?m unable to detail 
all the modifications, but it?s probably fair to assume the kernel is roughly 
equivalent to 3.13.43.

The compiler is GCC version 4.6.3.


KNI application startup
===

I have 384 (size chosen fairly arbitrarily) available huge pages, which seems 
to be enough to allow the ?kni? application to start up.

I have built the ?rte_kni? kernel module on the DPDK target machine. I load it 
with no arguments, and it loads without complaint.

I?m invoking the ?kni? application as follows:

  ./build/kni -c 0xf0 -n 4 -- -P -p 0x3 --config="(0,4,6,8),(1,5,7,9)"

So, the ?kni? application is in Promiscuous mode.

Once the application is started up, I set up two IP addresses for the KNI 
interfaces

  ifconfig vEth0_0 172.25.48.200
  ifconfig vEth1_0 172.25.48.201

Both seem to initialize correctly, and the ?kni? application notices that the 
NIC status has changed.


The ?kni? application seems to start up correctly. I?m not getting any errors, 
but equally, I?m not seeing traffic get routed into the Linux network stack as 
I?d expect.


Observations


I?ve done several tests:

  * Sent a low level of traffic from the Ixia (a few packets a second)
- The Ixia is directly connected, so the data is not going missing in the 
networking infrastructure
- The ?skeleton? application works as expected, so the Ixia, the cabling 
and a good part of the DPDK appears to be working
- A ?tcpdump? on the relevant network interfaces shows no incoming traffic
- Watching the incoming packet rate with ?sar -n DEV 1 1000? shows the 
kernel seeing no incoming traffic on the DPDK interfaces
- The statistics from the ?kni? application show no inbound data
- A packet capture on the Ixia interface shows outbound packets but no 
return packets.

  * Started the ?kni? application and the Ixia, then attempted to ping the Ixia
- In this case, the statistics from the ?kni? application do show the TX 
counters incrementing
- However, when I examine the Ixia?s packet capture, I see no signs of 
?ping? packets.


Dmesg contents
==

When I bring up the KNI interfaces, I get the following lines in the ?dmesg? 
log:

[71051.312668] KNI: /dev/kni opened
[71051.470926] KNI: Creating kni...
[71051.471280] KNI: tx_phys:  0x375313c0, tx_q addr:  0x8800
375313c0
[71051.471281] KNI: rx_phys:  0x3752f340, rx_q addr:  0x8800
3752f340
[71051.471282] KNI: alloc_phys:   0x3752d2c0, alloc_q addr:   0x8800
3752d2c0
[71051.471282] KNI: free_phys:0x3752b240, free_q addr:0x8800
3752b240
[71051.471284] KNI: req_phys: 0x375291c0, req_q addr: 0x8800
375291c0
[71051.471285] KNI: resp_phys: