[dpdk-dev] [PATCH v2] mempool: Free memzone if mempool populate phys fails

[Hemant Agrawal]

From: Nipun Gupta 

This patch fixes the issue of memzone not being freed incase the
rte_mempool_populate_phys fails in the rte_mempool_populate_default

This issue was identified when testing with OVS ~2.6
- configure the system with low memory (e.g. < 500 MB)
- add bridge and dpdk interfaces
- delete brigde
- keep on repeating the above sequence.

Fixes: d1d914ebbc25 ("mempool: allocate in several memory chunks by default")

Signed-off-by: Nipun Gupta 
---
 lib/librte_mempool/rte_mempool.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index e94e56f..aa513b9 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -578,8 +578,10 @@ rte_mempool_populate_default(struct rte_mempool *mp)
mz->len, pg_sz,
rte_mempool_memchunk_mz_free,
(void *)(uintptr_t)mz);
-   if (ret < 0)
+   if (ret < 0) {
+   rte_memzone_free(mz);
goto fail;
+   }
}

return mp->size;
-- 
1.9.1

[dpdk-dev] [PATCH] mempool: Free memzone if mempool populate phys fails

[Hemant Agrawal]

From: Nipun Gupta 

This fixes the issue of memzone not being freed, if the
rte_mempool_populate_phys fails in the rte_mempool_populate_default

This issue was identified when testing with OVS ~2.6
- configure the system with low memory (e.g. < 500 MB)
- add bridge and dpdk interfaces
- delete brigde
- keep on repeating the above sequence.

Signed-off-by: Nipun Gupta 
---
 lib/librte_mempool/rte_mempool.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index e94e56f..aa513b9 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -578,8 +578,10 @@ rte_mempool_populate_default(struct rte_mempool *mp)
mz->len, pg_sz,
rte_mempool_memchunk_mz_free,
(void *)(uintptr_t)mz);
-   if (ret < 0)
+   if (ret < 0) {
+   rte_memzone_free(mz);
goto fail;
+   }
}

return mp->size;
-- 
1.9.1

[dpdk-dev] Clarification for eth_driver changes

[Ferruh Yigit]

On 11/10/2016 11:05 AM, Shreyansh Jain wrote:
> Hello David,
> 
> On Thursday 10 November 2016 01:46 PM, David Marchand wrote:
>> Hello Shreyansh,
>>
>> On Thu, Nov 10, 2016 at 8:26 AM, Shreyansh Jain  
>> wrote:
>>> I need some help and clarification regarding some changes I am doing to
>>> cleanup the EAL code.
>>>
>>> There are some changes which should be done for eth_driver/rte_eth_device
>>> structures:
>>>
>>> 1. most obvious, eth_driver should be renamed to rte_eth_driver.
>>> 2. eth_driver currently has rte_pci_driver embedded in it
>>>  - there can be ethernet devices which are _not_ PCI
>>>  - in which case, this structure should be removed.
>>
>> Do we really need to keep a eth_driver ?
> 
> No. As you have rightly mentioned below (as well as in your Jan'16 
> post), it is a mere convenience.

Isn't it good to separate the logic related which bus device connected
and what functionality it provides. Because these two can be flexible:

device -> virtual_bus -> ethernet_functionality
device -> pci_bus -> crypto_functionality
device -> x_bus   -> y_function


what about:

create generic bus driver/device and all eal level deal with generic
bus. different buses inherit from generic bus logic

create generic functionality device/driver and pmd level deal with
these. different functionalities inherit from generic functionality logic

and use rte_device/rte_driver as glue logic for all these.

This makes easy to add new bus or functionality device/drivers without
breaking existing logic.


Something like this:

struct rte_device {
char *name;
struct rte_driver *drv;
struct rte_bus_device *bus_dev;
struct rte_funcional_device *func_dev;
*devargs
}

struct rte_bus_device {
struct rte_device *dev;
/* generic bus device */
}

struct rte_pci_device {
struct rte_bus_device bus_dev;
/* generic pci bus */
}

struct rte_vdev_device {
struct rte_bus_device bus_dev;
/* generic vdev bus */
}

struct rte_funcional_device {
struct rte_device *dev;
}

struct rte_eth_device {
struct rte_funcional_device func_dev;
/* generic eth device */
}

struct rte_crypto_device {
struct rte_funcional_device func_dev;
/* generic crypto device */
}


struct rte_driver {
char *name;
struct rte_device *dev;
struct rte_bus_driver *bus_drv;
struct rte_funcional_driver *func_drv;
}

struct rte_bus_driver {
struct rte_driver *drv;
rte_bus_probe_t *probe(dev, drv);
rte_bus_remove_t *remove(dev);
/* generic bus driver */
}

struct rte_pci_driver {
struct rte_bus_driver bus_drv;
*id_table;
/* generic pci bus */
}

struct rte_vdev_driver {
struct rte_bus_driver bus_drv;
/* generic vdev bus */
}

struct rte_funcional_driver {
struct rte_driver *drv;
rte_funcional_init_t *init;
rte_funcional_uninit_t *uninit;
}

struct rte_eth_driver {
struct rte_funcional_driver func_drv;
/* generic eth driver */
}

struct rte_crypto_driver {
struct rte_funcional_driver func_drv;
/* generic crypto driver */
}

pci_scan_one()
{
dev = create();
pci_dev = create();

dev->bus_dev = pci_dev;
pci_dev->bus_dev.dev = dev;

insert(bus_dev_list);
}

register_drv(drv)
{
insert(bus_drv_list)
insert(func_drv_list)
insert(drv_list)
}

rte_eal_bus_probe()
  for bus_dev in bus_dev_list
bus_probe_all_drivers(bus_dev)
  for bus_drv in bus_drv_list
bus_probe_one_driver(bus_drv, bus_dev)
  bus_dev->dev->drv = bus_drv->drv;
  bus_drv->drv->dev = bus_dev->dev;
  probe(drv, dev)

probe(drv, dev)
{
dev->func_dev = create();
func_dev->dev = dev;

func_drv = drv->func_drv;
func_drv->init(func_dev);
}

eht_init(func_dev)
{
eth_dev = (struct rte_eth_dev)func_dev;
drv = func_dev->dev->drv;
}

[dpdk-dev] [PATCH v1] doc: fix release notes for 16.11

[Shreyansh Jain]

On Friday 11 November 2016 05:34 PM, John McNamara wrote:
[...]
> -* **Improved device/driver hierarchy and generalized hotplugging**
> +* **Improved device/driver hierarchy and generalized hotplugging.**
>
> -  Device and driver relationship has been restructured by introducing generic
> -  classes. This paves way for having PCI, VDEV and other device types as
> -  just instantiated objects rather than classes in themselves. Hotplugging 
> too
> -  has been generalized into EAL so that ethernet or crypto devices can use 
> the
> +  The device and driver relationship has been restructured by introducing 
> generic
> +  classes. This paves the way for having PCI, VDEV and other device types as
> +  instantiated objects rather than classes in themselves. Hotplugging has 
> also
> +  been generalized into EAL so that Ethernet or crypto devices can use the
>common infrastructure.
>
> -  * removed ``pmd_type`` as way of segregation of devices
> -  * moved ``numa_node`` and ``devargs`` into ``rte_driver`` from
> +  * Removed ``pmd_type`` as a way of segregation of devices.
> +  * Moved ``numa_node`` and ``devargs`` into ``rte_driver`` from
>  ``rte_pci_driver``. These can now be used by any instantiated object of
>  ``rte_driver``.
> -  * added ``rte_device`` class and all PCI and VDEV devices inherit from it
> -  * renamed devinit/devuninit handlers to probe/remove to make it more
> -semantically correct with respect to device<=>driver relationship
> -  * moved hotplugging support to EAL. Hereafter, PCI and vdev can use the
> +  * Added ``rte_device`` class and all PCI and VDEV devices inherit from it
> +  * Renamed devinit/devuninit handlers to probe/remove to make it more
> +semantically correct with respect to the device <=> driver relationship.
> +  * Moved hotplugging support to EAL. Hereafter, PCI and vdev can use the
>  APIs ``rte_eal_dev_attach`` and ``rte_eal_dev_detach``.
> -  * helpers and support macros have been renamed to make them more synonymous
> +  * Renamed helpers and support macros to make them more synonymous
>  with their device types
> -(e.g. ``PMD_REGISTER_DRIVER`` => ``RTE_PMD_REGISTER_PCI``)
> +(e.g. ``PMD_REGISTER_DRIVER`` => ``RTE_PMD_REGISTER_PCI``).
>* Device naming functions have been generalized from ethdev and cryptodev
>  to EAL. ``rte_eal_pci_device_name`` has been introduced for obtaining
>  unique device name from PCI Domain-BDF description.

If it is possible to have a Reviewed-by for a particular part of a patch:

Reviewed-by: Shreyansh Jain 

[dpdk-dev] [PATCH] doc: add sub-repositories information

[Shreyansh Jain]

Hello Ferruh,

Trivial comment/suggestion:

