Re: [dpdk-dev] [PATCH 2/2] app/testpmd: fix hot-unplug detaching

[Matan Azrad]

Hi Thomas

Thanks for the patches, I Saw it just now.
 please see small comment below:

 From: Thomas Monjalon
> There is a possible race condition in the hotplug path in rmv_port_callback().
> If a port is created between
> close_port(port_id) and detach_port_device(port_id), then the port_id will
> have been reallocated to a different device which will be wrongly detached.
> 
> Since a check was added in detach_port_device() for manual detach case,
> the hotplug path was even more broken.
> It became impossible to run because the new check prevented to run
> detach_port_device() after the port is closed.
> 
> The solution for both issues is to not rely on the port_id for detaching the
> rte_device.
> The function detach_port_device() is split to allow calling
> detach_device() directly with the rte_device pointer, saved before closing
> the port.
> 
> Fixes: 43d0e304980a ("app/testpmd: fix invalid port detaching")

If you fix the race, Don't you think you need to add fixes line for the patch 
which created the race?

> Cc: sta...@dpdk.org
> 
> Signed-off-by: Thomas Monjalon 
> ---
>  app/test-pmd/testpmd.c | 48 --
>  1 file changed, 28 insertions(+), 20 deletions(-)
> 
> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
> 11203cb03d..035836adfb 100644
> --- a/app/test-pmd/testpmd.c
> +++ b/app/test-pmd/testpmd.c
> @@ -2633,32 +2633,17 @@ setup_attached_port(portid_t pi)
>   printf("Done\n");
>  }
> 
> -void
> -detach_port_device(portid_t port_id)
> +static void
> +detach_device(struct rte_device *dev)
>  {
> - struct rte_device *dev;
>   portid_t sibling;
> 
> - printf("Removing a device...\n");
> -
> - if (port_id_is_invalid(port_id, ENABLED_WARN))
> - return;
> -
> - dev = rte_eth_devices[port_id].device;
>   if (dev == NULL) {
>   printf("Device already removed\n");
>   return;
>   }
> 
> - if (ports[port_id].port_status != RTE_PORT_CLOSED) {
> - if (ports[port_id].port_status != RTE_PORT_STOPPED) {
> - printf("Port not stopped\n");
> - return;
> - }
> - printf("Port was not closed\n");
> - if (ports[port_id].flow_list)
> - port_flow_flush(port_id);
> - }
> + printf("Removing a device...\n");
> 
>   if (rte_dev_remove(dev) < 0) {
>   TESTPMD_LOG(ERR, "Failed to detach device %s\n", dev-
> >name); @@ -2676,13 +2661,31 @@ detach_port_device(portid_t port_id)
> 
>   remove_invalid_ports();
> 
> - printf("Device of port %u is detached\n", port_id);
> + printf("Device is detached\n");
>   printf("Now total ports is %d\n", nb_ports);
>   printf("Done\n");
>   return;
>  }
> 
>  void
> +detach_port_device(portid_t port_id)
> +{
> + if (port_id_is_invalid(port_id, ENABLED_WARN))
> + return;
> +
> + if (ports[port_id].port_status != RTE_PORT_CLOSED) {
> + if (ports[port_id].port_status != RTE_PORT_STOPPED) {
> + printf("Port not stopped\n");
> + return;
> + }
> + printf("Port was not closed\n");
> + if (ports[port_id].flow_list)
> + port_flow_flush(port_id);
> + }
> +
> + detach_device(rte_eth_devices[port_id].device);
> +}
> +
>  void
>  detach_devargs(char *identifier)
>  {
> @@ -2873,6 +2876,7 @@ rmv_port_callback(void *arg)
>   int need_to_start = 0;
>   int org_no_link_check = no_link_check;
>   portid_t port_id = (intptr_t)arg;
> + struct rte_device *dev;
> 
>   RTE_ETH_VALID_PORTID_OR_RET(port_id);
> 
> @@ -2883,8 +2887,12 @@ rmv_port_callback(void *arg)
>   no_link_check = 1;
>   stop_port(port_id);
>   no_link_check = org_no_link_check;
> +
> + /* Save rte_device pointer before closing ethdev port */
> + dev = rte_eth_devices[port_id].device;
>   close_port(port_id);
> - detach_port_device(port_id);
> + detach_device(dev); /* might be already removed or have more
> ports */
> +
>   if (need_to_start)
>   start_packet_forwarding(0);
>  }
> --
> 2.25.0

Re: [dpdk-dev] [PATCH 2/2] app/testpmd: fix hot-unplug detaching

[Thomas Monjalon]

16/02/2020 09:09, Matan Azrad:
> Hi Thomas
> 
> Thanks for the patches, I Saw it just now.
>  please see small comment below:
> 
>  From: Thomas Monjalon
> > There is a possible race condition in the hotplug path in 
> > rmv_port_callback().
> > If a port is created between
> > close_port(port_id) and detach_port_device(port_id), then the port_id will
> > have been reallocated to a different device which will be wrongly detached.
> > 
> > Since a check was added in detach_port_device() for manual detach case,
> > the hotplug path was even more broken.
> > It became impossible to run because the new check prevented to run
> > detach_port_device() after the port is closed.
> > 
> > The solution for both issues is to not rely on the port_id for detaching the
> > rte_device.
> > The function detach_port_device() is split to allow calling
> > detach_device() directly with the rte_device pointer, saved before closing
> > the port.
> > 
> > Fixes: 43d0e304980a ("app/testpmd: fix invalid port detaching")
> 
> If you fix the race, Don't you think you need to add fixes line for the patch 
> which created the race?

Yes, you're right, I forgot it.
It is too late now unfortunately, but we may request to backport it
properly in 18.11 as well.

Please Kevin, add this tag so it will be part of 18.11:

Fixes: cbb4c648c5df ("ethdev: use device handle to detach")

> > Cc: sta...@dpdk.org

Re: [dpdk-dev] [PATCH v4] net/i40e: relaxed barrier in the tx fastpath

[Thomas Monjalon]

15/02/2020 16:16, Ye Xiaolong:
> s/relaxed/relax
> 
> On 02/12, Gavin Hu wrote:
> >To keep ordering of mixed accesses, rte_cio is sufficient.
> >The rte_io barrier inside the I40E_PCI_REG_WRITE is overkill.[1]
[...]
> 
> Applied to dpdk-next-net-intel with Jerin's Reviewed-by tag, Thanks.

I assume it is too much risky doing such optimization post-rc3.

Ferruh, Xiaolong, you don't plan anymore pull from dpdk-next-net-intel
in 20.02?

Re: [dpdk-dev] [PATCH 0/5] Update docs for installing on FreeBSD

[Thomas Monjalon]

03/01/2020 16:32, Bruce Richardson:
> Update the FreeBSD GSG guide to cover:
> 
> * installing from package as well as via ports collection
> * building and installing manually via meson and ninja
> * building examples using the pkg-config file, since both the port/pkg
>   and building from source use meson.
> * other general tidy-up.
> 
> Bruce Richardson (5):
>   doc: update intro to FreeBSD GSG
>   doc: document installing from FreeBSD package
>   doc: add meson install instructions for FreeBSD
>   doc: update section on loading FreeBSD kernel modules
>   doc: update documentation on build and running FreeBSD apps

Applied, thanks

Re: [dpdk-dev] [PATCH] build: skip processing docs folder if docs disabled

[Thomas Monjalon]

03/01/2020 15:46, Bruce Richardson:
> While each target is set to be ignored if the docs are disabled in the
> meson build, there is little reason to process the docs folder at all.
> 
> Signed-off-by: Bruce Richardson 
> ---
> +if not get_option('enable_docs')
> + subdir_done()
> +endif

Why this patch is marked as superseded in patchwork?

Re: [dpdk-dev] [PATCH v8] doc: add meson ut info in prog guide

[Thomas Monjalon]

12/08/2019 14:40, Jananee Parthasarathy:
> From: Hari Kumar Vemula 
> 
> Add a programmer's guide section for meson ut
> 
> Signed-off-by: Hari Kumar Vemula 
> Acked-by: Bruce Richardson 
> Acked-by: Michael Santana 

The last part about enabling some skipped test case is not correct.
Because this patch is very old, I apply it without this last part:

> +To help find missing libraries, the user can specify additional search paths
> +for those libraries as below:
> +
> +* Single path::
> +
> +  $ export LIBRARY_PATH=path
> +
> +* Multiple paths::
> +
> +  $ export LIBRARY_PATH=path1:path2:path3
> +
> +Some functionality may be disabled due to library headers being missed as 
> part
> +of the build. To specify an additional search path for headers at
> +configuration time, use one of the commands below:
> +
> +*  Single path::
> +
> +   $ CFLAGS=-I/path meson build
> +
> +*  Multiple paths::
> +
> +   $ CFLAGS=`-I/path1 -I/path2 meson build`
> +
> +Below are some examples that show how to export libraries and their header
> +paths.
> +
> +To specify a single library at a time::
> +
> +$ export LIBRARY_PATH=/root/wireless_libs/zuc/
> +$ CFLAGS=-I/root/wireless_libs/zuc/include meson build
> +
> +To specify multiple libraries at a time::
> +
> +$ export LIBRARY_PATH=/path/zuc/:/path/libsso_kasumi/build/
> +$ CFLAGS=-I/path/zuc/include \
> + -I/path/libsso_kasumi/include \
> +  meson build

Re: [dpdk-dev] [PATCH v5] doc: introduce openwrt how-to guide

[Thomas Monjalon]

18/01/2020 06:48, Xiaolong Ye:
> This doc describes how to enable DPDK on Openwrt in both virtual and
> physical x86 environment.
> 
> Signed-off-by: Xiaolong Ye 
> ---
> --- /dev/null
> +++ b/doc/guides/howto/openwrt.rst
> +Enable DPDK on openwrt
> +==
> +
> +This document describes how to enable Data Plane Development Kit (DPDK) on
> +Openwrt in both a virtual and physical x86 environment.

Please take care of the uppercases in OpenWrt.

> +
> +Introduction
> +
> +
> +The OpenWrt project is a Linux operating system targeting embedded devices.
> +Instead of trying to create a single, static firmware, OpenWrt provides a 
> fully
> +writable filesystem with package management. This frees the user from the
> +application selection and configuration provided by the vendor and allows 
> users
> +to customize the device through the use of packages to suit any application. 
> For
> +developers OpenWrt is the framework to build an application without having to
> +build a complete firmware around it. For users is offers full customization
> +to use the device in ways never envisioned.

Why doing marketing for OpenWrt in DPDK doc?
It is a copy paste from https://openwrt.org/
I think it is enough to say OpenWrt is a source-based router OS with package 
management.

> +
> +Pre-requisites
> +~~
> +
> +You need gcc, binutils, bzip2, flex, python3.5+, perl, make, find, grep, 
> diff,
> +unzip, gawk, getopt, subversion, libz-dev and libc headers installed.

These are prerequisites for building, so should be in section below.
Maybe we can just provide a link to the official doc instead.

> +
> +Build OpenWrt
> +-
> +
> +You can obtain OpenWrt image through https://downloads.openwrt.org/releases. 
> To

Please take the habit of splitting lines after a punctuation.

> +fully customize your own OpenWrt, it is highly recommended to build it from
> +the source code. You can clone the OpenWrt source code as follows:
> +
> +.. code-block:: console
> +
> +git clone https://git.openwrt.org/openwrt/openwrt.git
> +
> +OpenWrt configuration
> +~
> +
> +* Select ``x86`` in ``Target System``
> +* Select ``x86_64`` in ``Subtarget``
> +* Select ``Build the OpenWrt SDK`` for cross-compilation environment
> +* Select ``Use glibc`` in ``Advanced configuration options (for developers)``
> +  then ``ToolChain Options`` and ``C Library implementation``
> +
> +Kernel configuration
> +
> +
> +The following configurations should be enabled:
> +
> +* ``CONFIG_UIO=y``

No, UIO is not recommended anymore.

> +* ``CONFIG_HUGETLBFS=y``
> +* ``CONFIG_HUGETLB_PAGE=y``
> +* ``CONFIG_PAGE_MONITOR=y``

Why PAGE_MONITOR?

> +
> +Build steps
> +~~~
> +
> +For detailed OpenWrt build steps, please refer to the
> +`OpenWrt build guide
> +`_.
> +
> +After the build is completed, you can find the images and sdk in
> +``/bin/targets/x86/64-glibc/``.

s/sdk/SDK/

[...]
> +[binaries]
> +c = 'x86_64-openwrt-linux-gcc'
> +cpp = 'x86_64-openwrt-linux-cpp'
> +ar = 'x86_64-openwrt-linux-ar'
> +strip = 'x86_64-openwrt-linux-strip'
> +
> +meson builddir --cross-file openwrt-cross

This is really a good example why meson should allow to override the toolchain 
prefix.
Please work with meson on this topic.

[...]
> +To cross compile with make:
> +
> +.. code-block:: console
> +
> +export STAGING_DIR= sdk>/glibc/openwrt-sdk-x86-64_gcc-8.3.0_glibc.Linux-x86_64/staging_dir
> +export RTE_SDK=`pwd`
> +export RTE_KERNELDIR= Root>/build_dir/target-x86_64_glibc/linux-x86_64/linux-4.19.81/
> +make config T=x86_64-native-linuxapp-gcc
> +make -j 100 CROSS=x86_64-openwrt-linux-gnu-

The make build system should not be documented as it is going to be deprecated.

> +
> +Running DPDK application on OpenWrt
> +---
> +
> +Virtual machine
> +~~~
> +
> +* Extract the boot image
> +
> +.. code-block:: console
> +
> +gzip -d openwrt-x86-64-combined-ext4.img.gz
> +
> +* Launch Qemu
> +
> +.. code-block:: console
> +
> +qemu-system-x86_64 \
> +-cpu host \
> +-smp 8 \
> +-enable-kvm \
> +-M q35 \
> +-m 2048M \
> +-object 
> memory-backend-file,id=mem,size=2048M,mem-path=/tmp/hugepages,share=on \
> +-drive file= folder>/openwrt-x86-64-combined-ext4.img,id=d0,if=none,bus=0,unit=0 \
> +-device ide-hd,drive=d0,bus=ide.0 \
> +-net nic,vlan=0 \
> +-net nic,vlan=1 \
> +-net user,vlan=1 \
> +-display none \
> +
> +
> +Physical machine
> +
> +
> +If you are using a Windows PC, you can use an image writer application such 
> as
> +``Win32 Disk Imager`` and ``Etcher`` to write the OpenWrt image
> +(openwrt-x86-64-combined-ext4.img) to a USB flash driver or SDcard.

If you just buil

Re: [dpdk-dev] [PATCH v1] doc: rework vm power manager user guide

[Thomas Monjalon]

07/01/2020 10:13, David Hunt:
> Review and re-work of vm_power_manager documentation. Hopefully this
> is clearer, easier to follow.
> 
> Signed-off-by: David Hunt 

checkpatch is reporting a typo done several times:
s/virutal/virtual/

> ---
>  .../img/vm_power_mgr_highlevel.svg| 2189 +++--

This high-level diagram is nice but I disagree about having text blocks.
I think images should be image-only and the text can be in .rst.
It will be easier to update.

Thanks

>  .../img/vm_power_mgr_vm_request_seq.svg   | 1455 +--
>  .../sample_app_ug/vm_power_management.rst | 1194 +
>  3 files changed, 2775 insertions(+), 2063 deletions(-)

Re: [dpdk-dev] [PATCH] maintainers: set QoS git tree for some ethdev files

[Thomas Monjalon]

23/01/2020 11:04, Dumitrescu, Cristian:
> From: Thomas Monjalon 
> > 
> > The tree dpdk-next-tm does not exist anymore.
> > Traffic management and metering APIs, which are part of ethdev,
> > can be merged in the existing tree dpdk-next-qos.
> > 
> > Signed-off-by: Thomas Monjalon 
> > ---
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > 
> >  Traffic Management API - EXPERIMENTAL
> >  M: Cristian Dumitrescu 
> > -T: git://dpdk.org/next/dpdk-next-tm
> > +T: git://dpdk.org/next/dpdk-next-qos
> >  F: lib/librte_ethdev/rte_tm*
> > 
> >  Traffic Metering and Policing API - EXPERIMENTAL
> >  M: Cristian Dumitrescu 
> > +T: git://dpdk.org/next/dpdk-next-qos
> >  F: lib/librte_ethdev/rte_mtr*
> 
> Acked-by: Cristian Dumitrescu 

Applied, thanks

Note that there is an overlap between dpdk-next-qos and dpdk-next-net.

Re: [dpdk-dev] [PATCH] build: skip processing docs folder if docs disabled

[David Marchand]

On Sun, Feb 16, 2020 at 11:07 AM Thomas Monjalon  wrote:
>
> 03/01/2020 15:46, Bruce Richardson:
> > While each target is set to be ignored if the docs are disabled in the
> > meson build, there is little reason to process the docs folder at all.
> >
> > Signed-off-by: Bruce Richardson 
> > ---
> > +if not get_option('enable_docs')
> > + subdir_done()
> > +endif
>
> Why this patch is marked as superseded in patchwork?
>

Because there were other series superseding it.
https://patchwork.dpdk.org/project/dpdk/list/?series=8032&state=%2A&archive=both
https://patchwork.dpdk.org/project/dpdk/list/?series=8039&state=%2A&archive=both
https://patchwork.dpdk.org/project/dpdk/list/?series=8056&state=%2A&archive=both

Then after testing and discussion, it was dropped.
http://inbox.dpdk.org/dev/CAJFAV8wNAtWf0a3s=xmqz+itgkgomnybdhtcdn-ihpjnm8y...@mail.gmail.com/


-- 
David Marchand

Re: [dpdk-dev] [PATCH] net/mlx5: add BlueField-2 device ID

[Gavin Hu]

Reviewed-by: Gavin Hu 

Re: [dpdk-dev] [PATCH v4] net/i40e: relaxed barrier in the tx fastpath

[Ye Xiaolong]

Hi, Thomas

On 02/16, Thomas Monjalon wrote:
>15/02/2020 16:16, Ye Xiaolong:
>> s/relaxed/relax
>> 
>> On 02/12, Gavin Hu wrote:
>> >To keep ordering of mixed accesses, rte_cio is sufficient.
>> >The rte_io barrier inside the I40E_PCI_REG_WRITE is overkill.[1]
>[...]
>> 
>> Applied to dpdk-next-net-intel with Jerin's Reviewed-by tag, Thanks.
>
>I assume it is too much risky doing such optimization post-rc3.

Yes, this iss a valid concern, I agree to postpone it to next release.

>
>Ferruh, Xiaolong, you don't plan anymore pull from dpdk-next-net-intel
>in 20.02?

There are still some bug fixing work going on in PRC, so I assume there 
should be some fix patches after RC3, they are still allowed to be merged
to 20.02, if the fix is relatively small in terms of lines of code and scope,
right?


Thanks,
Xiaolong

>
>

Re: [dpdk-dev] [PATCH v5] doc: introduce openwrt how-to guide

[Ye Xiaolong]

Hi, Thomas

Thanks a lot for your detailed review.

On 02/16, Thomas Monjalon wrote:
>18/01/2020 06:48, Xiaolong Ye:
>> This doc describes how to enable DPDK on Openwrt in both virtual and
>> physical x86 environment.
>> 
>> Signed-off-by: Xiaolong Ye 
>> ---
>> --- /dev/null
>> +++ b/doc/guides/howto/openwrt.rst
>> +Enable DPDK on openwrt
>> +==
>> +
>> +This document describes how to enable Data Plane Development Kit (DPDK) on
>> +Openwrt in both a virtual and physical x86 environment.
>
>Please take care of the uppercases in OpenWrt.

Got it, will stick to OpenWrt for all occurrences.

>
>> +
>> +Introduction
>> +
>> +
>> +The OpenWrt project is a Linux operating system targeting embedded devices.
>> +Instead of trying to create a single, static firmware, OpenWrt provides a 
>> fully
>> +writable filesystem with package management. This frees the user from the
>> +application selection and configuration provided by the vendor and allows 
>> users
>> +to customize the device through the use of packages to suit any 
>> application. For
>> +developers OpenWrt is the framework to build an application without having 
>> to
>> +build a complete firmware around it. For users is offers full customization
>> +to use the device in ways never envisioned.
>
>Why doing marketing for OpenWrt in DPDK doc?
>It is a copy paste from https://openwrt.org/
>I think it is enough to say OpenWrt is a source-based router OS with package 
>management.

Just want to gave some basic intro about OpenWrt, but it seems too much.
Will adopt your suggestion in next version.

>
>> +
>> +Pre-requisites
>> +~~
>> +
>> +You need gcc, binutils, bzip2, flex, python3.5+, perl, make, find, grep, 
>> diff,
>> +unzip, gawk, getopt, subversion, libz-dev and libc headers installed.
>
>These are prerequisites for building, so should be in section below.
>Maybe we can just provide a link to the official doc instead.
>

Make sense, will provide the link in next version.

>> +
>> +Build OpenWrt
>> +-
>> +
>> +You can obtain OpenWrt image through 
>> https://downloads.openwrt.org/releases. To
>
>Please take the habit of splitting lines after a punctuation.
>

Will keep this in mind.

>> +fully customize your own OpenWrt, it is highly recommended to build it from
>> +the source code. You can clone the OpenWrt source code as follows:
>> +
>> +.. code-block:: console
>> +
>> +git clone https://git.openwrt.org/openwrt/openwrt.git
>> +
>> +OpenWrt configuration
>> +~
>> +
>> +* Select ``x86`` in ``Target System``
>> +* Select ``x86_64`` in ``Subtarget``
>> +* Select ``Build the OpenWrt SDK`` for cross-compilation environment
>> +* Select ``Use glibc`` in ``Advanced configuration options (for 
>> developers)``
>> +  then ``ToolChain Options`` and ``C Library implementation``
>> +
>> +Kernel configuration
>> +
>> +
>> +The following configurations should be enabled:
>> +
>> +* ``CONFIG_UIO=y``
>
>No, UIO is not recommended anymore.

Got it, will recommend vfio instead.

>
>> +* ``CONFIG_HUGETLBFS=y``
>> +* ``CONFIG_HUGETLB_PAGE=y``
>> +* ``CONFIG_PAGE_MONITOR=y``
>
>Why PAGE_MONITOR?

Good catch, should be CONFIG_PROC_PAGE_MONITOR.

>
>> +
>> +Build steps
>> +~~~
>> +
>> +For detailed OpenWrt build steps, please refer to the
>> +`OpenWrt build guide
>> +`_.
>> +
>> +After the build is completed, you can find the images and sdk in
>> +``/bin/targets/x86/64-glibc/``.
>
>s/sdk/SDK/

Got it.

>
>[...]
>> +[binaries]
>> +c = 'x86_64-openwrt-linux-gcc'
>> +cpp = 'x86_64-openwrt-linux-cpp'
>> +ar = 'x86_64-openwrt-linux-ar'
>> +strip = 'x86_64-openwrt-linux-strip'
>> +
>> +meson builddir --cross-file openwrt-cross
>
>This is really a good example why meson should allow to override the toolchain 
>prefix.

Not sure whether I get your point or not, do you mean meson should support
something like "cross = 'x86_64-openwrt-linux-'" in config file (just like the
CROSS_COMPILE for make build system),  so we don't need to override the build
tools one by one?

>Please work with meson on this topic.

Sure, I guess time is not enough to do it in this release, will plan for
next one.

>
>[...]
>> +To cross compile with make:
>> +
>> +.. code-block:: console
>> +
>> +export STAGING_DIR=> sdk>/glibc/openwrt-sdk-x86-64_gcc-8.3.0_glibc.Linux-x86_64/staging_dir
>> +export RTE_SDK=`pwd`
>> +export RTE_KERNELDIR=> Root>/build_dir/target-x86_64_glibc/linux-x86_64/linux-4.19.81/
>> +make config T=x86_64-native-linuxapp-gcc
>> +make -j 100 CROSS=x86_64-openwrt-linux-gnu-
>
>The make build system should not be documented as it is going to be deprecated.

Got it.

>
>> +
>> +Running DPDK application on OpenWrt
>> +---
>> +
>> +Virtual machine
>> +~~~
>> +
>> +* Extract the boot image
>> +
>> +.. code-block:: console
>> +
>> +  

Re: [dpdk-dev] [PATCH v4] net/i40e: relaxed barrier in the tx fastpath

[Thomas Monjalon]

16/02/2020 17:38, Ye Xiaolong:
> Hi, Thomas
> 
> On 02/16, Thomas Monjalon wrote:
> >15/02/2020 16:16, Ye Xiaolong:
> >> s/relaxed/relax
> >> 
> >> On 02/12, Gavin Hu wrote:
> >> >To keep ordering of mixed accesses, rte_cio is sufficient.
> >> >The rte_io barrier inside the I40E_PCI_REG_WRITE is overkill.[1]
> >[...]
> >> 
> >> Applied to dpdk-next-net-intel with Jerin's Reviewed-by tag, Thanks.
> >
> >I assume it is too much risky doing such optimization post-rc3.
> 
> Yes, this iss a valid concern, I agree to postpone it to next release.
> 
> >
> >Ferruh, Xiaolong, you don't plan anymore pull from dpdk-next-net-intel
> >in 20.02?
> 
> There are still some bug fixing work going on in PRC, so I assume there 
> should be some fix patches after RC3, they are still allowed to be merged
> to 20.02, if the fix is relatively small in terms of lines of code and scope,
> right?

Right

Re: [dpdk-dev] [PATCH v5] doc: introduce openwrt how-to guide

[Thomas Monjalon]

16/02/2020 18:29, Ye Xiaolong:
> On 02/16, Thomas Monjalon wrote:
> >18/01/2020 06:48, Xiaolong Ye:
> >[...]
> >> +[binaries]
> >> +c = 'x86_64-openwrt-linux-gcc'
> >> +cpp = 'x86_64-openwrt-linux-cpp'
> >> +ar = 'x86_64-openwrt-linux-ar'
> >> +strip = 'x86_64-openwrt-linux-strip'
> >> +
> >> +meson builddir --cross-file openwrt-cross
> >
> >This is really a good example why meson should allow to override the 
> >toolchain prefix.
> 
> Not sure whether I get your point or not, do you mean meson should support
> something like "cross = 'x86_64-openwrt-linux-'" in config file (just like the
> CROSS_COMPILE for make build system),  so we don't need to override the build
> tools one by one?

Yes, I think meson should support CROSS_COMPILE environment variable
or a similar config option. I don't see the point of creating a new
config file for each toolchain prefix.


> >> +to /usr/lib64 in OpenWrt.
> >
> >libnuma is not packaged in OpenWrt?
> 
> Unfortunately not, I guess the reason maybe OpenWrt is mainly focused on 
> low-end
> embedded systems which don't have numa support. 

I would be nice to work on it in OpenWrt project then.

Re: [dpdk-dev] [PATCH v5] app/test: fix build when ring PMD is disabled

[Thomas Monjalon]

20/01/2020 18:36, Bruce Richardson:
> On Mon, Dec 23, 2019 at 06:53:05AM +, Reshma Pattan wrote:
> > Some unit tests has dependency on RING PMD,
> > so this patch is trying to fix those and other
> > closely related issues.
> > 
> > 1)pdump, latency, bitrate, ring PMD and test_event_eth_tx_adapter
> > unit tests are dependent on ring PMD, so compile those
> > tests only when ring PMD is enabled else ignore.
> > 
> > 2)get rid of make file error which was added by bond unit test
> > for ring PMD disabled case which is not necessary.
> > 
> > 3)Tx adapter UT is dependent on RING PMD, but it was
> > observed that it was missing from the run in meson
> > build, so added it. TX adapter UT uses 'sw event and
> > 'null' pmd drivers, so for shared builds the drivers .so
> > path has to be passed to the test args of meson UT run.
> > 
> > Fixes: 086eb64db3 ("test/pdump: add unit test for pdump library")
> > Fixes: fdeb30fa71 ("test/bitrate: add unit tests for bitrate library")
> > Fixes: 1e3676a06e ("test/latency: add unit tests for latencystats library")
> > Fixes: 46cf97e4bb ("eventdev: add test for eth Tx adapter")
> > Fixes: d23e09e0ef ("app/test: link with ring pmd when needed")
> > 
> > CC: sta...@dpdk.org
> > CC: Nikhil Rao 
> > CC: Chas Williams 
> > CC: Bruce Richardson 
> > CC: Stephen Hemminger 
> > 
> > Reported-by: Stephen Hemminger 
> > Signed-off-by: Reshma Pattan 
> > ---
> > v5: remove extra blank line.
> > v4: fix event_eth_tx_adapter_autotest for shared build
> > as reported by travis-ci
> > https://travis-ci.com/ovsrobot/dpdk/jobs/249598391
> > v3: add missing test event_eth_tx_adapter_autotest.
> > Add link bonding mode4 test to drivers test.
> > v2: fix comments of v1 and combine the patches 1/2 and 2/2 of v1
> > ---
> 
> Confirmed build now works with disable_drivers=net/ring
> 
> Tested-by: Bruce Richardson 

