[dpdk-dev] [PATCH] librte_pmd_packet: add PMD for AF_PACKET-based virtual devices

[Shaw, Jeffrey B]

Danny, can you specify multiple --vdev parameters?
"--vdev=eth_packet0,iface=eth0 --vdev=eth_packet1,iface=eth1"


-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Zhou, Danny
Sent: Friday, July 11, 2014 1:27 PM
To: John W. Linville
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH] librte_pmd_packet: add PMD for AF_PACKET-based 
virtual devices

I want to run a common DPDK L2 or L3 forward benchmark for bi-direction 
traffics, so at least two ports are required. Just like how to measure Linux 
bridge or OVS performance, you need add at least two ports into a bridge.

> -Original Message-
> From: John W. Linville [mailto:linville at tuxdriver.com]
> Sent: Saturday, July 12, 2014 3:32 AM
> To: Zhou, Danny
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] librte_pmd_packet: add PMD for 
> AF_PACKET-based virtual devices
> 
> I'm not sure that would make any sense -- the AF_PACKET sockets are 
> mapped to specific interfaces.
> 
> What are you trying to do with a syntax like that?
> 
> John
> 
> On Fri, Jul 11, 2014 at 07:04:19PM +, Zhou, Danny wrote:
> > Does it support specifying multiple NIC interfaces using command 
> > line option like
> "--vdev=eth_packet0,iface=..."? Say "iface=eth0,eth1,eth2...", tried 
> but it doesn't work.
> >
> > > -Original Message-
> > > From: Zhou, Danny
> > > Sent: Saturday, July 12, 2014 2:01 AM
> > > To: 'John W. Linville'
> > > Cc: dev at dpdk.org
> > > Subject: RE: [dpdk-dev] [PATCH] librte_pmd_packet: add PMD for 
> > > AF_PACKET-based virtual devices
> > >
> > > Tried on 3.12, both of them are undefined. Anyway, will comment 
> > > them out and see what performance it could achieve.
> > >
> > > > -Original Message-
> > > > From: John W. Linville [mailto:linville at tuxdriver.com]
> > > > Sent: Saturday, July 12, 2014 1:41 AM
> > > > To: Zhou, Danny
> > > > Cc: dev at dpdk.org
> > > > Subject: Re: [dpdk-dev] [PATCH] librte_pmd_packet: add PMD for 
> > > > AF_PACKET-based virtual devices
> > > >
> > > > On Fri, Jul 11, 2014 at 05:20:42PM +, Zhou, Danny wrote:
> > > > > Looks like you used a pretty new kernel version with new 
> > > > > socket options that old
> > > > kernel like my 3.12 does not support. When I tried this patch, 
> > > > it just cannot build, and compiler complains like below. Which 
> > > > Linux distribution does this
> > > patch work for?
> > > > How to ensure it works for old kernels?
> > > > >
> > > > > /home/danny/dpdk.org/dpdk/lib/librte_pmd_packet/rte_eth_packet
> > > > > .c
> > > > > : In function
> > > > rte_pmd_init_internals:
> > > > > /home/danny/dpdk.org/dpdk/lib/librte_pmd_packet/rte_eth_packet
> > > > > .c
> > > > > :524
> > > > > :1
> > > > > 7: error: PACKET_FANOUT_FLAG_ROLLOVER undeclared (first use in 
> > > > > this
> > > > > function)
> > > > > /home/danny/dpdk.org/dpdk/lib/librte_pmd_packet/rte_eth_packet
> > > > > .c
> > > > > :524
> > > > > :1
> > > > > 7: note: each undeclared identifier is reported only once for 
> > > > > each function it appears in 
> > > > > /home/danny/dpdk.org/dpdk/lib/librte_pmd_packet/rte_eth_packet
> > > > > .c
> > > > > :557
> > > > > :3
> > > > > 3: error: PACKET_QDISC_BYPASS undeclared (first use in this
> > > > > function)
> > > >
> > > > Both of them are isolated, so for playing with it you could just 
> > > > comment those
> out.
> > > > It looks like PACKET_FANOUT_FLAG_ROLLOVER should have been in 
> > > > 3.10, while PACKET_QDISC_BYPASS didn't show-up until 3.14...
> > > >
> > > > /home/linville/git/linux
> > > > [linville-x1.hq.tuxdriver.com]:> git annotate 
> > > > include/uapi/linux/if_packet.h | grep PACKET_FANOUT_FLAG_ROLLOVER
> > > > 77f65ebdca506   (Willem de Bruijn   2013-03-19 10:18:11 +   
> > > > 64)#define
> > > > PACKET_FANOUT_FLAG_ROLLOVER 0x1000
> > > >
> > > > /home/linville/git/linux
> > > > [linville-x1.hq.tuxdriver.com]:> git show -s --format=short
> > > > 77f65ebdca506 commit 77f65ebdca506870d99bfabe52bde222511022ec
> > > > Author: Willem de Bruijn 
> > > >
> > > > packet: packet fanout rollover during socket overload
> > > >
> > > > /home/linville/git/linux
> > > > [linville-x1.hq.tuxdriver.com]:> git describe --contains
> > > > 77f65ebdca506
> > > > v3.10-rc1~66^2~423
> > > >
> > > > /home/linville/git/linux
> > > > [linville-x1.hq.tuxdriver.com]:> git annotate 
> > > > include/uapi/linux/if_packet.h | grep PACKET_QDISC_BYPASS
> > > > d346a3fae3ff1   (Daniel Borkmann2013-12-06 11:36:17 +0100   
> > > > 56)#define
> > > > PACKET_QDISC_BYPASS 20
> > > >
> > > > /home/linville/git/linux
> > > > [linville-x1.hq.tuxdriver.com]:> git show -s --format=short
> > > > d346a3fae3ff1 commit
> > > > d346a3fae3ff1d99f5d0c819bf86edf9094a26a1
> > > > Author: Daniel Borkmann 
> > > >
> > > > packet: introduce PACKET_QDISC_BYPASS socket option
> > > >
> > > > /home/linville/git/linux
> > > > [linville-x1.hq.tuxdriver.com]:> git describe --contains
> > > > d346a3fae3ff1
> > > > 

[dpdk-dev] [PATCH] librte_pmd_packet: add PMD for AF_PACKET-based virtual devices

[Zhou, Danny]

I want to run a common DPDK L2 or L3 forward benchmark for bi-direction 
traffics, so at least two ports are required. Just like how to measure Linux 
bridge or OVS performance, you need add at least two ports into a bridge.

> -Original Message-
> From: John W. Linville [mailto:linville at tuxdriver.com]
> Sent: Saturday, July 12, 2014 3:32 AM
> To: Zhou, Danny
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] librte_pmd_packet: add PMD for
> AF_PACKET-based virtual devices
> 
> I'm not sure that would make any sense -- the AF_PACKET sockets are mapped to
> specific interfaces.
> 
> What are you trying to do with a syntax like that?
> 
> John
> 
> On Fri, Jul 11, 2014 at 07:04:19PM +, Zhou, Danny wrote:
> > Does it support specifying multiple NIC interfaces using command line 
> > option like
> "--vdev=eth_packet0,iface=..."? Say "iface=eth0,eth1,eth2...", tried but it 
> doesn't
> work.
> >
> > > -Original Message-
> > > From: Zhou, Danny
> > > Sent: Saturday, July 12, 2014 2:01 AM
> > > To: 'John W. Linville'
> > > Cc: dev at dpdk.org
> > > Subject: RE: [dpdk-dev] [PATCH] librte_pmd_packet: add PMD for
> > > AF_PACKET-based virtual devices
> > >
> > > Tried on 3.12, both of them are undefined. Anyway, will comment them
> > > out and see what performance it could achieve.
> > >
> > > > -Original Message-
> > > > From: John W. Linville [mailto:linville at tuxdriver.com]
> > > > Sent: Saturday, July 12, 2014 1:41 AM
> > > > To: Zhou, Danny
> > > > Cc: dev at dpdk.org
> > > > Subject: Re: [dpdk-dev] [PATCH] librte_pmd_packet: add PMD for
> > > > AF_PACKET-based virtual devices
> > > >
> > > > On Fri, Jul 11, 2014 at 05:20:42PM +, Zhou, Danny wrote:
> > > > > Looks like you used a pretty new kernel version with new socket
> > > > > options that old
> > > > kernel like my 3.12 does not support. When I tried this patch, it
> > > > just cannot build, and compiler complains like below. Which Linux
> > > > distribution does this
> > > patch work for?
> > > > How to ensure it works for old kernels?
> > > > >
> > > > > /home/danny/dpdk.org/dpdk/lib/librte_pmd_packet/rte_eth_packet.c
> > > > > : In function
> > > > rte_pmd_init_internals:
> > > > > /home/danny/dpdk.org/dpdk/lib/librte_pmd_packet/rte_eth_packet.c
> > > > > :524
> > > > > :1
> > > > > 7: error: PACKET_FANOUT_FLAG_ROLLOVER undeclared (first use in
> > > > > this
> > > > > function)
> > > > > /home/danny/dpdk.org/dpdk/lib/librte_pmd_packet/rte_eth_packet.c
> > > > > :524
> > > > > :1
> > > > > 7: note: each undeclared identifier is reported only once for
> > > > > each function it appears in
> > > > > /home/danny/dpdk.org/dpdk/lib/librte_pmd_packet/rte_eth_packet.c
> > > > > :557
> > > > > :3
> > > > > 3: error: PACKET_QDISC_BYPASS undeclared (first use in this
> > > > > function)
> > > >
> > > > Both of them are isolated, so for playing with it you could just 
> > > > comment those
> out.
> > > > It looks like PACKET_FANOUT_FLAG_ROLLOVER should have been in
> > > > 3.10, while PACKET_QDISC_BYPASS didn't show-up until 3.14...
> > > >
> > > > /home/linville/git/linux
> > > > [linville-x1.hq.tuxdriver.com]:> git annotate
> > > > include/uapi/linux/if_packet.h | grep PACKET_FANOUT_FLAG_ROLLOVER
> > > > 77f65ebdca506   (Willem de Bruijn   2013-03-19 10:18:11 +   
> > > > 64)#define
> > > > PACKET_FANOUT_FLAG_ROLLOVER 0x1000
> > > >
> > > > /home/linville/git/linux
> > > > [linville-x1.hq.tuxdriver.com]:> git show -s --format=short
> > > > 77f65ebdca506 commit 77f65ebdca506870d99bfabe52bde222511022ec
> > > > Author: Willem de Bruijn 
> > > >
> > > > packet: packet fanout rollover during socket overload
> > > >
> > > > /home/linville/git/linux
> > > > [linville-x1.hq.tuxdriver.com]:> git describe --contains
> > > > 77f65ebdca506
> > > > v3.10-rc1~66^2~423
> > > >
> > > > /home/linville/git/linux
> > > > [linville-x1.hq.tuxdriver.com]:> git annotate
> > > > include/uapi/linux/if_packet.h | grep PACKET_QDISC_BYPASS
> > > > d346a3fae3ff1   (Daniel Borkmann2013-12-06 11:36:17 +0100   
> > > > 56)#define
> > > > PACKET_QDISC_BYPASS 20
> > > >
> > > > /home/linville/git/linux
> > > > [linville-x1.hq.tuxdriver.com]:> git show -s --format=short
> > > > d346a3fae3ff1 commit
> > > > d346a3fae3ff1d99f5d0c819bf86edf9094a26a1
> > > > Author: Daniel Borkmann 
> > > >
> > > > packet: introduce PACKET_QDISC_BYPASS socket option
> > > >
> > > > /home/linville/git/linux
> > > > [linville-x1.hq.tuxdriver.com]:> git describe --contains
> > > > d346a3fae3ff1
> > > > v3.14-rc1~94^2~564
> > > >
> > > > Is there an example of code in DPDK that requires specific kernel
> > > > versions?  What is the preferred method for coding such dependencies?
> > > >
> > > > John
> > > > --
> > > > John W. LinvilleSomeday the world will need a hero, and 
> > > > you
> > > > linville at tuxdriver.com   might be all we have.  
> > > > Be ready.
> >
> 
> --
> John W. Linville 

[dpdk-dev] [PATCH] librte_pmd_packet: add PMD for AF_PACKET-based virtual devices

[Zhou, Danny]

Does it support specifying multiple NIC interfaces using command line option 
like "--vdev=eth_packet0,iface=..."? Say "iface=eth0,eth1,eth2...", tried but 
it doesn't work.