On Thursday 10 November 2016 10:57 PM, Ferruh Yigit wrote:
> DPDK switched to main and sub-repositories approach, this patch
> documents new approach and updates development process according.
>
> Signed-off-by: Ferruh Yigit 
> ---
>  doc/guides/contributing/patches.rst | 18 +++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/doc/guides/contributing/patches.rst 
> b/doc/guides/contributing/patches.rst
> index 729aea7..bec9bfc 100644
> --- a/doc/guides/contributing/patches.rst
> +++ b/doc/guides/contributing/patches.rst
> @@ -20,7 +20,14 @@ The DPDK development process has the following features:
>  * There is a mailing list where developers submit patches.
>  * There are maintainers for hierarchical components.
>  * Patches are reviewed publicly on the mailing list.
> -* Successfully reviewed patches are merged to the master branch of the 
> repository.
> +* Successfully reviewed patches are merged to the repository.
> +
> +|
> +
> +* There are main repository ``dpdk`` and sub-repositories ``dpdk-next-*``.
> +* A patch should be sent for its target repository. Like net drivers should 
> be on top of dpdk-next-net repository.
> +* All sub-repositories merged into main repository for -rc1 and -rc2 
> versions of the release.

'All sub-repositories *are* merged into ...'?

> +* After -rc2 release all patches should target main repository.
>
>  The mailing list for DPDK development is `dev at dpdk.org 
> `_.
>  Contributors will need to `register for the mailing list 
> `_ in order to submit patches.
> @@ -33,12 +40,17 @@ Refer to the `Pro Git Book 
> `_ for further informat
>  Getting the Source Code
>  ---
>
> -The source code can be cloned using either of the following::
> +The source code can be cloned using either of the following:
>
> -git clone git://dpdk.org/dpdk
> +main repository::
>
> +git clone git://dpdk.org/dpdk
>  git clone http://dpdk.org/git/dpdk
>
> +sub-repositories (`list `_)::
> +
> +git clone git://dpdk.org/next/dpdk-next-*
> +git clone http://dpdk.org/git/next/dpdk-next-*
>
>  Make your Changes
>  -
>

-
Shreyansh

[dpdk-dev] [PATCH v1] doc: rearrange the high level documentation index

[Thomas Monjalon]

2016-11-11 13:53, Mcnamara, John:
> I would prefer not to have some of these are highest level items such as
> "Xen Guide", and possibly "Crypto Device Drivers". Perhaps we could push
> them down a level with "Network Interface Controller Drivers" under a
> "Devices and Drivers" (or similar) section like:
> 
> * ...
> * Programmer's Guide
> * HowTo Guides
> * DPDK Tools User Guides
> * Devices and Drivers  
> * Network Interface Controller Drivers
> * Crypto Device Drivers
> * Xen Guide

Yes it may be an idea.
But as we will continue to support Xen Dom0, I think Xen should have
a special place somewhere (in Linux guide or separated)?

[dpdk-dev] [PATCH] improve git diff

[Ferruh Yigit]

On 11/11/2016 4:21 PM, Thomas Monjalon wrote:
> 2016-11-11 11:22, Ferruh Yigit:
>> On 11/9/2016 3:44 PM, Thomas Monjalon wrote:
>>> Sometimes git does not print the name of the function being changed
>>> after @@. It happens especially after a goto label which is not indented.
>>> Giving a hint about the languages of files .c, .h and .py
>>> will improve hunk headers of "git diff" rendering.
>>>
>>> Signed-off-by: Thomas Monjalon 
> [...]
>>> --- /dev/null
>>> +++ b/.gitattributes
>>> @@ -0,0 +1,3 @@
>>> +*.c   diff=cpp
>>> +*.h   diff=cpp
>>
>> Can't git auto detect to use C/C++ language diff use for .c/.h files?
> 
> No
> 
>> Do you have a sample that generates bad hunk header, just to test?
> 
> Yes, you'll find a lot of them with "git log -p | grep '@@.*:'"
> Example:
>   git show bb6722f | grep '@@.*:'
> Without the patch, it is a goto label in the hunk header.
> 

You are right, I was expecting better from git J

[dpdk-dev] [PATCH] improve git diff

[Thomas Monjalon]

2016-11-11 11:22, Ferruh Yigit:
> On 11/9/2016 3:44 PM, Thomas Monjalon wrote:
> > Sometimes git does not print the name of the function being changed
> > after @@. It happens especially after a goto label which is not indented.
> > Giving a hint about the languages of files .c, .h and .py
> > will improve hunk headers of "git diff" rendering.
> > 
> > Signed-off-by: Thomas Monjalon 
[...]
> > --- /dev/null
> > +++ b/.gitattributes
> > @@ -0,0 +1,3 @@
> > +*.c   diff=cpp
> > +*.h   diff=cpp
> 
> Can't git auto detect to use C/C++ language diff use for .c/.h files?

No

> Do you have a sample that generates bad hunk header, just to test?

Yes, you'll find a lot of them with "git log -p | grep '@@.*:'"
Example:
git show bb6722f | grep '@@.*:'
Without the patch, it is a goto label in the hunk header.

[dpdk-dev] [PATCH v2] mempool: Free memzone if mempool populate phys fails

[Olivier Matz]

Hi Hemant,

On 11/11/2016 04:47 PM, Hemant Agrawal wrote:
> From: Nipun Gupta 
> 
> This patch fixes the issue of memzone not being freed incase the
> rte_mempool_populate_phys fails in the rte_mempool_populate_default
> 
> This issue was identified when testing with OVS ~2.6
> - configure the system with low memory (e.g. < 500 MB)
> - add bridge and dpdk interfaces
> - delete brigde
> - keep on repeating the above sequence.
> 
> Fixes: d1d914ebbc25 ("mempool: allocate in several memory chunks by default")
> 
> Signed-off-by: Nipun Gupta 
> ---
>  lib/librte_mempool/rte_mempool.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/librte_mempool/rte_mempool.c 
> b/lib/librte_mempool/rte_mempool.c
> index e94e56f..aa513b9 100644
> --- a/lib/librte_mempool/rte_mempool.c
> +++ b/lib/librte_mempool/rte_mempool.c
> @@ -578,8 +578,10 @@ rte_mempool_populate_default(struct rte_mempool *mp)
>   mz->len, pg_sz,
>   rte_mempool_memchunk_mz_free,
>   (void *)(uintptr_t)mz);
> - if (ret < 0)
> + if (ret < 0) {
> + rte_memzone_free(mz);
>   goto fail;
> + }
>   }
>  
>   return mp->size;
> 

Acked-by: Olivier Matz 


Thanks
Olivier

[dpdk-dev] [xen][dpdk][question] Does dpdk support xenserver 7.0 now?

[Ethan Lynn]

Hi,
  I?m not sure if this is the right mailing list to ask  this question, if not, 
please let me know.

I try to compile dpdk-2.2.0 and dpdk-16.07.1 on xenserver, compilation 
finished, but I got error when using command `insmod rte_dom0_mm.ko`.
insmod: ERROR: could not insert module ./rte_dom0_mm.ko: No such device

I?m not sure if there?s some special configuration I was missing or DPDK 
doesn?t support xenserver 7.0 yet.


Best Regards,
Ethan Lynn
xuanlangjian at gmail.com

[dpdk-dev] [PATCH] doc: announce API and ABI changes for librte_eal

[Pattan, Reshma]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ferruh Yigit
> Sent: Friday, November 11, 2016 1:05 PM
> To: David Marchand ; Shreyansh Jain
> 
> Cc: Neil Horman ; dev at dpdk.org; Thomas
> Monjalon 
> Subject: Re: [dpdk-dev] [PATCH] doc: announce API and ABI changes for
> librte_eal
> 
> On 11/10/2016 3:51 PM, David Marchand wrote:
> > On Thu, Nov 10, 2016 at 12:17 PM, Shreyansh Jain
>  wrote:
> >> Signed-off-by: Shreyansh Jain 
> >> ---
> >>  doc/guides/rel_notes/deprecation.rst | 10 ++
> >>  1 file changed, 10 insertions(+)
> >>
> >> diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> >> index 1a9e1ae..2af2476 100644
> >> --- a/doc/guides/rel_notes/deprecation.rst
> >> +++ b/doc/guides/rel_notes/deprecation.rst
> >> @@ -35,3 +35,13 @@ Deprecation Notices
> >>  * mempool: The functions for single/multi producer/consumer are
> deprecated
> >>and will be removed in 17.02.
> >>It is replaced by ``rte_mempool_generic_get/put`` functions.
> >> +
> >> +* ABI/API changes are planned for 17.02: ``rte_device``, ``rte_driver`` 
> >> will
> be
> >> +  impacted because of introduction of a new ``rte_bus`` hierarchy. This
> would
> >> +  also impact the way devices are identified by EAL. A bus-device-driver
> model
> >> +  will be introduced providing a hierarchical view of devices.
> >> +
> >> +* ``eth_driver`` is planned to be removed in 17.02. This currently serves
> as
> >> +  a placeholder for PMDs to register themselves. Changes for ``rte_bus``
> will
> >> +  provide a way to handle device initialization currently being done in
> >> +  ``eth_driver``.
> >> --
> >> 2.7.4
> >>
> >
> > Acked-by: David Marchand 
> 
> Acked-by: Ferruh Yigit 

Acked-by: Reshma Pattan 

[dpdk-dev] pmdinfogen issues: cross compilation for ARM fails with older host compiler

[Neil Horman]