Applied, thanks

> Unfortunately, other parts fail if other drivers are similarly disabled,
> but that is for another patchset (and probably release!) to fix.

Good to know we are far from retirement ;)

Re: [dpdk-dev] [PATCH] app/test-fib: add test-fib application

[Thomas Monjalon]

11/12/2019 19:45, Vladimir Medvedkin:
> Introduce new application to provide user to evaluate and perform
> custom functional and performance tests for FIB library.
> 
> Signed-off-by: Vladimir Medvedkin 
> ---
>  app/test-fib/Makefile|   21 +
>  app/test-fib/main.c  | 1262 
> ++
>  app/test-fib/meson.build |6 +
>  3 files changed, 1289 insertions(+)

Added files in MAINTAINERS.

Nobody reviewed this app during the release cycle unfortunately,
but I assume it's fined.

Applied, thanks

Re: [dpdk-dev] [PATCH 0/5] l3fwd and lpm cleanups

[Thomas Monjalon]

26/01/2020 02:09, Stephen Hemminger:
> While working on l3fwd, saw some minor things that should be cleaned up.
> 
> Stephen Hemminger (5):
>   lpm: make ipv6 address immutable
>   examples/l3fwd: use RTE_DIM
>   examples/l3fwd: make lookup struct static
>   examples/l3fwd: make route array constant
>   examples/l3fwd: improve readability for destination lookup