> -Original Message-
> From: Zhou, Danny
> Sent: Saturday, July 12, 2014 2:01 AM
> To: 'John W. Linville'
> Cc: dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH] librte_pmd_packet: add PMD for
> AF_PACKET-based virtual devices
> 
> Tried on 3.12, both of them are undefined. Anyway, will comment them out and 
> see
> what performance it could achieve.
> 
> > -Original Message-
> > From: John W. Linville [mailto:linville at tuxdriver.com]
> > Sent: Saturday, July 12, 2014 1:41 AM
> > To: Zhou, Danny
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] librte_pmd_packet: add PMD for
> > AF_PACKET-based virtual devices
> >
> > On Fri, Jul 11, 2014 at 05:20:42PM +, Zhou, Danny wrote:
> > > Looks like you used a pretty new kernel version with new socket
> > > options that old
> > kernel like my 3.12 does not support. When I tried this patch, it just
> > cannot build, and compiler complains like below. Which Linux distribution 
> > does this
> patch work for?
> > How to ensure it works for old kernels?
> > >
> > > /home/danny/dpdk.org/dpdk/lib/librte_pmd_packet/rte_eth_packet.c: In
> > > function
> > rte_pmd_init_internals:
> > > /home/danny/dpdk.org/dpdk/lib/librte_pmd_packet/rte_eth_packet.c:524
> > > :1
> > > 7: error: PACKET_FANOUT_FLAG_ROLLOVER undeclared (first use in this
> > > function)
> > > /home/danny/dpdk.org/dpdk/lib/librte_pmd_packet/rte_eth_packet.c:524
> > > :1
> > > 7: note: each undeclared identifier is reported only once for each
> > > function it appears in
> > > /home/danny/dpdk.org/dpdk/lib/librte_pmd_packet/rte_eth_packet.c:557
> > > :3
> > > 3: error: PACKET_QDISC_BYPASS undeclared (first use in this
> > > function)
> >
> > Both of them are isolated, so for playing with it you could just comment 
> > those out.
> > It looks like PACKET_FANOUT_FLAG_ROLLOVER should have been in 3.10,
> > while PACKET_QDISC_BYPASS didn't show-up until 3.14...
> >
> > /home/linville/git/linux
> > [linville-x1.hq.tuxdriver.com]:> git annotate
> > include/uapi/linux/if_packet.h | grep PACKET_FANOUT_FLAG_ROLLOVER
> > 77f65ebdca506   (Willem de Bruijn   2013-03-19 10:18:11 +   
> > 64)#define
> > PACKET_FANOUT_FLAG_ROLLOVER 0x1000
> >
> > /home/linville/git/linux
> > [linville-x1.hq.tuxdriver.com]:> git show -s --format=short
> > 77f65ebdca506 commit 77f65ebdca506870d99bfabe52bde222511022ec
> > Author: Willem de Bruijn 
> >
> > packet: packet fanout rollover during socket overload
> >
> > /home/linville/git/linux
> > [linville-x1.hq.tuxdriver.com]:> git describe --contains 77f65ebdca506
> > v3.10-rc1~66^2~423
> >
> > /home/linville/git/linux
> > [linville-x1.hq.tuxdriver.com]:> git annotate
> > include/uapi/linux/if_packet.h | grep PACKET_QDISC_BYPASS
> > d346a3fae3ff1   (Daniel Borkmann2013-12-06 11:36:17 +0100   
> > 56)#define
> > PACKET_QDISC_BYPASS 20
> >
> > /home/linville/git/linux
> > [linville-x1.hq.tuxdriver.com]:> git show -s --format=short
> > d346a3fae3ff1 commit
> > d346a3fae3ff1d99f5d0c819bf86edf9094a26a1
> > Author: Daniel Borkmann 
> >
> > packet: introduce PACKET_QDISC_BYPASS socket option
> >
> > /home/linville/git/linux
> > [linville-x1.hq.tuxdriver.com]:> git describe --contains d346a3fae3ff1
> > v3.14-rc1~94^2~564
> >
> > Is there an example of code in DPDK that requires specific kernel
> > versions?  What is the preferred method for coding such dependencies?
> >
> > John
> > --
> > John W. LinvilleSomeday the world will need a hero, and you
> > linville at tuxdriver.com   might be all we have.  Be ready.

[dpdk-dev] [PATCH] librte_pmd_packet: add PMD for AF_PACKET-based virtual devices

[Thomas Monjalon]

2014-07-11 11:30, John W. Linville:
> On Fri, Jul 11, 2014 at 05:04:04PM +0200, Thomas Monjalon wrote:
> > 2014-07-11 10:51, John W. Linville:
> > > On Fri, Jul 11, 2014 at 03:26:39PM +0200, Thomas Monjalon wrote:
> > > > Thank you for this nice work.
> > > > 
> > > > I think it would be well suited to host this PMD as an external one in
> > > > order to make it work also with DPDK 1.7.0.
> > > 
> > > I'm not sure I understand the suggestion -- you don't want to merge
> > > the driver for 1.8?  Or you just want to host this patch somewhere,
> > > so people can still use it w/ 1.7?
> > 
> > I suggest to have a separated repository here:
> > http://dpdk.org/browse/
> 
> I really don't see any reason not to merge it.  It was already delayed
> by me waiting for all the PMD init changes to settle out in the 1.6
> release, and I still had to do a few touch-ups for it to compile on
> 1.7.  I definitely do not want to have to do that over and over again.

It's a pity that we didn't synchronize our efforts to make it integrated 
during 1.7.0 cycle.

> Why wouldn't you just merge it?  If someone wants to use it on 1.7,
> they can just apply the patch.

I'm OK to merge it. I was only suggesting to host your PMD externally like we 
did for virtio-net-pmd, vmxnet3-usermap and memnic.
It was the same discussion for the vmxnet3 PMD that Stephen submitted.

I start thinking that nobody wants PMD to be external. So we may merge this 
one in dpdk.git and start talking what to do for the other ones:
- move memnic in dpdk.git?
- move virtio-net-pmd and vmxnet3-usermap where sits their uio 
counterparts?
- merge Brocade's vmxnet3 as new one or as a replacement for 
vmxnet3-uio?

-- 
Thomas

[dpdk-dev] [PATCH] librte_pmd_packet: add PMD for AF_PACKET-based virtual devices

[Zhou, Danny]

Tried on 3.12, both of them are undefined. Anyway, will comment them out and 
see what performance it could achieve.

> -Original Message-
> From: John W. Linville [mailto:linville at tuxdriver.com]
> Sent: Saturday, July 12, 2014 1:41 AM
> To: Zhou, Danny
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] librte_pmd_packet: add PMD for
> AF_PACKET-based virtual devices
> 
> On Fri, Jul 11, 2014 at 05:20:42PM +, Zhou, Danny wrote:
> > Looks like you used a pretty new kernel version with new socket options 
> > that old
> kernel like my 3.12 does not support. When I tried this patch, it just cannot 
> build, and
> compiler complains like below. Which Linux distribution does this patch work 
> for?
> How to ensure it works for old kernels?
> >
> > /home/danny/dpdk.org/dpdk/lib/librte_pmd_packet/rte_eth_packet.c: In 
> > function
> rte_pmd_init_internals:
> > /home/danny/dpdk.org/dpdk/lib/librte_pmd_packet/rte_eth_packet.c:524:1
> > 7: error: PACKET_FANOUT_FLAG_ROLLOVER undeclared (first use in this
> > function)
> > /home/danny/dpdk.org/dpdk/lib/librte_pmd_packet/rte_eth_packet.c:524:1
> > 7: note: each undeclared identifier is reported only once for each
> > function it appears in
> > /home/danny/dpdk.org/dpdk/lib/librte_pmd_packet/rte_eth_packet.c:557:3
> > 3: error: PACKET_QDISC_BYPASS undeclared (first use in this function)
> 
> Both of them are isolated, so for playing with it you could just comment 
> those out.
> It looks like PACKET_FANOUT_FLAG_ROLLOVER should have been in 3.10, while
> PACKET_QDISC_BYPASS didn't show-up until 3.14...
> 
> /home/linville/git/linux
> [linville-x1.hq.tuxdriver.com]:> git annotate include/uapi/linux/if_packet.h 
> | grep
> PACKET_FANOUT_FLAG_ROLLOVER
> 77f65ebdca506 (Willem de Bruijn   2013-03-19 10:18:11 +   
> 64)#define
> PACKET_FANOUT_FLAG_ROLLOVER   0x1000
> 
> /home/linville/git/linux
> [linville-x1.hq.tuxdriver.com]:> git show -s --format=short 77f65ebdca506 
> commit
> 77f65ebdca506870d99bfabe52bde222511022ec
> Author: Willem de Bruijn 
> 
> packet: packet fanout rollover during socket overload
> 
> /home/linville/git/linux
> [linville-x1.hq.tuxdriver.com]:> git describe --contains 77f65ebdca506
> v3.10-rc1~66^2~423
> 
> /home/linville/git/linux
> [linville-x1.hq.tuxdriver.com]:> git annotate include/uapi/linux/if_packet.h 
> | grep
> PACKET_QDISC_BYPASS
> d346a3fae3ff1 (Daniel Borkmann2013-12-06 11:36:17 +0100   
> 56)#define
> PACKET_QDISC_BYPASS   20
> 
> /home/linville/git/linux
> [linville-x1.hq.tuxdriver.com]:> git show -s --format=short d346a3fae3ff1 
> commit
> d346a3fae3ff1d99f5d0c819bf86edf9094a26a1
> Author: Daniel Borkmann 
> 
> packet: introduce PACKET_QDISC_BYPASS socket option
> 
> /home/linville/git/linux
> [linville-x1.hq.tuxdriver.com]:> git describe --contains d346a3fae3ff1
> v3.14-rc1~94^2~564
> 
> Is there an example of code in DPDK that requires specific kernel versions?  
> What is
> the preferred method for coding such dependencies?
> 
> John
> --
> John W. Linville  Someday the world will need a hero, and you
> linville at tuxdriver.com might be all we have.  Be ready.

[dpdk-dev] Is it possible to install the current version of OVDK with DPDK 1.7.0?

[BYEONG-GI KIM]

Hello.

I've noticed that DPDK 1.7.0 version has been released a few days ago.

The DPDK vSwitch package, however, seems supporting old version, 1.6.x,
only.

Could the DPDK vSwitch be compiled by the latest DPDK?

Or Do I need to use 1.6.x version of DPDK?

Thanks in advance.

Best regards

Byeong-Gi KIM

[dpdk-dev] Build failure on Ubuntu 14.04

[Masaru Oki]

Hi,

I tried another workaround and works fine:
It similar to other kcompat function, add __kc_ prefix to function
definition
and #define skb_set_hash(a,b,c) __kc_skb_set_hash(a,b,c).

Thanks,



2014-07-06 0:27 GMT+09:00 Wiles, Roger Keith :

> 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
> <
> http://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<
> http://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<
> http://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<
> http://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
> :<
> http://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:<
> http://dpdk.org/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h:3853:1:>
> error: conflicting types for ???skb_set_hash???
>  skb_set_hash(struct sk_buff *skb, __u32 hash, __always_unused int type)
>  ^
> In file included from
> /usr/src/linux-headers-3.13.0-30-generic/include/linux/if_ether.h:23:0,
>  from /home/keithw/projects/dpdk/
> dpdk.org/lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_osdep.h:39<
> http://dpdk.org/lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_osdep.h:39>,
>  from /home/keithw/projects/dpdk/
> dpdk.org/lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_hw.h:31<
> http://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<
> http://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
> :<
> http://dpdk.org/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/kni/e1000_82575.c:38
> :>
> /usr/src/linux-headers-3.13.0-30-generic/include/linux/skbuff.h:740:1:
> note: previous definition of ???skb_set_hash??? was here
>  skb_set_hash(struct sk_buff *skb, __u32 hash, enum pkt_hash_types type)
>  ^
> make[10]: *** [/home/keithw/projects/dpdk/
> dpdk.org/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/kni/e1000_82575.o
> ]<
> http://dpdk.org/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/kni/e1000_82575.o]>
> Error 1
> make[9]: *** [_module_/home/keithw/projects/dpdk/
> dpdk.org/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/kni]<
> http://dpdk.org/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/kni]>
> Error 2
> make[8]: *** [sub-make] Error 2
> make[7]: *** [rte_kni.ko] Error 2
> make[6]: *** [kni] Error 2
> make[5]: *** [linuxapp] Error 2
> make[4]: *** [librte_eal] Error 2
> make[3]: *** [lib] Error 2
> make[2]: *** [all] Error 2
> make[1]: *** [x86_64-native-linuxapp-gcc_install] Error 2
> make: *** [install] Error 2
>
> Please verify this is correct.
>
> Thanks
> ++Keith
>
> Keith Wiles, Principal Technologist with CTO office, Wind River
> mobile 972-213-5533
>
> [Powering 30 Years of Innovation] >
>
>

[dpdk-dev] [PATCH] librte_pmd_packet: add PMD for AF_PACKET-based virtual devices

[Richardson, Bruce]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Friday, July 11, 2014 9:48 AM
> To: John W. Linville
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] librte_pmd_packet: add PMD for AF_PACKET-
> based virtual devices
> 
> 2014-07-11 11:30, John W. Linville:
> > On Fri, Jul 11, 2014 at 05:04:04PM +0200, Thomas Monjalon wrote:
> > > 2014-07-11 10:51, John W. Linville:
> > > > On Fri, Jul 11, 2014 at 03:26:39PM +0200, Thomas Monjalon wrote:
> > > > > Thank you for this nice work.
> > > > >
> > > > > I think it would be well suited to host this PMD as an external one in
> > > > > order to make it work also with DPDK 1.7.0.
> > > >
> > > > I'm not sure I understand the suggestion -- you don't want to merge
> > > > the driver for 1.8?  Or you just want to host this patch somewhere,
> > > > so people can still use it w/ 1.7?
> > >
> > > I suggest to have a separated repository here:
> > >   http://dpdk.org/browse/
> >
> > I really don't see any reason not to merge it.  It was already delayed
> > by me waiting for all the PMD init changes to settle out in the 1.6
> > release, and I still had to do a few touch-ups for it to compile on
> > 1.7.  I definitely do not want to have to do that over and over again.
> 
> It's a pity that we didn't synchronize our efforts to make it integrated
> during 1.7.0 cycle.
> 
> > Why wouldn't you just merge it?  If someone wants to use it on 1.7,
> > they can just apply the patch.
> 
> I'm OK to merge it. I was only suggesting to host your PMD externally like we
> did for virtio-net-pmd, vmxnet3-usermap and memnic.
> It was the same discussion for the vmxnet3 PMD that Stephen submitted.
> 
> I start thinking that nobody wants PMD to be external. So we may merge this
> one in dpdk.git and start talking what to do for the other ones:
>   - move memnic in dpdk.git?

Yes, I would agree with this. Having drivers in external git repos makes it 
hard for us to take them into account when planning on making changes to the 
core libs.

>   - move virtio-net-pmd and vmxnet3-usermap where sits their uio
> counterparts?
>   - merge Brocade's vmxnet3 as new one or as a replacement for
> vmxnet3-uio?

For these we really should try and converge on a single solution. Having 
multiple vmxnet3 and virtio drivers duplicates effort and is just plain messy! 
Of course, that's easier to say than to agree on...

/Bruce

[dpdk-dev] [PATCH] librte_pmd_packet: add PMD for AF_PACKET-based virtual devices

[Thomas Monjalon]

