[dpdk-dev] [PATCH] ixgbe: fix wrong packet type for VxLAN & NVGRE

[Thomas Monjalon]

2016-04-08 16:10, Wenzhuo Lu:
> VxLAN & NVGRE are supported by x550. As we know HW can parse
> the packet and tell SW the type info. For VxLAN & NVGRE packets
> there's some change. HW will not tell SW the info of the outer
> header but the inner header instead. But we always take the
> info as it's for the outer header. So the packet type info is
> not right when x550 receives VxLAN & NVGRE packets.
> 
> As x550 only supports IPv4 VxLAN & NVGRE packets, we can tell
> the outer header of VxLAN is IPv4 + UDP, and the outer header
> of NVGRE is IPv4 only. What we don't know is if there's
> optional field in the outer IPv4 header.
> 
> This patch implement the support of packet type for VxLAN &
> NVGRE. And it fixes the wrong packet type issue either.
> 
> BTW:
> It doesn't fix any existing commit as although it resolve an
> issue it's more like a new feature but not a fix.
> 
> Reported-by: Konstantin Ananyev 
> Signed-off-by: Wenzhuo Lu 

Applied, thanks

[dpdk-dev] [PATCH] performance-thread: limit app compilation to x86_64 targets

[Thomas Monjalon]

2016-04-08 17:20, Pablo de Lara:
> Performance-thread sample app is only supported for x86_64 targets,
> so this commit adds a check to avoid compilation on other targets.
> 
> Signed-off-by: Pablo de Lara 

Applied, thanks

[dpdk-dev] [PATCH] ipsec-secgw: fix anonymous union initialization

[Thomas Monjalon]

> In icc 14.0, compilation was broken:
> 
> examples/ipsec-secgw/sa.c(212): error: a designator for an anonymous
> union member can only appear within braces corresponding to that anonymous 
> union
> .cipher = { RTE_CRYPTO_CIPHER_OP_ENCRYPT, RTE_CRYPTO_CIPHER_AES_CBC,
>  ^
> 
> The member in anonymous union initialization should be inside '{}',
> otherwise it will report an error.
> 
> Fixes: d299106e8e31 (examples/ipsec-secgw: add IPsec sample application)
> 
> Signed-off-by: Pablo de Lara 

Applied, thanks

[dpdk-dev] [PATCH v2 1/1] examples/ip_pipeline: fix wrong size of argument

[Thomas Monjalon]

> CID 120150:
> Wrong size of the allocated memory. Passing argument as size of pointer
> (8UL) instead of size of structure app_pipeline_firewall_rule.
> 
> Fixes: 67ebdbef0c31 ("examples/ip_pipeline: add bulk update of firewall 
> rules")
> 
> Signed-off-by: Marcin Kerlin 

Applied, thanks

[dpdk-dev] Reg: promiscuous mode on VF

[Rose, Gregory V]

Bharath,

Please try the following:

In this example we are directing the traffic to queue 1 of VF ID 5.  First you 
must turn on ntuple.

$ ethtool ?K p5p2 ntuple on

Then you can set the FD rule:

$ ethtool ?N p5p2 flow-type udp4 dst-port 4790 action 1 user-def 5

When I do that this is the rule definition result:

Filter: 2045
Rule Type: UDP over IPv4
Src IP addr: 0.0.0.0 mask: 255.255.255.255
Dest IP addr: 0.0.0.0 mask: 255.255.255.255
TOS: 0x0 mask: 0xff
Src port: 0 mask: 0x
Dest port: 4790 mask: 0x0
VLAN EtherType: 0x0 mask: 0x
VLAN: 0x0 mask: 0x
User-defined: 0x5 mask: 0xff00
Action: Direct to queue 1

Be sure to use a version of ethtool 3.0 or greater and a recent kernel ? I 
tested on ethtool version 3.15 with a 3.18.4 Linux kernel from kernel.org and 
using the most recent ixgbe driver release.

Let me know if this works for you.

Thanks,

- Greg

From: Rose, Gregory V
Sent: Thursday, April 7, 2016 4:43 PM
To: bharath paulraj ; Qiu, Michael 
Cc: Zhang, Helin ; Lu, Wenzhuo ; Rowden, Aaron F ; dev at dpdk.org; 
Jayakumar, Muthurajan 
Subject: RE: [dpdk-dev] Reg: promiscuous mode on VF

Bharath,

I?m sorry for the delay but I am working on a response to this.  There is a way 
to do what you need to do and I will get together some instructions and respond 
by tomorrow.

Thanks and regards,

- Greg

From: bharath paulraj [mailto:bharathp...@gmail.com]
Sent: Thursday, April 7, 2016 3:40 AM
To: Qiu, Michael mailto:michael.qiu at intel.com>>
Cc: Rose, Gregory V mailto:gregory.v.rose at 
intel.com>>; Zhang, Helin mailto:helin.zhang at 
intel.com>>; Lu, Wenzhuo mailto:wenzhuo.lu at 
intel.com>>; Rowden, Aaron F mailto:aaron.f.rowden 
at intel.com>>; dev at dpdk.org; Jayakumar, Muthurajan 
mailto:muthurajan.jayakumar at intel.com>>
Subject: Re: [dpdk-dev] Reg: promiscuous mode on VF

Hi Team,

May I have some update on my previous mail? I am here stuck in flow creation.

Thanks,
Bharath

On Thu, Mar 31, 2016 at 4:13 PM, bharath paulraj mailto:bharathpaul at gmail.com>> wrote:
Hi Michael and All,

 I am unable to set the rule to receive the packet on the VF.
Below is my setup.

1. Creating one virtual function with one queue, in one of my port, p2p1.
modprobe ixgbe MQ=1 max_vfs=1 RSS=1 allow_unsupported_sfp=1
2. Below is the interface status after creating one virtual function.
[root at  sriov]# ifconfig p2p1
p2p1  Link encap:Ethernet  HWaddr A0:36:9F:86:C2:74
  inet6 addr: fe80::a236:9fff:fe86:c274/64 Scope:Link
  UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500 Metric:1
  RX packets:2540 errors:0 dropped:0 overruns:0 frame:0
  TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:157456 (153.7 KiB)  TX bytes:258 (258.0 b)

[root at  sriov]# ifconfig p2p1_0
p2p1_0Link encap:Ethernet  HWaddr DA:61:95:CD:AF:35
  inet6 addr: fe80::d861:95ff:fecd:af35/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:12 errors:0 dropped:0 overruns:0 frame:0
  TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:360 (360.0 b)  TX bytes:740 (740.0 b)
3. Next I am enable ntuple
ethtool -K p2p1  ntuple on
4. Now I am adding below rule
ethtool -N p2p1   flow-type udp4 dst-port 4789 action 0x1 --> VF 0, 
queue 0
ethtool -N p2p1   flow-type udp4 dst-port 4790 action 0x0 --> PF queue 0
5. [root at XXX sriov]# ethtool -n p2p1
1 RX rings available
Total 2 rules

Filter: 2044
Rule Type: UDP over IPv4
Src IP addr: 0.0.0.0 mask: 255.255.255.255
Dest IP addr: 0.0.0.0 mask: 255.255.255.255
TOS: 0x0 mask: 0xff
Src port: 0 mask: 0x
Dest port: 4790 mask: 0x0
VLAN EtherType: 0x0 mask: 0x
VLAN: 0x0 mask: 0x
User-defined: 0x0 mask: 0x
Action: Direct to queue 0

Filter: 2045
Rule Type: UDP over IPv4
Src IP addr: 0.0.0.0 mask: 255.255.255.255
Dest IP addr: 0.0.0.0 mask: 255.255.255.255
TOS: 0x0 mask: 0xff
Src port: 0 mask: 0x
Dest port: 4789 mask: 0x0
VLAN EtherType: 0x0 mask: 0x
VLAN: 0x0 mask: 0x
User-defined: 0x0 mask: 0x
Action: Direct to queue 0
>> Won't it show the VF queue numbers here?

6. Start the VM over p2p1_0
7. Below is the Packet I am sending
a) Dest MAC - VF Mac, Src MAC - any untagged, src ip - 1.1.1.1 dest ip - 
2.2.2.2 src port - 100 dest port - 4789
b) Dest MAC - VF Mac, Src MAC - any, untagged, src ip - 1.1.1.1 dest ip - 
2.2.2.2 src port - 100 dest port - 4790
c) Dest MAC - VF Mac, untagged, src ip - 1.1.1.1 dest ip - 2.2.2.2 src port - 
100 dest port - 4791

All the above testing is done on centOs-6.7 with ixgbe version - 4.3.13 with 

[dpdk-dev] [PATCH 1/2] docs: add cryptodevs guide overview section

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Declan Doherty
> Sent: Friday, April 8, 2016 5:17 PM
> To: dev at dpdk.org
> Cc: Doherty, Declan 
> Subject: [dpdk-dev] [PATCH 1/2] docs: add cryptodevs guide overview
> section
> 
> Details supported device features and algorithms for each crypto PMD.
> 
> Signed-off-by: Declan Doherty 


Acked-by: John McNamara 

[dpdk-dev] [PATCH v2] doc: fill nics features matrix for pcap

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ferruh Yigit
> Sent: Friday, April 8, 2016 5:39 PM
> To: dev at dpdk.org
> Cc: Yigit, Ferruh 
> Subject: [dpdk-dev] [PATCH v2] doc: fill nics features matrix for pcap
> 
> Signed-off-by: Ferruh Yigit 

Acked-by: John McNamara 