Applied (except RTE_DIM patch already applied), thanks.

Re: [dpdk-dev] [PATCH] Documentation errata:RCU_lib.rst and Ring fig 6.10 corrected

[Thomas Monjalon]

03/02/2020 05:56, pratee...@cse.iitb.ac.in:
> From: prateekagarwal88 
> 
> Signed-off-by: prateekagarwal88 

Sorry if the process is a bit hard.
There are 3 requirements for this patch:
- please use your real name (Prateek Agarwal)
- please add a description of the change
- add Honnappa as Cc so he notices your patch and review

Re: [dpdk-dev] [PATCH v2] mempool/octeontx2: optimize for L1D cache architecture

[Thomas Monjalon]

01/02/2020 12:51, Jerin Jacob:
> On Fri, Jan 31, 2020 at 10:53 PM  wrote:
> >
> > From: Pavan Nikhilesh 
> >
> > OCTEON TX2 has 8 sets, 41 ways L1D cache, VA<9:7> bits dictate
> > the set selection.
> > Add additional padding to ensure that the element size always
> > occupies odd number of cachelines to ensure even distribution
> > of elements among L1D cache sets.
> >
> > Signed-off-by: Pavan Nikhilesh 
> > Signed-off-by: Nithin Dabilpuram 
> > Signed-off-by: Vamsi Attunuru 
> > Signed-off-by: Jerin Jacob 
> > ---
> >  v2 Changes:
> >  --
> >  - Fix 32bit build break.
> 
> Acked-by: Jerin Jacob 
> 
> Delegated the patch to Thomas as it has come through the main tree.