On Fri, Nov 11, 2016 at 02:48:51PM +0100, Jan Viktorin wrote:
> Hello all,
> 
> On Fri, 11 Nov 2016 10:34:39 +
> Hemant Agrawal  wrote:
> 
> > Hi Neil,
> >Pmdinfogen compiles with host compiler. It usages 
> > rte_byteorder.h of the target platform.
> 
> This seems wierd to me... why is it so? I couldn't find any usage of 
> rte_byteorder.h in the source of pmdinfogen
> (what am I missing?). Why is it included there?
> 
See the CONVERT_NATIVE macro in pmdinfogen.h.  It makes use of the various
rte_[le|be]_to_cpu macros from rte_byteorder.h

> The pmdinfogen executes on the host but works with the (cross-compiled) 
> target binaries. Is that right? If the tool
> needs to know endianity then we probably need a header telling just the 
> target's endianity (or other metadata).
> 
pmdinfogen works on ELF object files, and can extract the endianess from the ELF
header itself (using the e_ident[EI_DATA] area).

> > However, if the host compiler is older than 4.8, it will be an issue during 
> > cross compilation for some platforms.
> > e.g. if we are compiling on x86 host for ARM, x86 host compiler will not 
> > understand the arm asm instructions.
> 
> This is not the actual issue. Consider an ARM build server that 
> cross-compiles DPDK for Intel x86 (I admit that this
> is quite a ridiculous situation, so take it easy ;)). Then we have just 
> opposite issues... Would we like to fill the
> DPDK x86 code base with #ifdef...#endif everytime there is some assembly 
> code? I'd just like to point out that this
> single instruction is not the true source of the problem. It is like 
> complaining that nasm cannot compile Thumb2
> instructions... No it cannot, sorry.
> 
It sounds like the issue is a general 'how to get support for another arch'
question.  In the case of rte_byteorder.h, its actually pretty cut and dry,
because thankfully all the instructions are wrapped up into nice C inline
functions or macros.  The trick is to simply define the api instructions in the
file for each arch, with a default generic case that just uses C, so it can be
compiled into whatever the target arch needs (although it may run more slowly).
That gets you initial support, and then you can optimize be creating a special
case for the new arch.  You have to do that for every API set that has per-arch
optimizations (the atomic ops, the tsc ops, memcpy, cpuflags, prefetch, etc).
Its time consuming, but its just the way it is.

> > 
> > /* fix missing __builtin_bswap16 for gcc older then 4.8 */
> > #if !(__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8))
> > static inline uint16_t rte_arch_bswap16(uint16_t _x)
> > {
> >register uint16_t x = _x;
> >asm volatile ("rev16 %0,%1"
> > : "=r" (x)
> > : "r" (x)
> > );
> >return x;
> > }
> > #endif
> > 
> > One easy solution is that we add compiler platform check in this code 
> > section of rte_byteorder.h
> > e.g
> > #if !(defined __arm__ || defined __aarch64__)
> > static inline uint16_t rte_arch_bswap16(uint16_t _x)
> > {
> >return (_x >> 8) | ((_x << 8) & 0xff00);
> > }
> > #else ?.
> > 
> > Is there a better way to fix it?
> 
Well, almost, what you have above is a good solution, but it shouldn't be the
ARM solution, it should be the code used if an arch specific variant of the code
isn't defined. The pattern rte_byteorder should follow is

#if (defined i686 || defined x86_64)

#elif (defined ppc || ppc64)

#else

#endif

The idea is to have a generic version that works for any arch to fall back on,
then if you have a faster way to do it on your arch, you can add a clause at
your leisure to do so.

Neil

> In my opinion, this would work as a hotfix but not as a solution.
> 
> Kind regards
> Jan
> 
> > 
> > Regards,
> > Hemant
> > 
> > 
> > From: Michael Wildt [mailto:michael.wildt at broadcom.com]
> > Sent: Wednesday, September 14, 2016 7:18 PM
> > To: Hemant Agrawal 
> > Cc: Thomas Monjalon ; users at dpdk.org
> > Subject: Re: [dpdk-users] Cross compile for ARM64 fails due to librte_vhost 
> > and pmdinfogen issues
> > 
> > Hi Hemant,
> > 
> > Thanks for the pointer to the 4.9.3 version. Haven't had issues with 4.9.2 
> > but good to know.
> > 
> > I gave that one a try and that works as well but as with the 5.3 I have to 
> > be on a Ubuntu not RHEL6 to make it work.
> > 
> > Thanks,
> > Michael
> > 
> > On Wed, Sep 14, 2016 at 3:25 AM, Hemant Agrawal  > nxp.com> wrote:
> > Hi Michael,
> > One of the problem, I found with Linaro gcc 4.9 toolchain for i686 
> > (default one), that it seems to be built with older kernel headers (<3.8). 
> > This usages older linux/vhost.h file.
> > 
> > However, we have not observed this issue with x86_64 based toolchain on 64 
> > bit m/c.
> >  
> > 

[dpdk-dev] [PATCH] i40e: Fix eth_i40e_dev_init sequence on ThunderX

[Zhang, Helin]

Hi Rao

The existing rule is to try best not modify source files in the folder of base/ 
for each PMD. The exceptions are *_osdep.h or *_osdep.c.
So for your case, please redefine the rd32/wr32 in i40e_osdep.h. (with 
condition compiles for ARM?, as other CPU structures may not need that.)

Regards,
Helin

