[dpdk-dev] [PATCH v2] mk: filter duplicate configuration entries

2016-07-05 Thread Thomas Monjalon
2016-07-05 17:47, Ferruh Yigit:
> On 6/30/2016 1:00 PM, Christian Ehrhardt wrote:
> > +   tac $(RTE_OUTPUT)/.config_tmp > 
> > $(RTE_OUTPUT)/.config_tmp_reverse ; \
> Now we are adding new binary dependency (tac) to build system

tac can be replaced by sed '1!G;h;$!d'



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

2016-07-05 Thread Yuanhan Liu
On Tue, Jul 05, 2016 at 06:43:57PM +0530, 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

Thanks. Maybe it's good to include those info in the commit log next
time.

--yliu


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

2016-07-05 Thread Adrien Mazarguil
Hi All,

First, forgive me for this large message, I know our mailboxes already
suffer quite a bit from the amount of traffic on this ML.

This is not exactly yet another thread about how flow director should be
extended, rather about a brand new API to handle filtering and
classification for incoming packets in the most PMD-generic and
application-friendly fashion we can come up with. Reasons described below.

I think this topic is important enough to include both the users of this API
as well as PMD maintainers. So far I have CC'ed librte_ether (especially
rte_eth_ctrl.h contributors), testpmd and PMD maintainers (with and without
a .filter_ctrl implementation), but if you know application maintainers
other than testpmd who use FDIR or might be interested in this discussion,
feel free to add them.

The issues we found with the current approach are already summarized in the
following document, but here is a quick summary for TL;DR folks:

- PMDs do not expose a common set of filter types and even when they do,
  their behavior more or less differs.

- Applications need to determine and adapt to device-specific limitations
  and quirks on their own, without help from PMDs.

- Writing an application that creates flow rules targeting all devices
  supported by DPDK is thus difficult, if not impossible.

- The current API has too many unspecified areas (particularly regarding
  side effects of flow rules) that make PMD implementation tricky.

This RFC API handles everything currently supported by .filter_ctrl, the
idea being to reimplement all of these to make them fully usable by
applications in a more generic and well defined fashion. It has a very small
set of mandatory features and an easy method to let applications probe for
supported capabilities.

The only downside is more work for the software control side of PMDs because
they have to adapt to the API instead of the reverse. I think helpers can be
added to EAL to assist with this.

HTML version:

 https://rawgit.com/6WIND/rte_flow/master/rte_flow.html

PDF version:

 https://rawgit.com/6WIND/rte_flow/master/rte_flow.pdf

Related draft header file (for reference while reading the specification):

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

Git tree for completeness (latest .rst version can be retrieved from here):

 https://github.com/6WIND/rte_flow

What follows is the ReST source of the above, for inline comments and
discussion. I intend to update that specification accordingly.


Generic filter interface


.. footer::

   v0.6

.. contents::
.. sectnum::
.. raw:: pdf

   PageBreak

Overview


DPDK provides several competing interfaces added over time to perform packet
matching and related actions such as filtering and classification.

They must be extended to implement the features supported by newer devices
in order to expose them to applications, however the current design has
several drawbacks:

- Complicated filter combinations which have not been hard-coded cannot be
  expressed.
- Prone to API/ABI breakage when new features must be added to an existing
  filter type, which frequently happens.

>From an application point of view:

- Having disparate interfaces, all optional and lacking in features does not
  make this API easy to use.
- Seemingly arbitrary built-in limitations of filter types based on the
  device they were initially designed for.
- Undefined relationship between different filter types.
- High complexity, considerable undocumented and/or undefined behavior.

Considering the growing number of devices supported by DPDK, adding a new
filter type each time a new feature must be implemented is not sustainable
in the long term. Applications not written to target a specific device
cannot really benefit from such an API.

For these reasons, this document defines an extensible unified API that
encompasses and supersedes these legacy filter types.

.. raw:: pdf

   PageBreak

Current API
===

Rationale
-

The reason several competing (and mostly overlapping) filtering APIs are
present in DPDK is due to its nature as a thin layer between hardware and
software.

Each subsequent interface has been added to better match the capabilities
and limitations of the latest supported device, which usually happened to
need an incompatible configuration approach. Because of this, many ended up
device-centric and not usable by applications that were not written for that
particular device.

This document is not the first attempt to address this proliferation issue,
in fact a lot of work has already been done both to create a more generic
interface while somewhat keeping compatibility with legacy ones through a
common call interface (``rte_eth_dev_filter_ctrl()`` with the
``.filter_ctrl`` PMD callback in ``rte_ethdev.h``).

Today, these previously incompatible interfaces are known as filter types
(``RTE_ETH_FILTER_*`` from ``enum rte_filter_type`` in ``rte_et

[dpdk-dev] [PATCH] net/virtio: fix null pointer dereference

2016-07-05 Thread Yuanhan Liu
On Tue, Jul 05, 2016 at 11:42:59AM +, Jianfeng Tan wrote:
> There is a logic bug in this code, that could lead to null pointer
> dereference when cvq is NULL. Fix this problem by changing logic
> _and_ to logic _or_.
> 
>>> CID 127480:  Null pointer dereferences  (FORWARD_NULL)
>>> Dereferencing null pointer "cvq".
>   if (!cvq && !cvq->vq) {
> ...
> }
> 
> Coverity issue: 127480
> 
> Fixes: 01ad44fd374f ("net/virtio: split Rx/Tx queue")
> 
> Signed-off-by: Jianfeng Tan 

Applied to dpdk-next-virtio.

Thanks.

--yliu


[dpdk-dev] Possible Bug: DPDK 16.04 Empty packet_type

2016-07-05 Thread Craig, Chris A.
We recently upgraded our environment to the 16.04 version of DPDK on a 14.04 
installation of Ubuntu. After upgrading, we noticed our code was behaving 
oddly. After further inspection, we discovered the `packet_type` attribute of 
the mbuf is always 0. We had previously used it to detect L2 protocols for 
further processing and confirmed our suspicions by seeing the correct bit flags 
set in dpdk-2.2.0. In addition, the same behavior is observed after upgrading 
the machine to 16.04. Attached and in-line are a small write up of the observed 
issue. Has anyone else observed this behavior? Is it expected?

==
DPDK 16.04 Bug
CPU: Intel(R) Xeon(R) CPU E5-2687W v3
NICs: (2) Intel Corporation Ethernet 10G 2P X710 Adapter
OS: Ubuntu 14.04 and 16.04
Kernel: 3.16.0-60-generic (x84 64)
DPDK: 16.04
Network devices using DPDK-compatible driver

:01:00.1 ?Ethernet 10G 2P X710 Adapter? drv=igb_uio unused=
:01:00.2 ?Ethernet 10G 2P X710 Adapter? drv=igb_uio unused=

Problem: rte eth rx burst(...) is not initializing the rte mbuf struct. 
Specifically, mb ? packet type is always 0. However, rte pkt mtod(mb, struct 
ether hdr *) does return a pointer at the beginning of the Ethernet header and 
parsing other higher level headers (e.g., TCP) works correctly.
Reproducing: Compile dpdk-16.04. Set verbose level=1 in testpmd.c and compile. 
Run ?./testpmd ? -i?, ?set fwd rxonly?, ?start?.

Example output:
src=00:00:00:00:00:01 - dst=00:00:00:00:00:02 - type=0x0800 - length=60 - 
nb_segs=1
Unknown packet type // Should have been RTE_PTYPE_L2_ETHER:
- Receive queue=0x0

src=00:00:00:00:00:01 - dst=00:00:00:00:00:02 - type=0x0800 - length=60 - 
nb_segs=1
Unknown packet type // Should have been RTE_PTYPE_L2_ETHER:
- Receive queue=0x0
...
Repeating the steps above with dpdk-2.2.0 on the same machine does not have 
this issue. Example output on dpdk-2.2.0:
src=00:00:00:00:00:01 - dst=00:00:00:00:00:02 - type=0x0800 - length=60 - 
nb_segs=1
  - (outer) L2 type: ETHER - (outer) L3 type: IPV4_EXT_UNKNOWN - (outer) L4 
type: UDP
  - Tunnel type: Unknown - Inner L2 type: Unknown - Inner L3 type: Unknown - 
Inner L4
   type: Unknown
- Receive queue=0x0
...


--
Christopher Craig
Cyber Security Software Engineer
Cyber and Information Security Research Group, Oak Ridge National Laboratory
http://www.csiir.ornl.gov || (865) 421 ? 2992 (work)
-- next part --
A non-text attachment was scrubbed...
Name: dpdk_16_04_bug.pdf
Type: application/pdf
Size: 71384 bytes
Desc: dpdk_16_04_bug.pdf
URL: 
<http://dpdk.org/ml/archives/dev/attachments/20160705/fdf44761/attachment-0001.pdf>


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

2016-07-05 Thread Yuanhan Liu
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?

--yliu


[dpdk-dev] [PATCH 1/4] net/virtio-user: fix return value not checked

2016-07-05 Thread Yuanhan Liu
On Tue, Jul 05, 2016 at 10:14:28AM +, Tan, Jianfeng wrote:
> > On Wed, Jun 29, 2016 at 09:05:33AM +, Jianfeng Tan wrote:
> > > - if (rte_kvargs_count(kvlist, VIRTIO_USER_ARG_CQ_NUM) == 1)
> > > - rte_kvargs_process(kvlist, VIRTIO_USER_ARG_CQ_NUM,
> > > -&get_integer_arg, &cq);
> > > + if (rte_kvargs_count(kvlist, VIRTIO_USER_ARG_CQ_NUM) == 1) {
> > > + ret = rte_kvargs_process(kvlist,
> > VIRTIO_USER_ARG_CQ_NUM,
> > > +  &get_integer_arg, &cq);
> > > + if (ret < 0) {
> > > + PMD_INIT_LOG(ERR, "error to parse %s",
> > > +  VIRTIO_USER_ARG_CQ_NUM);
> > > + goto end;
> > > + }
> > > + }
> > >   else if (queues > 1)
> > 
> > Above 2 lines should be in one line. Fixed, and series applied to
> > dpdk-next-virtio.
> 
> Thanks.
> 
> But there's another problem in the commit log: the Coverity defect ID should 
> be "127477, 127478"  instead of "127344, 127478". Can you please help make it 
> right?

Done.

--yliu


[dpdk-dev] [PATCH v3 6/6] ena: fix for icc compiler

2016-07-05 Thread Jan Mędala
Let me point it this way:
??This patch fixes: [dpdk-dev,v3,1/6] ena: update of ENA communication layer

  Jan

2016-07-05 19:04 GMT+02:00 Jan M?dala :

> Uhm, wait, I think that sha is wrong, please let me check it double time.
>
>   Jan
>
> 2016-07-05 19:03 GMT+02:00 Jan M?dala :
>
>> Bruce,
>>
>>
>> That'd be very kind of you if you can fix trailing zeros.
>>
>>
>> This patch
>>
>> Fixes: b5b8cd9 ("ena: update of ENA communication layer")
>>
>>
>> Regards,
>>
>>   Jan
>>
>> 2016-07-05 18:19 GMT+02:00 Bruce Richardson :
>>
>>> On Tue, Jul 05, 2016 at 09:52:09AM +0100, Ferruh Yigit wrote:
>>> > On 6/30/2016 4:04 PM, Jan Medala wrote:
>>> > > Signed-off-by: Alexander Matushevsky 
>>> > > Signed-off-by: Jakub Palider 
>>> > > Signed-off-by: Jan Medala 
>>> >
>>> > The compilation error to fix is [1], it may be good to add what to fix
>>> > into commit log.
>>> >
>>> > [1]
>>> > == Build drivers/net/ena
>>> >   CC ena_ethdev.o
>>> > /tmp/dpdk_maintain/ena_v3/dpdk/drivers/net/ena/ena_ethdev.c(943): error
>>> > #188: enumerated type mixed with another type
>>> > struct ena_com_create_io_ctx ctx = { 0 };
>>> >  ^
>>> >
>>> > /tmp/dpdk_maintain/ena_v3/dpdk/drivers/net/ena/ena_ethdev.c(1036):
>>> error
>>> > #188: enumerated type mixed with another type
>>> > struct ena_com_create_io_ctx ctx = { 0 };
>>> >  ^
>>> > ...
>>> >
>>> > > --- a/drivers/net/ena/ena_ethdev.c
>>> > > +++ b/drivers/net/ena/ena_ethdev.c
>>> > > @@ -940,7 +940,10 @@ static int ena_tx_queue_setup(struct
>>> rte_eth_dev *dev,
>>> > >   __rte_unused unsigned int socket_id,
>>> > >   __rte_unused const struct rte_eth_txconf
>>> *tx_conf)
>>> > >  {
>>> > > -   struct ena_com_create_io_ctx ctx = { 0 };
>>> > > +   struct ena_com_create_io_ctx ctx =
>>> > > +   /* policy set to _HOST just to satisfy icc compiler */
>>> > > +   { ENA_ADMIN_PLACEMENT_POLICY_HOST,
>>> > > + ENA_COM_IO_QUEUE_DIRECTION_TX, 0, 0, 0, 0 };
>>> >
>>> > Trailing "0" are not required, compiler will take care of them.
>>> >
>>> Jan,
>>>
>>> any comment on this? If you want, I can remove the trailing zeros on
>>> apply
>>> rather than needing a V3. Is that ok?
>>>
>>> Again a fixes line is missing, can you supply one.
>>>
>>> /Bruce
>>>
>>
>>
>


[dpdk-dev] [PATCH v3 6/6] ena: fix for icc compiler

2016-07-05 Thread Jan Mędala
Uhm, wait, I think that sha is wrong, please let me check it double time.

  Jan

2016-07-05 19:03 GMT+02:00 Jan M?dala :

> Bruce,
>
>
> That'd be very kind of you if you can fix trailing zeros.
>
>
> This patch
>
> Fixes: b5b8cd9 ("ena: update of ENA communication layer")
>
>
> Regards,
>
>   Jan
>
> 2016-07-05 18:19 GMT+02:00 Bruce Richardson :
>
>> On Tue, Jul 05, 2016 at 09:52:09AM +0100, Ferruh Yigit wrote:
>> > On 6/30/2016 4:04 PM, Jan Medala wrote:
>> > > Signed-off-by: Alexander Matushevsky 
>> > > Signed-off-by: Jakub Palider 
>> > > Signed-off-by: Jan Medala 
>> >
>> > The compilation error to fix is [1], it may be good to add what to fix
>> > into commit log.
>> >
>> > [1]
>> > == Build drivers/net/ena
>> >   CC ena_ethdev.o
>> > /tmp/dpdk_maintain/ena_v3/dpdk/drivers/net/ena/ena_ethdev.c(943): error
>> > #188: enumerated type mixed with another type
>> > struct ena_com_create_io_ctx ctx = { 0 };
>> >  ^
>> >
>> > /tmp/dpdk_maintain/ena_v3/dpdk/drivers/net/ena/ena_ethdev.c(1036): error
>> > #188: enumerated type mixed with another type
>> > struct ena_com_create_io_ctx ctx = { 0 };
>> >  ^
>> > ...
>> >
>> > > --- a/drivers/net/ena/ena_ethdev.c
>> > > +++ b/drivers/net/ena/ena_ethdev.c
>> > > @@ -940,7 +940,10 @@ static int ena_tx_queue_setup(struct rte_eth_dev
>> *dev,
>> > >   __rte_unused unsigned int socket_id,
>> > >   __rte_unused const struct rte_eth_txconf
>> *tx_conf)
>> > >  {
>> > > -   struct ena_com_create_io_ctx ctx = { 0 };
>> > > +   struct ena_com_create_io_ctx ctx =
>> > > +   /* policy set to _HOST just to satisfy icc compiler */
>> > > +   { ENA_ADMIN_PLACEMENT_POLICY_HOST,
>> > > + ENA_COM_IO_QUEUE_DIRECTION_TX, 0, 0, 0, 0 };
>> >
>> > Trailing "0" are not required, compiler will take care of them.
>> >
>> Jan,
>>
>> any comment on this? If you want, I can remove the trailing zeros on apply
>> rather than needing a V3. Is that ok?
>>
>> Again a fixes line is missing, can you supply one.
>>
>> /Bruce
>>
>
>


[dpdk-dev] [PATCH v3 5/6] ena: fix memory management issue

2016-07-05 Thread Jan Mędala
Yes, this is correct.

  Jan

2016-07-05 18:13 GMT+02:00 Bruce Richardson :

> On Mon, Jul 04, 2016 at 05:27:50PM +0100, Bruce Richardson wrote:
> > On Thu, Jun 30, 2016 at 05:04:58PM +0200, Jan Medala wrote:
> > > After allocating memzone it's required to zeroize memory in it.
> > > Freeing memzone with function dedicated for memoryzones.
> > >
> >
> > Can you provide a fixes line for this patch?
> >
>
> From looking at git blame, it looks to be:
> Fixes: 9ba7981ec992 ("ena: add communication layer for DPDK")
>
> Please confirm that is ok.
>
> /Bruce
>
>


[dpdk-dev] [PATCH v3 5/6] ena: fix memory management issue

2016-07-05 Thread Jan Mędala
Yes, this is correct.

  Jan

2016-07-05 18:13 GMT+02:00 Bruce Richardson :

> On Mon, Jul 04, 2016 at 05:27:50PM +0100, Bruce Richardson wrote:
> > On Thu, Jun 30, 2016 at 05:04:58PM +0200, Jan Medala wrote:
> > > After allocating memzone it's required to zeroize memory in it.
> > > Freeing memzone with function dedicated for memoryzones.
> > >
> >
> > Can you provide a fixes line for this patch?
> >
>
> From looking at git blame, it looks to be:
> Fixes: 9ba7981ec992 ("ena: add communication layer for DPDK")
>
> Please confirm that is ok.
>
> /Bruce
>
>


[dpdk-dev] [PATCH v3 6/6] ena: fix for icc compiler

2016-07-05 Thread Jan Mędala
Bruce,


That'd be very kind of you if you can fix trailing zeros.


This patch

Fixes: b5b8cd9 ("ena: update of ENA communication layer")


Regards,

  Jan

2016-07-05 18:19 GMT+02:00 Bruce Richardson :

> On Tue, Jul 05, 2016 at 09:52:09AM +0100, Ferruh Yigit wrote:
> > On 6/30/2016 4:04 PM, Jan Medala wrote:
> > > Signed-off-by: Alexander Matushevsky 
> > > Signed-off-by: Jakub Palider 
> > > Signed-off-by: Jan Medala 
> >
> > The compilation error to fix is [1], it may be good to add what to fix
> > into commit log.
> >
> > [1]
> > == Build drivers/net/ena
> >   CC ena_ethdev.o
> > /tmp/dpdk_maintain/ena_v3/dpdk/drivers/net/ena/ena_ethdev.c(943): error
> > #188: enumerated type mixed with another type
> > struct ena_com_create_io_ctx ctx = { 0 };
> >  ^
> >
> > /tmp/dpdk_maintain/ena_v3/dpdk/drivers/net/ena/ena_ethdev.c(1036): error
> > #188: enumerated type mixed with another type
> > struct ena_com_create_io_ctx ctx = { 0 };
> >  ^
> > ...
> >
> > > --- a/drivers/net/ena/ena_ethdev.c
> > > +++ b/drivers/net/ena/ena_ethdev.c
> > > @@ -940,7 +940,10 @@ static int ena_tx_queue_setup(struct rte_eth_dev
> *dev,
> > >   __rte_unused unsigned int socket_id,
> > >   __rte_unused const struct rte_eth_txconf
> *tx_conf)
> > >  {
> > > -   struct ena_com_create_io_ctx ctx = { 0 };
> > > +   struct ena_com_create_io_ctx ctx =
> > > +   /* policy set to _HOST just to satisfy icc compiler */
> > > +   { ENA_ADMIN_PLACEMENT_POLICY_HOST,
> > > + ENA_COM_IO_QUEUE_DIRECTION_TX, 0, 0, 0, 0 };
> >
> > Trailing "0" are not required, compiler will take care of them.
> >
> Jan,
>
> any comment on this? If you want, I can remove the trailing zeros on apply
> rather than needing a V3. Is that ok?
>
> Again a fixes line is missing, can you supply one.
>
> /Bruce
>


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

2016-07-05 Thread Jerin Jacob
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,

I have tested on a x86 machine with gcc 6.1. I could n't see any issues
with i686-native-linuxapp-gcc target

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)

More over this issue seems like an issue from x86 rte_memcpy implementation.

Jerin


[dpdk-dev] [PATCH v3 4/4] virtio: add neon support

2016-07-05 Thread Jerin Jacob
Added neon based Rx vector implementation.
Selection of the new handler based neon availability at runtime.
Updated the release notes and MAINTAINERS file.

Signed-off-by: Jerin Jacob 
---
 MAINTAINERS  |   1 +
 doc/guides/rel_notes/release_16_07.rst   |   2 +
 drivers/net/virtio/Makefile  |   2 +
 drivers/net/virtio/virtio_rxtx.c |   3 +
 drivers/net/virtio/virtio_rxtx_simple_neon.c | 235 +++
 5 files changed, 243 insertions(+)
 create mode 100644 drivers/net/virtio/virtio_rxtx_simple_neon.c

diff --git a/MAINTAINERS b/MAINTAINERS
index a59191e..ab04cee 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -143,6 +143,7 @@ F: lib/librte_acl/acl_run_neon.*
 F: lib/librte_lpm/rte_lpm_neon.h
 F: lib/librte_hash/rte*_arm64.h
 F: drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c
+F: drivers/net/virtio/virtio_rxtx_simple_neon.c

 EZchip TILE-Gx
 M: Zhigang Lu 
diff --git a/doc/guides/rel_notes/release_16_07.rst 
b/doc/guides/rel_notes/release_16_07.rst
index 569f562..57f3d28 100644
--- a/doc/guides/rel_notes/release_16_07.rst
+++ b/doc/guides/rel_notes/release_16_07.rst
@@ -180,6 +180,8 @@ New Features
   section of the "Network Interface Controller Drivers" document.


+* **Virtio NEON support for ARM.**
+
 Resolved Issues
 ---

diff --git a/drivers/net/virtio/Makefile b/drivers/net/virtio/Makefile
index c4103b7..97972a6 100644
--- a/drivers/net/virtio/Makefile
+++ b/drivers/net/virtio/Makefile
@@ -54,6 +54,8 @@ SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_rxtx_simple.c

 ifeq ($(CONFIG_RTE_ARCH_X86),y)
 SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_rxtx_simple_sse.c
+else ifneq ($(filter y,$(CONFIG_RTE_ARCH_ARM) $(CONFIG_RTE_ARCH_ARM64)),)
+SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_rxtx_simple_neon.c
 endif

 ifeq ($(CONFIG_RTE_VIRTIO_USER),y)
diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index adc3457..8f6cad8 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -481,6 +481,9 @@ virtio_update_rxtx_handler(struct rte_eth_dev *dev,
 #if defined RTE_ARCH_X86
if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SSE3))
use_simple_rxtx = 1;
+#elif defined RTE_ARCH_ARM64 || defined CONFIG_RTE_ARCH_ARM
+   if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_NEON))
+   use_simple_rxtx = 1;
 #endif