[dpdk-dev] [PATCH] ip_pipeline: fix build error for 32 bit gcc target

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jasvinder Singh
> Sent: Friday, April 8, 2016 6:13 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] ip_pipeline: fix build error for 32 bit gcc
> target
> 
> error log:
> ip_pipeline/pipeline/pipeline_routing_be.c:1537: integer constant is too
> large for 'long' type compilation terminated due to -Wfatal-errors
> 
> Fixes: 0ae7275810f1 ("examples/ip_pipeline: add more functions to routing
> pipeline")
> 
> Signed-off-by: Jasvinder Singh 

Acked-by: John McNamara 

[dpdk-dev] [PATCH] maintainers: claim responsibility for pcap PMD

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ferruh Yigit
> Sent: Friday, April 8, 2016 6:03 PM
> To: dev at dpdk.org
> Cc: Yigit, Ferruh 
> Subject: [dpdk-dev] [PATCH] maintainers: claim responsibility for pcap PMD
> 
> Signed-off-by: Ferruh Yigit 

Acked-by: John McNamara 

[dpdk-dev] [PATCH 2/2] docs: cryptodev chapter for programmer's guide

[De Lara Guarch, Pablo]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Declan Doherty
> Sent: Friday, April 08, 2016 5:17 PM
> To: dev at dpdk.org
> Cc: Doherty, Declan
> Subject: [dpdk-dev] [PATCH 2/2] docs: cryptodev chapter for programmer's
> guide
> 
> Add a programmer's guide section for cryptodev library.
> 
> Signed-off-by: Declan Doherty 
> ---
>  doc/guides/prog_guide/cryptodev_lib.rst  | 584
> +++
>  doc/guides/prog_guide/img/crypto_op.svg  |  75 +++
>  doc/guides/prog_guide/img/crypto_xform_chain.svg | 145 ++
>  doc/guides/prog_guide/img/cryptodev_sym_sess.svg |  66 +++
>  doc/guides/prog_guide/index.rst  |   1 +
>  5 files changed, 871 insertions(+)
>  create mode 100644 doc/guides/prog_guide/cryptodev_lib.rst
>  create mode 100644 doc/guides/prog_guide/img/crypto_op.svg
>  create mode 100644 doc/guides/prog_guide/img/crypto_xform_chain.svg
>  create mode 100644 doc/guides/prog_guide/img/cryptodev_sym_sess.svg
> 
> diff --git a/doc/guides/prog_guide/cryptodev_lib.rst
> b/doc/guides/prog_guide/cryptodev_lib.rst
> new file mode 100644
> index 000..6396d02
> --- /dev/null
> +++ b/doc/guides/prog_guide/cryptodev_lib.rst


...

> +
> +
> +Crypto Device API
> +~~~
> +
> +The cryptodev Library API is described in the *DPDK API Reference*
> document.
> +
> +

These two blank lines are not necessary.

Apart from that,
Acked-by: Pablo de Lara 

[dpdk-dev] [PATCH 1/2] docs: add cryptodevs guide overview section

[De Lara Guarch, Pablo]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Declan Doherty
> Sent: Friday, April 08, 2016 5:17 PM
> To: dev at dpdk.org
> Cc: Doherty, Declan
> Subject: [dpdk-dev] [PATCH 1/2] docs: add cryptodevs guide overview section
> 
> Details supported device features and algorithms for each crypto PMD.
> 
> Signed-off-by: Declan Doherty 

Acked-by: Pablo de Lara 

[dpdk-dev] [PATCH] maintainers: claim responsibility for pcap PMD

[Ferruh Yigit]

Signed-off-by: Ferruh Yigit 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index a7570cd..f213500 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -353,7 +353,7 @@ F: drivers/net/vhost/

 PCAP PMD
 M: Nicol?s Pernas Maradei 
-M: John McNamara 
+M: Ferruh Yigit 
 F: drivers/net/pcap/
 F: doc/guides/nics/pcap_ring.rst

-- 
2.5.5

[dpdk-dev] [PATCH] ipsec-secgw: fix anonymous union initialization

[Pablo de Lara]

In icc 14.0, compilation was broken:

examples/ipsec-secgw/sa.c(212): error: a designator for an anonymous
union member can only appear within braces corresponding to that anonymous union
.cipher = { RTE_CRYPTO_CIPHER_OP_ENCRYPT, RTE_CRYPTO_CIPHER_AES_CBC,
 ^

The member in anonymous union initialization should be inside '{}',
otherwise it will report an error.

Fixes: d299106e8e31 (examples/ipsec-secgw: add IPsec sample application)

Signed-off-by: Pablo de Lara 
---
 examples/ipsec-secgw/sa.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
index a5b8a63..b6260ed 100644
--- a/examples/ipsec-secgw/sa.c
+++ b/examples/ipsec-secgw/sa.c
@@ -209,15 +209,17 @@ static uint8_t cipher_key[256] = "sixteenbytes key";
 const struct rte_crypto_sym_xform aescbc_enc_xf = {
NULL,
RTE_CRYPTO_SYM_XFORM_CIPHER,
-   .cipher = { RTE_CRYPTO_CIPHER_OP_ENCRYPT, RTE_CRYPTO_CIPHER_AES_CBC,
+   {.cipher = { RTE_CRYPTO_CIPHER_OP_ENCRYPT, RTE_CRYPTO_CIPHER_AES_CBC,
.key = { cipher_key, 16 } }
+   }
 };

 const struct rte_crypto_sym_xform aescbc_dec_xf = {
NULL,
RTE_CRYPTO_SYM_XFORM_CIPHER,
-   .cipher = { RTE_CRYPTO_CIPHER_OP_DECRYPT, RTE_CRYPTO_CIPHER_AES_CBC,
+   {.cipher = { RTE_CRYPTO_CIPHER_OP_DECRYPT, RTE_CRYPTO_CIPHER_AES_CBC,
.key = { cipher_key, 16 } }
+   }
 };

 static uint8_t auth_key[256] = "twentybytes hash key";
@@ -226,28 +228,32 @@ static uint8_t auth_key[256] = "twentybytes hash key";
 const struct rte_crypto_sym_xform sha1hmac_gen_xf = {
NULL,
RTE_CRYPTO_SYM_XFORM_AUTH,
-   .auth = { RTE_CRYPTO_AUTH_OP_GENERATE, RTE_CRYPTO_AUTH_SHA1_HMAC,
+   {.auth = { RTE_CRYPTO_AUTH_OP_GENERATE, RTE_CRYPTO_AUTH_SHA1_HMAC,
.key = { auth_key, 20 }, 12, 0 }
+   }
 };

 const struct rte_crypto_sym_xform sha1hmac_verify_xf = {
NULL,
RTE_CRYPTO_SYM_XFORM_AUTH,
-   .auth = { RTE_CRYPTO_AUTH_OP_VERIFY, RTE_CRYPTO_AUTH_SHA1_HMAC,
+   {.auth = { RTE_CRYPTO_AUTH_OP_VERIFY, RTE_CRYPTO_AUTH_SHA1_HMAC,
.key = { auth_key, 20 }, 12, 0 }
+   }
 };

 /* AES CBC xform */
 const struct rte_crypto_sym_xform null_cipher_xf = {
NULL,
RTE_CRYPTO_SYM_XFORM_CIPHER,
-   .cipher = { .algo = RTE_CRYPTO_CIPHER_NULL }
+   {.cipher = { .algo = RTE_CRYPTO_CIPHER_NULL }
+   }
 };

 const struct rte_crypto_sym_xform null_auth_xf = {
NULL,
RTE_CRYPTO_SYM_XFORM_AUTH,
-   .auth = { .algo = RTE_CRYPTO_AUTH_NULL }
+   {.auth = { .algo = RTE_CRYPTO_AUTH_NULL }
+   }
 };

 struct sa_ctx {
-- 
2.5.5

[dpdk-dev] [PATCH] ip_pipeline: fix build error for 32 bit gcc target

[De Lara Guarch, Pablo]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jasvinder Singh
> Sent: Friday, April 08, 2016 6:13 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] ip_pipeline: fix build error for 32 bit gcc target
> 
> error log:
> ip_pipeline/pipeline/pipeline_routing_be.c:1537: integer constant is
> too large for 'long' type compilation terminated due to -Wfatal-errors
> 
> Fixes: 0ae7275810f1 ("examples/ip_pipeline: add more functions to routing
> pipeline")
> 
> Signed-off-by: Jasvinder Singh 

Acked-by:Pablo de Lara 

[dpdk-dev] [PATCH] doc: announce API changes for device objects

[Thomas Monjalon]

2016-04-08 11:35, Olivier Matz:
> On 04/07/2016 07:27 PM, Jan Viktorin wrote:
> > On Thu,  7 Apr 2016 17:33:17 +0200
> > David Marchand  wrote:
> > 
> >> Following discussions with Jan, here is a deprecation notice to prepare for
> >> hotplug and rte_device changes to come in 16.07.
> >>
> >> Signed-off-by: David Marchand 
> >> ---
> > Acked-by: Jan Viktorin 
> 
> Acked-by: Olivier Matz 

Acked-by: Thomas Monjalon 

[dpdk-dev] [PATCH v2] doc: fill nics features matrix for pcap

[Ferruh Yigit]

Signed-off-by: Ferruh Yigit 
---
 doc/guides/nics/overview.rst | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/doc/guides/nics/overview.rst b/doc/guides/nics/overview.rst
index 985fa58..ed116e3 100644
--- a/doc/guides/nics/overview.rst
+++ b/doc/guides/nics/overview.rst
@@ -93,7 +93,7 @@ Most of these differences are summarized below.
Rx interrupt   X X X X X X X X X X X X X X X
queue start/stop X   X X X X X X X X X X X X X X
   X   X X
MTU update   X X X   X   X X X X X X
-   jumbo frame  X X X X X X X X X   X X X X X X X X X X
+   jumbo frame  X X X X X X X X X   X X X X X X X X X X   X
scattered Rx X X X   X X X X X X X X X X X X X X X X
   X   X
LRO  X X X X
TSO  X   X   X X X X X X X X X X X X X X
@@ -127,23 +127,23 @@ Most of these differences are summarized below.
inner L4 checksumX   X   X   X   X   X
packet type parsing  X X X   X   X X X   X   X X X X X X
timesync X X X   X X
-   basic statsX X   X X X X X X X X X X X X X X X X X X X X
   X X X X
+   basic statsX X   X X X X X X X X X X X X X X X X X X X X   
X   X X X X
extended stats   X   X X X X X X X X X X X X X X
   X X
stats per queue  X   X X X X X X X X
   X   X X
EEPROM dump  X   X X
registers dump   X X X X X X
-   multiprocess aware   X X X X X X X X X X X X X X
+   multiprocess aware   X X X X X X X X X X X X X X   X
BSD nic_uio  X X   X X X X X X X X X X X X X X X
   X X
Linux UIO  X X   X X X X X X X X X X X X X X X X X X
   X X
Linux VFIO   X X   X X X X X X X X X X X X X X X
   X X
other kdrv   X X
   X
-   ARMv7   
   X X
-   ARMv8   
   X X
-   Power8   X X
-   TILE-Gx
-   x86-32   X X X X X X X X X X X X X X X X X X X X
 X X X
-   x86-64 X X   X X X X X X X X X X X X X X X X X X X X
   X X X X
-   usage doc  X X   X X X X
   X   X
+   ARMv7  
X   X X
+   ARMv8  
X   X X
+   Power8   X X   X
+   TILE-GxX
+   x86-32   X X X X X X X X X X X X X X X X X X X X   
X X X X
+   x86-64 X X   X X X X X X X X X X X X X X X X X X X X   
X   X X X X
+   usage doc  X X   X X X X   
X   X   X
design doc
perf doc
 = = = = = = = = = = = = = = = = = = = = = = = = = = = 
= = = = = = = =
-- 
2.5.5

[dpdk-dev] [PATCH] doc: fill nics features matrix for pcap

[Ferruh Yigit]

On 4/8/2016 5:23 PM, Ferruh Yigit wrote:
> ---
>  doc/guides/nics/overview.rst | 20 ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)

Self Nack, forget to add sign-off, sending again.

[dpdk-dev] [PATCH] doc: fill nics features matrix for pcap

[Ferruh Yigit]

---
 doc/guides/nics/overview.rst | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/doc/guides/nics/overview.rst b/doc/guides/nics/overview.rst
index 985fa58..ed116e3 100644
--- a/doc/guides/nics/overview.rst
+++ b/doc/guides/nics/overview.rst
@@ -93,7 +93,7 @@ Most of these differences are summarized below.
Rx interrupt   X X X X X X X X X X X X X X X
queue start/stop X   X X X X X X X X X X X X X X
   X   X X
MTU update   X X X   X   X X X X X X
-   jumbo frame  X X X X X X X X X   X X X X X X X X X X
+   jumbo frame  X X X X X X X X X   X X X X X X X X X X   X
scattered Rx X X X   X X X X X X X X X X X X X X X X
   X   X
LRO  X X X X
TSO  X   X   X X X X X X X X X X X X X X
@@ -127,23 +127,23 @@ Most of these differences are summarized below.
inner L4 checksumX   X   X   X   X   X
packet type parsing  X X X   X   X X X   X   X X X X X X
timesync X X X   X X
-   basic statsX X   X X X X X X X X X X X X X X X X X X X X
   X X X X
+   basic statsX X   X X X X X X X X X X X X X X X X X X X X   
X   X X X X
extended stats   X   X X X X X X X X X X X X X X
   X X
stats per queue  X   X X X X X X X X
   X   X X
EEPROM dump  X   X X
registers dump   X X X X X X
-   multiprocess aware   X X X X X X X X X X X X X X
+   multiprocess aware   X X X X X X X X X X X X X X   X
BSD nic_uio  X X   X X X X X X X X X X X X X X X
   X X
Linux UIO  X X   X X X X X X X X X X X X X X X X X X
   X X
Linux VFIO   X X   X X X X X X X X X X X X X X X
   X X
other kdrv   X X
   X
-   ARMv7   
   X X
-   ARMv8   
   X X
-   Power8   X X
-   TILE-Gx
-   x86-32   X X X X X X X X X X X X X X X X X X X X
 X X X
-   x86-64 X X   X X X X X X X X X X X X X X X X X X X X
   X X X X
-   usage doc  X X   X X X X
   X   X
+   ARMv7  
X   X X
+   ARMv8  
X   X X
+   Power8   X X   X
+   TILE-GxX
+   x86-32   X X X X X X X X X X X X X X X X X X X X   
X X X X
+   x86-64 X X   X X X X X X X X X X X X X X X X X X X X   
X   X X X X
+   usage doc  X X   X X X X   
X   X   X
design doc
perf doc
 = = = = = = = = = = = = = = = = = = = = = = = = = = = 
= = = = = = = =
-- 
2.5.5

[dpdk-dev] [PATCH] performance-thread: limit app compilation to x86_64 targets

[Pablo de Lara]

Performance-thread sample app is only supported for x86_64 targets,
so this commit adds a check to avoid compilation on other targets.

Signed-off-by: Pablo de Lara 
---
 examples/performance-thread/Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/examples/performance-thread/Makefile 
b/examples/performance-thread/Makefile
index 6278c9a..d2eec83 100644
--- a/examples/performance-thread/Makefile
+++ b/examples/performance-thread/Makefile
@@ -38,6 +38,9 @@ RTE_TARGET ?= x86_64-native-linuxapp-gcc

 include $(RTE_SDK)/mk/rte.vars.mk

+ifneq ($(CONFIG_RTE_ARCH),"x86_64")
+$(error This application is only supported for x86_64 targets)
+endif
 DIRS-y += l3fwd-thread
 DIRS-y += pthread_shim

-- 
2.5.5

[dpdk-dev] [PATCH 2/2] docs: cryptodev chapter for programmer's guide

[Declan Doherty]

Add a programmer's guide section for cryptodev library.

Signed-off-by: Declan Doherty 
---
 doc/guides/prog_guide/cryptodev_lib.rst  | 584 +++
 doc/guides/prog_guide/img/crypto_op.svg  |  75 +++
 doc/guides/prog_guide/img/crypto_xform_chain.svg | 145 ++
 doc/guides/prog_guide/img/cryptodev_sym_sess.svg |  66 +++
 doc/guides/prog_guide/index.rst  |   1 +
 5 files changed, 871 insertions(+)
 create mode 100644 doc/guides/prog_guide/cryptodev_lib.rst
 create mode 100644 doc/guides/prog_guide/img/crypto_op.svg
 create mode 100644 doc/guides/prog_guide/img/crypto_xform_chain.svg
 create mode 100644 doc/guides/prog_guide/img/cryptodev_sym_sess.svg

diff --git a/doc/guides/prog_guide/cryptodev_lib.rst 
b/doc/guides/prog_guide/cryptodev_lib.rst
new file mode 100644
index 000..6396d02
--- /dev/null
+++ b/doc/guides/prog_guide/cryptodev_lib.rst
@@ -0,0 +1,584 @@
+..  BSD LICENSE
+Copyright(c) 2016 Intel Corporation. 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
+the documentation and/or other materials provided with the
+distribution.
+* Neither the name of Intel Corporation nor the names of its
+contributors may be used to endorse or promote products derived
+from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+
+Cryptography Device Library
+=
+
+The cryptodev library provides a Crypto device framework for management and
+provisioning of hardware and software Crypto poll mode drivers, defining 
generic
+APIs which support a number of different Crypto operations. The framework
+currently only supports cipher, authentication, chained cipher/authentication
+and AEAD symmetric Crypto operations.
+
+
+Design Principles
+-
+
+The cryptodev library follows the same basic principles as those used in DPDKs
+Ethernet Device framework. The Crypto framework provides a generic Crypto 
device
+framework which supports both physical (hardware) and virtual (software) Crypto
+devices as well as a generic Crypto API which allows Crypto devices to be
+managed and configured and supports Crypto operations to be provisioned on
+Crypto poll mode driver.
+
+
+Device Management
+-
+
+Device Creation
+~~~
+
+Physical Crypto devices are discovered during the PCI probe/enumeration of the
+EAL function which is executed at DPDK initialization, based on
+their PCI device identifier, each unique PCI BDF (bus/bridge, device,
+function). Specific physical Crypto devices, like other physical devices in 
DPDK
+can be white-listed or black-listed using the EAL command line options.
+
+Virtual devices can be created by two mechanisms, either using the EAL command
+line options or from within the application using an EAL API directly.
+
+From the command line using the --vdev EAL option
+
+.. code-block:: console
+
+   --vdev  
'cryptodev_aesni_mb_pmd0,max_nb_queue_pairs=2,max_nb_sessions=1024,socket_id=0'
+
+Our using the rte_eal_vdev_init API within the application code.
+
+.. code-block:: c
+
+   rte_eal_vdev_init("cryptodev_aesni_mb_pmd",
+   
"max_nb_queue_pairs=2,max_nb_sessions=1024,socket_id=0")
+
+All virtual Crypto devices support the following initialization parameters:
+
+* max_nb_queue_pairs - maximum number of queue pairs supported by the device.
+* max_nb_sessions - maximum number of sessions supported by the device
+* socket_id - socket on which to allocate the device resources on.
+
+
+Device Identification
+~
+
+Each device, whether virtual or physical is uniquely designated by two
+identifiers:
+
+- A unique device index used to designate the Crypto device in all functions
+  exported by the cryptodev API.

[dpdk-dev] [PATCH 1/2] docs: add cryptodevs guide overview section

[Declan Doherty]

Details supported device features and algorithms for each crypto PMD.

Signed-off-by: Declan Doherty 
---
 doc/guides/cryptodevs/index.rst|  3 +-
 doc/guides/cryptodevs/overview.rst | 94 ++
 2 files changed, 96 insertions(+), 1 deletion(-)
 create mode 100644 doc/guides/cryptodevs/overview.rst

diff --git a/doc/guides/cryptodevs/index.rst b/doc/guides/cryptodevs/index.rst
index 85193da..a3f11f3 100644
--- a/doc/guides/cryptodevs/index.rst
+++ b/doc/guides/cryptodevs/index.rst
@@ -35,8 +35,9 @@ Crypto Device Drivers
 :maxdepth: 2
 :numbered:

+overview
 aesni_mb
 aesni_gcm
 null
 snow3g
-qat
+qat
\ No newline at end of file
diff --git a/doc/guides/cryptodevs/overview.rst 
b/doc/guides/cryptodevs/overview.rst
new file mode 100644
index 000..9f9af43
--- /dev/null
+++ b/doc/guides/cryptodevs/overview.rst
@@ -0,0 +1,94 @@
+..  BSD LICENSE
+Copyright(c) 2016 Intel Corporation. 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
+the documentation and/or other materials provided with the
+distribution.
+* Neither the name of Intel Corporation nor the names of its
+contributors may be used to endorse or promote products derived
+from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+Crypto Device Supported Functionality Matrices
+--
+
+Supported Feature Flags
+
+.. csv-table::
+   :header: "Feature Flags", "qat", "null", "aesni_mb", "aesni_gcm", "snow3g"
+   :stub-columns: 1
+
+   "RTE_CRYPTODEV_FF_SYMMETRIC_CRYPTO",x,x,,,
+   "RTE_CRYPTODEV_FF_ASYMMETRIC_CRYPTO",
+   "RTE_CRYPTODEV_FF_SYM_OPERATION_CHAINING",x,x,x,x,x
+   "RTE_CRYPTODEV_FF_CPU_SSE",,,x,x,x
+   "RTE_CRYPTODEV_FF_CPU_AVX",,,x,x,x
+   "RTE_CRYPTODEV_FF_CPU_AVX2",,,x,x,
+   "RTE_CRYPTODEV_FF_CPU_AESNI",,,x,x,
+   "RTE_CRYPTODEV_FF_HW_ACCELERATED",x
+
+Supported Cipher Algorithms
+
+.. csv-table::
+   :header: "Cipher Algorithms", "qat", "null", "aesni_mb", "aesni_gcm", 
"snow3g"
+   :stub-columns: 1
+
+   "NULL",,x,,,
+   "AES_CBC_128",x,,x,,
+   "AES_CBC_192",x,,x,,
+   "AES_CBC_256",x,,x,,
+   "AES_CTR_128",
+   "AES_CTR_192",
+   "AES_CTR_256",
+   "SNOW3G_UEA2",xx
+
+Supported Authentication Algorithms
+
+.. csv-table::
+   :header: "Cipher Algorithms", "qat", "null", "aesni_mb", "aesni_gcm", 
"snow3g"
+   :stub-columns: 1
+
+   "NONE",,x,,,
+   "MD5",
+   "MD5_HMAC",,,x,,
+   "SHA1",
+   "SHA1_HMAC",x,,x,,
+   "SHA224",
+   "SHA224_HMAC",,,x,,
+   "SHA256",
+   "SHA256_HMAC",x,,x,,
+   "SHA384",
+   "SHA384_HMAC",,,x,,
+   "SHA512",
+   "SHA512_HMAC",x,,x,,
+   "AES_XCBC",x,,x,,
+   "SNOW3G_UIA2",xx
+
+
+Supported AEAD Algorithms
+
+.. csv-table::
+   :header: "AEAD Algorithms", "qat", "null", "aesni_mb", "aesni_gcm", "snow3g"
+   :stub-columns: 1
+
+   "AES_GCM_128",x,,x,,
+   "AES_GCM_192",x
+   "AES_GCM_256",x
-- 
2.5.5

[dpdk-dev] [PATCH 0/2] cryptodev documentation patches

[Declan Doherty]

Add an overview section to the cryptodev guide which outlines each PMD supported
algorithms.

Add new chapter to the DPDK user guide for the cryptodev library

Declan Doherty (2):
  docs: add cryptodevs guide overview section
  docs: cryptodev chapter for programmer's guide

 doc/guides/cryptodevs/index.rst  |   3 +-
 doc/guides/cryptodevs/overview.rst   |  94 
 doc/guides/prog_guide/cryptodev_lib.rst  | 584 +++
 doc/guides/prog_guide/img/crypto_op.svg  |  75 +++
 doc/guides/prog_guide/img/crypto_xform_chain.svg | 145 ++
 doc/guides/prog_guide/img/cryptodev_sym_sess.svg |  66 +++
 doc/guides/prog_guide/index.rst  |   1 +
 7 files changed, 967 insertions(+), 1 deletion(-)
 create mode 100644 doc/guides/cryptodevs/overview.rst
 create mode 100644 doc/guides/prog_guide/cryptodev_lib.rst
 create mode 100644 doc/guides/prog_guide/img/crypto_op.svg
 create mode 100644 doc/guides/prog_guide/img/crypto_xform_chain.svg
 create mode 100644 doc/guides/prog_guide/img/cryptodev_sym_sess.svg

-- 
2.5.5

[dpdk-dev] [PATCH] docs: cryptodev chapter for programmer's guide

[Declan Doherty]

On 08/04/16 17:02, Declan Doherty wrote:
> Signed-off-by: Declan Doherty 
> ---
...
 >

Self Nack, I'm forgot to include the first patch of the patchset. Will 
resend.

Declan

[dpdk-dev] [PATCH] docs: cryptodev chapter for programmer's guide

[Declan Doherty]

Signed-off-by: Declan Doherty 
---
 doc/guides/cryptodevs/index.rst  |   3 +-
 doc/guides/cryptodevs/overview.rst   |  94 
 doc/guides/prog_guide/cryptodev_lib.rst  | 569 +--
 doc/guides/prog_guide/img/crypto_op.svg  |  75 +++
 doc/guides/prog_guide/img/crypto_xform_chain.svg | 145 ++
 doc/guides/prog_guide/img/cryptodev_sym_sess.svg |  66 +++
 6 files changed, 798 insertions(+), 154 deletions(-)
 create mode 100644 doc/guides/cryptodevs/overview.rst
 create mode 100644 doc/guides/prog_guide/img/crypto_op.svg
 create mode 100644 doc/guides/prog_guide/img/crypto_xform_chain.svg
 create mode 100644 doc/guides/prog_guide/img/cryptodev_sym_sess.svg

diff --git a/doc/guides/cryptodevs/index.rst b/doc/guides/cryptodevs/index.rst
index 85193da..a3f11f3 100644
--- a/doc/guides/cryptodevs/index.rst
+++ b/doc/guides/cryptodevs/index.rst
@@ -35,8 +35,9 @@ Crypto Device Drivers
 :maxdepth: 2
 :numbered:

+overview
 aesni_mb
 aesni_gcm
 null
 snow3g
-qat
+qat
\ No newline at end of file
diff --git a/doc/guides/cryptodevs/overview.rst 
b/doc/guides/cryptodevs/overview.rst
new file mode 100644
index 000..9f9af43
--- /dev/null
+++ b/doc/guides/cryptodevs/overview.rst
@@ -0,0 +1,94 @@
+..  BSD LICENSE
+Copyright(c) 2016 Intel Corporation. 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
+the documentation and/or other materials provided with the
+distribution.
+* Neither the name of Intel Corporation nor the names of its
+contributors may be used to endorse or promote products derived
+from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+Crypto Device Supported Functionality Matrices
+--
+
+Supported Feature Flags
+
+.. csv-table::
+   :header: "Feature Flags", "qat", "null", "aesni_mb", "aesni_gcm", "snow3g"
+   :stub-columns: 1
+
+   "RTE_CRYPTODEV_FF_SYMMETRIC_CRYPTO",x,x,,,
+   "RTE_CRYPTODEV_FF_ASYMMETRIC_CRYPTO",
+   "RTE_CRYPTODEV_FF_SYM_OPERATION_CHAINING",x,x,x,x,x
+   "RTE_CRYPTODEV_FF_CPU_SSE",,,x,x,x
+   "RTE_CRYPTODEV_FF_CPU_AVX",,,x,x,x
+   "RTE_CRYPTODEV_FF_CPU_AVX2",,,x,x,
+   "RTE_CRYPTODEV_FF_CPU_AESNI",,,x,x,
+   "RTE_CRYPTODEV_FF_HW_ACCELERATED",x
+
+Supported Cipher Algorithms
+
+.. csv-table::
+   :header: "Cipher Algorithms", "qat", "null", "aesni_mb", "aesni_gcm", 
"snow3g"
+   :stub-columns: 1
+
+   "NULL",,x,,,
+   "AES_CBC_128",x,,x,,
+   "AES_CBC_192",x,,x,,
+   "AES_CBC_256",x,,x,,
+   "AES_CTR_128",
+   "AES_CTR_192",
+   "AES_CTR_256",
+   "SNOW3G_UEA2",xx
+
+Supported Authentication Algorithms
+
+.. csv-table::
+   :header: "Cipher Algorithms", "qat", "null", "aesni_mb", "aesni_gcm", 
"snow3g"
+   :stub-columns: 1
+
+   "NONE",,x,,,
+   "MD5",
+   "MD5_HMAC",,,x,,
+   "SHA1",
+   "SHA1_HMAC",x,,x,,
+   "SHA224",
+   "SHA224_HMAC",,,x,,
+   "SHA256",
+   "SHA256_HMAC",x,,x,,
+   "SHA384",
+   "SHA384_HMAC",,,x,,
+   "SHA512",
+   "SHA512_HMAC",x,,x,,
+   "AES_XCBC",x,,x,,
+   "SNOW3G_UIA2",xx
+
+
+Supported AEAD Algorithms
+
+.. csv-table::
+   :header: "AEAD Algorithms", "qat", "null", "aesni_mb", "aesni_gcm", "snow3g"
+   :stub-columns: 1
+
+   "AES_GCM_128",x,,x,,
+   "AES_GCM_192",x
+   "AES_GCM_256",x
diff --git a/doc/guides/prog_guide/cryptodev_lib.rst 
b/doc/guides/prog_guide/cryptodev_lib.rst
index 638a02c..6396d02 100644
--- a/doc/guides/prog_guide/cryptodev_lib.rst
+++ b/doc/guides/prog_guide/cryptodev_lib.rst
@@ -31,291 +31,554 @@
 Cryptography Device Library
 =

-The cryptodev library provides a crypto device framework for management and 
-provisioning of hardware and virtual crypto poll mode drivers, 

[dpdk-dev] [PATCH v1] doc:add tested platforms and nics

[Qian Xu]

add a new file about tested platforms and nics in doc/guides/nics
Signed-off-by: Qian Xu 

diff --git a/doc/guides/nics/index.rst b/doc/guides/nics/index.rst
index 769f677..d34040b 100644
--- a/doc/guides/nics/index.rst
+++ b/doc/guides/nics/index.rst
@@ -36,6 +36,7 @@ Network Interface Controller Drivers
 :numbered:

 overview
+test_platforms
 bnx2x
 cxgbe
 e1000em
diff --git a/doc/guides/nics/test_platforms.rst 
b/doc/guides/nics/test_platforms.rst
new file mode 100644
index 000..00a4fd5
--- /dev/null
+++ b/doc/guides/nics/test_platforms.rst
@@ -0,0 +1,151 @@
+..  BSD LICENSE
+Copyright(c) 2016 Intel Corporation. All rights reserved.
+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
+the documentation and/or other materials provided with the
+distribution.
+* Neither the name of Intel Corporation nor the names of its
+contributors may be used to endorse or promote products derived
+from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+Tested Platforms and Nics
+=
+
+Tested Platforms
+
+
+Platform#1: SuperMicro 1U
+
+- BIOS: 1.0c
+- Processor: Intel(R) Atom(TM) CPU  C2758  @ 2.40GHz
+
+Platform#2: SuperMicro 1U
+
+- BIOS: 1.0a
+- Processor: Intel(R) Xeon(R) CPU D-1540 @ 2.00GHz
+- Onboard NIC: Intel(R) X552/X557-AT(2x10G) 
+  - firmware-version: 0x81cf; 
+  - device ID(PF/VF): 8086:15ad /8086:15a8; 
+  - kernel driver version: 4.2.5(ixgbe)
+
+Platform#3: SuperMicro 1U
+
+- BIOS: 1.0a
+- Processor: Intel(R) Xeon(R) CPU E5-4667 v3 @ 2.00GHz
+
+Platform#4: Intel(R) Server board S2600GZ
+
+- BIOS: SE5C600.86B.02.02.0002.122320131210
+- Processor: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
+
+Platform#5: Intel(R) Server board W2600CR
+
+- BIOS: SE5C600.86B.02.01.0002.082220131453
+- Processor: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
+
+Platform#6: Intel(R) Server board S2600CWT
+
+- BIOS: SE5C610.86B.01.01.0009.060120151350
+- Processor: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz
+
+Platform#7: Intel? Server board S2600WTT
+
+- BIOS: SE5C610.86B.01.01.0005.101720141054
+- Processor: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz
+
+Platform#8: Intel? Server board S2600WTT   
+
+- BIOS: SE5C610.86B.11.01.0044.090120151156
+- Processor: Intel(R) Xeon(R) CPU E5-2695 v4 @ 2.10GHz
+
+Tested NICs
+---
+
+NIC#1: Intel? Ethernet Controller X540-AT2
+
+- firmware version: 0x8389
+- device id(pf): 8086:1528
+- driver version: 3.23.2 (ixgbe)
+
+NIC#2: Intel? 82599ES 10 Gigabit Ethernet Controller
+
+- firmware version: 0x61bf0001
+- device id(pf/vf): 8086:10fb / 8086:10ed
+- driver version: 4.0.1-k (ixgbe)
+
+NIC#3: Intel Corporation Ethernet Connection X552/X557-AT 10GBASE-T
+
+- firmware version: 0x81cf
+- device id(pf/vf): 8086:15ad / 8086:15a8
+- driver version: 4.2.5(ixgbe)
+
+NIC#4: Intel? Ethernet Converged Network Adapter X710-DA4(4x10G) 
+
+- firmware version: 5.02 0x80002284
+- device id(pf/vf): 8086:1572 / 8086:154c
+- driver version: 1.4.26(i40e)
+
+NIC#4: Intel? Ethernet Converged Network Adapter X710-DA2(2x10G)
+
+- firmware version: 5.02 0x80002282
+- device id(pf/vf): 8086:1572 / 8086:154c
+- driver version: 1.4.25(i40e)
+   
+NIC#5: Intel? Ethernet Converged Network Adapter XL710-QDA1(1x40G)
+
+- firmware version: 5.02 0x80002281
+- device id(pf/vf): 8086:1584 / 8086:154c
+- driver version: 1.4.25(i40e)
+
+NIC#6: Intel? Ethernet Converged Network Adapter XL710-QDA2(2X40G)
+
+- firmware version: 5.02 0x80002285
+- device id(pf/vf): 8086:1583 / 8086:154c
+- driver version: 1.4.25(i40e)
+
+NIC#7: Intel? 82576EB Gigabit Ethernet Controller
+
+- firmware version: 1.2.1
+- device id(pf): 8086:1526
+- driver version: 5.2.13-k (igb)
+
+NIC#8: Intel? Ethernet 

[dpdk-dev] [PATCH v1] doc:add tested platforms and nics

[Thomas Monjalon]

2016-04-08 14:29, Xu, Qian Q:
> Agreed, and others can add their NICs info into the tested NICs and 
> platforms. One question about the release version, the NICs and platforms may 
> change with the release version, for example, for each release, the 
> information may be different, so we need mention the release version for the 
> tested nics and platforms. Then how about putting them in one session of 
> release notes? 

Please do at your convenience but do it quickly.
Thanks


> -Original Message-
> From: Mcnamara, John 
> Sent: Friday, April 08, 2016 6:05 PM
> To: Thomas Monjalon; Xu, Qian Q
> Cc: dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v1] doc:add tested platforms and nics
> 
> > -Original Message-
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > Sent: Friday, April 8, 2016 10:06 AM
> > To: Xu, Qian Q 
> > Cc: dev at dpdk.org; Mcnamara, John 
> > Subject: Re: [dpdk-dev] [PATCH v1] doc:add tested platforms and nics
> > 
> > >  overview
> > > +test_platforms
> > 
> > I think it would be better suited to integrate this information in the 
> > existing pages for e1000, ixgbe, i40e and fm10k.
> 
> Hi,
> 
> I think that this is better in one section where it can be reviewed together. 
> I think it should be the last chapter in the section though.
> 
> John.
> 

[dpdk-dev] [PATCH v2] doc: add section on tested platforms and nics

[John McNamara]

Add a new section on tested platforms and nics to the release notes.

Signed-off-by: Qian Xu 
Signed-off-by: John McNamara 
---

V2: 
 - Moved text to release notes.
 - Made mailing list changes.

 doc/guides/rel_notes/release_16_04.rst | 120 +
 1 file changed, 120 insertions(+)

diff --git a/doc/guides/rel_notes/release_16_04.rst 
b/doc/guides/rel_notes/release_16_04.rst
index 200053c..09036c1 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -533,3 +533,123 @@ The libraries prepended with a plus sign were incremented 
in this version.
  librte_table.so.2
  librte_timer.so.1
  librte_vhost.so.2
+
+
+Tested Platforms
+
+
+#. SuperMicro 1U
+
+   - BIOS: 1.0c
+   - Processor: Intel(R) Atom(TM) CPU C2758 @ 2.40GHz
+
+#. SuperMicro 1U
+
+   - BIOS: 1.0a
+   - Processor: Intel(R) Xeon(R) CPU D-1540 @ 2.00GHz
+   - Onboard NIC: Intel(R) X552/X557-AT (2x10G)
+
+ - Firmware-version: 0x81cf
+ - Device ID (PF/VF): 8086:15ad /8086:15a8
+
+   - kernel driver version: 4.2.5 (ixgbe)
+
+#. SuperMicro 1U
+
+   - BIOS: 1.0a
+   - Processor: Intel(R) Xeon(R) CPU E5-4667 v3 @ 2.00GHz
+
+#. Intel(R) Server board S2600GZ
+
+   - BIOS: SE5C600.86B.02.02.0002.122320131210
+   - Processor: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
+
+#. Intel(R) Server board W2600CR
+
+   - BIOS: SE5C600.86B.02.01.0002.082220131453
+   - Processor: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
+
+#. Intel(R) Server board S2600CWT
+
+   - BIOS: SE5C610.86B.01.01.0009.060120151350
+   - Processor: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz
+
+#. Intel(R) Server board S2600WTT
+
+   - BIOS: SE5C610.86B.01.01.0005.101720141054
+   - Processor: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz
+
+#. Intel(R) Server board S2600WTT
+
+   - BIOS: SE5C610.86B.11.01.0044.090120151156
+   - Processor: Intel(R) Xeon(R) CPU E5-2695 v4 @ 2.10GHz
+
+Tested NICs
+---
+
+#. Intel(R) Ethernet Controller X540-AT2
+
+   - Firmware version: 0x8389
+   - Device id (pf): 8086:1528
+   - Driver version: 3.23.2 (ixgbe)
+
+#. Intel(R) 82599ES 10 Gigabit Ethernet Controller
+
+   - Firmware version: 0x61bf0001
+   - Device id (pf/vf): 8086:10fb / 8086:10ed
+   - Driver version: 4.0.1-k (ixgbe)
+
+#. Intel(R) Corporation Ethernet Connection X552/X557-AT 10GBASE-T
+
+   - Firmware version: 0x81cf
+   - Device id (pf/vf): 8086:15ad / 8086:15a8
+   - Driver version: 4.2.5 (ixgbe)
+
+#. Intel(R) Ethernet Converged Network Adapter X710-DA4 (4x10G)
+
+   - Firmware version: 5.02 0x80002284
+   - Device id (pf/vf): 8086:1572 / 8086:154c
+   - Driver version: 1.4.26 (i40e)
+
+#. Intel(R) Ethernet Converged Network Adapter X710-DA2 (2x10G)
+
+   - Firmware version: 5.02 0x80002282
+   - Device id (pf/vf): 8086:1572 / 8086:154c
+   - Driver version: 1.4.25 (i40e)
+
+#. Intel(R) Ethernet Converged Network Adapter XL710-QDA1 (1x40G)
+
+   - Firmware version: 5.02 0x80002281
+   - Device id (pf/vf): 8086:1584 / 8086:154c
+   - Driver version: 1.4.25 (i40e)
+
+#. Intel(R) Ethernet Converged Network Adapter XL710-QDA2 (2X40G)
+
+   - Firmware version: 5.02 0x80002285
+   - Device id (pf/vf): 8086:1583 / 8086:154c
+   - Driver version: 1.4.25 (i40e)
+
+#. Intel(R) 82576EB Gigabit Ethernet Controller
+
+   - Firmware version: 1.2.1
+   - Device id (pf): 8086:1526
+   - Driver version: 5.2.13-k (igb)
+
+#. Intel(R) Ethernet Controller I210
+
+   - Firmware version: 3.16, 0x8500, 1.304.0
+   - Device id (pf): 8086:1533
+   - Driver version: 5.2.13-k (igb)
+
+#. Intel(R) Corporation I350 Gigabit Network Connection
+
+   - Firmware version: 1.48, 0x86e7
+   - Device id (pf/vf): 8086:1521 / 8086:1520
+   - Driver version: 5.2.13-k (igb)
+
+
+#. Intel(R) Ethernet Multi-host Controller FM1
+
+   - Firmware version: N/A
+   - Device id (pf/vf): 8086:15d0
+   - Driver version: 0.17.0.9 (fm10k)
-- 
2.5.0

[dpdk-dev] [PATCH] ixgbe: fix wrong packet type for VxLAN & NVGRE

[Wenzhuo Lu]

VxLAN & NVGRE are supported by x550. As we know HW can parse
the packet and tell SW the type info. For VxLAN & NVGRE packets
there's some change. HW will not tell SW the info of the outer
header but the inner header instead. But we always take the
info as it's for the outer header. So the packet type info is
not right when x550 receives VxLAN & NVGRE packets.

As x550 only supports IPv4 VxLAN & NVGRE packets, we can tell
the outer header of VxLAN is IPv4 + UDP, and the outer header
of NVGRE is IPv4 only. What we don't know is if there's
optional field in the outer IPv4 header.

This patch implement the support of packet type for VxLAN &
NVGRE. And it fixes the wrong packet type issue either.

BTW:
It doesn't fix any existing commit as although it resolve an
issue it's more like a new feature but not a fix.

Reported-by: Konstantin Ananyev 
Signed-off-by: Wenzhuo Lu 
---
 drivers/net/ixgbe/ixgbe_rxtx.c | 269 +
 drivers/net/ixgbe/ixgbe_rxtx.h |   6 +
 2 files changed, 252 insertions(+), 23 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
index 89c0eb9..a93af55 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
@@ -938,14 +938,59 @@ end_of_tx:
 #define IXGBE_PACKET_TYPE_IPV4_IPV6_EXT 0X0D
 #define IXGBE_PACKET_TYPE_IPV4_IPV6_EXT_TCP 0X1D
 #define IXGBE_PACKET_TYPE_IPV4_IPV6_EXT_UDP 0X2D
+
+#define IXGBE_PACKET_TYPE_NVGRE   0X00
+#define IXGBE_PACKET_TYPE_NVGRE_IPV4  0X01
+#define IXGBE_PACKET_TYPE_NVGRE_IPV4_TCP  0X11
+#define IXGBE_PACKET_TYPE_NVGRE_IPV4_UDP  0X21
+#define IXGBE_PACKET_TYPE_NVGRE_IPV4_SCTP 0X41
+#define IXGBE_PACKET_TYPE_NVGRE_IPV4_EXT  0X03
+#define IXGBE_PACKET_TYPE_NVGRE_IPV4_EXT_SCTP 0X43
+#define IXGBE_PACKET_TYPE_NVGRE_IPV6  0X04
+#define IXGBE_PACKET_TYPE_NVGRE_IPV6_TCP  0X14
+#define IXGBE_PACKET_TYPE_NVGRE_IPV6_UDP  0X24
+#define IXGBE_PACKET_TYPE_NVGRE_IPV6_EXT  0X0C
+#define IXGBE_PACKET_TYPE_NVGRE_IPV6_EXT_TCP  0X1C
+#define IXGBE_PACKET_TYPE_NVGRE_IPV6_EXT_UDP  0X2C
+#define IXGBE_PACKET_TYPE_NVGRE_IPV4_IPV6 0X05
+#define IXGBE_PACKET_TYPE_NVGRE_IPV4_IPV6_TCP 0X15
+#define IXGBE_PACKET_TYPE_NVGRE_IPV4_IPV6_UDP 0X25
+#define IXGBE_PACKET_TYPE_NVGRE_IPV4_IPV6_EXT 0X0D
+#define IXGBE_PACKET_TYPE_NVGRE_IPV4_IPV6_EXT_TCP 0X1D
+#define IXGBE_PACKET_TYPE_NVGRE_IPV4_IPV6_EXT_UDP 0X2D
+
+#define IXGBE_PACKET_TYPE_VXLAN   0X80
+#define IXGBE_PACKET_TYPE_VXLAN_IPV4  0X81
+#define IXGBE_PACKET_TYPE_VXLAN_IPV4_TCP  0x91
+#define IXGBE_PACKET_TYPE_VXLAN_IPV4_UDP  0xA1
+#define IXGBE_PACKET_TYPE_VXLAN_IPV4_SCTP 0xC1
+#define IXGBE_PACKET_TYPE_VXLAN_IPV4_EXT  0x83
+#define IXGBE_PACKET_TYPE_VXLAN_IPV4_EXT_SCTP 0XC3
+#define IXGBE_PACKET_TYPE_VXLAN_IPV6  0X84
+#define IXGBE_PACKET_TYPE_VXLAN_IPV6_TCP  0X94
+#define IXGBE_PACKET_TYPE_VXLAN_IPV6_UDP  0XA4
+#define IXGBE_PACKET_TYPE_VXLAN_IPV6_EXT  0X8C
+#define IXGBE_PACKET_TYPE_VXLAN_IPV6_EXT_TCP  0X9C
+#define IXGBE_PACKET_TYPE_VXLAN_IPV6_EXT_UDP  0XAC
+#define IXGBE_PACKET_TYPE_VXLAN_IPV4_IPV6 0X85
+#define IXGBE_PACKET_TYPE_VXLAN_IPV4_IPV6_TCP 0X95
+#define IXGBE_PACKET_TYPE_VXLAN_IPV4_IPV6_UDP 0XA5
+#define IXGBE_PACKET_TYPE_VXLAN_IPV4_IPV6_EXT 0X8D
+#define IXGBE_PACKET_TYPE_VXLAN_IPV4_IPV6_EXT_TCP 0X9D
+#define IXGBE_PACKET_TYPE_VXLAN_IPV4_IPV6_EXT_UDP 0XAD
+
 #define IXGBE_PACKET_TYPE_MAX   0X80
-#define IXGBE_PACKET_TYPE_MASK  0X7F
+#define IXGBE_PACKET_TYPE_TN_MAX0X100
 #define IXGBE_PACKET_TYPE_SHIFT 0X04

 /* @note: fix ixgbe_dev_supported_ptypes_get() if any change here. */
 static inline uint32_t
-ixgbe_rxd_pkt_info_to_pkt_type(uint16_t pkt_info)
+ixgbe_rxd_pkt_info_to_pkt_type(uint32_t pkt_info, uint16_t ptype_mask)
 {
+   /**
+* Use 2 different table for normal packet and tunnel packet
+* to save the space.
+*/
static const uint32_t
ptype_table[IXGBE_PACKET_TYPE_MAX] __rte_cache_aligned = {
[IXGBE_PACKET_TYPE_IPV4] = RTE_PTYPE_L2_ETHER |
@@ -991,11 +1036,172 @@ ixgbe_rxd_pkt_info_to_pkt_type(uint16_t pkt_info)
[IXGBE_PACKET_TYPE_IPV4_EXT_SCTP] = RTE_PTYPE_L2_ETHER |
RTE_PTYPE_L3_IPV4_EXT | RTE_PTYPE_L4_SCTP,
};
+
+   static const uint32_t
+   ptype_table_tn[IXGBE_PACKET_TYPE_TN_MAX] __rte_cache_aligned = {
+   [IXGBE_PACKET_TYPE_NVGRE] = RTE_PTYPE_L2_ETHER |
+   RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_TUNNEL_GRE |
+   RTE_PTYPE_INNER_L2_ETHER,
+   [IXGBE_PACKET_TYPE_NVGRE_IPV4] = RTE_PTYPE_L2_ETHER |
+   RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_TUNNEL_GRE |
+   

[dpdk-dev] [PATCH] vhost: call rte_vhost_enable_guest_notification only on enabled queues

[Tetsuya Mukawa]

On 2016/04/08 15:14, Yuanhan Liu wrote:
> On Fri, Apr 08, 2016 at 10:45:33AM +0900, Tetsuya Mukawa wrote:
>> On 2016/04/08 2:20, Thomas Monjalon wrote:
> If the vhost PMD were configured with more queues than the guest, the old
> code would segfault in rte_vhost_enable_guest_notification due to a NULL
> virtqueue pointer.
>
> Fixes: ee584e9710b9 ("vhost: add driver on top of the library")
> Signed-off-by: Rich Lane 
 Acked-by: Yuanhan Liu 
>>> Applied, thanks
>> Hi Rich and Yuanhan,
>>
>> I am sorry for late reply. I was out of office yesterday.
> Tetsuya, no worry! Man takes leaves, and isn't the reason we have 2 or
> more maintainers on some blocks? :)
>
>   --yliu

Yeah, thanks!

Tetsuya

[dpdk-dev] [PATCH v2 1/1] examples/ip_pipeline: fix wrong size of argument

[Marcin Kerlin]

v2:
added fixline

CID 120150:
Wrong size of the allocated memory. Passing argument as size of pointer
(8UL) instead of size of structure app_pipeline_firewall_rule.

Fixes: 67ebdbef0c31 ("examples/ip_pipeline: add bulk update of firewall rules")

Signed-off-by: Marcin Kerlin 
---
 examples/ip_pipeline/pipeline/pipeline_firewall.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/examples/ip_pipeline/pipeline/pipeline_firewall.c 
b/examples/ip_pipeline/pipeline/pipeline_firewall.c
index 320b25d..fd897d5 100644
--- a/examples/ip_pipeline/pipeline/pipeline_firewall.c
+++ b/examples/ip_pipeline/pipeline/pipeline_firewall.c
@@ -834,7 +834,7 @@ app_pipeline_firewall_add_bulk(struct app_params *app,
rules[i] = app_pipeline_firewall_rule_find(p, [i]);
new_rules[i] = (rules[i] == NULL);
if (rules[i] == NULL) {
-   rules[i] = rte_malloc(NULL, sizeof(rules[i]),
+   rules[i] = rte_malloc(NULL, sizeof(*rules[i]),
RTE_CACHE_LINE_SIZE);

if (rules[i] == NULL) {
-- 
1.9.1

[dpdk-dev] [PATCH] doc: announce ABI changes for user-owned mempool caches

[Hunt, David]

On 4/5/2016 4:42 PM, Olivier Matz wrote:
> On 04/05/2016 11:23 AM, Lazaros Koromilas wrote:
>> Deprecation notice for 16.04 for changes targeting release 16.07.
>> The changes affect struct rte_mempool, rte_mempool_cache and the
>> mempool API.
>>
>> Signed-off-by: Lazaros Koromilas 
> Acked-by: Olivier Matz 
>

Acked-by: David Hunt

[dpdk-dev] [examples/ip_pipeline: fix wrong size of argument 1/1]

[Marcin Kerlin]

CID 120150:
Wrong size of the allocated memory. Passing argument as size of pointer
(8UL) instead of size of structure app_pipeline_firewall_rule.


Signed-off-by: Marcin Kerlin 
---
 examples/ip_pipeline/pipeline/pipeline_firewall.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/examples/ip_pipeline/pipeline/pipeline_firewall.c 
b/examples/ip_pipeline/pipeline/pipeline_firewall.c
index 320b25d..fd897d5 100644
--- a/examples/ip_pipeline/pipeline/pipeline_firewall.c
+++ b/examples/ip_pipeline/pipeline/pipeline_firewall.c
@@ -834,7 +834,7 @@ app_pipeline_firewall_add_bulk(struct app_params *app,
rules[i] = app_pipeline_firewall_rule_find(p, [i]);
new_rules[i] = (rules[i] == NULL);
if (rules[i] == NULL) {
-   rules[i] = rte_malloc(NULL, sizeof(rules[i]),
+   rules[i] = rte_malloc(NULL, sizeof(*rules[i]),
RTE_CACHE_LINE_SIZE);

if (rules[i] == NULL) {
-- 
1.9.1

[dpdk-dev] [PATCH v1] doc:add tested platforms and nics

[Xu, Qian Q]

Agreed, and others can add their NICs info into the tested NICs and platforms. 
One question about the release version, the NICs and platforms may change with 
the release version, for example, for each release, the information may be 
different, so we need mention the release version for the tested nics and 
platforms. Then how about putting them in one session of release notes? 

Thanks
Qian


-Original Message-
From: Mcnamara, John 
Sent: Friday, April 08, 2016 6:05 PM
To: Thomas Monjalon; Xu, Qian Q
Cc: dev at dpdk.org
Subject: RE: [dpdk-dev] [PATCH v1] doc:add tested platforms and nics

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Friday, April 8, 2016 10:06 AM
> To: Xu, Qian Q 
> Cc: dev at dpdk.org; Mcnamara, John 
> Subject: Re: [dpdk-dev] [PATCH v1] doc:add tested platforms and nics
> 
> >  overview
> > +test_platforms
> 
> I think it would be better suited to integrate this information in the 
> existing pages for e1000, ixgbe, i40e and fm10k.

Hi,

I think that this is better in one section where it can be reviewed together. I 
think it should be the last chapter in the section though.

John.
-- 

[dpdk-dev] [PATCH] vhost: call rte_vhost_enable_guest_notification only on enabled queues

[Yuanhan Liu]

On Fri, Apr 08, 2016 at 10:45:33AM +0900, Tetsuya Mukawa wrote:
> On 2016/04/08 2:20, Thomas Monjalon wrote:
> >>> If the vhost PMD were configured with more queues than the guest, the old
> >>> code would segfault in rte_vhost_enable_guest_notification due to a NULL
> >>> virtqueue pointer.
> >>>
> >>> Fixes: ee584e9710b9 ("vhost: add driver on top of the library")
> >>> Signed-off-by: Rich Lane 
> >> Acked-by: Yuanhan Liu 
> > Applied, thanks
> 
> Hi Rich and Yuanhan,
> 
> I am sorry for late reply. I was out of office yesterday.

Tetsuya, no worry! Man takes leaves, and isn't the reason we have 2 or
more maintainers on some blocks? :)

--yliu

> I've tested it also today, and seems to be good.
> 
> Thanks,
> Tetsuya

[dpdk-dev] DPDK 2.2 issue with dpdk kni-virtio

[chintu hetam]

Hello All,

We are trying to test virtio-vhost-kni performance,

I able to start kni application but after that when i looked for
/sys/class/net/vEth0, there's no sock_fd and sock_en parameters, hence i am
stuck from attaching fd to virtio-qemu.

Host: Fedora 23
HugetblsFS: 1G pages

Following is my config.

[root at localhost dpdk-2.2.0]# ./tools/dpdk_nic_bind.py --status

Network devices using DPDK-compatible driver

:02:00.2 'I350 Gigabit Network Connection' drv=igb_uio unused=igb
:02:00.3 'I350 Gigabit Network Connection' drv=igb_uio unused=igb
:86:00.0 'Ethernet Controller 10-Gigabit X540-AT2' drv=igb_uio
unused=ixgbe
:86:00.1 'Ethernet Controller 10-Gigabit X540-AT2' drv=igb_uio
unused=ixgbe

Network devices using kernel driver
===
:02:00.0 'I350 Gigabit Network Connection' if=ens2f0 drv=igb
unused=igb_uio *Active*
:02:00.1 'I350 Gigabit Network Connection' if=ens2f1 drv=igb
unused=igb_uio
:89:00.0 'Ethernet Controller 10-Gigabit X540-AT2' if=enp137s0f0
drv=ixgbe unused=igb_uio
:89:00.1 'Ethernet Controller 10-Gigabit X540-AT2' if=enp137s0f1
drv=ixgbe unused=igb_uio

Other network devices
=



 examples/kni/build/app/kni -c 0xf -n 4 -- -p 0xc -P
--config="(2,0,1),(3,2,3)"
:
:
:
PP: Port ID: 3
APP: Rx lcore ID: 2, Tx lcore ID: 3
APP: Initialising port 2 ...
PMD: ixgbe_dev_rx_queue_setup(): sw_ring=0x7f1d3ffef6c0
sw_sc_ring=0x7f1d3ffef180 hw_ring=0x7f1d3ffefc00 dma_addr=0x533ffefc00
PMD: ixgbe_dev_tx_queue_setup(): sw_ring=0x7f1d3ffdcfc0
hw_ring=0x7f1d3ffdf000 dma_addr=0x533ffdf000
PMD: ixgbe_set_tx_function(): Using simple tx code path
PMD: ixgbe_set_tx_function(): Vector tx enabled.
PMD: ixgbe_set_rx_function(): Vector rx enabled, please make sure RX burst
size no less than 4 (port=2).
KNI: pci: 86:00:00   8086:1528
APP: Initialising port 3 ...
PMD: ixgbe_dev_rx_queue_setup(): sw_ring=0x7f1d3ffcc6c0
sw_sc_ring=0x7f1d3ffcc180 hw_ring=0x7f1d3ffccc00 dma_addr=0x533ffccc00
PMD: ixgbe_dev_tx_queue_setup(): sw_ring=0x7f1d3ffb9fc0
hw_ring=0x7f1d3ffbc000 dma_addr=0x533ffbc000
PMD: ixgbe_set_tx_function(): Using simple tx code path
PMD: ixgbe_set_tx_function(): Vector tx enabled.
PMD: ixgbe_set_rx_function(): Vector rx enabled, please make sure RX burst
size no less than 4 (port=3).
KNI: pci: 86:00:01   8086:1528

KNI: pci: 86:00:01   8086:1528

Checking link status
done
Port 2 Link Up - speed 100 Mbps - full-duplex
Port 3 Link Up - speed 100 Mbps - full-duplex
APP: Lcore 1 is writing to port 2
APP: Lcore 2 is reading from port 3
APP: Lcore 3 is writing to port 3
APP: Lcore 0 is reading from port 2

 ls /sys/class/net/vEth2/
addr_assign_type  broadcastdev_idduplex ifalias
 link_mode netdev_group  phys_port_name  proto_down  statistics
 type
address   carrier  dev_port  flags  ifindex
 mtu   operstate phys_switch_id  queues  subsystem
uevent
addr_len  carrier_changes  dormant   gro_flush_timeout  iflink
name_assign_type  phys_port_id  power   speed   tx_queue_len

As this is sysfs, it has to be in kmod, but i don't see any mention of
these two parameters, what's going on?

Any help on what causes this issue?


-thanks-

[dpdk-dev] [PATCH] doc: announce API changes for device objects

[Olivier Matz]

On 04/07/2016 07:27 PM, Jan Viktorin wrote:
> On Thu,  7 Apr 2016 17:33:17 +0200
> David Marchand  wrote:
> 
>> Following discussions with Jan, here is a deprecation notice to prepare for
>> hotplug and rte_device changes to come in 16.07.
>>
>> Signed-off-by: David Marchand 
>> ---
> Acked-by: Jan Viktorin 
> 

Acked-by: Olivier Matz 

[dpdk-dev] [PATCH] scripts: test build with all stats enabled

[Thomas Monjalon]

These stats will be compiled when adding +debug
to test-build.sh targets:
CONFIG_RTE_LIBRTE_IP_FRAG_TBL_STAT
CONFIG_RTE_SCHED_COLLECT_STATS
CONFIG_RTE_PORT_STATS_COLLECT
CONFIG_RTE_TABLE_STATS_COLLECT
CONFIG_RTE_PIPELINE_STATS_COLLECT
CONFIG_RTE_TEST_PMD_RECORD_BURST_STATS
CONFIG_RTE_TEST_PMD_RECORD_CORE_CYCLES

Signed-off-by: Thomas Monjalon 
---
 scripts/test-build.sh | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/scripts/test-build.sh b/scripts/test-build.sh
index e9e3dbc..9de90f7 100755
--- a/scripts/test-build.sh
+++ b/scripts/test-build.sh
@@ -137,8 +137,10 @@ config () #   
sed -ri   's,(NEXT_ABI=)y,\1n,' $1/.config
! echo $3 | grep -q '+shared' || \
sed -ri 's,(SHARED_LIB=)n,\1y,' $1/.config
-   ! echo $3 | grep -q '+debug' || \
-   sed -ri's,(DEBUG.*=)n,\1y,' $1/.config
+   ! echo $3 | grep -q '+debug' || ( \
+   sed -ri   's,(_DEBUG.*=)n,\1y,' $1/.config
+   sed -ri's,(_STAT.*=)n,\1y,' $1/.config
+   sed -ri 's,(TEST_PMD_RECORD_.*=)n,\1y,' $1/.config )

# Automatic configuration
! echo $2 | grep -q '^x86_64' || \
@@ -165,7 +167,6 @@ config () #   
sed -ri's,(PMD_QAT=)n,\1y,' $1/.config
sed -ri's,(KNI_VHOST.*=)n,\1y,' $1/.config
sed -ri   's,(SCHED_.*=)n,\1y,' $1/.config
-   sed -ri 's,(TEST_PMD_RECORD_.*=)n,\1y,' $1/.config
build_config_hook $1 $2 $3

# Explicit enabler/disabler (uppercase)
-- 
2.7.0

[dpdk-dev] [PATCH v1] doc:add tested platforms and nics

[Thomas Monjalon]

2016-04-08 16:57, Qian Xu:
> add a new file about tested platforms and nics in doc/guides/nics
> Signed-off-by: Qian Xu 
> 
> diff --git a/doc/guides/nics/index.rst b/doc/guides/nics/index.rst
> index 769f677..d34040b 100644
> --- a/doc/guides/nics/index.rst
> +++ b/doc/guides/nics/index.rst
> @@ -36,6 +36,7 @@ Network Interface Controller Drivers
>  :numbered:
>  
>  overview
> +test_platforms

I think it would be better suited to integrate this information
in the existing pages for e1000, ixgbe, i40e and fm10k.

[dpdk-dev] On DPDK ABI policy

[Marc Sune]

2016-04-07 13:51 GMT+02:00 Panu Matilainen :

> [ change of subject since this is about ABI policy, not namespacing ]
>
> On 04/07/2016 01:16 PM, Marc Sune wrote:
>
>>
>>
>> 2016-04-07 11:33 GMT+02:00 Panu Matilainen > >:
>>
>> On 04/07/2016 12:18 PM, Thomas Monjalon wrote:
>>
>> Thank you everyone for the feedbacks.
>>
>> 2016-04-05 15:56, Thomas Monjalon:
>>
>> The goal of this email is to get some feedback on how
>> important it is
>> to fix the DPDK namespace.
>>
>>
>> Everybody agree every symbols must be prefixed. Checking and
>> fixing the
>> namespace consistency will be in the roadmap.
>>
>> It seems most of you agree renaming would be a nice improvement
>> but not
>> so important.
>> The main drawback is the induced backporting pain, even if we have
>> some scripts to convert the patches to the old namespace.
>> Note: the backports can be in DPDK itself or in the applications.
>>
>> If there is enough agreement that we should do something, I
>> suggest to
>> introduce the "dpdk_" prefix slowly and live with both
>> "rte_" and "dpdk_"
>> during some time.
>> We could start using the new prefix for the new APIs
>> (example: crypto)
>> or when there is a significant API break (example: mempool).
>>
>>
>> The slow change has been clearly rejected in favor of a complete
>> change
>> in one patch.
>> The timing was also discussed as it could impact the pending
>> patches.
>> So it would be done at the end or the beginning of a release.
>> Marc suggests to do it for 16.04 as the numbering scheme has
>> changed.
>>
>>
>> Just noting that it cannot be done in 16.04 because the ABI policy
>> requires a deprecation cycle of at least one major release for every
>> breakage. And we're discussing a total 100% breakage of everything
>> here, even if its just a simple rename.
>>
>>
>> I keep not understanding the ABI policy, and particularly why ABI
>> changes have to be announced once cycle before _if_ there is already at
>> least one ABI change proposed. DPDK applications will have to recompile
>> anyway.
>>
>
> The point is to allow API/ABI consumers to assess in advance what sort of
> pains can they expect when moving their applications from one version to
> another. Otherwise all sorts of massive changes could ride the wave of
> whatever "change 16bit struct member to 32bit" trivialities that are
> nevertheless ABI breaks.
>
> There have already been quite a few exceptions to the rule when the ABI is
> already being broken, so its not entirely rigid. Another point that migth
> warrant some tweaking to the policy is the "core" libraries depending on
> each other so an ABI break in any one of them forces recompile of
> everything anyway.
>

In addition to what Matthew said:

I don't understand which sort of pains an announcement saying "we are going
to change this structure and this other, for those high level reasons, but
we don't know exactly how yet, because it is not fully implemented" can be
of any help to a DPDK user. At least it does not to me. This information
has to be in the release notes and users can read that before deciding to
upgrade to a new release.

On the other side, bug fixes still go to NEXT_VERSION. So in 1 ouf ot 2
cases (so far), next release is breaking ABI, so you will have to anyway
recompile your application.

And about ABI breakages; DPDK is not a standard library/library set. For
performance reasons it has a lot of inline code and other optimizations, so
even for small bug fixings can brake ABI, or to be precise, some bug fixes
in inline functions may be silently ignored. I don't know how many users
really use dynamic libraries for DPDK and if there is some warning
somewhere in the documentation for that.


> This aspect of the policy only slows down DPDK development and it
>>
>
> One could also think that slowing down development and forcing people to
> think ahead are not entirely unintentional or unwanted side-effects :)
>
> Look at the latest librte_vhost initiative to remove unnecessarily exposed
> structs to avoid having to deal with ABI breakages all the time: the policy
> is effectively encouraging people into better library design.
>
> pollutes the repository with commits announcing ABI changes that are
>> irrelevant after 2 cycles, as (code) diffs show that already (not
>> mentioning NEXT_ABI complexity and extra LOCs).
>>
>
> Fully agreed on NEXT_ABI, I never liked it at all.
>
> Maintaining LTS releases, and enforcing bug fixing in old LTS first,
>> upstreaming bugfixes is to me a much better approach to solve backwards
>> compatibility issues.
>>
>
> LTS releases could help the situation somewhat, but then again people tend
> to still 

[dpdk-dev] [PATCH] vhost: call rte_vhost_enable_guest_notification only on enabled queues

[Tetsuya Mukawa]

On 2016/04/08 2:20, Thomas Monjalon wrote:
>>> If the vhost PMD were configured with more queues than the guest, the old
>>> code would segfault in rte_vhost_enable_guest_notification due to a NULL
>>> virtqueue pointer.
>>>
>>> Fixes: ee584e9710b9 ("vhost: add driver on top of the library")
>>> Signed-off-by: Rich Lane 
>> Acked-by: Yuanhan Liu 
> Applied, thanks

Hi Rich and Yuanhan,

I am sorry for late reply. I was out of office yesterday.
I've tested it also today, and seems to be good.

Thanks,
Tetsuya

[dpdk-dev] On DPDK ABI policy

[Marc Sune]

2016-04-07 23:52 GMT+02:00 Matthew Hall :

> On Thu, Apr 07, 2016 at 02:51:35PM +0300, Panu Matilainen wrote:
> > LTS releases could help the situation somewhat, but then again
> > people tend to still want those new fancy things backported (you
> > know, have the cake and eat it too) but that can't be done because
> > of ABI breakage, so they're forced to run the latest version anyway.
>
> RH and Debian / Ubuntu don't put features in LTS except extremely rarely.
> Generally only if there's severe functionality breakage or security issues
> and
> the rest is ignored, and for good reason, as this is much more reliable and
> simple and predictable.
>
> If people are so irrational they can't deal with that simple of a policy,
> NEXT_ABI, LTS, etc. is never going to help them.
>
> If people like to have backported stuff, yes of course we can make trees
> and
> branches for this, they are basically free in Git. But at that point
> community
> people in need of LTS forks of features need to step up to the plate to
> help
> out.
>

Completely agree.

Marc


>
> Matthew.
>

[dpdk-dev] eal/tile arch broken on v16.04

[Thomas Monjalon]

2016-04-08 05:37, tom.barbette at ulg.ac.be:
> Hi,
> 
> I cannot build DPDK for tile-tilegx-linuxapp-gcc with any of the release 
> candidates for 16.04 :

I'm still waiting for a free toolchain working with DPDK here:
http://www.mellanox.com/repository/solutions/tile-scm/

> I also could never (cross)-compile without changing the following configure 
> options on v2.1 or v2.2, they cause intrinsic arch incompatibilities, so why 
> aren't they removed by default in the tile defconfig?
> CONFIG_RTE_LIBRTE_KNI=n
> CONFIG_RTE_KNI_KMOD=n
> CONFIG_RTE_LIBRTE_HASH=n
> CONFIG_RTE_LIBRTE_IP_FRAG=n 
> CONFIG_RTE_LIBRTE_CXGBE_PMD=n

A patch for the tile config would be integrated in 16.04.

[dpdk-dev] [PATCH v1] doc:add tested platforms and nics

[Mcnamara, John]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Friday, April 8, 2016 10:06 AM
> To: Xu, Qian Q 
> Cc: dev at dpdk.org; Mcnamara, John 
> Subject: Re: [dpdk-dev] [PATCH v1] doc:add tested platforms and nics
> 
> >  overview
> > +test_platforms
> 
> I think it would be better suited to integrate this information in the
> existing pages for e1000, ixgbe, i40e and fm10k.

Hi,

I think that this is better in one section where it can be reviewed together. I 
think it should be the last chapter in the section though.

John.
-- 

[dpdk-dev] [PATCH v1] doc:add tested platforms and nics

[Mcnamara, John]

Hi,

Thanks for that, some comments below.

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Qian Xu
> Sent: Friday, April 8, 2016 9:57 AM
> To: dev at dpdk.org
> Cc: Xu, Qian Q 
> Subject: [dpdk-dev] [PATCH v1] doc:add tested platforms and nics
> 
> add a new file about tested platforms and nics in doc/guides/nics
> Signed-off-by: Qian Xu 
> 
> diff --git a/doc/guides/nics/index.rst b/doc/guides/nics/index.rst index
> 769f677..d34040b 100644
> --- a/doc/guides/nics/index.rst
> +++ b/doc/guides/nics/index.rst
> @@ -36,6 +36,7 @@ Network Interface Controller Drivers
>  :numbered:
> 
>  overview
> +test_platforms
>  bnx2x
>  cxgbe
>  e1000em

I would suggest adding this as the last chapter in the NICs guide.



> +
> +Tested Platforms
> +
> +
> +Platform#1: SuperMicro 1U
> +

Instead of using "Platform#1" I would suggest omitting "Platform" and just use 
a simple numbered list using the RST directive "#." like this:

#. SuperMicro 1U



> +- BIOS: 1.0c
> +- Processor: Intel(R) Atom(TM) CPU  C2758  @ 2.40GHz

Some parts of the doc use (R) and (TM) and some use the symbols. I suggest 
using one or the other in all places.



> +
> +Platform#2: SuperMicro 1U
> +
> +- BIOS: 1.0a
> +- Processor: Intel(R) Xeon(R) CPU D-1540 @ 2.00GHz
> +- Onboard NIC: Intel(R) X552/X557-AT(2x10G)
> +  - firmware-version: 0x81cf;
> +  - device ID(PF/VF): 8086:15ad /8086:15a8;
> +  - kernel driver version: 4.2.5(ixgbe)

Apart from (R) and (TM) there should be a space between before all other 
parentheses, like this: 4.2.5 (ixgbe).

This is in several places in the docs.



> +Tested NICs
> +---
> +
> +NIC#1: Intel? Ethernet Controller X540-AT2

Same comment about using a numbered list as above.


Also, there are several checkpatch warnings about trailing whitespace and some 
tabs that should be fixed.

Thanks,

John

[dpdk-dev] [RFC] vhost user: add error handling for fd > 1023

[Xie, Huawei]

On 4/7/2016 10:52 PM, Christian Ehrhardt wrote:
> I totally agree to that there is no deterministic rule what to expect.
> The only rule is that #fd certainly always is > #vhost_user devices.
> In various setup variants I've crossed fd 1024 anywhere between 475
> and 970 vhost_user ports.
>
> Once the discussion continues and we have an updates version of the
> patch with some more agreement I hope I can help to test it.

Thanks. Let us first temporarily fix this problem for robustness, then
we consider whether upgrade to (e)poll.
Will check the patch in detail later. Basically it should work but need
check whether we need extra fixes elsewhere.

[dpdk-dev] eal/tile arch broken on v16.04

[tom.barbe...@ulg.ac.be]

Hi,

I cannot build DPDK for tile-tilegx-linuxapp-gcc with any of the release 
candidates for 16.04 :

--
(...)
  CC eal.o
In file included from 
/home/tom/dpdk-tile/lib/librte_eal/linuxapp/eal/eal.c:68:0:
/home/tom/dpdk-tile/tile-tilegx-linuxapp-gcc/include/rte_cycles.h:40:24: fatal 
error: arch/cycle.h: No such file or directory
 #include 
^
compilation terminated.
/home/tom/dpdk-tile/mk/internal/rte.compile-pre.mk:126: recipe for target 
'eal.o' failed
--

I also could never (cross)-compile without changing the following configure 
options on v2.1 or v2.2, they cause intrinsic arch incompatibilities, so why 
aren't they removed by default in the tile defconfig?
CONFIG_RTE_LIBRTE_KNI=n
CONFIG_RTE_KNI_KMOD=n
CONFIG_RTE_LIBRTE_HASH=n
CONFIG_RTE_LIBRTE_IP_FRAG=n 
CONFIG_RTE_LIBRTE_CXGBE_PMD=n

I imagine it'll stay true for 16.04...

Thanks,

Tom

[dpdk-dev] ethdev: replacement for rte_pci_dev_ids.h?

[Sean Hope (shope)]

>2016-04-07 18:10, Sean Hope:
>> Hello,
>> 
>> I see that rte_pci_dev_ids.h has been removed.
>
>No it has not been removed (yet):
>   
> http://dpdk.org/browse/dpdk/tree/lib/librte_eal/common/include/rte_pci_de
>v_ids.h
>
>> We are using it on our product to get supported device ids.
>> 
>> I understand the desire to move that data out of a central place and
>>into
>> each driver. Any chance that instead of living in a .c file, that each
>> driver could hold it in a .h file so that it could be easily consumed by
>> an external program?
>
>Yes there is a plan to move the PCI ids in the drivers but
>we need to make a tool to retrieve the ids from the ELF files.
>Why do you want to get them from a .h file?

The need for a .h file isn't an absolute, but we have some code that was
using the existing file. If each driver had their Ids in a per-driver .h
file then we just include one h file per driver instead of
rte_pci_dev_ids.h and our tool still works.

Thanks,
Sean

[dpdk-dev] [PATCH] ixgbe: checkpatch cleanups

[Lu, Wenzhuo]

Hi,


> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen Hemminger
> Sent: Friday, April 8, 2016 7:45 AM
> To: Zhang, Helin; Ananyev, Konstantin
> Cc: dev at dpdk.org; Stephen Hemminger
> Subject: [dpdk-dev] [PATCH] ixgbe: checkpatch cleanups
> 
> Run ixgbe driver through checkpatch and edit away all the
> nasty bits.  Fix line spacing, some bad indentation, and in a couple
> of cases use short circuit (already there) return to lessen indentation.
> 
> Signed-off-by: Stephen Hemminger 
Acked-by: Wenzhuo Lu 

[dpdk-dev] Port 0 Link Down - L2fwd sample application

[Lu, Wenzhuo]

Hi Vivek,


> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vivek Gupta
> Sent: Thursday, April 7, 2016 9:19 PM
> To: Marc Sune
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] Port 0 Link Down - L2fwd sample application
> 
> I have installed DPDK 2.2 version and didn?t build source coe.
The info is too limited, I cannot figure out what you're doing.
1, Confused, you didn't build the source code, so how you install DPDK?
2, Don't know the topology. Please make sure the connection is ready.
3, Would you like to try igb_uio? Normally we're using this one.

> 
> From: Marc Sune [mailto:marcdevel at gmail.com]
> Sent: Thursday, April 07, 2016 6:27 PM
> To: Vivek Gupta 
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] Port 0 Link Down - L2fwd sample application
> 
> 
> 
> 2016-04-07 14:50 GMT+02:00 Vivek Gupta mailto:vivek-
> g at hcl.com>>:
> Hi
> 
> I have binded eth0 and eth1 with DPDK and then tried to run the l2fwd example
> as below
> 
> ./build/l2fwd -c f -n 4 -- -q 8 -p 0x11  but each time I get error
> *
> Checking link status..
> Port 0 Link Down
> Port 1 Link Down
> 
> 
> I tried with test-pmd example but same result.Could you please help to up the
> link?
> 
> Port status is as below-
> Network devices using DPDK-compatible driver
> 
> :01:00.0 'Ethernet Controller 10-Gigabit X540-AT2' drv=uio_pci_generic
> unused=igb_uio
> :01:00.1 'Ethernet Controller 10-Gigabit X540-AT2' drv=uio_pci_generic
> unused=igb_uio
> :06:00.0 'Ethernet Controller 10-Gigabit X540-AT2' drv=uio_pci_generic
> unused=igb_uio
> :06:00.1 'Ethernet Controller 10-Gigabit X540-AT2' drv=uio_pci_generic
> unused=igb_uio
> 
> Network devices using kernel driver
> ===
> :81:00.0 'Ethernet Controller 10-Gigabit X540-AT2' if=eth4 drv=ixgbe
> unused=igb_uio,uio_pci_generic
> :81:00.1 'Ethernet Controller 10-Gigabit X540-AT2' if=eth5 drv=ixgbe
> unused=igb_uio,uio_pci_generic
> 
> Other network devices
> =
> 
> 
> 
> Thanks & Regards
> Vivek Gupta
> 
> In which commit or version are you?
> 
> Marc
> 
> 
> 
> ::DISCLAIMER::
> --
> --
> 
> The contents of this e-mail and any attachment(s) are confidential and 
> intended
> for the named recipient(s) only.
> E-mail transmission is not guaranteed to be secure or error-free as 
> information
> could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, 
> or
> may contain viruses in transmission. The e mail and its contents (with or 
> without
> referred errors) shall therefore not attach any liability on the originator 
> or HCL
> or its affiliates.
> Views or opinions, if any, presented in this email are solely those of the 
> author
> and may not necessarily reflect the views or opinions of HCL or its 
> affiliates. Any
> form of reproduction, dissemination, copying, disclosure, modification,
> distribution and / or publication of this message without the prior written
> consent of authorized representative of HCL is strictly prohibited. If you 
> have
> received this email in error please delete it and notify the sender 
> immediately.
> Before opening any email and/or attachments, please check them for viruses
> and other defects.
> 
> --
> --

[dpdk-dev] [dpdk-announce] release candidate 16.04-rc4

[Thomas Monjalon]

A new DPDK release candidate is ready for testing:
http://dpdk.org/browse/dpdk/tag/?id=v16.04-rc4

This is the last release candidate for 16.04.
Most of the changes are some bug fixes or doc updates.

The release will be closed as soon as every last details will be fixed.
Please check the documentation and the release notes.

If you plan to add a new feature in 16.07, it is the right time to
start talking and making some proposals.

Thank you

[dpdk-dev] [PATCH] vhost: call rte_vhost_enable_guest_notification only on enabled queues

[Tan, Jianfeng]

On 4/7/2016 11:29 PM, Loftus, Ciara wrote:
>> On 4/7/2016 8:29 AM, Rich Lane wrote:
>>> If the vhost PMD were configured with more queues than the guest, the
>> old
>>> code would segfault in rte_vhost_enable_guest_notification due to a NULL
>>> virtqueue pointer.
>>>
>>> Fixes: ee584e9710b9 ("vhost: add driver on top of the library")
>>> Signed-off-by: Rich Lane 
>>> ---
>>>drivers/net/vhost/rte_eth_vhost.c | 5 +++--
>>>1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/net/vhost/rte_eth_vhost.c
>> b/drivers/net/vhost/rte_eth_vhost.c
>>> index b1eb082..310cbef 100644
>>> --- a/drivers/net/vhost/rte_eth_vhost.c
>>> +++ b/drivers/net/vhost/rte_eth_vhost.c
>>> @@ -265,7 +265,6 @@ new_device(struct virtio_net *dev)
>>> vq->device = dev;
>>> vq->internal = internal;
>>> vq->port = eth_dev->data->port_id;
>>> -   rte_vhost_enable_guest_notification(dev, vq-
>>> virtqueue_id, 0);
>>> }
>>> for (i = 0; i < eth_dev->data->nb_tx_queues; i++) {
>>> vq = eth_dev->data->tx_queues[i];
>>> @@ -274,9 +273,11 @@ new_device(struct virtio_net *dev)
>>> vq->device = dev;
>>> vq->internal = internal;
>>> vq->port = eth_dev->data->port_id;
>>> -   rte_vhost_enable_guest_notification(dev, vq-
>>> virtqueue_id, 0);
>>> }
>>>
>>> +   for (i = 0; i < dev->virt_qp_nb * VIRTIO_QNUM; i++)
>>> +   rte_vhost_enable_guest_notification(dev, i, 0);
>>> +
>>> dev->flags |= VIRTIO_DEV_RUNNING;
>>> dev->priv = eth_dev;
>>> eth_dev->data->dev_link.link_status = ETH_LINK_UP;
>> Just one question, when qemu starts a vm, usually, only one queue is
>> enabled, then only 1 tx and 1 rx are called
>> rte_vhost_enable_guest_notification; but after system is up, we use
>> "ethtool -K eth0 combined x" to enable multiqueues, there's no chance to
>> call rte_vhost_enable_guest_notification for other queues, right?
> As far as I know, virt_qp_nb will report the number of queues available, 
> regardless of their state enabled/disabled. So for example if we have 4 
> queues, but only one enabled, virt_qp_nb should still = 4 and 
> rte_vhost_enable_guest_notification() will be called for all of these queues.

Oh, yes. I failed to really get multiqueue configured right, which leads 
to the wrong conclusion. Sorry.

Thanks,
Jianfeng

>
> Thanks,
> Ciara
>
>> Thanks,
>> Jianfeng

[dpdk-dev] DPDK namespace

[Thomas Monjalon]

2016-04-07 11:18, Thomas Monjalon:
> 2016-04-05 15:56, Thomas Monjalon:
> > The goal of this email is to get some feedback on how important it is
> > to fix the DPDK namespace.
> 
> Everybody agree every symbols must be prefixed. Checking and fixing the
> namespace consistency will be in the roadmap.
> 
> It seems most of you agree renaming would be a nice improvement but not
> so important.

The main benefits are:
- consistency with the name of the project
- avoid a namespace clash with another library using "rte" prefix
(the dpdk word is kind of reserved now)

> The main drawback is the induced backporting pain, even if we have
> some scripts to convert the patches to the old namespace.
> Note: the backports can be in DPDK itself or in the applications.
> 
> > If there is enough agreement that we should do something, I suggest to
> > introduce the "dpdk_" prefix slowly and live with both "rte_" and "dpdk_"
> > during some time.
> > We could start using the new prefix for the new APIs (example: crypto)
> > or when there is a significant API break (example: mempool).
> 
> The slow change has been clearly rejected in favor of a complete change
> in one patch.
> The timing was also discussed as it could impact the pending patches.
> So it would be done at the end or the beginning of a release.
> Marc suggests to do it for 16.04 as the numbering scheme has changed.
> 
> There is no strong conclusion at this point because we need to decide
> wether the renaming deserves to be done or never.
> I suggest to take the inputs from the technical board.

The technical board has agreed that the renaming cannot happen in 16.04.
The pro/cons balance need to be discussed more.
The plan is to keep the discussion open during the next 2 weeks and
take a decision based on the discussion outcome.

[dpdk-dev] [PATCH] vhost: call rte_vhost_enable_guest_notification only on enabled queues

[Yuanhan Liu]

On Wed, Apr 06, 2016 at 05:29:06PM -0700, Rich Lane wrote:
> If the vhost PMD were configured with more queues than the guest, the old
> code would segfault in rte_vhost_enable_guest_notification due to a NULL
> virtqueue pointer.
> 
> Fixes: ee584e9710b9 ("vhost: add driver on top of the library")
> Signed-off-by: Rich Lane 

Acked-by: Yuanhan Liu 

Thanks.

--yliu

[dpdk-dev] [PATCH] vhost: call rte_vhost_enable_guest_notification only on enabled queues

[Yuanhan Liu]

On Thu, Apr 07, 2016 at 03:29:32PM +, Loftus, Ciara wrote:
> > On 4/7/2016 8:29 AM, Rich Lane wrote:
> > > If the vhost PMD were configured with more queues than the guest, the
> > old
> > > code would segfault in rte_vhost_enable_guest_notification due to a NULL
> > > virtqueue pointer.
> > >
> > > Fixes: ee584e9710b9 ("vhost: add driver on top of the library")
> > > Signed-off-by: Rich Lane 
> > > ---
> > >   drivers/net/vhost/rte_eth_vhost.c | 5 +++--
> > >   1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/net/vhost/rte_eth_vhost.c
> > b/drivers/net/vhost/rte_eth_vhost.c
> > > index b1eb082..310cbef 100644
> > > --- a/drivers/net/vhost/rte_eth_vhost.c
> > > +++ b/drivers/net/vhost/rte_eth_vhost.c
> > > @@ -265,7 +265,6 @@ new_device(struct virtio_net *dev)
> > >   vq->device = dev;
> > >   vq->internal = internal;
> > >   vq->port = eth_dev->data->port_id;
> > > - rte_vhost_enable_guest_notification(dev, vq-
> > >virtqueue_id, 0);
> > >   }
> > >   for (i = 0; i < eth_dev->data->nb_tx_queues; i++) {
> > >   vq = eth_dev->data->tx_queues[i];
> > > @@ -274,9 +273,11 @@ new_device(struct virtio_net *dev)
> > >   vq->device = dev;
> > >   vq->internal = internal;
> > >   vq->port = eth_dev->data->port_id;
> > > - rte_vhost_enable_guest_notification(dev, vq-
> > >virtqueue_id, 0);
> > >   }
> > >
> > > + for (i = 0; i < dev->virt_qp_nb * VIRTIO_QNUM; i++)
> > > + rte_vhost_enable_guest_notification(dev, i, 0);
> > > +
> > >   dev->flags |= VIRTIO_DEV_RUNNING;
> > >   dev->priv = eth_dev;
> > >   eth_dev->data->dev_link.link_status = ETH_LINK_UP;
> > 
> > Just one question, when qemu starts a vm, usually, only one queue is
> > enabled, then only 1 tx and 1 rx are called
> > rte_vhost_enable_guest_notification; but after system is up, we use
> > "ethtool -K eth0 combined x" to enable multiqueues, there's no chance to
> > call rte_vhost_enable_guest_notification for other queues, right?
> 
> As far as I know, virt_qp_nb will report the number of queues available, 
> regardless of their state enabled/disabled. So for example if we have 4 
> queues, but only one enabled, virt_qp_nb should still = 4 and 
> rte_vhost_enable_guest_notification() will be called for all of these queues.

Yes.

--yliu

[dpdk-dev] [PATCH] doc: announce xstats api change for 16.07

[Thomas Monjalon]

> > This patch adds a notice that the API for the xstats functionality will be
> > modified in the 16.07 release, with no backwards compatibility planned
> > as it would require code duplication in each PMD that supports xstats.
> > 
> > Signed-off-by: Harry van Haaren 
> 
> Acked-by: Thomas Monjalon 
> Acked-by: Remy Horton 
> Acked-by: David Harton 
> Acked-by: Maryam Tahhan 

Applied, thanks

[dpdk-dev] [PATCH v1] doc: fix spellings

[Thomas Monjalon]

2016-04-07 22:14, John McNamara:
> Fix some spelling errors and typos.
> 
> Signed-off-by: John McNamara 

Applied, thanks

[dpdk-dev] [PATCH] doc: announce ABI change for rte_port_source_params structure

[Thomas Monjalon]

> > > Several new fields will be added to structure rte_port_source_params
> > > for source port enhancement with pcap file reading support.
> > >
> > > Signed-off-by: Fan Zhang 
> > > Acked-by: Cristian Dumitrescu 
> > 
> > Acked-by: Jasvinder Singh 
> 
> Acked-by: Piotr Azarewicz 

Applied, thanks

Please send a patch to remove NEXT_ABI early in the 16.07 cycle.

[dpdk-dev] [PATCH] bnx2x: Update documentation

[Thomas Monjalon]

2016-04-07 11:22, Rasesh Mody:
> Please apply the documentation patch for 16.04.
> 
> Signed-off-by: Rasesh Mody 

Applied, thanks

[dpdk-dev] [PATCH] mk: show version as a decimal integer

[Thomas Monjalon]

2016-03-24 22:26, Thomas Monjalon:
> In order to ease packaging support of changes in DPDK build system,
> introduce a decimal integer to compare version numbers.
> It does not show the minor numbers as it is not meaningful for packaging.
> 
> Usage for DPDK 16.04:
> % make showversionum
> 1604
> 
> Signed-off-by: Thomas Monjalon 

Applied

[dpdk-dev] [PATCH 0/8] simpler and better build test

[Thomas Monjalon]

2016-03-29 18:15, Thomas Monjalon:
> These are some improvements to the script test-build.sh which
> makes compilation testing easier in various environments with
> different dependencies.
> 
> Thomas Monjalon (8):
>   scripts: fix run in any directory
>   scripts: remove legacy build method test
>   scripts: test build of performance-thread example
>   scripts: stop build test after first error
>   scripts: allow tuning build options per test target
>   scripts: allow tuning any test build option
>   scripts: hook build test config
>   scripts: add verbose test build option

Applied

[dpdk-dev] [PATCH] scripts: build with libsso

[Thomas Monjalon]

> > Subject: [PATCH] scripts: build with libsso
> > 
> > Signed-off-by: Thomas Monjalon 
> 
> Acked-by: Pablo de Lara 

Applied

[dpdk-dev] [PATCH] examples: fix not all queues drained in l3fwd-*

[Thomas Monjalon]

> In l3fwd-acl and l3fwd-power not all tx ports was included in tx_port_id
> array, used to periodically drain only available ports. This caused that
> some packets can remain in buffer when application stops to receiving
> packets or when size of burst is small.
> 
> Fixes: e2366e74e029 ("examples: use buffered Tx")
> 
> Signed-off-by: Tomasz Kulasek 

Applied, thanks