Applied, thanks

Re: [dpdk-dev] [dpdk-stable] [PATCH] usertools: fix syntax warning in python 3.8

[Thomas Monjalon]

12/02/2020 13:31, Thomas Faivre:
> Silent the following warning when running script with python 3.8:
> 
> > /usr/bin/dpdk-pmdinfo:542: SyntaxWarning: "is" with a literal.
> > Did you mean "=="?
> >   if (autoload_path is None or autoload_path is ""):
> 
> As autoload_path can only be None or a string, directly check its bool
> value.
> 
> Fixes: c67c9a5c646a ("tools: query binaries for HW and other support 
> information")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Thomas Faivre 

Applied, thanks

Re: [dpdk-dev] [PATCH v2] usertools: fix telemetry python3 compatibility

[Thomas Monjalon]

24/01/2020 11:11, Laatz, Kevin:
> > The client script for use with the telemetry library did not support
> > Python3, as the data being sent over the socket was in string format.
> > Python3 requires the data be explicitly converted to bytes before being
> > sent. Similarily, the received bytes need to be decoded into string
> > format.
> > 
> > Fixes: 53f293c9a783 ("usertools: replace unsafe input function")
> > Fixes: fe35622659ed ("usertools: fix telemetry client with python 3")
> > Fixes: d1b94da4a4e0 ("usertools: add client script for telemetry")
> > Fixes: 4080e46c8078 ("telemetry: support global metrics")
> > Cc: andrius.sir...@intel.com
> > Cc: robin.ja...@6wind.com
> > Cc: reshma.pat...@intel.com
> > Cc: sta...@dpdk.org
> > 
> > Signed-off-by: Ciara Power 
> > Reviewed-by: Robin Jarry 
> > 
> 
> 
> Acked-by: Kevin Laatz 

Applied, thanks

[dpdk-dev] [dpdk-announce] release candidate 20.02-rc3

[Thomas Monjalon]

A new DPDK release candidate is ready for testing:
https://git.dpdk.org/dpdk/tag/?id=v20.02-rc3
121 patches were integrated.

The release notes so far:
http://doc.dpdk.org/guides/rel_notes/release_20_02.html
Some deprecation notices might be added if reviewed on time.

The -rc4 will include only bug fixes, doc and tooling.
This next milestone is expected during next week.
Please hurry up to do the last checks and bug fixes.
You may share some release validation results
by replying to this message (at dev@dpdk.org).

If you are preparing the next release cycle, please send your v1 patches
before the 20.05 proposal deadline, which will happen on March 18th.
It is also time to build an estimated roadmap for the next cycles.

Thank you everyone

[dpdk-dev] Bug Report

[980680431]

static int
test_timer_perf(void)
{
       .
       .
       .
       rte_timer_stop(&tms[0]);
  
rte_free(tms);
return 0;
}


REGISTER_TEST_COMMAND(timer_perf_autotest, test_timer_perf);

Re: [dpdk-dev] Windows Draft Build

[Dmitry Kozlyuk]

Hi,

> "Dpdk.sln" builds OK, will try launching sample apps
> a bit later.

Netuio driver consistently fails to install on Windows 10 in QEMU with
virtio-net (modern interface). Described below is my attempt to install the
driver from clean "windpdk-v18.08-clang" branch of "dpdk-draft-windows" repo.
The only change is hardware ID in INF file. What am I doing wrong here?

1. QEMU version: 4.2.0

QEMU command line:

qemu-system-x86_64 \
-enable-kvm \
-cpu host -smp 'cores=4,sockets=1,threads=1' \
-m 6G \
-drive "file=$disk,format=qcow2" \
-nic "user,id=winnet,model=e1000,smb=$HOME/src/dpdk" \
-netdev 'socket,listen=:1,id=dp0' -device 
'virtio-net-pci,disable-modern=off,disable-legacy=on,netdev=dp0' \
-netdev 'socket,listen=:10001,id=dp1' -device 
'virtio-net-pci,disable-modern=off,disable-legacy=on,netdev=dp1' \
\
-vga qxl


2. Loading unsigned drivers is enabled as follows:

 Microsoft Windows [Version 10.0.18363.418]
 (c) 2019 Microsoft Corporation. All rights reserved.

 Z:\>bcdedit.exe -set loadoptions DISABLE_INTEGRITY_CHECKS
 The operation completed successfully.

 Z:\>bcdedit.exe -set TESTSIGNING ON
 The operation completed successfully.

 Z:\>shutdown -r -t 0

After that, the desktop message shows:

 Test Mode
 Windows 10 Pro
 Build 18362.19h1_release.190318-1202

Including this step FTR, it works for other drivers.


3. Device status (no conflicting drivers):

 The drivers for this device are not installed. (Code 28)

 There are no compatible drivers for this device.


 To find a driver for this device, click Update Driver.

Device event log (note the hardware ID part):

 Device PCI\VEN_1AF4&DEV_1041&SUBSYS_11001AF4&REV_01\3&13c0b0c5&0&20
 requires further installation.


4. INF file is modified to include corresponding hardware ID:

diff --git a/kernel/windows/netuio/netuio.inf b/kernel/windows/netuio/netuio.inf
index b1696cc50..b6fd2c798 100644
--- a/kernel/windows/netuio/netuio.inf
+++ b/kernel/windows/netuio/netuio.inf
@@ -55,6 +55,7 @@ DriverVer=
 %F158B.netuio.Description%=netuio_Device, PCI\VEN_8086&DEV_158B   ; 
I40E_DEV_ID_25G_SFP28
 %F37D0.netuio.Description%=netuio_Device, PCI\VEN_8086&DEV_37D0
 %F153B.netuio.Description%=netuio_Device, PCI\VEN_8086&DEV_153B
+%virtio.netuio.Description%=netuio_Device, 
PCI\VEN_1AF4&DEV_1041&SUBSYS_11001AF4&REV_01
 
 [netuio_Device.NT]
 CopyFiles=Drivers_Dir
@@ -121,5 +122,6 @@ F158A.netuio.Description = "DPDK netUIO for Intel(R) 
Ethernet Network Adapter XX
 F158B.netuio.Description = "DPDK netUIO for Intel(R) Ethernet Network Adapter 
XXV710-DA1"
 F37D0.netuio.Description = "DPDK netUIO for Intel(R) Ethernet Connection X722"
 F153B.netuio.Description = "DPDK netUIO for Intel(R) Ethernet Connection 
I217-V"
+virtio.netuio.Description = "DPDK netUIO for virtio-net (modern)"
 netuio.DeviceDesc = "netuio Device"
 netuio.SVCDESC = "netuio Service"


5. Installation command fails after waiting for several minutes:

 Z:\>pnputil /add-driver Z:\windows\x64\Debug\netuio\netuio\netuio.inf 
/install
 Microsoft PnP Utility

 Adding driver package:  netuio.inf
 Driver package added successfully.
 Published Name: oem2.inf
 Unable to install driver package: This operation returned because the 
timeout period expired.

 Total driver packages:  1
 Added driver packages:  0

 Z:\>

Please find "C:\Windows\INF\setupapi.dev.log" attached as 
"clean_setupapi.dev.log".
Using devcon.exe from DDK yields similar result and log.

I also tried to add event tracing to the driver, but the driver doesn't even
get loaded, that is, DriverEntry is never called, so the cause shouldn't be
in driver code.


> I'm planning to use QEMU and virtio PMD (modern interface,
> because legacy uses PIO, which is not implemented by netuio) by adding a
> project similar to existing "librte_pmd_i40e".