2014-07-11 10:51, John W. Linville:
> On Fri, Jul 11, 2014 at 03:26:39PM +0200, Thomas Monjalon wrote:
> > 2014-07-10 16:32, John W. Linville:
> > > This is a Linux-specific virtual PMD driver backed by an AF_PACKET
> > > socket.  This implementation uses mmap'ed ring buffers to limit copying
> > > and user/kernel transitions.  The PACKET_FANOUT_HASH behavior of
> > > AF_PACKET is used for frame reception.  In the current implementation,
> > > Tx and Rx queues are always paired, and therefore are always equal
> > > in number -- changing this would be a Simple Matter Of Programming.
> > > 
> > > Interfaces of this type are created with a command line option like
> > > "--vdev=eth_packet0,iface=...".  There are a number of options availabe
> > > 
> > > as arguments:
> > >  - Interface is chosen by "iface" (required)
> > >  - Number of queue pairs set by "qpairs" (optional, default: 16)
> > >  - AF_PACKET MMAP block size set by "blocksz" (optional, default: 4096)
> > >  - AF_PACKET MMAP frame size set by "framesz" (optional, default: 2048)
> > >  - AF_PACKET MMAP frame count set by "framecnt" (optional, default: 512)
> > > 
> > > Signed-off-by: John W. Linville 
> > > ---
> > > This PMD is intended to provide a means for using DPDK on a broad
> > > range of hardware without hardware-specific PMDs and (hopefully)
> > > with better performance than what PCAP offers in Linux.  This might
> > > be useful as a development platform for DPDK applications when
> > > DPDK-supported hardware is expensive or unavailable.
> > 
> > Thank you for this nice work.
> > 
> > I think it would be well suited to host this PMD as an external one in
> > order to make it work also with DPDK 1.7.0.
> 
> I'm not sure I understand the suggestion -- you don't want to merge
> the driver for 1.8?  Or you just want to host this patch somewhere,
> so people can still use it w/ 1.7?

I suggest to have a separated repository here:
http://dpdk.org/browse/

-- 
Thomas

[dpdk-dev] [PATCH] librte_pmd_packet: add PMD for AF_PACKET-based virtual devices

[John W. Linville]

Ah, yes...sorry, I misunderstood what you wanted to do.  The syntax
below is what I would expect to use.

John

On Fri, Jul 11, 2014 at 08:35:01PM +, Zhou, Danny wrote:
> Thanks Jeff, it works as expected, like below command line:
> 
> ./l2fwd/build/l2fwd -c 0x3 -n 4 --vdev=eth_packet0,iface=p786p1 
> --vdev=eth_packet1,iface=p786p2 -- -p 0x3
> 
> > -Original Message-
> > From: Shaw, Jeffrey B
> > Sent: Saturday, July 12, 2014 4:32 AM
> > To: Zhou, Danny; John W. Linville
> > Cc: dev at dpdk.org
> > Subject: RE: [dpdk-dev] [PATCH] librte_pmd_packet: add PMD for
> > AF_PACKET-based virtual devices
> > 
> > Danny, can you specify multiple --vdev parameters?
> > "--vdev=eth_packet0,iface=eth0 --vdev=eth_packet1,iface=eth1"
> > 
> > 
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zhou, Danny
> > Sent: Friday, July 11, 2014 1:27 PM
> > To: John W. Linville
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] librte_pmd_packet: add PMD for
> > AF_PACKET-based virtual devices
> > 
> > I want to run a common DPDK L2 or L3 forward benchmark for bi-direction 
> > traffics,
> > so at least two ports are required. Just like how to measure Linux bridge 
> > or OVS
> > performance, you need add at least two ports into a bridge.
> > 
> > > -Original Message-
> > > From: John W. Linville [mailto:linville at tuxdriver.com]
> > > Sent: Saturday, July 12, 2014 3:32 AM
> > > To: Zhou, Danny
> > > Cc: dev at dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH] librte_pmd_packet: add PMD for
> > > AF_PACKET-based virtual devices
> > >
> > > I'm not sure that would make any sense -- the AF_PACKET sockets are
> > > mapped to specific interfaces.
> > >
> > > What are you trying to do with a syntax like that?
> > >
> > > John
> > >
> > > On Fri, Jul 11, 2014 at 07:04:19PM +, Zhou, Danny wrote:
> > > > Does it support specifying multiple NIC interfaces using command
> > > > line option like
> > > "--vdev=eth_packet0,iface=..."? Say "iface=eth0,eth1,eth2...", tried
> > > but it doesn't work.
> > > >
> > > > > -Original Message-
> > > > > From: Zhou, Danny
> > > > > Sent: Saturday, July 12, 2014 2:01 AM
> > > > > To: 'John W. Linville'
> > > > > Cc: dev at dpdk.org
> > > > > Subject: RE: [dpdk-dev] [PATCH] librte_pmd_packet: add PMD for
> > > > > AF_PACKET-based virtual devices
> > > > >
> > > > > Tried on 3.12, both of them are undefined. Anyway, will comment
> > > > > them out and see what performance it could achieve.
> > > > >
> > > > > > -Original Message-
> > > > > > From: John W. Linville [mailto:linville at tuxdriver.com]
> > > > > > Sent: Saturday, July 12, 2014 1:41 AM
> > > > > > To: Zhou, Danny
> > > > > > Cc: dev at dpdk.org
> > > > > > Subject: Re: [dpdk-dev] [PATCH] librte_pmd_packet: add PMD for
> > > > > > AF_PACKET-based virtual devices
> > > > > >
> > > > > > On Fri, Jul 11, 2014 at 05:20:42PM +, Zhou, Danny wrote:
> > > > > > > Looks like you used a pretty new kernel version with new
> > > > > > > socket options that old
> > > > > > kernel like my 3.12 does not support. When I tried this patch,
> > > > > > it just cannot build, and compiler complains like below. Which
> > > > > > Linux distribution does this
> > > > > patch work for?
> > > > > > How to ensure it works for old kernels?
> > > > > > >
> > > > > > > /home/danny/dpdk.org/dpdk/lib/librte_pmd_packet/rte_eth_packet
> > > > > > > .c
> > > > > > > : In function
> > > > > > rte_pmd_init_internals:
> > > > > > > /home/danny/dpdk.org/dpdk/lib/librte_pmd_packet/rte_eth_packet
> > > > > > > .c
> > > > > > > :524
> > > > > > > :1
> > > > > > > 7: error: PACKET_FANOUT_FLAG_ROLLOVER undeclared (first use in
> > > > > > > this
> > > > > > > function)
> > > > > > > /home/danny/dpdk.org/dpdk/lib/librte_pmd_packet/rte_eth_packet
> > > > > > > .c
> > > > > > > :524
> > > > > > > :1
> > > > > > > 7: note: each undeclared identifier is reported only once for
> > > > > > > each function it appears in
> > > > > > > /home/danny/dpdk.org/dpdk/lib/librte_pmd_packet/rte_eth_packet
> > > > > > > .c
> > > > > > > :557
> > > > > > > :3
> > > > > > > 3: error: PACKET_QDISC_BYPASS undeclared (first use in this
> > > > > > > function)
> > > > > >
> > > > > > Both of them are isolated, so for playing with it you could just
> > > > > > comment those
> > > out.
> > > > > > It looks like PACKET_FANOUT_FLAG_ROLLOVER should have been in
> > > > > > 3.10, while PACKET_QDISC_BYPASS didn't show-up until 3.14...
> > > > > >
> > > > > > /home/linville/git/linux
> > > > > > [linville-x1.hq.tuxdriver.com]:> git annotate
> > > > > > include/uapi/linux/if_packet.h | grep PACKET_FANOUT_FLAG_ROLLOVER
> > > > > > 77f65ebdca506   (Willem de Bruijn   2013-03-19 10:18:11 
> > > > > > +
> > 64)#define
> > > > > > PACKET_FANOUT_FLAG_ROLLOVER 0x1000
> > > > > >
> > > > > > /home/linville/git/linux
> > > > > > [linville-x1.hq.tuxdriver.com]:> git show -s --format=short
> > > > > > 77f65ebdca506 commit 

[dpdk-dev] [PATCH] librte_pmd_packet: add PMD for AF_PACKET-based virtual devices

[Venkatesan, Venky]

On Fri, Jul 11, 2014 at 03:29:17PM +, Venkatesan, Venky wrote:
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of John W. 
> > Linville
> > Sent: Friday, July 11, 2014 7:49 AM
> > To: Stephen Hemminger
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] librte_pmd_packet: add PMD for
> > AF_PACKET- based virtual devices
> > 
> > On Fri, Jul 11, 2014 at 06:11:47AM -0700, Stephen Hemminger wrote:
> > > On Thu, 10 Jul 2014 16:32:49 -0400 "John W. Linville" 
> > >  wrote:
> > >
> > > > This is a Linux-specific virtual PMD driver backed by an 
> > > > AF_PACKET



> > > > +struct pkt_rx_queue {
> > > > +   int sockfd;
> > > > +
> > > > +   struct iovec *rd;
> > > > +   uint8_t *map;
> > > > +   unsigned int framecount;
> > > > +   unsigned int framenum;
> > > > +
> > > > +   struct rte_mempool *mb_pool;
> > > > +
> > > > +   volatile unsigned long rx_pkts;
> > > > +   volatile unsigned long err_pkts;
> > >
> > > Use of volatile will generate slow code, don't think it is 
> > > necessary, especially when only one CPU can use a queue at a time.
> > 
> > That is a good point, worth checking out.  FWIW, those lines are 
> > boilerplate originally copied from the pcap PMD. :-)
> > 
> 
> > Yes, I agree it's worth checking out if there is a performance 
> > impact, but if we assume that the stats for RX/TX are possibly going 
> > to be read by another core, they really should be volatile for 
> > correctness
> 
> Accessing the rx_queue structure directly for stats is unlikely to happen 
> from a second core; we should probably change the PCAP PMD as well (thanks 
> for pointing that out John). 

> "Unlikely" doesn't sound completely safe... :-)

LOL. :-). This is an internal data structure and the DPDK docs specifically 
mention that they are not  multi-process safe/accessible. The unlikely was for 
people that don't read the docs ... ;)

[dpdk-dev] [PATCH] librte_pmd_packet: add PMD for AF_PACKET-based virtual devices

[John W. Linville]

I'm not sure that would make any sense -- the AF_PACKET sockets are
mapped to specific interfaces.

What are you trying to do with a syntax like that?

John

On Fri, Jul 11, 2014 at 07:04:19PM +, Zhou, Danny wrote:
> Does it support specifying multiple NIC interfaces using command line option 
> like "--vdev=eth_packet0,iface=..."? Say "iface=eth0,eth1,eth2...", tried but 
> it doesn't work.
> 
> > -Original Message-
> > From: Zhou, Danny
> > Sent: Saturday, July 12, 2014 2:01 AM
> > To: 'John W. Linville'
> > Cc: dev at dpdk.org
> > Subject: RE: [dpdk-dev] [PATCH] librte_pmd_packet: add PMD for
> > AF_PACKET-based virtual devices
> > 
> > Tried on 3.12, both of them are undefined. Anyway, will comment them out 
> > and see
> > what performance it could achieve.
> > 
> > > -Original Message-
> > > From: John W. Linville [mailto:linville at tuxdriver.com]
> > > Sent: Saturday, July 12, 2014 1:41 AM
> > > To: Zhou, Danny
> > > Cc: dev at dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH] librte_pmd_packet: add PMD for
> > > AF_PACKET-based virtual devices
> > >
> > > On Fri, Jul 11, 2014 at 05:20:42PM +, Zhou, Danny wrote:
> > > > Looks like you used a pretty new kernel version with new socket
> > > > options that old
> > > kernel like my 3.12 does not support. When I tried this patch, it just
> > > cannot build, and compiler complains like below. Which Linux distribution 
> > > does this
> > patch work for?
> > > How to ensure it works for old kernels?
> > > >
> > > > /home/danny/dpdk.org/dpdk/lib/librte_pmd_packet/rte_eth_packet.c: In
> > > > function
> > > rte_pmd_init_internals:
> > > > /home/danny/dpdk.org/dpdk/lib/librte_pmd_packet/rte_eth_packet.c:524
> > > > :1
> > > > 7: error: PACKET_FANOUT_FLAG_ROLLOVER undeclared (first use in this
> > > > function)
> > > > /home/danny/dpdk.org/dpdk/lib/librte_pmd_packet/rte_eth_packet.c:524
> > > > :1
> > > > 7: note: each undeclared identifier is reported only once for each
> > > > function it appears in
> > > > /home/danny/dpdk.org/dpdk/lib/librte_pmd_packet/rte_eth_packet.c:557
> > > > :3
> > > > 3: error: PACKET_QDISC_BYPASS undeclared (first use in this
> > > > function)
> > >
> > > Both of them are isolated, so for playing with it you could just comment 
> > > those out.
> > > It looks like PACKET_FANOUT_FLAG_ROLLOVER should have been in 3.10,
> > > while PACKET_QDISC_BYPASS didn't show-up until 3.14...
> > >
> > > /home/linville/git/linux
> > > [linville-x1.hq.tuxdriver.com]:> git annotate
> > > include/uapi/linux/if_packet.h | grep PACKET_FANOUT_FLAG_ROLLOVER
> > > 77f65ebdca506 (Willem de Bruijn   2013-03-19 10:18:11 +   
> > > 64)#define
> > > PACKET_FANOUT_FLAG_ROLLOVER   0x1000
> > >
> > > /home/linville/git/linux
> > > [linville-x1.hq.tuxdriver.com]:> git show -s --format=short
> > > 77f65ebdca506 commit 77f65ebdca506870d99bfabe52bde222511022ec
> > > Author: Willem de Bruijn 
> > >
> > > packet: packet fanout rollover during socket overload
> > >
> > > /home/linville/git/linux
> > > [linville-x1.hq.tuxdriver.com]:> git describe --contains 77f65ebdca506
> > > v3.10-rc1~66^2~423
> > >
> > > /home/linville/git/linux
> > > [linville-x1.hq.tuxdriver.com]:> git annotate
> > > include/uapi/linux/if_packet.h | grep PACKET_QDISC_BYPASS
> > > d346a3fae3ff1 (Daniel Borkmann2013-12-06 11:36:17 +0100   
> > > 56)#define
> > > PACKET_QDISC_BYPASS   20
> > >
> > > /home/linville/git/linux
> > > [linville-x1.hq.tuxdriver.com]:> git show -s --format=short
> > > d346a3fae3ff1 commit
> > > d346a3fae3ff1d99f5d0c819bf86edf9094a26a1
> > > Author: Daniel Borkmann 
> > >
> > > packet: introduce PACKET_QDISC_BYPASS socket option
> > >
> > > /home/linville/git/linux
> > > [linville-x1.hq.tuxdriver.com]:> git describe --contains d346a3fae3ff1
> > > v3.14-rc1~94^2~564
> > >
> > > Is there an example of code in DPDK that requires specific kernel
> > > versions?  What is the preferred method for coding such dependencies?
> > >
> > > John
> > > --
> > > John W. Linville  Someday the world will need a hero, and you
> > > linville at tuxdriver.com might be all we have.  Be ready.
> 

