[dpdk-dev] xstats performance

[Rasesh Mody]

> From: Remy Horton [mailto:remy.horton at intel.com]
> Sent: Wednesday, July 06, 2016 12:44 AM
> 
> 
> On 05/07/2016 19:10, Rasesh Mody wrote:
> [..]
> >> For all the current drivers xstats_names[idx].id==idx so it would
> >> just involve removing the references to the id field and updating the
> >> documentation. Complication is coordinating with QLogic for the bnx2x
> >> & qede xstats patches.
> >
> > We could incorporate this change in our re-submission.
> 
> The changes mentioned above have been merged in, so go ahead.. :)

We have submitted the QEDE and BNX2X PMD xstats patches with recent API changes.

During the xstats change verification, it was observed that the order in which 
xstats names are fetched don't seem to match the order in which xstats values 
are fetched. When populating the xstats names, we order them as driver specific 
xstats names and then standard stats names. Whereas, while populating the 
xstats values, we populate the standard stats values and then the driver 
specific xstats values.

In rte_eth_xstats_get_names(): xcount (or cnt_used_entries) + 
cnt_used_entries/count (RTE_NB_STATS + (dev->data->nb_rx_queues * 
RTE_NB_RXQ_STATS) + (dev->data->nb_tx_queues * RTE_NB_TXQ_STATS))
In rte_eth_xstats_get (): count (RTE_NB_STATS + (dev->data->nb_rx_queues * 
RTE_NB_RXQ_STATS) + (dev->data->nb_tx_queues * RTE_NB_TXQ_STATS)) + xcount

Could you take a look?

Thanks!
Rasesh

[dpdk-dev] [PATCH 1/3] net/bnx2x: remove unneeded dependency on hash library

[Rasesh Mody]

> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Wednesday, July 06, 2016 7:45 AM
> 
> Fixes: 9fb557035d90 ("bnx2x: enable PMD build")
> 
> Signed-off-by: Thomas Monjalon 

Acked-by: Rasesh Mody 

Thanks!
Rasesh