Also tried doing this, attaching patches. Got the same result.

I start every new attempt to install a driver variant from clean system
restored from disk snapshot. "Userpci" driver from my port installs and binds
OK, so this is not an QEMU/Windows incompatibility issue.

-- 
Dmitry Kozlyuk

Re: [dpdk-dev] [PATCH v5] doc: introduce openwrt how-to guide

[Ye Xiaolong]

On 02/16, Thomas Monjalon wrote:
>16/02/2020 18:29, Ye Xiaolong:
>> On 02/16, Thomas Monjalon wrote:
>> >18/01/2020 06:48, Xiaolong Ye:
>> >[...]
>> >> +[binaries]
>> >> +c = 'x86_64-openwrt-linux-gcc'
>> >> +cpp = 'x86_64-openwrt-linux-cpp'
>> >> +ar = 'x86_64-openwrt-linux-ar'
>> >> +strip = 'x86_64-openwrt-linux-strip'
>> >> +
>> >> +meson builddir --cross-file openwrt-cross
>> >
>> >This is really a good example why meson should allow to override the 
>> >toolchain prefix.
>> 
>> Not sure whether I get your point or not, do you mean meson should support
>> something like "cross = 'x86_64-openwrt-linux-'" in config file (just like 
>> the
>> CROSS_COMPILE for make build system),  so we don't need to override the build
>> tools one by one?
>
>Yes, I think meson should support CROSS_COMPILE environment variable
>or a similar config option. I don't see the point of creating a new
>config file for each toolchain prefix.

Totally agree, I would try to work on this to make it happen.

>
>
>> >> +to /usr/lib64 in OpenWrt.
>> >
>> >libnuma is not packaged in OpenWrt?
>> 
>> Unfortunately not, I guess the reason maybe OpenWrt is mainly focused on 
>> low-end
>> embedded systems which don't have numa support. 
>
>I would be nice to work on it in OpenWrt project then.

Make sense, I would submit a request to OpenWrt project.

Thanks,
Xiaolong

>
>
>

[dpdk-dev] [PATCH v3] examples/tep_term: remove redundant info get

[Xiaoyun Li]

Removed redundant function call of 'rte_eth_dev_info_get()' since it has
already been called earlier.

Coverity issue: 349922
Fixes: 2bb43bd4350a ("examples/tep_term: add TSO offload configuration")
Cc: sta...@dpdk.org

Signed-off-by: Xiaoyun Li 
---
 examples/tep_termination/vxlan_setup.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/examples/tep_termination/vxlan_setup.c 
b/examples/tep_termination/vxlan_setup.c
index eca119a72..4b44ccc14 100644
--- a/examples/tep_termination/vxlan_setup.c
+++ b/examples/tep_termination/vxlan_setup.c
@@ -194,8 +194,6 @@ vxlan_port_init(uint16_t port, struct rte_mempool 
*mbuf_pool)
ports_eth_addr[port].addr_bytes[5]);
 