-- 
John W. LinvilleSomeday the world will need a hero, and you
linville at tuxdriver.com   might be all we have.  Be ready.

[dpdk-dev] [PATCH] librte_pmd_packet: add PMD for AF_PACKET-based virtual devices

[Venkatesan, Venky]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of John W. Linville
> Sent: Friday, July 11, 2014 7:49 AM
> To: Stephen Hemminger
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] librte_pmd_packet: add PMD for 
> AF_PACKET- based virtual devices
> 
> On Fri, Jul 11, 2014 at 06:11:47AM -0700, Stephen Hemminger wrote:
> > On Thu, 10 Jul 2014 16:32:49 -0400
> > "John W. Linville"  wrote:
> >
> > > This is a Linux-specific virtual PMD driver backed by an AF_PACKET 
> > > socket.  This implementation uses mmap'ed ring buffers to limit 
> > > copying and user/kernel transitions.  The PACKET_FANOUT_HASH 
> > > behavior of AF_PACKET is used for frame reception.  In the current 
> > > implementation, Tx and Rx queues are always paired, and therefore 
> > > are always equal in number -- changing this would be a Simple Matter Of 
> > > Programming.
> > >
> > > Interfaces of this type are created with a command line option 
> > > like "--vdev=eth_packet0,iface=...".  There are a number of 
> > > options availabe as arguments:
> > >
> > >  - Interface is chosen by "iface" (required)
> > >  - Number of queue pairs set by "qpairs" (optional, default: 16)
> > >  - AF_PACKET MMAP block size set by "blocksz" (optional, default: 
> > > 4096)
> > >  - AF_PACKET MMAP frame size set by "framesz" (optional, default: 
> > > 2048)
> > >  - AF_PACKET MMAP frame count set by "framecnt" (optional, 
> > > default: 512)
> > >
> > > Signed-off-by: John W. Linville 
> > > ---
> > > This PMD is intended to provide a means for using DPDK on a broad 
> > > range of hardware without hardware-specific PMDs and (hopefully) 
> > > with better performance than what PCAP offers in Linux.  This 
> > > might be useful as a development platform for DPDK applications 
> > > when DPDK-supported hardware is expensive or unavailable.
> > >
> > >  config/common_bsdapp   |   5 +
> > >  config/common_linuxapp |   5 +
> > >  lib/Makefile   |   1 +
> > >  lib/librte_eal/linuxapp/eal/Makefile   |   1 +
> > >  lib/librte_pmd_packet/Makefile |  60 +++
> > >  lib/librte_pmd_packet/rte_eth_packet.c | 826
> +
> > >  lib/librte_pmd_packet/rte_eth_packet.h |  55 +++
> > >  mk/rte.app.mk  |   4 +
> > >  8 files changed, 957 insertions(+)  create mode 100644 
> > > lib/librte_pmd_packet/Makefile  create mode 100644 
> > > lib/librte_pmd_packet/rte_eth_packet.c
> > >  create mode 100644 lib/librte_pmd_packet/rte_eth_packet.h
> > >
> > > diff --git a/config/common_bsdapp b/config/common_bsdapp index 
> > > 943dce8f1ede..c317f031278e 100644
> > > --- a/config/common_bsdapp
> > > +++ b/config/common_bsdapp
> > > @@ -226,6 +226,11 @@ CONFIG_RTE_LIBRTE_PMD_PCAP=y  
> > > CONFIG_RTE_LIBRTE_PMD_BOND=y
> > >
> > >  #
> > > +# Compile software PMD backed by AF_PACKET sockets (Linux only) # 
> > > +CONFIG_RTE_LIBRTE_PMD_PACKET=n
> > > +
> > > +#
> > >  # Do prefetch of packet data within PMD driver receive function  
> > > #  CONFIG_RTE_PMD_PACKET_PREFETCH=y diff --git 
> > > a/config/common_linuxapp b/config/common_linuxapp index 
> > > 7bf5d80d4e26..f9e7bc3015ec 100644
> > > --- a/config/common_linuxapp
> > > +++ b/config/common_linuxapp
> > > @@ -249,6 +249,11 @@ CONFIG_RTE_LIBRTE_PMD_PCAP=n  
> > > CONFIG_RTE_LIBRTE_PMD_BOND=y
> > >
> > >  #
> > > +# Compile software PMD backed by AF_PACKET sockets (Linux only) # 
> > > +CONFIG_RTE_LIBRTE_PMD_PACKET=y
> > > +
> > > +#
> > >  # Compile Xen PMD
> > >  #
> > >  CONFIG_RTE_LIBRTE_PMD_XENVIRT=n
> > > diff --git a/lib/Makefile b/lib/Makefile index 
> > > 10c5bb3045bc..930fadf29898 100644
> > > --- a/lib/Makefile
> > > +++ b/lib/Makefile
> > > @@ -47,6 +47,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_I40E_PMD) +=
> librte_pmd_i40e
> > >  DIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += librte_pmd_bond
> > >  DIRS-$(CONFIG_RTE_LIBRTE_PMD_RING) += librte_pmd_ring
> > >  DIRS-$(CONFIG_RTE_LIBRTE_PMD_PCAP) += librte_pmd_pcap
> > > +DIRS-$(CONFIG_RTE_LIBRTE_PMD_PACKET) += librte_pmd_packet
> > >  DIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += librte_pmd_virtio
> > >  DIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += librte_pmd_vmxnet3
> > >  DIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += librte_pmd_xenvirt diff 
> > > --git a/lib/librte_eal/linuxapp/eal/Makefile
> b/lib/librte_eal/linuxapp/eal/Makefile
> > > index 756d6b0c9301..feed24a63272 100644
> > > --- a/lib/librte_eal/linuxapp/eal/Makefile
> > > +++ b/lib/librte_eal/linuxapp/eal/Makefile
> > > @@ -44,6 +44,7 @@ CFLAGS += -I$(RTE_SDK)/lib/librte_ether  CFLAGS 
> > > += -I$(RTE_SDK)/lib/librte_ivshmem  CFLAGS += 
> > > -I$(RTE_SDK)/lib/librte_pmd_ring  CFLAGS += 
> > > -I$(RTE_SDK)/lib/librte_pmd_pcap
> > > +CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_packet
> > >  CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_xenvirt
> > >  CFLAGS += $(WERROR_FLAGS) -O3
> > >
> > > diff --git a/lib/librte_pmd_packet/Makefile
> b/lib/librte_pmd_packet/Makefile
> > > new file mode 100644
> > > index 

[dpdk-dev] [PATCH] librte_pmd_packet: add PMD for AF_PACKET-based virtual devices

[Thomas Monjalon]

2014-07-10 16:32, John W. Linville:
> This is a Linux-specific virtual PMD driver backed by an AF_PACKET
> socket.  This implementation uses mmap'ed ring buffers to limit copying
> and user/kernel transitions.  The PACKET_FANOUT_HASH behavior of
> AF_PACKET is used for frame reception.  In the current implementation,
> Tx and Rx queues are always paired, and therefore are always equal
> in number -- changing this would be a Simple Matter Of Programming.
> 
> Interfaces of this type are created with a command line option like
> "--vdev=eth_packet0,iface=...".  There are a number of options availabe
> as arguments:
> 
>  - Interface is chosen by "iface" (required)
>  - Number of queue pairs set by "qpairs" (optional, default: 16)
>  - AF_PACKET MMAP block size set by "blocksz" (optional, default: 4096)
>  - AF_PACKET MMAP frame size set by "framesz" (optional, default: 2048)
>  - AF_PACKET MMAP frame count set by "framecnt" (optional, default: 512)
> 
> Signed-off-by: John W. Linville 
> ---
> This PMD is intended to provide a means for using DPDK on a broad
> range of hardware without hardware-specific PMDs and (hopefully)
> with better performance than what PCAP offers in Linux.  This might
> be useful as a development platform for DPDK applications when
> DPDK-supported hardware is expensive or unavailable.

Thank you for this nice work.

I think it would be well suited to host this PMD as an external one in order 
to make it work also with DPDK 1.7.0.

-- 
Thomas

[dpdk-dev] PMD for Cisco VIC Ethernet NIC - Request for guidelines for submission

[Hobywan Kenoby]

Hi Sujith,

It makes sens, using VFIO makes a far cleaner implementation. 
You worked on the performance, could you share some measurements ? Did you 
introduce vectorization functions as Intel did a while ago? There are allways 
tradeoffs between pps and latency, do you include documentation to configure 
the card for one or the other?
HK
From: ssuj...@cisco.com
To: hobywank at hotmail.com; dev at dpdk.org
Subject: Re: [dpdk-dev] PMD for Cisco VIC Ethernet NIC - Request for guidelines 
for submission
Date: Fri, 11 Jul 2014 07:46:08 +






Hi Hobywan,
Thanks for the email !



We?ve been working on performance benchmarking.  Also, we felt that it would be 
better to push the driver after Anatoly?s patch (vfio-pci) got in so that we 
could make the necessary modification before submission.  
Now that 1.7.0 is out, we are hopeful of submitting the patch soon.



Thanks,
-Sujith





From: Hobywan Kenoby 

Date: Thursday, 10 July 2014 1:37 am

To: "Sujith Sankar (ssujith)" , "dev at dpdk.org" 

Subject: RE: [dpdk-dev] PMD for Cisco VIC Ethernet NIC - Request for guidelines 
for submission







Hi Sujith,



It was exciting to see open source code coming from Cisco ensuring a DPDK 
application can run on any platform and with any card
I haven't seen your patch yet. What happened?



HK



> Date : Wed, 28 May 2014 08:06
> From : dev [mailto:dev-bounces at dpdk.org] 
> To :
dev at dpdk.org
> Subject : [dpdk-dev] PMD for Cisco VIC Ethernet NIC - Request for guidelines
> for submission
> 
> 
> Hi all,
> 
> We have been working on development of poll-mode driver for Cisco VIC
> Ethernet NIC and integration of it with DPDK.  We would like to submit this
> poll-mode driver (ENIC PMD) to the DPDK community so that it could be part
> of the DPDK tree.
> 
> Could someone please provide the guidelines and steps to do this?  As of
> now, ENIC PMD is being tested with DPDK 1.6.0r2.  Is it alright to submit a
> patch for DPDK 1.6.0r2?
> 
> One aspect of ENIC PMD is that it works with VFIO-PCI and not UIO.  Hope
> this is acceptable.  The following thread in dpdk-dev influenced this
> decision.
> 
http://dpdk.org/ml/archives/dev/2013-July/000373.html
> 
> ENIC PMD uses one interrupt per interface and it is used by the NIC for
> signalling the driver in case of any error.  Since this does not come in
> the fast path, it should be acceptable, isn?t it?
> 
> Please give your suggestions and comments.
> 
> Thanks,
> -Sujith

[dpdk-dev] [PATCH 0/7] vmxnet3: functionality enhancements

[Thomas Monjalon]

Hi Stephen,