> -Original Message-
> From: Satha Rao [mailto:skoteshwar at caviumnetworks.com]
> Sent: Thursday, November 10, 2016 8:04 PM
> To: Zhang, Helin
> Cc: Wu, Jingjing; jerin.jacob at caviumnetworks.com; jianbo.liu at linaro.org;
> dev at dpdk.org; Satha Rao
> Subject: [PATCH] i40e: Fix eth_i40e_dev_init sequence on ThunderX
> 
> i40e_asq_send_command: rd32 & wr32 under ThunderX gives unpredictable
>results. To solve this include rte memory barriers
> 
> Signed-off-by: Satha Rao 
> ---
>  drivers/net/i40e/base/i40e_adminq.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/i40e/base/i40e_adminq.c
> b/drivers/net/i40e/base/i40e_adminq.c
> index 0d3a83f..1038a95 100644
> --- a/drivers/net/i40e/base/i40e_adminq.c
> +++ b/drivers/net/i40e/base/i40e_adminq.c
> @@ -832,6 +832,7 @@ enum i40e_status_code
> i40e_asq_send_command(struct i40e_hw *hw,
>   }
> 
>   val = rd32(hw, hw->aq.asq.head);
> + rte_rmb();
>   if (val >= hw->aq.num_asq_entries) {
>   i40e_debug(hw, I40E_DEBUG_AQ_MESSAGE,
>  "AQTX: head overrun at %d\n", val); @@ -929,8
> +930,10 @@ enum i40e_status_code i40e_asq_send_command(struct
> i40e_hw *hw,
>   (hw->aq.asq.next_to_use)++;
>   if (hw->aq.asq.next_to_use == hw->aq.asq.count)
>   hw->aq.asq.next_to_use = 0;
> - if (!details->postpone)
> + if (!details->postpone) {
>   wr32(hw, hw->aq.asq.tail, hw->aq.asq.next_to_use);
> + rte_wmb();
> + }
> 
>   /* if cmd_details are not defined or async flag is not set,
>* we need to wait for desc write back
> --
> 2.7.4

[dpdk-dev] [PATCH v1] doc: rearrange the high level documentation index

[Mcnamara, John]

> -Original Message-
> From: Mcnamara, John
> Sent: Friday, November 11, 2016 1:46 PM
> To: dev at dpdk.org
> Cc: Mcnamara, John 
> Subject: [PATCH v1] doc: rearrange the high level documentation index
> 
> Rearrange the order of the high level documenation index into a more
> logical sequence for a new user.
> 
> Also, improve some of the high-level document names.
> 
> Signed-off-by: John McNamara 
> ---
> 
> After this patch the high-level index will look like this:
> 
> DPDK documentation
> 
> * Getting Started Guide for Linux
> * Getting Started Guide for FreeBSD
> * Sample Applications User Guides
> * Programmer's Guide
> * HowTo Guides
> * DPDK Tools User Guides
> * Testpmd Application User Guide
> * Network Interface Controller Drivers
> * Crypto Device Drivers
> * Xen Guide
> * Contributor's Guidelines
> * Release Notes
> * FAQ

P.S.,

I would prefer not to have some of these are highest level items such as
"Xen Guide", and possibly "Crypto Device Drivers". Perhaps we could push
them down a level with "Network Interface Controller Drivers" under a
"Devices and Drivers" (or similar) section like:

* ...
* Programmer's Guide
* HowTo Guides
* DPDK Tools User Guides
* Devices and Drivers  
* Network Interface Controller Drivers
* Crypto Device Drivers
* Xen Guide
* ...

[dpdk-dev] [PATCH v1] doc: rearrange the high level documentation index

[John McNamara]

Rearrange the order of the high level documenation index into
a more logical sequence for a new user.

Also, improve some of the high-level document names.

Signed-off-by: John McNamara 
---

After this patch the high-level index will look like this:

DPDK documentation

* Getting Started Guide for Linux
* Getting Started Guide for FreeBSD
* Sample Applications User Guides
* Programmer's Guide
* HowTo Guides
* DPDK Tools User Guides
* Testpmd Application User Guide
* Network Interface Controller Drivers
* Crypto Device Drivers
* Xen Guide
* Contributor's Guidelines
* Release Notes
* FAQ


 doc/guides/howto/index.rst |  4 ++--
 doc/guides/index.rst   | 14 +++---
 doc/guides/sample_app_ug/index.rst |  4 ++--
 doc/guides/tools/index.rst |  4 ++--
 4 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/doc/guides/howto/index.rst b/doc/guides/howto/index.rst
index aa6d3e2..5575b27 100644
--- a/doc/guides/howto/index.rst
+++ b/doc/guides/howto/index.rst
@@ -28,8 +28,8 @@
 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

-How To User Guides
-==
+HowTo Guides
+

 .. toctree::
 :maxdepth: 2
diff --git a/doc/guides/index.rst b/doc/guides/index.rst
index 57570f6..82b00e9 100644
--- a/doc/guides/index.rst
+++ b/doc/guides/index.rst
@@ -36,14 +36,14 @@ DPDK documentation

linux_gsg/index
freebsd_gsg/index
-   xen/index
-   prog_guide/index
-   nics/index
-   cryptodevs/index
sample_app_ug/index
+   prog_guide/index
+   howto/index
tools/index
testpmd_app_ug/index
-   faq/index
-   howto/index
-   rel_notes/index
+   nics/index
+   cryptodevs/index
+   xen/index
contributing/index
+   rel_notes/index
+   faq/index
diff --git a/doc/guides/sample_app_ug/index.rst 
b/doc/guides/sample_app_ug/index.rst
index cce0a9b..775e2f7 100644
--- a/doc/guides/sample_app_ug/index.rst
+++ b/doc/guides/sample_app_ug/index.rst
@@ -28,8 +28,8 @@
 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

-Sample Applications User Guide
-==
+Sample Applications User Guides
+===

 .. toctree::
 :maxdepth: 2
diff --git a/doc/guides/tools/index.rst b/doc/guides/tools/index.rst
index cbe98b2..513221c 100644
--- a/doc/guides/tools/index.rst
+++ b/doc/guides/tools/index.rst
@@ -28,8 +28,8 @@
 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

-Tool User Guides
-
+DPDK Tools User Guides
+==

 .. toctree::
 :maxdepth: 2
-- 
2.7.4

[dpdk-dev] [PATCH v2] doc: add sub-repositories information

[Ferruh Yigit]

DPDK switched to main and sub-repositories approach, this patch
documents new approach and updates development process according.

Signed-off-by: Ferruh Yigit 
Acked-by: John McNamara 
---
 doc/guides/contributing/patches.rst | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/doc/guides/contributing/patches.rst 
b/doc/guides/contributing/patches.rst
index 729aea7..fabddbe 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -20,7 +20,14 @@ The DPDK development process has the following features:
 * There is a mailing list where developers submit patches.
 * There are maintainers for hierarchical components.
 * Patches are reviewed publicly on the mailing list.
-* Successfully reviewed patches are merged to the master branch of the 
repository.
+* Successfully reviewed patches are merged to the repository.
+
+|
+
+* There are main repository ``dpdk`` and sub-repositories ``dpdk-next-*``.
+* A patch should be sent for its target repository. Like net drivers should be 
on top of dpdk-next-net repository.
+* All sub-repositories are merged into main repository for -rc1 and -rc2 
versions of the release.
+* After -rc2 release all patches should target main repository.

 The mailing list for DPDK development is `dev at dpdk.org 
`_.
 Contributors will need to `register for the mailing list 
`_ in order to submit patches.
@@ -33,12 +40,17 @@ Refer to the `Pro Git Book `_ 
for further informat
 Getting the Source Code
 ---

-The source code can be cloned using either of the following::
+The source code can be cloned using either of the following:

-git clone git://dpdk.org/dpdk
+main repository::

+git clone git://dpdk.org/dpdk
 git clone http://dpdk.org/git/dpdk

+sub-repositories (`list `_)::
+
+git clone git://dpdk.org/next/dpdk-next-*
+git clone http://dpdk.org/git/next/dpdk-next-*

 Make your Changes
 -
-- 
2.9.3

[dpdk-dev] [PATCH] doc: add sub-repositories information

[Ferruh Yigit]

Hi Shreyansh,

On 11/11/2016 1:15 PM, Shreyansh Jain wrote:
>> +* All sub-repositories merged into main repository for -rc1 and -rc2 
>> versions of the release.
> 'All sub-repositories *are* merged into ...'?

I will send a fixed version.

Thanks,
ferruh

[dpdk-dev] [PATCH] doc: announce API and ABI changes for librte_eal

[Ferruh Yigit]

On 11/10/2016 3:51 PM, David Marchand wrote:
> On Thu, Nov 10, 2016 at 12:17 PM, Shreyansh Jain  
> wrote:
>> Signed-off-by: Shreyansh Jain 
>> ---
>>  doc/guides/rel_notes/deprecation.rst | 10 ++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/doc/guides/rel_notes/deprecation.rst 
>> b/doc/guides/rel_notes/deprecation.rst
>> index 1a9e1ae..2af2476 100644
>> --- a/doc/guides/rel_notes/deprecation.rst
>> +++ b/doc/guides/rel_notes/deprecation.rst
>> @@ -35,3 +35,13 @@ Deprecation Notices
>>  * mempool: The functions for single/multi producer/consumer are deprecated
>>and will be removed in 17.02.
>>It is replaced by ``rte_mempool_generic_get/put`` functions.
>> +
>> +* ABI/API changes are planned for 17.02: ``rte_device``, ``rte_driver`` 
>> will be
>> +  impacted because of introduction of a new ``rte_bus`` hierarchy. This 
>> would
>> +  also impact the way devices are identified by EAL. A bus-device-driver 
>> model
>> +  will be introduced providing a hierarchical view of devices.
>> +
>> +* ``eth_driver`` is planned to be removed in 17.02. This currently serves as
>> +  a placeholder for PMDs to register themselves. Changes for ``rte_bus`` 
>> will
>> +  provide a way to handle device initialization currently being done in
>> +  ``eth_driver``.
>> --
>> 2.7.4
>>
> 
> Acked-by: David Marchand 

Acked-by: Ferruh Yigit 

[dpdk-dev] [PATCH] Revert "bonding: use existing enslaved device queues"

[Ilya Maximets]

Ping.

On 28.10.2016 09:14, Ilya Maximets wrote:
> On 25.10.2016 09:26, Ilya Maximets wrote:
>> On 24.10.2016 17:54, Jan Blunck wrote:
>>> On Wed, Oct 19, 2016 at 5:47 AM, Ilya Maximets  
>>> wrote:
 On 18.10.2016 18:19, Jan Blunck wrote:
> On Tue, Oct 18, 2016 at 2:49 PM, Ilya Maximets  samsung.com> wrote:
>> On 18.10.2016 15:28, Jan Blunck wrote:
>>> If the application already configured queues the PMD should not
>>> silently claim ownership and reset them.
>>>
>>> What exactly is the problem when changing MTU? This works fine from
>>> what I can tell.
>>
>> Following scenario leads to APP PANIC:
>>
>> 1. mempool_1 = rte_mempool_create()
>> 2. rte_eth_rx_queue_setup(bond0, ..., mempool_1);
>> 3. rte_eth_dev_start(bond0);
>> 4. mempool_2 = rte_mempool_create();
>> 5. rte_eth_dev_stop(bond0);
>> 6. rte_eth_rx_queue_setup(bond0, ..., mempool_2);
>> 7. rte_eth_dev_start(bond0);
>> * RX queues still use 'mempool_1' because reconfiguration 
>> doesn't affect them. *
>> 8. rte_mempool_free(mempool_1);
>> 9. On any rx operation we'll get PANIC because of using freed 
>> 'mempool_1':
>>  PANIC in rte_mempool_get_ops():
>>  assert "(ops_index >= 0) && (ops_index < 
>> RTE_MEMPOOL_MAX_OPS_IDX)" failed
>>
>> You may just start OVS 2.6 with DPDK bonding device and attempt to 
>> change MTU via 'mtu_request'.
>> Bug is easily reproducible.
>>
>
> I see. I'm not 100% that this is expected to work without leaking the
> driver's queues though. The driver is allowed to do allocations in
> its rx_queue_setup() function that are being freed via
> rx_queue_release() later. But rx_queue_release() is only called if you
> reconfigure the
> device with 0 queues.
>>
>> It's not true. Drivers usually calls 'rx_queue_release()' inside
>> 'rx_queue_setup()' function while reallocating the already allocated
>> queue. (See ixgbe driver for example). Also all HW queues are
>> usually destroyed inside 'eth_dev_stop()' and reallocated in
>> 'eth_dev_start()' or '{rx,tx}_queue_setup()'.
>> So, there is no leaks at all.
>>
> From what I understand there is no other way to
> reconfigure a device to use another mempool.
>
> But ... even that wouldn't work with the bonding driver right now: the
> bonding master only configures the slaves during startup. I can put
> that on my todo list.
>>
>> No, bonding master reconfigures new slaves in 'rte_eth_bond_slave_add()'
>> if needed.
>>
> Coming back to your original problem: changing the MTU for the bond
> does work through rte_eth_dev_set_mtu() for slaves supporting that. In
> any other case you could (re-)configure rxmode.max_rx_pkt_len (and
> jumbo_frame / enable_scatter accordingly). This does work without a
> call to rte_eth_rx_queue_setup().

 Thanks for suggestion, but using of rte_eth_dev_set_mtu() without
 reconfiguration will require to have mempools with huge mbufs (9KB)
 for all ports from the start. This is unacceptable because leads to
 significant performance regressions because of fast cache exhausting.
 Also this will require big work to rewrite OVS reconfiguration code
 this way.
 Anyway, it isn't the MTU only problem. Number of rx/tx descriptors
 also can't be changed in runtime.


 I'm not fully understand what is the use case for this 'reusing' code.
 Could you, please, describe situation where this behaviour is necessary?
>>>
>>> The device that is added to the bond was used before and therefore
>>> already has allocated queues. Therefore we reuse the existing queues
>>> of the devices instead of borrowing the queues of the bond device. If
>>> the slave is removed from the bond again there is no need to allocate
>>> the queues again.
>>>
>>> Hope that clarifies the usecase
>>
>> So, As I see, this is just an optimization that leads to differently
>> configured queues of same device and possible application crash if the
>> old configuration doesn't valid any more.
>>
>> With revert applied in your usecase while adding the device to bond
>> it's queues will be automatically reconfigured according to configuration
>> of the bond device. If the slave is removed from the bond all its'
>> queues will remain as configured by bond. You can reconfigure them if
>> needed. I guess, that in your case configuration of slave devices,
>> actually, matches configuration of bond device. In that case slave
>> will remain in the same state after removing from bond as it was
>> before adding.
> 
> So, Jan, Declan, what do you think about this?
> 
> Best regards, Ilya Maximets.
> 

[dpdk-dev] [PATCH v1] doc: fix release notes for 16.11

[John McNamara]

Fix grammar, spelling and formatting of DPDK 16.11 release notes.

Signed-off-by: John McNamara 
---
 doc/guides/rel_notes/release_16_11.rst | 171 -
 1 file changed, 83 insertions(+), 88 deletions(-)

diff --git a/doc/guides/rel_notes/release_16_11.rst 
b/doc/guides/rel_notes/release_16_11.rst
index 365b5a3..6f40f59 100644
--- a/doc/guides/rel_notes/release_16_11.rst
+++ b/doc/guides/rel_notes/release_16_11.rst
@@ -42,7 +42,7 @@ New Features
   * Added a new function ``rte_pktmbuf_read()`` to read the packet data from an
 mbuf chain, linearizing if required.
   * Added a new function ``rte_net_get_ptype()`` to parse an Ethernet packet
-in an mbuf chain and retrieve its packet type by software.
+in an mbuf chain and retrieve its packet type from software.
   * Added new functions ``rte_get_ptype_*()`` to dump a packet type as a 
string.

 * **Improved offloads support in mbuf.**
@@ -52,102 +52,108 @@ New Features
   * Added new Rx checksum flags in mbufs to describe more states: unknown,
 good, bad, or not present (useful for virtual drivers). This modification
 was done for IP and L4.
-  * Added a new RX LRO mbuf flag, used when packets are coalesced. This
+  * Added a new Rx LRO mbuf flag, used when packets are coalesced. This
 flag indicates that the segment size of original packets is known.

-* **Added vhost-user dequeue zero copy support**
+* **Added vhost-user dequeue zero copy support.**

-  The copy in dequeue path is saved, which is meant to improve the performance.
+  The copy in the dequeue path is avoided in order to improve the performance.
   In the VM2VM case, the boost is quite impressive. The bigger the packet size,
-  the bigger performance boost you may get. However, for VM2NIC case, there
-  are some limitations, yet the boost is not that impressive as VM2VM case.
+  the bigger performance boost you may get. However, for the VM2NIC case, there
+  are some limitations, so the boost is not as  impressive as the VM2VM case.
   It may even drop quite a bit for small packets.

-  For such reason, this feature is disabled by default. It can be enabled when
-  ``RTE_VHOST_USER_DEQUEUE_ZERO_COPY`` flag is given. Check the vhost section
-  at programming guide for more information.
+  For that reason, this feature is disabled by default. It can be enabled when
+  the ``RTE_VHOST_USER_DEQUEUE_ZERO_COPY`` flag is set. Check the VHost section
+  of the Programming Guide for more information.

 * **Added vhost-user indirect descriptors support.**

-  If indirect descriptor feature is negotiated, each packet sent by the guest
-  will take exactly one slot in the enqueue virtqueue. Without the feature, in
-  current version, even 64 bytes packets take two slots with Virtio PMD on 
guest
+  If the indirect descriptor feature is enabled, each packet sent by the guest
+  will take exactly one slot in the enqueue virtqueue. Without this feature, 
as in
+  the current version, even 64 bytes packets take two slots with Virtio PMD on 
guest
   side.

   The main impact is better performance for 0% packet loss use-cases, as it
   behaves as if the virtqueue size was enlarged, so more packets can be 
buffered
-  in case of system perturbations. On the downside, small performance 
degradation
-  is measured when running micro-benchmarks.
+  in the case of system perturbations. On the downside, small performance 
degradations
+  were measured when running micro-benchmarks.

 * **Added vhost PMD xstats.**

-  Added extended statistics to vhost PMD from per port perspective.
+  Added extended statistics to vhost PMD from a per port perspective.

 * **Supported offloads with virtio.**

-  * Rx/Tx checksums
-  * LRO
-  * TSO
+  Added support for the following offloads in virtio:
+
+  * Rx/Tx checksums.
+  * LRO.
+  * TSO.

 * **Added virtio NEON support for ARM.**

+  Added NEON support for ARM based virtio.
+
 * **Updated the ixgbe base driver.**

   Updated the ixgbe base driver, including the following changes:

-  * add X550em_a 10G PHY support
-  * support flow control auto negotiation for X550em_a 1G PHY
-  * add X550em_a FW ALEF support
-  * increase mailbox version to ixgbe_mbox_api_13
-  * add two MAC ops for Hyper-V support
+  * Added X550em_a 10G PHY support.
+  * Added support for flow control auto negotiation for X550em_a 1G PHY.
+  * Added X550em_a FW ALEF support.
+  * Increased mailbox version to ``ixgbe_mbox_api_13``.
+  * Added two MAC operations for Hyper-V support.

-* **Added API's for VF management to the ixgbe PMD.**
+* **Added APIs for VF management to the ixgbe PMD.**

-  Eight new API's have been added to the ixgbe PMD for VF management from the 
PF.
+  Eight new APIs have been added to the ixgbe PMD for VF management from the 
PF.
   The declarations for the API's can be found in ``rte_pmd_ixgbe.h``.

 * **Updated the enic driver.**

-  * Use interrupt for link status checking instead of polling
-  * More flow director modes on UCS 

[dpdk-dev] [PATCH] ethdev: check number of queues less than RTE_ETHDEV_QUEUE_STAT_CNTRS

[Bert van Leeuwen]

> On 11 Nov 2016, at 11:29 AM, Thomas Monjalon  
> wrote:
> 
> 2016-11-11 09:16, Alejandro Lucero:
>> Thomas,
>> 
>> We are wondering if you realize this patch fixes a bug with current ethdev
>> code as a device can have more than RTE_ETHDEV_QUEUE_STAT_CNTRS.
>> 
>> Maybe the commit message is giving the wrong impression and as you
>> commented, it should just focus on the bug it fixes and to leave for
>> another email thread the discussion of how to solve the
>> RTE_ETHDEV_QUEUE_STAT_CNTRS
>> problem.
>> 
>> Should we remove this from patchwork and to send another patch that way?
> 
> Yes please. It was my first comment, we don't understand the exact issue
> you are fixing.

In a nutshell, the rte_eth_xstats_get function was reading memory beyond what 
was stored in the internal arrays (and thus returning junk values). The patch 
simply prevents it from going out of bounds, it does not address the issue that 
the rest of the counters are lost though. This issue is not specific to our 
device, in fact we found it while using a multiqueue virtio device (32 queues), 
and traced the issue into this core ethdev functionality.

> And I have a bad feeling it could break something else (really just a 
> feeling).
> It is not the kind of patch we can apply the last day of a release.
> That's why I think it should wait 17.02.
> 
> Of course you can try to convince me and others to apply it as a last minute
> patch. But why are you sending a patch on the generic API in the last days?
> 
> Last argument: it is not fixing a regression of 16.11, so it is not so urgent.

Yes, it looks like this bug was present in DPDK 2.2 even, and possibly before 
that too.

[dpdk-dev] [PATCH v7 11/21] eal/soc: implement probing of drivers

[Shreyansh Jain]

On Thursday 10 November 2016 02:56 PM, Thomas Monjalon wrote:
> 2016-11-10 14:40, Shreyansh Jain:
>> On Thursday 10 November 2016 01:11 PM, Jianbo Liu wrote:
>>> On 10 November 2016 at 14:10, Shreyansh Jain  
>>> wrote:
 On Thursday 10 November 2016 09:00 AM, Jianbo Liu wrote:
> I'm still not sure about the purpose of soc_scan, and how to use it.


 For each device to be used by DPDK, which cannot be scanned/identified 
 using
 the existing PCI/VDEV methods (sysfs/bus/pci), 'soc_scan_t' provides a way
 for driver to make those devices part of device lists.

 Ideally, 'scan' is not a function of a driver. It is a bus function - which
 is missing in this case.

> If it's for each driver, it should at least struct rte_soc_driver * as
> its parameter.


 Its for each driver - assuming that each non-PCI driver which implements it
 knows how to find devices which it can control (for example, special area 
 in
 sysfs, or even platform bus).

>>>
>>> Considering there are several drivers in a platform bus, each driver
>>> call the scan function, like the rte_eal_soc_scan_platform_bus() you
>>> implemented.
>>> The first will add soc devices to the list, but the remaining calls
>>> are redundant.
>>
>> Indeed. This is exactly the issue we will face if we try and move this
>> scan/match logic to PCI - all devices are identified in one step.
>>
>> There is a difference in principle here:
>> A SoC device/driver combination is essentially focused towards a single
>> type of bus<->devices. For example, a NXP PMD would implement a scan
>> function which would scan for all devices on NXP's bus. This would not
>> conflict with another XYZ SoC PMD which scans its specific bus.
>>
>> There is caveat to this - the platform bus. There can be multiple
>> drivers which can serve platform bus compliant devices. First
>> PMD->scan() initiated for such a bus/device would leave all other scans
>> redundant.
>>
>> More similar caveats will come if we consider somewhat generic buses. At
>> least I couldn't find any interest for such devices in the ML when I
>> picked this series (from where Jan left it).
>>
>> Probably when more common type of PMDs come in, some default scan
>> implementation can check for skipping those devices which are already
>> added. It would be redundant but harmless.
>
> If several drivers use the same bus, it means the bus is standard enough
> to be implemented in EAL. So the scan function of this bus should be
> called only once when calling the generic EAL scan function.
>

In the current model, without a bus like object, this can only be 
implemented as a hack. This is because:
- If each driver has its scan, some of them (those on a common bus) 
would have their scan nullified
- Then, EAL would initiate the scan on their behalf. (rte_eal_init)
- Whereas, for those drivers which are 'special' scan, EAL would have to 
call each driver's scan.
- This selection is manual code change (nullifying the scan function).
- And then, EAL would have various 'generic' scan's chained together 
other than driver->scan().

A cleaner model would have been that EAL always calls the drivers->scan().

Obviously, this issue vanishes as soon as we have the bus->scan() like 
implementation where a bus would represent multiple devices/drivers.

_
Shreyansh

[dpdk-dev] pmdinfogen issues: cross compilation for ARM fails with older host compiler

[Hemant Agrawal]

Hi Neil,
   Pmdinfogen compiles with host compiler. It usages 
rte_byteorder.h of the target platform.
However, if the host compiler is older than 4.8, it will be an issue during 
cross compilation for some platforms.
e.g. if we are compiling on x86 host for ARM, x86 host compiler will not 
understand the arm asm instructions.

/* fix missing __builtin_bswap16 for gcc older then 4.8 */
#if !(__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8))
static inline uint16_t rte_arch_bswap16(uint16_t _x)
{
   register uint16_t x = _x;
   asm volatile ("rev16 %0,%1"
: "=r" (x)
: "r" (x)
);
   return x;
}
#endif

One easy solution is that we add compiler platform check in this code section 
of rte_byteorder.h
e.g
#if !(defined __arm__ || defined __aarch64__)
static inline uint16_t rte_arch_bswap16(uint16_t _x)
{
   return (_x >> 8) | ((_x << 8) & 0xff00);
}
#else ?.

Is there a better way to fix it?

Regards,
Hemant


From: Michael Wildt [mailto:michael.wi...@broadcom.com]
Sent: Wednesday, September 14, 2016 7:18 PM
To: Hemant Agrawal 
Cc: Thomas Monjalon ; users at dpdk.org
Subject: Re: [dpdk-users] Cross compile for ARM64 fails due to librte_vhost and 
pmdinfogen issues

Hi Hemant,

Thanks for the pointer to the 4.9.3 version. Haven't had issues with 4.9.2 but 
good to know.

I gave that one a try and that works as well but as with the 5.3 I have to be 
on a Ubuntu not RHEL6 to make it work.

Thanks,
Michael

On Wed, Sep 14, 2016 at 3:25 AM, Hemant Agrawal mailto:hemant.agrawal at nxp.com>> wrote:
Hi Michael,
One of the problem, I found with Linaro gcc 4.9 toolchain for i686 
(default one), that it seems to be built with older kernel headers (<3.8). This 
usages older linux/vhost.h file.

However, we have not observed this issue with x86_64 based toolchain on 64 bit 
m/c.
 
https://releases.linaro.org/14.11/components/toolchain/binaries/aarch64-linux-gnu/

Regards,
Hemant

> -Original Message-
> From: users [mailto:users-bounces at dpdk.org dpdk.org>] On Behalf Of Michael Wildt
> Sent: Wednesday, September 14, 2016 12:05 AM
> To: Thomas Monjalon mailto:thomas.monjalon at 
> 6wind.com>>
> Cc: users at dpdk.org
> Subject: Re: [dpdk-users] Cross compile for ARM64 fails due to librte_vhost 
> and
> pmdinfogen issues
>
> Hi Thomas,
>
> The Linaro gcc 4.9 is correct when it gets to __GNUC_MINOR__, used a test
> application. Its actually 4.9.2.
>
> Tried a newer Linaro tool chain, turned out to be a bit more complicated since
> that does not work on RHEL6, is however a success. With Linaro 5.3 one can
> cross compile dpdk fine with no errors, though the rte_byteorder.h file still
> points to arm's version, but pmdinfogen builds.
>
> Probably should still fix both issues just to keep the base clean.
>
> At least I have a workaround in the interim.
>
> Thanks for the help.
>
> Thanks,
> Michael
>
>
> On Tue, Sep 13, 2016 at 11:07 AM, Thomas Monjalon
> mailto:thomas.monjalon at 6wind.com>
> > wrote:
>
> > 2016-09-13 07:45, Michael Wildt:
> > > Hi Thomas,
> > >
> > > Appreciate the assistance. Please see inline.
> > >
> > >
> > > On Tue, Sep 13, 2016 at 5:03 AM, Thomas Monjalon <
> > thomas.monjalon at 6wind.com>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > 2016-09-12 22:20, Michael Wildt:
> > > > > I'm attempting to cross compile DPDK on an x86 for an ARM64 target.
> > This
> > > > > fails in the following areas, using latest dpdk as of 9/12. When
> > > > compiling
> > > > > natively there are no issues.
> > > >
> > > > Your analysis below seems good.
> > > > Interestingly, I do not see such error (don't know why).
> > > > Please could you share the commands you are using?
> > > >
> > >
> > > Sure can.
> > >
> > > make config T=arm64-armv8a-linuxapp-gcc CROSS=/projects/ccxsw/
> > > toolchains/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux/
> > bin/aarch64-linux-gnu-
> > > ARCH=arm64
> > >
> > > make T=arm64-armv8a-linuxapp-gcc CROSS=/projects/ccxsw/
> > > toolchains/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux/
> > bin/aarch64-linux-gnu-
> > > ARCH=arm64 RTE_KERNELDIR=/projects/kernel
> > >
> > > > > - librte_vhost, fails with:
> > > > >
> > > > > /projects/dpdk_latest/lib/librte_vhost/vhost_user/virtio-
> > > > net-user.c:250:23:
> > > > > error: array subscript is above array bounds [-Werror=array-bounds]
> > > > >rvq = dev->virtqueue[i * VIRTIO_QNUM + VIRTIO_RXQ];
> > > > [...]
> > > > > - buildtools/pmdinfogen, fails with:
> > > > >
> > > > > == Build buildtools/pmdinfogen
> > > > >   HOSTCC pmdinfogen.o
> > > > > /projects/dpdk_test_wget/dpdk-16.07/build/include/rte_byteorder.h:
> > > > > Assembler messages:
> > > > > /projects/dpdk_test_wget/dpdk-16.07/build/include/rte_
> > byteorder.h:53:
> > > > > Error: no such instruction: `rev16 

[dpdk-dev] [PATCH] mempool: Free memzone if mempool populate phys fails

[Thomas Monjalon]

2016-11-11 20:12, Hemant Agrawal:
> From: Nipun Gupta 
> 
> This fixes the issue of memzone not being freed, if the
> rte_mempool_populate_phys fails in the rte_mempool_populate_default
> 
> This issue was identified when testing with OVS ~2.6
> - configure the system with low memory (e.g. < 500 MB)
> - add bridge and dpdk interfaces
> - delete brigde
> - keep on repeating the above sequence.
> 
> Signed-off-by: Nipun Gupta 

You forgot the "Fixes:" line to give a tip on the release introducing this bug.

[dpdk-dev] [PATCH] ethdev: check number of queues less than RTE_ETHDEV_QUEUE_STAT_CNTRS

[Thomas Monjalon]

2016-11-11 09:16, Alejandro Lucero:
> Thomas,
> 
> We are wondering if you realize this patch fixes a bug with current ethdev
> code as a device can have more than RTE_ETHDEV_QUEUE_STAT_CNTRS.
> 
> Maybe the commit message is giving the wrong impression and as you
> commented, it should just focus on the bug it fixes and to leave for
> another email thread the discussion of how to solve the
> RTE_ETHDEV_QUEUE_STAT_CNTRS
> problem.
> 
> Should we remove this from patchwork and to send another patch that way?

Yes please. It was my first comment, we don't understand the exact issue
you are fixing.
And I have a bad feeling it could break something else (really just a feeling).
It is not the kind of patch we can apply the last day of a release.
That's why I think it should wait 17.02.

Of course you can try to convince me and others to apply it as a last minute
patch. But why are you sending a patch on the generic API in the last days?

Last argument: it is not fixing a regression of 16.11, so it is not so urgent.

[dpdk-dev] [PATCH] doc: add sub-repositories information

[Mcnamara, John]

> -Original Message-
> From: Yigit, Ferruh
> Sent: Thursday, November 10, 2016 5:27 PM
> To: dev at dpdk.org
> Cc: Mcnamara, John ; Thomas Monjalon
> 
> Subject: [PATCH] doc: add sub-repositories information
> 
> DPDK switched to main and sub-repositories approach, this patch documents
> new approach and updates development process according.
> 
> Signed-off-by: Ferruh Yigit 

Acked-by: John McNamara 

[dpdk-dev] [PATCH v4] latencystats: added new library for latency stats

[Remy Horton]

On 07/11/2016 21:14, Reshma Pattan wrote:
[..]
 > Signed-off-by: Reshma Pattan 

Reviewed-by: Remy Horton 


 > +static void
 > +metrics_display(int port_id)
 > +{
 > +struct rte_stat_value *stats;
 > +struct rte_metric_name *names;

Note that rte_stats_value is being renamed to rte_metric_value in the 
next version of the metrics library..


 > +int
 > +rte_latencystats_init(uint64_t samp_intvl,
 > +rte_latency_stats_flow_type_fn user_cb)
 > +{

Far as I can tell, user_cb is always NULL, and the two callbacks it 
eventually get passed to don't use it. There any reason the function 
signature has it at all?


 > +++ b/lib/librte_latencystats/rte_latencystats_version.map
 > @@ -0,0 +1,10 @@
 > +DPDK_16.11 {

This will need to change to 17.02 once new release cycle starts. :)

Will also need to add entry to release_17_02.rst once it becomes available..

..Remy

[dpdk-dev] [PATCH] doc: remove iomem and ioport handling in igb_uio

[Remy Horton]

On 22/09/2016 13:44, Jianfeng Tan wrote:
[..]
>
> Suggested-by: Yigit, Ferruh 
> Signed-off-by: Jianfeng Tan 

Acked-by: Remy Horton 


> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -57,3 +57,8 @@ Deprecation Notices
>  * API will change for ``rte_port_source_params`` and ``rte_port_sink_params``
>structures. The member ``file_name`` data type will be changed from
>``char *`` to ``const char *``. This change targets release 16.11.

As an aside I don't think changing a structure entry to const will 
affect its binary layout, so this ought not be an ABI break..

[dpdk-dev] [PATCH v2] net/qede: fix unknown speed errmsg for 25G link

[Harish Patil]

- Fix to use bitmapped values in NVM configuration for speed capability
  advertisement. This issue is specific to 25G NIC since it is capable
  of 25G and 10G speeds.

- Update feature list.

Fixes: 64c239b7f8b7 ("net/qede: fix advertising link speed capability")

Signed-off-by: Harish Patil 
---
 config/common_base   |  2 +-
 doc/guides/nics/features/qede.ini|  1 +
 doc/guides/nics/features/qede_vf.ini |  1 +
 doc/guides/nics/qede.rst |  2 +-
 drivers/net/qede/qede_ethdev.c   | 15 ++-
 drivers/net/qede/qede_if.h   |  2 +-
 drivers/net/qede/qede_main.c | 25 ++---
 7 files changed, 21 insertions(+), 27 deletions(-)

diff --git a/config/common_base b/config/common_base
index 21d18f8..4bff83a 100644
--- a/config/common_base
+++ b/config/common_base
@@ -315,7 +315,7 @@ CONFIG_RTE_LIBRTE_PMD_BOND=y
 CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB=n
 CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB_L1=n

-# QLogic 25G/40G/100G PMD
+# QLogic 10G/25G/40G/100G PMD
 #
 CONFIG_RTE_LIBRTE_QEDE_PMD=y
 CONFIG_RTE_LIBRTE_QEDE_DEBUG_INIT=n
diff --git a/doc/guides/nics/features/qede.ini 
b/doc/guides/nics/features/qede.ini
index 1f3c3f6..7d75030 100644
--- a/doc/guides/nics/features/qede.ini
+++ b/doc/guides/nics/features/qede.ini
@@ -4,6 +4,7 @@
 ; Refer to default.ini for the full list of available PMD features.
 ;
 [Features]
+Speed capabilities   = Y
 Link status  = Y
 Link status event= Y
 MTU update   = Y
diff --git a/doc/guides/nics/features/qede_vf.ini 
b/doc/guides/nics/features/qede_vf.ini
index 1c0f228..acb1b99 100644
--- a/doc/guides/nics/features/qede_vf.ini
+++ b/doc/guides/nics/features/qede_vf.ini
@@ -4,6 +4,7 @@
 ; Refer to default.ini for the full list of available PMD features.
 ;
 [Features]
+Speed capabilities   = Y
 Link status  = Y
 Link status event= Y
 MTU update   = Y
diff --git a/doc/guides/nics/qede.rst b/doc/guides/nics/qede.rst
index b6f54fd..d22ecdd 100644
--- a/doc/guides/nics/qede.rst
+++ b/doc/guides/nics/qede.rst
@@ -71,7 +71,7 @@ Non-supported Features
 Supported QLogic Adapters
 -

-- QLogic FastLinQ QL4 25G/40G/100G CNAs.
+- QLogic FastLinQ QL4 10G/25G/40G/100G CNAs.

 Prerequisites
 -
diff --git a/drivers/net/qede/qede_ethdev.c b/drivers/net/qede/qede_ethdev.c
index 59129f2..d106dd0 100644
--- a/drivers/net/qede/qede_ethdev.c
+++ b/drivers/net/qede/qede_ethdev.c
@@ -647,6 +647,7 @@ qede_dev_info_get(struct rte_eth_dev *eth_dev,
struct qede_dev *qdev = eth_dev->data->dev_private;
struct ecore_dev *edev = >edev;
struct qed_link_output link;
+   uint32_t speed_cap = 0;

PMD_INIT_FUNC_TRACE(edev);

@@ -681,7 +682,19 @@ qede_dev_info_get(struct rte_eth_dev *eth_dev,

memset(, 0, sizeof(struct qed_link_output));
qdev->ops->common->get_link(edev, );
-   dev_info->speed_capa = rte_eth_speed_bitflag(link.adv_speed, 0);
+   if (link.adv_speed & NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_1G)
+   speed_cap |= ETH_LINK_SPEED_1G;
+   if (link.adv_speed & NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_10G)
+   speed_cap |= ETH_LINK_SPEED_10G;
+   if (link.adv_speed & NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_25G)
+   speed_cap |= ETH_LINK_SPEED_25G;
+   if (link.adv_speed & NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_40G)
+   speed_cap |= ETH_LINK_SPEED_40G;
+   if (link.adv_speed & NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_50G)
+   speed_cap |= ETH_LINK_SPEED_50G;
+   if (link.adv_speed & NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_BB_100G)
+   speed_cap |= ETH_LINK_SPEED_100G;
+   dev_info->speed_capa = speed_cap;
 }

 /* return 0 means link status changed, -1 means not changed */
diff --git a/drivers/net/qede/qede_if.h b/drivers/net/qede/qede_if.h
index 4936349..2131fe2 100644
--- a/drivers/net/qede/qede_if.h
+++ b/drivers/net/qede/qede_if.h
@@ -70,7 +70,7 @@ struct qed_link_output {
uint32_t advertised_caps;   /* In ADVERTISED defs */
uint32_t lp_caps;   /* In ADVERTISED defs */
uint32_t speed; /* In Mb/s */
-   uint32_t adv_speed; /* In Mb/s */
+   uint32_t adv_speed; /* Speed mask */
uint8_t duplex; /* In DUPLEX defs */
uint8_t port;   /* In PORT defs */
bool autoneg;
diff --git a/drivers/net/qede/qede_main.c b/drivers/net/qede/qede_main.c
index d2e476c..ab22409 100644
--- a/drivers/net/qede/qede_main.c
+++ b/drivers/net/qede/qede_main.c
@@ -488,7 +488,6 @@ static void qed_fill_link(struct ecore_hwfn *hwfn,
struct ecore_mcp_link_state link;
struct ecore_mcp_link_capabilities link_caps;
uint32_t media_type;
-   uint32_t adv_speed;
uint8_t change = 0;

memset(if_link, 0, sizeof(*if_link));
@@ -516,28 +515,8 @@ static void qed_fill_link(struct ecore_hwfn *hwfn,

if_link->duplex = 

[dpdk-dev] [PATCH] ethdev: check number of queues less than RTE_ETHDEV_QUEUE_STAT_CNTRS

[Alejandro Lucero]

On Fri, Nov 11, 2016 at 9:29 AM, Thomas Monjalon 
wrote:

> 2016-11-11 09:16, Alejandro Lucero:
> > Thomas,
> >
> > We are wondering if you realize this patch fixes a bug with current
> ethdev
> > code as a device can have more than RTE_ETHDEV_QUEUE_STAT_CNTRS.
> >
> > Maybe the commit message is giving the wrong impression and as you
> > commented, it should just focus on the bug it fixes and to leave for
> > another email thread the discussion of how to solve the
> > RTE_ETHDEV_QUEUE_STAT_CNTRS
> > problem.
> >
> > Should we remove this from patchwork and to send another patch that way?
>
> Yes please. It was my first comment, we don't understand the exact issue
> you are fixing.
>

OK


> And I have a bad feeling it could break something else (really just a
> feeling).
> It is not the kind of patch we can apply the last day of a release.
> That's why I think it should wait 17.02.
>
>
Fine.


> Of course you can try to convince me and others to apply it as a last
> minute
> patch. But why are you sending a patch on the generic API in the last days?
>
>
We just found it a couple of days ago.


> Last argument: it is not fixing a regression of 16.11, so it is not so
> urgent.
>

[dpdk-dev] [PATCH] ethdev: check number of queues less than RTE_ETHDEV_QUEUE_STAT_CNTRS

[Alejandro Lucero]

Thomas,

We are wondering if you realize this patch fixes a bug with current ethdev
code as a device can have more than RTE_ETHDEV_QUEUE_STAT_CNTRS.

Maybe the commit message is giving the wrong impression and as you
commented, it should just focus on the bug it fixes and to leave for
another email thread the discussion of how to solve the
RTE_ETHDEV_QUEUE_STAT_CNTRS
problem.

Should we remove this from patchwork and to send another patch that way?


On Thu, Nov 10, 2016 at 4:04 PM, Alejandro Lucero <
alejandro.lucero at netronome.com> wrote:

>
>
> On Thu, Nov 10, 2016 at 4:01 PM, Thomas Monjalon <
> thomas.monjalon at 6wind.com> wrote:
>
>> 2016-11-10 15:43, Alejandro Lucero:
>> > On Thu, Nov 10, 2016 at 2:42 PM, Thomas Monjalon <
>> thomas.monjalon at 6wind.com>
>> > wrote:
>> >
>> > > 2016-11-10 14:00, Alejandro Lucero:
>> > > > From: Bert van Leeuwen 
>> > > >
>> > > > A device can have more than RTE_ETHDEV_QUEUE_STAT_CNTRS queues which
>> > > > is used inside struct rte_eth_stats. Ideally, DPDK should be built
>> with
>> > > > RTE_ETHDEV_QUEUE_STAT_CNTRS to the maximum number of queues a device
>> > > > can support, 65536, as uint16_t is used for keeping those values for
>> > > > RX and TX. But of course, having such big arrays inside struct
>> > > rte_eth_stats
>> > > > is not a good idea.
>> > >
>> > > RTE_ETHDEV_QUEUE_STAT_CNTRS come from a limitation in Intel devices.
>> > > They have limited number of registers to store the stats per queue.
>> > >
>> > > > Current default value is 16, which could likely be changed to 32 or
>> 64
>> > > > without too much opposition. And maybe it would be a good idea to
>> modify
>> > > > struct rte_eth_stats for allowing dynamically allocated arrays and
>> maybe
>> > > > some extra fields for keeping the array sizes.
>> > >
>> > > Yes
>> > > and? what is your issue exactly? with which device?
>> > > Please explain the idea brought by your patch.
>> > >
>> >
>> > Netronome NFP devices support 128 queues and future version will support
>> > 1024.
>> >
>> > A particular VF, our PMD just supports VFs, could get as much as 128.
>> > Although that is not likely, that could be an option for some client.
>> >
>> > Clients want to use a DPDK coming with a distribution, so changing the
>> > RTE_ETHDEV_QUEUE_STAT_CNTRS depending on the present devices is not an
>> > option.
>> >
>> > We would be happy if RTE_ETHDEV_QUEUE_STAT_CNTRS could be set to 1024,
>> > covering current and future requirements for our cards, but maybe having
>> > such big arrays inside struct rte_eth_stats is something people do not
>> want
>> > to have.
>> >
>> > A solution could be to create such arrays dynamically based on the
>> device
>> > to get the stats from. For example, call to rte_eth_dev_configure could
>> > have ax extra field for allocating a rte_eth_stats struct, which will be
>> > based on nb_rx_q and nb_tx_q params already given to that function.
>> >
>> > Maybe the first thing to know is what people think about just
>> incrementing
>> > RTE_ETHDEV_QUEUE_STAT_CNTRS to 1024.
>> >
>> > So Thomas, what do you think about this?
>>
>> I think this patch is doing something else :)
>>
>>
> Sure. But the problem the patch solves is pointing to this, IMHO, bigger
> issue.
>
>
>> I'm not sure what is better between big arrays and variable size.
>> I think you must explain these 2 options in another thread,
>> because I'm not sure you will have enough attention in a thread starting
>> with
>> "check number of queues less than RTE_ETHDEV_QUEUE_STAT_CNTRS".
>>
>
> Agree. I'll do that then.
>
> Thanks
>

[dpdk-dev] [PATCH] maintainers: claim responsability for xen

[Tan, Jianfeng]

Hi Thomas and Konrad,


On 11/11/2016 2:59 AM, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 9, 2016 at 5:03 PM, Thomas Monjalon
>  wrote:
>> 2016-11-07 07:38, Jianfeng Tan:
>>> As some users are still using xen as the hypervisor, I suggest to
>>> continue support for xen in DPDK. And from 16.11, I will be the
>>> maintainer of all xen-related files.
>>>
>>> Signed-off-by: Jianfeng Tan 
>> Applied
>>
>> Please Jianfeng, could you start your new role by sending a status
>> of Xen dom0 support in DPDK? I think there are some issues in latest 
>> releases.

Yes, I'm on this. And hope to send out update in the next week.

>>
> Pls also CC me and xen-devel at lists.xenproject.org if possible.

Glad to do that.

Thanks,
Jianfeng

>
> Thanks!

[dpdk-dev] [PATCH] net/ixgbe: fix link never come up problem with x552

[Thomas Monjalon]

> > From: zhao wei 
> > 
> > The links never coming up with DPDK16.11 when bring up x552 NIC, device id 
> > is
> > 15ac.This is caused by delete some code which casing removes X550em SFP iXFI
> > setup for the drivers in function ixgbe_setup_mac_link_sfp_x550em().Fix
> > methord is recover the deleted code.
> > 
> > Fixes: 1726b9cd9c40 ("net/ixgbe/base: remove X550em SFP iXFI setup")
> > 
> > Signed-off-by: zhao wei 
> Acked-by: Wenzhuo Lu 
> Thanks for the patch. It's a critical issue. We need to fix it. I'll report 
> it to our kernel driver developers.

Applied, thanks

[dpdk-dev] [PATCH 0/2] net/thunderx: add 83xx SoC support

[Thomas Monjalon]

2016-11-08 12:01, Jerin Jacob:
> CN83xx is 24 core version of ThunderX ARMv8 SoC with integrated
> octeon style packet and crypto accelerators.
> 
> The standard NIC block used in 88xx/81xx also included in 83xx.
> This patchset adds support for existing standard NIC block on 83xx by
> adding new HW capability flag to select the difference in runtime.
> 
> Jerin Jacob (2):
>   net/thunderx: disable l3 alignment pad feature
>   net/thunderx: add cn83xx support

Applied, thanks

[dpdk-dev] [PATCH v3] doc: arm64: document DPDK application profiling methods

[Thomas Monjalon]

> > Signed-off-by: Jerin Jacob 
> > Signed-off-by: John McNamara 
> 
> Acked-by: Jianbo Liu 

Applied, thanks

[dpdk-dev] [PATCH] doc: postpone ABI changes for Tx prepare

[Thomas Monjalon]

> > The changes for the feature "Tx prepare" should be made in version 17.02.
> > 
> > Signed-off-by: Thomas Monjalon 
> 
> Acked-by: Tomasz Kulasek 

Applied

[dpdk-dev] [PATCH] doc: move testpmd guide with other tools

[Thomas Monjalon]

2016-11-10 23:18, Wiles, Keith:
> > On Nov 10, 2016, at 5:02 PM, Thomas Monjalon  
> > wrote:
> > 2016-11-10 16:11, Mcnamara, John:
> >> The problem is that TestPMD is a bit of an outlier. It isn't a sample 
> >> application and it isn't really a test application despite the name (it is 
> >> more of a tester application). Also I don't think that it is a 
> >> tool/utility like the other apps in the target directory (if it is seen as 
> >> a tool then it should be renamed to something like dpdk-tester for 
> >> consistency). Testpmd also has quite a lot of documentation, more than any 
> >> of our other apps or utilities, which again makes it an outlier.
> > 
> > Yes testpmd is not the same kind of tool as others. It helps for tests,
> > debugging and demos.
> > 
> > About the name, as it is packaged as part of the runtime, I think we should
> > find a better name. As you said it should start with "dpdk-" and it should
> > contain "net" as it does not test the crypto drivers.
> > Something like dpdk-testpmd-net.
> 
> To me the name dpdk-testpmd-net is a bit long and does testpmd really just 
> test PMDs. I was thinking of the name dpdk-tester is really pretty short and 
> descriptive IMO. Adding net or pmd to the name does not really add anything 
> as dpdk is kind of networking. Just my $0.04 worth. 

I tend to agree. dpdk-tester is not so bad.
So this application could be able to test the crypto engines?

[dpdk-dev] [PATCH] doc: fix l3fwd mode selection from compile to run time

[Thomas Monjalon]

> > The l3fwd application route lookup mode can be selected at run time but
> > not at compile time. This patch corrects the statement in the doc.
> > 
> > Fixes: d0dff9ba ("doc: sample application user guide")
> > 
> > Signed-off-by: Reshma Pattan 
> 
> Acked-by: John McNamara 


Applied, thanks