if (tso_segsz != 0) {
-   struct rte_eth_dev_info dev_info;
-   rte_eth_dev_info_get(port, &dev_info);
if ((dev_info.tx_offload_capa & DEV_TX_OFFLOAD_TCP_TSO) == 0)
RTE_LOG(WARNING, PORT,
"hardware TSO offload is not supported\n");
-- 
2.17.1

Re: [dpdk-dev] [PATCH v2] examples/tep_term: fix return value check

[Li, Xiaoyun]

Hi

> -Original Message-
> From: David Marchand [mailto:david.march...@redhat.com]
> Sent: Thursday, February 13, 2020 22:57
> To: Li, Xiaoyun 
> Cc: Ye, Xiaolong ; Kovacevic, Marko
> ; dev ; dpdk stable
> 
> Subject: Re: [dpdk-dev] [PATCH v2] examples/tep_term: fix return value check
> 
> On Mon, Feb 10, 2020 at 8:05 AM Xiaoyun Li  wrote:
> >
> > Added return value check for 'rte_eth_dev_info_get()'.
> >
> > Coverity issue: 349922
> > Fixes: 2bb43bd4350a ("examples/tep_term: add TSO offload
> > configuration")
> 
> rte_eth_dev_info_get() prototype changed in 19.11.
> Before this, it was a void.
> So this Fixes: line is wrong.
> 
> 
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Xiaoyun Li 
> > ---
> >  examples/tep_termination/vxlan_setup.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/examples/tep_termination/vxlan_setup.c
> > b/examples/tep_termination/vxlan_setup.c
> > index eca119a72..f8385b690 100644
> > --- a/examples/tep_termination/vxlan_setup.c
> > +++ b/examples/tep_termination/vxlan_setup.c
> > @@ -195,7 +195,9 @@ vxlan_port_init(uint16_t port, struct rte_mempool
> > *mbuf_pool)
> >
> > if (tso_segsz != 0) {
> > struct rte_eth_dev_info dev_info;
> > -   rte_eth_dev_info_get(port, &dev_info);
> > +   retval = rte_eth_dev_info_get(port, &dev_info);
> > +   if (retval != 0)
> > +   return retval;
> > if ((dev_info.tx_offload_capa & DEV_TX_OFFLOAD_TCP_TSO) == 
> > 0)
> > RTE_LOG(WARNING, PORT,
> > "hardware TSO offload is not
> > supported\n");
> 
> I had a look at this function, dev_info is populated for port earlier in the 
> function,
> why do we need to check it again?
> https://git.dpdk.org/dpdk/tree/examples/tep_termination/vxlan_setup.c?h=v20
> .02-rc2#n119

Yes. I saw it too. And since it only uses tx_offload_capa which is fixed nic 
capability, I think can use dev_info directly without calling 
rte_eth_dev_info_get again.
Will send v3 as that. Then the fix line should be the same as this patch too.

Thanks.
> 
> 
> --
> David Marchand

[dpdk-dev] [PATCH] eal/windows: fix out-of-memory check

[Dmitry Kozlyuk]

Check vsnprintf() result to prevent calling malloc() with negative size.
Check actual malloc() result and terminate asprintf() with documented
error code to prevent the use of NULL pointer.

Fixes: e8428a9d8 ("eal/windows: add some basic functions and macros")

Signed-off-by: Dmitry Kozlyuk 
---
 lib/librte_eal/windows/eal/include/rte_os.h | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/lib/librte_eal/windows/eal/include/rte_os.h 
b/lib/librte_eal/windows/eal/include/rte_os.h
index 9e762617b..69e8f4733 100644
--- a/lib/librte_eal/windows/eal/include/rte_os.h
+++ b/lib/librte_eal/windows/eal/include/rte_os.h
@@ -66,10 +66,12 @@ asprintf(char **buffer, const char *format, ...)
va_start(arg, format);
size = vsnprintf(NULL, 0, format, arg) + 1;
va_end(arg);
+   if (size < 0)
+   return -1;
 
*buffer = malloc(size);
-   if (buffer == NULL)
-   printf("Cannot allocate memory");
+   if (*buffer == NULL)
+   return -1;
 
va_start(arg, format);
ret = vsnprintf(*buffer, size, format, arg);
-- 
2.25.0

[dpdk-dev] [PATCH v6] doc: introduce openwrt how-to guide

[Xiaolong Ye]

This doc describes how to enable DPDK on Openwrt in both virtual and
physical x86 environment.

Signed-off-by: Xiaolong Ye 
Acked-by: John McNamara 
---

V6 changes:

1. addressed review comments raised by Thomas

V5 changes:

1. improve the doc's grammar and wording according to John's
suggestions.

V4 changes:

1. add release notes

V3 changes:

1. emphasize target select in `OpenWrt configuration` section

V2 changes:

1. add meson build steps for dpdk
2. replace steps about build openwrt and running dpdk application with
links


 doc/guides/howto/index.rst |   1 +
 doc/guides/howto/openwrt.rst   | 163 +
 doc/guides/rel_notes/release_20_02.rst |   5 +
 3 files changed, 169 insertions(+)
 create mode 100644 doc/guides/howto/openwrt.rst

diff --git a/doc/guides/howto/index.rst b/doc/guides/howto/index.rst
index a4c131652..5a97ea508 100644
--- a/doc/guides/howto/index.rst
+++ b/doc/guides/howto/index.rst
@@ -19,3 +19,4 @@ HowTo Guides
 packet_capture_framework
 telemetry
 debug_troubleshoot
+openwrt
diff --git a/doc/guides/howto/openwrt.rst b/doc/guides/howto/openwrt.rst
new file mode 100644
index 0..6081f057b
--- /dev/null
+++ b/doc/guides/howto/openwrt.rst
@@ -0,0 +1,163 @@
+..  SPDX-License-Identifier: BSD-3-Clause
+Copyright(c) 2019 Intel Corporation.
+
+Enable DPDK on OpenWrt
+==
+
+This document describes how to enable Data Plane Development Kit (DPDK) on
+OpenWrt in both a virtual and physical x86 environment.
+
+Introduction
+
+
+The OpenWrt project is a well-known source-based router OS which provides a
+fully writable filesystem with package management.
+
+Build OpenWrt
+-
+
+You can obtain OpenWrt image through https://downloads.openwrt.org/releases.
+To fully customize your own OpenWrt, it is highly recommended to build it from
+the source code. You can clone the OpenWrt source code as follows:
+
+.. code-block:: console
+
+git clone https://git.openwrt.org/openwrt/openwrt.git
+
+OpenWrt configuration
+~
+
+* Select ``x86`` in ``Target System``
+* Select ``x86_64`` in ``Subtarget``
+* Select ``Build the OpenWrt SDK`` for cross-compilation environment
+* Select ``Use glibc`` in ``Advanced configuration options (for developers)``
+  then ``ToolChain Options`` and ``C Library implementation``
+
+Kernel configuration
+
+
+The following configurations should be enabled:
+
+* ``CONFIG_VFIO_IOMMU_TYPE1=y``
+* ``CONFIG_VFIO_VIRQFD=y``
+* ``CONFIG_VFIO=y``
+* ``CONFIG_VFIO_NOIOMMU=y``
+* ``CONFIG_VFIO_PCI=y``
+* ``CONFIG_VFIO_PCI_MMAP=y``
+* ``CONFIG_HUGETLBFS=y``
+* ``CONFIG_HUGETLB_PAGE=y``
+* ``CONFIG_PROC_PAGE_MONITOR=y``
+
+Build steps
+~~~
+
+For detailed OpenWrt build steps and prerequisites, please refer to the
+`OpenWrt build guide
+`_.
+
+After the build is completed, you can find the images and SDK in
+``/bin/targets/x86/64-glibc/``.
+
+
+DPDK Cross Compilation for OpenWrt
+--
+
+Pre-requisites
+~~
+
+NUMA is required to run DPDK in x86.
+
+.. note::
+
+For compiling the NUMA lib, run ``libtool --version`` to ensure the libtool
+version >= 2.2, otherwise the compilation will fail with errors.
+
+.. code-block:: console
+
+git clone https://github.com/numactl/numactl.git
+cd numactl
+git checkout v2.0.13 -b v2.0.13
+./autogen.sh
+autoconf -i
+export PATH=/glibc/openwrt-sdk-x86-64_gcc-8.3.0_glibc.Linux-x86_64/staging_dir/toolchain-x86_64_gcc-8.3.0_glibc/bin/:$PATH
+./configure CC=x86_64-openwrt-linux-gnu-gcc --prefix=
+make install
+
+The numa header files and lib file is generated in the include and lib folder
+respectively under .
+
+Build DPDK
+~~
+
+To cross compile with meson build, you need to write a customized cross file
+first.
+
+.. code-block:: console
+
+[binaries]
+c = 'x86_64-openwrt-linux-gcc'
+cpp = 'x86_64-openwrt-linux-cpp'
+ar = 'x86_64-openwrt-linux-ar'
+strip = 'x86_64-openwrt-linux-strip'
+
+meson builddir --cross-file openwrt-cross
+ninja -C builddir
+
+.. note::
+
+For compiling the igb_uio with the kernel version used in target machine,
+you need to explicitly specify kernel_dir in meson_options.txt.
+
+Running DPDK application on OpenWrt
+---
+
+Virtual machine
+~~~
+
+* Extract the boot image
+
+.. code-block:: console
+
+gzip -d openwrt-x86-64-combined-ext4.img.gz
+
+* Launch Qemu
+
+.. code-block:: console
+
+qemu-system-x86_64 \
+-cpu host \
+-smp 8 \
+-enable-kvm \
+-M q35 \
+-m 2048M \
+-object 
memory-backend-file,id=mem,size=2048M,mem-path=/tmp/hugepages,share=on \
+-drive file=/openwrt-x86-64-combined-ext4.img,id=d0,if=none,bus=0,unit=0 \
+-device ide-hd,

Re: [dpdk-dev] [PATCH v5] doc: introduce openwrt how-to guide

[Dmitry Kozlyuk]

> On 02/16, Thomas Monjalon wrote:
> >16/02/2020 18:29, Ye Xiaolong:  
> >> On 02/16, Thomas Monjalon wrote:  
> >> >18/01/2020 06:48, Xiaolong Ye:
> >> >[...]  
> >> >> +[binaries]
> >> >> +c = 'x86_64-openwrt-linux-gcc'
> >> >> +cpp = 'x86_64-openwrt-linux-cpp'
> >> >> +ar = 'x86_64-openwrt-linux-ar'
> >> >> +strip = 'x86_64-openwrt-linux-strip'
> >> >> +
> >> >> +meson builddir --cross-file openwrt-cross  
> >> >
> >> >This is really a good example why meson should allow to override the 
> >> >toolchain prefix.  
> >> 
> >> Not sure whether I get your point or not, do you mean meson should support
> >> something like "cross = 'x86_64-openwrt-linux-'" in config file (just like 
> >> the
> >> CROSS_COMPILE for make build system),  so we don't need to override the 
> >> build
> >> tools one by one?  
> >
> >Yes, I think meson should support CROSS_COMPILE environment variable
> >or a similar config option. I don't see the point of creating a new
> >config file for each toolchain prefix.  
> 
> Totally agree, I would try to work on this to make it happen.

You might be interested in this PR and its discussion:
https://github.com/mesonbuild/meson/pull/5859

-- 
Dmitry Kozlyuk

[dpdk-dev] [PATCH] net/i40e: fix multiple interrupt for VF

[Shougang Wang]

Interrupt mapping should be 1:n queue(s).This patch fixes the
logic of interrupt bind by code reconstruction.

Fixes: 6a6cf5f88b4a ("net/i40e: enable multi-queue Rx interrupt for VF")

Signed-off-by: Shougang Wang 
---
 drivers/net/i40e/i40e_ethdev_vf.c | 63 ---
 1 file changed, 42 insertions(+), 21 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev_vf.c 
b/drivers/net/i40e/i40e_ethdev_vf.c
index b84637309..868117508 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -651,47 +651,68 @@ i40evf_config_irq_map(struct rte_eth_dev *dev)
 {
struct i40e_vf *vf = I40EVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);
struct vf_cmd_info args;
-   uint8_t cmd_buffer[sizeof(struct virtchnl_irq_map_info) + \
-   sizeof(struct virtchnl_vector_map) * dev->data->nb_rx_queues];
+   uint8_t *cmd_buffer = NULL;
struct virtchnl_irq_map_info *map_info;
struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(dev);
struct rte_intr_handle *intr_handle = &pci_dev->intr_handle;
-   uint32_t vector_id;
-   int i, err;
+   uint32_t vec, cmd_buffer_size, max_vectors, nb_msix, msix_base, i;
+   uint16_t rxq_map[vf->vf_res->max_vectors];
+   int err;
 
if (dev->data->dev_conf.intr_conf.rxq != 0 &&
-   rte_intr_allow_others(intr_handle))
-   vector_id = I40E_RX_VEC_START;
-   else
-   vector_id = I40E_MISC_VEC_ID;
+   rte_intr_allow_others(intr_handle)) {
+   msix_base = I40E_RX_VEC_START;
+   /* For interrupt mode, available vector id is from 1. */
+   max_vectors = vf->vf_res->max_vectors - 1;
+   nb_msix = RTE_MIN(max_vectors, intr_handle->nb_efd);
+
+   vec = msix_base;
+   for (i = 0; i < dev->data->nb_rx_queues; i++) {
+   rxq_map[vec] |= 1 << i;
+   intr_handle->intr_vec[i] = vec++;
+   if (vec >= vf->vf_res->max_vectors)
+   vec = msix_base;
+   }
+   } else {
+   msix_base = I40E_MISC_VEC_ID;
+   nb_msix = 1;
+
+   for (i = 0; i < dev->data->nb_rx_queues; i++) {
+   rxq_map[msix_base] |= 1 << i;
+   if (rte_intr_dp_is_en(intr_handle))
+   intr_handle->intr_vec[i] = msix_base;
+   }
+   }
+
+   cmd_buffer_size = sizeof(struct virtchnl_irq_map_info) +
+   sizeof(struct virtchnl_vector_map) * nb_msix;
+   cmd_buffer = rte_zmalloc("i40e", cmd_buffer_size, 0);
+   if (!cmd_buffer) {
+   PMD_DRV_LOG(ERR, "Failed to allocate memory");
+   return I40E_ERR_NO_MEMORY;
+   }
 
map_info = (struct virtchnl_irq_map_info *)cmd_buffer;
-   map_info->num_vectors = dev->data->nb_rx_queues;
-   for (i = 0; i < dev->data->nb_rx_queues; i++) {
+   map_info->num_vectors = nb_msix;
+   for (i = 0; i < nb_msix; i++) {
map_info->vecmap[i].rxitr_idx = I40E_ITR_INDEX_DEFAULT;
map_info->vecmap[i].vsi_id = vf->vsi_res->vsi_id;
-   /* Always use default dynamic MSIX interrupt */
-   map_info->vecmap[i].vector_id = vector_id;
-   /* Don't map any tx queue */
+   map_info->vecmap[i].vector_id = msix_base + i;
map_info->vecmap[i].txq_map = 0;
-   map_info->vecmap[i].rxq_map = 1 << i;
-   if (rte_intr_dp_is_en(intr_handle))
-   intr_handle->intr_vec[i] = vector_id;
-   if (vector_id > I40E_MISC_VEC_ID)
-   vector_id++;
-   if (vector_id >= vf->vf_res->max_vectors)
-   vector_id = I40E_RX_VEC_START;
+   map_info->vecmap[i].rxq_map = rxq_map[msix_base + i];
}
 
args.ops = VIRTCHNL_OP_CONFIG_IRQ_MAP;
args.in_args = (u8 *)cmd_buffer;
-   args.in_args_size = sizeof(cmd_buffer);
+   args.in_args_size = cmd_buffer_size;
args.out_buffer = vf->aq_resp;
args.out_size = I40E_AQ_BUF_SZ;
err = i40evf_execute_vf_cmd(dev, &args);
if (err)
PMD_DRV_LOG(ERR, "fail to execute command OP_ENABLE_QUEUES");
 
+   rte_free(cmd_buffer);
+
return err;
 }
 
-- 
2.17.1

Re: [dpdk-dev] [PATCH v5] doc: introduce openwrt how-to guide

[Ye Xiaolong]

On 02/17, Dmitry Kozlyuk wrote:
>> On 02/16, Thomas Monjalon wrote:
>> >16/02/2020 18:29, Ye Xiaolong:  
>> >> On 02/16, Thomas Monjalon wrote:  
>> >> >18/01/2020 06:48, Xiaolong Ye:
>> >> >[...]  
>> >> >> +[binaries]
>> >> >> +c = 'x86_64-openwrt-linux-gcc'
>> >> >> +cpp = 'x86_64-openwrt-linux-cpp'
>> >> >> +ar = 'x86_64-openwrt-linux-ar'
>> >> >> +strip = 'x86_64-openwrt-linux-strip'
>> >> >> +
>> >> >> +meson builddir --cross-file openwrt-cross  
>> >> >
>> >> >This is really a good example why meson should allow to override the 
>> >> >toolchain prefix.  
>> >> 
>> >> Not sure whether I get your point or not, do you mean meson should support
>> >> something like "cross = 'x86_64-openwrt-linux-'" in config file (just 
>> >> like the
>> >> CROSS_COMPILE for make build system),  so we don't need to override the 
>> >> build
>> >> tools one by one?  
>> >
>> >Yes, I think meson should support CROSS_COMPILE environment variable
>> >or a similar config option. I don't see the point of creating a new
>> >config file for each toolchain prefix.  
>> 
>> Totally agree, I would try to work on this to make it happen.
>
>You might be interested in this PR and its discussion:
>https://github.com/mesonbuild/meson/pull/5859

Thanks for the info, I'll look into it.


Thanks,
Xiaolong
>
>-- 
>Dmitry Kozlyuk

Re: [dpdk-dev] [PATCH 6/6] doc: guide for Windows build using MinGW-w64

[Dmitry Kozlyuk]

> Remembered another issue: thread-local storage (TLS) with shared libraries.
> Windows PE doesn't support TLS via special sections, so compilers use TLS
> emulation layer. With static libraries, there are no issues described below.
> 
> The first aspect is a build-time issue of MinGW. When linking to DPDK shared
> libraries, errors occur:
> 
>   undefined reference to `__emutls_v.per_lcore__rte_errno'
>   undefined reference to `__emutls_v.per_lcore__rte_lcore_id'
> 
> DPDK declares per_lcore__XXX in a map file, but GCC places __thread symbols
> in __emutls_v section, so the proper name to export becomes __emutls_v.XXX.
> This can be worked around by using an additional version script with MinGW,
> as I do in my port [0], however, the proper solution would be fixing the bug
> on MinGW side [1]. MinGW already converts TLS variable names when generating
> DEF files with `-Wl,--output-def` option (not used by DPDK, just a hint).

Did some research and AFAICT, there is not effortless solution for
efficient per-lcore variables on Windows. While MinGW-w64 has aforementioned
issues (actually, GCC on Windows does), Clang with default TLS options just
generates wrong results when exporting variables from dynamic libraries.
Demo: https://github.com/PlushBeaver/tlstest

Thread [0] claims this is a fundamental problem with PE-COFF executable
format, but I honestly lack expertise to tell if this is valid. Microsoft
docs [1] suggests that exporting __thread variables won't just work. Can
someone from Microsoft or from UNH Lab comment further?

[0]: https://sourceforge.net/p/mingw-w64/mailman/message/31777672/
[1]:
https://docs.microsoft.com/en-us/windows/win32/dlls/using-thread-local-storage-in-a-dynamic-link-library

-- 
Dmitry Kozlyuk

Re: [dpdk-dev] [RFC PATCH 0/5] graph: introduce graph subsystem

[Jerin Jacob]

I got initial comments from Ray and Stephen on this RFC[1]. Thanks for
the comments.

Is anyone else planning to have an architecture level or API usage
level review or any review of other top-level aspects?
I believe low-level aspects of the code can be taken care of from the
v1 series onwards.

I am just wondering what would be an appropriate time for sending v1.
If someone planning for reviewing at the top level,
I can wait until the review complete. Let us know if anyone planning to review?

If no other comment then I would like to request tech board approval
for the library on 26/Feb meeting.

[1]
http://mails.dpdk.org/archives/dev/2020-January/156765.html



On Sat, Feb 1, 2020 at 11:14 AM Jerin Jacob  wrote:
>
> On Sat, Feb 1, 2020 at 12:05 AM Ray Kinsella  wrote:
> >
> > Hi Jerin,
>
> Hi Ray,
>
> > Much kudos on a huge contribution to the community.
>
> All the authors of this patch set spend at least the last 3/4 months
> to bring this up RFC with performance data with an l3fwd-graph example
> application.
> We hope it would be useful for DPDK community.
>
> > Look forward to spend more time looking at it in the next few days.
>
> That would be very helpful.
>
> >
> > I'll bite and ask the obvious questions - why would I use rte_graph over 
> > FD.io VPP?
>
> I did not get the opportunity to work day to day on FD.io projects. My
> understanding of FD.io is very limited.
> I do think, it is NOT one vs other. VPP is quite a mature project and
> they are pioneers in graph architecture.
>
> VPP is an entirely separate framework by itself and provides an
> alternate data plane environment.
> The objective of rte_graph is to add a graph subsystem to DPDK as a
> foundational element.
> This will allow the DPDK community to use the powerfull graph
> architecture concept in a fundamental
> way with purely DPDK based applications
>
> That would boil down to:
> 1) Provision to use pure native mbuf based dpdk application with graph
> architecture. i.e
> avoid the cost of packet format conversion for good.
> 2) Use rte_mempool, rte_flow, rte_tm, rte_cryptodev, rte_eventdev,
> rte_regexdev HW accelerated
> API in the data plane application.
> 3) Based on our experience, NPU HW accelerates are so different than
> one vendor to another vendor.
> Going forward, We believe, API abstraction may not be enough abstract
> the difference in HW.
> The Vendor-specific nodes can abstract the HW differences and reuse
> generic the nodes as needed.
> This would help both the silicon vendors and DPDK end-users to avoid writing
> capabilities based APIs and avoid vendor-specific fast path routines.
> So such vendor plugin can be part of dpdk to help both vendors
> and end-user of DPDK.
> 4) Provision for multiprocess support in graph architecture.
> 5) Contribute to dpdk.org
> 6) Use Linux coding standards.
> 7) Finally, one may consider using rte_graph, _if_ specific workload
> performs better in performance
> in this model due to framework and/or the HW acceleration attached to it.
>
>
> >
> > Ray K
> >