2014-07-11 06:03, Stephen Hemminger:
> On Thu, 19 Jun 2014 23:02:30 -0700
> 
> Stephen Hemminger  wrote:
> > This set of patches adds new functionality to VMXNET3 and
> > removes some dead code, and fixes a memory leak.
> > 
> > These patches assume that the earlier VMXNET3 cleanup patches
> > sent to the mailing list are already merged (they haven't been yet).
> 
> Why were these patches totally ignored for 1.7.0 release?
> They include bugfixes and other stuff that was broken in the
> Intel driver. We even found more.

This patchset brought some new functionalities and was some post after the 
feature freeze.
As already said (http://dpdk.org/ml/archives/announce/2014-June/30.html), 
it should go now in master for 1.7.1 cycle.
It would be good to have some reviews on these patches.

> If patches are going to be ignored, why should bother sending them?

They weren't ignored, but you seem to ignore the announce emails.
Please keep cool and let's continue the good work.
-- 
Thomas

[dpdk-dev] [PATCH] librte_pmd_packet: add PMD for AF_PACKET-based virtual devices

[Richardson, Bruce]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of John W. Linville
> Sent: Friday, July 11, 2014 7:49 AM
> To: Stephen Hemminger
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] librte_pmd_packet: add PMD for AF_PACKET-
> based virtual devices
> 
> On Fri, Jul 11, 2014 at 06:11:47AM -0700, Stephen Hemminger wrote:
> > On Thu, 10 Jul 2014 16:32:49 -0400
> > "John W. Linville"  wrote:
> >
> > > This is a Linux-specific virtual PMD driver backed by an AF_PACKET
> > > socket.  This implementation uses mmap'ed ring buffers to limit copying
> > > and user/kernel transitions.  The PACKET_FANOUT_HASH behavior of
> > > AF_PACKET is used for frame reception.  In the current implementation,
> > > Tx and Rx queues are always paired, and therefore are always equal
> > > in number -- changing this would be a Simple Matter Of Programming.
> > >
> > > Interfaces of this type are created with a command line option like
> > > "--vdev=eth_packet0,iface=...".  There are a number of options availabe
> > > as arguments:
> > >
> > >  - Interface is chosen by "iface" (required)
> > >  - Number of queue pairs set by "qpairs" (optional, default: 16)
> > >  - AF_PACKET MMAP block size set by "blocksz" (optional, default: 4096)
> > >  - AF_PACKET MMAP frame size set by "framesz" (optional, default: 2048)
> > >  - AF_PACKET MMAP frame count set by "framecnt" (optional, default: 512)
> > >
> > > Signed-off-by: John W. Linville 
> > > ---
> > > This PMD is intended to provide a means for using DPDK on a broad
> > > range of hardware without hardware-specific PMDs and (hopefully)
> > > with better performance than what PCAP offers in Linux.  This might
> > > be useful as a development platform for DPDK applications when
> > > DPDK-supported hardware is expensive or unavailable.
> > >
> > >  config/common_bsdapp   |   5 +
> > >  config/common_linuxapp |   5 +
> > >  lib/Makefile   |   1 +
> > >  lib/librte_eal/linuxapp/eal/Makefile   |   1 +
> > >  lib/librte_pmd_packet/Makefile |  60 +++
> > >  lib/librte_pmd_packet/rte_eth_packet.c | 826
> +
> > >  lib/librte_pmd_packet/rte_eth_packet.h |  55 +++
> > >  mk/rte.app.mk  |   4 +
> > >  8 files changed, 957 insertions(+)
> > >  create mode 100644 lib/librte_pmd_packet/Makefile
> > >  create mode 100644 lib/librte_pmd_packet/rte_eth_packet.c
> > >  create mode 100644 lib/librte_pmd_packet/rte_eth_packet.h
> > >
> > > diff --git a/config/common_bsdapp b/config/common_bsdapp
> > > index 943dce8f1ede..c317f031278e 100644
> > > --- a/config/common_bsdapp
> > > +++ b/config/common_bsdapp
> > > @@ -226,6 +226,11 @@ CONFIG_RTE_LIBRTE_PMD_PCAP=y
> > >  CONFIG_RTE_LIBRTE_PMD_BOND=y
> > >
> > >  #
> > > +# Compile software PMD backed by AF_PACKET sockets (Linux only)
> > > +#
> > > +CONFIG_RTE_LIBRTE_PMD_PACKET=n
> > > +
> > > +#
> > >  # Do prefetch of packet data within PMD driver receive function
> > >  #
> > >  CONFIG_RTE_PMD_PACKET_PREFETCH=y
> > > diff --git a/config/common_linuxapp b/config/common_linuxapp
> > > index 7bf5d80d4e26..f9e7bc3015ec 100644
> > > --- a/config/common_linuxapp
> > > +++ b/config/common_linuxapp
> > > @@ -249,6 +249,11 @@ CONFIG_RTE_LIBRTE_PMD_PCAP=n
> > >  CONFIG_RTE_LIBRTE_PMD_BOND=y
> > >
> > >  #
> > > +# Compile software PMD backed by AF_PACKET sockets (Linux only)
> > > +#
> > > +CONFIG_RTE_LIBRTE_PMD_PACKET=y
> > > +
> > > +#
> > >  # Compile Xen PMD
> > >  #
> > >  CONFIG_RTE_LIBRTE_PMD_XENVIRT=n
> > > diff --git a/lib/Makefile b/lib/Makefile
> > > index 10c5bb3045bc..930fadf29898 100644
> > > --- a/lib/Makefile
> > > +++ b/lib/Makefile
> > > @@ -47,6 +47,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_I40E_PMD) +=
> librte_pmd_i40e
> > >  DIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += librte_pmd_bond
> > >  DIRS-$(CONFIG_RTE_LIBRTE_PMD_RING) += librte_pmd_ring
> > >  DIRS-$(CONFIG_RTE_LIBRTE_PMD_PCAP) += librte_pmd_pcap
> > > +DIRS-$(CONFIG_RTE_LIBRTE_PMD_PACKET) += librte_pmd_packet
> > >  DIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += librte_pmd_virtio
> > >  DIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += librte_pmd_vmxnet3
> > >  DIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += librte_pmd_xenvirt
> > > diff --git a/lib/librte_eal/linuxapp/eal/Makefile
> b/lib/librte_eal/linuxapp/eal/Makefile
> > > index 756d6b0c9301..feed24a63272 100644
> > > --- a/lib/librte_eal/linuxapp/eal/Makefile
> > > +++ b/lib/librte_eal/linuxapp/eal/Makefile
> > > @@ -44,6 +44,7 @@ CFLAGS += -I$(RTE_SDK)/lib/librte_ether
> > >  CFLAGS += -I$(RTE_SDK)/lib/librte_ivshmem
> > >  CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_ring
> > >  CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_pcap
> > > +CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_packet
> > >  CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_xenvirt
> > >  CFLAGS += $(WERROR_FLAGS) -O3
> > >
> > > diff --git a/lib/librte_pmd_packet/Makefile
> b/lib/librte_pmd_packet/Makefile
> > > new file mode 100644
> > > index ..e1266fb992cd
> > > 

[dpdk-dev] [PATCH] librte_pmd_packet: add PMD for AF_PACKET-based virtual devices

[John W. Linville]

Not sure what the issue might be, PACKET_FANOUT_FLAG_ROLLOVER is
defined in include/uapi/linux/if_packet.h in the v3.12 tree.

On Fri, Jul 11, 2014 at 06:01:27PM +, Zhou, Danny wrote:
> Tried on 3.12, both of them are undefined. Anyway, will comment them out and 
> see what performance it could achieve.
> 
> > -Original Message-
> > From: John W. Linville [mailto:linville at tuxdriver.com]
> > Sent: Saturday, July 12, 2014 1:41 AM
> > To: Zhou, Danny
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] librte_pmd_packet: add PMD for
> > AF_PACKET-based virtual devices
> > 
> > On Fri, Jul 11, 2014 at 05:20:42PM +, Zhou, Danny wrote:
> > > Looks like you used a pretty new kernel version with new socket options 
> > > that old
> > kernel like my 3.12 does not support. When I tried this patch, it just 
> > cannot build, and
> > compiler complains like below. Which Linux distribution does this patch 
> > work for?
> > How to ensure it works for old kernels?
> > >
> > > /home/danny/dpdk.org/dpdk/lib/librte_pmd_packet/rte_eth_packet.c: In 
> > > function
> > rte_pmd_init_internals:
> > > /home/danny/dpdk.org/dpdk/lib/librte_pmd_packet/rte_eth_packet.c:524:1
> > > 7: error: PACKET_FANOUT_FLAG_ROLLOVER undeclared (first use in this
> > > function)
> > > /home/danny/dpdk.org/dpdk/lib/librte_pmd_packet/rte_eth_packet.c:524:1
> > > 7: note: each undeclared identifier is reported only once for each
> > > function it appears in
> > > /home/danny/dpdk.org/dpdk/lib/librte_pmd_packet/rte_eth_packet.c:557:3
> > > 3: error: PACKET_QDISC_BYPASS undeclared (first use in this function)
> > 
> > Both of them are isolated, so for playing with it you could just comment 
> > those out.
> > It looks like PACKET_FANOUT_FLAG_ROLLOVER should have been in 3.10, while
> > PACKET_QDISC_BYPASS didn't show-up until 3.14...
> > 
> > /home/linville/git/linux
> > [linville-x1.hq.tuxdriver.com]:> git annotate 
> > include/uapi/linux/if_packet.h | grep
> > PACKET_FANOUT_FLAG_ROLLOVER
> > 77f65ebdca506   (Willem de Bruijn   2013-03-19 10:18:11 +   
> > 64)#define
> > PACKET_FANOUT_FLAG_ROLLOVER 0x1000
> > 
> > /home/linville/git/linux
> > [linville-x1.hq.tuxdriver.com]:> git show -s --format=short 77f65ebdca506 
> > commit
> > 77f65ebdca506870d99bfabe52bde222511022ec
> > Author: Willem de Bruijn 
> > 
> > packet: packet fanout rollover during socket overload
> > 
> > /home/linville/git/linux
> > [linville-x1.hq.tuxdriver.com]:> git describe --contains 77f65ebdca506
> > v3.10-rc1~66^2~423
> > 
> > /home/linville/git/linux
> > [linville-x1.hq.tuxdriver.com]:> git annotate 
> > include/uapi/linux/if_packet.h | grep
> > PACKET_QDISC_BYPASS
> > d346a3fae3ff1   (Daniel Borkmann2013-12-06 11:36:17 +0100   
> > 56)#define
> > PACKET_QDISC_BYPASS 20
> > 
> > /home/linville/git/linux
> > [linville-x1.hq.tuxdriver.com]:> git show -s --format=short d346a3fae3ff1 
> > commit
> > d346a3fae3ff1d99f5d0c819bf86edf9094a26a1
> > Author: Daniel Borkmann 
> > 
> > packet: introduce PACKET_QDISC_BYPASS socket option
> > 
> > /home/linville/git/linux
> > [linville-x1.hq.tuxdriver.com]:> git describe --contains d346a3fae3ff1
> > v3.14-rc1~94^2~564
> > 
> > Is there an example of code in DPDK that requires specific kernel versions? 
> >  What is
> > the preferred method for coding such dependencies?
> > 
> > John
> > --
> > John W. LinvilleSomeday the world will need a hero, and you
> > linville at tuxdriver.com   might be all we have.  Be ready.
> 

-- 
John W. LinvilleSomeday the world will need a hero, and you
linville at tuxdriver.com   might be all we have.  Be ready.

[dpdk-dev] DPDK with Ubuntu 14.04?

[Wiles, Roger Keith]

Hi Matt,

I normal only compile the core DPDK code and then compile my Pktgen traffic 
generator application
(git clone https://github.com/Pktgen/Pktgen-DPDK) which uses a fair amount of 
functions from DPDK.

Thanks
++Keith

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

[Powering 30 Years of Innovation]

On Jul 11, 2014, at 8:17 AM, Matt Laswell mailto:laswell at infiniteio.com>> wrote:

Thanks Roger,

We saw similar issues with regard to kcompat.h.  Can I ask if you've done 
anything beyond the example applications under 14.04?

--
Matt Laswell
infinite io


On Thu, Jul 10, 2014 at 7:07 PM, Wiles, Roger Keith mailto:keith.wiles at windriver.com>> wrote:
The one problem I had with 14.04 was the kcompat.h file. It looks like a hash 
routine has changed its arguments. I edited the kcompat.h file and was about to 
change the code to allow DPDK to build. It is not affix but it worked for me.

lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h

/*  Changed the next line to use (3,13,8) instead of (3,14,0) KeithW */
#if ( LINUX_VERSION_CODE < KERNEL_VERSION(3,13,8) )
#if (!(RHEL_RELEASE_CODE && RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(7,0)))
#ifdef NETIF_F_RXHASH
#define PKT_HASH_TYPE_L3 0

Hope that works.

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

[Powering 30 Years of Innovation]

On Jul 10, 2014, at 5:56 PM, Matt Laswell mailto:laswell at infiniteio.com>> wrote:

Hey Folks,

I know that official support hasn't moved past Ubuntu 12.04 LTS yet, but
does anybody have any practical experience running with 14.04 LTS?  My team
has run into one compilation error so far with 1.7, but other than that
things look OK at first blush.  I'd like to move my product to 14.04 for a
variety of reasons, but would hate to spend time chasing down subtle
incompatibilities.  I'm guessing we're not the first ones to try this...

Thanks.

--
Matt Laswell
infinite io

[dpdk-dev] VM2VM_HARDWARE mode on i350

[Wei-Chun Chao]

Hi,
I was playing with vhost example to measure VM to VM throughput. With
default SW mode I saw 9Gbps. While trying HW mode, traffic does not
work.

Looking at the code I saw a snippet in
lib/librte_pmd_ixgbe/ixgbe_rxtx.c:ixgbe_vmdq_rx_hw_configure -

/* PFDMA Tx General Switch Control Enables VMDQ loopback */
if (cfg->enable_loop_back) {
IXGBE_WRITE_REG(hw, IXGBE_PFDTXGSWC, IXGBE_PFDTXGSWC_VT_LBEN);
for (i = 0; i < RTE_IXGBE_VMTXSW_REGISTER_COUNT; i++)
IXGBE_WRITE_REG(hw, IXGBE_VMTXSW(i), UINT32_MAX);
}

But there is no corresponding code in
lib/librte_pmd_e1000/igb_rxtx.c:igb_vmdq_rx_hw_configure.

Is this expected behavior? Or just something not implemented?

I tried adding some code similar to the following but it didn't help.

dtxswc = rd32(E1000_TXSWC);
if (enable)
dtxswc |= E1000_DTXSWC_VMDQ_LOOPBACK_EN;
else
dtxswc &= ~E1000_DTXSWC_VMDQ_LOOPBACK_EN;
wr32(E1000_TXSWC, dtxswc);

Another question: I have a i210 that doesn't support VMDq and vhost
example does not run even with vm2vm_software. Why is VMDq needed for
sw mode?

Thanks,
Weichun

[dpdk-dev] [PATCH] librte_pmd_packet: add PMD for AF_PACKET-based virtual devices

[John W. Linville]

On Fri, Jul 11, 2014 at 05:38:17PM +, Richardson, Bruce wrote:
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> > Sent: Friday, July 11, 2014 9:48 AM
> > To: John W. Linville
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] librte_pmd_packet: add PMD for AF_PACKET-
> > based virtual devices
> > 
> > 2014-07-11 11:30, John W. Linville:
> > > On Fri, Jul 11, 2014 at 05:04:04PM +0200, Thomas Monjalon wrote:
> > > > 2014-07-11 10:51, John W. Linville:
> > > > > On Fri, Jul 11, 2014 at 03:26:39PM +0200, Thomas Monjalon wrote:
> > > > > > Thank you for this nice work.
> > > > > >
> > > > > > I think it would be well suited to host this PMD as an external one 
> > > > > > in
> > > > > > order to make it work also with DPDK 1.7.0.
> > > > >
> > > > > I'm not sure I understand the suggestion -- you don't want to merge
> > > > > the driver for 1.8?  Or you just want to host this patch somewhere,
> > > > > so people can still use it w/ 1.7?
> > > >
> > > > I suggest to have a separated repository here:
> > > > http://dpdk.org/browse/
> > >
> > > I really don't see any reason not to merge it.  It was already delayed
> > > by me waiting for all the PMD init changes to settle out in the 1.6
> > > release, and I still had to do a few touch-ups for it to compile on
> > > 1.7.  I definitely do not want to have to do that over and over again.
> > 
> > It's a pity that we didn't synchronize our efforts to make it integrated
> > during 1.7.0 cycle.
> > 
> > > Why wouldn't you just merge it?  If someone wants to use it on 1.7,
> > > they can just apply the patch.
> > 
> > I'm OK to merge it. I was only suggesting to host your PMD externally like 
> > we
> > did for virtio-net-pmd, vmxnet3-usermap and memnic.
> > It was the same discussion for the vmxnet3 PMD that Stephen submitted.
> > 
> > I start thinking that nobody wants PMD to be external. So we may merge this
> > one in dpdk.git and start talking what to do for the other ones:
> > - move memnic in dpdk.git?
> 
> Yes, I would agree with this. Having drivers in external git repos makes it 
> hard for us to take them into account when planning on making changes to the 
> core libs.
> 
> > - move virtio-net-pmd and vmxnet3-usermap where sits their uio
> > counterparts?
> > - merge Brocade's vmxnet3 as new one or as a replacement for
> > vmxnet3-uio?
> 
> For these we really should try and converge on a single solution. Having 
> multiple vmxnet3 and virtio drivers duplicates effort and is just plain 
> messy! Of course, that's easier to say than to agree on...