/* Use simple rx/tx func if single segment and no offloads */
if (use_simple_rxtx &&
diff --git a/drivers/net/virtio/virtio_rxtx_simple_neon.c 
b/drivers/net/virtio/virtio_rxtx_simple_neon.c
new file mode 100644
index 000..793eefb
--- /dev/null
+++ b/drivers/net/virtio/virtio_rxtx_simple_neon.c
@@ -0,0 +1,235 @@
+/*
+ *   BSD LICENSE
+ *
+ *   Copyright (C) Cavium networks Ltd. 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 Cavium networks 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.
+*/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "virtio_rxtx_simple.h"
+
+#define RTE_VIRTIO_VPMD_RX_BURST 32
+#define RTE_VIRTIO_DESC_PER_LOOP 8
+#define RTE_VIRTIO_VPMD_RX_REARM_THRESH RTE_VIRTIO_VPMD_RX_BURST
+
+/* virtio vPMD receive routine, only accept(nb_pkts >= 
RTE_VIRTIO_DESC_PER_LOOP)
+ *
+ * This routine is for non-mergeable RX, one desc for each guest buffer.
+ * This routine is based on the RX rin

[dpdk-dev] [PATCH v3 3/4] virtio: add cpuflag based vector handler selection

2016-07-05 Thread Jerin Jacob
Introduced cpuflag based run-time detection to select the
SSE based simple Rx handler

Signed-off-by: Jerin Jacob 
---
 drivers/net/virtio/virtio_rxtx.c | 38 --
 1 file changed, 24 insertions(+), 14 deletions(-)

diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index e707954..adc3457 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -50,6 +50,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "virtio_logs.h"
 #include "virtio_ethdev.h"
@@ -470,6 +471,28 @@ virtio_dev_rx_queue_release(void *rxq)
rte_memzone_free(mz);
 }

+static void
+virtio_update_rxtx_handler(struct rte_eth_dev *dev,
+  const struct rte_eth_txconf *tx_conf)
+{
+   uint8_t use_simple_rxtx = 0;
+   struct virtio_hw *hw = dev->data->dev_private;
+
+#if defined RTE_ARCH_X86
+   if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SSE3))
+   use_simple_rxtx = 1;
+#endif
+   /* Use simple rx/tx func if single segment and no offloads */
+   if (use_simple_rxtx &&
+   (tx_conf->txq_flags & VIRTIO_SIMPLE_FLAGS) == VIRTIO_SIMPLE_FLAGS &&
+   !vtpci_with_feature(hw, VIRTIO_NET_F_MRG_RXBUF)) {
+   PMD_INIT_LOG(INFO, "Using simple rx/tx path");
+   dev->tx_pkt_burst = virtio_xmit_pkts_simple;
+   dev->rx_pkt_burst = virtio_recv_pkts_vec;
+   hw->use_simple_rxtx = use_simple_rxtx;
+   }
+}
+
 /*
  * struct rte_eth_dev *dev: Used to update dev
  * uint16_t nb_desc: Defaults to values read from config space
@@ -485,10 +508,6 @@ virtio_dev_tx_queue_setup(struct rte_eth_dev *dev,
const struct rte_eth_txconf *tx_conf)
 {
uint8_t vtpci_queue_idx = 2 * queue_idx + VTNET_SQ_TQ_QUEUE_IDX;
-
-#ifdef RTE_MACHINE_CPUFLAG_SSSE3
-   struct virtio_hw *hw = dev->data->dev_private;
-#endif
struct virtnet_tx *txvq;
struct virtqueue *vq;
uint16_t tx_free_thresh;
@@ -502,16 +521,7 @@ virtio_dev_tx_queue_setup(struct rte_eth_dev *dev,
return -EINVAL;
}

-#ifdef RTE_MACHINE_CPUFLAG_SSSE3
-   /* Use simple rx/tx func if single segment and no offloads */
-   if ((tx_conf->txq_flags & VIRTIO_SIMPLE_FLAGS) == VIRTIO_SIMPLE_FLAGS &&
-!vtpci_with_feature(hw, VIRTIO_NET_F_MRG_RXBUF)) {
-   PMD_INIT_LOG(INFO, "Using simple rx/tx path");
-   dev->tx_pkt_burst = virtio_xmit_pkts_simple;
-   dev->rx_pkt_burst = virtio_recv_pkts_vec;
-   hw->use_simple_rxtx = 1;
-   }
-#endif
+   virtio_update_rxtx_handler(dev, tx_conf);

ret = virtio_dev_queue_setup(dev, VTNET_TQ, queue_idx, vtpci_queue_idx,
nb_desc, socket_id, (void **)&txvq);
-- 
2.5.5



[dpdk-dev] [PATCH v3 2/4] virtio: move SSE based Rx implementation to separate file

2016-07-05 Thread Jerin Jacob
Split out SSE instruction based virtio simple Rx
implementation to a separate file

Signed-off-by: Jerin Jacob 
---
 drivers/net/virtio/Makefile |   4 +
 drivers/net/virtio/virtio_rxtx_simple.c | 273 ++--
 drivers/net/virtio/virtio_rxtx_simple.h | 133 ++
 drivers/net/virtio/virtio_rxtx_simple_sse.c | 222 ++
 4 files changed, 370 insertions(+), 262 deletions(-)
 create mode 100644 drivers/net/virtio/virtio_rxtx_simple.h
 create mode 100644 drivers/net/virtio/virtio_rxtx_simple_sse.c

diff --git a/drivers/net/virtio/Makefile b/drivers/net/virtio/Makefile
index b9b0d8d..c4103b7 100644
--- a/drivers/net/virtio/Makefile
+++ b/drivers/net/virtio/Makefile
@@ -52,6 +52,10 @@ SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_rxtx.c
 SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_ethdev.c
 SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_rxtx_simple.c

+ifeq ($(CONFIG_RTE_ARCH_X86),y)
+SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_rxtx_simple_sse.c
+endif
+
 ifeq ($(CONFIG_RTE_VIRTIO_USER),y)
 SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_user/vhost_user.c
 SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_user/virtio_user_dev.c
diff --git a/drivers/net/virtio/virtio_rxtx_simple.c 
b/drivers/net/virtio/virtio_rxtx_simple.c
index 67430da..485ddce 100644
--- a/drivers/net/virtio/virtio_rxtx_simple.c
+++ b/drivers/net/virtio/virtio_rxtx_simple.c
@@ -51,14 +51,7 @@
 #include 
 #include 

-#include "virtio_logs.h"
-#include "virtio_ethdev.h"
-#include "virtqueue.h"
-#include "virtio_rxtx.h"
-
-#define RTE_VIRTIO_VPMD_RX_BURST 32
-#define RTE_VIRTIO_DESC_PER_LOOP 8
-#define RTE_VIRTIO_VPMD_RX_REARM_THRESH RTE_VIRTIO_VPMD_RX_BURST
+#include "virtio_rxtx_simple.h"

 #ifndef __INTEL_COMPILER
 #pragma GCC diagnostic ignored "-Wcast-qual"
@@ -89,260 +82,6 @@ virtqueue_enqueue_recv_refill_simple(struct virtqueue *vq,
return 0;
 }