[dpdk-dev] [PATCH] net/octeontx: meson build fix if octeontx drivers are disabled

[agupta3]

From: Amit Gupta 

Add a condition to check if octeontx drivers are disabled.
octeontx drivers are built only if dependent drivers i.e.
ethdev, mempool and common/octeontx are enabled.

BugZilla ID # BUG 387

Change-Id: Idf9578fc04345e690ac48b4836faff2e25170331
Signed-off-by: Amit Gupta 
---
 drivers/net/octeontx/base/meson.build | 32 
 1 file changed, 24 insertions(+), 8 deletions(-)

diff --git a/drivers/net/octeontx/base/meson.build 
b/drivers/net/octeontx/base/meson.build
index a06a2c8..50e7972 100644
--- a/drivers/net/octeontx/base/meson.build
+++ b/drivers/net/octeontx/base/meson.build
@@ -9,17 +9,33 @@ sources = [
 
 depends = ['ethdev', 'mempool_octeontx']
 static_objs = []
-foreach d: depends
-   static_objs += [get_variable('static_rte_' + d)]
+
+disabled_drivers = get_option('disable_drivers').split(',')
+
+build = true
+foreach disable_path: disabled_drivers
+if (('net/octeontx' == disable_path) or
+  ('event/octeontx' == disable_path) or
+  ('common/octeontx' == disable_path) or
+  ('mempool/octeontx' == disable_path))
+build = false
+endif
 endforeach
 
 c_args = cflags
 if allow_experimental_apis
-   c_args += '-DALLOW_EXPERIMENTAL_API'
+c_args += '-DALLOW_EXPERIMENTAL_API'
 endif
-base_lib = static_library('octeontx_base', sources,
-   c_args: c_args,
-   dependencies: static_objs,
-)
 
-base_objs = base_lib.extract_all_objects()
+if build
+foreach d: depends
+static_objs += [get_variable('static_rte_' + d)]
+endforeach
+
+base_lib = static_library('octeontx_base', sources,
+c_args: c_args,
+dependencies: static_objs,
+)
+
+base_objs = base_lib.extract_all_objects()
+endif
-- 
1.8.3.1

[dpdk-dev] [PATCH] net/octeontx: meson build fix if octeontx drivers are disabled

[agupta3]

From: Amit Gupta 

Add a condition to check if octeontx drivers are disabled.
octeontx drivers are built only if dependent drivers i.e.
ethdev, mempool and common/octeontx are enabled.

BugZilla ID # BUG 387

Signed-off-by: Amit Gupta 
---
 drivers/net/octeontx/base/meson.build | 32 
 1 file changed, 24 insertions(+), 8 deletions(-)

diff --git a/drivers/net/octeontx/base/meson.build 
b/drivers/net/octeontx/base/meson.build
index a06a2c8..50e7972 100644
--- a/drivers/net/octeontx/base/meson.build
+++ b/drivers/net/octeontx/base/meson.build
@@ -9,17 +9,33 @@ sources = [
 
 depends = ['ethdev', 'mempool_octeontx']
 static_objs = []
-foreach d: depends
-   static_objs += [get_variable('static_rte_' + d)]
+
+disabled_drivers = get_option('disable_drivers').split(',')
+
+build = true
+foreach disable_path: disabled_drivers
+if (('net/octeontx' == disable_path) or
+  ('event/octeontx' == disable_path) or
+  ('common/octeontx' == disable_path) or
+  ('mempool/octeontx' == disable_path))
+build = false
+endif
 endforeach
 
 c_args = cflags
 if allow_experimental_apis
-   c_args += '-DALLOW_EXPERIMENTAL_API'
+c_args += '-DALLOW_EXPERIMENTAL_API'
 endif
-base_lib = static_library('octeontx_base', sources,
-   c_args: c_args,
-   dependencies: static_objs,
-)
 
-base_objs = base_lib.extract_all_objects()
+if build
+foreach d: depends
+static_objs += [get_variable('static_rte_' + d)]
+endforeach
+
+base_lib = static_library('octeontx_base', sources,
+c_args: c_args,
+dependencies: static_objs,
+)
+
+base_objs = base_lib.extract_all_objects()
+endif
-- 
1.8.3.1