+1

-- 
John W. LinvilleSomeday the world will need a hero, and you
linville at tuxdriver.com   might be all we have.  Be ready.

[dpdk-dev] [PATCH] librte_pmd_packet: add PMD for AF_PACKET-based virtual devices

[John W. Linville]

On Fri, Jul 11, 2014 at 05:20:42PM +, Zhou, Danny wrote:
> Looks like you used a pretty new kernel version with new socket options that 
> old kernel like my 3.12 does not support. When I tried this patch, it just 
> cannot build, and compiler complains like below. Which Linux distribution 
> does this patch work for? How to ensure it works for old kernels?
> 
> /home/danny/dpdk.org/dpdk/lib/librte_pmd_packet/rte_eth_packet.c: In function 
> rte_pmd_init_internals:
> /home/danny/dpdk.org/dpdk/lib/librte_pmd_packet/rte_eth_packet.c:524:17: 
> error: PACKET_FANOUT_FLAG_ROLLOVER undeclared (first use in this function)
> /home/danny/dpdk.org/dpdk/lib/librte_pmd_packet/rte_eth_packet.c:524:17: 
> note: each undeclared identifier is reported only once for each function it 
> appears in
> /home/danny/dpdk.org/dpdk/lib/librte_pmd_packet/rte_eth_packet.c:557:33: 
> error: PACKET_QDISC_BYPASS undeclared (first use in this function)

Both of them are isolated, so for playing with it you could just
comment those out.  It looks like PACKET_FANOUT_FLAG_ROLLOVER should
have been in 3.10, while PACKET_QDISC_BYPASS didn't show-up until
3.14...

/home/linville/git/linux
[linville-x1.hq.tuxdriver.com]:> git annotate include/uapi/linux/if_packet.h | 
grep PACKET_FANOUT_FLAG_ROLLOVER
77f65ebdca506   (Willem de Bruijn   2013-03-19 10:18:11 +   
64)#define PACKET_FANOUT_FLAG_ROLLOVER  0x1000

/home/linville/git/linux
[linville-x1.hq.tuxdriver.com]:> git show -s --format=short 77f65ebdca506
commit 77f65ebdca506870d99bfabe52bde222511022ec
Author: Willem de Bruijn 

packet: packet fanout rollover during socket overload

/home/linville/git/linux
[linville-x1.hq.tuxdriver.com]:> git describe --contains 77f65ebdca506
v3.10-rc1~66^2~423

/home/linville/git/linux
[linville-x1.hq.tuxdriver.com]:> git annotate include/uapi/linux/if_packet.h | 
grep PACKET_QDISC_BYPASS
d346a3fae3ff1   (Daniel Borkmann2013-12-06 11:36:17 +0100   
56)#define PACKET_QDISC_BYPASS  20

/home/linville/git/linux
[linville-x1.hq.tuxdriver.com]:> git show -s --format=short d346a3fae3ff1
commit d346a3fae3ff1d99f5d0c819bf86edf9094a26a1
Author: Daniel Borkmann 

packet: introduce PACKET_QDISC_BYPASS socket option

/home/linville/git/linux
[linville-x1.hq.tuxdriver.com]:> git describe --contains d346a3fae3ff1
v3.14-rc1~94^2~564

Is there an example of code in DPDK that requires specific kernel
versions?  What is the preferred method for coding such dependencies?

John
-- 
John W. LinvilleSomeday the world will need a hero, and you
linville at tuxdriver.com   might be all we have.  Be ready.

[dpdk-dev] [PATCH] librte_pmd_packet: add PMD for AF_PACKET-based virtual devices

[John W. Linville]

On Fri, Jul 11, 2014 at 03:29:17PM +, Venkatesan, Venky wrote:
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of John W. Linville
> > Sent: Friday, July 11, 2014 7:49 AM
> > To: Stephen Hemminger
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] librte_pmd_packet: add PMD for 
> > AF_PACKET- based virtual devices
> > 
> > On Fri, Jul 11, 2014 at 06:11:47AM -0700, Stephen Hemminger wrote:
> > > On Thu, 10 Jul 2014 16:32:49 -0400
> > > "John W. Linville"  wrote:
> > >
> > > > This is a Linux-specific virtual PMD driver backed by an AF_PACKET 



> > > > +struct pkt_rx_queue {
> > > > +   int sockfd;
> > > > +
> > > > +   struct iovec *rd;
> > > > +   uint8_t *map;
> > > > +   unsigned int framecount;
> > > > +   unsigned int framenum;
> > > > +
> > > > +   struct rte_mempool *mb_pool;
> > > > +
> > > > +   volatile unsigned long rx_pkts;
> > > > +   volatile unsigned long err_pkts;
> > >
> > > Use of volatile will generate slow code, don't think it is 
> > > necessary, especially when only one CPU can use a queue at a time.
> > 
> > That is a good point, worth checking out.  FWIW, those lines are 
> > boilerplate originally copied from the pcap PMD. :-)
> > 
> 
> > Yes, I agree it's worth checking out if there is a performance impact, but 
> > if we assume that the stats for RX/TX are possibly going to be read by 
> > another core, they really should be volatile for correctness
> 
> Accessing the rx_queue structure directly for stats is unlikely to happen 
> from a second core; we should probably change the PCAP PMD as well (thanks 
> for pointing that out John). 

"Unlikely" doesn't sound completely safe... :-)

-- 
John W. LinvilleSomeday the world will need a hero, and you
linville at tuxdriver.com   might be all we have.  Be ready.

[dpdk-dev] [PATCH] librte_pmd_packet: add PMD for AF_PACKET-based virtual devices

[John W. Linville]

On Fri, Jul 11, 2014 at 05:04:04PM +0200, Thomas Monjalon wrote:
> 2014-07-11 10:51, John W. Linville:
> > On Fri, Jul 11, 2014 at 03:26:39PM +0200, Thomas Monjalon wrote:
> > > 2014-07-10 16:32, John W. Linville:
> > > > This is a Linux-specific virtual PMD driver backed by an AF_PACKET
> > > > socket.  This implementation uses mmap'ed ring buffers to limit copying
> > > > and user/kernel transitions.  The PACKET_FANOUT_HASH behavior of
> > > > AF_PACKET is used for frame reception.  In the current implementation,
> > > > Tx and Rx queues are always paired, and therefore are always equal
> > > > in number -- changing this would be a Simple Matter Of Programming.
> > > > 
> > > > Interfaces of this type are created with a command line option like
> > > > "--vdev=eth_packet0,iface=...".  There are a number of options availabe
> > > > 
> > > > as arguments:
> > > >  - Interface is chosen by "iface" (required)
> > > >  - Number of queue pairs set by "qpairs" (optional, default: 16)
> > > >  - AF_PACKET MMAP block size set by "blocksz" (optional, default: 4096)
> > > >  - AF_PACKET MMAP frame size set by "framesz" (optional, default: 2048)
> > > >  - AF_PACKET MMAP frame count set by "framecnt" (optional, default: 512)
> > > > 
> > > > Signed-off-by: John W. Linville 
> > > > ---
> > > > This PMD is intended to provide a means for using DPDK on a broad
> > > > range of hardware without hardware-specific PMDs and (hopefully)
> > > > with better performance than what PCAP offers in Linux.  This might
> > > > be useful as a development platform for DPDK applications when
> > > > DPDK-supported hardware is expensive or unavailable.
> > > 
> > > Thank you for this nice work.
> > > 
> > > I think it would be well suited to host this PMD as an external one in
> > > order to make it work also with DPDK 1.7.0.
> > 
> > I'm not sure I understand the suggestion -- you don't want to merge
> > the driver for 1.8?  Or you just want to host this patch somewhere,
> > so people can still use it w/ 1.7?
> 
> I suggest to have a separated repository here:
>   http://dpdk.org/browse/

I really don't see any reason not to merge it.  It was already delayed
by me waiting for all the PMD init changes to settle out in the 1.6
release, and I still had to do a few touch-ups for it to compile on
1.7.  I definitely do not want to have to do that over and over again.

Why wouldn't you just merge it?  If someone wants to use it on 1.7,
they can just apply the patch.

John
-- 
John W. LinvilleSomeday the world will need a hero, and you
linville at tuxdriver.com   might be all we have.  Be ready.

[dpdk-dev] DPDK Performance issue with l2fwd

[zachary....@cas-well.com]

Hi Bruce:

Thanks for your suggestion.
I have tried to use testpmd to test 16 ports today.
The result is so Interested. It can work, although some ports get low
performance (only get 80%).

Besides, I also do another test in l2fwd.
I tried to use 82580 * 16 ports in the same platform with l2fwd test.
The same situation happened again.
So, it seems a big bug hidden in the l2fwd.

Have someone get the similar case?

BTW, may this issue relate with DPDK version?


On 07/10/2014 11:53 PM, Richardson, Bruce wrote:
> Hi,
>
> Have you tried running a test with 16 ports using any other applications, for 
> example testpmd?
>
> Regards,
> /Bruce
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zachary.Jen at cas-
>> well.com
>> Sent: Thursday, July 10, 2014 2:29 AM
>> To: dev at dpdk.org
>> Cc: Alan.Yu at cas-well.com
>> Subject: Re: [dpdk-dev] DPDK Performance issue with l2fwd
>>
>> Hi Alex:
>>
>> Thanks for your help.
>>
>> I forget to describe some criteria in my original post.
>>
>> At first, I has confirmed my 82599 has connected by PCIe Gen3 (Gen3 x8) 
>> speed.
>> The theoretical bandwidth can support over 160G in total.
>> Hence, It should get full speed in my test.
>>
>> Second, I have ever check the performance w/o DPDK in packet size 1518 in the
>> same environment, and indeed it can get 160G totally (by IRQ balance method).
>> So, I was so surprised to get this kinds of result in DPDK (I also use size 
>> 1518 to
>> test DPDK).
>>
>> BTW, I can get 120G throughput in 12 ports already. But when I add more than
>> 12 ports, I only can get 100G.
>> Why the performance gets less than 120G? Why only 10 ports works fine and NO
>> Tx and Rx in the others?
>> Is it bugs or limitations in DPDK?
>>
>> Has anyone every do the similar or the same test?
>>
>>
>> On 07/10/2014 04:40 PM, Alex Markuze wrote:
>> Hi Zachary,
>> Your issue may be with the PCI-e 3, with 16 lanes Each slot is limited to
>> 128Gb/s[3].
>> Now, AFAIK[1] the CPU is connected to the  I/O with a single PCI-E slot.
>>
>> Several thoughts that may help you:
>>
>> 1. You can figure out the max b/w by running netsurf over the kernel 
>> interfaces
>> (w/o DPDK). Each CPU can handle the Netperf and the Completion interrupts
>> with grace (packets of 64K and all offloads on) for 10Gb nics.
>> With more then 10 Nics I would disable the IRQ balancer and make sure
>> interrupts are spread evenly by setting the  IRQ affinity manually [2].
>> As long as you have a physical core(NO hyperthreading) per NIC port you can
>> figure out the MAX B/W you can get with all the nics.
>>
>> 2. You can try using (If available to you , obviously) 40Gb and 56Gb Nics
>> (Mellanox), In this case for each Netperf flow you will need to separate each
>> Netperf Stream and the interrupts to different Cores to Reach wire speed as
>> long as both cores are on the same NUMA node(lscpu).
>>
>> Hope this helps.
>>
>> [1]http://komposter.com.ua/documents/PCI_Express_Base_Specification_Revis
>> ion_3.0.pdf
>> [2]http://h50146.www5.hp.com/products/software/oe/linux/mainstream/supp
>> ort/whitepaper/pdfs/4AA4-9294ENW.pdf
>> [3]http://en.wikipedia.org/wiki/PCI_Express#PCI_Express_3.x
>>
>>
>> On Thu, Jul 10, 2014 at 11:07 AM, > well.com> wrote:
>> Hey Guys,
>>
>> Recently, I have used l2fwd to test 160G (82599 10G * 16 ports), but I
>> got a strange pheromone in my test.
>>
>> When I used 12 ports to test the performance of l2fwd, it can work fine
>> and achieve 120G.
>> But it got abnormal when I using over than 12 port. Part of ports seems
>> something wrong and no any Tx/Rx.
>> Has anyone know about this?
>>
>> My testing Environment.
>> 1. E5-2658 v2 (10 cores) * 2
>> http://ark.intel.com/zh-tw/products/76160/Intel-Xeon-Processor-E5-2658-v2-
>> 25M-Cache-2_40-GHz
>> 2. one core handle one port. (In order to get best performance.)
>> 3. No any QPI crossing  issue.
>> 4. l2fwd parameters
>>   4.1 -c 0xF0FF -- -P 0xF00FF  => 120G get!
>>   4.2 -c 0xFF0FF -- -P 0xFF0FF => Failed! Only first 10 ports can
>> work well.
>>   4.3 -c 0x3F3FF -- -P 0x3F3FF => Failed! Only first 10 ports can
>> work well.
>>
>> BTW, I have tried lots of parameter sets and if I set the ports number
>> over than 12 ports, it only first 10 ports got work.
>> Else, everything got well.
>>
>> Can anyone help me to solve the issue? Or DPDK only can set less equal
>> than 12 ports?
>> Or DPDK max throughput is 120G?
>>
>> 
>> ? This email may contain confidential
>> information. Please do not use or disclose it in any way and delete it if 
>> you are
>> not the intended recipient.
>>
>>
>>
>> --
>> Best Regards,
>> Zachary Jen
>>
>> Software RD
>> CAS-WELL Inc.
>> 8th Floor, No. 242, Bo-Ai St., Shu-Lin City, Taipei County 238, Taiwan
>> Tel: +886-2-7705-#6305
>> Fax: +886-2-7731-9988
>>
>> 
>> ? This email may contain confidential
>> 