-static inline void
-virtio_rxq_rearm_vec(struct virtnet_rx *rxvq)
-{
-   int i;
-   uint16_t desc_idx;
-   struct rte_mbuf **sw_ring;
-   struct vring_desc *start_dp;
-   int ret;
-   struct virtqueue *vq = rxvq->vq;
-
-   desc_idx = vq->vq_avail_idx & (vq->vq_nentries - 1);
-   sw_ring = &vq->sw_ring[desc_idx];
-   start_dp = &vq->vq_ring.desc[desc_idx];
-
-   ret = rte_mempool_get_bulk(rxvq->mpool, (void **)sw_ring,
-   RTE_VIRTIO_VPMD_RX_REARM_THRESH);
-   if (unlikely(ret)) {
-   rte_eth_devices[rxvq->port_id].data->rx_mbuf_alloc_failed +=
-   RTE_VIRTIO_VPMD_RX_REARM_THRESH;
-   return;
-   }
-
-   for (i = 0; i < RTE_VIRTIO_VPMD_RX_REARM_THRESH; i++) {
-   uintptr_t p;
-
-   p = (uintptr_t)&sw_ring[i]->rearm_data;
-   *(uint64_t *)p = rxvq->mbuf_initializer;
-
-   start_dp[i].addr =
-   MBUF_DATA_DMA_ADDR(sw_ring[i], vq->offset) -
-   vq->hw->vtnet_hdr_size;
-   start_dp[i].len = sw_ring[i]->buf_len -
-   RTE_PKTMBUF_HEADROOM + vq->hw->vtnet_hdr_size;
-   }
-
-   vq->vq_avail_idx += RTE_VIRTIO_VPMD_RX_REARM_THRESH;
-   vq->vq_free_cnt -= RTE_VIRTIO_VPMD_RX_REARM_THRESH;
-   vq_update_avail_idx(vq);
-}
-
-#ifdef RTE_MACHINE_CPUFLAG_SSSE3
-
-#include 
-
-/* virtio vPMD receive routine, only accept(nb_pkts >= 
RTE_VIRTIO_DESC_PER_LOOP)
- *
- * This routine is for non-mergeable RX, one desc for each guest buffer.
- * This routine is based on the RX ring layout optimization. Each entry in the
- * avail ring points to the desc with the same index in the desc ring and this
- * will never be changed in the driver.
- *
- * - nb_pkts < RTE_VIRTIO_DESC_PER_LOOP, just return no packet
- */
-uint16_t
-virtio_recv_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
-   uint16_t nb_pkts)
-{
-   struct virtnet_rx *rxvq = rx_queue;
-   struct virtqueue *vq = rxvq->vq;
-   uint16_t nb_used;
-   uint16_t desc_idx;
-   struct vring_used_elem *rused;
-   struct rte_mbuf **sw_ring;
-   struct rte_mbuf **sw_ring_end;
-   uint16_t nb_pkts_received;
-   __m128i shuf_msk1, shuf_msk2, len_adjust;
-
-   shuf_msk1 = _mm_set_epi8(
-   0xFF, 0xFF, 0xFF, 0xFF,
-   0xFF, 0xFF, /* vlan tci */
-   5, 4,   /* dat len */
-   0xFF, 0xFF, 5, 4,   /* pkt len */
-   0xFF, 0xFF, 0xFF, 0xFF  /* packet type */
-
-   );
-
-   shuf_msk2 = _mm_set_epi8(
-   0xFF, 0xFF, 0xFF, 0xFF,
-   0xFF, 0xFF, /* vlan tci */
-   13, 12, /* dat len */
-   0xFF, 0xFF, 13, 12, /* pkt len */
-   0xFF, 0xFF, 0xFF, 0xFF  /* packet type */
-   );
-
-   /* Subtract the header length.
-   *  In which case do we need the header length in used->len ?
-   */
-   len_adjust = _mm_set_epi16(
-

[dpdk-dev] [PATCH v3 1/4] virtio: conditional compilation cleanup

2016-07-05 Thread Jerin Jacob
Removed unnecessary compile time dependency on "use_simple_rxtx".

Signed-off-by: Jerin Jacob 
---
 drivers/net/virtio/Makefile |  3 ---
 drivers/net/virtio/virtio_pci.h |  1 +
 drivers/net/virtio/virtio_rxtx.c| 24 
 drivers/net/virtio/virtio_rxtx.h|  3 +--
 drivers/net/virtio/virtio_rxtx_simple.c |  8 ++--
 drivers/net/virtio/virtio_user_ethdev.c |  1 +
 6 files changed, 17 insertions(+), 23 deletions(-)

diff --git a/drivers/net/virtio/Makefile b/drivers/net/virtio/Makefile
index 3020b68..b9b0d8d 100644
--- a/drivers/net/virtio/Makefile
+++ b/drivers/net/virtio/Makefile
@@ -50,10 +50,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtqueue.c
 SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_pci.c
 SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_rxtx.c
 SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_ethdev.c
-
-ifeq ($(findstring 
RTE_MACHINE_CPUFLAG_SSSE3,$(CFLAGS)),RTE_MACHINE_CPUFLAG_SSSE3)
 SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_rxtx_simple.c
-endif

 ifeq ($(CONFIG_RTE_VIRTIO_USER),y)
 SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_user/vhost_user.c
diff --git a/drivers/net/virtio/virtio_pci.h b/drivers/net/virtio/virtio_pci.h
index dd7693f..b8295a7 100644
--- a/drivers/net/virtio/virtio_pci.h
+++ b/drivers/net/virtio/virtio_pci.h
@@ -253,6 +253,7 @@ struct virtio_hw {
uint8_t use_msix;
uint8_t started;
uint8_t modern;
+   uint8_t use_simple_rxtx;
uint8_t mac_addr[ETHER_ADDR_LEN];
uint32_tnotify_off_multiplier;
uint8_t *isr;
diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index a27208e..e707954 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -67,10 +67,6 @@
 #define VIRTIO_SIMPLE_FLAGS ((uint32_t)ETH_TXQ_FLAGS_NOMULTSEGS | \
ETH_TXQ_FLAGS_NOOFFLOADS)

-#ifdef RTE_MACHINE_CPUFLAG_SSSE3
-static int use_simple_rxtx;
-#endif
-
 static void
 vq_ring_free_chain(struct virtqueue *vq, uint16_t desc_idx)
 {
@@ -333,6 +329,7 @@ virtio_dev_rxtx_start(struct rte_eth_dev *dev)
 */
uint16_t i;
uint16_t desc_idx;
+   struct virtio_hw *hw = dev->data->dev_private;

PMD_INIT_FUNC_TRACE();

@@ -353,8 +350,7 @@ virtio_dev_rxtx_start(struct rte_eth_dev *dev)
nbufs = 0;
error = ENOSPC;

-#ifdef RTE_MACHINE_CPUFLAG_SSSE3
-   if (use_simple_rxtx) {
+   if (hw->use_simple_rxtx) {
for (desc_idx = 0; desc_idx < vq->vq_nentries;
 desc_idx++) {
vq->vq_ring.avail->ring[desc_idx] = desc_idx;
@@ -362,7 +358,7 @@ virtio_dev_rxtx_start(struct rte_eth_dev *dev)
VRING_DESC_F_WRITE;
}
}
-#endif
+
memset(&rxvq->fake_mbuf, 0, sizeof(rxvq->fake_mbuf));
for (desc_idx = 0; desc_idx < RTE_PMD_VIRTIO_RX_MAX_BURST;
 desc_idx++) {
@@ -378,12 +374,11 @@ virtio_dev_rxtx_start(struct rte_eth_dev *dev)
/**
* Enqueue allocated buffers*
***/
-#ifdef RTE_MACHINE_CPUFLAG_SSSE3
-   if (use_simple_rxtx)
+   if (hw->use_simple_rxtx)
error = 
virtqueue_enqueue_recv_refill_simple(vq, m);
else
-#endif
error = virtqueue_enqueue_recv_refill(vq, m);
+
if (error) {
rte_pktmbuf_free(m);
break;
@@ -404,8 +399,7 @@ virtio_dev_rxtx_start(struct rte_eth_dev *dev)
struct virtqueue *vq = txvq->vq;

virtio_dev_vring_start(vq);
-#ifdef RTE_MACHINE_CPUFLAG_SSSE3
-   if (use_simple_rxtx) {
+   if (hw->use_simple_rxtx) {
uint16_t mid_idx  = vq->vq_nentries >> 1;

for (desc_idx = 0; desc_idx < mid_idx; desc_idx++) {
@@ -426,7 +420,7 @@ virtio_dev_rxtx_start(struct rte_eth_dev *dev)
 desc_idx++)
vq->vq_ring.avail->ring[desc_idx] = desc_idx;
}
-#endif
+
VIRTQUEUE_DUMP(vq);
}
 }
@@ -456,9 +450,7 @@ virtio_dev_rx_queue_setup(struct rte_eth_dev *dev,

dev->data->rx_queues[queue_idx] = rxvq;

-#ifdef RTE_MACHINE_CPUFLAG_SSSE3
virtio_rxq_vec_setup(rxvq);
-#endif

return 0;
 }
@@ -517,7 +509,7 @@ virtio_dev_tx_queue_setup(struct rte_eth_dev *dev,
PMD_INIT_LOG(INFO, "Using simple rx/tx path");
dev->tx_pkt_burst = virtio_xmit_pkts_simple;
dev->rx_pkt_burst = virtio_recv_pkts_vec;
-   use_simple_rxtx 

[dpdk-dev] [PATCH v3 0/4] Virtio NEON support for ARM

2016-07-05 Thread Jerin Jacob
This patch-set includes,

1) General cleanup of compile time dependency.
2) made vector handler section based on run-time cpuflags
2) Added NEON support for optimized Rx handling

This patch-set is based on dpdk-next-virtio/master

v3:
Address Yuanhan's review comments
http://dpdk.org/dev/patchwork/patch/14495/
http://dpdk.org/dev/patchwork/patch/14496/

v2:
- made vector handler selection based on run-time cpuflags (Suggested by Thomas)
- moved vector implementations to .c file instead of .h file(Suggested by 
Jianbo)

Jerin Jacob (4):
  virtio: conditional compilation cleanup
  virtio: move SSE based Rx implementation to separate file
  virtio: add cpuflag based vector handler selection
  virtio: add neon support

 MAINTAINERS  |   1 +
 doc/guides/rel_notes/release_16_07.rst   |   2 +
 drivers/net/virtio/Makefile  |   7 +-
 drivers/net/virtio/virtio_pci.h  |   1 +
 drivers/net/virtio/virtio_rxtx.c |  63 ---
 drivers/net/virtio/virtio_rxtx.h |   3 +-
 drivers/net/virtio/virtio_rxtx_simple.c  | 269 ++-
 drivers/net/virtio/virtio_rxtx_simple.h  | 133 +
 drivers/net/virtio/virtio_rxtx_simple_neon.c | 235 +++
 drivers/net/virtio/virtio_rxtx_simple_sse.c  | 222 ++
 drivers/net/virtio/virtio_user_ethdev.c  |   1 +
 11 files changed, 646 insertions(+), 291 deletions(-)
 create mode 100644 drivers/net/virtio/virtio_rxtx_simple.h
 create mode 100644 drivers/net/virtio/virtio_rxtx_simple_neon.c
 create mode 100644 drivers/net/virtio/virtio_rxtx_simple_sse.c

-- 
2.5.5



[dpdk-dev] xstats performance

2016-07-05 Thread Rasesh Mody
Hi Remy,

> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Remy Horton
> Sent: Friday, July 01, 2016 2:15 AM
> 
> 
> On 29/06/2016 17:40, Thomas Monjalon wrote:
> [..]
> > I don't think it is possible to standardize stats ids, for two reasons:
> > - it is hard to maintain and avoid conflicts between drivers
> > - the drivers would have to lookup the names which degrades
> > performance
> 
> I designed it that way to keep flexibility down the line rather than 
> specifically
> for the above use-case.
> 
> 
> > I think the idea of Olivier would improve the performance of stats 
> > retrieval,
> > which was the idea of this rework :)
> > Unfortunately we need someone available to fix it quickly for RC2.
> 
> 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.

> ..Remy


[dpdk-dev] [PATCH] scripts: fix commit check of first word

2016-07-05 Thread Thomas Monjalon
The first word of each commit message is checked.
But when the commit range was greater than 1, only the latest commit
was checked.
It is fixed by checking each commit separately.

Fixes: 9c24780f0d5e ("scripts: check first word of commit messages")

Signed-off-by: Thomas Monjalon 
---
 scripts/check-git-log.sh | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/scripts/check-git-log.sh b/scripts/check-git-log.sh
index 7d2c7ee..c7fc0e4 100755
--- a/scripts/check-git-log.sh
+++ b/scripts/check-git-log.sh
@@ -49,6 +49,7 @@ fi

 range=${1:-origin/master..}

+commits=$(git log --format='%h' $range)
 headlines=$(git log --format='%s' $range)
 bodylines=$(git log --format='%b' $range)
 tags=$(git log --format='%b' $range | grep -i -e 'by *:' -e 'fix.*:')
@@ -115,9 +116,10 @@ bad=$(echo "$bodylines" | grep -v '^Fixes:' | awk 
'length>75 {print}' | sed 's,^
 [ -z "$bad" ] || printf "Line too long:\n$bad\n"

 # check starting commit message with "It"
-bad=$(echo "$bodylines" | head -n1 | grep -E --color=always \
-   -ie '^It ' \
-   | sed 's,^,\t,')
+bad=$(for commit in $commits ; do
+   firstbodyline=$(git log --format='%b' -1 $commit | head -n1)
+   echo "$firstbodyline" | grep --color=always -ie '^It '
+done | sed 's,^,\t,')
 [ -z "$bad" ] || printf "Wrong beginning of commit message:\n$bad\n"

 # check tags spelling
-- 
2.7.0



[dpdk-dev] [PATCH v2] mk: filter duplicate configuration entries

2016-07-05 Thread Ferruh Yigit
On 6/30/2016 1:00 PM, Christian Ehrhardt wrote:
> *updates in v2*
> - move to .config target
> - fix usage order of tac
> - simplify inner section by only using awk (instead of awk+loop+bash+sed)
> 
> Due to the hierarchy and the demand to keep the base config showing all
> options, some config keys end up multiple times in the .config file.
> 
> Due to the way the actual config is sourced only the last entry is
> important. That can confuse people changing values in .config which
> are then ignored.
> 
> A suggested solution was to filter for duplicates at the end of the
> actual config step which is implemented here.
> 
> Signed-off-by: Christian Ehrhardt 
> ---
>  mk/rte.sdkconfig.mk | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/mk/rte.sdkconfig.mk b/mk/rte.sdkconfig.mk
> index a3acfe6..6c46122 100644
> --- a/mk/rte.sdkconfig.mk
> +++ b/mk/rte.sdkconfig.mk
> @@ -79,11 +79,17 @@ $(RTE_OUTPUT):
>  ifdef NODOTCONF
>  $(RTE_OUTPUT)/.config: ;
>  else
> +# Generate config from template, if there are duplicates keep only the last
>  $(RTE_OUTPUT)/.config: $(RTE_CONFIG_TEMPLATE) FORCE | $(RTE_OUTPUT)
>   $(Q)if [ "$(RTE_CONFIG_TEMPLATE)" != "" -a -f "$(RTE_CONFIG_TEMPLATE)" 
> ]; then \
>   $(CPP) -undef -P -x assembler-with-cpp \
>   -ffreestanding \
>   -o $(RTE_OUTPUT)/.config_tmp $(RTE_CONFIG_TEMPLATE) ; \
> + tac $(RTE_OUTPUT)/.config_tmp > 
> $(RTE_OUTPUT)/.config_tmp_reverse ; \
Now we are adding new binary dependency (tac) to build system and we now
create a interim file, as far as I understand which is required to use awk.
Although this is a nice piece of awk command, I am not sure if sed
alternative or this is better because of above two issues. This is a
question that I have more than a comment against one to another.

If you prefer to use this one, I confirmed that this works fine.

> + awk --field-separator '=' '!/^#/ {if (!seen[$$1]) {print 
> ($$0)}; seen[$$1]=1;} \
> + /^#/ {print($$0)}' $(RTE_OUTPUT)/.config_tmp_reverse \
> + | tac > $(RTE_OUTPUT)/.config_tmp ; \
> + rm $(RTE_OUTPUT)/.config_tmp_reverse ; \
>   if ! cmp -s $(RTE_OUTPUT)/.config_tmp $(RTE_OUTPUT)/.config; 
> then \
>   cp $(RTE_OUTPUT)/.config_tmp $(RTE_OUTPUT)/.config ; \
>   cp $(RTE_OUTPUT)/.config_tmp $(RTE_OUTPUT)/.config.orig 
> ; \
> 



[dpdk-dev] [PATCH 18/18] app/testpmd: display sw packet type

2016-07-05 Thread Olivier Matz
In addition to the packet type returned by the PMD, also display the
packet type calculated by parsing the packet in software. This is
particularly useful to compare the 2 values.

Note: it does not mean that both hw and sw always have to provide the
same value, since it depends on what hardware supports.

Signed-off-by: Olivier Matz 
---
 app/test-pmd/rxonly.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/app/test-pmd/rxonly.c b/app/test-pmd/rxonly.c
index aba07ee..00da1a2 100644
--- a/app/test-pmd/rxonly.c
+++ b/app/test-pmd/rxonly.c
@@ -93,6 +93,8 @@ pkt_burst_receive(struct fwd_stream *fs)
uint16_t i, packet_type;
uint16_t is_encapsulation;
char buf[256];
+   struct rte_mbuf_hdr_lens hdr_lens;
+   uint32_t sw_packet_type;

 #ifdef RTE_TEST_PMD_RECORD_CORE_CYCLES
uint64_t start_tsc;
@@ -164,8 +166,26 @@ pkt_burst_receive(struct fwd_stream *fs)
mb->vlan_tci, mb->vlan_tci_outer);
if (mb->packet_type) {
rte_get_ptype_name(mb->packet_type, buf, sizeof(buf));
-   printf(" - %s", buf);
+   printf(" - hw ptype: %s", buf);
}
+   sw_packet_type = rte_pktmbuf_get_ptype(mb, &hdr_lens,
+   RTE_PTYPE_ALL_MASK);
+   rte_get_ptype_name(sw_packet_type, buf, sizeof(buf));
+   printf(" - sw ptype: %s", buf);
+   if (sw_packet_type & RTE_PTYPE_L2_MASK)
+   printf(" - l2_len=%d", hdr_lens.l2_len);
+   if (sw_packet_type & RTE_PTYPE_L3_MASK)
+   printf(" - l3_len=%d", hdr_lens.l3_len);
+   if (sw_packet_type & RTE_PTYPE_L4_MASK)
+   printf(" - l4_len=%d", hdr_lens.l4_len);
+   if (sw_packet_type & RTE_PTYPE_TUNNEL_MASK)
+   printf(" - tunnel_len=%d", hdr_lens.tunnel_len);
+   if (sw_packet_type & RTE_PTYPE_INNER_L2_MASK)
+   printf(" - inner_l2_len=%d", hdr_lens.inner_l2_len);
+   if (sw_packet_type & RTE_PTYPE_INNER_L3_MASK)
+   printf(" - inner_l3_len=%d", hdr_lens.inner_l3_len);
+   if (sw_packet_type & RTE_PTYPE_INNER_L4_MASK)
+   printf(" - inner_l4_len=%d", hdr_lens.inner_l4_len);
if (is_encapsulation) {
struct ipv4_hdr *ipv4_hdr;
struct ipv6_hdr *ipv6_hdr;
-- 
2.8.1



[dpdk-dev] [PATCH 17/18] app/testpmd: dump ptype using the new function

2016-07-05 Thread Olivier Matz
Use the function introduced in previous commit to dump the packet type
of the received packet.

Signed-off-by: Olivier Matz 
---
 app/test-pmd/rxonly.c | 175 ++
 1 file changed, 4 insertions(+), 171 deletions(-)

diff --git a/app/test-pmd/rxonly.c b/app/test-pmd/rxonly.c
index fbf287d..aba07ee 100644
--- a/app/test-pmd/rxonly.c
+++ b/app/test-pmd/rxonly.c
@@ -92,6 +92,7 @@ pkt_burst_receive(struct fwd_stream *fs)
uint16_t nb_rx;
uint16_t i, packet_type;
uint16_t is_encapsulation;
+   char buf[256];

 #ifdef RTE_TEST_PMD_RECORD_CORE_CYCLES
uint64_t start_tsc;
@@ -162,177 +163,9 @@ pkt_burst_receive(struct fwd_stream *fs)
printf(" - QinQ VLAN tci=0x%x, VLAN tci outer=0x%x",
mb->vlan_tci, mb->vlan_tci_outer);
if (mb->packet_type) {
-   uint32_t ptype;
-
-   /* (outer) L2 packet type */
-   ptype = mb->packet_type & RTE_PTYPE_L2_MASK;
-   switch (ptype) {
-   case RTE_PTYPE_L2_ETHER:
-   printf(" - (outer) L2 type: ETHER");
-   break;
-   case RTE_PTYPE_L2_ETHER_TIMESYNC:
-   printf(" - (outer) L2 type: ETHER_Timesync");
-   break;
-   case RTE_PTYPE_L2_ETHER_ARP:
-   printf(" - (outer) L2 type: ETHER_ARP");
-   break;
-   case RTE_PTYPE_L2_ETHER_LLDP:
-   printf(" - (outer) L2 type: ETHER_LLDP");
-   break;
-   case RTE_PTYPE_L2_ETHER_NSH:
-   printf(" - (outer) L2 type: ETHER_NSH");
-   break;
-   default:
-   printf(" - (outer) L2 type: Unknown");
-   break;
-   }
-
-   /* (outer) L3 packet type */
-   ptype = mb->packet_type & RTE_PTYPE_L3_MASK;
-   switch (ptype) {
-   case RTE_PTYPE_L3_IPV4:
-   printf(" - (outer) L3 type: IPV4");
-   break;
-   case RTE_PTYPE_L3_IPV4_EXT:
-   printf(" - (outer) L3 type: IPV4_EXT");
-   break;
-   case RTE_PTYPE_L3_IPV6:
-   printf(" - (outer) L3 type: IPV6");
-   break;
-   case RTE_PTYPE_L3_IPV4_EXT_UNKNOWN:
-   printf(" - (outer) L3 type: IPV4_EXT_UNKNOWN");
-   break;
-   case RTE_PTYPE_L3_IPV6_EXT:
-   printf(" - (outer) L3 type: IPV6_EXT");
-   break;
-   case RTE_PTYPE_L3_IPV6_EXT_UNKNOWN:
-   printf(" - (outer) L3 type: IPV6_EXT_UNKNOWN");
-   break;
-   default:
-   printf(" - (outer) L3 type: Unknown");
-   break;
-   }
-
-   /* (outer) L4 packet type */
-   ptype = mb->packet_type & RTE_PTYPE_L4_MASK;
-   switch (ptype) {
-   case RTE_PTYPE_L4_TCP:
-   printf(" - (outer) L4 type: TCP");
-   break;
-   case RTE_PTYPE_L4_UDP:
-   printf(" - (outer) L4 type: UDP");
-   break;
-   case RTE_PTYPE_L4_FRAG:
-   printf(" - (outer) L4 type: L4_FRAG");
-   break;
-   case RTE_PTYPE_L4_SCTP:
-   printf(" - (outer) L4 type: SCTP");
-   break;
-   case RTE_PTYPE_L4_ICMP:
-   printf(" - (outer) L4 type: ICMP");
-   break;
-   case RTE_PTYPE_L4_NONFRAG:
-   printf(" - (outer) L4 type: L4_NONFRAG");
-   break;
-   default:
-   printf(" - (outer) L4 type: Unknown");
-   break;
-   }
-
-   /* packet tunnel type */
-   ptype = mb->packet_type & RTE_PTYPE_TUNNEL_MASK;
-   switch (ptype) {
-   case RTE_PTYPE_TUNNEL_IP:
-   printf(" - Tunnel type: IP");
-   

[dpdk-dev] [PATCH 16/18] mbuf: clarify definition of fragment packet types

2016-07-05 Thread Olivier Matz
An IPv4 packet is considered as a fragment if:
- MF (more fragment) bit is set
- or Fragment_Offset field is non-zero

Update the API documentation of packet types to reflect this.

Signed-off-by: Olivier Matz 
---
 lib/librte_mbuf/rte_mbuf_ptype.h | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/lib/librte_mbuf/rte_mbuf_ptype.h b/lib/librte_mbuf/rte_mbuf_ptype.h
index 21bba37..55ee24f 100644
--- a/lib/librte_mbuf/rte_mbuf_ptype.h
+++ b/lib/librte_mbuf/rte_mbuf_ptype.h
@@ -234,7 +234,7 @@ extern "C" {
  *
  * Packet format:
  * <'ether type'=0x0800
- * | 'version'=4, 'protocol'=6, 'MF'=0>
+ * | 'version'=4, 'protocol'=6, 'MF'=0, 'frag_offset'=0>
  * or,
  * <'ether type'=0x86DD
  * | 'version'=6, 'next header'=6>
@@ -246,7 +246,7 @@ extern "C" {
  *
  * Packet format:
  * <'ether type'=0x0800
- * | 'version'=4, 'protocol'=17, 'MF'=0>
+ * | 'version'=4, 'protocol'=17, 'MF'=0, 'frag_offset'=0>
  * or,
  * <'ether type'=0x86DD
  * | 'version'=6, 'next header'=17>
@@ -265,6 +265,9 @@ extern "C" {
  * <'ether type'=0x0800
  * | 'version'=4, 'MF'=1>
  * or,
+ * <'ether type'=0x0800
+ * | 'version'=4, 'frag_offset'!=0>
+ * or,
  * <'ether type'=0x86DD
  * | 'version'=6, 'next header'=44>
  */
@@ -275,7 +278,7 @@ extern "C" {
  *
  * Packet format:
  * <'ether type'=0x0800
- * | 'version'=4, 'protocol'=132, 'MF'=0>
+ * | 'version'=4, 'protocol'=132, 'MF'=0, 'frag_offset'=0>
  * or,
  * <'ether type'=0x86DD
  * | 'version'=6, 'next header'=132>
@@ -287,7 +290,7 @@ extern "C" {
  *
  * Packet format:
  * <'ether type'=0x0800
- * | 'version'=4, 'protocol'=1, 'MF'=0>
+ * | 'version'=4, 'protocol'=1, 'MF'=0, 'frag_offset'=0>
  * or,
  * <'ether type'=0x86DD
  * | 'version'=6, 'next header'=1>
@@ -303,7 +306,7 @@ extern "C" {
  *
  * Packet format:
  * <'ether type'=0x0800
- * | 'version'=4, 'protocol'!=[6|17|132|1], 'MF'=0>
+ * | 'version'=4, 'protocol'!=[6|17|132|1], 'MF'=0, 'frag_offset'=0>
  * or,
  * <'ether type'=0x86DD
  * | 'version'=6, 'next header'!=[6|17|44|132|1]>
@@ -491,7 +494,7 @@ extern "C" {
  *
  * Packet format (inner only):
  * <'ether type'=0x0800
- * | 'version'=4, 'protocol'=6, 'MF'=0>
+ * | 'version'=4, 'protocol'=6, 'MF'=0, 'frag_offset'=0>
  * or,
  * <'ether type'=0x86DD
  * | 'version'=6, 'next header'=6>
@@ -503,7 +506,7 @@ extern "C" {
  *
  * Packet format (inner only):
  * <'ether type'=0x0800
- * | 'version'=4, 'protocol'=17, 'MF'=0>
+ * | 'version'=4, 'protocol'=17, 'MF'=0, 'frag_offset'=0>
  * or,
  * <'ether type'=0x86DD
  * | 'version'=6, 'next header'=17>
@@ -517,6 +520,9 @@ extern "C" {
  * <'ether type'=0x0800
  * | 'version'=4, 'MF'=1>
  * or,
+ * <'ether type'=0x0800
+ * | 'version'=4, 'frag_offset'!=0>
+ * or,
  * <'ether type'=0x86DD
  * | 'version'=6, 'next header'=44>
  */
@@ -527,7 +533,7 @@ extern "C" {
  *
  * Packet format (inner only):
  * <'ether type'=0x0800
- * | 'version'=4, 'protocol'=132, 'MF'=0>
+ * | 'version'=4, 'protocol'=132, 'MF'=0, 'frag_offset'=0>
  * or,
  * <'ether type'=0x86DD
  * | 'version'=6, 'next header'=132>
@@ -539,7 +545,7 @@ extern "C" {
  *
  * Packet format (inner only):
  * <'ether type'=0x0800
- * | 'version'=4, 'protocol'=1, 'MF'=0>
+ * | 'version'=4, 'protocol'=1, 'MF'=0, 'frag_offset'=0>
  * or,
  * <'ether type'=0x86DD
  * | 'version'=6, 'next header'=1>
@@ -552,7 +558,7 @@ extern "C" {
  *
  * Packet format (inner only):
  * <'ether type'=0x0800
- * | 'version'=4, 'protocol'!=[6|17|132|1], 'MF'=0>
+ * | 'version'=4, 'protocol'!=[6|17|132|1], 'MF'=0, 'frag_offset'=0>
  * or,
  * <'ether type'=0x86DD
  * | 'version'=6, 'next header'!=[6|17|44|132|1]>
-- 
2.8.1



[dpdk-dev] [PATCH 15/18] mbuf: add functions to dump packet type

2016-07-05 Thread Olivier Matz
Dumping the packet type is useful for debug purposes. Instead
of having each application providing its function to do that,
introduce functions to do it.

It factorizes the code and reduces the risk of desynchronization between
the new packet types and the dump function.

Signed-off-by: Olivier Matz 
---
 doc/guides/rel_notes/release_16_11.rst |   4 +
 lib/librte_mbuf/rte_mbuf_ptype.c   | 192 +
 lib/librte_mbuf/rte_mbuf_ptype.h   |  89 +++
 lib/librte_mbuf/rte_mbuf_version.map   |   8 ++
 4 files changed, 293 insertions(+)

diff --git a/doc/guides/rel_notes/release_16_11.rst 
b/doc/guides/rel_notes/release_16_11.rst
index 0ef8a87..7ce201b 100644
--- a/doc/guides/rel_notes/release_16_11.rst
+++ b/doc/guides/rel_notes/release_16_11.rst
@@ -44,6 +44,10 @@ New Features
   Added a new function ``rte_pktmbuf_get_ptype()`` to parse an Ethernet packet
   in an mbuf chain and retrieve its packet type by software.

+* **Added functions to dump the packet type as a string.**
+
+  Added new functions ``rte_get_ptype_*()`` to dump a packet type as a string.
+
 Resolved Issues
 ---

diff --git a/lib/librte_mbuf/rte_mbuf_ptype.c b/lib/librte_mbuf/rte_mbuf_ptype.c
index 2abb896..848b622 100644
--- a/lib/librte_mbuf/rte_mbuf_ptype.c
+++ b/lib/librte_mbuf/rte_mbuf_ptype.c
@@ -44,6 +44,198 @@
 #include 
 #include 

+/* get the name of the l2 packet type */
+const char *rte_get_ptype_l2_name(uint32_t ptype)
+{
+   switch (ptype & RTE_PTYPE_L2_MASK) {
+   case RTE_PTYPE_L2_ETHER: return "L2_ETHER";
+   case RTE_PTYPE_L2_ETHER_TIMESYNC: return "L2_ETHER_TIMESYNC";
+   case RTE_PTYPE_L2_ETHER_ARP: return "L2_ETHER_ARP";
+   case RTE_PTYPE_L2_ETHER_LLDP: return "L2_ETHER_LLDP";
+   case RTE_PTYPE_L2_ETHER_NSH: return "L2_ETHER_NSH";
+   case RTE_PTYPE_L2_ETHER_VLAN: return "L2_ETHER_VLAN";
+   case RTE_PTYPE_L2_ETHER_QINQ: return "L2_ETHER_QINQ";
+   case RTE_PTYPE_L2_ETHER_MPLS: return "L2_ETHER_MPLS";
+   default: return "L2_UNKNOWN";
+   }
+}
+
+/* get the name of the l3 packet type */
+const char *rte_get_ptype_l3_name(uint32_t ptype)
+{
+   switch (ptype & RTE_PTYPE_L3_MASK) {
+   case RTE_PTYPE_L3_IPV4: return "L3_IPV4";
+   case RTE_PTYPE_L3_IPV4_EXT: return "L3_IPV4_EXT";
+   case RTE_PTYPE_L3_IPV6: return "L3_IPV6";
+   case RTE_PTYPE_L3_IPV4_EXT_UNKNOWN: return "L3_IPV4_EXT_UNKNOWN";
+   case RTE_PTYPE_L3_IPV6_EXT: return "L3_IPV6_EXT";
+   case RTE_PTYPE_L3_IPV6_EXT_UNKNOWN: return "L3_IPV6_EXT_UNKNOWN";
+   default: return "L3_UNKNOWN";
+   }
+}
+
+/* get the name of the l4 packet type */
+const char *rte_get_ptype_l4_name(uint32_t ptype)
+{
+   switch (ptype & RTE_PTYPE_L4_MASK) {
+   case RTE_PTYPE_L4_TCP: return "L4_TCP";
+   case RTE_PTYPE_L4_UDP: return "L4_UDP";
+   case RTE_PTYPE_L4_FRAG: return "L4_FRAG";
+   case RTE_PTYPE_L4_SCTP: return "L4_SCTP";
+   case RTE_PTYPE_L4_ICMP: return "L4_ICMP";
+   case RTE_PTYPE_L4_NONFRAG: return "L4_NONFRAG";
+   default: return "L4_UNKNOWN";
+   }
+}
+
+/* get the name of the tunnel packet type */
+const char *rte_get_ptype_tunnel_name(uint32_t ptype)
+{
+   switch (ptype & RTE_PTYPE_TUNNEL_MASK) {
+   case RTE_PTYPE_TUNNEL_IP: return "TUNNEL_IP";
+   case RTE_PTYPE_TUNNEL_GRE: return "TUNNEL_GRE";
+   case RTE_PTYPE_TUNNEL_VXLAN: return "TUNNEL_VXLAN";
+   case RTE_PTYPE_TUNNEL_NVGRE: return "TUNNEL_NVGRE";
+   case RTE_PTYPE_TUNNEL_GENEVE: return "TUNNEL_GENEVE";
+   case RTE_PTYPE_TUNNEL_GRENAT: return "TUNNEL_GRENAT";
+   default: return "TUNNEL_UNKNOWN";
+   }
+}
+
+/* get the name of the inner_l2 packet type */
+const char *rte_get_ptype_inner_l2_name(uint32_t ptype)
+{
+   switch (ptype & RTE_PTYPE_INNER_L2_MASK) {
+   case RTE_PTYPE_INNER_L2_ETHER: return "INNER_L2_ETHER";
+   case RTE_PTYPE_INNER_L2_ETHER_VLAN: return "INNER_L2_ETHER_VLAN";
+   case RTE_PTYPE_INNER_L2_ETHER_QINQ: return "INNER_L2_ETHER_QINQ";
+   case RTE_PTYPE_INNER_L2_ETHER_MPLS: return "INNER_L2_ETHER_MPLS";
+   default: return "INNER_L2_UNKNOWN";
+   }
+}
+
+/* get the name of the inner_l3 packet type */
+const char *rte_get_ptype_inner_l3_name(uint32_t ptype)
+{
+   switch (ptype & RTE_PTYPE_INNER_L3_MASK) {
+   case RTE_PTYPE_INNER_L3_IPV4: return "INNER_L3_IPV4";
+   case RTE_PTYPE_INNER_L3_IPV4_EXT: return "INNER_L3_IPV4_EXT";
+   case RTE_PTYPE_INNER_L3_IPV6: return "INNER_L3_IPV6";
+   case RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN:
+   return "INNER_L3_IPV4_EXT_UNKNOWN";
+   case RTE_PTYPE_INNER_L3_IPV6_EXT: return "INNER_L3_IPV6_EXT";
+   case RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN:
+   return "INNER_L3_IPV6_EXT_UNKNOWN";
+   default: return "INNER_L3_UNKNOWN";
+   }
+}
+
+/* get the name of the inner_l4 packet type */
+const char *rte_get_ptype_inner_l4_name(uint32_t ptype)
+{
+   switch (p

[dpdk-dev] [PATCH 14/18] mbuf: get ptype for the first layers only

2016-07-05 Thread Olivier Matz
Add a parameter to rte_pktmbuf_get_ptype() to select which
layers should be parsed. This avoids to parse all layers if
only the first ones are required.

Signed-off-by: Olivier Matz 
---
 lib/librte_mbuf/rte_mbuf_ptype.c | 33 -
 lib/librte_mbuf/rte_mbuf_ptype.h |  7 ++-
 2 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 e5be308..2abb896 100644
--- a/lib/librte_mbuf/rte_mbuf_ptype.c
+++ b/lib/librte_mbuf/rte_mbuf_ptype.c
@@ -254,7 +254,7 @@ skip_ip6_ext(uint16_t proto, const struct rte_mbuf *m, 
uint32_t *off,

 /* 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 *hdr_lens, uint32_t layers)
 {
struct rte_mbuf_hdr_lens local_hdr_lens;
const struct ether_hdr *eh;
@@ -273,6 +273,9 @@ uint32_t rte_pktmbuf_get_ptype(const struct rte_mbuf *m,
off = sizeof(*eh);
hdr_lens->l2_len = off;

+   if ((layers & RTE_PTYPE_L2_MASK) == 0)
+   return 0;
+
if (proto == rte_cpu_to_be_16(ETHER_TYPE_IPv4))
goto l3; /* fast path if packet is IPv4 */

@@ -322,6 +325,9 @@ uint32_t rte_pktmbuf_get_ptype(const struct rte_mbuf *m,
}

  l3:
+   if ((layers & RTE_PTYPE_L3_MASK) == 0)
+   return pkt_type;
+
if (proto == rte_cpu_to_be_16(ETHER_TYPE_IPv4)) {
const struct ipv4_hdr *ip4h;
struct ipv4_hdr ip4h_copy;
@@ -333,6 +339,10 @@ uint32_t rte_pktmbuf_get_ptype(const struct rte_mbuf *m,
pkt_type |= ptype_l3_ip(ip4h->version_ihl);
hdr_lens->l3_len = ip4_hlen(ip4h);
off += hdr_lens->l3_len;
+
+   if ((layers & RTE_PTYPE_L4_MASK) == 0)
+   return pkt_type;
+
if (ip4h->fragment_offset & rte_cpu_to_be_16(
IPV4_HDR_OFFSET_MASK | IPV4_HDR_MF_FLAG)) {
pkt_type |= RTE_PTYPE_L4_FRAG;
@@ -360,6 +370,10 @@ uint32_t rte_pktmbuf_get_ptype(const struct rte_mbuf *m,
}
if (proto == 0)
return pkt_type;
+
+   if ((layers & RTE_PTYPE_L4_MASK) == 0)
+   return pkt_type;
+
if (frag) {
pkt_type |= RTE_PTYPE_L4_FRAG;
hdr_lens->l4_len = 0;
@@ -388,6 +402,10 @@ uint32_t rte_pktmbuf_get_ptype(const struct rte_mbuf *m,
uint32_t prev_off = off;

hdr_lens->l4_len = 0;
+
+   if ((layers & RTE_PTYPE_TUNNEL_MASK) == 0)
+   return pkt_type;
+
pkt_type |= ptype_tunnel(&proto, m, &off);
hdr_lens->tunnel_len = off - prev_off;
}
@@ -395,6 +413,9 @@ uint32_t rte_pktmbuf_get_ptype(const struct rte_mbuf *m,
/* same job for inner header: we need to duplicate the code
 * because the packet types do not have the same value.
 */
+   if ((layers & RTE_PTYPE_INNER_L2_MASK) == 0)
+   return pkt_type;
+
if (proto == rte_cpu_to_be_16(ETHER_TYPE_TEB)) {
eh = rte_pktmbuf_read(m, off, sizeof(*eh), &eh_copy);
if (unlikely(eh == NULL))
@@ -438,6 +459,9 @@ uint32_t rte_pktmbuf_get_ptype(const struct rte_mbuf *m,
return pkt_type;
}

+   if ((layers & RTE_PTYPE_INNER_L3_MASK) == 0)
+   return pkt_type;
+
if (proto == rte_cpu_to_be_16(ETHER_TYPE_IPv4)) {
const struct ipv4_hdr *ip4h;
struct ipv4_hdr ip4h_copy;
@@ -449,6 +473,9 @@ uint32_t rte_pktmbuf_get_ptype(const struct rte_mbuf *m,
pkt_type |= ptype_inner_l3_ip(ip4h->version_ihl);
hdr_lens->inner_l3_len = ip4_hlen(ip4h);
off += hdr_lens->inner_l3_len;
+
+   if ((layers & RTE_PTYPE_INNER_L4_MASK) == 0)
+   return pkt_type;
if (ip4h->fragment_offset &
rte_cpu_to_be_16(IPV4_HDR_OFFSET_MASK |
IPV4_HDR_MF_FLAG)) {
@@ -481,6 +508,10 @@ uint32_t rte_pktmbuf_get_ptype(const struct rte_mbuf *m,
}
if (proto == 0)
return pkt_type;
+
+   if ((layers & RTE_PTYPE_INNER_L4_MASK) == 0)
+   return pkt_type;
+
if (frag) {
pkt_type |= RTE_PTYPE_INNER_L4_FRAG;
hdr_lens->inner_l4_len = 0;
diff --git a/lib/librte_mbuf/rte_mbuf_ptype.h b/lib/librte_mbuf/rte_mbuf_ptype.h
index be3ad96..9af52b4 100644
--- a/lib/librte_mbuf/rte_mbuf_ptype.h
+++ b/lib/librte_mbuf/rte_mbuf_ptype.h
@@ -622,11 +622,16 @@ struct rte_mbuf_hdr_lens {
  * @param hdr_lens
  *   A pointer to a structure where the header lengths will be returned,

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

2016-07-05 Thread Olivier Matz
Add support of Nvgre tunnels in rte_pktmbuf_get_ptype().  At the same
time, as Nvgre transports Ethernet, we need to add the support for inner
Vlan, QinQ, and Mpls.

Signed-off-by: Jean Dao 
Signed-off-by: Olivier Matz 
---
 lib/librte_mbuf/rte_mbuf_ptype.c | 48 ++--
 lib/librte_mbuf/rte_mbuf_ptype.h | 20 -
 2 files changed, 65 insertions(+), 3 deletions(-)

diff --git a/lib/librte_mbuf/rte_mbuf_ptype.c b/lib/librte_mbuf/rte_mbuf_ptype.c
index f681a42..e5be308 100644
--- a/lib/librte_mbuf/rte_mbuf_ptype.c
+++ b/lib/librte_mbuf/rte_mbuf_ptype.c
@@ -183,7 +183,10 @@ ptype_tunnel(uint16_t *proto, const struct rte_mbuf *m,

*off += opt_len[flags];
*proto = gh->proto;
-   return RTE_PTYPE_TUNNEL_GRE;
+   if (*proto == rte_cpu_to_be_16(ETHER_TYPE_TEB))
+   return RTE_PTYPE_TUNNEL_NVGRE;
+   else
+   return RTE_PTYPE_TUNNEL_GRE;
}
case IPPROTO_IPIP:
*proto = rte_cpu_to_be_16(ETHER_TYPE_IPv4);
@@ -392,7 +395,48 @@ uint32_t rte_pktmbuf_get_ptype(const struct rte_mbuf *m,
/* same job for inner header: we need to duplicate the code
 * because the packet types do not have the same value.
 */
-   hdr_lens->inner_l2_len = 0;
+   if (proto == rte_cpu_to_be_16(ETHER_TYPE_TEB)) {
+   eh = rte_pktmbuf_read(m, off, sizeof(*eh), &eh_copy);
+   if (unlikely(eh == NULL))
+   return pkt_type;
+   pkt_type |= RTE_PTYPE_INNER_L2_ETHER;
+   proto = eh->ether_type;
+   off += sizeof(*eh);
+   hdr_lens->inner_l2_len = sizeof(*eh);
+   }
+
+   if (proto == rte_cpu_to_be_16(ETHER_TYPE_VLAN)) {
+   const struct vlan_hdr *vh;
+   struct vlan_hdr vh_copy;
+
+   pkt_type &= ~RTE_PTYPE_INNER_L2_MASK;
+   pkt_type |= RTE_PTYPE_INNER_L2_ETHER_VLAN;
+   vh = rte_pktmbuf_read(m, off, sizeof(*vh), &vh_copy);
+   if (unlikely(vh == NULL))
+   return pkt_type;
+   off += sizeof(*vh);
+   hdr_lens->inner_l2_len += sizeof(*vh);
+   proto = vh->eth_proto;
+   } else if (proto == rte_cpu_to_be_16(ETHER_TYPE_QINQ)) {
+   const struct vlan_hdr *vh;
+   struct vlan_hdr vh_copy;
+
+   pkt_type &= ~RTE_PTYPE_INNER_L2_MASK;
+   pkt_type |= RTE_PTYPE_INNER_L2_ETHER_QINQ;
+   vh = rte_pktmbuf_read(m, off + sizeof(*vh), sizeof(*vh),
+   &vh_copy);
+   if (unlikely(vh == NULL))
+   return pkt_type;
+   off += 2 * sizeof(*vh);
+   hdr_lens->inner_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))) {
+   pkt_type &= ~RTE_PTYPE_INNER_L2_MASK;
+   pkt_type |= RTE_PTYPE_INNER_L2_ETHER_MPLS;
+   hdr_lens->inner_l2_len += 4;
+   return pkt_type;
+   }

if (proto == rte_cpu_to_be_16(ETHER_TYPE_IPv4)) {
const struct ipv4_hdr *ip4h;
diff --git a/lib/librte_mbuf/rte_mbuf_ptype.h b/lib/librte_mbuf/rte_mbuf_ptype.h
index d037504..be3ad96 100644
--- a/lib/librte_mbuf/rte_mbuf_ptype.h
+++ b/lib/librte_mbuf/rte_mbuf_ptype.h
@@ -403,6 +403,24 @@ extern "C" {
  */
 #define RTE_PTYPE_INNER_L2_ETHER_VLAN   0x0002
 /**
+ * QinQ packet type.
+ *
+ * Packet format:
+ * <'ether type'=[0x88A8]>
+ */
+#define RTE_PTYPE_INNER_L2_ETHER_QINQ   0x0003
+/**
+ * MPLS packet type.
+ *
+ * Packet format:
+ * <'ether type'=[0x8847|0x0x8848]>
+ */
+#define RTE_PTYPE_INNER_L2_ETHER_MPLS   0x0004
+/**
+ * Mask of layer 2 packet types.
+ * It is used for outer packet for tunneling cases.
+ */
+/**
  * Mask of inner layer 2 packet types.
  */
 #define RTE_PTYPE_INNER_L2_MASK 0x000f
@@ -597,7 +615,7 @@ struct rte_mbuf_hdr_lens {
  *   L2: Ether, Vlan, QinQ, Mpls
  *   L3: IPv4, IPv6
  *   L4: TCP, UDP, SCTP
- *   Tunnels: IPv4, IPv6, Gre
+ *   Tunnels: IPv4, IPv6, Gre, Nvgre
  *
  * @param m
  *   The packet mbuf to be parsed.
-- 
2.8.1



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

2016-07-05 Thread Olivier Matz
Add support of Gre tunnels in rte_pktmbuf_get_ptype().

Signed-off-by: Jean Dao 
Signed-off-by: Olivier Matz 
---
 lib/librte_mbuf/rte_mbuf_ptype.c | 40 
 lib/librte_mbuf/rte_mbuf_ptype.h |  2 +-
 2 files changed, 37 insertions(+), 5 deletions(-)

diff --git a/lib/librte_mbuf/rte_mbuf_ptype.c b/lib/librte_mbuf/rte_mbuf_ptype.c
index 1fddbc3..f681a42 100644
--- a/lib/librte_mbuf/rte_mbuf_ptype.c
+++ b/lib/librte_mbuf/rte_mbuf_ptype.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 

 /* get l3 packet type from ip6 next protocol */
 static uint32_t
@@ -150,11 +151,40 @@ ptype_inner_l4(uint8_t proto)
return ptype_inner_l4_proto[proto];
 }

-/* get the tunnel packet type if any, update proto. */
+/* get the tunnel packet type if any, update proto and off. */
 static uint32_t
-ptype_tunnel(uint16_t *proto)
+ptype_tunnel(uint16_t *proto, const struct rte_mbuf *m,
+   uint32_t *off)
 {
switch (*proto) {
+   case IPPROTO_GRE: {
+   static const uint8_t opt_len[16] = {
+   [0x0] = 4,
+   [0x1] = 8,
+   [0x2] = 8,
+   [0x8] = 8,
+   [0x3] = 12,
+   [0x9] = 12,
+   [0xa] = 12,
+   [0xb] = 16,
+   };
+   const struct gre_hdr *gh;
+   struct gre_hdr gh_copy;
+   uint16_t flags;
+
+   gh = rte_pktmbuf_read(m, *off, sizeof(*gh), &gh_copy);
+   if (unlikely(gh == NULL))
+   return 0;
+
+   flags = rte_be_to_cpu_16(*(const uint16_t *)gh);
+   flags >>= 12;
+   if (opt_len[flags] == 0)
+   return 0;
+
+   *off += opt_len[flags];
+   *proto = gh->proto;
+   return RTE_PTYPE_TUNNEL_GRE;
+   }
case IPPROTO_IPIP:
*proto = rte_cpu_to_be_16(ETHER_TYPE_IPv4);
return RTE_PTYPE_TUNNEL_IP;
@@ -352,9 +382,11 @@ uint32_t rte_pktmbuf_get_ptype(const struct rte_mbuf *m,
hdr_lens->l4_len = sizeof(struct sctp_hdr);
return pkt_type;
} else {
+   uint32_t prev_off = off;
+
hdr_lens->l4_len = 0;
-   pkt_type |= ptype_tunnel(&proto);
-   hdr_lens->tunnel_len = 0;
+   pkt_type |= ptype_tunnel(&proto, m, &off);
+   hdr_lens->tunnel_len = off - prev_off;
}

/* same job for inner header: we need to duplicate the code
diff --git a/lib/librte_mbuf/rte_mbuf_ptype.h b/lib/librte_mbuf/rte_mbuf_ptype.h
index 87749b0..d037504 100644
--- a/lib/librte_mbuf/rte_mbuf_ptype.h
+++ b/lib/librte_mbuf/rte_mbuf_ptype.h
@@ -597,7 +597,7 @@ struct rte_mbuf_hdr_lens {
  *   L2: Ether, Vlan, QinQ, Mpls
  *   L3: IPv4, IPv6
  *   L4: TCP, UDP, SCTP
- *   Tunnels: IPv4, IPv6
+ *   Tunnels: IPv4, IPv6, Gre
  *
  * @param m
  *   The packet mbuf to be parsed.
-- 
2.8.1



[dpdk-dev] [PATCH 11/18] net: add Gre header structure

2016-07-05 Thread Olivier Matz
Add the Gre header structure in librte_net. It will be used by next
patches that adds the support of Gre tunnels in the software packet type
parser.

The extended headers (checksum, key or sequence number) are not defined.

Signed-off-by: Jean Dao 
Signed-off-by: Olivier Matz 
---
 lib/librte_net/Makefile  |  2 +-
 lib/librte_net/rte_gre.h | 71 
 2 files changed, 72 insertions(+), 1 deletion(-)
 create mode 100644 lib/librte_net/rte_gre.h

diff --git a/lib/librte_net/Makefile b/lib/librte_net/Makefile
index af57f40..ffbef58 100644
--- a/lib/librte_net/Makefile
+++ b/lib/librte_net/Makefile
@@ -36,7 +36,7 @@ CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3
 # install includes
 SYMLINK-$(CONFIG_RTE_LIBRTE_NET)-include := rte_ip.h rte_tcp.h rte_udp.h
 SYMLINK-$(CONFIG_RTE_LIBRTE_NET)-include += rte_sctp.h rte_icmp.h rte_arp.h
-SYMLINK-$(CONFIG_RTE_LIBRTE_NET)-include += rte_ether.h rte_mpls.h
+SYMLINK-$(CONFIG_RTE_LIBRTE_NET)-include += rte_ether.h rte_mpls.h rte_gre.h


 include $(RTE_SDK)/mk/rte.install.mk
diff --git a/lib/librte_net/rte_gre.h b/lib/librte_net/rte_gre.h
new file mode 100644
index 000..46568ff
--- /dev/null
+++ b/lib/librte_net/rte_gre.h
@@ -0,0 +1,71 @@
+/*-
+ *   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 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.
+ */
+
+#ifndef _RTE_GRE_H_
+#define _RTE_GRE_H_
+
+#include 
+#include 
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/**
+ * GRE Header
+ */
+struct gre_hdr {
+#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
+   uint16_t res2:4; /**< Reserved */
+   uint16_t s:1;/**< Sequence Number Present bit */
+   uint16_t k:1;/**< Key Present bit */
+   uint16_t res1:1; /**< Reserved */
+   uint16_t c:1;/**< Checksum Present bit */
+   uint16_t ver:3;  /**< Version Number */
+   uint16_t res3:5; /**< Reserved */
+#elif RTE_BYTE_ORDER == RTE_BIG_ENDIAN
+   uint16_t c:1;/**< Checksum Present bit */
+   uint16_t res1:1; /**< Reserved */
+   uint16_t k:1;/**< Key Present bit */
+   uint16_t s:1;/**< Sequence Number Present bit */
+   uint16_t res2:4; /**< Reserved */
+   uint16_t res3:5; /**< Reserved */
+   uint16_t ver:3;  /**< Version Number */
+#endif
+   uint16_t proto;  /**< Protocol Type */
+} __attribute__((__packed__));
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* RTE_GRE_H_ */
-- 
2.8.1



[dpdk-dev] [PATCH 10/18] mbuf: support Ip tunnels in software packet type parser

2016-07-05 Thread Olivier Matz
Add support of IP and IP6 tunnels in rte_pktmbuf_get_ptype().

We need to duplicate some code because the packet types do not have the
same value for a given protocol between inner and outer.

Signed-off-by: Jean Dao 
Signed-off-by: Olivier Matz 
---
 lib/librte_mbuf/rte_mbuf_ptype.c | 158 ++-
 lib/librte_mbuf/rte_mbuf_ptype.h |   1 +
 2 files changed, 156 insertions(+), 3 deletions(-)

diff --git a/lib/librte_mbuf/rte_mbuf_ptype.c b/lib/librte_mbuf/rte_mbuf_ptype.c
index 0dea600..1fddbc3 100644
--- a/lib/librte_mbuf/rte_mbuf_ptype.c
+++ b/lib/librte_mbuf/rte_mbuf_ptype.c
@@ -93,6 +93,79 @@ ptype_l4(uint8_t proto)
return ptype_l4_proto[proto];
 }

+/* get inner l3 packet type from ip6 next protocol */
+static uint32_t
+ptype_inner_l3_ip6(uint8_t ip6_proto)
+{
+   static const uint32_t ptype_inner_ip6_ext_proto_map[256] = {
+   [IPPROTO_HOPOPTS] = RTE_PTYPE_INNER_L3_IPV6_EXT -
+   RTE_PTYPE_INNER_L3_IPV6,
+   [IPPROTO_ROUTING] = RTE_PTYPE_INNER_L3_IPV6_EXT -
+   RTE_PTYPE_INNER_L3_IPV6,
+   [IPPROTO_FRAGMENT] = RTE_PTYPE_INNER_L3_IPV6_EXT -
+   RTE_PTYPE_INNER_L3_IPV6,
+   [IPPROTO_ESP] = RTE_PTYPE_INNER_L3_IPV6_EXT -
+   RTE_PTYPE_INNER_L3_IPV6,
+   [IPPROTO_AH] = RTE_PTYPE_INNER_L3_IPV6_EXT -
+   RTE_PTYPE_INNER_L3_IPV6,
+   [IPPROTO_DSTOPTS] = RTE_PTYPE_INNER_L3_IPV6_EXT -
+   RTE_PTYPE_INNER_L3_IPV6,
+   };
+
+   return RTE_PTYPE_INNER_L3_IPV6 +
+   ptype_inner_ip6_ext_proto_map[ip6_proto];
+}
+
+/* get inner l3 packet type from ip version and header length */
+static uint32_t
+ptype_inner_l3_ip(uint8_t ipv_ihl)
+{
+   static const uint32_t ptype_inner_l3_ip_proto_map[256] = {
+   [0x45] = RTE_PTYPE_INNER_L3_IPV4,
+   [0x46] = RTE_PTYPE_INNER_L3_IPV4_EXT,
+   [0x47] = RTE_PTYPE_INNER_L3_IPV4_EXT,
+   [0x48] = RTE_PTYPE_INNER_L3_IPV4_EXT,
+   [0x49] = RTE_PTYPE_INNER_L3_IPV4_EXT,
+   [0x4A] = RTE_PTYPE_INNER_L3_IPV4_EXT,
+   [0x4B] = RTE_PTYPE_INNER_L3_IPV4_EXT,
+   [0x4C] = RTE_PTYPE_INNER_L3_IPV4_EXT,
+   [0x4D] = RTE_PTYPE_INNER_L3_IPV4_EXT,
+   [0x4E] = RTE_PTYPE_INNER_L3_IPV4_EXT,
+   [0x4F] = RTE_PTYPE_INNER_L3_IPV4_EXT,
+   };
+
+   return ptype_inner_l3_ip_proto_map[ipv_ihl];
+}
+
+/* get inner l4 packet type from proto */
+static uint32_t
+ptype_inner_l4(uint8_t proto)
+{
+   static const uint32_t ptype_inner_l4_proto[256] = {
+   [IPPROTO_UDP] = RTE_PTYPE_INNER_L4_UDP,
+   [IPPROTO_TCP] = RTE_PTYPE_INNER_L4_TCP,
+   [IPPROTO_SCTP] = RTE_PTYPE_INNER_L4_SCTP,
+   };
+
+   return ptype_inner_l4_proto[proto];
+}
+
+/* get the tunnel packet type if any, update proto. */
+static uint32_t
+ptype_tunnel(uint16_t *proto)
+{
+   switch (*proto) {
+   case IPPROTO_IPIP:
+   *proto = rte_cpu_to_be_16(ETHER_TYPE_IPv4);
+   return RTE_PTYPE_TUNNEL_IP;
+   case IPPROTO_IPV6:
+   *proto = rte_cpu_to_be_16(ETHER_TYPE_IPv6);
+   return RTE_PTYPE_TUNNEL_IP; /* IP is also valid for IPv6 */
+   default:
+   return 0;
+   }
+}
+
 /* get the ipv4 header length */
 static uint8_t
 ip4_hlen(const struct ipv4_hdr *hdr)
@@ -227,9 +300,8 @@ uint32_t rte_pktmbuf_get_ptype(const struct rte_mbuf *m,
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)) {
+   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;
@@ -265,6 +337,7 @@ uint32_t rte_pktmbuf_get_ptype(const struct rte_mbuf *m,

if ((pkt_type & RTE_PTYPE_L4_MASK) == RTE_PTYPE_L4_UDP) {
hdr_lens->l4_len = sizeof(struct udp_hdr);
+   return pkt_type;
} else if ((pkt_type & RTE_PTYPE_L4_MASK) == RTE_PTYPE_L4_TCP) {
const struct tcp_hdr *th;
struct tcp_hdr th_copy;
@@ -274,10 +347,89 @@ uint32_t rte_pktmbuf_get_ptype(const struct rte_mbuf *m,
return pkt_type & (RTE_PTYPE_L2_MASK |
RTE_PTYPE_L3_MASK);
hdr_lens->l4_len = (th->data_off & 0xf0) >> 2;
+   return pkt_type;
} else if ((pkt_type & RTE_PTYPE_L4_MASK) == RTE_PTYPE_L4_SCTP) {
hdr_lens->l4_len = sizeof(struct sctp_hdr);
+  

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

2016-07-05 Thread Olivier Matz
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), &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));
+   return pkt_type;
}

+ l3:
if (proto == rte_cpu_to_be_16(ETHER_TYPE_IPv4)) {
const struct ipv4_hdr *ip4h;
struct ipv4_hdr ip4h_copy;
diff --git a/lib/librte_mbuf/rte_mbuf_ptype.h b/lib/librte_mbuf/rte_mbuf_ptype.h
index e2e92d0..adc4c03 100644
--- a/lib/librte_mbuf/rte_mbuf_ptype.h
+++ b/lib/librte_mbuf/rte_mbuf_ptype.h
@@ -150,6 +150,13 @@ extern "C" {
  */
 #define RTE_PTYPE_L2_ETHER_QINQ 0x0007
 /**
+ * MPLS packet type.
+ *
+ * Packet format:
+ * <'ether type'=[0x8847|0x0x8848]>
+ */
+#define RTE_PTYPE_L2_ETHER_MPLS 0x0008
+/**
  * Mask of layer 2 packet types.
  * It is used for outer packet for tunneling cases.
  */
@@ -587,7 +594,7 @@ struct rte_mbuf_hdr_lens {
  * (retval & RTE_PTYPE_L2_MASK) != RTE_PTYPE_UNKNOWN.
  *
  * Supported packet types are:
- *   L2: Ether, Vlan, QinQ
+ *   L2: Ether, Vlan, QinQ, Mpls
  *   L3: IPv4, IPv6
  *   L4: TCP, UDP, SCTP
  *
diff --git a/lib/librte_net/Makefile b/lib/librte_net/Makefile
index fc332ff..af57f40 100644
--- a/lib/librte_net/Makefile
+++ b/lib/librte_net/Makefile
@@ -34,7 +34,9 @@ include $(RTE_SDK)/mk/rte.vars.mk
 CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3

 # install includes
-SYMLINK-$(CONFIG_RTE_LIBRTE_NET)-include := rte_ip.h rte_tcp.h rte_udp.h 
rte_sctp.h rte_icmp.h rte_arp.h rte_ether.h
+SYMLINK-$(CONFIG_RTE_LIBRTE_NET)-include := rte_ip.h rte_tcp.h rte_udp.h
+SYMLINK-$(CONFIG_RTE_LIBRTE_NET)-include += rte_sctp.h rte_icmp.h rte_arp.h
+SYMLINK-$(CONFIG_RTE_LIBRTE_NET)-include += rte_ether.h rte_mpls.h


 include $(RTE_SDK)/mk/rte.install.mk
diff --git a/lib/librte_net/rte_ether.h b/lib/librte_net/rte_ether.h
index ff3d065..254cb2d 100644
--- a/lib/librte_net/rte_ether.h
+++ b/lib/librte_net/rte_ether.h
@@ -333,6 +333,8 @@ struct vxlan_hdr {
 #define ETHER_TYPE_1588 0x88F7 /**< IEEE 802.1AS 1588 Precise Time Protocol. */
 #define ETHER_TYPE_SLOW 0x8809 /**< Slow protocols (LACP and Marker). */
 #define ETHER_TYPE_TEB  0x6558 /**< Transparent Ethernet Bridging. */
+#define ETHER_TYPE_MPLS 0x8847 /**< MPLS ethertype. */
+#define ETHER_TYPE_MPLSM 0x8848 /**< MPLS multicast ethertype. */

 #define ETHER_VXLAN_HLEN (sizeof(struct udp_hdr) + sizeof(struct vxlan_hdr))
 /**< VXLAN tunnel header length. */
-- 
2.8.1



[dpdk-dev] [PATCH 08/18] net: add Mpls header structure

2016-07-05 Thread Olivier Matz
Add the Mpls header structure in librte_net. It will be used by next
patches that adds the support of Mpls L2 layer in the software packet
type parser.

Signed-off-by: Olivier Matz 
---
 lib/librte_net/rte_mpls.h | 64 +++
 1 file changed, 64 insertions(+)
 create mode 100644 lib/librte_net/rte_mpls.h

diff --git a/lib/librte_net/rte_mpls.h b/lib/librte_net/rte_mpls.h
new file mode 100644
index 000..bf8c6cc
--- /dev/null
+++ b/lib/librte_net/rte_mpls.h
@@ -0,0 +1,64 @@
+/*-
+ *   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 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.
+ */
+
+#ifndef _RTE_MPLS_H_
+#define _RTE_MPLS_H_
+
+#include 
+#include 
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/**
+ * MPLS Header
+ */
+struct mpls_hdr {
+   uint16_t tag_msb;   /**< Label(msb). */
+#if RTE_BYTE_ORDER == RTE_BIG_ENDIAN
+   uint8_t tag_lsb:4;  /**< Label(lsb). */
+   uint8_t tc:3;   /**< Traffic class. */
+   uint8_t bs:1;   /**< Bottom of stack. */
+#else
+   uint8_t bs:1;   /**< Bottom of stack. */
+   uint8_t tc:3;   /**< Traffic class. */
+   uint8_t tag_lsb:4;  /**< label(lsb) */
+#endif
+   uint8_t  ttl;   /**< Time to live. */
+} __attribute__((__packed__));
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* RTE_MPLS_H_ */
-- 
2.8.1



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

2016-07-05 Thread Olivier Matz
Add a new RTE_PTYPE_L2_ETHER_QINQ 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 | 12 
 lib/librte_mbuf/rte_mbuf_ptype.h |  9 -
 lib/librte_net/rte_ether.h   |  1 +
 3 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/lib/librte_mbuf/rte_mbuf_ptype.c b/lib/librte_mbuf/rte_mbuf_ptype.c
index 6bbb255..5d46608 100644
--- a/lib/librte_mbuf/rte_mbuf_ptype.c
+++ b/lib/librte_mbuf/rte_mbuf_ptype.c
@@ -177,6 +177,18 @@ uint32_t rte_pktmbuf_get_ptype(const struct rte_mbuf *m,
off += sizeof(*vh);
hdr_lens->l2_len += sizeof(*vh);
proto = vh->eth_proto;
+   } else if (proto == rte_cpu_to_be_16(ETHER_TYPE_QINQ)) {
+   const struct vlan_hdr *vh;
+   struct vlan_hdr vh_copy;
+
+   pkt_type = RTE_PTYPE_L2_ETHER_QINQ;
+   vh = rte_pktmbuf_read(m, off + sizeof(*vh), sizeof(*vh),
+   &vh_copy);
+   if (unlikely(vh == NULL))
+   return pkt_type;
+   off += 2 * sizeof(*vh);
+   hdr_lens->l2_len += 2 * sizeof(*vh);
+   proto = vh->eth_proto;
}

if (proto == rte_cpu_to_be_16(ETHER_TYPE_IPv4)) {
diff --git a/lib/librte_mbuf/rte_mbuf_ptype.h b/lib/librte_mbuf/rte_mbuf_ptype.h
index 5f1325c..e2e92d0 100644
--- a/lib/librte_mbuf/rte_mbuf_ptype.h
+++ b/lib/librte_mbuf/rte_mbuf_ptype.h
@@ -143,6 +143,13 @@ extern "C" {
  */
 #define RTE_PTYPE_L2_ETHER_VLAN 0x0006
 /**
+ * QinQ packet type.
+ *
+ * Packet format:
+ * <'ether type'=[0x88A8]>
+ */
+#define RTE_PTYPE_L2_ETHER_QINQ 0x0007
+/**
  * Mask of layer 2 packet types.
  * It is used for outer packet for tunneling cases.
  */
@@ -580,7 +587,7 @@ struct rte_mbuf_hdr_lens {
  * (retval & RTE_PTYPE_L2_MASK) != RTE_PTYPE_UNKNOWN.
  *
  * Supported packet types are:
- *   L2: Ether, Vlan
+ *   L2: Ether, Vlan, QinQ
  *   L3: IPv4, IPv6
  *   L4: TCP, UDP, SCTP
  *
diff --git a/lib/librte_net/rte_ether.h b/lib/librte_net/rte_ether.h
index 647e6c9..ff3d065 100644
--- a/lib/librte_net/rte_ether.h
+++ b/lib/librte_net/rte_ether.h
@@ -329,6 +329,7 @@ struct vxlan_hdr {
 #define ETHER_TYPE_ARP  0x0806 /**< Arp Protocol. */
 #define ETHER_TYPE_RARP 0x8035 /**< Reverse Arp Protocol. */
 #define ETHER_TYPE_VLAN 0x8100 /**< IEEE 802.1Q VLAN tagging. */
+#define ETHER_TYPE_QINQ 0x88A8 /**< IEEE 802.1ad QinQ tagging. */
 #define ETHER_TYPE_1588 0x88F7 /**< IEEE 802.1AS 1588 Precise Time Protocol. */
 #define ETHER_TYPE_SLOW 0x8809 /**< Slow protocols (LACP and Marker). */
 #define ETHER_TYPE_TEB  0x6558 /**< Transparent Ethernet Bridging. */
-- 
2.8.1



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

2016-07-05 Thread Olivier Matz
Add a new RTE_PTYPE_L2_ETHER_VLAN 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 | 13 +
 lib/librte_mbuf/rte_mbuf_ptype.h |  9 -
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/lib/librte_mbuf/rte_mbuf_ptype.c b/lib/librte_mbuf/rte_mbuf_ptype.c
index 73284ae..6bbb255 100644
--- a/lib/librte_mbuf/rte_mbuf_ptype.c
+++ b/lib/librte_mbuf/rte_mbuf_ptype.c
@@ -166,6 +166,19 @@ 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_VLAN)) {
+   const struct vlan_hdr *vh;
+   struct vlan_hdr vh_copy;
+
+   pkt_type = RTE_PTYPE_L2_ETHER_VLAN;
+   vh = rte_pktmbuf_read(m, off, sizeof(*vh), &vh_copy);
+   if (unlikely(vh == NULL))
+   return pkt_type;
+   off += sizeof(*vh);
+   hdr_lens->l2_len += sizeof(*vh);
+   proto = vh->eth_proto;
+   }
+
if (proto == rte_cpu_to_be_16(ETHER_TYPE_IPv4)) {
const struct ipv4_hdr *ip4h;
struct ipv4_hdr ip4h_copy;
diff --git a/lib/librte_mbuf/rte_mbuf_ptype.h b/lib/librte_mbuf/rte_mbuf_ptype.h
index f468520..5f1325c 100644
--- a/lib/librte_mbuf/rte_mbuf_ptype.h
+++ b/lib/librte_mbuf/rte_mbuf_ptype.h
@@ -136,6 +136,13 @@ extern "C" {
  */
 #define RTE_PTYPE_L2_ETHER_NSH  0x0005
 /**
+ * VLAN packet type.
+ *
+ * Packet format:
+ * <'ether type'=[0x8100]>
+ */
+#define RTE_PTYPE_L2_ETHER_VLAN 0x0006
+/**
  * Mask of layer 2 packet types.
  * It is used for outer packet for tunneling cases.
  */
@@ -573,7 +580,7 @@ struct rte_mbuf_hdr_lens {
  * (retval & RTE_PTYPE_L2_MASK) != RTE_PTYPE_UNKNOWN.
  *
  * Supported packet types are:
- *   L2: Ether
+ *   L2: Ether, Vlan
  *   L3: IPv4, IPv6
  *   L4: TCP, UDP, SCTP
  *
-- 
2.8.1



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

2016-07-05 Thread Olivier Matz
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

diff --git a/doc/guides/rel_notes/release_16_11.rst 
b/doc/guides/rel_notes/release_16_11.rst
index 9b4d533..0ef8a87 100644
--- a/doc/guides/rel_notes/release_16_11.rst
+++ b/doc/guides/rel_notes/release_16_11.rst
@@ -39,6 +39,11 @@ New Features
   Added a new function ``rte_pktmbuf_read()`` to read the packet data from an
   mbuf chain, linearizing if required.

+* **Added a function to get the packet type from packet data.**
+
+  Added a new function ``rte_pktmbuf_get_ptype()`` to parse an Ethernet packet
+  in an mbuf chain and retrieve its packet type by software.
+
 Resolved Issues
 ---

diff --git a/lib/librte_mbuf/Makefile b/lib/librte_mbuf/Makefile
index 27e037c..15bbc78 100644
--- a/lib/librte_mbuf/Makefile
+++ b/lib/librte_mbuf/Makefile
@@ -41,12 +41,13 @@ EXPORT_MAP := rte_mbuf_version.map
 LIBABIVER := 2

 # all source are stored in SRCS-y
-SRCS-$(CONFIG_RTE_LIBRTE_MBUF) := rte_mbuf.c
+SRCS-$(CONFIG_RTE_LIBRTE_MBUF) := rte_mbuf.c rte_mbuf_ptype.c

 # install includes
 SYMLINK-$(CONFIG_RTE_LIBRTE_MBUF)-include := rte_mbuf.h rte_mbuf_ptype.h

 # this lib needs eal
-DEPDIRS-$(CONFIG_RTE_LIBRTE_MBUF) += lib/librte_eal lib/librte_mempool
+DEPDIRS-$(CONFIG_RTE_LIBRTE_MBUF) += lib/librte_eal lib/librte_mempool \
+ lib/librte_net

 include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_mbuf/rte_mbuf_ptype.c b/lib/librte_mbuf/rte_mbuf_ptype.c
new file mode 100644
index 000..73284ae
--- /dev/null
+++ b/lib/librte_mbuf/rte_mbuf_ptype.c
@@ -0,0 +1,234 @@
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright 2016 6WIND S.A.
+ *   All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   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.
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* get l3 packet type from ip6 next protocol */
+static uint32_t
+ptype_l3_ip6(uint8_t ip6_proto)
+{
+   static const uint32_t ip6_ext_proto_map[256] = {
+   [IPPROTO_HOPOPTS] = RTE_PTYPE_L3_IPV6_EXT - RTE_PTYPE_L3_IPV6,
+   [IPPROTO_ROUTING] = RTE_PTYPE_L3_IPV6_EXT - RTE_PTYPE_L3_IPV6,
+   [IPPROTO_FRAGMENT] = RTE_PTYPE_L3_IPV6_EXT - RTE_PTYPE_L3_IPV6,
+   [IPPROTO_ESP] = RTE_PTYPE_L3_IPV6_EXT - RTE_PTYPE_L3_IPV6,
+

[dpdk-dev] [PATCH 04/18] mbuf: move packet type definitions in a new file

2016-07-05 Thread Olivier Matz
The file rte_mbuf.h starts to be quite big, and next commits
will introduce more functions related to packet types. Let's
move them in a new file.

Signed-off-by: Olivier Matz 
---
 lib/librte_mbuf/Makefile |   2 +-
 lib/librte_mbuf/rte_mbuf.h   | 495 +--
 lib/librte_mbuf/rte_mbuf_ptype.h | 552 +++
 3 files changed, 554 insertions(+), 495 deletions(-)
 create mode 100644 lib/librte_mbuf/rte_mbuf_ptype.h

diff --git a/lib/librte_mbuf/Makefile b/lib/librte_mbuf/Makefile
index 8d62b0d..27e037c 100644
--- a/lib/librte_mbuf/Makefile
+++ b/lib/librte_mbuf/Makefile
@@ -44,7 +44,7 @@ LIBABIVER := 2
 SRCS-$(CONFIG_RTE_LIBRTE_MBUF) := rte_mbuf.c

 # install includes
-SYMLINK-$(CONFIG_RTE_LIBRTE_MBUF)-include := rte_mbuf.h
+SYMLINK-$(CONFIG_RTE_LIBRTE_MBUF)-include := rte_mbuf.h rte_mbuf_ptype.h

 # this lib needs eal
 DEPDIRS-$(CONFIG_RTE_LIBRTE_MBUF) += lib/librte_eal lib/librte_mempool
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index b76ee20..ad6f660 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -60,6 +60,7 @@
 #include 
 #include 
 #include 
+#include 

 #ifdef __cplusplus
 extern "C" {
@@ -225,500 +226,6 @@ extern "C" {
 /* Use final bit of flags to indicate a control mbuf */
 #define CTRL_MBUF_FLAG   (1ULL << 63) /**< Mbuf contains control data */

-/*
- * 32 bits are divided into several fields to mark packet types. Note that
- * each field is indexical.
- * - Bit 3:0 is for L2 types.
- * - Bit 7:4 is for L3 or outer L3 (for tunneling case) types.
- * - Bit 11:8 is for L4 or outer L4 (for tunneling case) types.
- * - Bit 15:12 is for tunnel types.
- * - Bit 19:16 is for inner L2 types.
- * - Bit 23:20 is for inner L3 types.
- * - Bit 27:24 is for inner L4 types.
- * - Bit 31:28 is reserved.
- *
- * To be compatible with Vector PMD, RTE_PTYPE_L3_IPV4, RTE_PTYPE_L3_IPV4_EXT,
- * RTE_PTYPE_L3_IPV6, RTE_PTYPE_L3_IPV6_EXT, RTE_PTYPE_L4_TCP, RTE_PTYPE_L4_UDP
- * and RTE_PTYPE_L4_SCTP should be kept as below in a contiguous 7 bits.
- *
- * Note that L3 types values are selected for checking IPV4/IPV6 header from
- * performance point of view. Reading annotations of RTE_ETH_IS_IPV4_HDR and
- * RTE_ETH_IS_IPV6_HDR is needed for any future changes of L3 type values.
- *
- * Note that the packet types of the same packet recognized by different
- * hardware may be different, as different hardware may have different
- * capability of packet type recognition.
- *
- * examples:
- * <'ether type'=0x0800
- * | 'version'=4, 'protocol'=0x29
- * | 'version'=6, 'next header'=0x3A
- * | 'ICMPv6 header'>
- * will be recognized on i40e hardware as packet type combination of,
- * RTE_PTYPE_L2_ETHER |
- * RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
- * RTE_PTYPE_TUNNEL_IP |
- * RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN |
- * RTE_PTYPE_INNER_L4_ICMP.
- *
- * <'ether type'=0x86DD
- * | 'version'=6, 'next header'=0x2F
- * | 'GRE header'
- * | 'version'=6, 'next header'=0x11
- * | 'UDP header'>
- * will be recognized on i40e hardware as packet type combination of,
- * RTE_PTYPE_L2_ETHER |
- * RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
- * RTE_PTYPE_TUNNEL_GRENAT |
- * RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN |
- * RTE_PTYPE_INNER_L4_UDP.
- */
-#define RTE_PTYPE_UNKNOWN   0x
-/**
- * Ethernet packet type.
- * It is used for outer packet for tunneling cases.
- *
- * Packet format:
- * <'ether type'=[0x0800|0x86DD]>
- */
-#define RTE_PTYPE_L2_ETHER  0x0001
-/**
- * Ethernet packet type for time sync.
- *
- * Packet format:
- * <'ether type'=0x88F7>
- */
-#define RTE_PTYPE_L2_ETHER_TIMESYNC 0x0002
-/**
- * ARP (Address Resolution Protocol) packet type.
- *
- * Packet format:
- * <'ether type'=0x0806>
- */
-#define RTE_PTYPE_L2_ETHER_ARP  0x0003
-/**
- * LLDP (Link Layer Discovery Protocol) packet type.
- *
- * Packet format:
- * <'ether type'=0x88CC>
- */
-#define RTE_PTYPE_L2_ETHER_LLDP 0x0004
-/**
- * NSH (Network Service Header) packet type.
- *
- * Packet format:
- * <'ether type'=0x894F>
- */
-#define RTE_PTYPE_L2_ETHER_NSH  0x0005
-/**
- * Mask of layer 2 packet types.
- * It is used for outer packet for tunneling cases.
- */
-#define RTE_PTYPE_L2_MASK   0x000f
-/**
- * IP (Internet Protocol) version 4 packet type.
- * It is used for outer packet for tunneling cases, and does not contain any
- * header option.
- *
- * Packet format:
- * <'ether type'=0x0800
- * | 'version'=4, 'ihl'=5>
- */
-#define RTE_PTYPE_L3_IPV4   0x0010
-/**
- * IP (Internet Protocol) version 4 packet type.
- * It is used for outer packet for tunneling cases, and contains header
- * options.
- *
- * Packet format:
- * <'ether type'=0x0800
- * | 'version'=4, 'ihl'=[6-15], 'options'>
- */
-#define RTE_PTYPE_L3_IPV4_EXT   0x0030
-/**
- * IP (Internet Protocol) version 6 packet type.
- * It is used for outer 

[dpdk-dev] [PATCH 03/18] net: move Ethernet header definitions to the net library

2016-07-05 Thread Olivier Matz
The proper place for rte_ether.h is in librte_net because it defines
network headers.

Moving it will also prevent to have circular references in the following
patches that will require the Ethernet header definition in rte_mbuf.c.
By the way, fix minor checkpatch issues.

Signed-off-by: Didier Pallard 
Signed-off-by: Olivier Matz 
---
 lib/librte_ether/Makefile|   3 +-
 lib/librte_ether/rte_ether.h | 416 ---
 lib/librte_net/Makefile  |   2 +-
 lib/librte_net/rte_ether.h   | 416 +++
 4 files changed, 418 insertions(+), 419 deletions(-)
 delete mode 100644 lib/librte_ether/rte_ether.h
 create mode 100644 lib/librte_net/rte_ether.h

diff --git a/lib/librte_ether/Makefile b/lib/librte_ether/Makefile
index 0bb5dc9..488b7c8 100644
--- a/lib/librte_ether/Makefile
+++ b/lib/librte_ether/Makefile
@@ -48,12 +48,11 @@ SRCS-y += rte_ethdev.c
 #
 # Export include files
 #
-SYMLINK-y-include += rte_ether.h
 SYMLINK-y-include += rte_ethdev.h
 SYMLINK-y-include += rte_eth_ctrl.h
 SYMLINK-y-include += rte_dev_info.h

 # this lib depends upon:
-DEPDIRS-y += lib/librte_eal lib/librte_mempool lib/librte_ring lib/librte_mbuf
+DEPDIRS-y += lib/librte_net lib/librte_eal lib/librte_mempool lib/librte_ring 
lib/librte_mbuf

 include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_ether/rte_ether.h b/lib/librte_ether/rte_ether.h
deleted file mode 100644
index 1d62d8e..000
--- a/lib/librte_ether/rte_ether.h
+++ /dev/null
@@ -1,416 +0,0 @@
-/*-
- *   BSD LICENSE
- *
- *   Copyright(c) 2010-2014 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.
- */
-
-#ifndef _RTE_ETHER_H_
-#define _RTE_ETHER_H_
-
-/**
- * @file
- *
- * Ethernet Helpers in RTE
- */
-
-#ifdef __cplusplus
-extern "C" {
-#endif
-
-#include 
-#include 
-
-#include 
-#include 
-#include 
-#include 
-
-#define ETHER_ADDR_LEN  6 /**< Length of Ethernet address. */
-#define ETHER_TYPE_LEN  2 /**< Length of Ethernet type field. */
-#define ETHER_CRC_LEN   4 /**< Length of Ethernet CRC. */
-#define ETHER_HDR_LEN   \
-   (ETHER_ADDR_LEN * 2 + ETHER_TYPE_LEN) /**< Length of Ethernet header. */
-#define ETHER_MIN_LEN   64/**< Minimum frame len, including CRC. */
-#define ETHER_MAX_LEN   1518  /**< Maximum frame len, including CRC. */
-#define ETHER_MTU   \
-   (ETHER_MAX_LEN - ETHER_HDR_LEN - ETHER_CRC_LEN) /**< Ethernet MTU. */
-
-#define ETHER_MAX_VLAN_FRAME_LEN \
-   (ETHER_MAX_LEN + 4) /**< Maximum VLAN frame length, including CRC. */
-
-#define ETHER_MAX_JUMBO_FRAME_LEN \
-   0x3F00 /**< Maximum Jumbo frame length, including CRC. */
-
-#define ETHER_MAX_VLAN_ID  4095 /**< Maximum VLAN ID. */
-
-#define ETHER_MIN_MTU 68 /**< Minimum MTU for IPv4 packets, see RFC 791. */
-
-/**
- * Ethernet address:
- * A universally administered address is uniquely assigned to a device by its
- * manufacturer. The first three octets (in transmission order) contain the
- * Organizationally Unique Identifier (OUI). The following three (MAC-48 and
- * EUI-48) octets are assigned by that organization with the only constraint
- * of uniqueness.
- * A locally administered address is assigned to a device by a network
- * administrator and does not contain OUIs.
- * See http://standards.ieee.org/regauth/groupmac/tutorial.html
- */
-struct ether_addr {
-   uint8_t addr_bytes[ETHER_ADDR_LEN]; /**< Ad

[dpdk-dev] [PATCH 02/18] mbuf: add function to read packet data

2016-07-05 Thread Olivier Matz
Introduce a new function to read the packet data from an mbuf chain. It
linearizes the data if required, and also ensures that the mbuf is large
enough.

This function is used in next commits that add a software parser to
retrieve the packet type.

Signed-off-by: Olivier Matz 
---
 doc/guides/rel_notes/release_16_11.rst |  4 
 lib/librte_mbuf/rte_mbuf.c | 36 ++
 lib/librte_mbuf/rte_mbuf.h | 35 +
 lib/librte_mbuf/rte_mbuf_version.map   |  7 +++
 4 files changed, 82 insertions(+)

diff --git a/doc/guides/rel_notes/release_16_11.rst 
b/doc/guides/rel_notes/release_16_11.rst
index 0106bc9..9b4d533 100644
--- a/doc/guides/rel_notes/release_16_11.rst
+++ b/doc/guides/rel_notes/release_16_11.rst
@@ -34,6 +34,10 @@ New Features

  Refer to the previous release notes for examples.

+* **Added function to read packet data.**
+
+  Added a new function ``rte_pktmbuf_read()`` to read the packet data from an
+  mbuf chain, linearizing if required.

 Resolved Issues
 ---
diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
index 601e528..a515ece 100644
--- a/lib/librte_mbuf/rte_mbuf.c
+++ b/lib/librte_mbuf/rte_mbuf.c
@@ -59,6 +59,7 @@
 #include 
 #include 
 #include 
+#include 

 /*
  * ctrlmbuf constructor, given as a callback function to
@@ -259,6 +260,41 @@ rte_pktmbuf_dump(FILE *f, const struct rte_mbuf *m, 
unsigned dump_len)
}
 }

+/* read len data bytes in a mbuf at specified offset (internal) */
+const void *__rte_pktmbuf_read(const struct rte_mbuf *m, uint32_t off,
+   uint32_t len, void *buf)
+{
+   const struct rte_mbuf *seg = m;
+   uint32_t buf_off = 0, copy_len;
+
+   if (off + len > rte_pktmbuf_pkt_len(m))
+   return NULL;
+
+   while (off >= rte_pktmbuf_data_len(seg) &&
+   rte_pktmbuf_data_len(seg) != 0) {
+   off -= rte_pktmbuf_data_len(seg);
+   seg = seg->next;
+   }
+
+   if (off + len <= rte_pktmbuf_data_len(seg))
+   return rte_pktmbuf_mtod_offset(seg, char *, off);
+
+   /* rare case: header is split among several segments */
+   while (len > 0) {
+   copy_len = rte_pktmbuf_data_len(seg) - off;
+   if (copy_len > len)
+   copy_len = len;
+   rte_memcpy((char *)buf + buf_off,
+   rte_pktmbuf_mtod_offset(seg, char *, off), copy_len);
+   off = 0;
+   buf_off += copy_len;
+   len -= copy_len;
+   seg = seg->next;
+   }
+
+   return buf;
+}
+
 /*
  * Get the name of a RX offload flag. Must be kept synchronized with flag
  * definitions in rte_mbuf.h.
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 101485f..b76ee20 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -1958,6 +1958,41 @@ static inline int rte_pktmbuf_is_contiguous(const struct 
rte_mbuf *m)
 }

 /**
+ * @internal used by rte_pktmbuf_read().
+ */
+const void *__rte_pktmbuf_read(const struct rte_mbuf *m, uint32_t off,
+   uint32_t len, void *buf);
+
+/**
+ * Read len data bytes in a mbuf at specified offset.
+ *
+ * If the data is contiguous, return the pointer in the mbuf data, else
+ * copy the data in the buffer provided by the user and return its
+ * pointer.
+ *
+ * @param m
+ *   The pointer to the mbuf.
+ * @param off
+ *   The offset of the data in the mbuf.
+ * @param len
+ *   The amount of bytes to read.
+ * @param buf
+ *   The buffer where data is copied if it is not contigous in mbuf
+ *   data. Its length should be at least equal to the len parameter.
+ * @return
+ *   The pointer to the data, either in the mbuf if it is contiguous,
+ *   or in the user buffer. If mbuf is too small, NULL is returned.
+ */
+static inline const void *rte_pktmbuf_read(const struct rte_mbuf *m,
+   uint32_t off, uint32_t len, void *buf)
+{
+   if (likely(off + len <= rte_pktmbuf_data_len(m)))
+   return rte_pktmbuf_mtod_offset(m, char *, off);
+   else
+   return __rte_pktmbuf_read(m, off, len, buf);
+}
+
+/**
  * Chain an mbuf to another, thereby creating a segmented packet.
  *
  * Note: The implementation will do a linear walk over the segments to find
diff --git a/lib/librte_mbuf/rte_mbuf_version.map 
b/lib/librte_mbuf/rte_mbuf_version.map
index e10f6bd..79e4dd8 100644
--- a/lib/librte_mbuf/rte_mbuf_version.map
+++ b/lib/librte_mbuf/rte_mbuf_version.map
@@ -18,3 +18,10 @@ DPDK_2.1 {
rte_pktmbuf_pool_create;

 } DPDK_2.0;
+
+DPDK_16.11 {
+   global:
+
+   __rte_pktmbuf_read;
+
+} DPDK_2.1;
-- 
2.8.1



[dpdk-dev] [PATCH 01/18] doc: add template for release notes 16.11

2016-07-05 Thread Olivier Matz
Signed-off-by: Olivier Matz 
---
 doc/guides/rel_notes/release_16_11.rst | 160 +
 1 file changed, 160 insertions(+)
 create mode 100644 doc/guides/rel_notes/release_16_11.rst

diff --git a/doc/guides/rel_notes/release_16_11.rst 
b/doc/guides/rel_notes/release_16_11.rst
new file mode 100644
index 000..0106bc9
--- /dev/null
+++ b/doc/guides/rel_notes/release_16_11.rst
@@ -0,0 +1,160 @@
+DPDK Release 16.11
+==
+
+.. **Read this first.**
+
+   The text below explains how to update the release notes.
+
+   Use proper spelling, capitalization and punctuation in all sections.
+
+   Variable and config names should be quoted as fixed width text: 
``LIKE_THIS``.
+
+   Build the docs and view the output file to ensure the changes are correct::
+
+  make doc-guides-html
+
+  firefox build/doc/html/guides/rel_notes/release_16_11.html
+
+
+New Features
+
+
+.. This section should contain new features added in this release. Sample 
format:
+
+   * **Add a title in the past tense with a full stop.**
+
+ Add a short 1-2 sentence description in the past tense. The description
+ should be enough to allow someone scanning the release notes to understand
+ the new feature.
+
+ If the feature adds a lot of sub-features you can use a bullet list like 
this.
+
+ * Added feature foo to do something.
+ * Enhanced feature bar to do something else.
+
+ Refer to the previous release notes for examples.
+
+
+Resolved Issues
+---
+
+.. This section should contain bug fixes added to the relevant sections. 
Sample format:
+
+   * **code/section Fixed issue in the past tense with a full stop.**
+
+ Add a short 1-2 sentence description of the resolved issue in the past 
tense.
+ The title should contain the code/lib section like a commit message.
+ Add the entries in alphabetic order in the relevant sections below.
+
+
+EAL
+~~~
+
+
+Drivers
+~~~
+
+
+Libraries
+~
+
+
+Examples
+
+
+
+Other
+~
+
+
+Known Issues
+
+
+.. This section should contain new known issues in this release. Sample format:
+
+   * **Add title in present tense with full stop.**
+
+ Add a short 1-2 sentence description of the known issue in the present
+ tense. Add information on any known workarounds.
+
+
+API Changes
+---
+
+.. This section should contain API changes. Sample format:
+
+   * Add a short 1-2 sentence description of the API change. Use fixed width
+ quotes for ``rte_function_names`` or ``rte_struct_names``. Use the past 
tense.
+
+
+ABI Changes
+---
+
+.. * Add a short 1-2 sentence description of the ABI change that was announced 
in
+ the previous releases and made in this release. Use fixed width quotes for
+ ``rte_function_names`` or ``rte_struct_names``. Use the past tense.
+
+
+Shared Library Versions
+---
+
+.. Update any library version updated in this release and prepend with a ``+`` 
sign.
+
+The libraries prepended with a plus sign were incremented in this version.
+
+.. code-block:: diff
+
+ libethdev.so.3
+ librte_acl.so.2
+ librte_cfgfile.so.2
+ librte_cmdline.so.2
+ librte_distributor.so.1
+ librte_eal.so.2
+ librte_hash.so.2
+ librte_ip_frag.so.1
+ librte_ivshmem.so.1
+ librte_jobstats.so.1
+ librte_kni.so.2
+ librte_kvargs.so.1
+ librte_lpm.so.2
+ librte_mbuf.so.2
+ librte_mempool.so.2
+ librte_meter.so.1
+ librte_pipeline.so.3
+ librte_pmd_bond.so.1
+ librte_pmd_ring.so.2
+ librte_port.so.2
+ librte_power.so.1
+ librte_reorder.so.1
+ librte_ring.so.1
+ librte_sched.so.1
+ librte_table.so.2
+ librte_timer.so.1
+ librte_vhost.so.2
+
+
+Tested Platforms
+
+
+.. This section should contain a list of platforms that were tested with this
+   release.
+
+   The format is:
+
+   #. Platform name.
+
+  - Platform details.
+  - Platform details.
+
+
+Tested NICs
+---
+
+.. This section should contain a list of NICs that were tested with this 
release.
+
+   The format is:
+
+   #. NIC name.
+
+  - NIC details.
+  - NIC details.
-- 
2.8.1



[dpdk-dev] [PATCH 00/18] software parser for packet type

2016-07-05 Thread Olivier Matz
This patchset introduces a software packet type parser. This
feature is targeted for v16.11.

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

It 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.

Olivier Matz (18):
  doc: add template for release notes 16.11
  mbuf: add function to read packet data
  net: move Ethernet header definitions to the net library
  mbuf: move packet type definitions in a new file
  mbuf: add function to get packet type from data
  mbuf: support Vlan in software packet type parser
  mbuf: support QinQ in software packet type parser
  net: add Mpls header structure
  mbuf: support Mpls in software packet type parser
  mbuf: support Ip tunnels in software packet type parser
  net: add Gre header structure
  mbuf: support Gre in software packet type parser
  mbuf: support Nvgre in software packet type parser
  mbuf: get ptype for the first layers only
  mbuf: add functions to dump packet type
  mbuf: clarify definition of fragment packet types
  app/testpmd: dump ptype using the new function
  app/testpmd: display sw packet type

 app/test-pmd/rxonly.c  | 195 ++---
 doc/guides/rel_notes/release_16_11.rst | 173 
 lib/librte_ether/Makefile  |   3 +-
 lib/librte_ether/rte_ether.h   | 416 ---
 lib/librte_mbuf/Makefile   |   7 +-
 lib/librte_mbuf/rte_mbuf.c |  36 ++
 lib/librte_mbuf/rte_mbuf.h | 530 ++--
 lib/librte_mbuf/rte_mbuf_ptype.c   | 735 +
 lib/librte_mbuf/rte_mbuf_ptype.h   | 735 +
 lib/librte_mbuf/rte_mbuf_version.map   |  16 +
 lib/librte_net/Makefile|   4 +-
 lib/librte_net/rte_ether.h | 419 +++
 lib/librte_net/rte_gre.h   |  71 
 lib/librte_net/rte_mpls.h  |  64 +++
 14 files changed, 2317 insertions(+), 1087 deletions(-)
 create mode 100644 doc/guides/rel_notes/release_16_11.rst
 delete mode 100644 lib/librte_ether/rte_ether.h
 create mode 100644 lib/librte_mbuf/rte_mbuf_ptype.c
 create mode 100644 lib/librte_mbuf/rte_mbuf_ptype.h
 create mode 100644 lib/librte_net/rte_ether.h
 create mode 100644 lib/librte_net/rte_gre.h
 create mode 100644 lib/librte_net/rte_mpls.h

Test report
===

Topology:

 dut
   +-+   
   | |   
   | ixgbe pmd   +---.
   | |   |
   | |   |
   | ixgbe linux +---'
   | |   
   +-+   

We will send packets with scapy from the kernel interface to
testpmd with rxonly engine, and check the logs to verify the
packet type.

# compile and run testpmd
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

# on another terminal, run scapy
scapy

eh = Ether(src="00:01:02:03:04:05", dst="00:1B:21:AB:8F:10")
vlan = Dot1Q(vlan=0x666)
eth = "ixgbe2"

class MPLS(Packet):
   name = "MPLS"
   fields_desc =  [ BitField("label", 3, 20),
 BitField("cos", 0, 3),
 BitField("bs", 1, 1),
 ByteField("ttl", 0)  ]

bind_layers(Ether, MPLS, type=0x8847)
bind_layers(GRE, IPv6, type=0x86dd)

v4/udp
==

# scapy
p = eh/IP()/UDP()/Raw("x"*32)
sendp(p, iface=eth)
p = eh/vlan/IP()/UDP()/Raw("x"*32)
sendp(p, iface=eth)
p = eh/vlan/vlan/IP()/UDP()/Raw("x"*32)
p.type=0x88A8 # QinQ
sendp(p, iface=eth)
p = eh/MPLS(bs=1)/IP()/UDP()/Raw("x"*32)
sendp(p, iface=eth)
p = eh/IP(options=IPOption('\x83\x03\x10'))/UDP()/Raw("x"*32)
sendp(p, iface=eth)

# displayed in testpmd
port 0/queue 0: received 1 packets
  src=00:01:02:03:04:05 - dst=00:1B:21:AB:8F:10 - type=0x0800 - length=74 - 
nb_segs=1 - hw ptype: L2_ETHER L3_IPV4 L4_UDP  - sw ptype: L2_ETHER L3_IPV4 
L4_UDP  - l2_len=14 - l3_len=20 - l4_len=8 - 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=0x8100 - length=78 - 
nb_segs=1 - hw ptype: L2_ETHER L3_IPV4 L4_UDP  - sw ptype: L2_ETHER_VLAN 
L3_IPV4 L4_UDP  - l2_len=18 - l3_len=20 - l4_len=8 - Receive queue=0x0
  PKT_RX_VLAN_PKT
port 0/queue 0: received 1 packets
  src=00:01:02:03:04:05 - dst=00:1B:21:AB:8F:10 - type=0x88a8 - length=82 - 
nb_segs=1 - hw ptype: L2_ETHER  - sw 

[dpdk-dev] [PATCH] scripts: fix commit check of first word

2016-07-05 Thread Bruce Richardson
On Tue, Jul 05, 2016 at 05:54:26PM +0200, Thomas Monjalon wrote:
> The first word of each commit message is checked.
> But when the commit range was greater than 1, only the latest commit
> was checked.
> It is fixed by checking each commit separately.
> 
> Fixes: 9c24780f0d5e ("scripts: check first word of commit messages")
> 
> Signed-off-by: Thomas Monjalon 
> ---

Tested-by: Bruce Richardson 
Acked-by: Bruce Richardson 


[dpdk-dev] [PATCH v3 6/6] ena: fix for icc compiler

2016-07-05 Thread Bruce Richardson
On Tue, Jul 05, 2016 at 09:52:09AM +0100, Ferruh Yigit wrote:
> On 6/30/2016 4:04 PM, Jan Medala wrote:
> > Signed-off-by: Alexander Matushevsky 
> > Signed-off-by: Jakub Palider 
> > Signed-off-by: Jan Medala 
> 
> The compilation error to fix is [1], it may be good to add what to fix
> into commit log.
> 
> [1]
> == Build drivers/net/ena
>   CC ena_ethdev.o
> /tmp/dpdk_maintain/ena_v3/dpdk/drivers/net/ena/ena_ethdev.c(943): error
> #188: enumerated type mixed with another type
> struct ena_com_create_io_ctx ctx = { 0 };
>  ^
> 
> /tmp/dpdk_maintain/ena_v3/dpdk/drivers/net/ena/ena_ethdev.c(1036): error
> #188: enumerated type mixed with another type
> struct ena_com_create_io_ctx ctx = { 0 };
>  ^
> ...
> 
> > --- a/drivers/net/ena/ena_ethdev.c
> > +++ b/drivers/net/ena/ena_ethdev.c
> > @@ -940,7 +940,10 @@ static int ena_tx_queue_setup(struct rte_eth_dev *dev,
> >   __rte_unused unsigned int socket_id,
> >   __rte_unused const struct rte_eth_txconf *tx_conf)
> >  {
> > -   struct ena_com_create_io_ctx ctx = { 0 };
> > +   struct ena_com_create_io_ctx ctx =
> > +   /* policy set to _HOST just to satisfy icc compiler */
> > +   { ENA_ADMIN_PLACEMENT_POLICY_HOST,
> > + ENA_COM_IO_QUEUE_DIRECTION_TX, 0, 0, 0, 0 };
> 
> Trailing "0" are not required, compiler will take care of them.
> 
Jan,

any comment on this? If you want, I can remove the trailing zeros on apply
rather than needing a V3. Is that ok?

Again a fixes line is missing, can you supply one.

/Bruce


[dpdk-dev] [PATCH v3 5/6] ena: fix memory management issue

2016-07-05 Thread Bruce Richardson
On Mon, Jul 04, 2016 at 05:27:50PM +0100, Bruce Richardson wrote:
> On Thu, Jun 30, 2016 at 05:04:58PM +0200, Jan Medala wrote:
> > After allocating memzone it's required to zeroize memory in it.
> > Freeing memzone with function dedicated for memoryzones.
> > 
> 
> Can you provide a fixes line for this patch?
> 

>From looking at git blame, it looks to be:
Fixes: 9ba7981ec992 ("ena: add communication layer for DPDK")

Please confirm that is ok.

/Bruce



[dpdk-dev] [PATCH v2] scripts: add additional git log capitalization checks

2016-07-05 Thread Bruce Richardson
Add API, NUMA, HW, SW, FW and VMDq to list of words to capitalize properly.
Since VMDq is a bit unusual, add it as special case check so we can
print an error message giving the correct way to write it.

Signed-off-by: Bruce Richadson 

---
v2: add NUMA to list
---
 scripts/check-git-log.sh | 9 +
 1 file changed, 9 insertions(+)

diff --git a/scripts/check-git-log.sh b/scripts/check-git-log.sh
index 7d2c7ee..0f2b4bc 100755
--- a/scripts/check-git-log.sh
+++ b/scripts/check-git-log.sh
@@ -89,11 +89,14 @@ bad=$(echo "$headlines" | grep --color=always \
 bad=$(echo "$headlines" | grep -E --color=always \
-e '\<(rx|tx|RX|TX)\>' \
-e '\<[pv]f\>' \
+   -e '\<[hsf]w\>' \
-e '\' \
+   -e ':.*\' \
-e ':.*\' \
-e ':.*\' \
-e ':.*\' \
-e ':.*\' \
+   -e ':.*\' \
-e ':.*\' \
-e ':.*\' \
-e ':.*\' \
@@ -106,6 +109,12 @@ bad=$(echo "$headlines" | grep -E --color=always \
| sed 's,^,\t,')
 [ -z "$bad" ] || printf "Wrong headline lowercase:\n$bad\n"

+# special case check for VMDq to give good error message
+bad=$(echo "$headlines" | grep -E --color=always \
+   -e '\<(vmdq|VMDQ)\>' \
+   | sed 's,^,\t,')
+[ -z "$bad" ] || printf "Wrong headline capitalization, use 'VMDq':\n$bad\n"
+
 # check headline length (60 max)
 bad=$(echo "$headlines" | awk 'length>60 {print}' | sed 's,^,\t,')
 [ -z "$bad" ] || printf "Headline too long:\n$bad\n"
-- 
2.5.5



[dpdk-dev] [PATCH v3 3/6] ena: disable readless communication regarding to HW revision

2016-07-05 Thread Bruce Richardson
On Tue, Jul 05, 2016 at 12:02:41PM +0200, Jan M?dala wrote:
> Bruce,
> 
> Here's explanation of readless communication (on behalf of Alex):
> 
> > "readless" refers to ability to read ENA registers without actually
> > issuing read request from host (x86).
> > Instead, host programs 2 registers on device that trigger DMA from device
> > to host and report register value.
> > However, this functionality is not going to be available in all type of
> > devices. The decision if this mode is supported or not , is taken from
> > revision_id in pci configuration space.
> 
> 

Thanks, I'll add this into the commit message to help explain things to anyone
looking at the commit later.

/Bruce

> Regards
> 
>   Jan
> 
> 2016-07-04 17:43 GMT+02:00 Bruce Richardson :
> 
> > On Thu, Jun 30, 2016 at 05:04:56PM +0200, Jan Medala wrote:
> > > Depending on HW revision readless communcation between host and device
> > > may be unavailable.
> > > In that case prevent PMD of seting up readless communication mechanism.
> > >
> > The idea of readless communication is a strange one. Can you provide a bit
> > more detail as to what "readless communication" refers to.
> >
> > /Bruce
> >


[dpdk-dev] [PATCH v9 0/7] export PMD infos

2016-07-05 Thread Neil Horman
On Mon, Jul 04, 2016 at 10:10:37PM +0200, Thomas Monjalon wrote:
> 2016-07-04 12:41, Neil Horman:
> > On Mon, Jul 04, 2016 at 03:10:14PM +0200, Thomas Monjalon wrote:
> > > Hi Neil,
> > > 
> > > I don't really understand why you don't accept I contribute to this
> > > patchset. More details below.
> > > 
> > I don't object to your contribution to this patchset.  What I object to is 
> > you
> > making changes contrary to what I just spent I don't even know how many 
> > weeks
> > arguing with you and others about.  Given your role as maintainer, it is
> > tantamout to a 'my way or the highway' position.
> 
> Thank you for explaining your feeling so clearly.
> I'm sorry for any inconvenience or misunderstanding.
> I now understand that you prefer I make some patches separately after
> integrating your version.
> So I can send a v10 based on your v8 which only fixes compilation.
> Or you can do it yourself if you prefer.
> Then I'll send another series for the other changes.
> Deal?
> 
You go ahead and do it, I'm done.
Neil



[dpdk-dev] [PATCH v4] igb_uio: fix possible mmap failure for Linux >= v4.5

2016-07-05 Thread Ferruh Yigit
mmap the iomem range of the PCI device fails for kernels that
enabled CONFIG_IO_STRICT_DEVMEM option:

EAL: pci_map_resource():
 cannot mmap(39, 0x7f1c5180, 0x10, 0x0):
 Invalid argument (0x)

CONFIG_IO_STRICT_DEVMEM is introduced in Linux v4.5 and not enabled
by default:
Linux commit: 90a545e restrict /dev/mem to idle io memory ranges

As a workaround igb_uio can stop reserving PCI memory resources, from
kernel point of view iomem region looks like idle and mmap works
again. This matches uio_pci_generic usage.

With this update device iomem range is not protected against any
other kernel drivers or userspace access. But this  shouldn't
be a problem for dpdk usage module since purpose of the igb_uio
module is to provide userspace access.

Fixes: af75078fece3 ("first public release")

Signed-off-by: Ferruh Yigit 

---
v4:
*  release notes, resolved issues section updated for this fix
---
 doc/guides/rel_notes/release_16_07.rst| 14 ++
 lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 13 -
 2 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/doc/guides/rel_notes/release_16_07.rst 
b/doc/guides/rel_notes/release_16_07.rst
index 569f562..1ddcdab 100644
--- a/doc/guides/rel_notes/release_16_07.rst
+++ b/doc/guides/rel_notes/release_16_07.rst
@@ -231,6 +231,20 @@ Examples
 Other
 ~

+* **igb_uio: Fixed possible mmap failure for Linux >= v4.5.**
+
+mmaping the iomem range of the PCI device fails for kernels that
+enabled CONFIG_IO_STRICT_DEVMEM option:
+
+EAL: pci_map_resource():
+ cannot mmap(39, 0x7f1c5180, 0x10, 0x0):
+ Invalid argument (0x)
+
+CONFIG_IO_STRICT_DEVMEM is introduced in Linux v4.5
+
+Updated igb_uio to stop reserving PCI memory resources, from
+kernel point of view iomem region looks like idle and mmap worked
+again. This matches uio_pci_generic usage.

 Known Issues
 
diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c 
b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
index 45a5720..df41e45 100644
--- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
+++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
@@ -342,16 +342,6 @@ igbuio_pci_probe(struct pci_dev *dev, const struct 
pci_device_id *id)
goto fail_free;
}

-   /*
-* reserve device's PCI memory regions for use by this
-* module
-*/
-   err = pci_request_regions(dev, "igb_uio");
-   if (err != 0) {
-   dev_err(&dev->dev, "Cannot request regions\n");
-   goto fail_disable;
-   }
-
/* enable bus mastering on the device */
pci_set_master(dev);

@@ -441,8 +431,6 @@ fail_release_iomem:
igbuio_pci_release_iomem(&udev->info);
if (udev->mode == RTE_INTR_MODE_MSIX)
pci_disable_msix(udev->pdev);
-   pci_release_regions(dev);
-fail_disable:
pci_disable_device(dev);
 fail_free:
kfree(udev);
@@ -460,7 +448,6 @@ igbuio_pci_remove(struct pci_dev *dev)
igbuio_pci_release_iomem(&udev->info);
if (udev->mode == RTE_INTR_MODE_MSIX)
pci_disable_msix(dev);
-   pci_release_regions(dev);
pci_disable_device(dev);
pci_set_drvdata(dev, NULL);
kfree(udev);
-- 
2.7.4



[dpdk-dev] [PATCH] scripts: add check for net driver names without net prefix

2016-07-05 Thread Bruce Richardson
Since the current standard for commit prefixes is to put the device type
e.g. "net", in front of the driver name, add a check for commit titles
which have a net driver name without any prefix in front of it.

Signed-off-by: Bruce Richardson 
---
 scripts/check-git-log.sh | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/scripts/check-git-log.sh b/scripts/check-git-log.sh
index 7d2c7ee..7dc1fd8 100755
--- a/scripts/check-git-log.sh
+++ b/scripts/check-git-log.sh
@@ -78,6 +78,12 @@ bad=$(echo "$headlines" | grep --color=always \
| sed 's,^,\t,')
 [ -z "$bad" ] || printf "Wrong headline label:\n$bad\n"

+# check headline label for net/ prefix if needed
+bad=$(echo "$headlines" | grep -E --color=always \
+   -e "^($(ls drivers/net | grep -v Makefile | tr '\n' '|')):" \
+   | sed 's,^,\t,')
+[ -z "$bad" ] || printf "Headline missing 'net/' prefix:\n$bad\n"
+
 # check headline lowercase for first words
 bad=$(echo "$headlines" | grep --color=always \
-e '^.*[A-Z].*:' \
-- 
2.5.5



[dpdk-dev] [PATCH] doc: announce API change for virtual device initialization

2016-07-05 Thread Thomas Monjalon
2016-07-05 14:04, Ferruh Yigit:
> On 7/4/2016 3:50 PM, Pablo de Lara wrote:
> > +* The rte_eal_vdev_init function will be changed in 16.11 to return
> > +  the port/device id of the device created, instead of 0, when it has been
> > +  initialized successfully, so user can use the returned value straight 
> > away
> > +  to call all the device functions that require that parameter.
> 
> There is another API rte_eth_dev_attach(), which returns port_id, and is
> a common wrapper both for pdev and vdev.
> So with proper devargs this API calls rte_eal_vdev_init() and returns
> port_id (set in argument) without any extra side effect.

I think rte_eth_dev_attach() should be removed from ethdev.
Hotplugging a device belongs to device management, i.e. EAL.


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

2016-07-05 Thread Bill Bonaparte
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).

I am not sure if this api works for the real interface.
who has more information about this, and why it does not work on virtual
machine ?

Appreciate any comments and reply.


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

2016-07-05 Thread Ferruh Yigit
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.

Thanks,
ferruh




[dpdk-dev] [PATCH] doc: announce API change for virtual device initialization

2016-07-05 Thread De Lara Guarch, Pablo


> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Tuesday, July 05, 2016 2:39 PM
> To: Yigit, Ferruh
> Cc: dev at dpdk.org; De Lara Guarch, Pablo; Mcnamara, John
> Subject: Re: [dpdk-dev] [PATCH] doc: announce API change for virtual device
> initialization
> 
> 2016-07-05 14:04, Ferruh Yigit:
> > On 7/4/2016 3:50 PM, Pablo de Lara wrote:
> > > +* The rte_eal_vdev_init function will be changed in 16.11 to return
> > > +  the port/device id of the device created, instead of 0, when it has 
> > > been
> > > +  initialized successfully, so user can use the returned value straight 
> > > away
> > > +  to call all the device functions that require that parameter.
> >
> > There is another API rte_eth_dev_attach(), which returns port_id, and is
> > a common wrapper both for pdev and vdev.
> > So with proper devargs this API calls rte_eal_vdev_init() and returns
> > port_id (set in argument) without any extra side effect.
> 
> I think rte_eth_dev_attach() should be removed from ethdev.
> Hotplugging a device belongs to device management, i.e. EAL.

Even though rte_eth_dev_attach returns the port id, I think that 
rte_eal_vdev_init
can return the port id anyway (and then, we can remove the call to 
rte_eth_dev_get_port_by_name
 in rte_eth_dev_attach). 


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

2016-07-05 Thread Adrien Mazarguil
On Tue, Jul 05, 2016 at 12:27:06PM +0100, Ferruh Yigit wrote:
> On 7/5/2016 11:44 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).
> 
> Out of curiosity, is there a specific standard version that is targeted?

Considering past discussions on more or less related topics (such as [1]), I
think we target at least C99 compliance for exported headers only. It can be
even better if we manage to have them comply with C90 but I think it is not
worth the effort, as all the compilers we support do understand C99. C11
support is not widespread enough yet.

Note that even after applying this series, exported headers are not really
C99 compliant. Extensions are only made clear through the use of
__extension__ keywords (and a few minor changes) that non-compliant
statements are perfectly normal and compilers should not worry about them
when compiling user applications with stricter flags than usual (-pedantic).

Remember that the rest of DPDK can use whatever internally without explicit
keywords as long as it works with the default set of options and all
supported compiler versions for targetted platforms. This series does not
change anything in this regard.

Also C++ compat is on currently only on a best effort basis. Works as long
as -pedantic is not specified, that is a task for later if we really want
full compliance.

In short:

- Exported headers: C99, C++11 (best effort)
- Internally: GNU C99/C11, no C++ (but I guess it would be C++11 considering
  the number of extensions we'd need otherwise).

[1] http://dpdk.org/ml/archives/dev/2015-November/027355.html

-- 
Adrien Mazarguil
6WIND


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

2016-07-05 Thread Thomas Monjalon
2016-07-05 12:27, Ferruh Yigit:
> On 7/5/2016 11:44 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).
> 
> Out of curiosity, is there a specific standard version that is targeted?

In the last patch (scripts/check-includes.sh), there is this:
+: ${PEDANTIC_CFLAGS=-std=c99 -pedantic -Wall -Wextra -Werror}
+: ${PEDANTIC_CXXFLAGS=}
+: ${PEDANTIC_CPPFLAGS=-D_XOPEN_SOURCE=600}

I guess it means that strict C99 is targeted and there is no standard
requirement for C++.


[dpdk-dev] [PATCH v2 3/3] i40e: fix out-of-bounds access

2016-07-05 Thread Bruce Richardson
On Tue, Jul 05, 2016 at 02:10:05PM +0800, Beilei Xing wrote:
> When calling i40e_flowtype_to_pctype in
> i40e_get_hash_filter_global_config and
> i40e_set_hash_filter_global_config, function
> i40e_flowtype_to_pctype will be possibly
> out-of-bounds accessed, because size of callee's array
> is 15. So judge flow type before calling
> i40e_flowtype_to_pctype.
> Meanwhile do the same change in other functions.
> 
> Coverity issue: 37793, 37794
> 
> Fixes: 782c8c92f13f ("i40e: add hash configuration")
> Fixes: f2b2e2354bbd ("i40e: split function for hash and flow director input")
> Fixes: 98f055707685 ("i40e: configure input fields for RSS or flow director")
> 
> Signed-off-by: Beilei Xing 
> ---
>  drivers/net/i40e/i40e_ethdev.c | 21 -
>  1 file changed, 12 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index a1cad37..111a552 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -6908,6 +6908,9 @@ i40e_get_hash_filter_global_config(struct i40e_hw *hw,
>   mask &= ~(1UL << i);
>   /* Bit set indicats the coresponding flow type is supported */
>   g_cfg->valid_bit_mask[0] |= (1UL << i);
> + /* if flowtype is invalid, continue */
> + if (!I40E_VALID_FLOW(i))
> + continue;
>   pctype = i40e_flowtype_to_pctype(i);
>   reg = i40e_read_rx_ctl(hw, I40E_GLQF_HSYM(pctype));
>   if (reg & I40E_GLQF_HSYM_SYMH_ENA_MASK)

Rather than having the same check done in multiple places, is there a reason
why we can't just put the check once in i40e_flowtype_to_pctype?

/Bruce


[dpdk-dev] [PATCH v2 2/3] i40e: fix dereference before null check

2016-07-05 Thread Bruce Richardson
On Tue, Jul 05, 2016 at 02:10:04PM +0800, Beilei Xing wrote:
> Null-checking vsi suggests that it may be null, but it
> has be dereferenced before null-checking. So move if
> statement to the front of assignment statement.
> 
> Coverity: 119265, 119266
> 
> Fixes: d0a349409bd7 ("i40e: support AQ based RSS config")
> Fixes: 647d1eaf758b ("i40evf: support AQ based RSS config")
> 
> Signed-off-by: Beilei Xing 

Acked-by: Bruce Richardson 



[dpdk-dev] [PATCH v2 1/3] i40e: fix log error

2016-07-05 Thread Bruce Richardson
On Tue, Jul 05, 2016 at 02:10:03PM +0800, Beilei Xing wrote:
> The condition, "(pf->flags | I40E_FLAG_VMDQ)" will always be true,
> regardless of the value of the flags operand, because I40E_FLAG_VMDQ
> is 4ULL - meaning at least one bit will always be set in the result.
> That will cause log error when VMDq is disabled.
> Since the original intent behind the condition is to check if VMDq
> is enabled, fix the code by changing "|" to "&".
> 
> Coverity issue: 13219, 13221
> 
> Fixes: 4805ed59e957 ("i40e: enhance mac address operations")
> 
> Signed-off-by: Beilei Xing 

Acked-by: Bruce Richardson 



[dpdk-dev] [PATCH] examples/tep_term: fix out-of-bounds access

2016-07-05 Thread Beilei Xing
Coverity reported lots of out-of-bounds in function
vxlan_link, these issues should happen when index
port_id evaluates to 2, cause size of arrays is
2 in structure.
Fix this issue by modifying judgement condition, make
sure port_id is less than 2.

Coverity issue: 107121, 107122, 107123, 107124, 107125

Fixes: 4abe471ed6fc ("examples/tep_term: implement VXLAN processing")

Signed-off-by: Beilei Xing 
---
 examples/tep_termination/vxlan_setup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/examples/tep_termination/vxlan_setup.c 
b/examples/tep_termination/vxlan_setup.c
index 37575c2..8f1f15b 100644
--- a/examples/tep_termination/vxlan_setup.c
+++ b/examples/tep_termination/vxlan_setup.c
@@ -249,7 +249,7 @@ vxlan_link(struct vhost_dev *vdev, struct rte_mbuf *m)

struct rte_eth_tunnel_filter_conf tunnel_filter_conf;

-   if (unlikely(portid > VXLAN_N_PORTS)) {
+   if (unlikely(portid >= VXLAN_N_PORTS)) {
RTE_LOG(INFO, VHOST_DATA,
"(%d) WARNING: Not configuring device,"
"as already have %d ports for VXLAN.",
-- 
2.5.0



[dpdk-dev] [PATCH v2 3/3] i40e: fix out-of-bounds access

2016-07-05 Thread Beilei Xing
When calling i40e_flowtype_to_pctype in
i40e_get_hash_filter_global_config and
i40e_set_hash_filter_global_config, function
i40e_flowtype_to_pctype will be possibly
out-of-bounds accessed, because size of callee's array
is 15. So judge flow type before calling
i40e_flowtype_to_pctype.
Meanwhile do the same change in other functions.

Coverity issue: 37793, 37794

Fixes: 782c8c92f13f ("i40e: add hash configuration")
Fixes: f2b2e2354bbd ("i40e: split function for hash and flow director input")
Fixes: 98f055707685 ("i40e: configure input fields for RSS or flow director")

Signed-off-by: Beilei Xing 
---
 drivers/net/i40e/i40e_ethdev.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index a1cad37..111a552 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -6908,6 +6908,9 @@ i40e_get_hash_filter_global_config(struct i40e_hw *hw,
mask &= ~(1UL << i);
/* Bit set indicats the coresponding flow type is supported */
g_cfg->valid_bit_mask[0] |= (1UL << i);
+   /* if flowtype is invalid, continue */
+   if (!I40E_VALID_FLOW(i))
+   continue;
pctype = i40e_flowtype_to_pctype(i);
reg = i40e_read_rx_ctl(hw, I40E_GLQF_HSYM(pctype));
if (reg & I40E_GLQF_HSYM_SYMH_ENA_MASK)
@@ -6979,6 +6982,9 @@ i40e_set_hash_filter_global_config(struct i40e_hw *hw,
if (!(mask0 & (1UL << i)))
continue;
mask0 &= ~(1UL << i);
+   /* if flowtype is invalid, continue */
+   if (!I40E_VALID_FLOW(i))
+   continue;
pctype = i40e_flowtype_to_pctype(i);
reg = (g_cfg->sym_hash_enable_mask[0] & (1UL << i)) ?
I40E_GLQF_HSYM_SYMH_ENA_MASK : 0;
@@ -7541,13 +7547,11 @@ i40e_hash_filter_inset_select(struct i40e_hw *hw,
return -EINVAL;
}

-   pctype = i40e_flowtype_to_pctype(conf->flow_type);
-   if (pctype == 0 || pctype > I40E_FILTER_PCTYPE_L2_PAYLOAD) {
-   PMD_DRV_LOG(ERR, "Not supported flow type (%u)",
-   conf->flow_type);
+   if (!I40E_VALID_FLOW(conf->flow_type)) {
+   PMD_DRV_LOG(ERR, "invalid flow_type input.");
return -EINVAL;
}
-
+   pctype = i40e_flowtype_to_pctype(conf->flow_type);
ret = i40e_parse_input_set(&input_set, pctype, conf->field,
   conf->inset_size);
if (ret) {
@@ -7612,12 +7616,11 @@ i40e_fdir_filter_inset_select(struct i40e_pf *pf,
return -EINVAL;
}

-   pctype = i40e_flowtype_to_pctype(conf->flow_type);
-   if (pctype == 0 || pctype > I40E_FILTER_PCTYPE_L2_PAYLOAD) {
-   PMD_DRV_LOG(ERR, "Not supported flow type (%u)",
-   conf->flow_type);
+   if (!I40E_VALID_FLOW(conf->flow_type)) {
+   PMD_DRV_LOG(ERR, "invalid flow_type input.");
return -EINVAL;
}
+   pctype = i40e_flowtype_to_pctype(conf->flow_type);
ret = i40e_parse_input_set(&input_set, pctype, conf->field,
   conf->inset_size);
if (ret) {
-- 
2.5.0



[dpdk-dev] [PATCH v2 2/3] i40e: fix dereference before null check

2016-07-05 Thread Beilei Xing
Null-checking vsi suggests that it may be null, but it
has be dereferenced before null-checking. So move if
statement to the front of assignment statement.

Coverity: 119265, 119266

Fixes: d0a349409bd7 ("i40e: support AQ based RSS config")
Fixes: 647d1eaf758b ("i40evf: support AQ based RSS config")

Signed-off-by: Beilei Xing 
---
 drivers/net/i40e/i40e_ethdev.c| 7 +--
 drivers/net/i40e/i40e_ethdev_vf.c | 7 +--
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 46ae866..a1cad37 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -3168,13 +3168,16 @@ i40e_get_rss_lut(struct i40e_vsi *vsi, uint8_t *lut, 
uint16_t lut_size)
 static int
 i40e_set_rss_lut(struct i40e_vsi *vsi, uint8_t *lut, uint16_t lut_size)
 {
-   struct i40e_pf *pf = I40E_VSI_TO_PF(vsi);
-   struct i40e_hw *hw = I40E_VSI_TO_HW(vsi);
+   struct i40e_pf *pf;
+   struct i40e_hw *hw;
int ret;

if (!vsi || !lut)
return -EINVAL;

+   pf = I40E_VSI_TO_PF(vsi);
+   hw = I40E_VSI_TO_HW(vsi);
+
if (pf->flags & I40E_FLAG_RSS_AQ_CAPABLE) {
ret = i40e_aq_set_rss_lut(hw, vsi->vsi_id, TRUE,
  lut, lut_size);
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c 
b/drivers/net/i40e/i40e_ethdev_vf.c
index 7b6df1d..d727232 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -2377,13 +2377,16 @@ i40evf_get_rss_lut(struct i40e_vsi *vsi, uint8_t *lut, 
uint16_t lut_size)
 static int
 i40evf_set_rss_lut(struct i40e_vsi *vsi, uint8_t *lut, uint16_t lut_size)
 {
-   struct i40e_vf *vf = I40E_VSI_TO_VF(vsi);
-   struct i40e_hw *hw = I40E_VSI_TO_HW(vsi);
+   struct i40e_vf *vf;
+   struct i40e_hw *hw;
int ret;

if (!vsi || !lut)
return -EINVAL;

+   vf = I40E_VSI_TO_VF(vsi);
+   hw = I40E_VSI_TO_HW(vsi);
+
if (vf->flags & I40E_FLAG_RSS_AQ_CAPABLE) {
ret = i40e_aq_set_rss_lut(hw, vsi->vsi_id, FALSE,
  lut, lut_size);
-- 
2.5.0



[dpdk-dev] [PATCH v2 1/3] i40e: fix log error

2016-07-05 Thread Beilei Xing
The condition, "(pf->flags | I40E_FLAG_VMDQ)" will always be true,
regardless of the value of the flags operand, because I40E_FLAG_VMDQ
is 4ULL - meaning at least one bit will always be set in the result.
That will cause log error when VMDq is disabled.
Since the original intent behind the condition is to check if VMDq
is enabled, fix the code by changing "|" to "&".

Coverity issue: 13219, 13221

Fixes: 4805ed59e957 ("i40e: enhance mac address operations")

Signed-off-by: Beilei Xing 
---
 drivers/net/i40e/i40e_ethdev.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index f414d93..46ae866 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -2952,9 +2952,10 @@ i40e_macaddr_add(struct rte_eth_dev *dev,
int ret;

/* If VMDQ not enabled or configured, return */
-   if (pool != 0 && (!(pf->flags | I40E_FLAG_VMDQ) || 
!pf->nb_cfg_vmdq_vsi)) {
+   if (pool != 0 && (!(pf->flags & I40E_FLAG_VMDQ) ||
+ !pf->nb_cfg_vmdq_vsi)) {
PMD_DRV_LOG(ERR, "VMDQ not %s, can't set mac to pool %u",
-   pf->flags | I40E_FLAG_VMDQ ? "configured" : "enabled",
+   pf->flags & I40E_FLAG_VMDQ ? "configured" : "enabled",
pool);
return;
}
@@ -3005,7 +3006,7 @@ i40e_macaddr_remove(struct rte_eth_dev *dev, uint32_t 
index)
vsi = pf->main_vsi;
else {
/* No VMDQ pool enabled or configured */
-   if (!(pf->flags | I40E_FLAG_VMDQ) ||
+   if (!(pf->flags & I40E_FLAG_VMDQ) ||
(i > pf->nb_cfg_vmdq_vsi)) {
PMD_DRV_LOG(ERR, "No VMDQ pool enabled"
"/configured");
-- 
2.5.0



[dpdk-dev] [PATCH v2 0/3] fix coverity defects

2016-07-05 Thread Beilei Xing
Fix some open coverity defects.

V2 changes:
 Rework commit log.
 Refactor patchset.

Beilei Xing (3):
  i40e: fix log error
  i40e: fix dereference before null check
  i40e: fix out-of-bounds access

 drivers/net/i40e/i40e_ethdev.c| 35 +--
 drivers/net/i40e/i40e_ethdev_vf.c |  7 +--
 2 files changed, 26 insertions(+), 16 deletions(-)

-- 
2.5.0



[dpdk-dev] [PATCH] scripts: add additional git log capitalization checks

2016-07-05 Thread Bruce Richardson
Add API, HW, SW, FW and VMDq to list of words to capitalize properly.
Since VMDq is a bit unusual, add it as special case check so we can
print an error message giving the correct way to write it.

Signed-off-by: Bruce Richadson 
---
 scripts/check-git-log.sh | 8 
 1 file changed, 8 insertions(+)

diff --git a/scripts/check-git-log.sh b/scripts/check-git-log.sh
index 7d2c7ee..1dbf592 100755
--- a/scripts/check-git-log.sh
+++ b/scripts/check-git-log.sh
@@ -89,7 +89,9 @@ bad=$(echo "$headlines" | grep --color=always \
 bad=$(echo "$headlines" | grep -E --color=always \
-e '\<(rx|tx|RX|TX)\>' \
-e '\<[pv]f\>' \
+   -e '\<[hsf]w\>' \
-e '\' \
+   -e ':.*\' \
-e ':.*\' \
-e ':.*\' \
-e ':.*\' \
@@ -106,6 +108,12 @@ bad=$(echo "$headlines" | grep -E --color=always \
| sed 's,^,\t,')
 [ -z "$bad" ] || printf "Wrong headline lowercase:\n$bad\n"

+# special case check for VMDq to give good error message
+bad=$(echo "$headlines" | grep -E --color=always \
+   -e '\<(vmdq|VMDQ)\>' \
+   | sed 's,^,\t,')
+[ -z "$bad" ] || printf "Wrong headline capitalization, use 'VMDq':\n$bad\n"
+
 # check headline length (60 max)
 bad=$(echo "$headlines" | awk 'length>60 {print}' | sed 's,^,\t,')
 [ -z "$bad" ] || printf "Headline too long:\n$bad\n"
-- 
2.5.5



[dpdk-dev] [PATCH] doc: announce API change for virtual device initialization

2016-07-05 Thread Ferruh Yigit
On 7/4/2016 3:50 PM, Pablo de Lara wrote:
> In order to create a virtual device, user needs to call
> rte_eal_vdev_init generally, but this function returns 0
> on success or negative number if error. Instead, something
> more useful would be to return the port or device id of the
> device created, so the user can call rte_eal_vdev_init
> function and use the device straight away, using the id returned
> by the function.
> 
> Signed-off-by: Pablo de Lara 
> ---
>  doc/guides/rel_notes/deprecation.rst | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst 
> b/doc/guides/rel_notes/deprecation.rst
> index f502f86..60cc7c7 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -41,3 +41,8 @@ Deprecation Notices
>  * The mempool functions for single/multi producer/consumer are deprecated and
>will be removed in 16.11.
>It is replaced by rte_mempool_generic_get/put functions.
> +
> +* The rte_eal_vdev_init function will be changed in 16.11 to return
> +  the port/device id of the device created, instead of 0, when it has been
> +  initialized successfully, so user can use the returned value straight away
> +  to call all the device functions that require that parameter.
> 

Hi Pablo,

There is another API rte_eth_dev_attach(), which returns port_id, and is
a common wrapper both for pdev and vdev.
So with proper devargs this API calls rte_eal_vdev_init() and returns
port_id (set in argument) without any extra side effect.

I just would like remind it in case that works for you, since what
rte_eth_dev_attach() does sounds like what is targeted with this API change.

Thanks,
ferruh


[dpdk-dev] Low packet generation rate of 526kpps using pktgen-dpdk from inside VM

2016-07-05 Thread Wiles, Keith
-Original Message-
From: Abhishek Mahajan 
Date: Tuesday, July 5, 2016 at 1:49 AM
To: Keith Wiles , "dev at dpdk.org" 
Cc: "Addepalli, Srinivasa R" , "Shivastava, 
RakeshX" 
Subject: RE: [dpdk-dev] Low packet generation rate of 526kpps using pktgen-dpdk 
from inside VM

Hi Keith,

I tried your core mask suggestion, still I am getting same performance values.

I just enabled logs for virtio tx in DPDK to find the problem, I am getting 
"PMD: virtio_xmit_pkts() tx: No free tx descriptors to transmit".
This seems to be virtio issue, is there any tuning parameters for increasing 
the virtio performance for using with pktgen-dpdk ?

KW: Pktgen has its own mbufs for sending this message is from the virtio driver 
and you need to look at the configuration options for that driver. Normally the 
TX mbufs are used directly from the application (Pktgen), but in this case it 
must have its own set of mbufs.

Regards
Abhishek

-Original Message-
From: Wiles, Keith [mailto:keith.wi...@intel.com]
Sent: Monday, July 04, 2016 8:03 PM
To: Abhishek Mahajan ; dev at dpdk.org
Cc: Addepalli, Srinivasa R ; RakeshX 
Contact 
Subject: Re: [dpdk-dev] Low packet generation rate of 526kpps using pktgen-dpdk 
from inside VM

-Original Message-
From: dev  on behalf of Abhishek Mahajan 

Date: Monday, July 4, 2016 at 7:27 AM
To: "dev at dpdk.org" 
Cc: "Addepalli, Srinivasa R" , "Shivastava, 
RakeshX" 
Subject: [dpdk-dev] Low packet generation rate of 526kpps using pktgen-dpdk 
from inside VM

Hi,

With pktgen-dpdk inside VM, it is observed that packet TX rate (526Kpps with 
64byte size) is very low. How can higher packet rates be achieved ?

On enabling logs of virtio pmd in DPDK, getting following logs in syslogs:
PMD: virtio_xmit_pkts() tx: No free tx descriptors to transmit

Two PC setup having configuration as follow:
-> Xeon Processor : Intel(R) Xeon(R) CPU E5-2603 v3 @ 1.60GHz  having 6 cores.
-> RAM : 16GB
->One PC is generating traffic other is receiving the packets using pktgen 
tool. The two PC are connected directly with 10G Ethernet interface.

Generation side PC - Host
-> 2 cores dedicated to OVS-DPDK
-> 1 core is free for Linux kernel
-> OS: Ubuntu 14.04
-> Linux kernel : 3.13.0-85-generic
-> DPDK version : 2.2.0
-> OVS version : 2.5.0
-> VFIO driver for port binding

VM - Total 3 cores
-> 2 cores for pktgen
-> 1 core for Linux kernel
-> OS: Ubuntu 15.04
-> Linux kernel : 3.19.8
-> DPDK version : 16.04
-> Pktgen version : 3.0.00
-> UIO driver for port binding

DPDK, OVS and pktgen are build using - x86_64-ivshmen-linuxapp-gcc option.

VM launched through following Qemu command :

* qemu-system-x86_64 --enable-kvm -smp 3 -cpu host -m 2048 -chardev 
socket,id=charnet0,path=/var/run/openvswitch/vhost-user1 -netdev 
type=vhost-user,id=hostnet0,chardev=charnet0,vhostforce=on -device 
virtio-net-pci,netdev=hostnet0,mac=16:fa:13:26:31:1b -object 
memory-backend-file,id=mem,size=2048M,mem-path=/dev/hugepages,share=on -numa 
node,memdev=mem -mem-prealloc -hda /home/aricent/ubuntu_15_04.img

Pktgen is launched using following command:
Pktgen -c -0x3 -n 4 -m 512 -b 000:00:04.0 - p 0x3 -t -m 
"[1:1].0"

KW: I do not think this is Pktgen problem, but please try pktgen ?c 0x6 ?n 4 ?m 
512 ?b :00:04.0 -- -T ?m?[2:2].0?
Core 0 needs to be left alone for Linux and core 1 is used for Pktgen display 
and core 2 is used for Rx/Tx on port 0.

OVS command used:

* /usr/sbin/ovs-vswitchd --dpdk -c 0xc -n 4 -m 2048 -- 
unix:/var/run/openvswitch/db.sock -vconsole:emer -vsyslog:err -vfile:info 
--mlockall --no-chdir --log-file=/var/log/openvswitch/ovs-vswitchd.log 
--pidfile=/var/run/openvswitch/ovs-vswitchd.pid --detach -monitor

Thanks & Regards
Abhishek
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for 
the use of the individual to whom it is addressed. It may contain privileged or 
confidential information and should not be circulated or used for any purpose 
other than for what it is intended. If you have received this message in error, 
please notify the originator immediately. If you are not the intended 
recipient, you are notified that you are strictly prohibited from using, 
copying, altering, or disclosing the contents of this message. Aricent accepts 
no responsibility for loss or damage arising from the use of the information 
transmitted by this email including damage from virus."





"DISCLAIMER: This message is proprietary to Aricent and is intended solely for 
the use of the individual to whom it is addressed. It may contain privileged or 
confidential information and should not be circulated or used for any purpose 
other than for what it is intended. If you have received this message in error, 
please notify the originator immediately. If you are not the intended 
recipient, you are notified that you are strictly prohibited from using, 
copying, altering, or disclosing the contents of this message. Aricent accepts 
no responsibility for loss

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

2016-07-05 Thread Adrien Mazarguil
Hi Jan,

On Tue, Jul 05, 2016 at 01:15:23PM +0200, Jan Viktorin wrote:
> Hi Adrien,
> 
> I am the only one in CC and only in the 00/11 patch. Is it a mistake? Or what 
> is the purpose?

It was on purpose to draw your attention to my comment regarding #includes
within extern "C" blocks.

> Regards?
> Jan?Viktorin
> RehiveTech
> Sent?from?a?mobile?device
> ? P?vodn? zpr?va ?
> Od: Adrien Mazarguil
> Odesl?no: ?ter?, 5. ?ervence 2016 12:45
> Komu: dev at dpdk.org
> Kopie: Jan Viktorin
> P?edm?t: [PATCH v2 00/11] Fix build errors related to exported headers
> 
> 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 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 | 6 +-
> 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 v2 00/11] Fix build errors related to exported headers

2016-07-05 Thread Jan Viktorin
Hi Adrien,

I am the only one in CC and only in the 00/11 patch. Is it a mistake? Or what 
is the purpose?

Regards?
Jan?Viktorin
RehiveTech
Sent?from?a?mobile?device
? P?vodn? zpr?va ?
Od: Adrien Mazarguil
Odesl?no: ?ter?, 5. ?ervence 2016 12:45
Komu: dev at dpdk.org
Kopie: Jan Viktorin
P?edm?t: [PATCH v2 00/11] Fix build errors related to exported headers

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 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 | 6 +-
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 +-
lib/librte_lpm/rte_lpm.h | 7 +-
lib/librte_lpm/rte_lpm_neon.h | 1 +
lib/librte_lpm/rte_lpm_sse.h | 1 +
lib/librte_mbuf/rte_mbuf.h | 9 +
lib/librte_mempool/rte_mempool.h | 3 +
lib/librte_pdump/rte_pdump.h | 4 +
lib/librte_pipeline/rte_pipeline.h | 4 +-
lib/librte_reorder/rte_reorder.h | 2 +
lib/librte_ring/rte_ring.h | 2 +-
lib/librte_sched/rte_bitmap.h | 3 +-
lib/librte_sched/rte_reciproc

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

2016-07-05 Thread 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;
+}
+" "$f

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

2016-07-05 Thread 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 v2 09/11] lib: remove named variadic macros in exported headers

2016-07-05 Thread 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 v2 08/11] lib: work around forward reference to enum types

2016-07-05 Thread 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 v2 07/11] lib: add missing include dependencies

2016-07-05 Thread 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 5aeed22

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

2016-07-05 Thread 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 "rte_cry

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

2016-07-05 Thread 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 v2 04/11] lib: work around nonstandard bit-fields

2016-07-05 Thread 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_ether/rte_ethdev.h| 4 
 lib/librte_lpm/rte_lpm.h | 4 
 lib/librte_mbuf/rte_mbuf.h   | 1 +
 4 files changed, 11 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_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_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; /**< Rule depth. */
 };

+__extension__
 struct rte_lpm_tbl_entry {
/**
 * Stores Next hop (tbl8 or tbl24 when valid_group is not set) or
@@ -137,6 +139,7 @@ struct rte_lpm_tbl_entry {
 };

 #else
+__extension__
 struct rte_lpm_tbl_entry_v20 {
uint8_t depth   :6;
uint8_t valid_group :1;
@@ -147,6 +150,7 @@ struct rte_lpm_tbl_entry_v20 {
};
 };

+__extension__
 struct rte_lpm_tbl_entry {
uint32_t depth   :6;
uint32_t valid_group :1;
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 434ec31..3d3e847 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -865,6 +865,7 @@ struct rte_mbuf {
/* fields to support TX offloads */
union {
uint64_t tx_offload;   /**< combined for easy fetch */
+   __extension__
struct {
uint64_t l2_len:7; /**< L2 (MAC) Header Length. */
uint64_t l3_len:9; /**< L3 (IP) Header Length. */
-- 
2.1.4



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

2016-07-05 Thread 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 101485f..434e

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

2016-07-05 Thread 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 v2 01/11] lib: work around braced-groups within expressions

2016-07-05 Thread 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..9a7b912 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..a71fb13 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); \
typ

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

2016-07-05 Thread 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 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   |   6 +-
 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 +-
 lib/librte_lpm/rte_lpm.h|   7 +-
 lib/librte_lpm/rte_lpm_neon.h   |   1 +
 lib/librte_lpm/rte_lpm_s

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

2016-07-05 Thread Ferruh Yigit
On 7/5/2016 11:44 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).

Out of curiosity, is there a specific standard version that is targeted?



[dpdk-dev] [PATCH v3 3/6] ena: disable readless communication regarding to HW revision

2016-07-05 Thread Jan Mędala
Bruce,

Here's explanation of readless communication (on behalf of Alex):

> "readless" refers to ability to read ENA registers without actually
> issuing read request from host (x86).
> Instead, host programs 2 registers on device that trigger DMA from device
> to host and report register value.
> However, this functionality is not going to be available in all type of
> devices. The decision if this mode is supported or not , is taken from
> revision_id in pci configuration space.


Regards

  Jan

2016-07-04 17:43 GMT+02:00 Bruce Richardson :

> On Thu, Jun 30, 2016 at 05:04:56PM +0200, Jan Medala wrote:
> > Depending on HW revision readless communcation between host and device
> > may be unavailable.
> > In that case prevent PMD of seting up readless communication mechanism.
> >
> The idea of readless communication is a strange one. Can you provide a bit
> more detail as to what "readless communication" refers to.
>
> /Bruce
>


[dpdk-dev] [PATCH 2/2] malloc: no need to zero out memory on zmalloc

2016-07-05 Thread Sergio Gonzalez Monroy
Zeroing out memory on rte_zmalloc_socket is not required anymore since all
allocated memory is already zeroed.

Signed-off-by: Sergio Gonzalez Monroy 
---
 lib/librte_eal/common/rte_malloc.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/lib/librte_eal/common/rte_malloc.c 
b/lib/librte_eal/common/rte_malloc.c
index 47deb00..f4a8835 100644
--- a/lib/librte_eal/common/rte_malloc.c
+++ b/lib/librte_eal/common/rte_malloc.c
@@ -123,11 +123,7 @@ rte_malloc(const char *type, size_t size, unsigned align)
 void *
 rte_zmalloc_socket(const char *type, size_t size, unsigned align, int socket)
 {
-   void *ptr = rte_malloc_socket(type, size, align, socket);
-
-   if (ptr != NULL)
-   memset(ptr, 0, size);
-   return ptr;
+   return rte_malloc_socket(type, size, align, socket);
 }

 /*
-- 
2.4.11



[dpdk-dev] [PATCH 1/2] mem: zero out memory on free

2016-07-05 Thread Sergio Gonzalez Monroy
Since [1] memzones are not guaranteed to be zeroed out.
This could potentially cause issues as applications might have been
relying on the allocated memory being zeroed out.

On init all allocated memory is zeroed by the kernel, so by zeroing out
memory on free, all available dpdk memory is always zeroed.

[1] fafcc11985a2 ("mem: rework memzone to be allocated by malloc")

Signed-off-by: Sergio Gonzalez Monroy 
---
 lib/librte_eal/common/malloc_elem.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/lib/librte_eal/common/malloc_elem.c 
b/lib/librte_eal/common/malloc_elem.c
index 27e9925..42568e1 100644
--- a/lib/librte_eal/common/malloc_elem.c
+++ b/lib/librte_eal/common/malloc_elem.c
@@ -275,11 +275,14 @@ malloc_elem_free(struct malloc_elem *elem)
return -1;

rte_spinlock_lock(&(elem->heap->lock));
+   size_t sz = elem->size - sizeof(*elem);
+   uint8_t *ptr = (uint8_t *)&elem[1];
struct malloc_elem *next = RTE_PTR_ADD(elem, elem->size);
if (next->state == ELEM_FREE){
/* remove from free list, join to this one */
elem_free_list_remove(next);
join_elem(elem, next);
+   sz += sizeof(*elem);
}

/* check if previous element is free, if so join with it and return,
@@ -288,15 +291,17 @@ malloc_elem_free(struct malloc_elem *elem)
if (elem->prev != NULL && elem->prev->state == ELEM_FREE) {
elem_free_list_remove(elem->prev);
join_elem(elem->prev, elem);
-   malloc_elem_free_list_insert(elem->prev);
-   }
-   /* otherwise add ourselves to the free list */
-   else {
-   malloc_elem_free_list_insert(elem);
-   elem->pad = 0;
+   sz += sizeof(*elem);
+   ptr -= sizeof(*elem);
+   elem = elem->prev;
}
+   malloc_elem_free_list_insert(elem);
+
/* decrease heap's count of allocated elements */
elem->heap->alloc_count--;
+
+   memset(ptr, 0, sz);
+
rte_spinlock_unlock(&(elem->heap->lock));

return 0;
-- 
2.4.11



[dpdk-dev] [PATCH 0/3] net/mlx: fix link state modification

2016-07-05 Thread Bruce Richardson
On Tue, Jul 05, 2016 at 11:25:10AM +0200, Adrien Mazarguil wrote:
> On Mon, Jul 04, 2016 at 10:24:16AM +0200, Olivier Matz wrote:
> > This series adds a missing device operation in mlx4 to
> > set the link state. It also fixes the function to set the
> > flags on the kernel interface in both mlx4 and mlx5.
> 
> Thanks.
> 
> Acked-by: Adrien Mazarguil 
> 
Series applied to dpdk-next-net/rel_16_07

/Bruce


[dpdk-dev] [PATCH] doc: announce API change for virtual device initialization

2016-07-05 Thread Declan Doherty
On 04/07/16 15:50, Pablo de Lara wrote:
> In order to create a virtual device, user needs to call
> rte_eal_vdev_init generally, but this function returns 0
> on success or negative number if error. Instead, something
> more useful would be to return the port or device id of the
> device created, so the user can call rte_eal_vdev_init
> function and use the device straight away, using the id returned
> by the function.
>
> Signed-off-by: Pablo de Lara 
> ---
>  doc/guides/rel_notes/deprecation.rst | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst 
> b/doc/guides/rel_notes/deprecation.rst
> index f502f86..60cc7c7 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -41,3 +41,8 @@ Deprecation Notices
>  * The mempool functions for single/multi producer/consumer are deprecated and
>will be removed in 16.11.
>It is replaced by rte_mempool_generic_get/put functions.
> +
> +* The rte_eal_vdev_init function will be changed in 16.11 to return
> +  the port/device id of the device created, instead of 0, when it has been
> +  initialized successfully, so user can use the returned value straight away
> +  to call all the device functions that require that parameter.
>

Acked-by: Declan Doherty 



[dpdk-dev] [PATCH] net/virtio: fix null pointer dereference

2016-07-05 Thread Jianfeng Tan
There is a logic bug in this code, that could lead to null pointer
dereference when cvq is NULL. Fix this problem by changing logic
_and_ to logic _or_.

   >> CID 127480:  Null pointer dereferences  (FORWARD_NULL)
   >> Dereferencing null pointer "cvq".
if (!cvq && !cvq->vq) {
...
}

Coverity issue: 127480

Fixes: 01ad44fd374f ("net/virtio: split Rx/Tx queue")

Signed-off-by: Jianfeng Tan 
---
 drivers/net/virtio/virtio_ethdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index 480daa3..828afef 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -166,7 +166,7 @@ virtio_send_command(struct virtnet_ctl *cvq, struct 
virtio_pmd_ctrl *ctrl,

ctrl->status = status;

-   if (!cvq && !cvq->vq) {
+   if (!cvq || !cvq->vq) {
PMD_INIT_LOG(ERR, "Control queue is not supported.");
return -1;
}
-- 
2.1.4



[dpdk-dev] [PATCH 0/3] net/mlx: fix link state modification

2016-07-05 Thread Adrien Mazarguil
On Mon, Jul 04, 2016 at 10:24:16AM +0200, Olivier Matz wrote:
> This series adds a missing device operation in mlx4 to
> set the link state. It also fixes the function to set the
> flags on the kernel interface in both mlx4 and mlx5.

Thanks.

Acked-by: Adrien Mazarguil 

> Guo Fengtian (1):
>   net/mlx4: add link up/down callback function
> 
> Olivier Matz (2):
>   net/mlx: fix setting of interface flags
>   net/mlx5: fix api comment of link set function
> 
>  drivers/net/mlx4/mlx4.c| 88 
> +-
>  drivers/net/mlx5/mlx5_ethdev.c |  4 +-
>  2 files changed, 89 insertions(+), 3 deletions(-)
> 
> -- 
> 2.8.1

-- 
Adrien Mazarguil
6WIND


[dpdk-dev] [PATCH] net/fm10k: fix Rx descriptor read timing

2016-07-05 Thread Bruce Richardson
On Tue, Jul 05, 2016 at 10:43:42AM +0100, Bruce Richardson wrote:
> On Mon, Jul 04, 2016 at 03:51:08PM +0800, Wang Xiao W wrote:
> > We find that when traffic is light, a few amount of packets will be
> > wrongly parsed (e.g. packet type), however this issue will not happen
> > when traffic is heavy.
> > 
> > The root cause is some fields in fm10k_rx_desc are read at wrong timing.
> > When the input speed is slower than software's capability, fm10k scalar
> > Rx function accesses descriptors closely to HW, so there's potential
> > sequence: some fields like pkt_info in fm10k_rx_desc are read before HW
> > writeback but some fields like DD bit are read after HW writeback, this
> > will lead to the later packet parsing function using incorrect value.
> > 
> > This patch fixes this issue by reading and parsing Rx descriptor after
> > DD bit is set.
> > 
> > Fixes: 4b61d3bfa941 ("fm10k: add receive and tranmit")
> > Fixes: c82dd0a7bfa5 ("fm10k: add scatter receive")
> > 
> > Signed-off-by: Wang Xiao W 
> 
> Fix looks correct to me. The key part I think is that the read of the
> descriptor at line "desc = q->hw_ring[next_dd];" is not atomic as it's
> a read of 16B, allowing part of the descriptor to be read either side of
> a HW write-back.
> 
> Acked-by: Bruce Richardson 
> 
Applied to dpdk-next-net/rel_16_07

/Bruce


[dpdk-dev] [PATCH] net/fm10k: fix Rx descriptor read timing

2016-07-05 Thread Bruce Richardson
On Mon, Jul 04, 2016 at 03:51:08PM +0800, Wang Xiao W wrote:
> We find that when traffic is light, a few amount of packets will be
> wrongly parsed (e.g. packet type), however this issue will not happen
> when traffic is heavy.
> 
> The root cause is some fields in fm10k_rx_desc are read at wrong timing.
> When the input speed is slower than software's capability, fm10k scalar
> Rx function accesses descriptors closely to HW, so there's potential
> sequence: some fields like pkt_info in fm10k_rx_desc are read before HW
> writeback but some fields like DD bit are read after HW writeback, this
> will lead to the later packet parsing function using incorrect value.
> 
> This patch fixes this issue by reading and parsing Rx descriptor after
> DD bit is set.
> 
> Fixes: 4b61d3bfa941 ("fm10k: add receive and tranmit")
> Fixes: c82dd0a7bfa5 ("fm10k: add scatter receive")
> 
> Signed-off-by: Wang Xiao W 

Fix looks correct to me. The key part I think is that the read of the
descriptor at line "desc = q->hw_ring[next_dd];" is not atomic as it's
a read of 16B, allowing part of the descriptor to be read either side of
a HW write-back.

Acked-by: Bruce Richardson 

> ---
>  drivers/net/fm10k/fm10k_rxtx.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/fm10k/fm10k_rxtx.c b/drivers/net/fm10k/fm10k_rxtx.c
> index dd92a91..5b2d04b 100644
> --- a/drivers/net/fm10k/fm10k_rxtx.c
> +++ b/drivers/net/fm10k/fm10k_rxtx.c
> @@ -114,10 +114,10 @@ fm10k_recv_pkts(void *rx_queue, struct rte_mbuf 
> **rx_pkts,
>  
>   nb_pkts = RTE_MIN(nb_pkts, q->alloc_thresh);
>   for (count = 0; count < nb_pkts; ++count) {
> + if (!(q->hw_ring[next_dd].d.staterr & FM10K_RXD_STATUS_DD))
> + break;
>   mbuf = q->sw_ring[next_dd];
>   desc = q->hw_ring[next_dd];
> - if (!(desc.d.staterr & FM10K_RXD_STATUS_DD))
> - break;
>  #ifdef RTE_LIBRTE_FM10K_DEBUG_RX
>   dump_rxd(&desc);
>  #endif
> @@ -228,10 +228,10 @@ fm10k_recv_scattered_pkts(void *rx_queue, struct 
> rte_mbuf **rx_pkts,
>  
>   nb_seg = RTE_MIN(nb_pkts, q->alloc_thresh);
>   for (count = 0; count < nb_seg; count++) {
> + if (!(q->hw_ring[next_dd].d.staterr & FM10K_RXD_STATUS_DD))
> + break;
>   mbuf = q->sw_ring[next_dd];
>   desc = q->hw_ring[next_dd];
> - if (!(desc.d.staterr & FM10K_RXD_STATUS_DD))
> - break;
>  #ifdef RTE_LIBRTE_FM10K_DEBUG_RX
>   dump_rxd(&desc);
>  #endif
> -- 
> 1.9.3
> 


[dpdk-dev] [PATCH] net/thunderx: fix start/stop with different queue size

2016-07-05 Thread Bruce Richardson
On Mon, Jul 04, 2016 at 12:46:14PM +0530, Jerin Jacob wrote:
> From: Kamil Rytarowski 
> 
> Allocate maximum supported hardware ring hardware descriptors
> memory on the first rte_eth_dma_zone_reserve call in-order to
> get sufficient hardware ring buffer space on subsequent queue
> setup request with different queue size.
> 
> Fixes: aa0d976e501d ("net/thunderx: add Rx queue setup and release")
> Fixes: 3f3c6f9724a8 ("net/thunderx: add Tx queue setup and release")
> Fixes: 7413feee662d ("net/thunderx: add device start/stop and close")
> 
> Signed-off-by: Kamil Rytarowski 
> Signed-off-by: Zyta Szpak 
> Signed-off-by: Jerin Jacob 
> ---

Applied to dpdk-next-net/rel_16_07 as:
"net/thunderx: fix memory alloc issue when changing ring size"

/Bruce


[dpdk-dev] [PATCH] app/testpmd: refactor of RSS fwd config

2016-07-05 Thread Ilya Maximets
Since
commit f2bb7ae1d204 ("app/testpmd: handle all Rx queues in RSS setup")
behavior of rss_fwd_config_setup() changed and description of this
function is wrong now.

Also, there is a type mismatch in a loop.

Signed-off-by: Ilya Maximets 
---
 app/test-pmd/config.c | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index c5865f9..bfcbff9 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -1201,14 +1201,9 @@ simple_fwd_config_setup(void)
 }

 /**
- * For the RSS forwarding test, each core is assigned on every port a transmit
- * queue whose index is the index of the core itself. This approach limits the
- * maximumm number of processing cores of the RSS test to the maximum number of
- * TX queues supported by the devices.
- *
- * Each core is assigned a single stream, each stream being composed of
- * a RX queue to poll on a RX port for input messages, associated with
- * a TX queue of a TX port where to send forwarded packets.
+ * For the RSS forwarding test all streams distributed over lcores. Each stream
+ * being composed of a RX queue to poll on a RX port for input messages,
+ * associated with a TX queue of a TX port where to send forwarded packets.
  * All packets received on the RX queue of index "RxQj" of the RX port "RxPi"
  * are sent on the TX queue "TxQl" of the TX port "TxPk" according to the two
  * following rules:
@@ -1222,7 +1217,7 @@ rss_fwd_config_setup(void)
portid_t   txp;
queueid_t  rxq;
queueid_t  nb_q;
-   lcoreid_t  lc_id;
+   streamid_t  sm_id;

nb_q = nb_rxq;
if (nb_q > nb_txq)
@@ -1241,10 +1236,10 @@ rss_fwd_config_setup(void)

setup_fwd_config_of_each_lcore(&cur_fwd_config);
rxp = 0; rxq = 0;
-   for (lc_id = 0; lc_id < cur_fwd_config.nb_fwd_streams; lc_id++) {
+   for (sm_id = 0; sm_id < cur_fwd_config.nb_fwd_streams; sm_id++) {
struct fwd_stream *fs;

-   fs = fwd_streams[lc_id];
+   fs = fwd_streams[sm_id];

if ((rxp & 0x1) == 0)
txp = (portid_t) (rxp + 1);
-- 
2.7.4



[dpdk-dev] [PATCH 1/4] net/virtio-user: fix return value not checked

2016-07-05 Thread Tan, Jianfeng
Hi Yuanhan,

> -Original Message-
> From: Yuanhan Liu [mailto:yuanhan.liu at linux.intel.com]
> Sent: Friday, July 1, 2016 10:16 AM
> To: Tan, Jianfeng
> Cc: dev at dpdk.org; Xie, Huawei; Mcnamara, John
> Subject: Re: [PATCH 1/4] net/virtio-user: fix return value not checked
> 
> On Wed, Jun 29, 2016 at 09:05:33AM +, Jianfeng Tan wrote:
> > -   if (rte_kvargs_count(kvlist, VIRTIO_USER_ARG_CQ_NUM) == 1)
> > -   rte_kvargs_process(kvlist, VIRTIO_USER_ARG_CQ_NUM,
> > -  &get_integer_arg, &cq);
> > +   if (rte_kvargs_count(kvlist, VIRTIO_USER_ARG_CQ_NUM) == 1) {
> > +   ret = rte_kvargs_process(kvlist,
> VIRTIO_USER_ARG_CQ_NUM,
> > +&get_integer_arg, &cq);
> > +   if (ret < 0) {
> > +   PMD_INIT_LOG(ERR, "error to parse %s",
> > +VIRTIO_USER_ARG_CQ_NUM);
> > +   goto end;
> > +   }
> > +   }
> > else if (queues > 1)
> 
> Above 2 lines should be in one line. Fixed, and series applied to
> dpdk-next-virtio.

Thanks.

But there's another problem in the commit log: the Coverity defect ID should be 
"127477, 127478"  instead of "127344, 127478". Can you please help make it 
right?

Thanks,
Jianfeng

> 
> Thanks.
> 
>   --yliu


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

2016-07-05 Thread Shreyansh jain
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.

> 
> Jan
> 

-
Shreyansh




[dpdk-dev] [PATCH v2] net/ixgbe: fix compilation when offload flags disabled

2016-07-05 Thread Bruce Richardson
On Fri, Jul 01, 2016 at 10:02:46AM +0100, Ananyev, Konstantin wrote:
> 
> > The ixgbe driver does not compile if CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE=n
> > because the macro has not the proper number of parameters. To reproduce
> > the issue:
> > 
> >   make config T=x86_64-native-linuxapp-gcc
> >   sed -i 
> > 's,CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE=y,CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE=n,'
> >  build/.config
> >   make -j4
> >   [...]
> >ixgbe_rxtx_vec_sse.c: In function ?_recv_raw_pkts_vec?:
> >ixgbe_rxtx_vec_sse.c:345:53: error: macro "desc_to_olflags_v" passed 3 
> > arguments, but takes just 2
> >   desc_to_olflags_v(descs, vlan_flags, &rx_pkts[pos]);
> > ^
> >ixgbe_rxtx_vec_sse.c:345:3: error: ?desc_to_olflags_v? undeclared (first 
> > use in this function)
> >   desc_to_olflags_v(descs, vlan_flags, &rx_pkts[pos]);
> >   ^
> >ixgbe_rxtx_vec_sse.c:345:3: note: each undeclared identifier is reported 
> > only once for each function it appears in
> >ixgbe_rxtx_vec_sse.c:231:10: error: variable ?vlan_flags? set but not 
> > used [-Werror=unused-but-set-variable]
> >  uint8_t vlan_flags;
> >  ^
> >cc1: all warnings being treated as errors
> > 
> > This patch fixes the number of arguments in th macro, and ensure that
> > vlan_flags is marked as used to avoid the third error.
> > 
> > Fixes: b37b528d957c ("mbuf: add new Rx flags for stripped VLAN")
> > Reported-by: Amin Tootoonchian 
> > Signed-off-by: Olivier Matz 
> > ---
> >  drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c 
> > b/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c
> > index 4f95deb..1c4fd7c 100644
> > --- a/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c
> > +++ b/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c
> > @@ -197,7 +197,9 @@ desc_to_olflags_v(__m128i descs[4], uint8_t vlan_flags,
> > rx_pkts[3]->ol_flags = vol.e[3];
> >  }
> >  #else
> > -#define desc_to_olflags_v(desc, rx_pkts) do {} while (0)
> > +#define desc_to_olflags_v(desc, vlan_flags, rx_pkts) do { \
> > +   RTE_SET_USED(vlan_flags); \
> > +   } while (0)
> >  #endif
> > 
> >  /*
> > --
> 
> Acked-by: Konstantin Ananyev 
> 
Applied to dpdk-next-net/rel_16_07

/Bruce


[dpdk-dev] [PATCH v3] hash: new function to retrieve a key given its position

2016-07-05 Thread De Lara Guarch, Pablo


> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Yari Adan
> Petralanda
> Sent: Monday, July 04, 2016 10:00 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v3] hash: new function to retrieve a key given its
> position
> 
> The function rte_hash_get_key_with_position is added in this patch.
> As the position returned when adding a key is frequently used as an
> offset into an array of user data, this function performs the operation
> of retrieving a key given this offset.
> 
> A possible use case would be to delete a key from the hash table when
> its entry in the array of data has certain value. For instance, the key
> could be a flow 5-tuple, and the value stored in the array a time
> stamp.
> 
> Signed-off-by: Juan Antonio Montesinos
> 
> Signed-off-by: Yari Adan Petralanda 

Acked-by: Pablo de Lara 


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

2016-07-05 Thread Luca Boccassi
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? 

Hi,

Unfortunately we need the VF reset working sooner than that, so one way
or the other I'll need to sort it out. Given I've got a use case where
this is happening, if it can be helpful for you I'm more than happy to
help as a guinea pig. If you could please give some guidance/guidelines
with regards to which API to use to sort the mbuf problem, I can try it
out and give back some feedback.

Thanks!

-- 
Kind regards,
Luca Boccassi


[dpdk-dev] [PATCH v3 6/6] ena: fix for icc compiler

2016-07-05 Thread Ferruh Yigit
On 6/30/2016 4:04 PM, Jan Medala wrote:
> Signed-off-by: Alexander Matushevsky 
> Signed-off-by: Jakub Palider 
> Signed-off-by: Jan Medala 

The compilation error to fix is [1], it may be good to add what to fix
into commit log.

[1]
== Build drivers/net/ena
  CC ena_ethdev.o
/tmp/dpdk_maintain/ena_v3/dpdk/drivers/net/ena/ena_ethdev.c(943): error
#188: enumerated type mixed with another type
struct ena_com_create_io_ctx ctx = { 0 };
 ^

/tmp/dpdk_maintain/ena_v3/dpdk/drivers/net/ena/ena_ethdev.c(1036): error
#188: enumerated type mixed with another type
struct ena_com_create_io_ctx ctx = { 0 };
 ^
...

> --- a/drivers/net/ena/ena_ethdev.c
> +++ b/drivers/net/ena/ena_ethdev.c
> @@ -940,7 +940,10 @@ static int ena_tx_queue_setup(struct rte_eth_dev *dev,
> __rte_unused unsigned int socket_id,
> __rte_unused const struct rte_eth_txconf *tx_conf)
>  {
> - struct ena_com_create_io_ctx ctx = { 0 };
> + struct ena_com_create_io_ctx ctx =
> + /* policy set to _HOST just to satisfy icc compiler */
> + { ENA_ADMIN_PLACEMENT_POLICY_HOST,
> +   ENA_COM_IO_QUEUE_DIRECTION_TX, 0, 0, 0, 0 };

Trailing "0" are not required, compiler will take care of them.





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

2016-07-05 Thread Ferruh Yigit
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.

Compilation error is:
== Build drivers/net/virtio
  CC virtio_rxtx_simple.o
In file included from
/root/development/dpdk/build/include/rte_mempool.h:77:0,
 from
/root/development/dpdk/drivers/net/virtio/virtio_rxtx_simple.c:46:
/root/development/dpdk/drivers/net/virtio/virtio_rxtx_simple.c: In
function ?virtio_xmit_pkts_simple?:
/root/development/dpdk/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);
  ^
/root/development/dpdk/build/include/rte_memcpy.h:552:2: error: array
subscript is above array bounds [-Werror=array-bounds]
  rte_mov16((uint8_t *)dst + 2 * 16, (const uint8_t *)src + 2 * 16);
  ^
/root/development/dpdk/build/include/rte_memcpy.h:553:2: error: array
subscript is above array bounds [-Werror=array-bounds]
  rte_mov16((uint8_t *)dst + 3 * 16, (const uint8_t *)src + 3 * 16);
  ^
/root/development/dpdk/build/include/rte_memcpy.h:554:2: error: array
subscript is above array bounds [-Werror=array-bounds]
  rte_mov16((uint8_t *)dst + 4 * 16, (const uint8_t *)src + 4 * 16);
  ^
...
...

Thanks,
ferruh


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

2016-07-05 Thread Jan Viktorin
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 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.

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.

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.

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?

Any other objections?

Jan Viktorin
RehiveTech
Sent from a mobile device?

>> 
>> Jan
>>?
>
>-
>Shreyansh




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

2016-07-05 Thread Jay Rolette
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


  1   2   >