[dpdk-dev] [PATCH 07/11] pmdinfogen: fix build warnings

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> Sent: Thursday, July 7, 2016 6:55 PM
> To: Thomas Monjalon 
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 07/11] pmdinfogen: fix build warnings
> 
> On Thu, Jul 07, 2016 at 05:36:26PM +0200, Thomas Monjalon wrote:
> > When compiled with a standard clang, pmdinfogen can raise a warning:
> > buildtools/pmdinfogen/pmdinfogen.c:365:1: warning:
> > control reaches end of non-void function
> >
> > Actually there can be more warnings with stricter compilers.
> > In order to catch them early and fix most of them, the DPDK standard
> > flags WERROR_FLAGS are used.
> >
> > The warnings fixed are:
> > no previous prototype for ...
> > no return statement in function returning non-void
> > variable ?secstrings? set but not used
> > ?sec_name? defined but not used
> > ?get_symbol_index? defined but not used
> > pointer of type ?void *? used in arithmetic
> >
> > Fixes: 98b0fdb0ffc6 ("pmdinfogen: add buildtools and pmdinfogen
> > utility")
> >
> > Signed-off-by: Thomas Monjalon 
> > ---
> I'm not opposed to any of these changes, but I'm really starting to wonder
> how well used/maintained clang is as a toolchain target.  I assert that
> because, with my admittedly broken dependency rule, a native clang build
> for me errors out in any number of places:
> 
> /home/nhorman/git/dpdk/lib/librte_eal/linuxapp/eal/eal_pci.c:392:37:
> error:
> equality comparison with extraneous parentheses [-Werror,-Wparentheses-
> equality]  if (((_device_list)->tqh_first == ((void*)0))) {
>   ~~^
> /home/nhorman/git/dpdk/lib/librte_eal/linuxapp/eal/eal_pci.c:392:37: note:
> remove extraneous parentheses around the comparison to silence this
> warning  if (((_device_list)->tqh_first == ((void*)0))) {


It is due to the clang/ccache "issue" that is tripping up everyone. Exporting 
CCACHE_CPP2=yes should fix it. There was a thread about this earlier in the 
week.

John.

[dpdk-dev] [PATCH] net/mlx5: fix packet type and offload flags in Rx

[Maxime Leroy]

In mlx5 rx function, the packet_type and ol_flags mbuf fields are not
properly initialized when no rx offload feature is enabled (checksum, l2
tun checksum, vlan_strip, crc). Thus, these fields can have a value
different of 0 depending on their value when the mbuf was freed.

This can result in an incorrect application behavior if invalid
ol_flags/ptype are set, or memory corruptions if IND_ATTACHED_MBUF is
set in ol_flags.

Fixes: 081f7eae242e ("mlx5: process offload flags only when requested")

Signed-off-by: Maxime Leroy 
---
 drivers/net/mlx5/mlx5_rxtx.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
index 0c352f3f..4132fd74 100644
--- a/drivers/net/mlx5/mlx5_rxtx.c
+++ b/drivers/net/mlx5/mlx5_rxtx.c
@@ -1599,6 +1599,8 @@ mlx5_rx_burst(void *dpdk_rxq, struct rte_mbuf **pkts, 
uint16_t pkts_n)
pkt = seg;
assert(len >= (rxq->crc_present << 2));
/* Update packet information. */
+   pkt->packet_type = 0;
+   pkt->ol_flags = 0;
if (rxq->csum | rxq->csum_l2tun | rxq->vlan_strip |
rxq->crc_present) {
if (rxq->csum) {
-- 
2.1.4

[dpdk-dev] [PATCH v3 00/11] Fix build errors related to exported headers

[Wiles, Keith]

> On Jul 7, 2016, at 10:49 AM, Adrien Mazarguil  
> wrote:
> 
> DPDK uses GNU C language extensions in most of its code base. This is fine
> for internal source files whose compilation flags are controlled by DPDK,
> however user applications that use exported "public" headers may experience
> compilation failures when enabling strict error/standard checks (-std and
> -pedantic for instance).

Do you try compiling these changes with CLANG and/or ICC compilers?

[dpdk-dev] [PATCH 11/11] maintainers: add section for pmdinfo

[Thomas Monjalon]

2016-07-07 12:14, Neil Horman:
> On Thu, Jul 07, 2016 at 05:45:09PM +0200, Thomas Monjalon wrote:
> > Neil,
> > 
> > I would gladly drop this patch from the series if you send a similar one
> > with your name as maintainer.
> > 
> > Thanks
> > 
> Lets get through the rest of this stuff first, then I'll send it when we're
> complete.  Sound good?

Up to you

[dpdk-dev] [PATCH 09/11] eal: move PCI table macro

[Thomas Monjalon]

2016-07-07 12:11, Neil Horman:
> On Thu, Jul 07, 2016 at 05:36:28PM +0200, Thomas Monjalon wrote:
> > Remove include of rte_pci.h in the generic header rte_dev.h
> > and move the macro DRIVER_REGISTER_PCI_TABLE in rte_pci.h.
[...]
> > --- a/lib/librte_eal/common/include/rte_dev.h
> > +++ b/lib/librte_eal/common/include/rte_dev.h
> > @@ -48,7 +48,7 @@ extern "C" {
> >  
> >  #include 
> >  #include 
> > -#include 
> > +
> >  #include 
> >  
> >  __attribute__((format(printf, 2, 0)))
> > @@ -195,10 +195,6 @@ DRIVER_EXPORT_NAME(nm, __COUNTER__)
> >  
> >  #define DRV_EXP_TAG(name, tag) __##name##_##tag
> >  
> > -#define DRIVER_REGISTER_PCI_TABLE(name, table) \
> > -static const char DRV_EXP_TAG(name, pci_tbl_export)[] 
> > __attribute__((used)) = \
> > -RTE_STR(table)
> > -
> >  #define DRIVER_REGISTER_PARAM_STRING(name, str) \
> >  static const char DRV_EXP_TAG(name, param_string_export)[] \
> >  __attribute__((used)) = str
> > diff --git a/lib/librte_eal/common/include/rte_pci.h 
> > b/lib/librte_eal/common/include/rte_pci.h
> > index fa74962..3b0d26a 100644
> > --- a/lib/librte_eal/common/include/rte_pci.h
> > +++ b/lib/librte_eal/common/include/rte_pci.h
> > @@ -188,6 +188,11 @@ struct rte_pci_device {
> > .subsystem_device_id = PCI_ANY_ID
> >  #endif
> >  
> > +#define DRIVER_REGISTER_PCI_TABLE(name, table) \
> > +static const char __##name##_pci_tbl_export[] \
> > +   __attribute__((used)) = \
> > +   RTE_STR(table)
> > +
> 
> This seems strange to me, in that its odd for the driver information export
> macros to be spread out in multiple locations.  Specifically it enjoins the 
> use
> of the DRV_EXP_TAG macro, which helps centralize tag naming.  Perhaps the 
> happy
> medium is to place all the export macros (includnig PMD_REGISTER_DRIVER) into
> its own pmd_register.h header?

I don't know.
David, your opinion?

[dpdk-dev] [PATCH 03/11] mk: fix build dependency of drivers on pmdinfogen

[Thomas Monjalon]

2016-07-07 11:56, Neil Horman:
> On Thu, Jul 07, 2016 at 05:36:22PM +0200, Thomas Monjalon wrote:
> > When compiling the drivers, some code is generated with pmdinfogen.
> > A fresh parallel build can fail if a driver is compiled before pmdinfogen:
> > build/buildtools/dpdk-pmdinfogen: Permission denied
> > 
> > There was a dependency declared in drivers/Makefile but it cannot work
> > because this file is based on mk/rte.subdir.mk which do not handle
> > dependencies.
> > 
> > It is fixed by declaring the whole buildtools as (order only) prerequisite
> > of drivers.
[...]
> > --- a/drivers/Makefile
> > +++ b/drivers/Makefile
> > @@ -34,6 +34,4 @@ include $(RTE_SDK)/mk/rte.vars.mk
> >  DIRS-y += net
> >  DIRS-$(CONFIG_RTE_LIBRTE_CRYPTODEV) += crypto
> >  
> > -DEPDIRS-y += buildtools/pmdinfo
> > -
> >  include $(RTE_SDK)/mk/rte.subdir.mk
> > diff --git a/mk/rte.sdkbuild.mk b/mk/rte.sdkbuild.mk
> > index fb68af2..354f006 100644
> > --- a/mk/rte.sdkbuild.mk
> > +++ b/mk/rte.sdkbuild.mk
> > @@ -49,6 +49,7 @@ $(1): $(sort $(LOCAL_DEPDIRS-$(1)))
> >  endef
> >  
> >  $(foreach d,$(ROOTDIRS-y),$(eval $(call depdirs_rule,$(d
> > +drivers: | buildtools
> >  
> I'm not sure i understand the reasoning here, DEPDIRS is meant to declare
> prerequisites to a directory (and its children) getting built, right?  A 
> parallel make should block any drivers getting built prior to pmdinfogen 
> getting
> built.  What am I missing?

DEPDIRS-y is not parsed at all in the context of rte.subdir.mk.
That's why this line was ignored by the build system.

[dpdk-dev] [PATCH 01/11] drivers: fix build with new register macro

[Adrien Mazarguil]

On Thu, Jul 07, 2016 at 05:36:20PM +0200, Thomas Monjalon wrote:
> Compilation fails because of some typos.
> 
> Fixes: cb6696d22023 ("drivers: update registration macro usage")
> 
> Signed-off-by: Thomas Monjalon 
> ---
>  drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 2 +-
>  drivers/net/mlx4/mlx4.c| 2 +-
>  drivers/net/mlx5/mlx5.c| 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c 
> b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
> index db3e562..859a04b 100644
> --- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
> +++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
> @@ -721,6 +721,6 @@ static struct rte_driver cryptodev_aesni_mb_pmd_drv = {
>   .uninit = cryptodev_aesni_mb_uninit
>  };
>  
> -PMD_REGISTER_DRIVER(cryptodev_aesni_mb_pmd_drvi, aesni_mb);
> +PMD_REGISTER_DRIVER(cryptodev_aesni_mb_pmd_drv, aesni_mb);
>  DRIVER_REGISTER_PARAM_STRING(aesni_gcm, "max_nb_queue_pairs= "
>  "max_nb_sessions= socket_id=");
> diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
> index 8758eac..d9ffb13 100644
> --- a/drivers/net/mlx4/mlx4.c
> +++ b/drivers/net/mlx4/mlx4.c
> @@ -5861,5 +5861,5 @@ static struct rte_driver rte_mlx4_driver = {
>   .init = rte_mlx4_pmd_init,
>  };
>  
> -PMD_REGISTER_DRIVER(rte_mlx4_driveri, mlx4)
> +PMD_REGISTER_DRIVER(rte_mlx4_driver, mlx4);
>  DRIVER_REGISTER_PCI_TABLE(mlx4, mlx4_pci_id_map);
> diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
> index 358e9b4..8d32252 100644
> --- a/drivers/net/mlx5/mlx5.c
> +++ b/drivers/net/mlx5/mlx5.c
> @@ -762,5 +762,5 @@ static struct rte_driver rte_mlx5_driver = {
>   .init = rte_mlx5_pmd_init,
>  };
>  
> -PMD_REGISTER_DRIVER(rte_mlx5_driveri, mlx5)
> +PMD_REGISTER_DRIVER(rte_mlx5_driver, mlx5);
>  DRIVER_REGISTER_PCI_TABLE(mlx5, mlx5_pci_id_map);
> -- 
> 2.7.0

Saw the issue when compiling my patchset after rebasing, thus,

Tested-by: Adrien Mazarguil 

-- 
Adrien Mazarguil
6WIND

[dpdk-dev] [PATCH 1/2] net/enic: fix setting MAC address when a port is restarted

[Nelson Escobar]

enic_disable() removed the MAC address when a port was shut down but
enic_enable() didn't add the MAC address back when the port was
started again. Move where we set the MAC address for the adapter from
enic_setup_finish() to a enic_enable() so that port restarting works
properly.

Fixes: fefed3d1e62c ("enic: new driver")

Signed-off-by: Nelson Escobar 
Reviewed-by: John Daley 
---
 drivers/net/enic/enic_main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index 8eacf2d..1f3d14e 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -455,6 +455,8 @@ int enic_enable(struct enic *enic)
for (index = 0; index < enic->rq_count; index++)
enic_start_rq(enic, index);

+   vnic_dev_add_addr(enic->vdev, enic->mac_addr);
+
vnic_dev_enable_wait(enic->vdev);

/* Register and enable error interrupt */
@@ -971,8 +973,6 @@ int enic_setup_finish(struct enic *enic)
return -1;
}

-   vnic_dev_add_addr(enic->vdev, enic->mac_addr);
-
/* Default conf */
vnic_dev_packet_filter(enic->vdev,
1 /* directed  */,
-- 
2.7.0

[dpdk-dev] [PATCH 09/18] mbuf: support Mpls in software packet type parser

[Olivier Matz]

Hi Cunming,

On 07/07/2016 10:48 AM, Liang, Cunming wrote:
> Hi Olivier,
> 
>> -Original Message-
>> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
>> Sent: Wednesday, July 06, 2016 4:00 PM
>> To: Liang, Cunming ; dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH 09/18] mbuf: support Mpls in software packet
>> type parser
>>
>> Hi Cunming,
>>
>> On 07/06/2016 09:08 AM, Liang, Cunming wrote:
>>> Hi Olivier,
>>>
>>> On 7/5/2016 11:41 PM, Olivier Matz wrote:
 Add a new RTE_PTYPE_L2_ETHER_MPLS packet type, and its support in
 rte_pktmbuf_get_ptype().

 Signed-off-by: Didier Pallard 
 Signed-off-by: Olivier Matz 
 ---
   lib/librte_mbuf/rte_mbuf_ptype.c | 25 +
   lib/librte_mbuf/rte_mbuf_ptype.h |  9 -
   lib/librte_net/Makefile  |  4 +++-
   lib/librte_net/rte_ether.h   |  2 ++
   4 files changed, 38 insertions(+), 2 deletions(-)

 diff --git a/lib/librte_mbuf/rte_mbuf_ptype.c
 b/lib/librte_mbuf/rte_mbuf_ptype.c
 index 5d46608..0dea600 100644
 --- a/lib/librte_mbuf/rte_mbuf_ptype.c
 +++ b/lib/librte_mbuf/rte_mbuf_ptype.c
 @@ -41,6 +41,7 @@
   #include 
   #include 
   #include 
 +#include 
 /* get l3 packet type from ip6 next protocol */
   static uint32_t
 @@ -166,6 +167,9 @@ uint32_t rte_pktmbuf_get_ptype(const struct
 rte_mbuf *m,
   off = sizeof(*eh);
   hdr_lens->l2_len = off;
   +if (proto == rte_cpu_to_be_16(ETHER_TYPE_IPv4))
 +goto l3; /* fast path if packet is IPv4 */
 +
   if (proto == rte_cpu_to_be_16(ETHER_TYPE_VLAN)) {
   const struct vlan_hdr *vh;
   struct vlan_hdr vh_copy;
 @@ -189,8 +193,29 @@ uint32_t rte_pktmbuf_get_ptype(const struct
 rte_mbuf *m,
   off += 2 * sizeof(*vh);
   hdr_lens->l2_len += 2 * sizeof(*vh);
   proto = vh->eth_proto;
 +} else if ((proto == rte_cpu_to_be_16(ETHER_TYPE_MPLS)) ||
 +(proto == rte_cpu_to_be_16(ETHER_TYPE_MPLSM))) {
 +unsigned int i;
 +const struct mpls_hdr *mh;
 +struct mpls_hdr mh_copy;
 +
 +#define MAX_MPLS_HDR 5
 +for (i = 0; i < MAX_MPLS_HDR; i++) {
 +mh = rte_pktmbuf_read(m, off + (i * sizeof(*mh)),
 +sizeof(*mh), _copy);
 +if (unlikely(mh == NULL))
 +return pkt_type;
 +if (mh->bs)
 +break;
 +}
 +if (i == MAX_MPLS_HDR)
 +return pkt_type;
 +pkt_type = RTE_PTYPE_L2_ETHER_MPLS;
 +hdr_lens->l2_len += (sizeof(*mh) * (i + 1));
>>> [LC] l2_len includes Eth, Vlan(opt.), MPLS(opt.). For VLAN and MPLS, it
>>> may include #n times overlay.
>>> These layer recognition knowledge are lost after the detection logic.
>>> Once the APP takes the ptype, for the layer(L2, L3, L4) which has more
>>> shim-layer, the xxx_len can't help to avoid the re-parse cost.
>>
>> This is linked with the definition of packet type. Each layer has a
>> type, and here we associate it to a length (by the way the length is
>> something we may consider integrate inside the packet type in the future).
> [LC] Yes, I see. 
> My point is in some case, the length can represent for different layer.
> For who interests on L2 MPLS, the length layer scheme maybe can define as 
> {L2/MPLS/inner_L2/inner_L3}.
> The rte_mbuf_hdr_lens likes a meta data which associates with the specific 
> parser(assuming customized runtime instance provided by 
> rte_pktmbuf_get_ptype).
> The provider understand the meaning and layout.

OK, I see.

For VLAN or QinQ, we could consider that it is the same L2 than the
Ethernet header.
But maybe MPLS should not be part of this patchset, because it's
actually a bit different. The choice I've made was to represent MPLS in
packet_type like this:

  Ether - MPLS - IP - TCP
  \ / ||
  L2 L3L4

Another way to represent it would be:

  Ether - MPLS - IP - TCP
|  |  ||
   L2   INNER_L2INNER_L4
  INNER_L3

If it's too confusing, we may remove MPLS from this patchset.


Regards,
Olivier



>  
>>
>> The packet_type model allows to describe many packets kinds. Some will
>> be difficult to represent (ex: a packet with several different L2 or
>> L3). But I think this is a good compromise that could help the
>> application to get some information without looking inside the packet.
>>
>> Changing the packet type structure to something more flexible/complex
>> would probably imply to loose time filling it in drivers and parse it in
>> the application. And we already have a structure that contains all the
>> information needed by the application: the packet data ;)
> [LC] Fully agree. Sometimes it's a tradeoff, if the offering meta data by 
> parser is 
> not enough for further processing, the 

[dpdk-dev] [PATCH v3 11/11] scripts: check compilation of exported header files

[Adrien Mazarguil]

This script checks that header files in a given directory do not miss
dependencies when included on their own, do not conflict and accept being
compiled with the strictest possible flags.

Signed-off-by: Adrien Mazarguil 
---
 MAINTAINERS   |   1 +
 scripts/check-includes.sh | 286 +
 scripts/test-build.sh |  14 ++
 3 files changed, 301 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index a59191e..c12db3d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -26,6 +26,7 @@ T: git://dpdk.org/dpdk
 F: MAINTAINERS
 F: scripts/check-maintainers.sh
 F: scripts/check-git-log.sh
+F: scripts/check-includes.sh
 F: scripts/checkpatches.sh
 F: scripts/load-devel-config.sh
 F: scripts/test-build.sh
diff --git a/scripts/check-includes.sh b/scripts/check-includes.sh
new file mode 100755
index 000..d65adc6
--- /dev/null
+++ b/scripts/check-includes.sh
@@ -0,0 +1,286 @@
+#!/bin/sh -e
+#
+#   BSD LICENSE
+#
+#   Copyright 2016 6WIND S.A.
+#
+#   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 6WIND S.A. 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.
+
+# This script checks that header files in a given directory do not miss
+# dependencies when included on their own, do not conflict and accept being
+# compiled with the strictest possible flags.
+#
+# Files are looked up in the directory provided as the first argument,
+# otherwise build/include by default.
+#
+# Recognized environment variables:
+#
+# VERBOSE=1 is the same as -v.
+#
+# QUIET=1 is the same as -q.
+#
+# SUMMARY=1 is the same as -s.
+#
+# CC, CPPFLAGS, CFLAGS, EXTRA_CPPFLAGS, EXTRA_CFLAGS, CXX, CXXFLAGS and
+# EXTRA_CXXFLAGS are taken into account.
+#
+# PEDANTIC_CFLAGS, PEDANTIC_CXXFLAGS and PEDANTIC_CPPFLAGS provide strict
+# C/C++ compilation flags.
+#
+# IGNORE contains a list of shell patterns matching files (relative to the
+# include directory) to avoid. It is set by default to known DPDK headers
+# which must not be included on their own.
+#
+# IGNORE_CXX provides additional files for C++.
+
+while getopts hqvs arg; do
+   case $arg in
+   h)
+   cat < /dev/null
+
+[ "$VERBOSE" = 1 ] &&
+output ()
+{
+   local CCV
+   local CXXV
+
+   shift
+   CCV=$CC
+   CXXV=$CXX
+   CC="echo $CC" CXX="echo $CXX" "$@"
+   CC=$CCV
+   CXX=$CXXV
+
+   "$@"
+} ||
+output ()
+{
+
+   printf '  %s\n' "$1"
+   shift
+   "$@"
+}
+
+trap 'rm -f "$temp_cc" "$temp_cxx"' EXIT
+
+compile_cc ()
+{
+   ${CC} -I"$include_dir" \
+   ${PEDANTIC_CPPFLAGS} ${CPPFLAGS} ${EXTRA_CPPFLAGS} \
+   ${PEDANTIC_CFLAGS} ${CFLAGS} ${EXTRA_CFLAGS} \
+   -c -o /dev/null "${temp_cc}"
+}
+
+compile_cxx ()
+{
+   ${CXX} -I"$include_dir" \
+   ${PEDANTIC_CPPFLAGS} ${CPPFLAGS} ${EXTRA_CPPFLAGS} \
+   ${PEDANTIC_CXXFLAGS} ${CXXFLAGS} ${EXTRA_CXXFLAGS} \
+   -c -o /dev/null "${temp_cxx}"
+}
+
+ignore ()
+{
+   file="$1"
+   shift
+   while [ $# -ne 0 ]; do
+   case "$file" in
+   $1)
+   return 0
+   ;;
+   esac
+   shift
+   done
+   return 1
+}
+
+# Check C/C++ compilation for each header file.
+
+while read -r path
+do
+   file=${path#$include_dir}
+   file=${file##/}
+   if ignore "$file" $IGNORE; then
+   output "SKIP $file" :
+   continue
+   fi
+   if printf "\
+#include <%s>
+
+int main(void)
+{
+   return 0;
+}
+" 

[dpdk-dev] [PATCH v3 10/11] lib: hide static functions never defined

[Adrien Mazarguil]

Arch-specific functions not defined for all architectures (missing on x86
in this case) and not used anywhere should not expose a prototype.

This commit prevents the following error:

 error: `rte_mov48' declared `static' but never defined

Signed-off-by: Adrien Mazarguil 
---
 lib/librte_eal/common/include/generic/rte_memcpy.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/lib/librte_eal/common/include/generic/rte_memcpy.h 
b/lib/librte_eal/common/include/generic/rte_memcpy.h
index afb0afe..4e9d879 100644
--- a/lib/librte_eal/common/include/generic/rte_memcpy.h
+++ b/lib/librte_eal/common/include/generic/rte_memcpy.h
@@ -64,6 +64,8 @@ rte_mov16(uint8_t *dst, const uint8_t *src);
 static inline void
 rte_mov32(uint8_t *dst, const uint8_t *src);

+#ifdef __DOXYGEN__
+
 /**
  * Copy 48 bytes from one location to another using optimised
  * instructions. The locations should not overlap.
@@ -76,6 +78,8 @@ rte_mov32(uint8_t *dst, const uint8_t *src);
 static inline void
 rte_mov48(uint8_t *dst, const uint8_t *src);

+#endif /* __DOXYGEN__ */
+
 /**
  * Copy 64 bytes from one location to another using optimised
  * instructions. The locations should not overlap.
-- 
2.1.4

[dpdk-dev] [PATCH v3 09/11] lib: remove named variadic macros in exported headers

[Adrien Mazarguil]

Exported header files used by applications should allow the strictest
compiler flags. Language extensions used in many places must be explicitly
marked or removed to avoid warnings and compilation failures.

Since there is no way to force named variadic macros as extensions, use a
a standard __VA_ARGS__ with an extra dummy argument to format strings.

This commit prevents the following errors:

 error: ISO C does not permit named variadic macros

Signed-off-by: Adrien Mazarguil 
---
 lib/librte_cryptodev/rte_cryptodev.h   | 32 ++---
 lib/librte_cryptodev/rte_cryptodev_pmd.h   |  2 +-
 lib/librte_eal/common/include/rte_common.h |  9 +++
 3 files changed, 28 insertions(+), 15 deletions(-)

diff --git a/lib/librte_cryptodev/rte_cryptodev.h 
b/lib/librte_cryptodev/rte_cryptodev.h
index be9a544..febea9b 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -77,26 +77,30 @@ extern const char **rte_cyptodev_names;

 /* Logging Macros */

-#define CDEV_LOG_ERR(fmt, args...) \
-   RTE_LOG(ERR, CRYPTODEV, "%s() line %u: " fmt "\n",  \
-   __func__, __LINE__, ## args)
+#define CDEV_LOG_ERR(...) \
+   RTE_LOG(ERR, CRYPTODEV, \
+   RTE_FMT("%s() line %u: " RTE_FMT_HEAD(__VA_ARGS__,) "\n", \
+   __func__, __LINE__, RTE_FMT_TAIL(__VA_ARGS__,)))

-#define CDEV_PMD_LOG_ERR(dev, fmt, args...)\
-   RTE_LOG(ERR, CRYPTODEV, "[%s] %s() line %u: " fmt "\n", \
-   dev, __func__, __LINE__, ## args)
+#define CDEV_PMD_LOG_ERR(dev, ...) \
+   RTE_LOG(ERR, CRYPTODEV, \
+   RTE_FMT("[%s] %s() line %u: " RTE_FMT_HEAD(__VA_ARGS__,) "\n", \
+   dev, __func__, __LINE__, RTE_FMT_TAIL(__VA_ARGS__,)))

 #ifdef RTE_LIBRTE_CRYPTODEV_DEBUG
-#define CDEV_LOG_DEBUG(fmt, args...)   \
-   RTE_LOG(DEBUG, CRYPTODEV, "%s() line %u: " fmt "\n",\
-   __func__, __LINE__, ## args)\
+#define CDEV_LOG_DEBUG(...) \
+   RTE_LOG(DEBUG, CRYPTODEV, \
+   RTE_FMT("%s() line %u: " RTE_FMT_HEAD(__VA_ARGS__,) "\n", \
+   __func__, __LINE__, RTE_FMT_TAIL(__VA_ARGS__,)))

-#define CDEV_PMD_TRACE(fmt, args...)   \
-   RTE_LOG(DEBUG, CRYPTODEV, "[%s] %s: " fmt "\n", \
-   dev, __func__, ## args)
+#define CDEV_PMD_TRACE(...) \
+   RTE_LOG(DEBUG, CRYPTODEV, \
+   RTE_FMT("[%s] %s: " RTE_FMT_HEAD(__VA_ARGS__,) "\n", \
+   dev, __func__, RTE_FMT_TAIL(__VA_ARGS__,)))

 #else
-#define CDEV_LOG_DEBUG(fmt, args...)
-#define CDEV_PMD_TRACE(fmt, args...)
+#define CDEV_LOG_DEBUG(...) (void)0
+#define CDEV_PMD_TRACE(...) (void)0
 #endif

 /**
diff --git a/lib/librte_cryptodev/rte_cryptodev_pmd.h 
b/lib/librte_cryptodev/rte_cryptodev_pmd.h
index cf08a50..4a07362 100644
--- a/lib/librte_cryptodev/rte_cryptodev_pmd.h
+++ b/lib/librte_cryptodev/rte_cryptodev_pmd.h
@@ -62,7 +62,7 @@ extern "C" {
 #define RTE_PMD_DEBUG_TRACE(...) \
rte_pmd_debug_trace(__func__, __VA_ARGS__)
 #else
-#define RTE_PMD_DEBUG_TRACE(fmt, args...)
+#define RTE_PMD_DEBUG_TRACE(...)
 #endif

 struct rte_cryptodev_session {
diff --git a/lib/librte_eal/common/include/rte_common.h 
b/lib/librte_eal/common/include/rte_common.h
index 98ecc1c..db5ac91 100644
--- a/lib/librte_eal/common/include/rte_common.h
+++ b/lib/librte_eal/common/include/rte_common.h
@@ -335,6 +335,15 @@ rte_bsf32(uint32_t v)
 /** Take a macro value and get a string version of it */
 #define RTE_STR(x) _RTE_STR(x)

+/**
+ * ISO C helpers to modify format strings using variadic macros.
+ * This is a replacement for the ", ## __VA_ARGS__" GNU extension.
+ * An empty %s argument is appended to avoid a dangling comma.
+ */
+#define RTE_FMT(fmt, ...) fmt "%.0s", __VA_ARGS__ ""
+#define RTE_FMT_HEAD(fmt, ...) fmt
+#define RTE_FMT_TAIL(fmt, ...) __VA_ARGS__
+
 /** Mask value of type "tp" for the first "ln" bit set. */
 #defineRTE_LEN2MASK(ln, tp)\
((tp)((uint64_t)-1 >> (sizeof(uint64_t) * CHAR_BIT - (ln
-- 
2.1.4

[dpdk-dev] [PATCH v3 08/11] lib: work around forward reference to enum types

[Adrien Mazarguil]

Exported header files used by applications should allow the strictest
compiler flags. Language extensions used in many places must be explicitly
marked or removed to avoid warnings and compilation failures.

This commit prevents the following errors:

 error: ISO C forbids forward references to `enum' types

Signed-off-by: Adrien Mazarguil 
---
 lib/librte_eal/common/include/generic/rte_cpuflags.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lib/librte_eal/common/include/generic/rte_cpuflags.h 
b/lib/librte_eal/common/include/generic/rte_cpuflags.h
index c1da357..71321f3 100644
--- a/lib/librte_eal/common/include/generic/rte_cpuflags.h
+++ b/lib/librte_eal/common/include/generic/rte_cpuflags.h
@@ -44,6 +44,7 @@
 /**
  * Enumeration of all CPU features supported
  */
+__extension__
 enum rte_cpu_flag_t;

 /**
@@ -55,6 +56,7 @@ enum rte_cpu_flag_t;
  * flag name
  * NULL if flag ID is invalid
  */
+__extension__
 const char *
 rte_cpu_get_flag_name(enum rte_cpu_flag_t feature);

@@ -68,6 +70,7 @@ rte_cpu_get_flag_name(enum rte_cpu_flag_t feature);
  * 0 if flag is not available
  * -ENOENT if flag is invalid
  */
+__extension__
 int
 rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature);

-- 
2.1.4

[dpdk-dev] [PATCH v3 07/11] lib: add missing include dependencies

[Adrien Mazarguil]

Exported header files for use by applications should be self sufficient and
allow out of order inclusion. Moreover, they must include all the system
headers they need for types and macros.

This commit prevents the following errors:

 error: `RTE_MAX_LCORE' undeclared here (not in a function)
 error: `RTE_LPM_VALID_EXT_ENTRY_BITMASK' undeclared
  (first use in this function)
 error: #error "Unsupported cache line size"
 error: `asm' undeclared (first use in this function)
 error: implicit declaration of function `[...]'
 error: unknown type name `[...]'
 error: field `mac_addr' has incomplete type
 error: `CHAR_BIT' undeclared here (not in a function)
 error: `struct [...]' declared inside parameter list
 error: unknown type name `uint8_t'

Signed-off-by: Adrien Mazarguil 
---
 lib/librte_cfgfile/rte_cfgfile.h  | 2 ++
 lib/librte_cmdline/cmdline.h  | 1 +
 lib/librte_cmdline/cmdline_parse_portlist.h   | 1 +
 lib/librte_cmdline/cmdline_socket.h   | 3 +++
 lib/librte_eal/common/include/arch/arm/rte_byteorder.h| 2 ++
 lib/librte_eal/common/include/arch/arm/rte_prefetch_32.h  | 1 +
 lib/librte_eal/common/include/arch/arm/rte_prefetch_64.h  | 1 +
 lib/librte_eal/common/include/arch/arm/rte_vect.h | 1 +
 lib/librte_eal/common/include/arch/ppc_64/rte_atomic.h| 1 +
 lib/librte_eal/common/include/arch/ppc_64/rte_byteorder.h | 1 +
 lib/librte_eal/common/include/arch/ppc_64/rte_prefetch.h  | 1 +
 lib/librte_eal/common/include/arch/x86/rte_atomic.h   | 2 ++
 lib/librte_eal/common/include/arch/x86/rte_atomic_32.h| 6 ++
 lib/librte_eal/common/include/arch/x86/rte_atomic_64.h| 8 
 lib/librte_eal/common/include/arch/x86/rte_byteorder.h| 2 ++
 lib/librte_eal/common/include/arch/x86/rte_byteorder_32.h | 7 +++
 lib/librte_eal/common/include/arch/x86/rte_byteorder_64.h | 7 +++
 lib/librte_eal/common/include/arch/x86/rte_prefetch.h | 1 +
 lib/librte_eal/common/include/arch/x86/rte_rtm.h  | 1 +
 lib/librte_eal/common/include/arch/x86/rte_vect.h | 2 ++
 lib/librte_eal/common/include/generic/rte_atomic.h| 1 +
 lib/librte_eal/common/include/generic/rte_byteorder.h | 2 ++
 lib/librte_eal/common/include/rte_eal.h   | 1 +
 lib/librte_eal/common/include/rte_memory.h| 2 ++
 lib/librte_eal/common/include/rte_time.h  | 8 
 lib/librte_eal/common/include/rte_version.h   | 1 +
 lib/librte_ether/rte_dev_info.h   | 2 ++
 lib/librte_ether/rte_eth_ctrl.h   | 4 
 lib/librte_lpm/rte_lpm_neon.h | 1 +
 lib/librte_lpm/rte_lpm_sse.h  | 1 +
 lib/librte_pdump/rte_pdump.h  | 4 
 lib/librte_reorder/rte_reorder.h  | 2 ++
 lib/librte_sched/rte_bitmap.h | 1 +
 lib/librte_sched/rte_reciprocal.h | 2 ++
 lib/librte_sched/rte_sched_common.h   | 1 +
 35 files changed, 84 insertions(+)

diff --git a/lib/librte_cfgfile/rte_cfgfile.h b/lib/librte_cfgfile/rte_cfgfile.h
index f649836..e81a5a2 100644
--- a/lib/librte_cfgfile/rte_cfgfile.h
+++ b/lib/librte_cfgfile/rte_cfgfile.h
@@ -34,6 +34,8 @@
 #ifndef __INCLUDE_RTE_CFGFILE_H__
 #define __INCLUDE_RTE_CFGFILE_H__

+#include 
+
 #ifdef __cplusplus
 extern "C" {
 #endif
diff --git a/lib/librte_cmdline/cmdline.h b/lib/librte_cmdline/cmdline.h
index 2578ca8..65d73b0 100644
--- a/lib/librte_cmdline/cmdline.h
+++ b/lib/librte_cmdline/cmdline.h
@@ -63,6 +63,7 @@

 #include 
 #include 
+#include 

 /**
  * @file
diff --git a/lib/librte_cmdline/cmdline_parse_portlist.h 
b/lib/librte_cmdline/cmdline_parse_portlist.h
index 73d70e0..058df3e 100644
--- a/lib/librte_cmdline/cmdline_parse_portlist.h
+++ b/lib/librte_cmdline/cmdline_parse_portlist.h
@@ -61,6 +61,7 @@
 #ifndef _PARSE_PORTLIST_H_
 #define _PARSE_PORTLIST_H_

+#include 
 #include 

 #ifdef __cplusplus
diff --git a/lib/librte_cmdline/cmdline_socket.h 
b/lib/librte_cmdline/cmdline_socket.h
index 8cc2dfb..aa6068e 100644
--- a/lib/librte_cmdline/cmdline_socket.h
+++ b/lib/librte_cmdline/cmdline_socket.h
@@ -61,6 +61,9 @@
 #ifndef _CMDLINE_SOCKET_H_
 #define _CMDLINE_SOCKET_H_

+#include 
+#include 
+
 #ifdef __cplusplus
 extern "C" {
 #endif
diff --git a/lib/librte_eal/common/include/arch/arm/rte_byteorder.h 
b/lib/librte_eal/common/include/arch/arm/rte_byteorder.h
index 3f2dd1f..1b312b3 100644
--- a/lib/librte_eal/common/include/arch/arm/rte_byteorder.h
+++ b/lib/librte_eal/common/include/arch/arm/rte_byteorder.h
@@ -41,6 +41,8 @@
 extern "C" {
 #endif

+#include 
+#include 
 #include "generic/rte_byteorder.h"

 /* fix missing __builtin_bswap16 for gcc older then 4.8 */
diff --git a/lib/librte_eal/common/include/arch/arm/rte_prefetch_32.h 
b/lib/librte_eal/common/include/arch/arm/rte_prefetch_32.h
index 

[dpdk-dev] [PATCH v3 06/11] lib: work around unnamed structs/unions

[Adrien Mazarguil]

Exported header files used by applications should allow the strictest
compiler flags. Language extensions used in many places must be explicitly
marked to avoid warnings and compilation failures.

Unnamed structs/unions are allowed since C11, however many compiler
versions do not use this mode by default.

This commit prevents the following errors:

 error: ISO C99 doesn't support unnamed structs/unions
 error: struct has no named members

Signed-off-by: Adrien Mazarguil 
---
 lib/librte_cryptodev/rte_crypto.h | 2 ++
 lib/librte_cryptodev/rte_crypto_sym.h | 3 +++
 lib/librte_cryptodev/rte_cryptodev.h  | 4 
 lib/librte_cryptodev/rte_cryptodev_pmd.h  | 2 ++
 lib/librte_eal/common/include/arch/ppc_64/rte_cycles.h| 2 ++
 lib/librte_eal/common/include/arch/x86/rte_atomic_32.h| 3 +++
 lib/librte_eal/common/include/arch/x86/rte_cycles.h   | 2 ++
 lib/librte_eal/common/include/rte_common.h| 7 +++
 lib/librte_eal/common/include/rte_devargs.h   | 1 +
 lib/librte_eal/common/include/rte_interrupts.h| 2 ++
 lib/librte_eal/common/include/rte_memory.h| 1 +
 lib/librte_eal/common/include/rte_memzone.h   | 2 ++
 lib/librte_eal/linuxapp/eal/include/exec-env/rte_interrupts.h | 1 +
 lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h | 4 
 lib/librte_hash/rte_thash.h   | 3 +++
 lib/librte_lpm/rte_lpm.h  | 1 +
 lib/librte_mbuf/rte_mbuf.h| 5 +
 lib/librte_mempool/rte_mempool.h  | 2 ++
 lib/librte_pipeline/rte_pipeline.h| 2 ++
 lib/librte_timer/rte_timer.h  | 2 ++
 20 files changed, 51 insertions(+)

diff --git a/lib/librte_cryptodev/rte_crypto.h 
b/lib/librte_cryptodev/rte_crypto.h
index 5bc3eaa..9019518 100644
--- a/lib/librte_cryptodev/rte_crypto.h
+++ b/lib/librte_cryptodev/rte_crypto.h
@@ -48,6 +48,7 @@ extern "C" {
 #include 
 #include 
 #include 
+#include 

 #include "rte_crypto_sym.h"

@@ -111,6 +112,7 @@ struct rte_crypto_op {
void *opaque_data;
/**< Opaque pointer for user data */

+   RTE_STD_C11
union {
struct rte_crypto_sym_op *sym;
/**< Symmetric operation parameters */
diff --git a/lib/librte_cryptodev/rte_crypto_sym.h 
b/lib/librte_cryptodev/rte_crypto_sym.h
index d9bd821..8178e5a 100644
--- a/lib/librte_cryptodev/rte_crypto_sym.h
+++ b/lib/librte_cryptodev/rte_crypto_sym.h
@@ -51,6 +51,7 @@ extern "C" {
 #include 
 #include 
 #include 
+#include 


 /** Symmetric Cipher Algorithms */
@@ -333,6 +334,7 @@ struct rte_crypto_sym_xform {
/**< next xform in chain */
enum rte_crypto_sym_xform_type type
; /**< xform type */
+   RTE_STD_C11
union {
struct rte_crypto_auth_xform auth;
/**< Authentication / hash xform */
@@ -371,6 +373,7 @@ struct rte_crypto_sym_op {

enum rte_crypto_sym_op_sess_type sess_type;

+   RTE_STD_C11
union {
struct rte_cryptodev_sym_session *session;
/**< Handle for the initialised session context */
diff --git a/lib/librte_cryptodev/rte_cryptodev.h 
b/lib/librte_cryptodev/rte_cryptodev.h
index 7991add..be9a544 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -48,6 +48,7 @@ extern "C" {
 #include "rte_kvargs.h"
 #include "rte_crypto.h"
 #include "rte_dev.h"
+#include 

 #define CRYPTODEV_NAME_NULL_PMD("cryptodev_null_pmd")
 /**< Null crypto PMD device name */
@@ -104,6 +105,7 @@ extern const char **rte_cyptodev_names;
 struct rte_cryptodev_symmetric_capability {
enum rte_crypto_sym_xform_type xform_type;
/**< Transform type : Authentication / Cipher */
+   RTE_STD_C11
union {
struct {
enum rte_crypto_auth_algorithm algo;
@@ -177,6 +179,7 @@ struct rte_cryptodev_capabilities {
enum rte_crypto_op_type op;
/**< Operation type */

+   RTE_STD_C11
union {
struct rte_cryptodev_symmetric_capability sym;
/**< Symmetric operation capability parameters */
@@ -751,6 +754,7 @@ rte_cryptodev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,

 /** Cryptodev symmetric crypto session */
 struct rte_cryptodev_sym_session {
+   RTE_STD_C11
struct {
uint8_t dev_id;
/**< Device Id */
diff --git a/lib/librte_cryptodev/rte_cryptodev_pmd.h 
b/lib/librte_cryptodev/rte_cryptodev_pmd.h
index 3a3845c..cf08a50 100644
--- a/lib/librte_cryptodev/rte_cryptodev_pmd.h
+++ b/lib/librte_cryptodev/rte_cryptodev_pmd.h
@@ -52,6 +52,7 @@ extern "C" {
 #include 
 #include 
 #include 
+#include 

 #include 

[dpdk-dev] [PATCH v3 05/11] lib: work around structs with no members

[Adrien Mazarguil]

Exported header files used by applications should allow the strictest
compiler flags. Language extensions used in many places must be explicitly
marked or removed to avoid warnings and compilation failures.

This commit prevents the following errors:

 error: struct has no members

Signed-off-by: Adrien Mazarguil 
---
 lib/librte_mempool/rte_mempool.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
index fb7052e..fc33db8 100644
--- a/lib/librte_mempool/rte_mempool.h
+++ b/lib/librte_mempool/rte_mempool.h
@@ -169,6 +169,7 @@ STAILQ_HEAD(rte_mempool_objhdr_list, rte_mempool_objhdr);
  * In debug mode, each object stored in mempools are suffixed by this
  * trailer structure containing a cookie preventing memory corruptions.
  */
+__extension__
 struct rte_mempool_objtlr {
 #ifdef RTE_LIBRTE_MEMPOOL_DEBUG
uint64_t cookie; /**< Debug cookie. */
-- 
2.1.4

[dpdk-dev] [PATCH v3 04/11] lib: work around nonstandard bit-fields

[Adrien Mazarguil]

Exported header files used by applications should allow the strictest
compiler flags. Language extensions used in many places must be explicitly
marked or removed to avoid warnings and compilation failures.

This commit prevents the following errors:

 error: type of bit-field `[...]' is a GCC extension

Note: the standard does not require implementations to issue a diagnostic
message with these, and such errors do not occur with recent GCC or clang
versions. However, GCC 4.7 is still common and using the extension keyword
is easier than checking compiler version.

Signed-off-by: Adrien Mazarguil 
---
 lib/librte_cryptodev/rte_cryptodev.h  | 2 ++
 lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h | 1 +
 lib/librte_ether/rte_ethdev.h | 4 
 lib/librte_kni/rte_kni.h  | 1 +
 lib/librte_lpm/rte_lpm.h  | 4 
 lib/librte_mbuf/rte_mbuf.h| 1 +
 6 files changed, 13 insertions(+)

diff --git a/lib/librte_cryptodev/rte_cryptodev.h 
b/lib/librte_cryptodev/rte_cryptodev.h
index 0123c24..7991add 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -619,6 +619,7 @@ struct rte_cryptodev {
struct rte_cryptodev_cb_list link_intr_cbs;
/**< User application callback for interrupts if present */

+   __extension__
uint8_t attached : 1;
/**< Flag indicating the device is attached */
 } __rte_cache_aligned;
@@ -642,6 +643,7 @@ struct rte_cryptodev_data {
char name[RTE_CRYPTODEV_NAME_MAX_LEN];
/**< Unique identifier name */

+   __extension__
uint8_t dev_started : 1;
/**< Device state: STARTED(1)/STOPPED(0) */

diff --git a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h 
b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
index 7f458a3..2ef0506 100644
--- a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
+++ b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
@@ -159,6 +159,7 @@ struct rte_kni_device_info {
uint16_t group_id;/**< Group ID */
uint32_t core_id; /**< core ID to bind for kernel thread */

+   __extension__
uint8_t force_bind : 1;   /**< Flag for kernel thread binding */

/* mbuf size */
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 0f17323..755f150 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -255,6 +255,7 @@ struct rte_eth_stats {
 /**
  * A structure used to retrieve link-level information of an Ethernet port.
  */
+__extension__
 struct rte_eth_link {
uint32_t link_speed;/**< ETH_SPEED_NUM_ */
uint16_t link_duplex  : 1;  /**< ETH_LINK_[HALF/FULL]_DUPLEX */
@@ -346,6 +347,7 @@ struct rte_eth_rxmode {
enum rte_eth_rx_mq_mode mq_mode;
uint32_t max_rx_pkt_len;  /**< Only used if jumbo_frame enabled. */
uint16_t split_hdr_size;  /**< hdr buf size (header_split enabled).*/
+   __extension__
uint16_t header_split : 1, /**< Header Split enable. */
hw_ip_checksum   : 1, /**< IP/UDP/TCP checksum offload enable. 
*/
hw_vlan_filter   : 1, /**< VLAN filter enable. */
@@ -645,6 +647,7 @@ struct rte_eth_txmode {

/* For i40e specifically */
uint16_t pvid;
+   __extension__
uint8_t hw_vlan_reject_tagged : 1,
/**< If set, reject sending out tagged pkts */
hw_vlan_reject_untagged : 1,
@@ -1696,6 +1699,7 @@ struct rte_eth_dev_data {
struct ether_addr* hash_mac_addrs;
/** Device Ethernet MAC addresses of hash filtering. */
uint8_t port_id;   /**< Device [external] port identifier. */
+   __extension__
uint8_t promiscuous   : 1, /**< RX promiscuous mode ON(1) / OFF(0). */
scattered_rx : 1,  /**< RX of scattered packets is ON(1) / 
OFF(0) */
all_multicast : 1, /**< RX all multicast mode ON(1) / OFF(0). */
diff --git a/lib/librte_kni/rte_kni.h b/lib/librte_kni/rte_kni.h
index 7363e6c..5f6f9e4 100644
--- a/lib/librte_kni/rte_kni.h
+++ b/lib/librte_kni/rte_kni.h
@@ -88,6 +88,7 @@ struct rte_kni_conf {
struct rte_pci_addr addr;
struct rte_pci_id id;

+   __extension__
uint8_t force_bind : 1; /* Flag to bind kernel thread */
 };

diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
index 79a4593..28668a3 100644
--- a/lib/librte_lpm/rte_lpm.h
+++ b/lib/librte_lpm/rte_lpm.h
@@ -93,6 +93,7 @@ extern "C" {

 #if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
 /** @internal Tbl24 entry structure. */
+__extension__
 struct rte_lpm_tbl_entry_v20 {
/**
 * Stores Next hop (tbl8 or tbl24 when valid_group is not set) or
@@ -116,6 +117,7 @@ struct rte_lpm_tbl_entry_v20 {
uint8_t depth   :6; /**< 

[dpdk-dev] [PATCH v3 03/11] lib: use C99 syntax for zero-size arrays

[Adrien Mazarguil]

Exported header files used by applications should allow the strictest
compiler flags. Language extensions used in many places must be explicitly
marked or removed to avoid warnings and compilation failures.

The extension keyword is used whenever the C99 syntax cannot do it.

This commit prevents the following errors:

 error: ISO C forbids zero-size array `[...]'

Signed-off-by: Adrien Mazarguil 
---
 lib/librte_acl/rte_acl.h  | 2 +-
 lib/librte_cryptodev/rte_cryptodev.h  | 2 +-
 lib/librte_cryptodev/rte_cryptodev_pmd.h  | 2 +-
 lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h | 2 +-
 lib/librte_hash/rte_fbk_hash.h| 2 +-
 lib/librte_ip_frag/rte_ip_frag.h  | 2 +-
 lib/librte_lpm/rte_lpm.h  | 2 +-
 lib/librte_mbuf/rte_mbuf.h| 3 +++
 lib/librte_pipeline/rte_pipeline.h| 2 +-
 lib/librte_ring/rte_ring.h| 2 +-
 lib/librte_sched/rte_bitmap.h | 2 +-
 11 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/lib/librte_acl/rte_acl.h b/lib/librte_acl/rte_acl.h
index 0979a09..c059dc3 100644
--- a/lib/librte_acl/rte_acl.h
+++ b/lib/librte_acl/rte_acl.h
@@ -144,7 +144,7 @@ struct rte_acl_rule_data {
struct rte_acl_field field[fld_num]; \
 }

-RTE_ACL_RULE_DEF(rte_acl_rule, 0);
+RTE_ACL_RULE_DEF(rte_acl_rule,);

 #defineRTE_ACL_RULE_SZ(fld_num)\
(sizeof(struct rte_acl_rule) + sizeof(struct rte_acl_field) * (fld_num))
diff --git a/lib/librte_cryptodev/rte_cryptodev.h 
b/lib/librte_cryptodev/rte_cryptodev.h
index 7768f0a..0123c24 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -759,7 +759,7 @@ struct rte_cryptodev_sym_session {
} __rte_aligned(8);
/**< Public symmetric session details */

-   char _private[0];
+   char _private[];
/**< Private session material */
 };

diff --git a/lib/librte_cryptodev/rte_cryptodev_pmd.h 
b/lib/librte_cryptodev/rte_cryptodev_pmd.h
index 7d049ea..3a3845c 100644
--- a/lib/librte_cryptodev/rte_cryptodev_pmd.h
+++ b/lib/librte_cryptodev/rte_cryptodev_pmd.h
@@ -71,7 +71,7 @@ struct rte_cryptodev_session {
struct rte_mempool *mp;
} __rte_aligned(8);

-   char _private[0];
+   char _private[];
 };

 struct rte_cryptodev_driver;
diff --git a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h 
b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
index 2acdfd9..7f458a3 100644
--- a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
+++ b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
@@ -102,7 +102,7 @@ struct rte_kni_fifo {
volatile unsigned read;  /**< Next position to be read */
unsigned len;/**< Circular buffer length */
unsigned elem_size;  /**< Pointer size - for 32/64 bit OS */
-   void * volatile buffer[0];   /**< The buffer contains mbuf pointers */
+   void *volatile buffer[]; /**< The buffer contains mbuf pointers */
 };

 /*
diff --git a/lib/librte_hash/rte_fbk_hash.h b/lib/librte_hash/rte_fbk_hash.h
index a430961..bd46048 100644
--- a/lib/librte_hash/rte_fbk_hash.h
+++ b/lib/librte_hash/rte_fbk_hash.h
@@ -115,7 +115,7 @@ struct rte_fbk_hash_table {
uint32_t init_val;  /**< For initialising hash function. */

/** A flat table of all buckets. */
-   union rte_fbk_hash_entry t[0];
+   union rte_fbk_hash_entry t[];
 };

 /**
diff --git a/lib/librte_ip_frag/rte_ip_frag.h b/lib/librte_ip_frag/rte_ip_frag.h
index 92cedf2..4c3faad 100644
--- a/lib/librte_ip_frag/rte_ip_frag.h
+++ b/lib/librte_ip_frag/rte_ip_frag.h
@@ -124,7 +124,7 @@ struct rte_ip_frag_tbl {
struct ip_frag_pkt *last; /**< last used entry. */
struct ip_pkt_list lru;   /**< LRU list for table entries. */
struct ip_frag_tbl_stat stat; /**< statistics counters. */
-   struct ip_frag_pkt pkt[0];/**< hash table. */
+   struct ip_frag_pkt pkt[]; /**< hash table. */
 };

 /** IPv6 fragment extension header */
diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
index 2df1d67..79a4593 100644
--- a/lib/librte_lpm/rte_lpm.h
+++ b/lib/librte_lpm/rte_lpm.h
@@ -193,7 +193,7 @@ struct rte_lpm_v20 {
__rte_cache_aligned; /**< LPM tbl24 table. */
struct rte_lpm_tbl_entry_v20 tbl8[RTE_LPM_TBL8_NUM_ENTRIES]
__rte_cache_aligned; /**< LPM tbl8 table. */
-   struct rte_lpm_rule_v20 rules_tbl[0] \
+   struct rte_lpm_rule_v20 rules_tbl[]
__rte_cache_aligned; /**< LPM rules. */
 };

diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 

[dpdk-dev] [PATCH v3 02/11] lib: work around large enum values

[Adrien Mazarguil]

Exported header files used by applications should allow the strictest
compiler flags. Language extensions used in many places must be explicitly
marked or removed to avoid warnings and compilation failures.

This commit prevents the following errors:

 error: ISO C restricts enumerator values to range of `int'

Signed-off-by: Adrien Mazarguil 
---
 lib/librte_eal/common/include/rte_memory.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/librte_eal/common/include/rte_memory.h 
b/lib/librte_eal/common/include/rte_memory.h
index 0661109..6a2b3f1 100644
--- a/lib/librte_eal/common/include/rte_memory.h
+++ b/lib/librte_eal/common/include/rte_memory.h
@@ -54,6 +54,7 @@ extern "C" {

 #include 

+__extension__
 enum rte_page_sizes {
RTE_PGSIZE_4K= 1ULL << 12,
RTE_PGSIZE_64K   = 1ULL << 16,
-- 
2.1.4

[dpdk-dev] [PATCH v3 01/11] lib: work around braced-groups within expressions

[Adrien Mazarguil]

Exported header files used by applications should allow the strictest
compiler flags. Language extensions used in many places must be explicitly
marked or removed to avoid warnings and compilation failures.

This commit prevents the following errors:

 error: ISO C forbids braced-groups within expressions

Signed-off-by: Adrien Mazarguil 
---
 lib/librte_eal/common/include/arch/arm/rte_memcpy_32.h | 3 ++-
 lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h | 3 ++-
 lib/librte_eal/common/include/arch/x86/rte_memcpy.h| 4 ++--
 lib/librte_eal/common/include/arch/x86/rte_vect.h  | 6 --
 lib/librte_eal/common/include/rte_common.h | 6 --
 5 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/lib/librte_eal/common/include/arch/arm/rte_memcpy_32.h 
b/lib/librte_eal/common/include/arch/arm/rte_memcpy_32.h
index da6c233..c3a2619 100644
--- a/lib/librte_eal/common/include/arch/arm/rte_memcpy_32.h
+++ b/lib/librte_eal/common/include/arch/arm/rte_memcpy_32.h
@@ -148,7 +148,8 @@ rte_mov256(uint8_t *dst, const uint8_t *src)
 }

 #define rte_memcpy(dst, src, n)  \
-   ({ (__builtin_constant_p(n)) ?   \
+   __extension__ ({ \
+   (__builtin_constant_p(n)) ?  \
memcpy((dst), (src), (n)) :  \
rte_memcpy_func((dst), (src), (n)); })

diff --git a/lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h 
b/lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h
index acf7aac..ca9d1dc 100644
--- a/lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h
+++ b/lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h
@@ -95,7 +95,8 @@ rte_mov256(uint8_t *dst, const uint8_t *src)
 }

 #define rte_memcpy(dst, src, n)  \
-   ({ (__builtin_constant_p(n)) ?   \
+   __extension__ ({ \
+   (__builtin_constant_p(n)) ?  \
memcpy((dst), (src), (n)) :  \
rte_memcpy_func((dst), (src), (n)); })

diff --git a/lib/librte_eal/common/include/arch/x86/rte_memcpy.h 
b/lib/librte_eal/common/include/arch/x86/rte_memcpy.h
index 413035e..b3bfc23 100644
--- a/lib/librte_eal/common/include/arch/x86/rte_memcpy.h
+++ b/lib/librte_eal/common/include/arch/x86/rte_memcpy.h
@@ -594,7 +594,7 @@ rte_mov256(uint8_t *dst, const uint8_t *src)
  * - __m128i  ~  must be pre-defined
  */
 #define MOVEUNALIGNED_LEFT47_IMM(dst, src, len, offset)
 \
-({ 
 \
+__extension__ ({   
 \
 int tmp;   
 \
 while (len >= 128 + 16 - offset) { 
 \
 xmm0 = _mm_loadu_si128((const __m128i *)((const uint8_t *)src - offset 
+ 0 * 16));  \
@@ -655,7 +655,7 @@ rte_mov256(uint8_t *dst, const uint8_t *src)
  * - __m128i  ~  used in MOVEUNALIGNED_LEFT47_IMM must be 
pre-defined
  */
 #define MOVEUNALIGNED_LEFT47(dst, src, len, offset)   \
-({\
+__extension__ ({  \
 switch (offset) { \
 case 0x01: MOVEUNALIGNED_LEFT47_IMM(dst, src, n, 0x01); break;\
 case 0x02: MOVEUNALIGNED_LEFT47_IMM(dst, src, n, 0x02); break;\
diff --git a/lib/librte_eal/common/include/arch/x86/rte_vect.h 
b/lib/librte_eal/common/include/arch/x86/rte_vect.h
index b698797..2836f2c 100644
--- a/lib/librte_eal/common/include/arch/x86/rte_vect.h
+++ b/lib/librte_eal/common/include/arch/x86/rte_vect.h
@@ -106,7 +106,8 @@ typedef union rte_ymm {
 #endif /* __AVX__ */

 #ifdef RTE_ARCH_I686
-#define _mm_cvtsi128_si64(a) ({ \
+#define _mm_cvtsi128_si64(a)\
+__extension__ ({\
rte_xmm_t m;\
m.x = (a);  \
(m.u64[0]); \
@@ -117,7 +118,8 @@ typedef union rte_ymm {
  * Prior to version 12.1 icc doesn't support _mm_set_epi64x.
  */
 #if (defined(__ICC) && __ICC < 1210)
-#define _mm_set_epi64x(a, b)  ({ \
+#define _mm_set_epi64x(a, b) \
+__extension__ ({ \
rte_xmm_t m; \
m.u64[0] = b;\
m.u64[1] = a;\
diff --git a/lib/librte_eal/common/include/rte_common.h 
b/lib/librte_eal/common/include/rte_common.h
index 332f2a4..477472b 100644
--- a/lib/librte_eal/common/include/rte_common.h
+++ b/lib/librte_eal/common/include/rte_common.h
@@ -268,7 +268,8 @@ rte_align64pow2(uint64_t v)
 /**
  * Macro to return the minimum of two numbers
  */
-#define RTE_MIN(a, b) ({ \
+#define RTE_MIN(a, b) \
+   __extension__ ({ \
typeof (a) _a = (a); \

[dpdk-dev] [PATCH v3 00/11] Fix build errors related to exported headers

[Adrien Mazarguil]

DPDK uses GNU C language extensions in most of its code base. This is fine
for internal source files whose compilation flags are controlled by DPDK,
however user applications that use exported "public" headers may experience
compilation failures when enabling strict error/standard checks (-std and
-pedantic for instance).

Exported headers are installed system-wide and must be as clean as possible
so applications do not have to resort to workarounds.

This patchset affects exported headers only, compilation problems are
addressed as follows:

- Adding the __extension__ keyword to nonstandard constructs (same method
  as existing libraries when there is no other choice).
- Adding the __extension__ keyword to C11 constructs to remain compatible
  with pure C99.
- Adding missing includes so exported files can be included out of order
  and on their own.
- Fixing GNU printf-like variadic macros as there is no magic keyword for
  these.

Changes in v3:

- Fixed compilation issue on ARM and POWER8 due to missing parenthesis.
- Added bit-field fix for rte_kni.h.

Changes in v2:

- Rebased on top of the current HEAD.
- Added script to check headers automatically (check-includes.sh), for both
  C and C++ compilation.
- Updated test-build.sh to use it.
- Fixed consistency of new #include directives, now inside extern "C"
  blocks for files that already do that (Jan, fixing these was too much
  work for this patchset so I settled on this solution in the meantime).
- Updated headlines to address check-git-log.sh complaints.

Adrien Mazarguil (11):
  lib: work around braced-groups within expressions
  lib: work around large enum values
  lib: use C99 syntax for zero-size arrays
  lib: work around nonstandard bit-fields
  lib: work around structs with no members
  lib: work around unnamed structs/unions
  lib: add missing include dependencies
  lib: work around forward reference to enum types
  lib: remove named variadic macros in exported headers
  lib: hide static functions never defined
  scripts: check compilation of exported header files

 MAINTAINERS |   1 +
 lib/librte_acl/rte_acl.h|   2 +-
 lib/librte_cfgfile/rte_cfgfile.h|   2 +
 lib/librte_cmdline/cmdline.h|   1 +
 lib/librte_cmdline/cmdline_parse_portlist.h |   1 +
 lib/librte_cmdline/cmdline_socket.h |   3 +
 lib/librte_cryptodev/rte_crypto.h   |   2 +
 lib/librte_cryptodev/rte_crypto_sym.h   |   3 +
 lib/librte_cryptodev/rte_cryptodev.h|  40 ++-
 lib/librte_cryptodev/rte_cryptodev_pmd.h|   6 +-
 .../common/include/arch/arm/rte_byteorder.h |   2 +
 .../common/include/arch/arm/rte_memcpy_32.h |   3 +-
 .../common/include/arch/arm/rte_prefetch_32.h   |   1 +
 .../common/include/arch/arm/rte_prefetch_64.h   |   1 +
 .../common/include/arch/arm/rte_vect.h  |   1 +
 .../common/include/arch/ppc_64/rte_atomic.h |   1 +
 .../common/include/arch/ppc_64/rte_byteorder.h  |   1 +
 .../common/include/arch/ppc_64/rte_cycles.h |   2 +
 .../common/include/arch/ppc_64/rte_memcpy.h |   3 +-
 .../common/include/arch/ppc_64/rte_prefetch.h   |   1 +
 .../common/include/arch/x86/rte_atomic.h|   2 +
 .../common/include/arch/x86/rte_atomic_32.h |   9 +
 .../common/include/arch/x86/rte_atomic_64.h |   8 +
 .../common/include/arch/x86/rte_byteorder.h |   2 +
 .../common/include/arch/x86/rte_byteorder_32.h  |   7 +
 .../common/include/arch/x86/rte_byteorder_64.h  |   7 +
 .../common/include/arch/x86/rte_cycles.h|   2 +
 .../common/include/arch/x86/rte_memcpy.h|   4 +-
 .../common/include/arch/x86/rte_prefetch.h  |   1 +
 .../common/include/arch/x86/rte_rtm.h   |   1 +
 .../common/include/arch/x86/rte_vect.h  |   8 +-
 .../common/include/generic/rte_atomic.h |   1 +
 .../common/include/generic/rte_byteorder.h  |   2 +
 .../common/include/generic/rte_cpuflags.h   |   3 +
 .../common/include/generic/rte_memcpy.h |   4 +
 lib/librte_eal/common/include/rte_common.h  |  22 +-
 lib/librte_eal/common/include/rte_devargs.h |   1 +
 lib/librte_eal/common/include/rte_eal.h |   1 +
 lib/librte_eal/common/include/rte_interrupts.h  |   2 +
 lib/librte_eal/common/include/rte_memory.h  |   4 +
 lib/librte_eal/common/include/rte_memzone.h |   2 +
 lib/librte_eal/common/include/rte_time.h|   8 +
 lib/librte_eal/common/include/rte_version.h |   1 +
 .../eal/include/exec-env/rte_interrupts.h   |   1 +
 .../eal/include/exec-env/rte_kni_common.h   |   7 +-
 lib/librte_ether/rte_dev_info.h |   2 +
 lib/librte_ether/rte_eth_ctrl.h |   4 +
 lib/librte_ether/rte_ethdev.h   |   4 +
 lib/librte_hash/rte_fbk_hash.h  |   2 +-
 lib/librte_hash/rte_thash.h |   3 +
 lib/librte_ip_frag/rte_ip_frag.h|   2 +-
 

[dpdk-dev] [PATCH 05/18] mbuf: add function to get packet type from data

[Olivier Matz]

Hi Cunming,

Thank you for your feedback.

On 07/07/2016 10:19 AM, Liang, Cunming wrote:
> Hi Olivier,
> 
>> -Original Message-
>> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
>> Sent: Wednesday, July 06, 2016 3:43 PM
>> To: Liang, Cunming ; dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH 05/18] mbuf: add function to get packet type
>> from data
>>
>> Hi Cunming,
>>
>> On 07/06/2016 08:44 AM, Liang, Cunming wrote:
>>> Hi Olivier,
>>>
>>> On 7/5/2016 11:41 PM, Olivier Matz wrote:
 Introduce the function rte_pktmbuf_get_ptype() that parses a
 mbuf and returns its packet type. For now, the following packet
 types are parsed:
 L2: Ether
 L3: IPv4, IPv6
 L4: TCP, UDP, SCTP

 The goal here is to provide a reference implementation for packet type
 parsing. This function will be used by testpmd in next commits, allowing
 to compare its result with the value given by the hardware.

 This function will also be useful when implementing Rx offload support
 in virtio pmd. Indeed, the virtio protocol gives the csum start and
 offset, but it does not give the L4 protocol nor it tells if the
 checksum is relevant for inner or outer. This information has to be
 known to properly set the ol_flags in mbuf.

 Signed-off-by: Didier Pallard 
 Signed-off-by: Jean Dao 
 Signed-off-by: Olivier Matz 
 ---
   doc/guides/rel_notes/release_16_11.rst |   5 +
   lib/librte_mbuf/Makefile   |   5 +-
   lib/librte_mbuf/rte_mbuf_ptype.c   | 234
 +
   lib/librte_mbuf/rte_mbuf_ptype.h   |  43 ++
   lib/librte_mbuf/rte_mbuf_version.map   |   1 +
   5 files changed, 286 insertions(+), 2 deletions(-)
   create mode 100644 lib/librte_mbuf/rte_mbuf_ptype.c

 [...]
 +
 +/* parse mbuf data to get packet type */
 +uint32_t rte_pktmbuf_get_ptype(const struct rte_mbuf *m,
 +struct rte_mbuf_hdr_lens *hdr_lens)
 +{
 +struct rte_mbuf_hdr_lens local_hdr_lens;
 +const struct ether_hdr *eh;
 +struct ether_hdr eh_copy;
 +uint32_t pkt_type = RTE_PTYPE_L2_ETHER;
 +uint32_t off = 0;
 +uint16_t proto;
 +
 +if (hdr_lens == NULL)
 +hdr_lens = _hdr_lens;
 +
 +eh = rte_pktmbuf_read(m, off, sizeof(*eh), _copy);
 +if (unlikely(eh == NULL))
 +return 0;
 +proto = eh->ether_type;
 +off = sizeof(*eh);
 +hdr_lens->l2_len = off;
 +
 +if (proto == rte_cpu_to_be_16(ETHER_TYPE_IPv4)) {
 +const struct ipv4_hdr *ip4h;
 +struct ipv4_hdr ip4h_copy;
 +
 +ip4h = rte_pktmbuf_read(m, off, sizeof(*ip4h), _copy);
 +if (unlikely(ip4h == NULL))
 +return pkt_type;
 +
 +pkt_type |= ptype_l3_ip(ip4h->version_ihl);
 +hdr_lens->l3_len = ip4_hlen(ip4h);
 +off += hdr_lens->l3_len;
 +if (ip4h->fragment_offset &
 +rte_cpu_to_be_16(IPV4_HDR_OFFSET_MASK |
 +IPV4_HDR_MF_FLAG)) {
 +pkt_type |= RTE_PTYPE_L4_FRAG;
 +hdr_lens->l4_len = 0;
 +return pkt_type;
 +}
 +proto = ip4h->next_proto_id;
 +pkt_type |= ptype_l4(proto);
 +} else if (proto == rte_cpu_to_be_16(ETHER_TYPE_IPv6)) {
 +const struct ipv6_hdr *ip6h;
 +struct ipv6_hdr ip6h_copy;
 +int frag = 0;
 +
 +ip6h = rte_pktmbuf_read(m, off, sizeof(*ip6h), _copy);
 +if (unlikely(ip6h == NULL))
 +return pkt_type;
 +
 +proto = ip6h->proto;
 +hdr_lens->l3_len = sizeof(*ip6h);
 +off += hdr_lens->l3_len;
 +pkt_type |= ptype_l3_ip6(proto);
 +if ((pkt_type & RTE_PTYPE_L3_MASK) == RTE_PTYPE_L3_IPV6_EXT) {
 +proto = skip_ip6_ext(proto, m, , );
 +hdr_lens->l3_len = off - hdr_lens->l2_len;
 +}
 +if (proto == 0)
 +return pkt_type;
 +if (frag) {
 +pkt_type |= RTE_PTYPE_L4_FRAG;
 +hdr_lens->l4_len = 0;
 +return pkt_type;
 +}
 +pkt_type |= ptype_l4(proto);
 +}
 +
 +if ((pkt_type & RTE_PTYPE_L4_MASK) == RTE_PTYPE_L4_UDP) {
 +hdr_lens->l4_len = sizeof(struct udp_hdr);
 +} else if ((pkt_type & RTE_PTYPE_L4_MASK) == RTE_PTYPE_L4_TCP) {
 +const struct tcp_hdr *th;
 +struct tcp_hdr th_copy;
 +
 +th = rte_pktmbuf_read(m, off, sizeof(*th), _copy);
 +if (unlikely(th == NULL))
 +return pkt_type & (RTE_PTYPE_L2_MASK |
 +RTE_PTYPE_L3_MASK);
 +hdr_lens->l4_len = (th->data_off & 0xf0) >> 2;
 +} else if ((pkt_type & 

[dpdk-dev] [PATCH 11/11] maintainers: add section for pmdinfo

[Thomas Monjalon]

Neil,

I would gladly drop this patch from the series if you send a similar one
with your name as maintainer.

Thanks


2016-07-07 17:36, Thomas Monjalon:
> The author of this feature is Neil Horman.
> 
> Signed-off-by: Thomas Monjalon 
> ---
> +Driver information
> +F: buildtools/pmdinfogen/
> +F: tools/pmdinfo.py

[dpdk-dev] [PATCH 10/11] doc: fix syntax in pmdinfogen guide

[Thomas Monjalon]

2016-07-07 17:36, Thomas Monjalon:
> Sphynx reports this error:
> 
> doc/guides/prog_guide/dev_kit_build_system.rst:337: WARNING:
> Pygments lexer name u'C' is not known
> 
> Fixes: 737ddf3fb ("doc: add prog guide section documenting pmdinfo script")
> 
> Signed-off-by: Thomas Monjalon 

Reported-by: Bernard Iremonger 

[dpdk-dev] [PATCH 09/11] eal: move PCI table macro

[Thomas Monjalon]

2016-07-07 17:36, Thomas Monjalon:
> Remove include of rte_pci.h in the generic header rte_dev.h
> and move the macro DRIVER_REGISTER_PCI_TABLE in rte_pci.h.
> 
> Fixes: cb6696d22023 ("drivers: update registration macro usage")
> 
> Signed-off-by: Thomas Monjalon 

Suggested-by: David Marchand 

[dpdk-dev] [PATCH 11/11] maintainers: add section for pmdinfo

[Thomas Monjalon]

The author of this feature is Neil Horman.

Signed-off-by: Thomas Monjalon 
---
 MAINTAINERS | 4 
 1 file changed, 4 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index a59191e..f996c2e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -68,6 +68,10 @@ F: lib/librte_compat/
 F: doc/guides/rel_notes/deprecation.rst
 F: scripts/validate-abi.sh

+Driver information
+F: buildtools/pmdinfogen/
+F: tools/pmdinfo.py
+

 Environment Abstraction Layer
 -
-- 
2.7.0

[dpdk-dev] [PATCH 10/11] doc: fix syntax in pmdinfogen guide

[Thomas Monjalon]

Sphynx reports this error:

doc/guides/prog_guide/dev_kit_build_system.rst:337: WARNING:
Pygments lexer name u'C' is not known

Fixes: 737ddf3fb ("doc: add prog guide section documenting pmdinfo script")

Signed-off-by: Thomas Monjalon 
---
 doc/guides/prog_guide/dev_kit_build_system.rst | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/doc/guides/prog_guide/dev_kit_build_system.rst 
b/doc/guides/prog_guide/dev_kit_build_system.rst
index 1dc1388..18a3010 100644
--- a/doc/guides/prog_guide/dev_kit_build_system.rst
+++ b/doc/guides/prog_guide/dev_kit_build_system.rst
@@ -319,8 +319,7 @@ instance the macro:

 .. code-block:: c

-PMD_REGISTER_DRIVER(drv, name)
-
+   PMD_REGISTER_DRIVER(drv, name)

 Creates the following symbol:

@@ -334,7 +333,7 @@ can be exported from the object file and used to produce a 
hardware support
 description, that pmdinfogen then encodes into a json formatted string in the
 following format:

-.. code-block:: C
+.. code-block:: c

static char ="PMD_INFO_STRING=\"{'name' : '', 
...}\"";

-- 
2.7.0

[dpdk-dev] [PATCH 09/11] eal: move PCI table macro

[Thomas Monjalon]

Remove include of rte_pci.h in the generic header rte_dev.h
and move the macro DRIVER_REGISTER_PCI_TABLE in rte_pci.h.

Fixes: cb6696d22023 ("drivers: update registration macro usage")

Signed-off-by: Thomas Monjalon 
---
 lib/librte_eal/common/include/rte_dev.h | 6 +-
 lib/librte_eal/common/include/rte_pci.h | 5 +
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/lib/librte_eal/common/include/rte_dev.h 
b/lib/librte_eal/common/include/rte_dev.h
index e6f0d4c..68ca7ef 100644
--- a/lib/librte_eal/common/include/rte_dev.h
+++ b/lib/librte_eal/common/include/rte_dev.h
@@ -48,7 +48,7 @@ extern "C" {

 #include 
 #include 
-#include 
+
 #include 

 __attribute__((format(printf, 2, 0)))
@@ -195,10 +195,6 @@ DRIVER_EXPORT_NAME(nm, __COUNTER__)

 #define DRV_EXP_TAG(name, tag) __##name##_##tag

-#define DRIVER_REGISTER_PCI_TABLE(name, table) \
-static const char DRV_EXP_TAG(name, pci_tbl_export)[] __attribute__((used)) = \
-RTE_STR(table)
-
 #define DRIVER_REGISTER_PARAM_STRING(name, str) \
 static const char DRV_EXP_TAG(name, param_string_export)[] \
 __attribute__((used)) = str
diff --git a/lib/librte_eal/common/include/rte_pci.h 
b/lib/librte_eal/common/include/rte_pci.h
index fa74962..3b0d26a 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -188,6 +188,11 @@ struct rte_pci_device {
.subsystem_device_id = PCI_ANY_ID
 #endif

+#define DRIVER_REGISTER_PCI_TABLE(name, table) \
+static const char __##name##_pci_tbl_export[] \
+   __attribute__((used)) = \
+   RTE_STR(table)
+
 struct rte_pci_driver;

 /**
-- 
2.7.0

[dpdk-dev] [PATCH 08/11] pmdinfogen: fix usage message

[Thomas Monjalon]

The name of the tool is pmdinfogen.

Fixes: 98b0fdb0ffc6 ("pmdinfogen: add buildtools and pmdinfogen utility")

Signed-off-by: Thomas Monjalon 
---
 buildtools/pmdinfogen/pmdinfogen.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/buildtools/pmdinfogen/pmdinfogen.c 
b/buildtools/pmdinfogen/pmdinfogen.c
index beb06f1..1b7b931 100644
--- a/buildtools/pmdinfogen/pmdinfogen.c
+++ b/buildtools/pmdinfogen/pmdinfogen.c
@@ -398,7 +398,7 @@ int main(int argc, char **argv)

if (argc < 3) {
fprintf(stderr,
-   "usage: pmdinfo  \n");
+   "usage: pmdinfogen  \n");
exit(127);
}
parse_elf(, argv[1]);
-- 
2.7.0

[dpdk-dev] [PATCH 07/11] pmdinfogen: fix build warnings

[Thomas Monjalon]

When compiled with a standard clang, pmdinfogen can raise a warning:
buildtools/pmdinfogen/pmdinfogen.c:365:1: warning:
control reaches end of non-void function

Actually there can be more warnings with stricter compilers.
In order to catch them early and fix most of them, the DPDK standard flags
WERROR_FLAGS are used.

The warnings fixed are:
no previous prototype for ...
no return statement in function returning non-void
variable ?secstrings? set but not used
?sec_name? defined but not used
?get_symbol_index? defined but not used
pointer of type ?void *? used in arithmetic

Fixes: 98b0fdb0ffc6 ("pmdinfogen: add buildtools and pmdinfogen utility")

Signed-off-by: Thomas Monjalon 
---
 buildtools/pmdinfogen/Makefile |  4 +--
 buildtools/pmdinfogen/pmdinfogen.c | 58 --
 2 files changed, 20 insertions(+), 42 deletions(-)

diff --git a/buildtools/pmdinfogen/Makefile b/buildtools/pmdinfogen/Makefile
index 125901b..3885d3b 100644
--- a/buildtools/pmdinfogen/Makefile
+++ b/buildtools/pmdinfogen/Makefile
@@ -41,9 +41,9 @@ HOSTAPP = pmdinfogen
 #
 SRCS-y += pmdinfogen.c

-HOST_EXTRA_CFLAGS += -g -I${RTE_OUTPUT}/include
+HOST_CFLAGS += $(WERROR_FLAGS) -g
+HOST_CFLAGS += -I$(RTE_OUTPUT)/include

 DEPDIRS-y += lib/librte_eal

 include $(RTE_SDK)/mk/rte.hostapp.mk
-
diff --git a/buildtools/pmdinfogen/pmdinfogen.c 
b/buildtools/pmdinfogen/pmdinfogen.c
index 0947dc6..beb06f1 100644
--- a/buildtools/pmdinfogen/pmdinfogen.c
+++ b/buildtools/pmdinfogen/pmdinfogen.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "pmdinfogen.h"

 #ifdef RTE_ARCH_64
@@ -32,7 +33,7 @@ static const char *sym_name(struct elf_info *elf, Elf_Sym 
*sym)
return "(unknown)";
 }

-void *grab_file(const char *filename, unsigned long *size)
+static void *grab_file(const char *filename, unsigned long *size)
 {
struct stat st;
void *map = MAP_FAILED;
@@ -59,7 +60,7 @@ failed:
   * spaces in the beginning of the line is trimmed away.
   * Return a pointer to a static buffer.
   **/
-void release_file(void *file, unsigned long size)
+static void release_file(void *file, unsigned long size)
 {
munmap(file, size);
 }
@@ -67,9 +68,8 @@ void release_file(void *file, unsigned long size)

 static void *get_sym_value(struct elf_info *info, const Elf_Sym *sym)
 {
-   void *ptr = (void *)info->hdr + info->sechdrs[sym->st_shndx].sh_offset;
-
-   return (void *)(ptr + sym->st_value);
+   return RTE_PTR_ADD(info->hdr,
+   info->sechdrs[sym->st_shndx].sh_offset + sym->st_value);
 }

 static Elf_Sym *find_sym_in_symtab(struct elf_info *info,
@@ -95,7 +95,6 @@ static int parse_elf(struct elf_info *info, const char 
*filename)
Elf_Ehdr *hdr;
Elf_Shdr *sechdrs;
Elf_Sym  *sym;
-   const char *secstrings;
int endian;
unsigned int symtab_idx = ~0U, symtab_shndx_idx = ~0U;

@@ -140,7 +139,7 @@ static int parse_elf(struct elf_info *info, const char 
*filename)
hdr->e_shnum = TO_NATIVE(endian, 16, hdr->e_shnum);
hdr->e_shstrndx  = TO_NATIVE(endian, 16, hdr->e_shstrndx);

-   sechdrs = (void *)hdr + hdr->e_shoff;
+   sechdrs = RTE_PTR_ADD(hdr, hdr->e_shoff);
info->sechdrs = sechdrs;

/* Check if file offset is correct */
@@ -191,7 +190,6 @@ static int parse_elf(struct elf_info *info, const char 
*filename)
TO_NATIVE(endian, ADDR_SIZE, sechdrs[i].sh_entsize);
}
/* Find symbol table. */
-   secstrings = (void *)hdr + sechdrs[info->secindex_strings].sh_offset;
for (i = 1; i < info->num_sections; i++) {
int nobits = sechdrs[i].sh_type == SHT_NOBITS;

@@ -206,22 +204,22 @@ static int parse_elf(struct elf_info *info, const char 
*filename)
if (sechdrs[i].sh_type == SHT_SYMTAB) {
unsigned int sh_link_idx;
symtab_idx = i;
-   info->symtab_start = (void *)hdr +
-   sechdrs[i].sh_offset;
-   info->symtab_stop  = (void *)hdr +
-   sechdrs[i].sh_offset + sechdrs[i].sh_size;
+   info->symtab_start = RTE_PTR_ADD(hdr,
+   sechdrs[i].sh_offset);
+   info->symtab_stop  = RTE_PTR_ADD(hdr,
+   sechdrs[i].sh_offset + sechdrs[i].sh_size);
sh_link_idx = sechdrs[i].sh_link;
-   info->strtab   = (void *)hdr +
-   sechdrs[sh_link_idx].sh_offset;
+   info->strtab   = RTE_PTR_ADD(hdr,
+   sechdrs[sh_link_idx].sh_offset);
}

/* 32bit section no. table? ("more than 64k sections") */
if (sechdrs[i].sh_type == SHT_SYMTAB_SHNDX) {
symtab_shndx_idx = i;
-

[dpdk-dev] [PATCH 06/11] mk: fix verbose pmdinfogen run

[Thomas Monjalon]

When building with "make V=1" it is expected to see the output of each
compiler command in order to debug them.
Unfortunately the pmdinfogen related commands were always quiet.

It is fixed by defining the commands in some Makefile variables.
They are printed if the verbose mode is enabled.

The other benefit of this rework is to stop compilation after a
failure with pmdinfogen.

The command readlink is removed in this rework because it seems useless.

Fixes: 3d781ca32874 ("mk: do post processing on objects that register a driver")

Signed-off-by: Thomas Monjalon 
---
 mk/internal/rte.compile-pre.mk | 26 --
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/mk/internal/rte.compile-pre.mk b/mk/internal/rte.compile-pre.mk
index 87d2d93..9c25ff6 100644
--- a/mk/internal/rte.compile-pre.mk
+++ b/mk/internal/rte.compile-pre.mk
@@ -84,28 +84,26 @@ C_TO_O = $(CC) -Wp,-MD,$(call obj2dep,$(@)).tmp $(CFLAGS) \
 C_TO_O_STR = $(subst ','\'',$(C_TO_O)) #'# fix syntax highlight
 C_TO_O_DISP = $(if $(V),"$(C_TO_O_STR)","  CC $(@)")
 endif
+PMDINFO_GEN = $(RTE_SDK_BIN)/app/pmdinfogen $@ $@.pmd.c
+PMDINFO_CC = $(CC) $(CFLAGS) -c -o $@.pmd.o $@.pmd.c
+PMDINFO_LD = $(CROSS)ld $(LDFLAGS) -r -o $@.o $@.pmd.o $@
+PMDINFO_TO_O = if grep -q 'PMD_REGISTER_DRIVER(.*)' $<; then \
+   echo "$(if $V,$(PMDINFO_GEN),  PMDINFO $@.pmd.c)" && \
+   $(PMDINFO_GEN) && \
+   echo "$(if $V,$(PMDINFO_CC),  CC $@.pmd.o)" && \
+   $(PMDINFO_CC) && \
+   echo "$(if $V,$(PMDINFO_LD),  LD $@)" && \
+   $(PMDINFO_LD) && \
+   mv -f $@.o $@; fi
 C_TO_O_CMD = 'cmd_$@ = $(C_TO_O_STR)'
 C_TO_O_DO = @set -e; \
echo $(C_TO_O_DISP); \
$(C_TO_O) && \
-   sh -c "grep -q \"PMD_REGISTER_DRIVER(.*)\" $<; \
-   if [ \$$? -eq 0 ]; then \
-   echo \"  PMDINFOGEN\" $@; \
-   OBJF=`readlink -f $@`; \
-   $(RTE_SDK_BIN)/app/pmdinfogen \$$OBJF \$$OBJF.pmd.c; \
-   if [ \$$? -eq 0 ]; \
-   then \
-   echo \"  PMDINFOBUILD\" $@; \
-   $(CC) $(CFLAGS) -c -o \$$OBJF.pmd.o \$$OBJF.pmd.c; \
-   $(CROSS)ld $(LDFLAGS) -r -o \$$OBJF.o \$$OBJF.pmd.o 
\$$OBJF; \
-   mv -f \$$OBJF.o \$$OBJF; \
-   fi; \
-   fi;" && \
+   $(PMDINFO_TO_O) && \
echo $(C_TO_O_CMD) > $(call obj2cmd,$(@)) && \
sed 's,'$@':,dep_'$@' =,' $(call obj2dep,$(@)).tmp > $(call 
obj2dep,$(@)) && \
rm -f $(call obj2dep,$(@)).tmp

-
 # return an empty string if string are equal
 compare = $(strip $(subst $(1),,$(2)) $(subst $(2),,$(1)))

-- 
2.7.0

[dpdk-dev] [PATCH 05/11] mk: fix driver build with installed SDK

[Thomas Monjalon]

The tool pmdinfogen was called from RTE_OUTPUT/app/ which does not exist
if building a driver outside of the SDK build.
When building DPDK, RTE_SDK_BIN is RTE_OUTPUT. When building an external
driver, RTE_SDK_BIN must point to the installed DPDK directory containing
includes, libs, etc.

That's why pmdinfogen must be installed in the SDK directory and be part
of the SDK installation.

Fixes: 3d781ca32874 ("mk: do post processing on objects that register a driver")

Signed-off-by: Thomas Monjalon 
---
 mk/internal/rte.compile-pre.mk | 2 +-
 mk/rte.sdkinstall.mk   | 8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/mk/internal/rte.compile-pre.mk b/mk/internal/rte.compile-pre.mk
index 5632d6e..87d2d93 100644
--- a/mk/internal/rte.compile-pre.mk
+++ b/mk/internal/rte.compile-pre.mk
@@ -92,7 +92,7 @@ C_TO_O_DO = @set -e; \
if [ \$$? -eq 0 ]; then \
echo \"  PMDINFOGEN\" $@; \
OBJF=`readlink -f $@`; \
-   ${RTE_OUTPUT}/app/pmdinfogen \$$OBJF \$$OBJF.pmd.c; \
+   $(RTE_SDK_BIN)/app/pmdinfogen \$$OBJF \$$OBJF.pmd.c; \
if [ \$$? -eq 0 ]; \
then \
echo \"  PMDINFOBUILD\" $@; \
diff --git a/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk
index b0d985c..7cd352c 100644
--- a/mk/rte.sdkinstall.mk
+++ b/mk/rte.sdkinstall.mk
@@ -117,6 +117,7 @@ install-runtime:
$(Q)cp -a$O/lib/* $(DESTDIR)$(libdir)
$(Q)$(call rte_mkdir, $(DESTDIR)$(bindir))
$(Q)tar -cf -  -C $O --exclude 'app/*.map' \
+   --exclude app/pmdinfogen \
--exclude 'app/cmdline*' --exclude app/test \
--exclude app/testacl --exclude app/testpipeline app | \
tar -xf -  -C $(DESTDIR)$(bindir) --strip-components=1 \
@@ -126,10 +127,8 @@ install-runtime:
$(Q)$(call rte_mkdir,  $(DESTDIR)$(sbindir))
$(Q)$(call rte_symlink,$(DESTDIR)$(datadir)/tools/dpdk_nic_bind.py, 
\
   $(DESTDIR)$(sbindir)/dpdk_nic_bind)
-   $(Q)$(call rte_symlink,$(DESTDIR)$(bindir)/pmdinfogen, \
-  $(DESTDIR)$(bindir)/dpdk_pmdinfogen)
$(Q)$(call rte_symlink,$(DESTDIR)$(datadir)/tools/pmdinfo.py, \
-  $(DESTDIR)$(bindir)/dpdk_pmdinfo)
+  $(DESTDIR)$(bindir)/dpdk_pmdinfo)

 install-kmod:
 ifneq ($(wildcard $O/kmod/*),)
@@ -145,8 +144,9 @@ install-sdk:
$(Q)$(call rte_mkdir,$(DESTDIR)$(sdkdir))
$(Q)cp -a   $(RTE_SDK)/mk$(DESTDIR)$(sdkdir)
$(Q)cp -a   $(RTE_SDK)/scripts   $(DESTDIR)$(sdkdir)
-   $(Q)$(call rte_mkdir,$(DESTDIR)$(targetdir))
+   $(Q)$(call rte_mkdir,
$(DESTDIR)$(targetdir)/app)
$(Q)cp -a   $O/.config   $(DESTDIR)$(targetdir)
+   $(Q)cp -a   $O/app/pmdinfogen
$(DESTDIR)$(targetdir)/app
$(Q)$(call rte_symlink, $(DESTDIR)$(includedir), 
$(DESTDIR)$(targetdir)/include)
$(Q)$(call rte_symlink, $(DESTDIR)$(libdir), 
$(DESTDIR)$(targetdir)/lib)

-- 
2.7.0

[dpdk-dev] [PATCH 04/11] mk: remove traces of hostapp build directory

[Thomas Monjalon]

The recipe rte.hostapp.mk does not build in hostapp/ anymore.

Fixes: 98b0fdb0ffc6 ("pmdinfogen: add buildtools and pmdinfogen utility")

Signed-off-by: Thomas Monjalon 
---
 doc/guides/freebsd_gsg/build_dpdk.rst | 2 +-
 doc/guides/linux_gsg/build_dpdk.rst   | 2 +-
 mk/rte.sdkbuild.mk| 5 ++---
 mk/rte.sdkconfig.mk   | 2 +-
 4 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/doc/guides/freebsd_gsg/build_dpdk.rst 
b/doc/guides/freebsd_gsg/build_dpdk.rst
index 1d92c08..93c4366 100644
--- a/doc/guides/freebsd_gsg/build_dpdk.rst
+++ b/doc/guides/freebsd_gsg/build_dpdk.rst
@@ -183,7 +183,7 @@ contains the kernel modules to install:

 ls x86_64-native-bsdapp-gcc

-app build hostapp include kmod lib Makefile
+app build include kmod lib Makefile


 .. _loading_contigmem:
diff --git a/doc/guides/linux_gsg/build_dpdk.rst 
b/doc/guides/linux_gsg/build_dpdk.rst
index 198c0b6..fb2c481 100644
--- a/doc/guides/linux_gsg/build_dpdk.rst
+++ b/doc/guides/linux_gsg/build_dpdk.rst
@@ -152,7 +152,7 @@ A kmod  directory is also present that contains kernel 
modules which may be load

 ls x86_64-native-linuxapp-gcc

-app build hostapp include kmod lib Makefile
+app build include kmod lib Makefile

 Loading Modules to Enable Userspace IO for DPDK
 ---
diff --git a/mk/rte.sdkbuild.mk b/mk/rte.sdkbuild.mk
index 354f006..23fcf1e 100644
--- a/mk/rte.sdkbuild.mk
+++ b/mk/rte.sdkbuild.mk
@@ -64,9 +64,8 @@ build: $(ROOTDIRS-y)
 .PHONY: clean
 clean: $(CLEANDIRS)
@rm -rf $(RTE_OUTPUT)/include $(RTE_OUTPUT)/app \
-   $(RTE_OUTPUT)/hostapp $(RTE_OUTPUT)/lib \
-   $(RTE_OUTPUT)/hostlib $(RTE_OUTPUT)/kmod \
-   $(RTE_OUTPUT)/buildtools
+   $(RTE_OUTPUT)/lib \
+   $(RTE_OUTPUT)/hostlib $(RTE_OUTPUT)/kmod
@[ -d $(RTE_OUTPUT)/include ] || mkdir -p $(RTE_OUTPUT)/include
@$(RTE_SDK)/scripts/gen-config-h.sh $(RTE_OUTPUT)/.config \
> $(RTE_OUTPUT)/include/rte_config.h
diff --git a/mk/rte.sdkconfig.mk b/mk/rte.sdkconfig.mk
index a3acfe6..068d787 100644
--- a/mk/rte.sdkconfig.mk
+++ b/mk/rte.sdkconfig.mk
@@ -108,7 +108,7 @@ $(RTE_OUTPUT)/Makefile: | $(RTE_OUTPUT)
 # if NODOTCONF variable is defined, don't try to rebuild .config
 $(RTE_OUTPUT)/include/rte_config.h: $(RTE_OUTPUT)/.config
$(Q)rm -rf $(RTE_OUTPUT)/include $(RTE_OUTPUT)/app \
-   $(RTE_OUTPUT)/hostapp $(RTE_OUTPUT)/lib \
+   $(RTE_OUTPUT)/lib \
$(RTE_OUTPUT)/hostlib $(RTE_OUTPUT)/kmod $(RTE_OUTPUT)/build
$(Q)mkdir -p $(RTE_OUTPUT)/include
$(Q)$(RTE_SDK)/scripts/gen-config-h.sh $(RTE_OUTPUT)/.config \
-- 
2.7.0

[dpdk-dev] [PATCH 03/11] mk: fix build dependency of drivers on pmdinfogen

[Thomas Monjalon]

When compiling the drivers, some code is generated with pmdinfogen.
A fresh parallel build can fail if a driver is compiled before pmdinfogen:
build/buildtools/dpdk-pmdinfogen: Permission denied

There was a dependency declared in drivers/Makefile but it cannot work
because this file is based on mk/rte.subdir.mk which do not handle
dependencies.

It is fixed by declaring the whole buildtools as (order only) prerequisite
of drivers.

Fixes: cb6696d22023 ("drivers: update registration macro usage")

Signed-off-by: Thomas Monjalon 
---
 drivers/Makefile   | 2 --
 mk/rte.sdkbuild.mk | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/Makefile b/drivers/Makefile
index 75a3168..81c03a8 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -34,6 +34,4 @@ include $(RTE_SDK)/mk/rte.vars.mk
 DIRS-y += net
 DIRS-$(CONFIG_RTE_LIBRTE_CRYPTODEV) += crypto

-DEPDIRS-y += buildtools/pmdinfo
-
 include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/mk/rte.sdkbuild.mk b/mk/rte.sdkbuild.mk
index fb68af2..354f006 100644
--- a/mk/rte.sdkbuild.mk
+++ b/mk/rte.sdkbuild.mk
@@ -49,6 +49,7 @@ $(1): $(sort $(LOCAL_DEPDIRS-$(1)))
 endef

 $(foreach d,$(ROOTDIRS-y),$(eval $(call depdirs_rule,$(d
+drivers: | buildtools

 #
 # build and clean targets
-- 
2.7.0

[dpdk-dev] [PATCH 02/11] crypto: fix parameters registration

[Thomas Monjalon]

The name aesni_gcm was used to register parameters of several
crypto drivers.

Fixes: cb6696d22023 ("drivers: update registration macro usage")

Signed-off-by: Thomas Monjalon 
---
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 2 +-
 drivers/crypto/null/null_crypto_pmd.c  | 2 +-
 drivers/crypto/snow3g/rte_snow3g_pmd.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c 
b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
index 859a04b..e3dea54 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
@@ -722,5 +722,5 @@ static struct rte_driver cryptodev_aesni_mb_pmd_drv = {
 };

 PMD_REGISTER_DRIVER(cryptodev_aesni_mb_pmd_drv, aesni_mb);
-DRIVER_REGISTER_PARAM_STRING(aesni_gcm, "max_nb_queue_pairs= "
+DRIVER_REGISTER_PARAM_STRING(aesni_mb, "max_nb_queue_pairs= "
 "max_nb_sessions= socket_id=");
diff --git a/drivers/crypto/null/null_crypto_pmd.c 
b/drivers/crypto/null/null_crypto_pmd.c
index 0a195ed..7df88a3 100644
--- a/drivers/crypto/null/null_crypto_pmd.c
+++ b/drivers/crypto/null/null_crypto_pmd.c
@@ -276,5 +276,5 @@ static struct rte_driver cryptodev_null_pmd_drv = {
 };

 PMD_REGISTER_DRIVER(cryptodev_null_pmd_drv, cryptodev_null_pmd);
-DRIVER_REGISTER_PARAM_STRING(aesni_gcm, "max_nb_queue_pairs= "
+DRIVER_REGISTER_PARAM_STRING(cryptodev_null_pmd, "max_nb_queue_pairs= "
 "max_nb_sessions= socket_id=");
diff --git a/drivers/crypto/snow3g/rte_snow3g_pmd.c 
b/drivers/crypto/snow3g/rte_snow3g_pmd.c
index ddb724c..465d020 100644
--- a/drivers/crypto/snow3g/rte_snow3g_pmd.c
+++ b/drivers/crypto/snow3g/rte_snow3g_pmd.c
@@ -646,5 +646,5 @@ static struct rte_driver cryptodev_snow3g_pmd_drv = {
 };

 PMD_REGISTER_DRIVER(cryptodev_snow3g_pmd_drv, snow3g);
-DRIVER_REGISTER_PARAM_STRING(aesni_gcm, "max_nb_queue_pairs= "
+DRIVER_REGISTER_PARAM_STRING(snow3g, "max_nb_queue_pairs= "
 "max_nb_sessions= socket_id=");
-- 
2.7.0

[dpdk-dev] [PATCH 00/11] additions to pmdinfogen

[Thomas Monjalon]

These are the patches that I think needed for RC2.
There are other patches needed as discussed on the mailing-list which
are not part of this series:
  - overwritten driver name (reported by Pablo)
  - pmdinfo.py on FreeBSD (reported by Bruce)

Thomas Monjalon (11):
  drivers: fix build with new register macro
  crypto: fix parameters registration
  mk: fix build dependency of drivers on pmdinfogen
  mk: remove traces of hostapp build directory
  mk: fix driver build with installed SDK
  mk: fix verbose pmdinfogen run
  pmdinfogen: fix build warnings
  pmdinfogen: fix usage message
  eal: move PCI table macro
  doc: fix syntax in pmdinfogen guide
  maintainers: add section for pmdinfo

 MAINTAINERS|  4 ++
 buildtools/pmdinfogen/Makefile |  4 +-
 buildtools/pmdinfogen/pmdinfogen.c | 60 --
 doc/guides/freebsd_gsg/build_dpdk.rst  |  2 +-
 doc/guides/linux_gsg/build_dpdk.rst|  2 +-
 doc/guides/prog_guide/dev_kit_build_system.rst |  5 +--
 drivers/Makefile   |  2 -
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c |  4 +-
 drivers/crypto/null/null_crypto_pmd.c  |  2 +-
 drivers/crypto/snow3g/rte_snow3g_pmd.c |  2 +-
 drivers/net/mlx4/mlx4.c|  2 +-
 drivers/net/mlx5/mlx5.c|  2 +-
 lib/librte_eal/common/include/rte_dev.h|  6 +--
 lib/librte_eal/common/include/rte_pci.h|  5 +++
 mk/internal/rte.compile-pre.mk | 26 ++-
 mk/rte.sdkbuild.mk |  6 +--
 mk/rte.sdkconfig.mk|  2 +-
 mk/rte.sdkinstall.mk   |  8 ++--
 18 files changed, 61 insertions(+), 83 deletions(-)

-- 
2.7.0

[dpdk-dev] [PATCH v6 0/4] support reset of VF link

[Luca Boccassi]

On Thu, 2016-07-07 at 13:12 +, Lu, Wenzhuo wrote:
> > -Original Message-
> > From: Luca Boccassi [mailto:lboccass at Brocade.com]
> > Sent: Thursday, July 7, 2016 6:21 PM
> > To: Lu, Wenzhuo
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v6 0/4] support reset of VF link
> > 
> > On Thu, 2016-07-07 at 01:09 +, Lu, Wenzhuo wrote:
> > > Hi Luca,
> > >
> > >
> > > > -Original Message-
> > > > From: Luca Boccassi [mailto:lboccass at Brocade.com]
> > > > Sent: Thursday, July 7, 2016 12:23 AM
> > > > To: Lu, Wenzhuo
> > > > Cc: dev at dpdk.org
> > > > Subject: Re: [dpdk-dev] [PATCH v6 0/4] support reset of VF link
> > > >
> > > > On Wed, 2016-07-06 at 00:45 +, Lu, Wenzhuo wrote:
> > > > > Hi Luca,
> > > > >
> > > > > > -Original Message-
> > > > > > From: Luca Boccassi [mailto:lboccass at Brocade.com]
> > > > > > Sent: Tuesday, July 5, 2016 5:53 PM
> > > > > > To: Lu, Wenzhuo
> > > > > > Cc: dev at dpdk.org
> > > > > > Subject: Re: [dpdk-dev] [PATCH v6 0/4] support reset of VF link
> > > > > >
> > > > > > On Tue, 2016-07-05 at 00:52 +, Lu, Wenzhuo wrote:
> > > > > > > Hi Luca,
> > > > > > >
> > > > > > >
> > > > > > > > -Original Message-
> > > > > > > > From: Luca Boccassi [mailto:lboccass at Brocade.com]
> > > > > > > > Sent: Monday, July 4, 2016 11:48 PM
> > > > > > > > To: Lu, Wenzhuo
> > > > > > > > Cc: dev at dpdk.org
> > > > > > > > Subject: Re: [dpdk-dev] [PATCH v6 0/4] support reset of VF
> > > > > > > > link
> > > > > > > >
> > > > > > > > On Mon, 2016-06-20 at 14:24 +0800, Wenzhuo Lu wrote:
> > > > > > > > > If the PF link is down and up, VF link will not work 
> > > > > > > > > accordingly.
> > > > > > > > > This patch set addes the support of VF link reset. So,
> > > > > > > > > when VF receices the messges of physical link down/up. APP
> > > > > > > > > can reset the VF link and let it recover.
> > > > > > > > >
> > > > > > > > > PS: This patch set is splitted from a previous patch set,
> > > > > > > > > *automatic link recovery on ixgbe/igb VF*, and it's base
> > > > > > > > > on the patch set *support mailbox interruption on ixgbe/igb 
> > > > > > > > > VF*.
> > > > > > > > >
> > > > > > > > > Wenzhuo Lu (3):
> > > > > > > > >   lib/librte_ether: support device reset
> > > > > > > > >   ixgbe: implement device reset on VF
> > > > > > > > >   igb: implement device reset on VF
> > > > > > > > >
> > > > > > > > > Zhe Tao (1):
> > > > > > > > >   i40e: implement device reset on VF
> > > > > > > > >
> > > > > > > > > v1:
> > > > > > > > > - Added the implementation for the VF reset functionality.
> > > > > > > > > v2:
> > > > > > > > > - Changed the i40e related operations during VF reset.
> > > > > > > > > v3:
> > > > > > > > > - Resent the patches because of the mail sent issue.
> > > > > > > > > v4:
> > > > > > > > > - Removed some VF reset emulation code.
> > > > > > > > > v5:
> > > > > > > > > - Removed all the code related with lock.
> > > > > > > > > v6:
> > > > > > > > > - Updated the NIC feature overview matrix.
> > > > > > > > > - Added more explanation in the doxygen comment of reset API.
> > > > > > > > >
> > > > > > > > >  doc/guides/nics/overview.rst   |  1 +
> > > > > > > > >  doc/guides/rel_notes/release_16_07.rst | 13 ++
> > > > > > > > >  drivers/net/e1000/igb_ethdev.c | 59
> > 
> > > > > > > > >  drivers/net/i40e/i40e_ethdev.h |  4 ++
> > > > > > > > >  drivers/net/i40e/i40e_ethdev_vf.c  | 83
> > > > > > > > ++
> > > > > > > > >  drivers/net/i40e/i40e_rxtx.c   | 10 
> > > > > > > > >  drivers/net/i40e/i40e_rxtx.h   |  4 ++
> > > > > > > > >  drivers/net/ixgbe/ixgbe_ethdev.c   | 64
> > > > +-
> > > > > > > > >  drivers/net/ixgbe/ixgbe_ethdev.h   |  2 +-
> > > > > > > > >  drivers/net/ixgbe/ixgbe_rxtx.c | 12 +++--
> > > > > > > > >  lib/librte_ether/rte_ethdev.c  | 17 +++
> > > > > > > > >  lib/librte_ether/rte_ethdev.h  | 24 ++
> > > > > > > > >  lib/librte_ether/rte_ether_version.map |  7 +++
> > > > > > > > >  13 files changed, 295 insertions(+), 5 deletions(-)
> > > > > > > >
> > > > > > > > Hello Wenzhuo,
> > > > > > > >
> > > > > > > > I'm testing this patchset, but I am sporadically running
> > > > > > > > into an issue where the VFs reset fails after the PF flaps.
> > > > > > > >
> > > > > > > > I have a VM running on a KVM box with a X540-AT2, passing 2 VFs 
> > > > > > > > in.
> > > > > > > >
> > > > > > > > I am using calling rte_eth_dev_reset in response to a
> > > > > > > > RTE_ETH_EVENT_INTR_RESET callback, and the following errors
> > > > > > > > appear in the
> > > > > > > > log:
> > > > > > > >
> > > > > > > > PMD: ixgbevf_dev_reset(): Ixgbe VF reset: Failed to update link.
> > > > > > > > PMD: ixgbe_alloc_rx_queue_mbufs(): RX mbuf alloc failed
> > > > > > > > queue_id=0
> > > > > > > > PMD: ixgbevf_dev_start(): Unable to initialize RX 

[dpdk-dev] 16.11 Roadmap

[O'Driscoll, Tim]

We published our initial roadmap for 16.11 at the start of May. Since then, 
we've been doing more detailed planning and would like to provide an update on 
the features that we plan to submit for this release.

We'll schedule a community call where some of our software developers will 
describe their work in a bit more detail and answer any questions. It would be 
good if others are also willing to share their plans so that we can build up a 
complete picture of what's planned for 16.11.

This is what we're planning to submit for 16.11:

Cryptodev Support for Hardware Acceleration (via Intel(r) QuickAssist 
Technology) for Additional Algorithms:
Add support for additional algorithms which are supported by Intel(r) 
QuickAssist Technology but are not currently supported in DPDK. This includes: 
3DES_CBC_128/192, KASUMI, NULL, SHA224_HMAC, SHA384_HMAC and AES-GMAC. 

Cryptodev Support for Software Acceleration for Additional Algorithms:
Add support for software implementations of additional crypto algorithms. This 
includes: ZUC (EEA3 and EIA3) and 3DES_CBC_128/192 with MD5_HMAC, 
SHA1/SHA224/SHA256_HMAC and AES-GMAC.  ZUC will be supported via an optimized 
software library similar to KASUMI and SNOW3G. 3DES, and potentially other 
software implementations in future, will not be an optimized implementation, so 
it will not perform to the same level as other optimized software libraries.

Cryptodev Performance Optimization:
Analyze the performance of the cryptodev API, identify bottlenecks, and 
optimize where required.

IPsec Sample App Enhancements:
Add support for AES-GCM, AES-CTR, config file support to remove hard-coding of 
SAs/SPs etc., use forward cipher function to generate IV on CBC mode.

Generic Flow Director/Filtering/Classification API:
When a Generic Flow Director/Filtering/Classification API is agreed (see 
Adrien's RFC: http://dpdk.org/ml/archives/dev/2016-July/043365.html), implement 
support for that API for ixgbe and i40e.

Cuckoo Hash Enhancements:
Optimize the Cuckoo Hash lookup stages by using intelligent prefetching for 
keys and using IA AVX instructions for vector processing of keys.

Add vHost PMD xStats:
Update the vHost PMD to support the extended statistics API.

Delay Packet Copy in vHost-User Dequeue:
It may be possible to increase vhost-user performance by delaying the packet 
copy on Tx until a point where we know for certain whether the copy is required 
or not. This would avoid copying the packet in cases where it is not definitely 
required. Further investigation is required to determine how much of a 
performance gain can be achieved.

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'Driscoll, Tim
> Sent: Tuesday, May 3, 2016 12:25 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] 16.11 Roadmap
> 
> We were a little late doing this for 16.07, so we're going to try and
> communicate our roadmap for future releases earlier. Our aim is to do
> this 6 months before a release. Some things will obviously change during
> planning/development, so we'll provide an update 4 months before the
> release. After that, things should hopefully be relatively stable.
> 
> Below are the features that we're planning to submit for 16.11. It would
> be good if others are also willing to share their plans so that we can
> build up a complete picture of what's planned for 16.11.
> 
> 
> Cryptodev Scheduler & Packet Reordering:
> Add a scheduler to cryptodev which will allow hardware and software
> acceleration to be used on the same core. If both are available, the
> scheduler will determine whether to use hardware or software
> acceleration based on packet size and other factors (TBD). Support
> packet reordering in cryptodev so that packet order is maintained when
> hardware and software acceleration are combined.
> 
> Cryptodev Support for Hardware Acceleration (via Intel(r) QuickAssist
> Technology) for Additional Algorithms:
> Add support for all algorithms which are supported by Intel(r)
> QuickAssist Technology but are not currently supported in DPDK. This
> includes: AES_CTR_128/192/256, MD5, MD5_HMAC, SHA1, SHA224, SHA224_HMAC,
> SHA256, SHA384, SHA384_HMAC, SHA512, AES-XTS, KASUMI.
> 
> Cryptodev Support for Software Acceleration for Additional Algorithms:
> For every algorithm that we support in hardware, provide a software
> implementation. This means that an application can always rely on the
> cryptodev API to provide the requested service, even if hardware
> acceleration is not available.
> 
> Cryptodev Performance Optimization:
> Analyze the performance of the cryptodev API, identify bottlenecks, and
> optimize where required.
> 
> Generic Classification API:
> Create a new API to provide generic filtering capabilities that works
> across NICs. This will include a software implementation which can be
> used in cases where NICs that don't support all the capabilities of the
> API. An RFC will be submitted in the 16.07 timeframe. We're 

[dpdk-dev] [PATCH v1 28/28] ether: support SoC device/driver

[Shreyansh jain]

Hi Jan,

Apologies for delay in my response.

On Tuesday 05 July 2016 10:46 AM, Jan Viktorin wrote:
> Hello Shreyansh,
> ?
>> On Monday 04 July 2016 08:06 PM, Jan Viktorin wrote:
>>> On Mon, 4 Jul 2016 19:57:18 +0530
>>> Shreyansh jain  wrote:
>>>
>>> [...]
>>>
>>> @@ -1431,7 +1524,7 @@ >rte_eth_dev_info_get(uint8_t port_id, struct 
>>> >rte_eth_dev_info *dev_info)
>>>
>>> RTE_FUNC_PTR_OR_RET(*dev->dev_ops->>dev_infos_get);
>>> (*dev->dev_ops->dev_infos_get)(dev, dev_info);
>>> -   dev_info->pci_dev = dev->pci_dev;
>>> +   dev_info->soc_dev = dev->soc_dev; 
>>
>> I think both the members, pci_dev and soc_dev, should be updated by this 
>> call.
>> Is there some specific reason why soc_dev is the only one which is 
>> getting updated? 
>
> Yes, looks like a mistake. Thanks! And sorry for delayed reply. 

 No problems - thanks for confirmation.
 I have gone through almost complete series and as and when you rebase it, 
 it would have my ACK.
>>>
>>> OK, thanks. That's what I am playing with right now. I've rebased on v3 of 
>>> this patch. There will
>>> be some more tests in my v2.
>>>
 rte_driver patchset which I sent last are broken - I will publish an 
 updated version very soon.
>>>
>>> I am surprised that you've changed the args to RTE_EAL_PCI_REGISTER... Are 
>>> you sure about this step?
>>> I wrote that I'll change it myself for v2 for SoC to accept name and 
>>> pointer as it was originally for PCI...
>>
>> Really? Then probably I understood it wrong. I don't have any issues with 
>> the first one as well but just for slightly cleaner approach I thought of 
>> going with your suggest (or, suggestion as understood by me).
> ?>
>> Anyways the patch is broken and doesn't apply on master. I will push a new 
>> version (with revert EAL_PCI_REGISTER arguments) within today.
> 
> Ok. I am away for few days this week but I will continue as soon as possible 
> on the soc patchset and also on the rte_device/driver issue. We have to cut 
> this as soon as possible. I think the best would be to post a small patchset 
> on top of this one introducing the change.

I am anyway working on a driver for NXP's SoC platform which I am basing over 
rte_device + SoC patchset.
I plan to release a draft of this driver soon. It might help validate both the 
patchsets in a limited manner.

> 
> I think, there should be a single list of rte_device and a list for 
> rte_driver while preserving lists for each infra, so also rte_pci_device 
> would have a separate list. Then, it's possible to iterate over all PCI 
> devices easily and iterate over all devices generically at the same time.

I have similar understanding. Separate pci/soc lists, and unified rte_driver 
and rte_device lists. This, in my opinion, would help keep the interfaces clean 
(free of unnecessary checks).

> 
> What I am not sure about are addr and id things. It's quite difficult to 
> generalize them. The addr needs a conpare function but how to compare pci 
> addr to another type of addr? Do we need this? If so, I'll work on this.

I am not sure why we need to compare the PCI addresses with non-PCI (or any 
other, SoC) address set? Can you elaborate?

> 
> Another thing - resources. Do we want to have a kind of a generic 
> rte_resource instead of rte_pci_resource? I think this is clearly possible. I 
> am about to do this.

The idea sounds good but I don't know whether it would be feasible or not. My 
understanding is that resources have special characteristics. Generalizing them 
would involve creating opaque objects in rte_resource{..} which in turn beats 
the purpose of generalization.

Probably, I will wait for your next patchset version to understand your 
approach.

> 
> I am afraid we are unable to change devargs significantly in this release :/ 
> (due to time and lack of a discussion here).? What I really like to see is 
> the virtual device conversion and pmd_type removal. Are you able to look at 
> this?

pmd_type removal is my todo as well. This would anyway impact the vdevs.
I haven't given devargs much thought, yet.

> 
> Any other objections?

I was looking at various discussions [1],[2] that have happened in past. From 
that, the summary I have is:
 1) Generalize devices to rte_device/rte_driver
  `-- Cleaner interfaces/difference for 'bus', 'driver' and 'device'
  `-- Moving the init/deinit functions into rte_device/rte_driver layer
  `-- hierarchical device structure (as explained by David in [1]) 
 2) Do away with device type specific initializations (registrations)
  `-- No more pdev/vdev distinction
  `-- standardizing devargs for accepting device specific strings.
 3) Hotplug support

Most of work of (1) David has already done. What remains is completing (2) and 
probably (3) which I haven't verified yet.

[1] http://dpdk.org/ml/archives/dev/2016-January/031390.html
[2] http://dpdk.org/ml/archives/dev/2016-January/030975.html

> 
> Jan Viktorin
> 

[dpdk-dev] [PATCH 2/2] bnx2x: add support for xstats

[Rasesh Mody]

This patch adds support for extended statistics for BNX2X PMD.

Signed-off-by: Rasesh Mody 
---
 doc/guides/nics/overview.rst |2 +-
 drivers/net/bnx2x/bnx2x_ethdev.c |   86 ++
 2 files changed, 87 insertions(+), 1 deletion(-)

diff --git a/doc/guides/nics/overview.rst b/doc/guides/nics/overview.rst
index 91fb18d..572ced4 100644
--- a/doc/guides/nics/overview.rst
+++ b/doc/guides/nics/overview.rst
@@ -128,7 +128,7 @@ Most of these differences are summarized below.
Packet type parsingY Y Y   Y   Y Y Y   Y   Y Y Y Y Y Y  
   Y Y Y
Timesync   Y Y Y   Y Y
Basic statsY Y Y   Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y  
 Y Y Y   Y Y Y Y Y
-   Extended stats Y   Y   Y Y Y Y Y Y Y Y Y Y Y Y Y Y  
   Y Y   Y   Y
+   Extended stats Y Y Y   Y   Y Y Y Y Y Y Y Y Y Y Y Y Y Y  
   Y Y   Y   Y
Stats per queueY   Y Y Y Y Y Y Y Y  
   Y Y   Y Y   Y Y
EEPROM dumpY   Y   Y Y
Registers dump Y   Y Y Y Y Y Y  
   Y
diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
index 3ff57c4..a57299f 100644
--- a/drivers/net/bnx2x/bnx2x_ethdev.c
+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
@@ -28,6 +28,42 @@ static struct rte_pci_id pci_id_bnx2xvf_map[] = {
{ .vendor_id = 0, }
 };

+struct rte_bnx2x_xstats_name_off {
+   char name[RTE_ETH_XSTATS_NAME_SIZE];
+   uint32_t offset_hi;
+   uint32_t offset_lo;
+};
+
+static const struct rte_bnx2x_xstats_name_off bnx2x_xstats_strings[] = {
+   {"rx_buffer_drops",
+   offsetof(struct bnx2x_eth_stats, brb_drop_hi),
+   offsetof(struct bnx2x_eth_stats, brb_drop_lo)},
+   {"rx_buffer_truncates",
+   offsetof(struct bnx2x_eth_stats, brb_truncate_hi),
+   offsetof(struct bnx2x_eth_stats, brb_truncate_lo)},
+   {"rx_buffer_truncate_discard",
+   offsetof(struct bnx2x_eth_stats, brb_truncate_discard),
+   offsetof(struct bnx2x_eth_stats, brb_truncate_discard)},
+   {"mac_filter_discard",
+   offsetof(struct bnx2x_eth_stats, mac_filter_discard),
+   offsetof(struct bnx2x_eth_stats, mac_filter_discard)},
+   {"no_match_vlan_tag_discard",
+   offsetof(struct bnx2x_eth_stats, mf_tag_discard),
+   offsetof(struct bnx2x_eth_stats, mf_tag_discard)},
+   {"tx_pause",
+   offsetof(struct bnx2x_eth_stats, pause_frames_sent_hi),
+   offsetof(struct bnx2x_eth_stats, pause_frames_sent_lo)},
+   {"rx_pause",
+   offsetof(struct bnx2x_eth_stats, pause_frames_received_hi),
+   offsetof(struct bnx2x_eth_stats, pause_frames_received_lo)},
+   {"tx_priority_flow_control",
+   offsetof(struct bnx2x_eth_stats, pfc_frames_sent_hi),
+   offsetof(struct bnx2x_eth_stats, pfc_frames_sent_lo)},
+   {"rx_priority_flow_control",
+   offsetof(struct bnx2x_eth_stats, pfc_frames_received_hi),
+   offsetof(struct bnx2x_eth_stats, pfc_frames_received_lo)}
+};
+
 static void
 bnx2x_link_update(struct rte_eth_dev *dev)
 {
@@ -334,6 +370,52 @@ bnx2x_dev_stats_get(struct rte_eth_dev *dev, struct 
rte_eth_stats *stats)
 brb_truncate_discard + stats->rx_nombuf;
 }

+static int
+bnx2x_get_xstats_names(__rte_unused struct rte_eth_dev *dev,
+  struct rte_eth_xstat_name *xstats_names,
+  __rte_unused unsigned limit)
+{
+   unsigned int i, stat_cnt = RTE_DIM(bnx2x_xstats_strings);
+
+   if (xstats_names != NULL)
+   for (i = 0; i < stat_cnt; i++)
+   snprintf(xstats_names[i].name,
+   sizeof(xstats_names[i].name),
+   "%s",
+   bnx2x_xstats_strings[i].name);
+
+   return stat_cnt;
+}
+
+static int
+bnx2x_dev_xstats_get(struct rte_eth_dev *dev, struct rte_eth_xstat *xstats,
+unsigned int n)
+{
+   struct bnx2x_softc *sc = dev->data->dev_private;
+   unsigned int num = RTE_DIM(bnx2x_xstats_strings);
+
+   if (n < num)
+   return num;
+
+   bnx2x_stats_handle(sc, STATS_EVENT_UPDATE);
+
+   for (num = 0; num < n; num++) {
+   if (bnx2x_xstats_strings[num].offset_hi !=
+   bnx2x_xstats_strings[num].offset_lo)
+   xstats[num].value = HILO_U64(
+ *(uint32_t *)((char *)>eth_stats +
+ bnx2x_xstats_strings[num].offset_hi),
+ *(uint32_t *)((char *)>eth_stats +
+ bnx2x_xstats_strings[num].offset_lo));
+   else
+   

[dpdk-dev] [PATCH 1/2] qede: add support for xstats

[Rasesh Mody]

This patch adds support for extended statistics for QEDE PMD.

Signed-off-by: Rasesh Mody 
---
 doc/guides/nics/overview.rst   |2 +-
 drivers/net/qede/qede_ethdev.c |  204 ++--
 2 files changed, 197 insertions(+), 9 deletions(-)

diff --git a/doc/guides/nics/overview.rst b/doc/guides/nics/overview.rst
index a23eb5c..91fb18d 100644
--- a/doc/guides/nics/overview.rst
+++ b/doc/guides/nics/overview.rst
@@ -128,7 +128,7 @@ Most of these differences are summarized below.
Packet type parsingY Y Y   Y   Y Y Y   Y   Y Y Y Y Y Y  
   Y Y Y
Timesync   Y Y Y   Y Y
Basic statsY Y Y   Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y  
 Y Y Y   Y Y Y Y Y
-   Extended stats Y   Y   Y Y Y Y Y Y Y Y Y Y Y Y Y Y  
 Y   Y
+   Extended stats Y   Y   Y Y Y Y Y Y Y Y Y Y Y Y Y Y  
   Y Y   Y   Y
Stats per queueY   Y Y Y Y Y Y Y Y  
   Y Y   Y Y   Y Y
EEPROM dumpY   Y   Y Y
Registers dump Y   Y Y Y Y Y Y  
   Y
diff --git a/drivers/net/qede/qede_ethdev.c b/drivers/net/qede/qede_ethdev.c
index bb531be..3f6b77d 100644
--- a/drivers/net/qede/qede_ethdev.c
+++ b/drivers/net/qede/qede_ethdev.c
@@ -14,6 +14,151 @@ static const struct qed_eth_ops *qed_ops;
 static const char *drivername = "qede pmd";
 static int64_t timer_period = 1;

+struct rte_qede_xstats_name_off {
+   char name[RTE_ETH_XSTATS_NAME_SIZE];
+   uint64_t offset;
+};
+
+static const struct rte_qede_xstats_name_off qede_xstats_strings[] = {
+   {"rx_unicast_bytes", offsetof(struct ecore_eth_stats, rx_ucast_bytes)},
+   {"rx_multicast_bytes",
+   offsetof(struct ecore_eth_stats, rx_mcast_bytes)},
+   {"rx_broadcast_bytes",
+   offsetof(struct ecore_eth_stats, rx_bcast_bytes)},
+   {"rx_unicast_packets", offsetof(struct ecore_eth_stats, rx_ucast_pkts)},
+   {"rx_multicast_packets",
+   offsetof(struct ecore_eth_stats, rx_mcast_pkts)},
+   {"rx_broadcast_packets",
+   offsetof(struct ecore_eth_stats, rx_bcast_pkts)},
+
+   {"tx_unicast_bytes", offsetof(struct ecore_eth_stats, tx_ucast_bytes)},
+   {"tx_multicast_bytes",
+   offsetof(struct ecore_eth_stats, tx_mcast_bytes)},
+   {"tx_broadcast_bytes",
+   offsetof(struct ecore_eth_stats, tx_bcast_bytes)},
+   {"tx_unicast_packets", offsetof(struct ecore_eth_stats, tx_ucast_pkts)},
+   {"tx_multicast_packets",
+   offsetof(struct ecore_eth_stats, tx_mcast_pkts)},
+   {"tx_broadcast_packets",
+   offsetof(struct ecore_eth_stats, tx_bcast_pkts)},
+
+   {"rx_64_byte_packets",
+   offsetof(struct ecore_eth_stats, rx_64_byte_packets)},
+   {"rx_65_to_127_byte_packets",
+   offsetof(struct ecore_eth_stats, rx_65_to_127_byte_packets)},
+   {"rx_128_to_255_byte_packets",
+   offsetof(struct ecore_eth_stats, rx_128_to_255_byte_packets)},
+   {"rx_256_to_511_byte_packets",
+   offsetof(struct ecore_eth_stats, rx_256_to_511_byte_packets)},
+   {"rx_512_to_1023_byte_packets",
+   offsetof(struct ecore_eth_stats, rx_512_to_1023_byte_packets)},
+   {"rx_1024_to_1518_byte_packets",
+   offsetof(struct ecore_eth_stats, rx_1024_to_1518_byte_packets)},
+   {"rx_1519_to_1522_byte_packets",
+   offsetof(struct ecore_eth_stats, rx_1519_to_1522_byte_packets)},
+   {"rx_1519_to_2047_byte_packets",
+   offsetof(struct ecore_eth_stats, rx_1519_to_2047_byte_packets)},
+   {"rx_2048_to_4095_byte_packets",
+   offsetof(struct ecore_eth_stats, rx_2048_to_4095_byte_packets)},
+   {"rx_4096_to_9216_byte_packets",
+   offsetof(struct ecore_eth_stats, rx_4096_to_9216_byte_packets)},
+   {"rx_9217_to_16383_byte_packets",
+   offsetof(struct ecore_eth_stats,
+rx_9217_to_16383_byte_packets)},
+   {"tx_64_byte_packets",
+   offsetof(struct ecore_eth_stats, tx_64_byte_packets)},
+   {"tx_65_to_127_byte_packets",
+   offsetof(struct ecore_eth_stats, tx_65_to_127_byte_packets)},
+   {"tx_128_to_255_byte_packets",
+   offsetof(struct ecore_eth_stats, tx_128_to_255_byte_packets)},
+   {"tx_256_to_511_byte_packets",
+   offsetof(struct ecore_eth_stats, tx_256_to_511_byte_packets)},
+   {"tx_512_to_1023_byte_packets",
+   offsetof(struct ecore_eth_stats, tx_512_to_1023_byte_packets)},
+   {"tx_1024_to_1518_byte_packets",
+   offsetof(struct ecore_eth_stats, tx_1024_to_1518_byte_packets)},
+   {"trx_1519_to_1522_byte_packets",
+   offsetof(struct ecore_eth_stats, tx_1519_to_2047_byte_packets)},
+   

[dpdk-dev] [PATCH 2/2] vfio: fix coding style

[Yong Wang]

Signed-off-by: Yong Wang 
---
 lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c 
b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
index 3729c35..6492216 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
@@ -274,7 +274,8 @@ pci_vfio_set_bus_master(int dev_fd)

 /* pick IOMMU type. returns a pointer to vfio_iommu_type or NULL for error */
 static const struct vfio_iommu_type *
-pci_vfio_set_iommu_type(int vfio_container_fd) {
+pci_vfio_set_iommu_type(int vfio_container_fd)
+{
unsigned idx;
for (idx = 0; idx < RTE_DIM(iommu_types); idx++) {
const struct vfio_iommu_type *t = _types[idx];
@@ -297,7 +298,8 @@ pci_vfio_set_iommu_type(int vfio_container_fd) {

 /* check if we have any supported extensions */
 static int
-pci_vfio_has_supported_extensions(int vfio_container_fd) {
+pci_vfio_has_supported_extensions(int vfio_container_fd)
+{
int ret;
unsigned idx, n_extensions = 0;
for (idx = 0; idx < RTE_DIM(iommu_types); idx++) {
-- 
1.9.1

[dpdk-dev] [PATCH 1/2] vfio: fix pci_vfio_map_resource

[Yong Wang]

The offset of the 2nd mmap when mapping the region after msix_bar
needs to take region address into consideration.  This is exposed
when using vfio-pci to manage vmxnet3 pmd.

Fixes: 90a1633b2347 ("eal/linux: allow to map BARs with MSI-X tables")

Signed-off-by: Yong Wang 
Signed-off-by: Ronghua Zhang 
---
 lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c 
b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
index f91b924..3729c35 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
@@ -896,7 +896,7 @@ pci_vfio_map_resource(struct rte_pci_device *dev)
} else {
memreg[0].offset = reg.offset;
memreg[0].size = table_start;
-   memreg[1].offset = table_end;
+   memreg[1].offset = reg.offset + table_end;
memreg[1].size = reg.size - table_end;

RTE_LOG(DEBUG, EAL,
@@ -939,7 +939,8 @@ pci_vfio_map_resource(struct rte_pci_device *dev)
/* if there's a second part, try to map it */
if (map_addr != MAP_FAILED
&& memreg[1].offset && memreg[1].size) {
-   void *second_addr = RTE_PTR_ADD(bar_addr, 
memreg[1].offset);
+   void *second_addr = RTE_PTR_ADD(bar_addr,
+   
memreg[1].offset - memreg[0].offset);
map_addr = pci_map_resource(second_addr,
vfio_dev_fd, 
memreg[1].offset,
memreg[1].size,
-- 
1.9.1

[dpdk-dev] [PATCH v3] mempool: replace c memcpy code semantics with optimized rte_memcpy

[Ferruh Yigit]

On 7/6/2016 5:21 PM, Ferruh Yigit wrote:
> On 7/5/2016 3:09 PM, Ferruh Yigit wrote:
>> On 7/5/2016 2:13 PM, Jerin Jacob wrote:
>>> On Tue, Jul 05, 2016 at 07:32:46PM +0800, Yuanhan Liu wrote:
 On Tue, Jul 05, 2016 at 09:43:03AM +0100, Ferruh Yigit wrote:
> On 6/30/2016 6:28 PM, Thomas Monjalon wrote:
>> 2016-06-30 17:46, Jerin Jacob:
>>> Signed-off-by: Jerin Jacob 
>>> Acked-by: Olivier Matz 
>>
>> Applied, thanks
>>
>
> Hi Jerin,
>
> This commit cause a compilation error on target i686-native-linuxapp-gcc
> with gcc6.

 Besides that, I'm more curious to know have you actually seen any
 performance boost?
>>>
>>> let me first address your curiosity,
>>> http://dpdk.org/dev/patchwork/patch/12993/( check the second comment)
>>> http://dpdk.org/ml/archives/dev/2016-June/042701.html
>>>
>>> Ferruh,
>>
>> Hi Jerin,
>>
>>>
>>> I have tested on a x86 machine with gcc 6.1. I could n't see any issues
>>> with i686-native-linuxapp-gcc target
>> Thanks for investigating the issue.
>>
>>>
>>> Steps following to create gcc 6.1 toolchain
>>> https://sahas.ra.naman.ms/2016/05/31/building-gcc6-1-on-fedora-23/
>>> (removed --disable-multilib to have support for -m32)
>>>
>>> ? [dpdk-master] $ gcc -v
>>> Using built-in specs.
>>> COLLECT_GCC=gcc
>>> COLLECT_LTO_WRAPPER=/opt/gcc-6.1.0/libexec/gcc/x86_64-pc-linux-gnu/6.1.0/lto-wrapper
>>> Target: x86_64-pc-linux-gnu
>>> Configured with: ../gcc-6.1.0/configure --prefix=/opt/gcc-6.1.0
>>> --enable-languages=c,c++ --enable-libmudflap --with-system-zlib
>>> Thread model: posix
>>> gcc version 6.1.0 (GCC)
>> I am using Fedora24, which has gcc6 (6.1.1) as default.
>>
>>>
>>> More over this issue seems like an issue from x86 rte_memcpy implementation.
>> You are right. But i686 compilation starts failing with this commit.
>> And reverting this commit in the current HEAD solves the compilation
>> problem.
>> I am not really clear about reason of the compilation error.
> 
> The compile error is because compiler is so smart now and at the same
> time not enough smart.
> 
> Call stack is as following:
> 
> virtio_xmit_pkts_simple
>   virtio_xmit_cleanup
> rte_mempool_put_bulk
>   rte_mempool_generic_put
> __mempool_generic_put
> rte_memcpy
> 
> The array used as source buffer in virtio_xmit_cleanup (free) is a
> pointer array with 32 elements, in 32bit this makes 128 bytes.
> 
> in rte_memcpy() implementation, there a code piece as following:
> if (size > 256) {
> rte_move128(...);
> rte_move128(...); <--- [1]
> 
> }
> 
> The compiler traces the array all through the call stack and knows the
> size of array is 128 and generates a warning on above [1] which tries to
> access beyond byte 128.
> But unfortunately it ignores the "(size > 256)" check.
> 
> In 64bit, this warning is not generated because array size becomes 256
> bytes.
> 
> So this warning is a false positive. Although I am working on it, if
> anybody has a suggestion to prevent warning, quite welcome. At worst I
> will disable this compiler warning for the file.

I have sent a patch:
http://dpdk.org/ml/archives/dev/2016-July/043492.html

Giving a hint to compiler that variable "size" is related to the size of
the source buffer fixes compiler warning.

- This update is in virtio fast path, can you please review it from
point of performance effect.

- Isn't this surprisingly smart of compiler, or am I missing something J

Thanks,
ferruh

[dpdk-dev] [PATCH] net/virtio: fix gcc6 i686 compiler error

[Ferruh Yigit]

This is for target i686-native-linuxapp-gcc and gcc6,

Compilation error is:
== Build drivers/net/virtio
  CC virtio_rxtx_simple.o
In file included from
.../build/include/rte_mempool.h:77:0,
 from
.../drivers/net/virtio/virtio_rxtx_simple.c:46:
.../drivers/net/virtio/virtio_rxtx_simple.c: In
function ?virtio_xmit_pkts_simple?:
.../build/include/rte_memcpy.h:551:2: error: array
subscript is above array bounds [-Werror=array-bounds]
  rte_mov16((uint8_t *)dst + 1 * 16, (const uint8_t *)src + 1 * 16);
  ^

Call stack is as following:

virtio_xmit_pkts_simple
  virtio_xmit_cleanup
rte_mempool_put_bulk
  rte_mempool_generic_put
__mempool_generic_put
  rte_memcpy

The array used as source buffer in virtio_xmit_cleanup (free) is a
pointer array with 32 elements, in 32bit this makes 128 bytes.

in rte_memcpy() implementation, there a code piece as following:
if (size > 256) {
rte_move128(...);
rte_move128(...); <--- [1]

}

The compiler traces the array all through the call stack and knows the
size of array is 128 and generates a warning on above [1] which tries to
access beyond byte 128.
But unfortunately it ignores the "(size > 256)" check.

Giving a hint to compiler that variable "size" is related to the size of
the source buffer fixes compiler warning.

Fixes: 863bfb474493 ("mempool: optimize copy in cache")

Signed-off-by: Ferruh Yigit 
---
 drivers/net/virtio/virtio_rxtx_simple.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/net/virtio/virtio_rxtx_simple.c 
b/drivers/net/virtio/virtio_rxtx_simple.c
index 242ad90..d8fcc15 100644
--- a/drivers/net/virtio/virtio_rxtx_simple.c
+++ b/drivers/net/virtio/virtio_rxtx_simple.c
@@ -301,7 +301,7 @@ static inline void
 virtio_xmit_cleanup(struct virtqueue *vq)
 {
uint16_t i, desc_idx;
-   int nb_free = 0;
+   uint32_t nb_free = 0;
struct rte_mbuf *m, *free[VIRTIO_TX_MAX_FREE_BUF_SZ];

desc_idx = (uint16_t)(vq->vq_used_cons_idx &
@@ -319,13 +319,16 @@ virtio_xmit_cleanup(struct virtqueue *vq)
free[nb_free++] = m;
else {
rte_mempool_put_bulk(free[0]->pool,
-   (void **)free, nb_free);
+   (void **)free,
+   RTE_MIN(RTE_DIM(free),
+   nb_free));
free[0] = m;
nb_free = 1;
}
}
}
-   rte_mempool_put_bulk(free[0]->pool, (void **)free, nb_free);
+   rte_mempool_put_bulk(free[0]->pool, (void **)free,
+   RTE_MIN(RTE_DIM(free), nb_free));
} else {
for (i = 1; i < VIRTIO_TX_FREE_NR; i++) {
m = (struct rte_mbuf *)vq->vq_descx[desc_idx++].cookie;
-- 
2.7.4

[dpdk-dev] [PATCH] ixgbe: support checksum flags in sse vector Rx function

[Olivier Matz]

Update desc_to_olflags_v() to set PKT_RX_IP_CKSUM_BAD and
PKT_RX_L4_CKSUM_BAD in the ol_fags of the mbuf.

The Rx vector function can now be used with hw_ip_checksum
enabled.

Tested with:

  cd dpdk.org/
  make config T=x86_64-native-linuxapp-gcc
  make -j32
  mkdir -p /mnt/huge
  mount -t hugetlbfs nodev /mnt/huge
  echo 256 > 
/sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
  modprobe uio_pci_generic
  python tools/dpdk_nic_bind.py -b uio_pci_generic :04:00.0
  ./build/app/testpmd -l 2,4 -- --total-num-mbufs=65536 -i 
--port-topology=chained --enable-rx-cksum --disable-hw-vlan-filter 
--disable-hw-vlan-strip
set fwd rxonly
set verbose 1
start

  # send packets to testpmd using scapy
  eh = Ether(src="00:01:02:03:04:05", dst="00:1B:21:AB:8F:10")
  p = Ether()/IP(src="1.1.1.1", dst="1.1.1.2")/UDP()/Raw("x"*50)
  sendp(p, iface="ixgbe2")
  p = Ether()/IP(src="1.1.1.1", dst="1.1.1.2", chksum=42)/UDP()/Raw("x"*50)
  sendp(p, iface="ixgbe2")
  p = Ether()/IP(src="1.1.1.1", dst="1.1.1.2")/UDP(chksum=42)/Raw("x"*50)
  sendp(p, iface="ixgbe2")
  p = Ether()/IP(src="1.1.1.1", dst="1.1.1.2", 
chksum=45)/UDP(chksum=42)/Raw("x"*50)
  sendp(p, iface="ixgbe2")

  # result
  port 0/queue 0: received 1 packets
src=00:01:02:03:04:05 - dst=00:1B:21:AB:8F:10 - type=0x0800 - length=92 - 
nb_segs=1Unknown packet type
   - Receive queue=0x0
  port 0/queue 0: received 1 packets
src=00:01:02:03:04:05 - dst=00:1B:21:AB:8F:10 - type=0x0800 - length=92 - 
nb_segs=1Unknown packet type
   - Receive queue=0x0
PKT_RX_IP_CKSUM_BAD
  port 0/queue 0: received 1 packets
src=00:01:02:03:04:05 - dst=00:1B:21:AB:8F:10 - type=0x0800 - length=92 - 
nb_segs=1Unknown packet type
   - Receive queue=0x0
PKT_RX_L4_CKSUM_BAD
  port 0/queue 0: received 1 packets
src=00:01:02:03:04:05 - dst=00:1B:21:AB:8F:10 - type=0x0800 - length=92 - 
nb_segs=1Unknown packet type
   - Receive queue=0x0
PKT_RX_L4_CKSUM_BAD
PKT_RX_IP_CKSUM_BAD

Signed-off-by: Maxime Leroy 
Signed-off-by: Olivier Matz 
---
 drivers/net/ixgbe/ixgbe_rxtx_vec_common.h |  8 ++---
 drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c   |  6 
 drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c| 50 +--
 3 files changed, 42 insertions(+), 22 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_rxtx_vec_common.h 
b/drivers/net/ixgbe/ixgbe_rxtx_vec_common.h
index 62b8201..05f8185 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx_vec_common.h
+++ b/drivers/net/ixgbe/ixgbe_rxtx_vec_common.h
@@ -309,12 +309,8 @@ ixgbe_rx_vec_dev_conf_condition_check_default(struct 
rte_eth_dev *dev)
if (fconf->mode != RTE_FDIR_MODE_NONE)
return -1;

-   /*
-* - no csum error report support
-* - no header split support
-*/
-   if (rxmode->hw_ip_checksum == 1 ||
-   rxmode->header_split == 1)
+   /* no header split support */
+   if (rxmode->header_split == 1)
return -1;

return 0;
diff --git a/drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c 
b/drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c
index 64a329e..f96cc85 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c
@@ -556,5 +556,11 @@ ixgbe_txq_vec_setup(struct ixgbe_tx_queue *txq)
 int __attribute__((cold))
 ixgbe_rx_vec_dev_conf_condition_check(struct rte_eth_dev *dev)
 {
+   struct rte_eth_rxmode *rxmode = >data->dev_conf.rxmode;
+
+   /* no csum error report support */
+   if (rxmode->hw_ip_checksum == 1)
+   return -1;
+
return ixgbe_rx_vec_dev_conf_condition_check_default(dev);
 }
diff --git a/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c 
b/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c
index 1c4fd7c..dc5657e 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c
@@ -145,7 +145,7 @@ static inline void
 desc_to_olflags_v(__m128i descs[4], uint8_t vlan_flags,
struct rte_mbuf **rx_pkts)
 {
-   __m128i ptype0, ptype1, vtag0, vtag1;
+   __m128i ptype0, ptype1, vtag0, vtag1, csum;
union {
uint16_t e[4];
uint64_t dword;
@@ -162,18 +162,26 @@ desc_to_olflags_v(__m128i descs[4], uint8_t vlan_flags,
PKT_RX_RSS_HASH, 0, PKT_RX_RSS_HASH, 0,
PKT_RX_RSS_HASH, PKT_RX_RSS_HASH, PKT_RX_RSS_HASH, 0);

-   /* mask everything except vlan present bit */
-   const __m128i vlan_msk = _mm_set_epi16(
-   0x, 0x,
-   0x, 0x,
-   IXGBE_RXD_STAT_VP, IXGBE_RXD_STAT_VP,
-   IXGBE_RXD_STAT_VP, IXGBE_RXD_STAT_VP);
-   /* map vlan present (0x8) to ol_flags */
-   const __m128i vlan_map = _mm_set_epi8(
+   /* mask everything except vlan present and l4/ip csum error */
+   const __m128i vlan_csum_msk = _mm_set_epi16(
+   (IXGBE_RXDADV_ERR_TCPE | IXGBE_RXDADV_ERR_IPE) >> 16,
+   

[dpdk-dev] Help: How to read packet statistics from device registers via dpdk PMD?

[Bill Bonaparte]

I am so happy to get your reply.
My dpdk version is 2.1?and the OS is centOS 7?
the following is the output from "dpdk_nic_bind.py --status":

[root at APV35 ~]# dpdk_nic_bind.py --status

Network devices using DPDK-compatible driver

:04:00.0 'VMXNET3 Ethernet Controller' drv=igb_uio unused=
:0b:00.0 'VMXNET3 Ethernet Controller' drv=igb_uio unused=
:13:00.0 'VMXNET3 Ethernet Controller' drv=igb_uio unused=
:1b:00.0 'VMXNET3 Ethernet Controller' drv=igb_uio unused=

Network devices using kernel driver
===
:03:00.0 'VMXNET3 Ethernet Controller' if=ens160 drv=vmxnet3
unused=igb_uio *Active*

Other network devices
=


I tried it on the physical mathine, it still does not work. the OS is
centOS 7, too.
[root at AN ~]# dpdk_nic_bind.py --status

Network devices using DPDK-compatible driver

:01:00.0 '82599ES 10-Gigabit SFI/SFP+ Network Connection' drv=igb_uio
unused=
:01:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection' drv=igb_uio
unused=
:03:00.0 'I350 Gigabit Backplane Connection' drv=igb_uio unused=
:03:00.1 'I350 Gigabit Backplane Connection' drv=igb_uio unused=
:03:00.2 'I350 Gigabit Backplane Connection' drv=igb_uio unused=
:03:00.3 'I350 Gigabit Backplane Connection' drv=igb_uio unused=
:07:00.0 'I350 Gigabit Network Connection' drv=igb_uio unused=
:07:00.1 'I350 Gigabit Network Connection' drv=igb_uio unused=
:07:00.2 'I350 Gigabit Network Connection' drv=igb_uio unused=
:07:00.3 'I350 Gigabit Network Connection' drv=igb_uio unused=
:09:00.0 'I350 Gigabit Network Connection' drv=igb_uio unused=
:09:00.1 'I350 Gigabit Network Connection' drv=igb_uio unused=
:09:00.2 'I350 Gigabit Network Connection' drv=igb_uio unused=
:09:00.3 'I350 Gigabit Network Connection' drv=igb_uio unused=
:0c:00.0 'Device 0011' drv=igb_uio unused=
:0f:00.1 'I350 Gigabit Network Connection' drv=igb_uio unused=

Network devices using kernel driver
===
:0f:00.0 'I350 Gigabit Network Connection' if=enp15s0f0 drv=igb
unused=igb_uio *Active*

Other network devices
=



On Tue, Jul 5, 2016 at 8:03 PM, Jay Rolette  wrote:

>
> On Tue, Jul 5, 2016 at 2:35 AM, Bill Bonaparte 
> wrote:
>
>> Hi:
>> I am a new fish, I have tried my best to find answer about my question on
>> web, but I failed. so
>> I come here to ask for your help. the below is my question:
>>
>> I found that dpdk provides a api rte_eth_stats_get to read packet
>> statistics about the interface, includes total input/output
>> unicast/multicast/brodcast packets/bytes. but the api does not work on
>> VMxnet interface (which is a virtual interface in VMware machine).
>>
>
> Probably something in your app or environment rather than in the API
> itself. We run rte_eth_stats_get() against interfaces in VMware Fusion,
> VirtualBox and real hardware and they all work generally.
>
> Need some info before anyone can help you much:
>
> * What version of DPDK are you running?
> * What OS are you running on?
> * Output from "dpdk_nic_bind.py --status"?
>
> Jay
>

[dpdk-dev] [PATCH 08/11] pmdinfogen: fix usage message

[Neil Horman]

On Thu, Jul 07, 2016 at 06:24:16PM +0200, Thomas Monjalon wrote:
> 2016-07-07 12:05, Neil Horman:
> > On Thu, Jul 07, 2016 at 05:36:27PM +0200, Thomas Monjalon wrote:
> > > - "usage: pmdinfo  \n");
> > > + "usage: pmdinfogen  \n");
> > 
> > That should probably be an "%s...", argv[0], just to keep the name in line 
> > with
> > whatever its run as (via the symlink for instance)
> 
> Yes I was hesitating.
> I think argv[0] gives the full path. So it is often used with basename().
> Do you prefer this solution?

I think that makes more sense yes, given that pmdinfogen might be run as the
direct app or as the dpdk- prefixed symlink

Neil

> 
> 

[dpdk-dev] [PATCH 03/11] mk: fix build dependency of drivers on pmdinfogen

[Neil Horman]

On Thu, Jul 07, 2016 at 06:21:49PM +0200, Thomas Monjalon wrote:
> 2016-07-07 11:56, Neil Horman:
> > On Thu, Jul 07, 2016 at 05:36:22PM +0200, Thomas Monjalon wrote:
> > > When compiling the drivers, some code is generated with pmdinfogen.
> > > A fresh parallel build can fail if a driver is compiled before pmdinfogen:
> > >   build/buildtools/dpdk-pmdinfogen: Permission denied
> > > 
> > > There was a dependency declared in drivers/Makefile but it cannot work
> > > because this file is based on mk/rte.subdir.mk which do not handle
> > > dependencies.
> > > 
> > > It is fixed by declaring the whole buildtools as (order only) prerequisite
> > > of drivers.
> [...]
> > > --- a/drivers/Makefile
> > > +++ b/drivers/Makefile
> > > @@ -34,6 +34,4 @@ include $(RTE_SDK)/mk/rte.vars.mk
> > >  DIRS-y += net
> > >  DIRS-$(CONFIG_RTE_LIBRTE_CRYPTODEV) += crypto
> > >  
> > > -DEPDIRS-y += buildtools/pmdinfo
> > > -
> > >  include $(RTE_SDK)/mk/rte.subdir.mk
> > > diff --git a/mk/rte.sdkbuild.mk b/mk/rte.sdkbuild.mk
> > > index fb68af2..354f006 100644
> > > --- a/mk/rte.sdkbuild.mk
> > > +++ b/mk/rte.sdkbuild.mk
> > > @@ -49,6 +49,7 @@ $(1): $(sort $(LOCAL_DEPDIRS-$(1)))
> > >  endef
> > >  
> > >  $(foreach d,$(ROOTDIRS-y),$(eval $(call depdirs_rule,$(d
> > > +drivers: | buildtools
> > >  
> > I'm not sure i understand the reasoning here, DEPDIRS is meant to declare
> > prerequisites to a directory (and its children) getting built, right?  A 
> > parallel make should block any drivers getting built prior to pmdinfogen 
> > getting
> > built.  What am I missing?
> 
> DEPDIRS-y is not parsed at all in the context of rte.subdir.mk.
> That's why this line was ignored by the build system.
> 
Ah, ok then (though it seems like that might be a useful variable to query,
rather than dead reconing it inside the sdk build file

Acked-by: Neil Horman 

[dpdk-dev] [PATCH] ena: fix doorbell submission when not needed

[Jan Mędala]

Avoid submitting doorbell when:
* no packets have been submitted to TX
* no free resources have been submitted while RX

Sending doorbell without actual work to be performed by device
violates ENA specification and can lead to unpredictable behavior.

Fixes: 1173fca25af9 ("ena: add polling-mode driver")

Signed-off-by: Alexander Matushevsky 
Signed-off-by: Jan Medala 
---
 drivers/net/ena/ena_ethdev.c | 33 ++---
 1 file changed, 22 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index 702289b..d68e7ec 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -920,10 +920,14 @@ static int ena_populate_rx_queue(struct ena_ring
*rxq, unsigned int count)
  next_to_use = ENA_RX_RING_IDX_NEXT(next_to_use, ring_size);
  }

- rte_wmb();
- rxq->next_to_use = next_to_use;
- /* let HW know that it can fill buffers with data */
- ena_com_write_sq_doorbell(rxq->ena_com_io_sq);
+ /* When we submitted free recources to device... */
+ if (i > 0) {
+ /* ...let HW know that it can fill buffers with data */
+ rte_wmb();
+ ena_com_write_sq_doorbell(rxq->ena_com_io_sq);
+
+ rxq->next_to_use = next_to_use;
+ }

  return i;
 }
@@ -1316,7 +1320,7 @@ static uint16_t eth_ena_xmit_pkts(void *tx_queue,
struct rte_mbuf **tx_pkts,
  struct ena_tx_buffer *tx_info;
  struct ena_com_buf *ebuf;
  uint16_t rc, req_id, total_tx_descs = 0;
- int sent_idx = 0;
+ uint16_t sent_idx = 0;
  int nb_hw_desc;

  /* Check adapter state */
@@ -1395,9 +1399,14 @@ static uint16_t eth_ena_xmit_pkts(void *tx_queue,
struct rte_mbuf **tx_pkts,
  next_to_use = ENA_TX_RING_IDX_NEXT(next_to_use, ring_size);
  }

- /* Let HW do it's best :-) */
- rte_wmb();
- ena_com_write_sq_doorbell(tx_ring->ena_com_io_sq);
+ /* If there are ready packets to be xmitted... */
+ if (sent_idx > 0) {
+ /* ...let HW do its best :-) */
+ rte_wmb();
+ ena_com_write_sq_doorbell(tx_ring->ena_com_io_sq);
+
+ tx_ring->next_to_use = next_to_use;
+ }

  /* Clear complete packets  */
  while (ena_com_tx_comp_req_id_get(tx_ring->ena_com_io_cq, _id) >= 0) {
@@ -1420,9 +1429,11 @@ static uint16_t eth_ena_xmit_pkts(void *tx_queue,
struct rte_mbuf **tx_pkts,
  break;
  }

- /* acknowledge completion of sent packets */
- ena_com_comp_ack(tx_ring->ena_com_io_sq, total_tx_descs);
- tx_ring->next_to_use = next_to_use;
+ if (total_tx_descs > 0) {
+ /* acknowledge completion of sent packets */
+ ena_com_comp_ack(tx_ring->ena_com_io_sq, total_tx_descs);
+ }
+
  return sent_idx;
 }

-- 
2.8.1

[dpdk-dev] [PATCH v6 0/4] support reset of VF link

[Lu, Wenzhuo]

> -Original Message-
> From: Luca Boccassi [mailto:lboccass at Brocade.com]
> Sent: Thursday, July 7, 2016 6:21 PM
> To: Lu, Wenzhuo
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v6 0/4] support reset of VF link
> 
> On Thu, 2016-07-07 at 01:09 +, Lu, Wenzhuo wrote:
> > Hi Luca,
> >
> >
> > > -Original Message-
> > > From: Luca Boccassi [mailto:lboccass at Brocade.com]
> > > Sent: Thursday, July 7, 2016 12:23 AM
> > > To: Lu, Wenzhuo
> > > Cc: dev at dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH v6 0/4] support reset of VF link
> > >
> > > On Wed, 2016-07-06 at 00:45 +, Lu, Wenzhuo wrote:
> > > > Hi Luca,
> > > >
> > > > > -Original Message-
> > > > > From: Luca Boccassi [mailto:lboccass at Brocade.com]
> > > > > Sent: Tuesday, July 5, 2016 5:53 PM
> > > > > To: Lu, Wenzhuo
> > > > > Cc: dev at dpdk.org
> > > > > Subject: Re: [dpdk-dev] [PATCH v6 0/4] support reset of VF link
> > > > >
> > > > > On Tue, 2016-07-05 at 00:52 +, Lu, Wenzhuo wrote:
> > > > > > Hi Luca,
> > > > > >
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Luca Boccassi [mailto:lboccass at Brocade.com]
> > > > > > > Sent: Monday, July 4, 2016 11:48 PM
> > > > > > > To: Lu, Wenzhuo
> > > > > > > Cc: dev at dpdk.org
> > > > > > > Subject: Re: [dpdk-dev] [PATCH v6 0/4] support reset of VF
> > > > > > > link
> > > > > > >
> > > > > > > On Mon, 2016-06-20 at 14:24 +0800, Wenzhuo Lu wrote:
> > > > > > > > If the PF link is down and up, VF link will not work 
> > > > > > > > accordingly.
> > > > > > > > This patch set addes the support of VF link reset. So,
> > > > > > > > when VF receices the messges of physical link down/up. APP
> > > > > > > > can reset the VF link and let it recover.
> > > > > > > >
> > > > > > > > PS: This patch set is splitted from a previous patch set,
> > > > > > > > *automatic link recovery on ixgbe/igb VF*, and it's base
> > > > > > > > on the patch set *support mailbox interruption on ixgbe/igb VF*.
> > > > > > > >
> > > > > > > > Wenzhuo Lu (3):
> > > > > > > >   lib/librte_ether: support device reset
> > > > > > > >   ixgbe: implement device reset on VF
> > > > > > > >   igb: implement device reset on VF
> > > > > > > >
> > > > > > > > Zhe Tao (1):
> > > > > > > >   i40e: implement device reset on VF
> > > > > > > >
> > > > > > > > v1:
> > > > > > > > - Added the implementation for the VF reset functionality.
> > > > > > > > v2:
> > > > > > > > - Changed the i40e related operations during VF reset.
> > > > > > > > v3:
> > > > > > > > - Resent the patches because of the mail sent issue.
> > > > > > > > v4:
> > > > > > > > - Removed some VF reset emulation code.
> > > > > > > > v5:
> > > > > > > > - Removed all the code related with lock.
> > > > > > > > v6:
> > > > > > > > - Updated the NIC feature overview matrix.
> > > > > > > > - Added more explanation in the doxygen comment of reset API.
> > > > > > > >
> > > > > > > >  doc/guides/nics/overview.rst   |  1 +
> > > > > > > >  doc/guides/rel_notes/release_16_07.rst | 13 ++
> > > > > > > >  drivers/net/e1000/igb_ethdev.c | 59
> 
> > > > > > > >  drivers/net/i40e/i40e_ethdev.h |  4 ++
> > > > > > > >  drivers/net/i40e/i40e_ethdev_vf.c  | 83
> > > > > > > ++
> > > > > > > >  drivers/net/i40e/i40e_rxtx.c   | 10 
> > > > > > > >  drivers/net/i40e/i40e_rxtx.h   |  4 ++
> > > > > > > >  drivers/net/ixgbe/ixgbe_ethdev.c   | 64
> > > +-
> > > > > > > >  drivers/net/ixgbe/ixgbe_ethdev.h   |  2 +-
> > > > > > > >  drivers/net/ixgbe/ixgbe_rxtx.c | 12 +++--
> > > > > > > >  lib/librte_ether/rte_ethdev.c  | 17 +++
> > > > > > > >  lib/librte_ether/rte_ethdev.h  | 24 ++
> > > > > > > >  lib/librte_ether/rte_ether_version.map |  7 +++
> > > > > > > >  13 files changed, 295 insertions(+), 5 deletions(-)
> > > > > > >
> > > > > > > Hello Wenzhuo,
> > > > > > >
> > > > > > > I'm testing this patchset, but I am sporadically running
> > > > > > > into an issue where the VFs reset fails after the PF flaps.
> > > > > > >
> > > > > > > I have a VM running on a KVM box with a X540-AT2, passing 2 VFs 
> > > > > > > in.
> > > > > > >
> > > > > > > I am using calling rte_eth_dev_reset in response to a
> > > > > > > RTE_ETH_EVENT_INTR_RESET callback, and the following errors
> > > > > > > appear in the
> > > > > > > log:
> > > > > > >
> > > > > > > PMD: ixgbevf_dev_reset(): Ixgbe VF reset: Failed to update link.
> > > > > > > PMD: ixgbe_alloc_rx_queue_mbufs(): RX mbuf alloc failed
> > > > > > > queue_id=0
> > > > > > > PMD: ixgbevf_dev_start(): Unable to initialize RX hardware
> > > > > > > (-12)
> > > > > > > PMD: ixgbevf_dev_reset(): Ixgbe VF reset: Failed to start device.
> > > > > > >
> > > > > > > Jumping in with GDB, it seems that the rte_rxmbuf_alloc call
> > > > > > > in ixgbe_alloc_rx_queue_mbufs returns NULL at iteration 64 out of
> 2048.
> > 

[dpdk-dev] [PATCH] maintainers: claim responsibility for KNI

[Zhang, Helin]

> -Original Message-
> From: Yigit, Ferruh
> Sent: Thursday, July 7, 2016 7:00 PM
> To: dev at dpdk.org
> Cc: Zhang, Helin ; Thomas Monjalon
> 
> Subject: [PATCH] maintainers: claim responsibility for KNI
> 
> Signed-off-by: Ferruh Yigit 
Acked-by: Helin Zhang 

> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a59191e..250e542 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -249,7 +249,7 @@ F: app/test/test_link_bonding*
>  F: examples/bond/
> 
>  Linux KNI
> -M: Helin Zhang 
> +M: Ferruh Yigit 
>  F: lib/librte_eal/linuxapp/kni/
>  F: lib/librte_kni/
>  F: doc/guides/prog_guide/kernel_nic_interface.rst
> --
> 2.7.4

[dpdk-dev] [PATCH 2/2] examples/ipsec-secgw: add sample configuration files

[Fan Zhang]

This patch adds two sample configuration files to ipsec-secgw sample
application. The sample configuration files shows how to set-up systems
back-to-back that would forward traffic through an IPsec tunnel.

Signed-off-by: Fan Zhang 
---
 examples/ipsec-secgw/ep0.cfg | 119 +++
 examples/ipsec-secgw/ep1.cfg | 119 +++
 2 files changed, 238 insertions(+)
 create mode 100644 examples/ipsec-secgw/ep0.cfg
 create mode 100644 examples/ipsec-secgw/ep1.cfg

diff --git a/examples/ipsec-secgw/ep0.cfg b/examples/ipsec-secgw/ep0.cfg
new file mode 100644
index 000..be4732a
--- /dev/null
+++ b/examples/ipsec-secgw/ep0.cfg
@@ -0,0 +1,119 @@
+###
+#   IPSEC-SECGW Endpoint sample configuration
+#
+#   The main purpose of this file is to show how to configure two systems
+#   back-to-back that would forward traffic through an IPsec tunnel. This
+#   file is the Endpoint 0 configuration. To use this configuration file,
+#   add the following command-line option:
+#
+#   -f ./ep0.cfg
+#
+###
+
+#SP IPv4 rules
+sp ipv4 out esp protect 5 pri 1 dst 192.168.105.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 out esp protect 6 pri 1 dst 192.168.106.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 out esp protect 10 pri 1 dst 192.168.175.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 out esp protect 11 pri 1 dst 192.168.176.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 out esp protect 15 pri 1 dst 192.168.200.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 out esp protect 16 pri 1 dst 192.168.201.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 out esp protect 25 pri 1 dst 192.168.55.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 out esp protect 26 pri 1 dst 192.168.56.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 out esp bypass pri 1 dst 192.168.240.0/24 sport 0:65535 dport 0:65535
+sp ipv4 out esp bypass pri 1 dst 192.168.241.0/24 sport 0:65535 dport 0:65535
+
+sp ipv4 in esp protect 105 pri 1 dst 192.168.115.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 in esp protect 106 pri 1 dst 192.168.116.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 in esp protect 110 pri 1 dst 192.168.185.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 in esp protect 111 pri 1 dst 192.168.186.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 in esp protect 115 pri 1 dst 192.168.210.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 in esp protect 116 pri 1 dst 192.168.211.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 in esp protect 115 pri 1 dst 192.168.210.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 in esp protect 125 pri 1 dst 192.168.65.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 in esp protect 125 pri 1 dst 192.168.65.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 in esp protect 126 pri 1 dst 192.168.66.0/24 sport 0:65535 dport 
0:65535
+sp ipv4 in esp bypass pri 1 dst 192.168.245.0/24 sport 0:65535 dport 0:65535
+sp ipv4 in esp bypass pri 1 dst 192.168.246.0/24 sport 0:65535 dport 0:65535
+
+#SP IPv6 rules
+sp ipv6 out esp protect 5 pri 1 dst :::::::/96 
\
+sport 0:65535 dport 0:65535
+sp ipv6 out esp protect 6 pri 1 dst :::::::/96 
\
+sport 0:65535 dport 0:65535
+sp ipv6 out esp protect 10 pri 1 dst 
:::::::/96 \
+sport 0:65535 dport 0:65535
+sp ipv6 out esp protect 11 pri 1 dst 
:::::::/96 \
+sport 0:65535 dport 0:65535
+sp ipv6 out esp protect 25 pri 1 dst 
:::::::/96 \
+sport 0:65535 dport 0:65535
+sp ipv6 out esp protect 26 pri 1 dst 
:::::::/96 \
+sport 0:65535 dport 0:65535
+
+sp ipv6 in esp protect 15 pri 1 dst :::::::/96 
\
+sport 0:65535 dport 0:65535
+sp ipv6 in esp protect 16 pri 1 dst :::::::/96 
\
+sport 0:65535 dport 0:65535
+sp ipv6 in esp protect 110 pri 1 dst 
:::::::/96 \
+sport 0:65535 dport 0:65535
+sp ipv6 in esp protect 111 pri 1 dst 
:::::::/96 \
+sport 0:65535 dport 0:65535
+sp ipv6 in esp protect 125 pri 1 dst 
:::::::/96 \
+sport 0:65535 dport 0:65535
+sp ipv6 in esp protect 126 pri 1 dst 
:::::::/96 \
+sport 0:65535 dport 0:65535
+
+#SA rules
+sa out 5 aes-128-cbc sha1-hmac ipv4-tunnel src 172.16.1.5 dst 172.16.2.5
+sa out 6 aes-128-cbc sha1-hmac ipv4-tunnel src 172.16.1.6 dst 172.16.2.6
+sa out 10 aes-128-cbc sha1-hmac transport
+sa out 11 aes-128-cbc sha1-hmac transport
+sa out 15 null null ipv4-tunnel src 172.16.1.5 dst 172.16.2.5
+sa out 16 null null ipv4-tunnel src 172.16.1.6 dst 172.16.2.6
+sa out 25 aes-128-cbc sha1-hmac ipv6-tunnel \
+src ::::::: \
+dst :::::::
+sa out 26 aes-128-cbc sha1-hmac ipv6-tunnel \
+src 

[dpdk-dev] [PATCH 1/2] examples/ipsec_secgw: add configuration file support

[Fan Zhang]

This patch adds the configuration file support to ipsec_secgw
sample application. Instead of hard-coded rules, the users can
specify their own SP, SA, and routing rules in the configuration
file. An command line option "-f" is added to pass the
configuration file location to the application.

Configuration item formats:

SP rule format:
sp   esp \
  

SA rule format:
sa   

Routing rule format:
rt

Signed-off-by: Fan Zhang 
---
 doc/guides/sample_app_ug/ipsec_secgw.rst | 806 ---
 examples/ipsec-secgw/Makefile|   1 +
 examples/ipsec-secgw/ipsec-secgw.c   |  48 +-
 examples/ipsec-secgw/ipsec.h |   8 +-
 examples/ipsec-secgw/parser.c| 602 +++
 examples/ipsec-secgw/parser.h| 116 +
 examples/ipsec-secgw/rt.c| 255 +-
 examples/ipsec-secgw/sa.c| 428 
 examples/ipsec-secgw/sp4.c   | 523 +++-
 examples/ipsec-secgw/sp6.c   | 524 +---
 10 files changed, 2073 insertions(+), 1238 deletions(-)
 create mode 100644 examples/ipsec-secgw/parser.c
 create mode 100644 examples/ipsec-secgw/parser.h

diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst 
b/doc/guides/sample_app_ug/ipsec_secgw.rst
index fcb33c2..125bfa7 100644
--- a/doc/guides/sample_app_ug/ipsec_secgw.rst
+++ b/doc/guides/sample_app_ug/ipsec_secgw.rst
@@ -122,7 +122,7 @@ The application has a number of command line options::
 -p PORTMASK -P -u PORTMASK
 --config (port,queue,lcore)[,(port,queue,lcore]
 --single-sa SAIDX
-   --ep0|--ep1
+   -f config_file_path

 Where:

@@ -142,14 +142,10 @@ Where:
 on both Inbound and Outbound. This option is meant for 
debugging/performance
 purposes.

-*   ``--ep0``: configure the app as Endpoint 0.
+*   ``-f config_file_path``: the full path of text-based file containing all
+configuration items for running the application (See Configuration file
+syntax section below). ``-f config_file_path`` **must** be specified.

-*   ``--ep1``: configure the app as Endpoint 1.
-
-Either one of ``--ep0`` or ``--ep1`` **must** be specified.
-The main purpose of these options is to easily configure two systems
-back-to-back that would forward traffic through an IPsec tunnel (see
-:ref:`figure_ipsec_endpoints`).

 The mapping of lcores to port/queues is similar to other l3fwd applications.

@@ -157,7 +153,8 @@ For example, given the following command line::

 ./build/ipsec-secgw -l 20,21 -n 4 --socket-mem 0,2048   \
--vdev "cryptodev_null_pmd" -- -p 0xf -P -u 0x3  \
-   --config="(0,0,20),(1,0,20),(2,0,21),(3,0,21)" --ep0 \
+   --config="(0,0,20),(1,0,20),(2,0,21),(3,0,21)"   \
+   -f /path/to/config_file  \

 where each options means:

@@ -194,8 +191,10 @@ where each options means:
 |  |   |   |   
|
 
+--+---+---+---+

-*   The ``--ep0`` options configures the app with a given set of SP, SA and 
Routing
-entries as explained below in more detail.
+*   The ``-f /path/to/config_file`` option enables the application read and 
+parse the configuration file specified, and configures the application
+with a given set of SP, SA and Routing entries accordingly. The syntax of
+the configuration file will be explained below in more detail.

 Refer to the *DPDK Getting Started Guide* for general information on running
 applications and the Environment Abstraction Layer (EAL) options.
@@ -219,496 +218,321 @@ For example, something like the following command line:
 --vdev "cryptodev_aesni_mb_pmd" --vdev "cryptodev_null_pmd" \
-- \
 -p 0xf -P -u 0x3 --config="(0,0,20),(1,0,20),(2,0,21),(3,0,21)" \
---ep0
+-f path/to/config_file


 Configurations
 --

-The following sections provide some details on the default values used to
-initialize the SP, SA and Routing tables.
-Currently all configuration information is hard coded into the application.
+The following sections provide the syntax of configurations to initialize 
+your SP, SA and Routing tables.
+Configurations shall be specified in the configuration file to be passed to
+the application. The file is then parsed by the application. The successful
+parsing will result in the appropriate rules being applied to the tables 
+accordingly.

-The following image illustrate a few of the concepts regarding IPSec, such
-as protected/unprotected and inbound/outbound traffic, from the point of
-view of two back-to-back endpoints:

-.. _figure_ipsec_endpoints:
+Configuration File Syntax
+~~

-.. figure:: img/ipsec_endpoints.*
+As mention in the 

[dpdk-dev] [PATCH 0/2] examples/ipsec_secgw: add configuration file support

[Fan Zhang]

This patchset adds the configuration file supported to ipsec_secgw
sample application. Two sample configuration files, ep0.cfg and ep1.cfg
are also added to show how to configure two systems back-to-back that 
would forward traffic through an IPsec tunnel

Fan Zhang (2):
  examples/ipsec_secgw: add configuration file support
  examples/ipsec-secgw: add sample configuration files

 doc/guides/sample_app_ug/ipsec_secgw.rst | 806 ---
 examples/ipsec-secgw/Makefile|   1 +
 examples/ipsec-secgw/ep0.cfg | 119 +
 examples/ipsec-secgw/ep1.cfg | 119 +
 examples/ipsec-secgw/ipsec-secgw.c   |  48 +-
 examples/ipsec-secgw/ipsec.h |   8 +-
 examples/ipsec-secgw/parser.c| 602 +++
 examples/ipsec-secgw/parser.h| 116 +
 examples/ipsec-secgw/rt.c| 255 +-
 examples/ipsec-secgw/sa.c| 428 
 examples/ipsec-secgw/sp4.c   | 523 +++-
 examples/ipsec-secgw/sp6.c   | 524 +---
 12 files changed, 2311 insertions(+), 1238 deletions(-)
 create mode 100644 examples/ipsec-secgw/ep0.cfg
 create mode 100644 examples/ipsec-secgw/ep1.cfg
 create mode 100644 examples/ipsec-secgw/parser.c
 create mode 100644 examples/ipsec-secgw/parser.h

-- 
2.5.5

[dpdk-dev] [PATCH v2] i40: fix the VXLAN TSO issue

[Zhe Tao]

Problem:
When using the TSO + VXLAN feature in i40e, the outer UDP length fields in
the multiple UDP segments which are TSOed by the i40e will have the
wrong value.

Fix this problem by adding the tunnel type field in the i40e descriptor
which was missed before.

Fixes: 77b8301733c3 ("i40e: VXLAN Tx checksum offload")

Signed-off-by: Zhe Tao 
---
V2: Edited some comments for mbuf structure and i40e driver.

 app/test-pmd/csumonly.c  | 26 +++---
 drivers/net/i40e/i40e_rxtx.c | 12 +---
 lib/librte_mbuf/rte_mbuf.h   | 16 +++-
 3 files changed, 43 insertions(+), 11 deletions(-)

diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index ac4bd8f..d423c20 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -204,7 +204,8 @@ parse_ethernet(struct ether_hdr *eth_hdr, struct 
testpmd_offload_info *info)
 static void
 parse_vxlan(struct udp_hdr *udp_hdr,
struct testpmd_offload_info *info,
-   uint32_t pkt_type)
+   uint32_t pkt_type,
+   uint64_t *ol_flags)
 {
struct ether_hdr *eth_hdr;

@@ -215,6 +216,7 @@ parse_vxlan(struct udp_hdr *udp_hdr,
RTE_ETH_IS_TUNNEL_PKT(pkt_type) == 0)
return;

+   *ol_flags |= PKT_TX_TUNNEL_VXLAN;
info->is_tunnel = 1;
info->outer_ethertype = info->ethertype;
info->outer_l2_len = info->l2_len;
@@ -231,7 +233,9 @@ parse_vxlan(struct udp_hdr *udp_hdr,

 /* Parse a gre header */
 static void
-parse_gre(struct simple_gre_hdr *gre_hdr, struct testpmd_offload_info *info)
+parse_gre(struct simple_gre_hdr *gre_hdr,
+ struct testpmd_offload_info *info,
+ uint64_t *ol_flags)
 {
struct ether_hdr *eth_hdr;
struct ipv4_hdr *ipv4_hdr;
@@ -242,6 +246,8 @@ parse_gre(struct simple_gre_hdr *gre_hdr, struct 
testpmd_offload_info *info)
if ((gre_hdr->flags & _htons(~GRE_SUPPORTED_FIELDS)) != 0)
return;

+   *ol_flags |= PKT_TX_TUNNEL_GRE;
+
gre_len += sizeof(struct simple_gre_hdr);

if (gre_hdr->flags & _htons(GRE_KEY_PRESENT))
@@ -417,7 +423,7 @@ process_inner_cksums(void *l3_hdr, const struct 
testpmd_offload_info *info,
  * packet */
 static uint64_t
 process_outer_cksums(void *outer_l3_hdr, struct testpmd_offload_info *info,
-   uint16_t testpmd_ol_flags)
+   uint16_t testpmd_ol_flags, uint64_t orig_ol_flags)
 {
struct ipv4_hdr *ipv4_hdr = outer_l3_hdr;
struct ipv6_hdr *ipv6_hdr = outer_l3_hdr;
@@ -442,6 +448,9 @@ process_outer_cksums(void *outer_l3_hdr, struct 
testpmd_offload_info *info,
 * hardware supporting it today, and no API for it. */

udp_hdr = (struct udp_hdr *)((char *)outer_l3_hdr + info->outer_l3_len);
+   if ((orig_ol_flags & PKT_TX_TCP_SEG) &&
+   ((orig_ol_flags & PKT_TX_TUNNEL_MASK) == PKT_TX_TUNNEL_VXLAN))
+   udp_hdr->dgram_cksum = 0;
/* do not recalculate udp cksum if it was 0 */
if (udp_hdr->dgram_cksum != 0) {
udp_hdr->dgram_cksum = 0;
@@ -705,15 +714,18 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
if (info.l4_proto == IPPROTO_UDP) {
struct udp_hdr *udp_hdr;
udp_hdr = (struct udp_hdr *)((char *)l3_hdr +
-   info.l3_len);
-   parse_vxlan(udp_hdr, , m->packet_type);
+  info.l3_len);
+   parse_vxlan(udp_hdr, , m->packet_type,
+   _flags);
} else if (info.l4_proto == IPPROTO_GRE) {
struct simple_gre_hdr *gre_hdr;
gre_hdr = (struct simple_gre_hdr *)
((char *)l3_hdr + info.l3_len);
-   parse_gre(gre_hdr, );
+   parse_gre(gre_hdr, , _flags);
} else if (info.l4_proto == IPPROTO_IPIP) {
void *encap_ip_hdr;
+
+   ol_flags |= PKT_TX_TUNNEL_IPIP;
encap_ip_hdr = (char *)l3_hdr + info.l3_len;
parse_encap_ip(encap_ip_hdr, );
}
@@ -745,7 +757,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
 * processed in hardware. */
if (info.is_tunnel == 1) {
ol_flags |= process_outer_cksums(outer_l3_hdr, ,
-   testpmd_ol_flags);
+   testpmd_ol_flags, ol_flags);
}

/* step 4: fill the mbuf meta data (flags and header lengths) */
diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index 049a813..4c987f2 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -801,6 

[dpdk-dev] [RFC] Generic flow director/filtering/classification API

[Adrien Mazarguil]

Hi Lu Wenzhuo,

Thanks for your feedback, I'm replying below as well.

On Thu, Jul 07, 2016 at 07:14:18AM +, Lu, Wenzhuo wrote:
> Hi Adrien,
> I have some questions, please see inline, thanks.
> 
> > -Original Message-
> > From: Adrien Mazarguil [mailto:adrien.mazarguil at 6wind.com]
> > Sent: Wednesday, July 6, 2016 2:17 AM
> > To: dev at dpdk.org
> > Cc: Thomas Monjalon; Zhang, Helin; Wu, Jingjing; Rasesh Mody; Ajit Khaparde;
> > Rahul Lakkireddy; Lu, Wenzhuo; Jan Medala; John Daley; Chen, Jing D; 
> > Ananyev,
> > Konstantin; Matej Vido; Alejandro Lucero; Sony Chacko; Jerin Jacob; De Lara
> > Guarch, Pablo; Olga Shern
> > Subject: [RFC] Generic flow director/filtering/classification API
> > 
> > 
> > Requirements for a new API:
> > 
> > - Flexible and extensible without causing API/ABI problems for existing
> >   applications.
> > - Should be unambiguous and easy to use.
> > - Support existing filtering features and actions listed in `Filter types`_.
> > - Support packet alteration.
> > - In case of overlapping filters, their priority should be well documented.
> Does that mean we don't guarantee the consistent of priority? The priority 
> can be different on different NICs. So the behavior of the actions  can be 
> different. Right?

No, the intent is precisely to define what happens in order to get a
consistent result across different devices, and document cases with
undefined behavior. There must be no room left for interpretation.

For example, the API must describe what happens when two overlapping filters
(e.g. one matching an Ethernet header, another one matching an IP header)
match a given packet at a given priority level.

It is documented in section 4.1.1 (priorities) as "undefined behavior".
Applications remain free to do it and deal with consequences, at least they
know they cannot expect a consistent outcome, unless they use different
priority levels for both rules, see also 4.4.5 (flow rules priority).

> Seems the users still need to aware the some details of the HW? Do we need to 
> add the negotiation for the priority?

Priorities as defined in this document may not be directly mappable to HW
capabilities (e.g. HW does not support enough priorities, or that some
corner case make them not work as described), in which case the PMD may
choose to simulate priorities (again 4.4.5), as long as the end result
follows the specification.

So users must not be aware of some HW details, the PMD does and must perform
the needed workarounds to suit their expectations. Users may only be
impacted by errors while attempting to create rules that are either
unsupported or would cause them (or existing rules) to diverge from the
spec.

> > Flow rules can have several distinct actions (such as counting,
> > encapsulating, decapsulating before redirecting packets to a particular
> > queue, etc.), instead of relying on several rules to achieve this and having
> > applications deal with hardware implementation details regarding their
> > order.
> I think normally HW doesn't support several actions in one rule. If a rule 
> has several actions, seems HW has to split it to several rules. The order can 
> still be a problem.

Note that, except for a very small subset of pattern items and actions,
supporting multiple actions for a given rule is not mandatory, and can be
emulated as you said by having to split them into several rules each with
its own priority if possible (see 3.3 "high level design").

Also, a rule "action" as defined in this API can be just about anything, for
example combining a queue redirection with 32-bit tagging. FDIR supports
many cases of what can be described as several actions, see 5.7 "FDIR to
most item types ? QUEUE, DROP, PASSTHRU".

If you were thinking about having two queue targets for a given rule, then
I agree with you - that is why a rule cannot have more than a single action
of a given type (see 4.1.5 actions), to avoid such abuse from applications.

Applications must use several pass-through rules with different priority
levels if they want to perform a given action several times on a given
packet. Again, PMDs support is not mandatory as pass-through is optional.

> > ``ETH``
> > ^^^
> > 
> > Matches an Ethernet header.
> > 
> > - ``dst``: destination MAC.
> > - ``src``: source MAC.
> > - ``type``: EtherType.
> > - ``tags``: number of 802.1Q/ad tags defined.
> > - ``tag[]``: 802.1Q/ad tag definitions, innermost first. For each one:
> > 
> >  - ``tpid``: Tag protocol identifier.
> >  - ``tci``: Tag control information.
> "ETH" means all the parameters, dst, src, type... need to be matched? The 
> same question for IPv4, IPv6 ...

Yes, it's basically the description of all Ethernet header fields including
VLAN tags (same for other protocols). Please see the linked draft header
file which should make all of this easier to understand:

 https://raw.githubusercontent.com/6WIND/rte_flow/master/rte_flow.h

> > ``UDP``
> > ^^^
> > 
> > Matches a UDP header.
> > 

[dpdk-dev] [PATCH v2] i40: fix the VXLAN TSO issue

[Ananyev, Konstantin]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ananyev, Konstantin
> Sent: Thursday, July 07, 2016 11:51 AM
> To: Tao, Zhe; dev at dpdk.org
> Cc: Tao, Zhe; Wu, Jingjing
> Subject: Re: [dpdk-dev] [PATCH v2] i40: fix the VXLAN TSO issue
> 
> 
> Hi Tao,
> 
> Sorry hit send button too early by accident :)
> 
> > >
> > > Problem:
> > > When using the TSO + VXLAN feature in i40e, the outer UDP length fields in
> > > the multiple UDP segments which are TSOed by the i40e will have the
> > > wrong value.
> > >
> > > Fix this problem by adding the tunnel type field in the i40e descriptor
> > > which was missed before.
> > >
> > > Fixes: 77b8301733c3 ("i40e: VXLAN Tx checksum offload")
> > >
> > > Signed-off-by: Zhe Tao 
> > > ---
> > > V2: Edited some comments for mbuf structure and i40e driver.
> > >
> > >  app/test-pmd/csumonly.c  | 26 +++---
> > >  drivers/net/i40e/i40e_rxtx.c | 12 +---
> > >  lib/librte_mbuf/rte_mbuf.h   | 16 +++-
> > >  3 files changed, 43 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
> > > index ac4bd8f..d423c20 100644
> > > --- a/app/test-pmd/csumonly.c
> > > +++ b/app/test-pmd/csumonly.c
> > > @@ -204,7 +204,8 @@ parse_ethernet(struct ether_hdr *eth_hdr, struct 
> > > testpmd_offload_info *info)
> > >  static void
> > >  parse_vxlan(struct udp_hdr *udp_hdr,
> > >   struct testpmd_offload_info *info,
> > > - uint32_t pkt_type)
> > > + uint32_t pkt_type,
> > > + uint64_t *ol_flags)
> > >  {
> > >   struct ether_hdr *eth_hdr;
> > >
> > > @@ -215,6 +216,7 @@ parse_vxlan(struct udp_hdr *udp_hdr,
> > >   RTE_ETH_IS_TUNNEL_PKT(pkt_type) == 0)
> > >   return;
> > >
> > > + *ol_flags |= PKT_TX_TUNNEL_VXLAN;

Do we always have to setup tunnelling flags here?
Obviously it would mean an extra CTD per packet and might slowdown things.
In fact, I think current patch wouldn't work correctly if
TESTPMD_TX_OFFLOAD_OUTER_IP_CKSUM is not set.
So, can we do it only when TSO is enabled or outer IP checksum is enabled?

> > >   info->is_tunnel = 1;
> > >   info->outer_ethertype = info->ethertype;
> > >   info->outer_l2_len = info->l2_len;
> > > @@ -231,7 +233,9 @@ parse_vxlan(struct udp_hdr *udp_hdr,
> > >
> > >  /* Parse a gre header */
> > >  static void
> > > -parse_gre(struct simple_gre_hdr *gre_hdr, struct testpmd_offload_info 
> > > *info)
> > > +parse_gre(struct simple_gre_hdr *gre_hdr,
> > > +   struct testpmd_offload_info *info,
> > > +   uint64_t *ol_flags)
> > >  {
> > >   struct ether_hdr *eth_hdr;
> > >   struct ipv4_hdr *ipv4_hdr;
> > > @@ -242,6 +246,8 @@ parse_gre(struct simple_gre_hdr *gre_hdr, struct 
> > > testpmd_offload_info *info)
> > >   if ((gre_hdr->flags & _htons(~GRE_SUPPORTED_FIELDS)) != 0)
> > >   return;
> > >
> > > + *ol_flags |= PKT_TX_TUNNEL_GRE;
> > > +
> > >   gre_len += sizeof(struct simple_gre_hdr);
> > >
> > >   if (gre_hdr->flags & _htons(GRE_KEY_PRESENT))
> > > @@ -417,7 +423,7 @@ process_inner_cksums(void *l3_hdr, const struct 
> > > testpmd_offload_info *info,
> > >   * packet */
> > >  static uint64_t
> > >  process_outer_cksums(void *outer_l3_hdr, struct testpmd_offload_info 
> > > *info,
> > > - uint16_t testpmd_ol_flags)
> > > + uint16_t testpmd_ol_flags, uint64_t orig_ol_flags)
> > >  {
> > >   struct ipv4_hdr *ipv4_hdr = outer_l3_hdr;
> > >   struct ipv6_hdr *ipv6_hdr = outer_l3_hdr;
> > > @@ -442,6 +448,9 @@ process_outer_cksums(void *outer_l3_hdr, struct 
> > > testpmd_offload_info *info,
> > >* hardware supporting it today, and no API for it. */
> > >
> > >   udp_hdr = (struct udp_hdr *)((char *)outer_l3_hdr + info->outer_l3_len);
> > > + if ((orig_ol_flags & PKT_TX_TCP_SEG) &&
> > > + ((orig_ol_flags & PKT_TX_TUNNEL_MASK) == PKT_TX_TUNNEL_VXLAN))
> > > + udp_hdr->dgram_cksum = 0;
> > >   /* do not recalculate udp cksum if it was 0 */
> > >   if (udp_hdr->dgram_cksum != 0) {
> > >   udp_hdr->dgram_cksum = 0;
> > > @@ -705,15 +714,18 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
> > >   if (info.l4_proto == IPPROTO_UDP) {
> > >   struct udp_hdr *udp_hdr;
> > >   udp_hdr = (struct udp_hdr *)((char *)l3_hdr +
> > > - info.l3_len);
> > > - parse_vxlan(udp_hdr, , m->packet_type);
> > > +info.l3_len);
> > > + parse_vxlan(udp_hdr, , m->packet_type,
> > > + _flags);
> > >   } else if (info.l4_proto == IPPROTO_GRE) {
> > >   struct simple_gre_hdr *gre_hdr;
> > >   gre_hdr = (struct simple_gre_hdr *)
> > >   ((char *)l3_hdr + info.l3_len);
> > > - parse_gre(gre_hdr, );
> > > + parse_gre(gre_hdr, , _flags);

[dpdk-dev] [PATCH 11/11] maintainers: add section for pmdinfo

[Neil Horman]

On Thu, Jul 07, 2016 at 05:45:09PM +0200, Thomas Monjalon wrote:
> Neil,
> 
> I would gladly drop this patch from the series if you send a similar one
> with your name as maintainer.
> 
> Thanks
> 
Lets get through the rest of this stuff first, then I'll send it when we're
complete.  Sound good?
Neil

> 
> 2016-07-07 17:36, Thomas Monjalon:
> > The author of this feature is Neil Horman.
> > 
> > Signed-off-by: Thomas Monjalon 
> > ---
> > +Driver information
> > +F: buildtools/pmdinfogen/
> > +F: tools/pmdinfo.py
> 
> 
> 

[dpdk-dev] [PATCH 11/11] maintainers: add section for pmdinfo

[Neil Horman]

On Thu, Jul 07, 2016 at 05:36:30PM +0200, Thomas Monjalon wrote:
> The author of this feature is Neil Horman.
> 
> Signed-off-by: Thomas Monjalon 
> ---
>  MAINTAINERS | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a59191e..f996c2e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -68,6 +68,10 @@ F: lib/librte_compat/
>  F: doc/guides/rel_notes/deprecation.rst
>  F: scripts/validate-abi.sh
>  
> +Driver information
> +F: buildtools/pmdinfogen/
> +F: tools/pmdinfo.py
> +
>  
>  Environment Abstraction Layer
>  -
> -- 
> 2.7.0
> 
> 
Acked-by: Neil Horman 

[dpdk-dev] [PATCH 10/11] doc: fix syntax in pmdinfogen guide

[Neil Horman]

On Thu, Jul 07, 2016 at 05:36:29PM +0200, Thomas Monjalon wrote:
> Sphynx reports this error:
> 
> doc/guides/prog_guide/dev_kit_build_system.rst:337: WARNING:
> Pygments lexer name u'C' is not known
> 
> Fixes: 737ddf3fb ("doc: add prog guide section documenting pmdinfo script")
> 
> Signed-off-by: Thomas Monjalon 
> ---
>  doc/guides/prog_guide/dev_kit_build_system.rst | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/doc/guides/prog_guide/dev_kit_build_system.rst 
> b/doc/guides/prog_guide/dev_kit_build_system.rst
> index 1dc1388..18a3010 100644
> --- a/doc/guides/prog_guide/dev_kit_build_system.rst
> +++ b/doc/guides/prog_guide/dev_kit_build_system.rst
> @@ -319,8 +319,7 @@ instance the macro:
>  
>  .. code-block:: c
>  
> -PMD_REGISTER_DRIVER(drv, name)
> -
> +   PMD_REGISTER_DRIVER(drv, name)
>  
>  Creates the following symbol:
>  
> @@ -334,7 +333,7 @@ can be exported from the object file and used to produce 
> a hardware support
>  description, that pmdinfogen then encodes into a json formatted string in the
>  following format:
>  
> -.. code-block:: C
> +.. code-block:: c
>  
> static char ="PMD_INFO_STRING=\"{'name' : '', 
> ...}\"";
>  
> -- 
> 2.7.0
> 
> 
Acked-by: Neil Horman 

[dpdk-dev] [PATCH 09/11] eal: move PCI table macro

[Neil Horman]

On Thu, Jul 07, 2016 at 05:36:28PM +0200, Thomas Monjalon wrote:
> Remove include of rte_pci.h in the generic header rte_dev.h
> and move the macro DRIVER_REGISTER_PCI_TABLE in rte_pci.h.
> 
> Fixes: cb6696d22023 ("drivers: update registration macro usage")
> 
> Signed-off-by: Thomas Monjalon 
> ---
>  lib/librte_eal/common/include/rte_dev.h | 6 +-
>  lib/librte_eal/common/include/rte_pci.h | 5 +
>  2 files changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/lib/librte_eal/common/include/rte_dev.h 
> b/lib/librte_eal/common/include/rte_dev.h
> index e6f0d4c..68ca7ef 100644
> --- a/lib/librte_eal/common/include/rte_dev.h
> +++ b/lib/librte_eal/common/include/rte_dev.h
> @@ -48,7 +48,7 @@ extern "C" {
>  
>  #include 
>  #include 
> -#include 
> +
>  #include 
>  
>  __attribute__((format(printf, 2, 0)))
> @@ -195,10 +195,6 @@ DRIVER_EXPORT_NAME(nm, __COUNTER__)
>  
>  #define DRV_EXP_TAG(name, tag) __##name##_##tag
>  
> -#define DRIVER_REGISTER_PCI_TABLE(name, table) \
> -static const char DRV_EXP_TAG(name, pci_tbl_export)[] __attribute__((used)) 
> = \
> -RTE_STR(table)
> -
>  #define DRIVER_REGISTER_PARAM_STRING(name, str) \
>  static const char DRV_EXP_TAG(name, param_string_export)[] \
>  __attribute__((used)) = str
> diff --git a/lib/librte_eal/common/include/rte_pci.h 
> b/lib/librte_eal/common/include/rte_pci.h
> index fa74962..3b0d26a 100644
> --- a/lib/librte_eal/common/include/rte_pci.h
> +++ b/lib/librte_eal/common/include/rte_pci.h
> @@ -188,6 +188,11 @@ struct rte_pci_device {
>   .subsystem_device_id = PCI_ANY_ID
>  #endif
>  
> +#define DRIVER_REGISTER_PCI_TABLE(name, table) \
> +static const char __##name##_pci_tbl_export[] \
> + __attribute__((used)) = \
> + RTE_STR(table)
> +
>  struct rte_pci_driver;
>  
>  /**
> -- 
> 2.7.0
> 
> 

This seems strange to me, in that its odd for the driver information export
macros to be spread out in multiple locations.  Specifically it enjoins the use
of the DRV_EXP_TAG macro, which helps centralize tag naming.  Perhaps the happy
medium is to place all the export macros (includnig PMD_REGISTER_DRIVER) into
its own pmd_register.h header?

[dpdk-dev] [PATCH 08/11] pmdinfogen: fix usage message

[Neil Horman]

On Thu, Jul 07, 2016 at 05:36:27PM +0200, Thomas Monjalon wrote:
> The name of the tool is pmdinfogen.
> 
> Fixes: 98b0fdb0ffc6 ("pmdinfogen: add buildtools and pmdinfogen utility")
> 
> Signed-off-by: Thomas Monjalon 
> ---
>  buildtools/pmdinfogen/pmdinfogen.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/buildtools/pmdinfogen/pmdinfogen.c 
> b/buildtools/pmdinfogen/pmdinfogen.c
> index beb06f1..1b7b931 100644
> --- a/buildtools/pmdinfogen/pmdinfogen.c
> +++ b/buildtools/pmdinfogen/pmdinfogen.c
> @@ -398,7 +398,7 @@ int main(int argc, char **argv)
>  
>   if (argc < 3) {
>   fprintf(stderr,
> - "usage: pmdinfo  \n");
> + "usage: pmdinfogen  \n");
>   exit(127);
>   }
>   parse_elf(, argv[1]);
> -- 
> 2.7.0
> 
> 

That should probably be an "%s...", argv[0], just to keep the name in line with
whatever its run as (via the symlink for instance)

Neil

[dpdk-dev] [PATCH 06/11] mk: fix verbose pmdinfogen run

[Neil Horman]

On Thu, Jul 07, 2016 at 05:36:25PM +0200, Thomas Monjalon wrote:
> When building with "make V=1" it is expected to see the output of each
> compiler command in order to debug them.
> Unfortunately the pmdinfogen related commands were always quiet.
> 
> It is fixed by defining the commands in some Makefile variables.
> They are printed if the verbose mode is enabled.
> 
> The other benefit of this rework is to stop compilation after a
> failure with pmdinfogen.
> 
> The command readlink is removed in this rework because it seems useless.
> 
> Fixes: 3d781ca32874 ("mk: do post processing on objects that register a 
> driver")
> 
> Signed-off-by: Thomas Monjalon 
> ---
>  mk/internal/rte.compile-pre.mk | 26 --
>  1 file changed, 12 insertions(+), 14 deletions(-)
> 
> diff --git a/mk/internal/rte.compile-pre.mk b/mk/internal/rte.compile-pre.mk
> index 87d2d93..9c25ff6 100644
> --- a/mk/internal/rte.compile-pre.mk
> +++ b/mk/internal/rte.compile-pre.mk
> @@ -84,28 +84,26 @@ C_TO_O = $(CC) -Wp,-MD,$(call obj2dep,$(@)).tmp $(CFLAGS) 
> \
>  C_TO_O_STR = $(subst ','\'',$(C_TO_O)) #'# fix syntax highlight
>  C_TO_O_DISP = $(if $(V),"$(C_TO_O_STR)","  CC $(@)")
>  endif
> +PMDINFO_GEN = $(RTE_SDK_BIN)/app/pmdinfogen $@ $@.pmd.c
> +PMDINFO_CC = $(CC) $(CFLAGS) -c -o $@.pmd.o $@.pmd.c
> +PMDINFO_LD = $(CROSS)ld $(LDFLAGS) -r -o $@.o $@.pmd.o $@
> +PMDINFO_TO_O = if grep -q 'PMD_REGISTER_DRIVER(.*)' $<; then \
> + echo "$(if $V,$(PMDINFO_GEN),  PMDINFO $@.pmd.c)" && \
> + $(PMDINFO_GEN) && \
> + echo "$(if $V,$(PMDINFO_CC),  CC $@.pmd.o)" && \
> + $(PMDINFO_CC) && \
> + echo "$(if $V,$(PMDINFO_LD),  LD $@)" && \
> + $(PMDINFO_LD) && \
> + mv -f $@.o $@; fi
>  C_TO_O_CMD = 'cmd_$@ = $(C_TO_O_STR)'
>  C_TO_O_DO = @set -e; \
>   echo $(C_TO_O_DISP); \
>   $(C_TO_O) && \
> - sh -c "grep -q \"PMD_REGISTER_DRIVER(.*)\" $<; \
> - if [ \$$? -eq 0 ]; then \
> - echo \"  PMDINFOGEN\" $@; \
> - OBJF=`readlink -f $@`; \
> - $(RTE_SDK_BIN)/app/pmdinfogen \$$OBJF \$$OBJF.pmd.c; \
> - if [ \$$? -eq 0 ]; \
> - then \
> - echo \"  PMDINFOBUILD\" $@; \
> - $(CC) $(CFLAGS) -c -o \$$OBJF.pmd.o \$$OBJF.pmd.c; \
> - $(CROSS)ld $(LDFLAGS) -r -o \$$OBJF.o \$$OBJF.pmd.o 
> \$$OBJF; \
> - mv -f \$$OBJF.o \$$OBJF; \
> - fi; \
> - fi;" && \
> + $(PMDINFO_TO_O) && \
>   echo $(C_TO_O_CMD) > $(call obj2cmd,$(@)) && \
>   sed 's,'$@':,dep_'$@' =,' $(call obj2dep,$(@)).tmp > $(call 
> obj2dep,$(@)) && \
>   rm -f $(call obj2dep,$(@)).tmp
>  
> -
>  # return an empty string if string are equal
>  compare = $(strip $(subst $(1),,$(2)) $(subst $(2),,$(1)))
>  
> -- 
> 2.7.0
> 
> 
Acked-by: Neil Horman 

[dpdk-dev] [PATCH 04/11] mk: remove traces of hostapp build directory

[Neil Horman]

On Thu, Jul 07, 2016 at 05:36:23PM +0200, Thomas Monjalon wrote:
> The recipe rte.hostapp.mk does not build in hostapp/ anymore.
> 
> Fixes: 98b0fdb0ffc6 ("pmdinfogen: add buildtools and pmdinfogen utility")
> 
> Signed-off-by: Thomas Monjalon 
> ---
>  doc/guides/freebsd_gsg/build_dpdk.rst | 2 +-
>  doc/guides/linux_gsg/build_dpdk.rst   | 2 +-
>  mk/rte.sdkbuild.mk| 5 ++---
>  mk/rte.sdkconfig.mk   | 2 +-
>  4 files changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/doc/guides/freebsd_gsg/build_dpdk.rst 
> b/doc/guides/freebsd_gsg/build_dpdk.rst
> index 1d92c08..93c4366 100644
> --- a/doc/guides/freebsd_gsg/build_dpdk.rst
> +++ b/doc/guides/freebsd_gsg/build_dpdk.rst
> @@ -183,7 +183,7 @@ contains the kernel modules to install:
>  
>  ls x86_64-native-bsdapp-gcc
>  
> -app build hostapp include kmod lib Makefile
> +app build include kmod lib Makefile
>  
>  
>  .. _loading_contigmem:
> diff --git a/doc/guides/linux_gsg/build_dpdk.rst 
> b/doc/guides/linux_gsg/build_dpdk.rst
> index 198c0b6..fb2c481 100644
> --- a/doc/guides/linux_gsg/build_dpdk.rst
> +++ b/doc/guides/linux_gsg/build_dpdk.rst
> @@ -152,7 +152,7 @@ A kmod  directory is also present that contains kernel 
> modules which may be load
>  
>  ls x86_64-native-linuxapp-gcc
>  
> -app build hostapp include kmod lib Makefile
> +app build include kmod lib Makefile
>  
>  Loading Modules to Enable Userspace IO for DPDK
>  ---
> diff --git a/mk/rte.sdkbuild.mk b/mk/rte.sdkbuild.mk
> index 354f006..23fcf1e 100644
> --- a/mk/rte.sdkbuild.mk
> +++ b/mk/rte.sdkbuild.mk
> @@ -64,9 +64,8 @@ build: $(ROOTDIRS-y)
>  .PHONY: clean
>  clean: $(CLEANDIRS)
>   @rm -rf $(RTE_OUTPUT)/include $(RTE_OUTPUT)/app \
> - $(RTE_OUTPUT)/hostapp $(RTE_OUTPUT)/lib \
> - $(RTE_OUTPUT)/hostlib $(RTE_OUTPUT)/kmod \
> - $(RTE_OUTPUT)/buildtools
> + $(RTE_OUTPUT)/lib \
> + $(RTE_OUTPUT)/hostlib $(RTE_OUTPUT)/kmod
>   @[ -d $(RTE_OUTPUT)/include ] || mkdir -p $(RTE_OUTPUT)/include
>   @$(RTE_SDK)/scripts/gen-config-h.sh $(RTE_OUTPUT)/.config \
>   > $(RTE_OUTPUT)/include/rte_config.h
> diff --git a/mk/rte.sdkconfig.mk b/mk/rte.sdkconfig.mk
> index a3acfe6..068d787 100644
> --- a/mk/rte.sdkconfig.mk
> +++ b/mk/rte.sdkconfig.mk
> @@ -108,7 +108,7 @@ $(RTE_OUTPUT)/Makefile: | $(RTE_OUTPUT)
>  # if NODOTCONF variable is defined, don't try to rebuild .config
>  $(RTE_OUTPUT)/include/rte_config.h: $(RTE_OUTPUT)/.config
>   $(Q)rm -rf $(RTE_OUTPUT)/include $(RTE_OUTPUT)/app \
> - $(RTE_OUTPUT)/hostapp $(RTE_OUTPUT)/lib \
> + $(RTE_OUTPUT)/lib \
>   $(RTE_OUTPUT)/hostlib $(RTE_OUTPUT)/kmod $(RTE_OUTPUT)/build
>   $(Q)mkdir -p $(RTE_OUTPUT)/include
>   $(Q)$(RTE_SDK)/scripts/gen-config-h.sh $(RTE_OUTPUT)/.config \
> -- 
> 2.7.0
> 
> 

Acked-by: Neil Horman 

[dpdk-dev] [PATCH] maintainers: claim responsibility for KNI

[Ferruh Yigit]

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

diff --git a/MAINTAINERS b/MAINTAINERS
index a59191e..250e542 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -249,7 +249,7 @@ F: app/test/test_link_bonding*
 F: examples/bond/

 Linux KNI
-M: Helin Zhang 
+M: Ferruh Yigit 
 F: lib/librte_eal/linuxapp/kni/
 F: lib/librte_kni/
 F: doc/guides/prog_guide/kernel_nic_interface.rst
-- 
2.7.4

[dpdk-dev] [PATCH 03/11] mk: fix build dependency of drivers on pmdinfogen

[Neil Horman]

On Thu, Jul 07, 2016 at 05:36:22PM +0200, Thomas Monjalon wrote:
> When compiling the drivers, some code is generated with pmdinfogen.
> A fresh parallel build can fail if a driver is compiled before pmdinfogen:
>   build/buildtools/dpdk-pmdinfogen: Permission denied
> 
> There was a dependency declared in drivers/Makefile but it cannot work
> because this file is based on mk/rte.subdir.mk which do not handle
> dependencies.
> 
> It is fixed by declaring the whole buildtools as (order only) prerequisite
> of drivers.
> 
> Fixes: cb6696d22023 ("drivers: update registration macro usage")
> 
> Signed-off-by: Thomas Monjalon 
> ---
>  drivers/Makefile   | 2 --
>  mk/rte.sdkbuild.mk | 1 +
>  2 files changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 75a3168..81c03a8 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -34,6 +34,4 @@ include $(RTE_SDK)/mk/rte.vars.mk
>  DIRS-y += net
>  DIRS-$(CONFIG_RTE_LIBRTE_CRYPTODEV) += crypto
>  
> -DEPDIRS-y += buildtools/pmdinfo
> -
>  include $(RTE_SDK)/mk/rte.subdir.mk
> diff --git a/mk/rte.sdkbuild.mk b/mk/rte.sdkbuild.mk
> index fb68af2..354f006 100644
> --- a/mk/rte.sdkbuild.mk
> +++ b/mk/rte.sdkbuild.mk
> @@ -49,6 +49,7 @@ $(1): $(sort $(LOCAL_DEPDIRS-$(1)))
>  endef
>  
>  $(foreach d,$(ROOTDIRS-y),$(eval $(call depdirs_rule,$(d
> +drivers: | buildtools
>  
I'm not sure i understand the reasoning here, DEPDIRS is meant to declare
prerequisites to a directory (and its children) getting built, right?  A 
parallel make should block any drivers getting built prior to pmdinfogen getting
built.  What am I missing?

Neil

>  #
>  # build and clean targets
> -- 
> 2.7.0
> 
> 

[dpdk-dev] [PATCH 02/11] crypto: fix parameters registration

[Neil Horman]

On Thu, Jul 07, 2016 at 05:36:21PM +0200, Thomas Monjalon wrote:
> The name aesni_gcm was used to register parameters of several
> crypto drivers.
> 
> Fixes: cb6696d22023 ("drivers: update registration macro usage")
> 
> Signed-off-by: Thomas Monjalon 
> ---
>  drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 2 +-
>  drivers/crypto/null/null_crypto_pmd.c  | 2 +-
>  drivers/crypto/snow3g/rte_snow3g_pmd.c | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c 
> b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
> index 859a04b..e3dea54 100644
> --- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
> +++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
> @@ -722,5 +722,5 @@ static struct rte_driver cryptodev_aesni_mb_pmd_drv = {
>  };
>  
>  PMD_REGISTER_DRIVER(cryptodev_aesni_mb_pmd_drv, aesni_mb);
> -DRIVER_REGISTER_PARAM_STRING(aesni_gcm, "max_nb_queue_pairs= "
> +DRIVER_REGISTER_PARAM_STRING(aesni_mb, "max_nb_queue_pairs= "
>  "max_nb_sessions= socket_id=");
> diff --git a/drivers/crypto/null/null_crypto_pmd.c 
> b/drivers/crypto/null/null_crypto_pmd.c
> index 0a195ed..7df88a3 100644
> --- a/drivers/crypto/null/null_crypto_pmd.c
> +++ b/drivers/crypto/null/null_crypto_pmd.c
> @@ -276,5 +276,5 @@ static struct rte_driver cryptodev_null_pmd_drv = {
>  };
>  
>  PMD_REGISTER_DRIVER(cryptodev_null_pmd_drv, cryptodev_null_pmd);
> -DRIVER_REGISTER_PARAM_STRING(aesni_gcm, "max_nb_queue_pairs= "
> +DRIVER_REGISTER_PARAM_STRING(cryptodev_null_pmd, "max_nb_queue_pairs= "
>  "max_nb_sessions= socket_id=");
> diff --git a/drivers/crypto/snow3g/rte_snow3g_pmd.c 
> b/drivers/crypto/snow3g/rte_snow3g_pmd.c
> index ddb724c..465d020 100644
> --- a/drivers/crypto/snow3g/rte_snow3g_pmd.c
> +++ b/drivers/crypto/snow3g/rte_snow3g_pmd.c
> @@ -646,5 +646,5 @@ static struct rte_driver cryptodev_snow3g_pmd_drv = {
>  };
>  
>  PMD_REGISTER_DRIVER(cryptodev_snow3g_pmd_drv, snow3g);
> -DRIVER_REGISTER_PARAM_STRING(aesni_gcm, "max_nb_queue_pairs= "
> +DRIVER_REGISTER_PARAM_STRING(snow3g, "max_nb_queue_pairs= "
>  "max_nb_sessions= socket_id=");
> -- 
> 2.7.0
> 
> 
This would be fine, but based on Lauras recent comments, this needs additional
fixing to work with the unit tests, I've posted a patch in response to her
report

Neil

[dpdk-dev] [PATCH 01/11] drivers: fix build with new register macro

[Neil Horman]

On Thu, Jul 07, 2016 at 05:36:20PM +0200, Thomas Monjalon wrote:
> Compilation fails because of some typos.
> 
> Fixes: cb6696d22023 ("drivers: update registration macro usage")
> 
> Signed-off-by: Thomas Monjalon 
> ---
>  drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 2 +-
>  drivers/net/mlx4/mlx4.c| 2 +-
>  drivers/net/mlx5/mlx5.c| 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c 
> b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
> index db3e562..859a04b 100644
> --- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
> +++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
> @@ -721,6 +721,6 @@ static struct rte_driver cryptodev_aesni_mb_pmd_drv = {
>   .uninit = cryptodev_aesni_mb_uninit
>  };
>  
> -PMD_REGISTER_DRIVER(cryptodev_aesni_mb_pmd_drvi, aesni_mb);
> +PMD_REGISTER_DRIVER(cryptodev_aesni_mb_pmd_drv, aesni_mb);
>  DRIVER_REGISTER_PARAM_STRING(aesni_gcm, "max_nb_queue_pairs= "
>  "max_nb_sessions= socket_id=");
> diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
> index 8758eac..d9ffb13 100644
> --- a/drivers/net/mlx4/mlx4.c
> +++ b/drivers/net/mlx4/mlx4.c
> @@ -5861,5 +5861,5 @@ static struct rte_driver rte_mlx4_driver = {
>   .init = rte_mlx4_pmd_init,
>  };
>  
> -PMD_REGISTER_DRIVER(rte_mlx4_driveri, mlx4)
> +PMD_REGISTER_DRIVER(rte_mlx4_driver, mlx4);
>  DRIVER_REGISTER_PCI_TABLE(mlx4, mlx4_pci_id_map);
> diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
> index 358e9b4..8d32252 100644
> --- a/drivers/net/mlx5/mlx5.c
> +++ b/drivers/net/mlx5/mlx5.c
> @@ -762,5 +762,5 @@ static struct rte_driver rte_mlx5_driver = {
>   .init = rte_mlx5_pmd_init,
>  };
>  
> -PMD_REGISTER_DRIVER(rte_mlx5_driveri, mlx5)
> +PMD_REGISTER_DRIVER(rte_mlx5_driver, mlx5);
>  DRIVER_REGISTER_PCI_TABLE(mlx5, mlx5_pci_id_map);
> -- 
> 2.7.0
> 
> 
Acked-by: Neil Horman 

[dpdk-dev] [PATCH v3 2/2] doc: add live migration overview image

[Bernard Iremonger]

This patch adds an image of the Live Migration test configuration.

Signed-off-by: Bernard Iremonger 
---
 doc/guides/howto/img/lm_overview.svg  | 666 ++
 doc/guides/howto/lm_bond_virtio_sriov.rst |   4 +
 2 files changed, 670 insertions(+)
 create mode 100644 doc/guides/howto/img/lm_overview.svg

diff --git a/doc/guides/howto/img/lm_overview.svg 
b/doc/guides/howto/img/lm_overview.svg
new file mode 100644
index 000..d913ae0
--- /dev/null
+++ b/doc/guides/howto/img/lm_overview.svg
@@ -0,0 +1,666 @@
+
+
+
+http://purl.org/dc/elements/1.1/;
+   xmlns:cc="http://creativecommons.org/ns#;
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#;
+   xmlns:svg="http://www.w3.org/2000/svg;
+   xmlns="http://www.w3.org/2000/svg;
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd;
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape;
+   width="1052.8693"
+   height="762.99158"
+   id="svg2"
+   version="1.1"
+   inkscape:version="0.48.4 r9939"
+   sodipodi:docname="lm_overview.svg">
+  
+
+  
+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+
+  
+image/svg+xml
+http://purl.org/dc/dcmitype/StillImage; />
+
+  
+
+  
+  
+
+
+
+
+
+
+
+
+VM 1 
+Switch with 10Gb ports
+Server 1
+Server 2
+  10 Gb Traffic Generator
+VM 2 
+Linux, KVM, QEMU 
+Linux, KVM, QEMU 
+10 Gb NIC
+10 Gb NIC
+
+
+10 Gb NIC
+10 Gb NIC
+
+DPDK Testpmd App.
+bonded device withvirtio and VF slaves
+
+DPDK Testpmd App.
+bonded device withvirtio and VF slaves
+Kernel PF driver
+Kernel PF driver
+SW bridge with Tapand PF connected 
+NFS ServerVM disk image
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+SW bridge with Tapand PF connected 
+10 Gb Migration Link
+  
+
diff --git a/doc/guides/howto/lm_bond_virtio_sriov.rst 
b/doc/guides/howto/lm_bond_virtio_sriov.rst
index 68bb0ea..f9d3667 100644
--- a/doc/guides/howto/lm_bond_virtio_sriov.rst
+++ b/doc/guides/howto/lm_bond_virtio_sriov.rst
@@ -57,6 +57,10 @@ The switch is configured to broadcast traffic on all the NIC 
ports.
 Live Migration with SR-IOV VF test setup:
 -

+.. _figure_lm_overview:
+
+.. figure:: img/lm_overview.*
+
 Live Migration steps for VM with Virtio and VF PMD's:
 -

-- 
2.9.0

[dpdk-dev] [PATCH v3 1/2] doc: live migration of VM with Virtio and VF

[Bernard Iremonger]

This patch describes the procedure to be be followed
to perform Live Migration of a VM with Virtio and VF PMD's
using the bonding PMD.

It includes sample host and VM scripts used in the procedure,
and a sample switch configuration.

Signed-off-by: Bernard Iremonger 
---
 doc/guides/howto/index.rst|  38 ++
 doc/guides/howto/lm_bond_virtio_sriov.rst | 689 ++
 doc/guides/index.rst  |   1 +
 3 files changed, 728 insertions(+)
 create mode 100644 doc/guides/howto/index.rst
 create mode 100644 doc/guides/howto/lm_bond_virtio_sriov.rst

diff --git a/doc/guides/howto/index.rst b/doc/guides/howto/index.rst
new file mode 100644
index 000..4b97a32
--- /dev/null
+++ b/doc/guides/howto/index.rst
@@ -0,0 +1,38 @@
+..  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.
+
+How To User Guide
+=
+
+.. toctree::
+:maxdepth: 3
+:numbered:
+
+lm_bond_virtio_sriov
diff --git a/doc/guides/howto/lm_bond_virtio_sriov.rst 
b/doc/guides/howto/lm_bond_virtio_sriov.rst
new file mode 100644
index 000..68bb0ea
--- /dev/null
+++ b/doc/guides/howto/lm_bond_virtio_sriov.rst
@@ -0,0 +1,689 @@
+..  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.
+
+
+Live Migration of VM with SR-IOV VF:
+
+
+Live Migration overview for VM with Virtio and VF PMD's:
+
+
+It is not possible to migrate a Virtual Machine which has an SR-IOV Virtual 
Function.
+To get around this problem the bonding PMD is used.
+
+A bonded device is created in the VM.
+The virtio and VF PMD's are added as slaves to the bonded device.
+The VF is set as the primary slave of the bonded device.
+
+A bridge must be set up on the Host connecting the tap device, which is the

[dpdk-dev] [PATCH v3 0/2] doc: live migration procedure

[Bernard Iremonger]

This pachset set describes the procedure to Live migrate
a VM with Virtio and VF PMD's using the bonding PMD.

Changes in v3:
rename directory from how_to to howto
move to after FAQ in the index

Changes in v2:
change primary port before removing slave port
remove unused variables from QEMU scripts
identify NIC's in bridge setup scripts

Bernard Iremonger (2):
  doc: live migration of VM with Virtio and VF
  doc: add live migration overview image

 doc/guides/howto/img/lm_overview.svg  | 666 
 doc/guides/howto/index.rst|  38 ++
 doc/guides/howto/lm_bond_virtio_sriov.rst | 693 ++
 doc/guides/index.rst  |   1 +
 4 files changed, 1398 insertions(+)
 create mode 100644 doc/guides/howto/img/lm_overview.svg
 create mode 100644 doc/guides/howto/index.rst
 create mode 100644 doc/guides/howto/lm_bond_virtio_sriov.rst

-- 
2.9.0

[dpdk-dev] [PATCH] crypto: normalize cryptodev pmd names with macros

[Neil Horman]

Recently reported, the introduction of pmd information exports led to a
breakage of cryptodev unit tests because the test infrastructure relies on the
cryptodev names being available in macros.  This patch fixes the pmd naming to
use the macro names.  Note that the macro names were already pre-stringified,
which won't work as the PMD_REGISTER_DRIVER macro requires the name in both a
processing token and stringified form.  As such the names are defined now as
tokens, and converted where needed to stringified form on demand using RTE_STR.

Tested using the null and aesni_mb crypto pmds, as I don't have hardware for any
other device.  Also not build tested on snow3g or kasumi pmd because building
those requires external libraries that appear to not be open source licensed.

Signed-off-by: Neil Horman 
CC: Bruce Richardson 
CC: Thomas Monjalon 
CC: "De Lara Guarch, Pablo" 
CC: Stephen Hemminger 
CC: Panu Matilainen 
---
 app/test/test_cryptodev.c  | 20 ++--
 app/test/test_cryptodev_perf.c | 18 +-
 drivers/crypto/aesni_gcm/aesni_gcm_pmd.c   |  7 +++
 drivers/crypto/aesni_gcm/aesni_gcm_pmd_private.h   |  6 +++---
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c |  7 +++
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h |  2 +-
 drivers/crypto/kasumi/rte_kasumi_pmd.c |  5 ++---
 drivers/crypto/null/null_crypto_pmd.c  |  7 +++
 drivers/crypto/null/null_crypto_pmd_private.h  |  6 +++---
 drivers/crypto/qat/rte_qat_cryptodev.c |  4 ++--
 drivers/crypto/snow3g/rte_snow3g_pmd.c |  4 ++--
 lib/librte_cryptodev/rte_cryptodev.h   | 12 ++--
 12 files changed, 47 insertions(+), 51 deletions(-)

diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
index fbfe1d0..1e1f887 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -186,12 +186,12 @@ testsuite_setup(void)
if (nb_devs < 2) {
for (i = nb_devs; i < 2; i++) {
ret = rte_eal_vdev_init(
-   CRYPTODEV_NAME_AESNI_MB_PMD, NULL);
+   RTE_STR(CRYPTODEV_NAME_AESNI_MB_PMD), 
NULL);

TEST_ASSERT(ret == 0,
"Failed to create instance %u of"
" pmd : %s",
-   i, CRYPTODEV_NAME_AESNI_MB_PMD);
+   i, 
RTE_STR(CRYPTODEV_NAME_AESNI_MB_PMD));
}
}
}
@@ -203,10 +203,10 @@ testsuite_setup(void)
if (nb_devs < 2) {
for (i = nb_devs; i < 2; i++) {
TEST_ASSERT_SUCCESS(rte_eal_vdev_init(
-   CRYPTODEV_NAME_AESNI_GCM_PMD, NULL),
+   RTE_STR(CRYPTODEV_NAME_AESNI_GCM_PMD), 
NULL),
"Failed to create instance %u of"
" pmd : %s",
-   i, CRYPTODEV_NAME_AESNI_GCM_PMD);
+   i, 
RTE_STR(CRYPTODEV_NAME_AESNI_GCM_PMD));
}
}
}
@@ -217,10 +217,10 @@ testsuite_setup(void)
if (nb_devs < 2) {
for (i = nb_devs; i < 2; i++) {
TEST_ASSERT_SUCCESS(rte_eal_vdev_init(
-   CRYPTODEV_NAME_SNOW3G_PMD, NULL),
+   RTE_STR(CRYPTODEV_NAME_SNOW3G_PMD), 
NULL),
"Failed to create instance %u of"
" pmd : %s",
-   i, CRYPTODEV_NAME_SNOW3G_PMD);
+   i, RTE_STR(CRYPTODEV_NAME_SNOW3G_PMD));
}
}
}
@@ -231,10 +231,10 @@ testsuite_setup(void)
if (nb_devs < 2) {
for (i = nb_devs; i < 2; i++) {
TEST_ASSERT_SUCCESS(rte_eal_vdev_init(
-   CRYPTODEV_NAME_KASUMI_PMD, NULL),
+   RTE_STR(CRYPTODEV_NAME_KASUMI_PMD), 
NULL),
"Failed to create instance %u of"
" pmd : %s",
-   i, CRYPTODEV_NAME_KASUMI_PMD);
+   i, RTE_STR(CRYPTODEV_NAME_KASUMI_PMD));
}
}
}
@@ -246,12 +246,12 @@ testsuite_setup(void)
if (nb_devs < 2) {
for (i = nb_devs; i < 2; i++) {
int dev_id = rte_eal_vdev_init(
- 

[dpdk-dev] [PATCHv8 2/6] drivers: Update driver registration macro usage

[De Lara Guarch, Pablo]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> Sent: Friday, June 17, 2016 7:46 PM
> To: dev at dpdk.org
> Cc: Neil Horman; Richardson, Bruce; Thomas Monjalon; Stephen Hemminger;
> Panu Matilainen
> Subject: [dpdk-dev] [PATCHv8 2/6] drivers: Update driver registration macro
> usage
> 
> Modify the PMD_REGISTER_DRIVER macro, adding a name argument to it.
> The
> addition of a name argument creates a token that can be used for subsequent
> macros in the creation of unique symbol names to export additional bits of
> information for use by the pmdinfogen tool.  For example:
> 
> PMD_REGISTER_DRIVER(ena_driver, ena);
> 
> registers the ena_driver struct as it always did, and creates a symbol
> const char this_pmd_name0[] __attribute__((used)) = "ena";
> 
> which pmdinfogen can search for and extract.  The subsequent macro
> 
> DRIVER_REGISTER_PCI_TABLE(ena, ena_pci_id_map);
> 
> creates a symbol const char ena_pci_tbl_export[] __attribute__((used)) =
> "ena_pci_id_map";
> 
> Which allows pmdinfogen to find the pci table of this driver
> 
> Using this pattern, we can export arbitrary bits of information.
> 
> pmdinfo uses this information to extract hardware support from an object
> file and create a json string to make hardware support info discoverable
> later.
> 
> Signed-off-by: Neil Horman 
> Acked-by: Panu Matilainen 
> CC: Bruce Richardson 
> CC: Thomas Monjalon 
> CC: Stephen Hemminger 
> CC: Panu Matilainen 

Hi,

I was running some crypto unit tests and I realized that the tests do not pass 
anymore,
because the creation of the software crypto device fails, due to this patch.

The reason is that the name of the pmd has changed (some names have changed,
like eth_pcap to pcap, whereas others have remained the same, like eth_null),
so the name passed to rte_eal_vdev_init has to be changed.

I am not sure if that is going to cause any problems, because users will have to
change their code because of this name change.

Also, if now the name is being set with PMD_REGISTER_DRIVER,
then we should remove it from the rte_driver structure, right?

static struct rte_driver pmd_ring_drv = {
.name = "eth_ring", <-- This is being overwritten by 
PMD_REGISTER_DRIVER?
.type = PMD_VDEV,
.init = rte_pmd_ring_devinit,
.uninit = rte_pmd_ring_devuninit,
};

PMD_REGISTER_DRIVER(pmd_ring_drv, eth_ring);

Pablo

[dpdk-dev] [PATCH v2] i40: fix the VXLAN TSO issue

[Ananyev, Konstantin]

Hi Tao,

Sorry hit send button too early by accident :)

> >
> > Problem:
> > When using the TSO + VXLAN feature in i40e, the outer UDP length fields in
> > the multiple UDP segments which are TSOed by the i40e will have the
> > wrong value.
> >
> > Fix this problem by adding the tunnel type field in the i40e descriptor
> > which was missed before.
> >
> > Fixes: 77b8301733c3 ("i40e: VXLAN Tx checksum offload")
> >
> > Signed-off-by: Zhe Tao 
> > ---
> > V2: Edited some comments for mbuf structure and i40e driver.
> >
> >  app/test-pmd/csumonly.c  | 26 +++---
> >  drivers/net/i40e/i40e_rxtx.c | 12 +---
> >  lib/librte_mbuf/rte_mbuf.h   | 16 +++-
> >  3 files changed, 43 insertions(+), 11 deletions(-)
> >
> > diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
> > index ac4bd8f..d423c20 100644
> > --- a/app/test-pmd/csumonly.c
> > +++ b/app/test-pmd/csumonly.c
> > @@ -204,7 +204,8 @@ parse_ethernet(struct ether_hdr *eth_hdr, struct 
> > testpmd_offload_info *info)
> >  static void
> >  parse_vxlan(struct udp_hdr *udp_hdr,
> > struct testpmd_offload_info *info,
> > -   uint32_t pkt_type)
> > +   uint32_t pkt_type,
> > +   uint64_t *ol_flags)
> >  {
> > struct ether_hdr *eth_hdr;
> >
> > @@ -215,6 +216,7 @@ parse_vxlan(struct udp_hdr *udp_hdr,
> > RTE_ETH_IS_TUNNEL_PKT(pkt_type) == 0)
> > return;
> >
> > +   *ol_flags |= PKT_TX_TUNNEL_VXLAN;
> > info->is_tunnel = 1;
> > info->outer_ethertype = info->ethertype;
> > info->outer_l2_len = info->l2_len;
> > @@ -231,7 +233,9 @@ parse_vxlan(struct udp_hdr *udp_hdr,
> >
> >  /* Parse a gre header */
> >  static void
> > -parse_gre(struct simple_gre_hdr *gre_hdr, struct testpmd_offload_info 
> > *info)
> > +parse_gre(struct simple_gre_hdr *gre_hdr,
> > + struct testpmd_offload_info *info,
> > + uint64_t *ol_flags)
> >  {
> > struct ether_hdr *eth_hdr;
> > struct ipv4_hdr *ipv4_hdr;
> > @@ -242,6 +246,8 @@ parse_gre(struct simple_gre_hdr *gre_hdr, struct 
> > testpmd_offload_info *info)
> > if ((gre_hdr->flags & _htons(~GRE_SUPPORTED_FIELDS)) != 0)
> > return;
> >
> > +   *ol_flags |= PKT_TX_TUNNEL_GRE;
> > +
> > gre_len += sizeof(struct simple_gre_hdr);
> >
> > if (gre_hdr->flags & _htons(GRE_KEY_PRESENT))
> > @@ -417,7 +423,7 @@ process_inner_cksums(void *l3_hdr, const struct 
> > testpmd_offload_info *info,
> >   * packet */
> >  static uint64_t
> >  process_outer_cksums(void *outer_l3_hdr, struct testpmd_offload_info *info,
> > -   uint16_t testpmd_ol_flags)
> > +   uint16_t testpmd_ol_flags, uint64_t orig_ol_flags)
> >  {
> > struct ipv4_hdr *ipv4_hdr = outer_l3_hdr;
> > struct ipv6_hdr *ipv6_hdr = outer_l3_hdr;
> > @@ -442,6 +448,9 @@ process_outer_cksums(void *outer_l3_hdr, struct 
> > testpmd_offload_info *info,
> >  * hardware supporting it today, and no API for it. */
> >
> > udp_hdr = (struct udp_hdr *)((char *)outer_l3_hdr + info->outer_l3_len);
> > +   if ((orig_ol_flags & PKT_TX_TCP_SEG) &&
> > +   ((orig_ol_flags & PKT_TX_TUNNEL_MASK) == PKT_TX_TUNNEL_VXLAN))
> > +   udp_hdr->dgram_cksum = 0;
> > /* do not recalculate udp cksum if it was 0 */
> > if (udp_hdr->dgram_cksum != 0) {
> > udp_hdr->dgram_cksum = 0;
> > @@ -705,15 +714,18 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
> > if (info.l4_proto == IPPROTO_UDP) {
> > struct udp_hdr *udp_hdr;
> > udp_hdr = (struct udp_hdr *)((char *)l3_hdr +
> > -   info.l3_len);
> > -   parse_vxlan(udp_hdr, , m->packet_type);
> > +  info.l3_len);
> > +   parse_vxlan(udp_hdr, , m->packet_type,
> > +   _flags);
> > } else if (info.l4_proto == IPPROTO_GRE) {
> > struct simple_gre_hdr *gre_hdr;
> > gre_hdr = (struct simple_gre_hdr *)
> > ((char *)l3_hdr + info.l3_len);
> > -   parse_gre(gre_hdr, );
> > +   parse_gre(gre_hdr, , _flags);
> > } else if (info.l4_proto == IPPROTO_IPIP) {
> > void *encap_ip_hdr;
> > +
> > +   ol_flags |= PKT_TX_TUNNEL_IPIP;
> > encap_ip_hdr = (char *)l3_hdr + info.l3_len;
> > parse_encap_ip(encap_ip_hdr, );
> > }
> > @@ -745,7 +757,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
> >  * processed in hardware. */
> > if (info.is_tunnel == 1) {
> > ol_flags |= process_outer_cksums(outer_l3_hdr, ,
> > -   testpmd_ol_flags);
> > +   testpmd_ol_flags, ol_flags);
> >  

[dpdk-dev] [PATCH v6 0/4] support reset of VF link

[Luca Boccassi]

On Thu, 2016-07-07 at 01:09 +, Lu, Wenzhuo wrote:
> Hi Luca,
> 
> 
> > -Original Message-
> > From: Luca Boccassi [mailto:lboccass at Brocade.com]
> > Sent: Thursday, July 7, 2016 12:23 AM
> > To: Lu, Wenzhuo
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v6 0/4] support reset of VF link
> > 
> > On Wed, 2016-07-06 at 00:45 +, Lu, Wenzhuo wrote:
> > > Hi Luca,
> > >
> > > > -Original Message-
> > > > From: Luca Boccassi [mailto:lboccass at Brocade.com]
> > > > Sent: Tuesday, July 5, 2016 5:53 PM
> > > > To: Lu, Wenzhuo
> > > > Cc: dev at dpdk.org
> > > > Subject: Re: [dpdk-dev] [PATCH v6 0/4] support reset of VF link
> > > >
> > > > On Tue, 2016-07-05 at 00:52 +, Lu, Wenzhuo wrote:
> > > > > Hi Luca,
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: Luca Boccassi [mailto:lboccass at Brocade.com]
> > > > > > Sent: Monday, July 4, 2016 11:48 PM
> > > > > > To: Lu, Wenzhuo
> > > > > > Cc: dev at dpdk.org
> > > > > > Subject: Re: [dpdk-dev] [PATCH v6 0/4] support reset of VF link
> > > > > >
> > > > > > On Mon, 2016-06-20 at 14:24 +0800, Wenzhuo Lu wrote:
> > > > > > > If the PF link is down and up, VF link will not work accordingly.
> > > > > > > This patch set addes the support of VF link reset. So, when VF
> > > > > > > receices the messges of physical link down/up. APP can reset
> > > > > > > the VF link and let it recover.
> > > > > > >
> > > > > > > PS: This patch set is splitted from a previous patch set,
> > > > > > > *automatic link recovery on ixgbe/igb VF*, and it's base on
> > > > > > > the patch set *support mailbox interruption on ixgbe/igb VF*.
> > > > > > >
> > > > > > > Wenzhuo Lu (3):
> > > > > > >   lib/librte_ether: support device reset
> > > > > > >   ixgbe: implement device reset on VF
> > > > > > >   igb: implement device reset on VF
> > > > > > >
> > > > > > > Zhe Tao (1):
> > > > > > >   i40e: implement device reset on VF
> > > > > > >
> > > > > > > v1:
> > > > > > > - Added the implementation for the VF reset functionality.
> > > > > > > v2:
> > > > > > > - Changed the i40e related operations during VF reset.
> > > > > > > v3:
> > > > > > > - Resent the patches because of the mail sent issue.
> > > > > > > v4:
> > > > > > > - Removed some VF reset emulation code.
> > > > > > > v5:
> > > > > > > - Removed all the code related with lock.
> > > > > > > v6:
> > > > > > > - Updated the NIC feature overview matrix.
> > > > > > > - Added more explanation in the doxygen comment of reset API.
> > > > > > >
> > > > > > >  doc/guides/nics/overview.rst   |  1 +
> > > > > > >  doc/guides/rel_notes/release_16_07.rst | 13 ++
> > > > > > >  drivers/net/e1000/igb_ethdev.c | 59 
> > > > > > > 
> > > > > > >  drivers/net/i40e/i40e_ethdev.h |  4 ++
> > > > > > >  drivers/net/i40e/i40e_ethdev_vf.c  | 83
> > > > > > ++
> > > > > > >  drivers/net/i40e/i40e_rxtx.c   | 10 
> > > > > > >  drivers/net/i40e/i40e_rxtx.h   |  4 ++
> > > > > > >  drivers/net/ixgbe/ixgbe_ethdev.c   | 64
> > +-
> > > > > > >  drivers/net/ixgbe/ixgbe_ethdev.h   |  2 +-
> > > > > > >  drivers/net/ixgbe/ixgbe_rxtx.c | 12 +++--
> > > > > > >  lib/librte_ether/rte_ethdev.c  | 17 +++
> > > > > > >  lib/librte_ether/rte_ethdev.h  | 24 ++
> > > > > > >  lib/librte_ether/rte_ether_version.map |  7 +++
> > > > > > >  13 files changed, 295 insertions(+), 5 deletions(-)
> > > > > >
> > > > > > Hello Wenzhuo,
> > > > > >
> > > > > > I'm testing this patchset, but I am sporadically running into an
> > > > > > issue where the VFs reset fails after the PF flaps.
> > > > > >
> > > > > > I have a VM running on a KVM box with a X540-AT2, passing 2 VFs in.
> > > > > >
> > > > > > I am using calling rte_eth_dev_reset in response to a
> > > > > > RTE_ETH_EVENT_INTR_RESET callback, and the following errors
> > > > > > appear in the
> > > > > > log:
> > > > > >
> > > > > > PMD: ixgbevf_dev_reset(): Ixgbe VF reset: Failed to update link.
> > > > > > PMD: ixgbe_alloc_rx_queue_mbufs(): RX mbuf alloc failed
> > > > > > queue_id=0
> > > > > > PMD: ixgbevf_dev_start(): Unable to initialize RX hardware (-12)
> > > > > > PMD: ixgbevf_dev_reset(): Ixgbe VF reset: Failed to start device.
> > > > > >
> > > > > > Jumping in with GDB, it seems that the rte_rxmbuf_alloc call in
> > > > > > ixgbe_alloc_rx_queue_mbufs returns NULL at iteration 64 out of 2048.
> > > > > > The application has ~500 2MB hugepages, and there's 2GB of free
> > > > > > memory available on top of that.
> > > > > >
> > > > > > Have you seen this before? Any pointer or suggestion for debugging?
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > > > --
> > > > > > Kind regards,
> > > > > > Luca Boccassi
> > > > > I think the problem is the mbuf occupied by the packets is not
> > > > > released. This
> > > > memory has to be released by the APP, so my patches 

[dpdk-dev] [PATCH v2] i40: fix the VXLAN TSO issue

[Ananyev, Konstantin]

Hi Tao,

> 
> Problem:
> When using the TSO + VXLAN feature in i40e, the outer UDP length fields in
> the multiple UDP segments which are TSOed by the i40e will have the
> wrong value.
> 
> Fix this problem by adding the tunnel type field in the i40e descriptor
> which was missed before.
> 
> Fixes: 77b8301733c3 ("i40e: VXLAN Tx checksum offload")
> 
> Signed-off-by: Zhe Tao 
> ---
> V2: Edited some comments for mbuf structure and i40e driver.
> 
>  app/test-pmd/csumonly.c  | 26 +++---
>  drivers/net/i40e/i40e_rxtx.c | 12 +---
>  lib/librte_mbuf/rte_mbuf.h   | 16 +++-
>  3 files changed, 43 insertions(+), 11 deletions(-)
> 
> diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
> index ac4bd8f..d423c20 100644
> --- a/app/test-pmd/csumonly.c
> +++ b/app/test-pmd/csumonly.c
> @@ -204,7 +204,8 @@ parse_ethernet(struct ether_hdr *eth_hdr, struct 
> testpmd_offload_info *info)
>  static void
>  parse_vxlan(struct udp_hdr *udp_hdr,
>   struct testpmd_offload_info *info,
> - uint32_t pkt_type)
> + uint32_t pkt_type,
> + uint64_t *ol_flags)
>  {
>   struct ether_hdr *eth_hdr;
> 
> @@ -215,6 +216,7 @@ parse_vxlan(struct udp_hdr *udp_hdr,
>   RTE_ETH_IS_TUNNEL_PKT(pkt_type) == 0)
>   return;
> 
> + *ol_flags |= PKT_TX_TUNNEL_VXLAN;
>   info->is_tunnel = 1;
>   info->outer_ethertype = info->ethertype;
>   info->outer_l2_len = info->l2_len;
> @@ -231,7 +233,9 @@ parse_vxlan(struct udp_hdr *udp_hdr,
> 
>  /* Parse a gre header */
>  static void
> -parse_gre(struct simple_gre_hdr *gre_hdr, struct testpmd_offload_info *info)
> +parse_gre(struct simple_gre_hdr *gre_hdr,
> +   struct testpmd_offload_info *info,
> +   uint64_t *ol_flags)
>  {
>   struct ether_hdr *eth_hdr;
>   struct ipv4_hdr *ipv4_hdr;
> @@ -242,6 +246,8 @@ parse_gre(struct simple_gre_hdr *gre_hdr, struct 
> testpmd_offload_info *info)
>   if ((gre_hdr->flags & _htons(~GRE_SUPPORTED_FIELDS)) != 0)
>   return;
> 
> + *ol_flags |= PKT_TX_TUNNEL_GRE;
> +
>   gre_len += sizeof(struct simple_gre_hdr);
> 
>   if (gre_hdr->flags & _htons(GRE_KEY_PRESENT))
> @@ -417,7 +423,7 @@ process_inner_cksums(void *l3_hdr, const struct 
> testpmd_offload_info *info,
>   * packet */
>  static uint64_t
>  process_outer_cksums(void *outer_l3_hdr, struct testpmd_offload_info *info,
> - uint16_t testpmd_ol_flags)
> + uint16_t testpmd_ol_flags, uint64_t orig_ol_flags)
>  {
>   struct ipv4_hdr *ipv4_hdr = outer_l3_hdr;
>   struct ipv6_hdr *ipv6_hdr = outer_l3_hdr;
> @@ -442,6 +448,9 @@ process_outer_cksums(void *outer_l3_hdr, struct 
> testpmd_offload_info *info,
>* hardware supporting it today, and no API for it. */
> 
>   udp_hdr = (struct udp_hdr *)((char *)outer_l3_hdr + info->outer_l3_len);
> + if ((orig_ol_flags & PKT_TX_TCP_SEG) &&
> + ((orig_ol_flags & PKT_TX_TUNNEL_MASK) == PKT_TX_TUNNEL_VXLAN))
> + udp_hdr->dgram_cksum = 0;
>   /* do not recalculate udp cksum if it was 0 */
>   if (udp_hdr->dgram_cksum != 0) {
>   udp_hdr->dgram_cksum = 0;
> @@ -705,15 +714,18 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
>   if (info.l4_proto == IPPROTO_UDP) {
>   struct udp_hdr *udp_hdr;
>   udp_hdr = (struct udp_hdr *)((char *)l3_hdr +
> - info.l3_len);
> - parse_vxlan(udp_hdr, , m->packet_type);
> +info.l3_len);
> + parse_vxlan(udp_hdr, , m->packet_type,
> + _flags);
>   } else if (info.l4_proto == IPPROTO_GRE) {
>   struct simple_gre_hdr *gre_hdr;
>   gre_hdr = (struct simple_gre_hdr *)
>   ((char *)l3_hdr + info.l3_len);
> - parse_gre(gre_hdr, );
> + parse_gre(gre_hdr, , _flags);
>   } else if (info.l4_proto == IPPROTO_IPIP) {
>   void *encap_ip_hdr;
> +
> + ol_flags |= PKT_TX_TUNNEL_IPIP;
>   encap_ip_hdr = (char *)l3_hdr + info.l3_len;
>   parse_encap_ip(encap_ip_hdr, );
>   }
> @@ -745,7 +757,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
>* processed in hardware. */
>   if (info.is_tunnel == 1) {
>   ol_flags |= process_outer_cksums(outer_l3_hdr, ,
> - testpmd_ol_flags);
> + testpmd_ol_flags, ol_flags);
>   }
> 
>   /* step 4: fill the mbuf meta data (flags and header lengths) */
> diff --git a/drivers/net/i40e/i40e_rxtx.c 

[dpdk-dev] [PATCH v4] Pci: Add the class_id support

[Thomas Monjalon]

2016-07-06 12:08, Ferruh Yigit:
> On 6/14/2016 3:52 PM, Thomas Monjalon wrote:
> > 2016-05-24 20:50, Ziye Yang:
> >> This patch is used to add the class_id (class_code,
> >> subclass_code, programming_interface) support for
> >> pci_device probe. With this patch, it will be
> >> flexible for users to probe a class of devices
> >> by class_id.
> >>
> >>
> >> Signed-off-by: Ziye Yang 
> > 
> > Applied, thanks
> > 
> Hi Thomas, Ziye,
> 
> Is modification in public "struct rte_pci_id" is a ABI break?
> If so, it requires eal LIBABIVER increase and release notes update.

Not really sure. I was thinking that it is used only by drivers
but not by applications.

[dpdk-dev] [PATCH 09/18] mbuf: support Mpls in software packet type parser

[Liang, Cunming]

Hi Olivier,

> -Original Message-
> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
> Sent: Wednesday, July 06, 2016 4:00 PM
> To: Liang, Cunming ; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 09/18] mbuf: support Mpls in software packet
> type parser
> 
> Hi Cunming,
> 
> On 07/06/2016 09:08 AM, Liang, Cunming wrote:
> > Hi Olivier,
> >
> > On 7/5/2016 11:41 PM, Olivier Matz wrote:
> >> Add a new RTE_PTYPE_L2_ETHER_MPLS packet type, and its support in
> >> rte_pktmbuf_get_ptype().
> >>
> >> Signed-off-by: Didier Pallard 
> >> Signed-off-by: Olivier Matz 
> >> ---
> >>   lib/librte_mbuf/rte_mbuf_ptype.c | 25 +
> >>   lib/librte_mbuf/rte_mbuf_ptype.h |  9 -
> >>   lib/librte_net/Makefile  |  4 +++-
> >>   lib/librte_net/rte_ether.h   |  2 ++
> >>   4 files changed, 38 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/lib/librte_mbuf/rte_mbuf_ptype.c
> >> b/lib/librte_mbuf/rte_mbuf_ptype.c
> >> index 5d46608..0dea600 100644
> >> --- a/lib/librte_mbuf/rte_mbuf_ptype.c
> >> +++ b/lib/librte_mbuf/rte_mbuf_ptype.c
> >> @@ -41,6 +41,7 @@
> >>   #include 
> >>   #include 
> >>   #include 
> >> +#include 
> >> /* get l3 packet type from ip6 next protocol */
> >>   static uint32_t
> >> @@ -166,6 +167,9 @@ uint32_t rte_pktmbuf_get_ptype(const struct
> >> rte_mbuf *m,
> >>   off = sizeof(*eh);
> >>   hdr_lens->l2_len = off;
> >>   +if (proto == rte_cpu_to_be_16(ETHER_TYPE_IPv4))
> >> +goto l3; /* fast path if packet is IPv4 */
> >> +
> >>   if (proto == rte_cpu_to_be_16(ETHER_TYPE_VLAN)) {
> >>   const struct vlan_hdr *vh;
> >>   struct vlan_hdr vh_copy;
> >> @@ -189,8 +193,29 @@ uint32_t rte_pktmbuf_get_ptype(const struct
> >> rte_mbuf *m,
> >>   off += 2 * sizeof(*vh);
> >>   hdr_lens->l2_len += 2 * sizeof(*vh);
> >>   proto = vh->eth_proto;
> >> +} else if ((proto == rte_cpu_to_be_16(ETHER_TYPE_MPLS)) ||
> >> +(proto == rte_cpu_to_be_16(ETHER_TYPE_MPLSM))) {
> >> +unsigned int i;
> >> +const struct mpls_hdr *mh;
> >> +struct mpls_hdr mh_copy;
> >> +
> >> +#define MAX_MPLS_HDR 5
> >> +for (i = 0; i < MAX_MPLS_HDR; i++) {
> >> +mh = rte_pktmbuf_read(m, off + (i * sizeof(*mh)),
> >> +sizeof(*mh), _copy);
> >> +if (unlikely(mh == NULL))
> >> +return pkt_type;
> >> +if (mh->bs)
> >> +break;
> >> +}
> >> +if (i == MAX_MPLS_HDR)
> >> +return pkt_type;
> >> +pkt_type = RTE_PTYPE_L2_ETHER_MPLS;
> >> +hdr_lens->l2_len += (sizeof(*mh) * (i + 1));
> > [LC] l2_len includes Eth, Vlan(opt.), MPLS(opt.). For VLAN and MPLS, it
> > may include #n times overlay.
> > These layer recognition knowledge are lost after the detection logic.
> > Once the APP takes the ptype, for the layer(L2, L3, L4) which has more
> > shim-layer, the xxx_len can't help to avoid the re-parse cost.
> 
> This is linked with the definition of packet type. Each layer has a
> type, and here we associate it to a length (by the way the length is
> something we may consider integrate inside the packet type in the future).
[LC] Yes, I see. 
My point is in some case, the length can represent for different layer.
For who interests on L2 MPLS, the length layer scheme maybe can define as 
{L2/MPLS/inner_L2/inner_L3}.
The rte_mbuf_hdr_lens likes a meta data which associates with the specific 
parser(assuming customized runtime instance provided by rte_pktmbuf_get_ptype).
The provider understand the meaning and layout.

> 
> The packet_type model allows to describe many packets kinds. Some will
> be difficult to represent (ex: a packet with several different L2 or
> L3). But I think this is a good compromise that could help the
> application to get some information without looking inside the packet.
> 
> Changing the packet type structure to something more flexible/complex
> would probably imply to loose time filling it in drivers and parse it in
> the application. And we already have a structure that contains all the
> information needed by the application: the packet data ;)
[LC] Fully agree. Sometimes it's a tradeoff, if the offering meta data by 
parser is 
not enough for further processing, the duplication packet data walking through 
may happen.
It's hard to define a meta data format for all cases. Probably the raw META is 
a good choice, which is recognized by the parser provider.

> 
> In any case, this is not really the topic of the patchset, which just
> provide a helper to parse a packet by software and get a packet_type (as
> it is defined today).
[LC] Maybe the conversation is a little beyond. Hope you get my point.

Thanks.

> 
> Regards,
> Olivier

[dpdk-dev] [PATCH v2 1/2] doc: live migration of VM with Virtio and VF

[Iremonger, Bernard]

Hi Thomas,


> Subject: Re: [dpdk-dev] [PATCH v2 1/2] doc: live migration of VM with Virtio
> and VF
> 
> 2016-07-06 17:01, Bernard Iremonger:
> > @@ -45,3 +45,4 @@ DPDK documentation
> > faq/index
> > rel_notes/index
> > contributing/index
> > +   how_to/index
> 
> 2 personal opinions:
> - I feel a directory "howto" (without underscore) would be nice.
> - The position in the index could be just after the faq.

I will rename the directory how_to to howto and move to after faq and send a v3.

Regards,

Bernard.

[dpdk-dev] [PATCH 6/6] l3fwd: add altivec support for em_hash_key

[Gowrishankar]

From: gowrishankar 

This patch adds ppc64le port for em_mask_key function.

Signed-off-by: Gowrishankar 
---
 examples/l3fwd/l3fwd_em.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/examples/l3fwd/l3fwd_em.c b/examples/l3fwd/l3fwd_em.c
index fc59243..3e261d1 100644
--- a/examples/l3fwd/l3fwd_em.c
+++ b/examples/l3fwd/l3fwd_em.c
@@ -259,6 +259,14 @@ em_mask_key(void *key, xmm_t mask)

return vandq_s32(data, mask);
 }
+#elif defined(RTE_MACHINE_CPUFLAG_ALTIVEC)
+static inline xmm_t
+em_mask_key(void *key, xmm_t mask)
+{
+   xmm_t data = vec_ld(0, (xmm_t *)(key));
+
+   return vec_and(data, mask);
+}
 #endif

 static inline uint8_t
-- 
1.9.1

[dpdk-dev] [PATCH 5/6] ip_pipeline: fix lcore mapping for varying SMT threads as in ppc64

[Gowrishankar]

From: gowrishankar 

offline lcore would still refer to original core id and this has to
be considered while creating cpu core mask.

Signed-off-by: Gowrishankar 
---
 examples/ip_pipeline/cpu_core_map.c | 12 +---
 examples/ip_pipeline/init.c |  4 
 2 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/examples/ip_pipeline/cpu_core_map.c 
b/examples/ip_pipeline/cpu_core_map.c
index cb088b1..482e68e 100644
--- a/examples/ip_pipeline/cpu_core_map.c
+++ b/examples/ip_pipeline/cpu_core_map.c
@@ -351,9 +351,6 @@ cpu_core_map_compute_linux(struct cpu_core_map *map)
int lcore_socket_id =
cpu_core_map_get_socket_id_linux(lcore_id);

-   if (lcore_socket_id < 0)
-   return -1;
-
if (((uint32_t) lcore_socket_id) == socket_id)
n_detected++;
}
@@ -368,18 +365,11 @@ cpu_core_map_compute_linux(struct cpu_core_map *map)
cpu_core_map_get_socket_id_linux(
lcore_id);

-   if (lcore_socket_id < 0)
-   return -1;
-
int lcore_core_id =
cpu_core_map_get_core_id_linux(
lcore_id);

-   if (lcore_core_id < 0)
-   return -1;
-
-   if (((uint32_t) lcore_socket_id == socket_id) &&
-   ((uint32_t) lcore_core_id == core_id)) {
+   if ((uint32_t) lcore_socket_id == socket_id) {
uint32_t pos = cpu_core_map_pos(map,
socket_id,
core_id_contig,
diff --git a/examples/ip_pipeline/init.c b/examples/ip_pipeline/init.c
index 83422e8..4acd38c 100644
--- a/examples/ip_pipeline/init.c
+++ b/examples/ip_pipeline/init.c
@@ -59,7 +59,11 @@ static void
 app_init_core_map(struct app_params *app)
 {
APP_LOG(app, HIGH, "Initializing CPU core map ...");
+#if defined(RTE_ARCH_PPC_64)
+   app->core_map = cpu_core_map_init(2, 5, 1, 0);
+#else
app->core_map = cpu_core_map_init(4, 32, 4, 0);
+#endif

if (app->core_map == NULL)
rte_panic("Cannot create CPU core map\n");
-- 
1.9.1

[dpdk-dev] [PATCH 4/6] table: cache align rte_bucket_4_8

[Gowrishankar]

From: gowrishankar 

Align rte_bucket_4_8 for cache line.

Signed-off-by: Gowrishankar 
---
 lib/librte_table/rte_table_hash_key8.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_table/rte_table_hash_key8.c 
b/lib/librte_table/rte_table_hash_key8.c
index e2e2bdc..4d5e0cd 100644
--- a/lib/librte_table/rte_table_hash_key8.c
+++ b/lib/librte_table/rte_table_hash_key8.c
@@ -68,7 +68,7 @@ struct rte_bucket_4_8 {
uint64_t key[4];

/* Cache line 1 */
-   uint8_t data[0];
+   uint8_t data[0] __rte_cache_aligned;
 };

 struct rte_table_hash {
-- 
1.9.1

[dpdk-dev] [PATCH 2/6] lpm: add altivec intrinsics for dpdk lpm on ppc_64

[Gowrishankar]

From: gowrishankar 

This patch adds ppc64le port for LPM library in DPDK.

Signed-off-by: Gowrishankar 
---
 app/test/test_xmmt_ops.h   |  16 +++
 .../common/include/arch/ppc_64/rte_vect.h  |  60 
 lib/librte_lpm/Makefile|   2 +
 lib/librte_lpm/rte_lpm.h   |   2 +
 lib/librte_lpm/rte_lpm_altivec.h   | 154 +
 5 files changed, 234 insertions(+)
 create mode 100644 lib/librte_eal/common/include/arch/ppc_64/rte_vect.h
 create mode 100644 lib/librte_lpm/rte_lpm_altivec.h

diff --git a/app/test/test_xmmt_ops.h b/app/test/test_xmmt_ops.h
index de9c16f..42174d2 100644
--- a/app/test/test_xmmt_ops.h
+++ b/app/test/test_xmmt_ops.h
@@ -62,6 +62,22 @@ vect_set_epi32(int i3, int i2, int i1, int i0)
 /* sets the 4 signed 32-bit integer values and returns the xmm_t variable */
 #define vect_set_epi32(i3, i2, i1, i0) _mm_set_epi32(i3, i2, i1, i0)

+#elif defined(RTE_ARCH_PPC_64)
+
+/* vect_* abstraction implementation using ALTIVEC */
+
+/* loads the xmm_t value from address p(does not need to be 16-byte aligned)*/
+#define vect_loadu_sil128(p) vec_ld(0, p)
+
+/* sets the 4 signed 32-bit integer values and returns the xmm_t variable */
+static inline xmm_t  __attribute__((always_inline))
+vect_set_epi32(int i3, int i2, int i1, int i0)
+{
+   xmm_t data = (xmm_t){i0, i1, i2, i3};
+
+   return data;
+}
+
 #endif

 #endif /* _TEST_XMMT_OPS_H_ */
diff --git a/lib/librte_eal/common/include/arch/ppc_64/rte_vect.h 
b/lib/librte_eal/common/include/arch/ppc_64/rte_vect.h
new file mode 100644
index 000..05209e5
--- /dev/null
+++ b/lib/librte_eal/common/include/arch/ppc_64/rte_vect.h
@@ -0,0 +1,60 @@
+/*
+ *   BSD LICENSE
+ *
+ *   Copyright (C) IBM Corporation 2016.
+ *
+ *   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 IBM 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.
+*/
+
+#ifndef _RTE_VECT_PPC_64_H_
+#define _RTE_VECT_PPC_64_H_
+
+#include 
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+typedef vector signed int xmm_t;
+
+#defineXMM_SIZE(sizeof(xmm_t))
+#defineXMM_MASK(XMM_SIZE - 1)
+
+typedef union rte_xmm {
+   xmm_tx;
+   uint8_t  u8[XMM_SIZE / sizeof(uint8_t)];
+   uint16_t u16[XMM_SIZE / sizeof(uint16_t)];
+   uint32_t u32[XMM_SIZE / sizeof(uint32_t)];
+   uint64_t u64[XMM_SIZE / sizeof(uint64_t)];
+   double   pd[XMM_SIZE / sizeof(double)];
+} __attribute__((aligned(16))) rte_xmm_t;
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_VECT_PPC_64_H_ */
diff --git a/lib/librte_lpm/Makefile b/lib/librte_lpm/Makefile
index 656ade2..3dc549d 100644
--- a/lib/librte_lpm/Makefile
+++ b/lib/librte_lpm/Makefile
@@ -51,6 +51,8 @@ ifneq ($(filter y,$(CONFIG_RTE_ARCH_ARM) 
$(CONFIG_RTE_ARCH_ARM64)),)
 SYMLINK-$(CONFIG_RTE_LIBRTE_LPM)-include += rte_lpm_neon.h
 else ifeq ($(CONFIG_RTE_ARCH_X86),y)
 SYMLINK-$(CONFIG_RTE_LIBRTE_LPM)-include += rte_lpm_sse.h
+else ifeq ($(CONFIG_RTE_ARCH_PPC_64),y)
+SYMLINK-$(CONFIG_RTE_LIBRTE_LPM)-include += rte_lpm_altivec.h
 endif

 # this lib needs eal
diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
index 2df1d67..dbe5483 100644
--- a/lib/librte_lpm/rte_lpm.h
+++ b/lib/librte_lpm/rte_lpm.h
@@ -480,6 +480,8 @@ rte_lpm_lookupx4(const struct rte_lpm *lpm, xmm_t ip, 
uint32_t hop[4],

 #if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64)
 #include "rte_lpm_neon.h"
+#elif defined(RTE_ARCH_PPC_64)

[dpdk-dev] [PATCH 1/6] config: enable lpm, port, table, pipeline, acl, sched libraries for ppc64le

[Gowrishankar]

From: gowrishankar 

In this patch, DPDK libraries such as LPM, port, table, pipeline, ACL,
and sched are enabled for ppc64le.

Signed-off-by: Gowrishankar 
---
 config/defconfig_ppc_64-power8-linuxapp-gcc | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/config/defconfig_ppc_64-power8-linuxapp-gcc 
b/config/defconfig_ppc_64-power8-linuxapp-gcc
index 9eb0cc4..02d15bc 100644
--- a/config/defconfig_ppc_64-power8-linuxapp-gcc
+++ b/config/defconfig_ppc_64-power8-linuxapp-gcc
@@ -57,9 +57,9 @@ CONFIG_RTE_LIBRTE_ENIC_PMD=n
 CONFIG_RTE_LIBRTE_FM10K_PMD=n

 # This following libraries are not available on Power. So they're turned off.
-CONFIG_RTE_LIBRTE_LPM=n
-CONFIG_RTE_LIBRTE_ACL=n
-CONFIG_RTE_LIBRTE_SCHED=n
-CONFIG_RTE_LIBRTE_PORT=n
-CONFIG_RTE_LIBRTE_TABLE=n
-CONFIG_RTE_LIBRTE_PIPELINE=n
+CONFIG_RTE_LIBRTE_LPM=y
+CONFIG_RTE_LIBRTE_ACL=y
+CONFIG_RTE_LIBRTE_SCHED=y
+CONFIG_RTE_LIBRTE_PORT=y
+CONFIG_RTE_LIBRTE_TABLE=y
+CONFIG_RTE_LIBRTE_PIPELINE=y
-- 
1.9.1

[dpdk-dev] [PATCH 0/6] enable lpm, acl and other missing libraries in ppc64le

[Gowrishankar]

This patchset enables LPM, ACL and other few missing libs in ppc64le and also
address few patches in related examples (ip_pipeline and l3fwd).


Test report:

LPM autotest test results as below.

RTE>>lpm_autotest 
No. routes = 1076806
Route distribution per prefix width: 
DEPTHQUANTITY (PERCENT)
--- 
01  0 (0.00)
02  0 (0.00)
03  1 (0.00)
04  0 (0.00)
05  3 (0.00)
06  2 (0.00)
07  4 (0.00)
08201 (0.02)
09 37 (0.00)
10 55 (0.01)
11 97 (0.01)
12381 (0.04)
13775 (0.07)
14   2104 (0.20)
15   3712 (0.34)
16  69319 (6.44)
17  12983 (1.21)
18  23667 (2.20)
19  69068 (6.41)
20  62354 (5.79)
21  48531 (4.51)
22  72355 (6.72)
23  85427 (7.93)
24 583900 (54.23)
25   2654 (0.25)
26   5650 (0.52)
27   6467 (0.60)
28   7127 (0.66)
29  12936 (1.20)
30   5999 (0.56)
31 13 (0.00)
32984 (0.09)

Unique added entries = 1039948
Used table 24 entries = 11343198 (67.6107%)
64 byte Cache entries used = 360735 (23087040 bytes)
Average LPM Add: 110766 cycles
Average LPM Lookup: 34.5 cycles (fails = 19.3%)
BULK LPM Lookup: 31.5 cycles (fails = 19.3%)
LPM LookupX4: 29.5 cycles (fails = 19.3%)
Average LPM Delete: 63813.8 cycles
Test OK
RTE>>

ACL autotest test results as below:

..
...
ACL: trie 0: number of rules: 17, indexes: 4
ACL: trie 1: number of rules: 10, indexes: 5
ACL: Gen phase for ACL "acl_ctx":
runtime memory footprint on socket -1:
single nodes/bytes used: 8822/70576
quad nodes/vectors/bytes used: 12788/53374/426992
DFA nodes/group64/bytes used: 2175/4359/2233864
match nodes/bytes used: 24100/3084800
total: 5818432 bytes
max limit: 18446744073709551615 bytes
ACL: Build phase for ACL "acl_ctx":
node limit for tree split: 16384
nodes created: 47885
memory consumed: 100663380
ACL: trie 0: number of rules: 22, indexes: 5
ACL: trie 1: number of rules: 5, indexes: 5
Test OK
RTE>>

Thanks.

[dpdk-dev] [PATCH 1/6] config: enable lpm, port, table, pipeline, acl, sched libraries for ppc64le

[Gowrishankar]

From: gowrishankar 

In this patch, DPDK libraries such as LPM, port, table, pipeline, ACL,
and sched are enabled for ppc64le.

Signed-off-by: Gowrishankar 
---
 config/defconfig_ppc_64-power8-linuxapp-gcc | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/config/defconfig_ppc_64-power8-linuxapp-gcc 
b/config/defconfig_ppc_64-power8-linuxapp-gcc
index 9eb0cc4..02d15bc 100644
--- a/config/defconfig_ppc_64-power8-linuxapp-gcc
+++ b/config/defconfig_ppc_64-power8-linuxapp-gcc
@@ -57,9 +57,9 @@ CONFIG_RTE_LIBRTE_ENIC_PMD=n
 CONFIG_RTE_LIBRTE_FM10K_PMD=n

 # This following libraries are not available on Power. So they're turned off.
-CONFIG_RTE_LIBRTE_LPM=n
-CONFIG_RTE_LIBRTE_ACL=n
-CONFIG_RTE_LIBRTE_SCHED=n
-CONFIG_RTE_LIBRTE_PORT=n
-CONFIG_RTE_LIBRTE_TABLE=n
-CONFIG_RTE_LIBRTE_PIPELINE=n
+CONFIG_RTE_LIBRTE_LPM=y
+CONFIG_RTE_LIBRTE_ACL=y
+CONFIG_RTE_LIBRTE_SCHED=y
+CONFIG_RTE_LIBRTE_PORT=y
+CONFIG_RTE_LIBRTE_TABLE=y
+CONFIG_RTE_LIBRTE_PIPELINE=y
-- 
1.9.1

[dpdk-dev] [PATCH 05/18] mbuf: add function to get packet type from data

[Liang, Cunming]

Hi Olivier,

> -Original Message-
> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
> Sent: Wednesday, July 06, 2016 3:43 PM
> To: Liang, Cunming ; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 05/18] mbuf: add function to get packet type
> from data
> 
> Hi Cunming,
> 
> On 07/06/2016 08:44 AM, Liang, Cunming wrote:
> > Hi Olivier,
> >
> > On 7/5/2016 11:41 PM, Olivier Matz wrote:
> >> Introduce the function rte_pktmbuf_get_ptype() that parses a
> >> mbuf and returns its packet type. For now, the following packet
> >> types are parsed:
> >> L2: Ether
> >> L3: IPv4, IPv6
> >> L4: TCP, UDP, SCTP
> >>
> >> The goal here is to provide a reference implementation for packet type
> >> parsing. This function will be used by testpmd in next commits, allowing
> >> to compare its result with the value given by the hardware.
> >>
> >> This function will also be useful when implementing Rx offload support
> >> in virtio pmd. Indeed, the virtio protocol gives the csum start and
> >> offset, but it does not give the L4 protocol nor it tells if the
> >> checksum is relevant for inner or outer. This information has to be
> >> known to properly set the ol_flags in mbuf.
> >>
> >> Signed-off-by: Didier Pallard 
> >> Signed-off-by: Jean Dao 
> >> Signed-off-by: Olivier Matz 
> >> ---
> >>   doc/guides/rel_notes/release_16_11.rst |   5 +
> >>   lib/librte_mbuf/Makefile   |   5 +-
> >>   lib/librte_mbuf/rte_mbuf_ptype.c   | 234
> >> +
> >>   lib/librte_mbuf/rte_mbuf_ptype.h   |  43 ++
> >>   lib/librte_mbuf/rte_mbuf_version.map   |   1 +
> >>   5 files changed, 286 insertions(+), 2 deletions(-)
> >>   create mode 100644 lib/librte_mbuf/rte_mbuf_ptype.c
> >>
> >> [...]
> >> +
> >> +/* parse mbuf data to get packet type */
> >> +uint32_t rte_pktmbuf_get_ptype(const struct rte_mbuf *m,
> >> +struct rte_mbuf_hdr_lens *hdr_lens)
> >> +{
> >> +struct rte_mbuf_hdr_lens local_hdr_lens;
> >> +const struct ether_hdr *eh;
> >> +struct ether_hdr eh_copy;
> >> +uint32_t pkt_type = RTE_PTYPE_L2_ETHER;
> >> +uint32_t off = 0;
> >> +uint16_t proto;
> >> +
> >> +if (hdr_lens == NULL)
> >> +hdr_lens = _hdr_lens;
> >> +
> >> +eh = rte_pktmbuf_read(m, off, sizeof(*eh), _copy);
> >> +if (unlikely(eh == NULL))
> >> +return 0;
> >> +proto = eh->ether_type;
> >> +off = sizeof(*eh);
> >> +hdr_lens->l2_len = off;
> >> +
> >> +if (proto == rte_cpu_to_be_16(ETHER_TYPE_IPv4)) {
> >> +const struct ipv4_hdr *ip4h;
> >> +struct ipv4_hdr ip4h_copy;
> >> +
> >> +ip4h = rte_pktmbuf_read(m, off, sizeof(*ip4h), _copy);
> >> +if (unlikely(ip4h == NULL))
> >> +return pkt_type;
> >> +
> >> +pkt_type |= ptype_l3_ip(ip4h->version_ihl);
> >> +hdr_lens->l3_len = ip4_hlen(ip4h);
> >> +off += hdr_lens->l3_len;
> >> +if (ip4h->fragment_offset &
> >> +rte_cpu_to_be_16(IPV4_HDR_OFFSET_MASK |
> >> +IPV4_HDR_MF_FLAG)) {
> >> +pkt_type |= RTE_PTYPE_L4_FRAG;
> >> +hdr_lens->l4_len = 0;
> >> +return pkt_type;
> >> +}
> >> +proto = ip4h->next_proto_id;
> >> +pkt_type |= ptype_l4(proto);
> >> +} else if (proto == rte_cpu_to_be_16(ETHER_TYPE_IPv6)) {
> >> +const struct ipv6_hdr *ip6h;
> >> +struct ipv6_hdr ip6h_copy;
> >> +int frag = 0;
> >> +
> >> +ip6h = rte_pktmbuf_read(m, off, sizeof(*ip6h), _copy);
> >> +if (unlikely(ip6h == NULL))
> >> +return pkt_type;
> >> +
> >> +proto = ip6h->proto;
> >> +hdr_lens->l3_len = sizeof(*ip6h);
> >> +off += hdr_lens->l3_len;
> >> +pkt_type |= ptype_l3_ip6(proto);
> >> +if ((pkt_type & RTE_PTYPE_L3_MASK) == RTE_PTYPE_L3_IPV6_EXT) {
> >> +proto = skip_ip6_ext(proto, m, , );
> >> +hdr_lens->l3_len = off - hdr_lens->l2_len;
> >> +}
> >> +if (proto == 0)
> >> +return pkt_type;
> >> +if (frag) {
> >> +pkt_type |= RTE_PTYPE_L4_FRAG;
> >> +hdr_lens->l4_len = 0;
> >> +return pkt_type;
> >> +}
> >> +pkt_type |= ptype_l4(proto);
> >> +}
> >> +
> >> +if ((pkt_type & RTE_PTYPE_L4_MASK) == RTE_PTYPE_L4_UDP) {
> >> +hdr_lens->l4_len = sizeof(struct udp_hdr);
> >> +} else if ((pkt_type & RTE_PTYPE_L4_MASK) == RTE_PTYPE_L4_TCP) {
> >> +const struct tcp_hdr *th;
> >> +struct tcp_hdr th_copy;
> >> +
> >> +th = rte_pktmbuf_read(m, off, sizeof(*th), _copy);
> >> +if (unlikely(th == NULL))
> >> +return pkt_type & (RTE_PTYPE_L2_MASK |
> >> +RTE_PTYPE_L3_MASK);
> >> +hdr_lens->l4_len = (th->data_off & 0xf0) >> 2;
> >> +} else if ((pkt_type & RTE_PTYPE_L4_MASK) == RTE_PTYPE_L4_SCTP) {
> >> +hdr_lens->l4_len = sizeof(struct sctp_hdr);
> >> +

[dpdk-dev] [PATCHv8 2/6] drivers: Update driver registration macro usage

[Neil Horman]

On Thu, Jul 07, 2016 at 11:00:59AM +, De Lara Guarch, Pablo wrote:
> 
> 
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> > Sent: Friday, June 17, 2016 7:46 PM
> > To: dev at dpdk.org
> > Cc: Neil Horman; Richardson, Bruce; Thomas Monjalon; Stephen Hemminger;
> > Panu Matilainen
> > Subject: [dpdk-dev] [PATCHv8 2/6] drivers: Update driver registration macro
> > usage
> > 
> > Modify the PMD_REGISTER_DRIVER macro, adding a name argument to it.
> > The
> > addition of a name argument creates a token that can be used for subsequent
> > macros in the creation of unique symbol names to export additional bits of
> > information for use by the pmdinfogen tool.  For example:
> > 
> > PMD_REGISTER_DRIVER(ena_driver, ena);
> > 
> > registers the ena_driver struct as it always did, and creates a symbol
> > const char this_pmd_name0[] __attribute__((used)) = "ena";
> > 
> > which pmdinfogen can search for and extract.  The subsequent macro
> > 
> > DRIVER_REGISTER_PCI_TABLE(ena, ena_pci_id_map);
> > 
> > creates a symbol const char ena_pci_tbl_export[] __attribute__((used)) =
> > "ena_pci_id_map";
> > 
> > Which allows pmdinfogen to find the pci table of this driver
> > 
> > Using this pattern, we can export arbitrary bits of information.
> > 
> > pmdinfo uses this information to extract hardware support from an object
> > file and create a json string to make hardware support info discoverable
> > later.
> > 
> > Signed-off-by: Neil Horman 
> > Acked-by: Panu Matilainen 
> > CC: Bruce Richardson 
> > CC: Thomas Monjalon 
> > CC: Stephen Hemminger 
> > CC: Panu Matilainen 
> 
> Hi,
> 
> I was running some crypto unit tests and I realized that the tests do not 
> pass anymore,
> because the creation of the software crypto device fails, due to this patch.
> 
> The reason is that the name of the pmd has changed (some names have changed,
> like eth_pcap to pcap, whereas others have remained the same, like eth_null),
> so the name passed to rte_eal_vdev_init has to be changed.
> 
> I am not sure if that is going to cause any problems, because users will have 
> to
> change their code because of this name change.
> 
> Also, if now the name is being set with PMD_REGISTER_DRIVER,
> then we should remove it from the rte_driver structure, right?
> 
> static struct rte_driver pmd_ring_drv = {
> .name = "eth_ring", <-- This is being overwritten by 
> PMD_REGISTER_DRIVER?
> .type = PMD_VDEV,
> .init = rte_pmd_ring_devinit,
> .uninit = rte_pmd_ring_devuninit,
> };
> 
> PMD_REGISTER_DRIVER(pmd_ring_drv, eth_ring);

The short answer to the question is yes, there is no real need to explicitly
call out the name in the definition of the rt_driver structure definition. I
made this change because some drivers failed to provide a driver name at all
(which was previously acceptable), but with the introduction of this patch the
name field is also used to construct the intermediate strings from which the
exported information is built.

We could restore the origional name of the driver that was renamed, though I'm
not sure which one that is (the example you provide should result in the pmd
having the exact same name).  Or we could update the registration macro to use
the cryptodev name macros.

Neil

> 
> Pablo
> 
> 

[dpdk-dev] Help: How to read packet statistics from device registers via dpdk PMD?

[Jay Rolette]

On Thu, Jul 7, 2016 at 12:52 AM, Bill Bonaparte 
wrote:

> I am so happy to get your reply.
> My dpdk version is 2.1?and the OS is centOS 7?
> the following is the output from "dpdk_nic_bind.py --status":
>
> [root at APV35 ~]# dpdk_nic_bind.py --status
>
> Network devices using DPDK-compatible driver
> 
> :04:00.0 'VMXNET3 Ethernet Controller' drv=igb_uio unused=
> :0b:00.0 'VMXNET3 Ethernet Controller' drv=igb_uio unused=
> :13:00.0 'VMXNET3 Ethernet Controller' drv=igb_uio unused=
> :1b:00.0 'VMXNET3 Ethernet Controller' drv=igb_uio unused=
>
> Network devices using kernel driver
> ===
> :03:00.0 'VMXNET3 Ethernet Controller' if=ens160 drv=vmxnet3
> unused=igb_uio *Active*
>
> Other network devices
> =
> 
>

That's a different virtual NIC than what I'm running in my VMs, but given
your app isn't working directly on the hardware, I doubt that's the issue.
In case it helps along the way, here's what I see in my VM:

$ dpdk_nic_bind.py --status

Network devices using DPDK-compatible driver

:02:02.0 '82545EM Gigabit Ethernet Controller (Copper)' drv=igb_uio
unused=
:02:03.0 '82545EM Gigabit Ethernet Controller (Copper)' drv=igb_uio
unused=
:02:04.0 '82545EM Gigabit Ethernet Controller (Copper)' drv=igb_uio
unused=
:02:05.0 '82545EM Gigabit Ethernet Controller (Copper)' drv=igb_uio
unused=

Network devices using kernel driver
===
:02:01.0 '82545EM Gigabit Ethernet Controller (Copper)' if=eth0
drv=e1000 unused=igb_uio *Active*

Other network devices
=



> I tried it on the physical mathine, it still does not work. the OS is
> centOS 7, too.
> [root at AN ~]# dpdk_nic_bind.py --status
>
> Network devices using DPDK-compatible driver
> 
> :01:00.0 '82599ES 10-Gigabit SFI/SFP+ Network Connection' drv=igb_uio
> unused=
> :01:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection' drv=igb_uio
> unused=
> :03:00.0 'I350 Gigabit Backplane Connection' drv=igb_uio unused=
> :03:00.1 'I350 Gigabit Backplane Connection' drv=igb_uio unused=
> :03:00.2 'I350 Gigabit Backplane Connection' drv=igb_uio unused=
> :03:00.3 'I350 Gigabit Backplane Connection' drv=igb_uio unused=
> :07:00.0 'I350 Gigabit Network Connection' drv=igb_uio unused=
> :07:00.1 'I350 Gigabit Network Connection' drv=igb_uio unused=
> :07:00.2 'I350 Gigabit Network Connection' drv=igb_uio unused=
> :07:00.3 'I350 Gigabit Network Connection' drv=igb_uio unused=
> :09:00.0 'I350 Gigabit Network Connection' drv=igb_uio unused=
> :09:00.1 'I350 Gigabit Network Connection' drv=igb_uio unused=
> :09:00.2 'I350 Gigabit Network Connection' drv=igb_uio unused=
> :09:00.3 'I350 Gigabit Network Connection' drv=igb_uio unused=
> :0c:00.0 'Device 0011' drv=igb_uio unused=
> :0f:00.1 'I350 Gigabit Network Connection' drv=igb_uio unused=
>
> Network devices using kernel driver
> ===
> :0f:00.0 'I350 Gigabit Network Connection' if=enp15s0f0 drv=igb
> unused=igb_uio *Active*
>
> Other network devices
> =
> 
>

With it not working on hardware and you having devices successfully bound
to DPDK, maybe it's a problem in your app. Have you tried running any of
the sample apps that use rte_eth_stats_get() and see if it works there?

Jay


> On Tue, Jul 5, 2016 at 8:03 PM, Jay Rolette  wrote:
>
>>
>> On Tue, Jul 5, 2016 at 2:35 AM, Bill Bonaparte 
>> wrote:
>>
>>> Hi:
>>> I am a new fish, I have tried my best to find answer about my question on
>>> web, but I failed. so
>>> I come here to ask for your help. the below is my question:
>>>
>>> I found that dpdk provides a api rte_eth_stats_get to read packet
>>> statistics about the interface, includes total input/output
>>> unicast/multicast/brodcast packets/bytes. but the api does not work on
>>> VMxnet interface (which is a virtual interface in VMware machine).
>>>
>>
>> Probably something in your app or environment rather than in the API
>> itself. We run rte_eth_stats_get() against interfaces in VMware Fusion,
>> VirtualBox and real hardware and they all work generally.
>>
>> Need some info before anyone can help you much:
>>
>> * What version of DPDK are you running?
>> * What OS are you running on?
>> * Output from "dpdk_nic_bind.py --status"?
>>
>> Jay
>>
>
>

[dpdk-dev] [RFC] Generic flow director/filtering/classification API

[Lu, Wenzhuo]

Hi Adrien,
I have some questions, please see inline, thanks.

> -Original Message-
> From: Adrien Mazarguil [mailto:adrien.mazarguil at 6wind.com]
> Sent: Wednesday, July 6, 2016 2:17 AM
> To: dev at dpdk.org
> Cc: Thomas Monjalon; Zhang, Helin; Wu, Jingjing; Rasesh Mody; Ajit Khaparde;
> Rahul Lakkireddy; Lu, Wenzhuo; Jan Medala; John Daley; Chen, Jing D; Ananyev,
> Konstantin; Matej Vido; Alejandro Lucero; Sony Chacko; Jerin Jacob; De Lara
> Guarch, Pablo; Olga Shern
> Subject: [RFC] Generic flow director/filtering/classification API
> 
> 
> Requirements for a new API:
> 
> - Flexible and extensible without causing API/ABI problems for existing
>   applications.
> - Should be unambiguous and easy to use.
> - Support existing filtering features and actions listed in `Filter types`_.
> - Support packet alteration.
> - In case of overlapping filters, their priority should be well documented.
Does that mean we don't guarantee the consistent of priority? The priority can 
be different on different NICs. So the behavior of the actions  can be 
different. Right?
Seems the users still need to aware the some details of the HW? Do we need to 
add the negotiation for the priority?

> 
> Flow rules can have several distinct actions (such as counting,
> encapsulating, decapsulating before redirecting packets to a particular
> queue, etc.), instead of relying on several rules to achieve this and having
> applications deal with hardware implementation details regarding their
> order.
I think normally HW doesn't support several actions in one rule. If a rule has 
several actions, seems HW has to split it to several rules. The order can still 
be a problem.

> 
> ``ETH``
> ^^^
> 
> Matches an Ethernet header.
> 
> - ``dst``: destination MAC.
> - ``src``: source MAC.
> - ``type``: EtherType.
> - ``tags``: number of 802.1Q/ad tags defined.
> - ``tag[]``: 802.1Q/ad tag definitions, innermost first. For each one:
> 
>  - ``tpid``: Tag protocol identifier.
>  - ``tci``: Tag control information.
"ETH" means all the parameters, dst, src, type... need to be matched? The same 
question for IPv4, IPv6 ...

> 
> ``UDP``
> ^^^
> 
> Matches a UDP header.
> 
> - ``sport``: source port.
> - ``dport``: destination port.
> - ``length``: UDP length.
> - ``checksum``: UDP checksum.
Why checksum? Do we need to filter the packets by checksum value?

> 
> ``VOID`` (action)
> ^
> 
> Used as a placeholder for convenience. It is ignored and simply discarded by
> PMDs.
Don't understand why we need VOID. If it?s about the format. Why not guarantee 
it in rte layer?

> 
> Behavior
> 
> 
> - API operations are synchronous and blocking (``EAGAIN`` cannot be
>   returned).
> 
> - There is no provision for reentrancy/multi-thread safety, although nothing
>   should prevent different devices from being configured at the same
>   time. PMDs may protect their control path functions accordingly.
> 
> - Stopping the data path (TX/RX) should not be necessary when managing flow
>   rules. If this cannot be achieved naturally or with workarounds (such as
>   temporarily replacing the burst function pointers), an appropriate error
>   code must be returned (``EBUSY``).
PMD cannot stop the data path without adding lock. So I think if some rules 
cannot be applied without stopping rx/tx, PMD has to return fail.
Or let the APP to stop the data path.

> 
> - PMDs, not applications, are responsible for maintaining flow rules
>   configuration when stopping and restarting a port or performing other
>   actions which may affect them. They can only be destroyed explicitly.
Don?t understand " They can only be destroyed explicitly." If a new rule has 
conflict with an old one, what should we do? Return fail?

> 
> ``ANY`` pattern item
> 
> 
> This pattern item stands for anything, which can be difficult to translate
> to something hardware would understand, particularly if followed by more
> specific types.
> 
> Consider the following pattern:
> 
> +---++
> | 0 | ETHER  |
> +---++
> | 1 | ANY (``min`` = 1, ``max`` = 1) |
> +---++
> | 2 | TCP|
> +---++
> 
> Knowing that TCP does not make sense with something other than IPv4 and IPv6
> as L3, such a pattern may be translated to two flow rules instead:
> 
> +---++
> | 0 | ETHER  |
> +---++
> | 1 | IPV4 (zeroed mask) |
> +---++
> | 2 | TCP|
> +---++
> 
> +---++
> | 0 | ETHER  |
> +---++
> | 1 | IPV6 (zeroed mask) |
> +---++
> | 2 | TCP|
> +---++
> 
> Note that as soon as a ANY rule covers several layers, this approach may
> yield a large number of hidden flow rules. It is thus 

[dpdk-dev] [PATCH] ip_frag: fix doxygen formatting

[Hiroyuki Mikita]

This commit fixes some functions missing in API documentation.

Signed-off-by: Hiroyuki Mikita 
---
 lib/librte_ip_frag/rte_ip_frag.h | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/lib/librte_ip_frag/rte_ip_frag.h b/lib/librte_ip_frag/rte_ip_frag.h
index 92cedf2..f8ed526 100644
--- a/lib/librte_ip_frag/rte_ip_frag.h
+++ b/lib/librte_ip_frag/rte_ip_frag.h
@@ -77,7 +77,7 @@ struct ip_frag_key {
uint32_t key_len;  /**< src/dst key length */
 };

-/*
+/**
  * @internal Fragmented packet to reassemble.
  * First two entries in the frags[] array are for the last and first fragments.
  */
@@ -151,7 +151,7 @@ struct ipv6_extension_fragment {



-/*
+/**
  * Create a new IP fragmentation table.
  *
  * @param bucket_num
@@ -174,7 +174,7 @@ struct rte_ip_frag_tbl * rte_ip_frag_table_create(uint32_t 
bucket_num,
uint32_t bucket_entries,  uint32_t max_entries,
uint64_t max_cycles, int socket_id);

-/*
+/**
  * Free allocated IP fragmentation table.
  *
  * @param btl
@@ -215,7 +215,7 @@ rte_ipv6_fragment_packet(struct rte_mbuf *pkt_in,
struct rte_mempool *pool_direct,
struct rte_mempool *pool_indirect);

-/*
+/**
  * This function implements reassembly of fragmented IPv6 packets.
  * Incoming mbuf should have its l2_len/l3_len fields setup correctly.
  *
@@ -241,7 +241,7 @@ struct rte_mbuf *rte_ipv6_frag_reassemble_packet(struct 
rte_ip_frag_tbl *tbl,
struct rte_mbuf *mb, uint64_t tms, struct ipv6_hdr *ip_hdr,
struct ipv6_extension_fragment *frag_hdr);

-/*
+/**
  * Return a pointer to the packet's fragment header, if found.
  * It only looks at the extension header that's right after the fixed IPv6
  * header, and doesn't follow the whole chain of extension headers.
@@ -291,7 +291,7 @@ int32_t rte_ipv4_fragment_packet(struct rte_mbuf *pkt_in,
struct rte_mempool *pool_direct,
struct rte_mempool *pool_indirect);

-/*
+/**
  * This function implements reassembly of fragmented IPv4 packets.
  * Incoming mbufs should have its l2_len/l3_len fields setup correclty.
  *
@@ -314,7 +314,7 @@ struct rte_mbuf * rte_ipv4_frag_reassemble_packet(struct 
rte_ip_frag_tbl *tbl,
struct rte_ip_frag_death_row *dr,
struct rte_mbuf *mb, uint64_t tms, struct ipv4_hdr *ip_hdr);

-/*
+/**
  * Check if the IPv4 packet is fragmented
  *
  * @param hdr
@@ -333,7 +333,7 @@ rte_ipv4_frag_pkt_is_fragmented(const struct ipv4_hdr * 
hdr) {
return ip_flag != 0 || ip_ofs  != 0;
 }

-/*
+/**
  * Free mbufs on a given death row.
  *
  * @param dr
@@ -345,7 +345,7 @@ void rte_ip_frag_free_death_row(struct 
rte_ip_frag_death_row *dr,
uint32_t prefetch);


-/*
+/**
  * Dump fragmentation table statistics to file.
  *
  * @param f
-- 
2.7.4

[dpdk-dev] [PATCH v6 0/4] support reset of VF link

[Lu, Wenzhuo]

Hi Luca,


> -Original Message-
> From: Luca Boccassi [mailto:lboccass at Brocade.com]
> Sent: Thursday, July 7, 2016 12:23 AM
> To: Lu, Wenzhuo
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v6 0/4] support reset of VF link
> 
> On Wed, 2016-07-06 at 00:45 +, Lu, Wenzhuo wrote:
> > Hi Luca,
> >
> > > -Original Message-
> > > From: Luca Boccassi [mailto:lboccass at Brocade.com]
> > > Sent: Tuesday, July 5, 2016 5:53 PM
> > > To: Lu, Wenzhuo
> > > Cc: dev at dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH v6 0/4] support reset of VF link
> > >
> > > On Tue, 2016-07-05 at 00:52 +, Lu, Wenzhuo wrote:
> > > > Hi Luca,
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Luca Boccassi [mailto:lboccass at Brocade.com]
> > > > > Sent: Monday, July 4, 2016 11:48 PM
> > > > > To: Lu, Wenzhuo
> > > > > Cc: dev at dpdk.org
> > > > > Subject: Re: [dpdk-dev] [PATCH v6 0/4] support reset of VF link
> > > > >
> > > > > On Mon, 2016-06-20 at 14:24 +0800, Wenzhuo Lu wrote:
> > > > > > If the PF link is down and up, VF link will not work accordingly.
> > > > > > This patch set addes the support of VF link reset. So, when VF
> > > > > > receices the messges of physical link down/up. APP can reset
> > > > > > the VF link and let it recover.
> > > > > >
> > > > > > PS: This patch set is splitted from a previous patch set,
> > > > > > *automatic link recovery on ixgbe/igb VF*, and it's base on
> > > > > > the patch set *support mailbox interruption on ixgbe/igb VF*.
> > > > > >
> > > > > > Wenzhuo Lu (3):
> > > > > >   lib/librte_ether: support device reset
> > > > > >   ixgbe: implement device reset on VF
> > > > > >   igb: implement device reset on VF
> > > > > >
> > > > > > Zhe Tao (1):
> > > > > >   i40e: implement device reset on VF
> > > > > >
> > > > > > v1:
> > > > > > - Added the implementation for the VF reset functionality.
> > > > > > v2:
> > > > > > - Changed the i40e related operations during VF reset.
> > > > > > v3:
> > > > > > - Resent the patches because of the mail sent issue.
> > > > > > v4:
> > > > > > - Removed some VF reset emulation code.
> > > > > > v5:
> > > > > > - Removed all the code related with lock.
> > > > > > v6:
> > > > > > - Updated the NIC feature overview matrix.
> > > > > > - Added more explanation in the doxygen comment of reset API.
> > > > > >
> > > > > >  doc/guides/nics/overview.rst   |  1 +
> > > > > >  doc/guides/rel_notes/release_16_07.rst | 13 ++
> > > > > >  drivers/net/e1000/igb_ethdev.c | 59 
> > > > > > 
> > > > > >  drivers/net/i40e/i40e_ethdev.h |  4 ++
> > > > > >  drivers/net/i40e/i40e_ethdev_vf.c  | 83
> > > > > ++
> > > > > >  drivers/net/i40e/i40e_rxtx.c   | 10 
> > > > > >  drivers/net/i40e/i40e_rxtx.h   |  4 ++
> > > > > >  drivers/net/ixgbe/ixgbe_ethdev.c   | 64
> +-
> > > > > >  drivers/net/ixgbe/ixgbe_ethdev.h   |  2 +-
> > > > > >  drivers/net/ixgbe/ixgbe_rxtx.c | 12 +++--
> > > > > >  lib/librte_ether/rte_ethdev.c  | 17 +++
> > > > > >  lib/librte_ether/rte_ethdev.h  | 24 ++
> > > > > >  lib/librte_ether/rte_ether_version.map |  7 +++
> > > > > >  13 files changed, 295 insertions(+), 5 deletions(-)
> > > > >
> > > > > Hello Wenzhuo,
> > > > >
> > > > > I'm testing this patchset, but I am sporadically running into an
> > > > > issue where the VFs reset fails after the PF flaps.
> > > > >
> > > > > I have a VM running on a KVM box with a X540-AT2, passing 2 VFs in.
> > > > >
> > > > > I am using calling rte_eth_dev_reset in response to a
> > > > > RTE_ETH_EVENT_INTR_RESET callback, and the following errors
> > > > > appear in the
> > > > > log:
> > > > >
> > > > > PMD: ixgbevf_dev_reset(): Ixgbe VF reset: Failed to update link.
> > > > > PMD: ixgbe_alloc_rx_queue_mbufs(): RX mbuf alloc failed
> > > > > queue_id=0
> > > > > PMD: ixgbevf_dev_start(): Unable to initialize RX hardware (-12)
> > > > > PMD: ixgbevf_dev_reset(): Ixgbe VF reset: Failed to start device.
> > > > >
> > > > > Jumping in with GDB, it seems that the rte_rxmbuf_alloc call in
> > > > > ixgbe_alloc_rx_queue_mbufs returns NULL at iteration 64 out of 2048.
> > > > > The application has ~500 2MB hugepages, and there's 2GB of free
> > > > > memory available on top of that.
> > > > >
> > > > > Have you seen this before? Any pointer or suggestion for debugging?
> > > > >
> > > > > Thanks!
> > > > >
> > > > > --
> > > > > Kind regards,
> > > > > Luca Boccassi
> > > > I think the problem is the mbuf occupied by the packets is not
> > > > released. This
> > > memory has to be released by the APP, so my patches haven?t covered this.
> > > Actually an example is needed to show how to use the reset API. I
> > > plan to modify the testpmd.
> > > > You may notice this feature is postponed to 16.11. Would you like
> > > > to wait for
> > > the new version that will include an example?
> > >
> > 

[dpdk-dev] [PATCHv8 0/6] Implement pmd hardware support exports

[Thomas Monjalon]

2016-06-30 08:45, Remy Horton:
> On 17/06/2016 19:46, Neil Horman wrote:
> > Hey all-
> > So heres attempt number 2 at a method for exporting PMD hardware support
> > information.  As we discussed previously, the consensus seems to be that pmd
> > information should be:
> [..]
> > Signed-off-by: Neil Horman 
> > Acked-by: Panu Matilainen 
> > CC: Bruce Richardson 
> > CC: Thomas Monjalon 
> > CC: Stephen Hemminger 
> > CC: Panu Matilainen 
> 
> Acked-by: Remy Horton 

v8 applied

The only changes I did are to update new drivers introduced recently:

--- a/drivers/crypto/kasumi/rte_kasumi_pmd.c
+++ b/drivers/crypto/kasumi/rte_kasumi_pmd.c
@@ -654,4 +654,6 @@ static struct rte_driver cryptodev_kasumi_pmd_drv = {
.uninit = cryptodev_kasumi_uninit
 };

-PMD_REGISTER_DRIVER(cryptodev_kasumi_pmd_drv);
+PMD_REGISTER_DRIVER(cryptodev_kasumi_pmd_drv, kasumi);
+DRIVER_REGISTER_PARAM_STRING(kasumi, "max_nb_queue_pairs= "
+"max_nb_sessions= socket_id=");

--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -1046,4 +1046,5 @@ static struct rte_driver bnxt_pmd_drv = {
.init = bnxt_rte_pmd_init,
 };

-PMD_REGISTER_DRIVER(bnxt_pmd_drv);
+PMD_REGISTER_DRIVER(bnxt_pmd_drv, bnxt);
+DRIVER_REGISTER_PCI_TABLE(bnxt, bnxt_pci_id_map);

--- a/drivers/net/thunderx/nicvf_ethdev.c
+++ b/drivers/net/thunderx/nicvf_ethdev.c
@@ -1788,4 +1788,5 @@ static struct rte_driver rte_nicvf_driver = {
.init = rte_nicvf_pmd_init,
 };

-PMD_REGISTER_DRIVER(rte_nicvf_driver);
+PMD_REGISTER_DRIVER(rte_nicvf_driver, thunderx_nicvf);
+DRIVER_REGISTER_PCI_TABLE(thunderx_nicvf, pci_id_nicvf_map);

--- a/drivers/net/virtio/virtio_user_ethdev.c
+++ b/drivers/net/virtio/virtio_user_ethdev.c
@@ -437,4 +437,4 @@ static struct rte_driver virtio_user_driver = {
.uninit = virtio_user_pmd_devuninit,
 };

-PMD_REGISTER_DRIVER(virtio_user_driver);
+PMD_REGISTER_DRIVER(virtio_user_driver, virtio_user);