[dpdk-dev] [PATCH] librte_pmd_packet: add PMD for AF_PACKET-based virtual devices

[John W. Linville]

On Fri, Jul 11, 2014 at 06:11:47AM -0700, Stephen Hemminger wrote:
> On Thu, 10 Jul 2014 16:32:49 -0400
> "John W. Linville"  wrote:
> 
> > This is a Linux-specific virtual PMD driver backed by an AF_PACKET
> > socket.  This implementation uses mmap'ed ring buffers to limit copying
> > and user/kernel transitions.  The PACKET_FANOUT_HASH behavior of
> > AF_PACKET is used for frame reception.  In the current implementation,
> > Tx and Rx queues are always paired, and therefore are always equal
> > in number -- changing this would be a Simple Matter Of Programming.
> > 
> > Interfaces of this type are created with a command line option like
> > "--vdev=eth_packet0,iface=...".  There are a number of options availabe
> > as arguments:
> > 
> >  - Interface is chosen by "iface" (required)
> >  - Number of queue pairs set by "qpairs" (optional, default: 16)
> >  - AF_PACKET MMAP block size set by "blocksz" (optional, default: 4096)
> >  - AF_PACKET MMAP frame size set by "framesz" (optional, default: 2048)
> >  - AF_PACKET MMAP frame count set by "framecnt" (optional, default: 512)
> > 
> > Signed-off-by: John W. Linville 
> > ---
> > This PMD is intended to provide a means for using DPDK on a broad
> > range of hardware without hardware-specific PMDs and (hopefully)
> > with better performance than what PCAP offers in Linux.  This might
> > be useful as a development platform for DPDK applications when
> > DPDK-supported hardware is expensive or unavailable.
> > 
> >  config/common_bsdapp   |   5 +
> >  config/common_linuxapp |   5 +
> >  lib/Makefile   |   1 +
> >  lib/librte_eal/linuxapp/eal/Makefile   |   1 +
> >  lib/librte_pmd_packet/Makefile |  60 +++
> >  lib/librte_pmd_packet/rte_eth_packet.c | 826 
> > +
> >  lib/librte_pmd_packet/rte_eth_packet.h |  55 +++
> >  mk/rte.app.mk  |   4 +
> >  8 files changed, 957 insertions(+)
> >  create mode 100644 lib/librte_pmd_packet/Makefile
> >  create mode 100644 lib/librte_pmd_packet/rte_eth_packet.c
> >  create mode 100644 lib/librte_pmd_packet/rte_eth_packet.h
> > 
> > diff --git a/config/common_bsdapp b/config/common_bsdapp
> > index 943dce8f1ede..c317f031278e 100644
> > --- a/config/common_bsdapp
> > +++ b/config/common_bsdapp
> > @@ -226,6 +226,11 @@ CONFIG_RTE_LIBRTE_PMD_PCAP=y
> >  CONFIG_RTE_LIBRTE_PMD_BOND=y
> >  
> >  #
> > +# Compile software PMD backed by AF_PACKET sockets (Linux only)
> > +#
> > +CONFIG_RTE_LIBRTE_PMD_PACKET=n
> > +
> > +#
> >  # Do prefetch of packet data within PMD driver receive function
> >  #
> >  CONFIG_RTE_PMD_PACKET_PREFETCH=y
> > diff --git a/config/common_linuxapp b/config/common_linuxapp
> > index 7bf5d80d4e26..f9e7bc3015ec 100644
> > --- a/config/common_linuxapp
> > +++ b/config/common_linuxapp
> > @@ -249,6 +249,11 @@ CONFIG_RTE_LIBRTE_PMD_PCAP=n
> >  CONFIG_RTE_LIBRTE_PMD_BOND=y
> >  
> >  #
> > +# Compile software PMD backed by AF_PACKET sockets (Linux only)
> > +#
> > +CONFIG_RTE_LIBRTE_PMD_PACKET=y
> > +
> > +#
> >  # Compile Xen PMD
> >  #
> >  CONFIG_RTE_LIBRTE_PMD_XENVIRT=n
> > diff --git a/lib/Makefile b/lib/Makefile
> > index 10c5bb3045bc..930fadf29898 100644
> > --- a/lib/Makefile
> > +++ b/lib/Makefile
> > @@ -47,6 +47,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += librte_pmd_i40e
> >  DIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += librte_pmd_bond
> >  DIRS-$(CONFIG_RTE_LIBRTE_PMD_RING) += librte_pmd_ring
> >  DIRS-$(CONFIG_RTE_LIBRTE_PMD_PCAP) += librte_pmd_pcap
> > +DIRS-$(CONFIG_RTE_LIBRTE_PMD_PACKET) += librte_pmd_packet
> >  DIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += librte_pmd_virtio
> >  DIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += librte_pmd_vmxnet3
> >  DIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += librte_pmd_xenvirt
> > diff --git a/lib/librte_eal/linuxapp/eal/Makefile 
> > b/lib/librte_eal/linuxapp/eal/Makefile
> > index 756d6b0c9301..feed24a63272 100644
> > --- a/lib/librte_eal/linuxapp/eal/Makefile
> > +++ b/lib/librte_eal/linuxapp/eal/Makefile
> > @@ -44,6 +44,7 @@ CFLAGS += -I$(RTE_SDK)/lib/librte_ether
> >  CFLAGS += -I$(RTE_SDK)/lib/librte_ivshmem
> >  CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_ring
> >  CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_pcap
> > +CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_packet
> >  CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_xenvirt
> >  CFLAGS += $(WERROR_FLAGS) -O3
> >  
> > diff --git a/lib/librte_pmd_packet/Makefile b/lib/librte_pmd_packet/Makefile
> > new file mode 100644
> > index ..e1266fb992cd
> > --- /dev/null
> > +++ b/lib/librte_pmd_packet/Makefile
> > @@ -0,0 +1,60 @@
> > +#   BSD LICENSE
> > +#
> > +#   Copyright(c) 2014 John W. Linville 
> > +#   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
> > +#   Copyright(c) 2014 6WIND S.A.
> > +#   All rights reserved.
> > +#
> > +#   Redistribution and use in source and binary forms, with or without
> > +#   modification, are permitted provided that the following conditions
> > +#   are met:
> > +#
> > +# 

[dpdk-dev] [PATCH] kni: use netif_rx instead of netif_receive_skb in which ocurr deallock on userpace contex

[Thomas Monjalon]

Hi,

Thank you for sending this patch.
Please, could you re-send it with a more detailed explanation and a
Signed-off-by line?

There is a how-to for patch contributions here:
http://dpdk.org/dev#send


2014-07-11 01:04, Yao-Po Wang:
> ---
>  lib/librte_eal/linuxapp/kni/kni_net.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/librte_eal/linuxapp/kni/kni_net.c
> b/lib/librte_eal/linuxapp/kni/kni_net.c index d3c0190..28cc5ab 100644
> --- a/lib/librte_eal/linuxapp/kni/kni_net.c
> +++ b/lib/librte_eal/linuxapp/kni/kni_net.c
> @@ -179,7 +179,7 @@ kni_net_rx_normal(struct kni_dev *kni)
>   skb->ip_summed = CHECKSUM_UNNECESSARY;
> 
>   /* Call netif interface */
> - netif_receive_skb(skb);
> + netif_rx(skb);
> 
>   /* Update statistics */
>   kni->stats.rx_bytes += len;

[dpdk-dev] DPDK with Ubuntu 14.04?

[Matt Laswell]

Thanks Roger,

We saw similar issues with regard to kcompat.h.  Can I ask if you've done
anything beyond the example applications under 14.04?

--
Matt Laswell
infinite io


On Thu, Jul 10, 2014 at 7:07 PM, Wiles, Roger Keith <
keith.wiles at windriver.com> wrote:

>  The one problem I had with 14.04 was the kcompat.h file. It looks like a
> hash routine has changed its arguments. I edited the kcompat.h file and was
> about to change the code to allow DPDK to build. It is not affix but it
> worked for me.
>
>  lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
>
>  /*  Changed the next line to use (3,13,8) instead of (3,14,0) KeithW
> */
> #if ( LINUX_VERSION_CODE < KERNEL_VERSION(3,13,8) )
> #if (!(RHEL_RELEASE_CODE && RHEL_RELEASE_CODE >=
> RHEL_RELEASE_VERSION(7,0)))
> #ifdef NETIF_F_RXHASH
> #define PKT_HASH_TYPE_L3 0
>
>  *Hope that works.*
>
>  *Keith **Wiles*, Principal Technologist with CTO office, *Wind River*
> mobile 972-213-5533
>
> [image: Powering 30 Years of Innovation]
> 
>
>  On Jul 10, 2014, at 5:56 PM, Matt Laswell  wrote:
>
> Hey Folks,
>
> I know that official support hasn't moved past Ubuntu 12.04 LTS yet, but
> does anybody have any practical experience running with 14.04 LTS?  My team
> has run into one compilation error so far with 1.7, but other than that
> things look OK at first blush.  I'd like to move my product to 14.04 for a
> variety of reasons, but would hate to spend time chasing down subtle
> incompatibilities.  I'm guessing we're not the first ones to try this...
>
> Thanks.
>
> --
> Matt Laswell
> infinite io
>
>
>

[dpdk-dev] Build failure on Ubuntu 14.04

[Choi, Sy Jong]

Hi Waterman

I'm seeing the same problem, here is my Ubuntu version, I'm using ubunto 
desktop.
Linux schoi5-desktop 3.13.0-30-generic #55-Ubuntu SMP Fri Jul 4 21:40:53 UTC 
2014 x86_64 x86_64 x86_64 GNU/Linux


Regards,
Choi, Sy Jong
Platform Application Engineer


-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Cao, Waterman
Sent: Monday, July 07, 2014 4:13 PM
To: Wiles, Roger Keith (Wind River); 
Subject: Re: [dpdk-dev] Build failure on Ubuntu 14.04

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.horg/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/li
>b/librte_eal/linuxapp/kni/e1000_82575.oinuxapp-gcc/build/lib/librte_eal/linuxapp/kni/e1000_82575.o>k.org/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/kni/e100
>0_82575.o>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/li
>b/librte_eal/linuxapp/kni/e1000_82575.c:38:ve-linuxapp-gcc/build/lib/librte_eal/linuxapp/kni/e1000_82575.c:38:>tp://dpdk.org/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/
>kni/e1000_82575.c:38:>/lib/librte_eal/linuxapp/kni/e1000_82575.c:38:>

[dpdk-dev] PMD for Cisco VIC Ethernet NIC - Request for guidelines for submission

[Sujith Sankar (ssujith)]

Hi Hobywan,
Thanks for the email !

We?ve been working on performance benchmarking.  Also, we felt that it would be 
better to push the driver after Anatoly?s patch (vfio-pci) got in so that we 
could make the necessary modification before submission.
Now that 1.7.0 is out, we are hopeful of submitting the patch soon.

Thanks,
-Sujith

From: Hobywan Kenoby mailto:hobyw...@hotmail.com>>
Date: Thursday, 10 July 2014 1:37 am
To: "Sujith Sankar (ssujith)" mailto:ssujith at 
cisco.com>>, "dev at dpdk.org" mailto:dev at dpdk.org>>
Subject: RE: [dpdk-dev] PMD for Cisco VIC Ethernet NIC - Request for guidelines 
for submission

Hi Sujith,

It was exciting to see open source code coming from Cisco ensuring a DPDK 
application can run on any platform and with any card
I haven't seen your patch yet. What happened?

HK





> Date : Wed, 28 May 2014 08:06

> From : dev [mailto:dev-bounces at dpdk.org]

> To : dev at dpdk.org

> Subject : [dpdk-dev] PMD for Cisco VIC Ethernet NIC - Request for guidelines

> for submission

>

>

> Hi all,

>

> We have been working on development of poll-mode driver for Cisco VIC

> Ethernet NIC and integration of it with DPDK.  We would like to submit this

> poll-mode driver (ENIC PMD) to the DPDK community so that it could be part

> of the DPDK tree.

>

> Could someone please provide the guidelines and steps to do this?  As of

> now, ENIC PMD is being tested with DPDK 1.6.0r2.  Is it alright to submit a

> patch for DPDK 1.6.0r2?

>

> One aspect of ENIC PMD is that it works with VFIO-PCI and not UIO.  Hope

> this is acceptable.  The following thread in dpdk-dev influenced this

> decision.

> http://dpdk.org/ml/archives/dev/2013-July/000373.html

>

> ENIC PMD uses one interrupt per interface and it is used by the NIC for

> signalling the driver in case of any error.  Since this does not come in

> the fast path, it should be acceptable, isn?t it?

>

> Please give your suggestions and comments.

>

> Thanks,

> -Sujith

[dpdk-dev] [PATCH] librte_pmd_packet: add PMD for AF_PACKET-based virtual devices

[Stephen Hemminger]

On Thu, 10 Jul 2014 16:32:49 -0400
"John W. Linville"  wrote:

> This is a Linux-specific virtual PMD driver backed by an AF_PACKET
> socket.  This implementation uses mmap'ed ring buffers to limit copying
> and user/kernel transitions.  The PACKET_FANOUT_HASH behavior of
> AF_PACKET is used for frame reception.  In the current implementation,
> Tx and Rx queues are always paired, and therefore are always equal
> in number -- changing this would be a Simple Matter Of Programming.
> 
> Interfaces of this type are created with a command line option like
> "--vdev=eth_packet0,iface=...".  There are a number of options availabe
> as arguments:
> 
>  - Interface is chosen by "iface" (required)
>  - Number of queue pairs set by "qpairs" (optional, default: 16)
>  - AF_PACKET MMAP block size set by "blocksz" (optional, default: 4096)
>  - AF_PACKET MMAP frame size set by "framesz" (optional, default: 2048)
>  - AF_PACKET MMAP frame count set by "framecnt" (optional, default: 512)
> 
> Signed-off-by: John W. Linville 
> ---
> This PMD is intended to provide a means for using DPDK on a broad
> range of hardware without hardware-specific PMDs and (hopefully)
> with better performance than what PCAP offers in Linux.  This might
> be useful as a development platform for DPDK applications when
> DPDK-supported hardware is expensive or unavailable.
> 
>  config/common_bsdapp   |   5 +
>  config/common_linuxapp |   5 +
>  lib/Makefile   |   1 +
>  lib/librte_eal/linuxapp/eal/Makefile   |   1 +
>  lib/librte_pmd_packet/Makefile |  60 +++
>  lib/librte_pmd_packet/rte_eth_packet.c | 826 
> +
>  lib/librte_pmd_packet/rte_eth_packet.h |  55 +++
>  mk/rte.app.mk  |   4 +
>  8 files changed, 957 insertions(+)
>  create mode 100644 lib/librte_pmd_packet/Makefile
>  create mode 100644 lib/librte_pmd_packet/rte_eth_packet.c
>  create mode 100644 lib/librte_pmd_packet/rte_eth_packet.h
> 
> diff --git a/config/common_bsdapp b/config/common_bsdapp
> index 943dce8f1ede..c317f031278e 100644
> --- a/config/common_bsdapp
> +++ b/config/common_bsdapp
> @@ -226,6 +226,11 @@ CONFIG_RTE_LIBRTE_PMD_PCAP=y
>  CONFIG_RTE_LIBRTE_PMD_BOND=y
>  
>  #
> +# Compile software PMD backed by AF_PACKET sockets (Linux only)
> +#
> +CONFIG_RTE_LIBRTE_PMD_PACKET=n
> +
> +#
>  # Do prefetch of packet data within PMD driver receive function
>  #
>  CONFIG_RTE_PMD_PACKET_PREFETCH=y
> diff --git a/config/common_linuxapp b/config/common_linuxapp
> index 7bf5d80d4e26..f9e7bc3015ec 100644
> --- a/config/common_linuxapp
> +++ b/config/common_linuxapp
> @@ -249,6 +249,11 @@ CONFIG_RTE_LIBRTE_PMD_PCAP=n
>  CONFIG_RTE_LIBRTE_PMD_BOND=y
>  
>  #
> +# Compile software PMD backed by AF_PACKET sockets (Linux only)
> +#
> +CONFIG_RTE_LIBRTE_PMD_PACKET=y
> +
> +#
>  # Compile Xen PMD
>  #
>  CONFIG_RTE_LIBRTE_PMD_XENVIRT=n
> diff --git a/lib/Makefile b/lib/Makefile
> index 10c5bb3045bc..930fadf29898 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -47,6 +47,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += librte_pmd_i40e
>  DIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += librte_pmd_bond
>  DIRS-$(CONFIG_RTE_LIBRTE_PMD_RING) += librte_pmd_ring
>  DIRS-$(CONFIG_RTE_LIBRTE_PMD_PCAP) += librte_pmd_pcap
> +DIRS-$(CONFIG_RTE_LIBRTE_PMD_PACKET) += librte_pmd_packet
>  DIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += librte_pmd_virtio
>  DIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += librte_pmd_vmxnet3
>  DIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += librte_pmd_xenvirt
> diff --git a/lib/librte_eal/linuxapp/eal/Makefile 
> b/lib/librte_eal/linuxapp/eal/Makefile
> index 756d6b0c9301..feed24a63272 100644
> --- a/lib/librte_eal/linuxapp/eal/Makefile
> +++ b/lib/librte_eal/linuxapp/eal/Makefile
> @@ -44,6 +44,7 @@ CFLAGS += -I$(RTE_SDK)/lib/librte_ether
>  CFLAGS += -I$(RTE_SDK)/lib/librte_ivshmem
>  CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_ring
>  CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_pcap
> +CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_packet
>  CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_xenvirt
>  CFLAGS += $(WERROR_FLAGS) -O3
>  
> diff --git a/lib/librte_pmd_packet/Makefile b/lib/librte_pmd_packet/Makefile
> new file mode 100644
> index ..e1266fb992cd
> --- /dev/null
> +++ b/lib/librte_pmd_packet/Makefile
> @@ -0,0 +1,60 @@
> +#   BSD LICENSE
> +#
> +#   Copyright(c) 2014 John W. Linville 
> +#   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
> +#   Copyright(c) 2014 6WIND S.A.
> +#   All rights reserved.
> +#
> +#   Redistribution and use in source and binary forms, with or without
> +#   modification, are permitted provided that the following conditions
> +#   are met:
> +#
> +# * Redistributions of source code must retain the above copyright
> +#   notice, this list of conditions and the following disclaimer.
> +# * Redistributions in binary form must reproduce the above copyright
> +#   notice, this list of conditions and the following disclaimer in
> +#   

[dpdk-dev] [PATCH 0/7] vmxnet3: functionality enhancements

[Stephen Hemminger]

On Thu, 19 Jun 2014 23:02:30 -0700
Stephen Hemminger  wrote:

> This set of patches adds new functionality to VMXNET3 and
> removes some dead code, and fixes a memory leak.
> 
> These patches assume that the earlier VMXNET3 cleanup patches
> sent to the mailing list are already merged (they haven't been yet).
> 
> 
> 

Why were these patches totally ignored for 1.7.0 release?
They include bugfixes and other stuff that was broken in the
Intel driver. We even found more.

If patches are going to be ignored, why should bother sending them?

[dpdk-dev] [PATCH 0/6] Clang compilation support on FreeBSD and Linux

[Zhan, Zhaochen]

> > This patch set enables clang compilation on FreeBSD and Linux. It
> > includes patches to fix a number of compilation errors thrown up by
> > clang, and then adds in the appropriate toolchain makefiles and
> > compile-time configurations.
> >
> > This set has been tested with clang v3.3 on FreeBSD 10 and clang
> > v3.4 on Fedora linux 20. The example apps folder has not been tested
> > at this time, this patch set only focuses on the core libraries and apps.
> >
> > Bruce Richardson (6):
> >   pmd_bond: add missing variable initialization
> >   Makefiles: add clang to compiler if/else block
> >   mk: Ensure correct detection of SSE4.2 on FreeBSD
> >   acl: add nmmintrin.h header to allow clang compilation
> >   mk: add toolchain for clang and linuxapp target
> >   config: add compile target for clang on BSD
>
> Tested-by: Zhaochen Zhan mailto:zhaochen.zhan at 
> intel.com>>
>
> We verified the compilation on FreeBSD 10.0 with Clang 3.3 and Fedora
> 20 with Clang 3.4.
> We also verified some simple test cases (pmd, cmdline, hello_world and
> timer) on FreeBSD with Clang 3.3.

Acked-by: Zhaochen Zhan mailto:zhaochen.zhan at 
intel.com>>

[dpdk-dev] Running kni with low amount of cores

[Zhang, Helin]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olson, Matt Lyle
> Sent: Thursday, July 10, 2014 4:12 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] Running kni with low amount of cores
> 
> Hello,
> 
> I have two NIC devices and a quad core system that I'm trying to run kni on. I
> would like to leave two cores for general use and two cores for kni. When run
> kni on just one of the ports, everything works fine and I can use that vEth
> normally. The exact command I run is this: ./kni -c 0x0c -n 2 -- -P -p 0x1
> -config="(0,2,3)" But when I try to run kni on both ports, I can't find a
> configuration to make it work. Here's all the configs that I have tried, but 
> none
> of them seem to work properly, the same way as just a single port: "(0,2,3),
> (1,2,3)" "(0,2,3), (1,3,2)""(0,2,2), (1,3,3)". I'm wondering if it is
> supposed to work this way,  where each port needs its own Tx and Rx core, or
> if there is a way to get around it. If it is supposed to work this way, would 
> it be
> worth my time to edit the code to allow me to have all Rx information dealt
> with on one core and all Tx on another?
> 
> Thanks,
> Matt Olson

Hi Matt

For the KNI example application, each lcore is used for RX or TX of a port 
only, you can check the first part of code in main_loop() in 
examples/kni/main.c.
It assumes that the number of lcores is not the bottle neck.

So for the scenario of yours, that might be supported. But it would not be too 
difficult to support your case by modifying the example application by yourself.

Regards,
Helin

[dpdk-dev] Error while inserting module /build/kmod/igb_uio.ko

[Daniel, Christopher]

Chris,

Here is what I verified...

>> $ uname -r
3.12.6

>> $ grep __fentry__ /proc/kallsyms
Nothing found here.

>> $ grep CONFIG_FTRACE /lib/modules/$(uname -r)/build/.config
CONFIG_FTRACE=y
CONFIG_FTRACE_SYSCALLS=y
CONFIG_FTRACE_MCOUNT_RECORD=y
# CONFIG_FTRACE_STARTUP_TEST is not set



-Original Message-
From: Chris Wright [mailto:chr...@redhat.com] 
Sent: Thursday, July 10, 2014 6:51 PM
To: Daniel, Christopher
Cc: Chris Wright; dev at dpdk.org
Subject: Re: [dpdk-dev] Error while inserting module /build/kmod/igb_uio.ko

* Daniel, Christopher (Chris.Daniel at flukenetworks.com) wrote:
> > On Jul 10, 2014, at 6:31 PM, "Chris Wright"  wrote:
> > * Daniel, Christopher (Chris.Daniel at flukenetworks.com) wrote:
> >> Linux localhost.localdomain 3.12.6 #4 SMP Fri Dec 27 14:26:57 EST 
> >> 2013 x86_64 x86_64 x86_64 GNU/Linux : Centos

OK, I expected to see a suffix like 3.12.6.el...(why I assumed you built your 
own kernel)

> >> 1)  Downloaded the latest version of DPK ( 1.7);
> >> 2)  Executing the quick start instructions ( running gcc 4.7.x)
> >> 3)  Having an issue with
> >>  # insmod build/kmod/igb_uio.ko I am getting
> >> insmod: error inserting './build/kmod/igb_uio.ko': -1 Unknown 
> >> symbol in module
> >> 
> >> dmesg:
> >> igb_uio: Unknown symbol __fentry__ (err 0)
> > 
> > seems like you have built module w/ CONFIG_FTRACE and built kernel 
> > w/out.  did you manually set RTE_KERNELDIR when you built (if so, is 
> > it pointing to the right location?)
> 
> Actually I did not build the kernel. It is unmodified from the original 
> centos download.
> I also did not change any build parameters while building the module.
> Used all the defaults from the download and executed the commands as in the 
> quick start guide.
> Is there something I can change and rebuild the dpk module ?

Hmm, you could verify a couple things:

$ uname -r
$ grep __fentry__ /proc/kallsyms
$ grep CONFIG_FTRACE /lib/modules/$(uname -r)/build/.config

thanks,
-chris

[dpdk-dev] [PATCH] nic_uio: add device ids for i40e devices

[Richardson, Bruce]

The FreeBSD nic_uio driver was missing the #defines to include the device ids
for devices using the i40e driver. This change adds in the missing defines.

Signed-off-by: Bruce Richardson 
---
 lib/librte_eal/bsdapp/nic_uio/nic_uio.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/librte_eal/bsdapp/nic_uio/nic_uio.c 
b/lib/librte_eal/bsdapp/nic_uio/nic_uio.c
index 3fe6f1c..8ba7f1b 100644
--- a/lib/librte_eal/bsdapp/nic_uio/nic_uio.c
+++ b/lib/librte_eal/bsdapp/nic_uio/nic_uio.c
@@ -109,6 +109,8 @@ struct pci_bdf {
 #define RTE_PCI_DEV_ID_DECL_IGBVF(vend, dev)   {vend, dev},
 #define RTE_PCI_DEV_ID_DECL_IXGBE(vend, dev)   {vend, dev},
 #define RTE_PCI_DEV_ID_DECL_IXGBEVF(vend, dev) {vend, dev},
+#define RTE_PCI_DEV_ID_DECL_I40E(vend, dev){vend, dev},
+#define RTE_PCI_DEV_ID_DECL_I40EVF(vend, dev)  {vend, dev},
 #define RTE_PCI_DEV_ID_DECL_VIRTIO(vend, dev)  {vend, dev},

 const struct device devices[] = {
-- 
2.0.0

[dpdk-dev] DPDK with Ubuntu 14.04?

[Wiles, Roger Keith]

The one problem I had with 14.04 was the kcompat.h file. It looks like a hash 
routine has changed its arguments. I edited the kcompat.h file and was about to 
change the code to allow DPDK to build. It is not affix but it worked for me.

lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h

/*  Changed the next line to use (3,13,8) instead of (3,14,0) KeithW */
#if ( LINUX_VERSION_CODE < KERNEL_VERSION(3,13,8) )
#if (!(RHEL_RELEASE_CODE && RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(7,0)))
#ifdef NETIF_F_RXHASH
#define PKT_HASH_TYPE_L3 0

Hope that works.

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

[Powering 30 Years of Innovation]

On Jul 10, 2014, at 5:56 PM, Matt Laswell mailto:laswell at infiniteio.com>> wrote:

Hey Folks,

I know that official support hasn't moved past Ubuntu 12.04 LTS yet, but
does anybody have any practical experience running with 14.04 LTS?  My team
has run into one compilation error so far with 1.7, but other than that
things look OK at first blush.  I'd like to move my product to 14.04 for a
variety of reasons, but would hate to spend time chasing down subtle
incompatibilities.  I'm guessing we're not the first ones to try this...

Thanks.

--
Matt Laswell
infinite io