[dpdk-dev] [PATCH] clean bare metal support traces

[David Marchand]

Bare metal support has been gone for quite some time but we still had
some checks on system includes.

Signed-off-by: David Marchand 
---
 app/test-pmd/cmdline.c| 6 +-
 app/test/commands.c   | 5 -
 app/test/test_cmdline_ipaddr.c| 7 +--
 examples/cmdline/commands.c   | 8 ++--
 lib/librte_cmdline/cmdline_parse_ipaddr.c | 6 +-
 5 files changed, 5 insertions(+), 27 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 56783aa..e28b8ba 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -11,13 +11,9 @@
 #include 
 #include 
 #include 
-#ifndef __linux__
-#ifndef __FreeBSD__
-#include 
-#else
+#ifdef __FreeBSD__
 #include 
 #endif
-#endif
 #include 
 
 #include 
diff --git a/app/test/commands.c b/app/test/commands.c
index 8d5a03a..3bf767b 100644
--- a/app/test/commands.c
+++ b/app/test/commands.c
@@ -10,11 +10,6 @@
 #include 
 #include 
 #include 
-#ifndef __linux__
-#ifndef __FreeBSD__
-#include 
-#endif
-#endif
 #include 
 #include 
 #include 
diff --git a/app/test/test_cmdline_ipaddr.c b/app/test/test_cmdline_ipaddr.c
index 8ee7f62..2d11ce9 100644
--- a/app/test/test_cmdline_ipaddr.c
+++ b/app/test/test_cmdline_ipaddr.c
@@ -6,14 +6,9 @@
 #include 
 #include 
 #include 
-
-#ifndef __linux__
-#ifndef __FreeBSD__
-#include 
-#else
+#ifdef __FreeBSD__
 #include 
 #endif
-#endif
 
 #include 
 
diff --git a/examples/cmdline/commands.c b/examples/cmdline/commands.c
index e96739f..1249ee7 100644
--- a/examples/cmdline/commands.c
+++ b/examples/cmdline/commands.c
@@ -12,12 +12,8 @@
 #include 
 #include 
 #include 
-#ifndef __linux__
-   #ifdef __FreeBSD__
-   #include 
-   #else
-   #include 
-   #endif
+#ifdef __FreeBSD__
+#include 
 #endif
 
 #include 
diff --git a/lib/librte_cmdline/cmdline_parse_ipaddr.c 
b/lib/librte_cmdline/cmdline_parse_ipaddr.c
index 6647f56..848c1eb 100644
--- a/lib/librte_cmdline/cmdline_parse_ipaddr.c
+++ b/lib/librte_cmdline/cmdline_parse_ipaddr.c
@@ -13,13 +13,9 @@
 #include 
 #include 
 #include 
-#ifndef __linux__
-#ifndef __FreeBSD__
-#include 
-#else
+#ifdef __FreeBSD__
 #include 
 #endif
-#endif
 
 #include 
 
-- 
1.8.3.1

[dpdk-dev] [PATCH] buildtools: lighter experimental symbol check

[David Marchand]

Dumping every object file for every symbol is too heavy.
Use a temporary storage.

Before:
$ rm -rf master && make defconfig O=master
$ time make EXTRA_CFLAGS=-g O=master
[...]
real2m24.063s
user1m16.985s
sys 1m46.372s

After:
$ rm -rf master && make defconfig O=master
$ time make EXTRA_CFLAGS=-g O=master
[...]
real1m37.110s
user0m49.417s
sys 0m51.803s

Signed-off-by: David Marchand 
---
 buildtools/check-experimental-syms.sh | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/buildtools/check-experimental-syms.sh 
b/buildtools/check-experimental-syms.sh
index 0f6c62d..47a06fc 100755
--- a/buildtools/check-experimental-syms.sh
+++ b/buildtools/check-experimental-syms.sh
@@ -18,14 +18,15 @@ then
exit 0
 fi
 
+DUMPFILE=$(mktemp -t dpdk.${0##*/}.XXX.objdump)
+trap 'rm -f "$DUMPFILE"' EXIT
+objdump -t $OBJFILE >$DUMPFILE
+
 ret=0
 for SYM in `$LIST_SYMBOL -S EXPERIMENTAL $MAPFILE`
 do
-   objdump -t $OBJFILE | grep -q "\.text.*$SYM$"
-   IN_TEXT=$?
-   objdump -t $OBJFILE | grep -q "\.text\.experimental.*$SYM$"
-   IN_EXP=$?
-   if [ $IN_TEXT -eq 0 -a $IN_EXP -ne 0 ]
+   if grep -q "\.text.*$SYM$" $DUMPFILE &&
+   ! grep -q "\.text\.experimental.*$SYM$" $DUMPFILE
then
cat >&2 <<- END_OF_MESSAGE
$SYM is not flagged as experimental
@@ -37,11 +38,11 @@ do
 done
 
 # Filter out symbols suffixed with a . for icc
-for SYM in `objdump -t $OBJFILE |awk '{
+for SYM in `awk '{
if ($2 != "l" && $4 == ".text.experimental" && !($NF ~ /\.$/)) {
print $NF
}
-}'`
+}' $DUMPFILE`
 do
$LIST_SYMBOL -S EXPERIMENTAL -s $SYM -q $MAPFILE || {
cat >&2 <<- END_OF_MESSAGE
-- 
1.8.3.1

[dpdk-dev] [v4] net/i40e: fix vf runtime queues rss config

[Xiao Zhang]

I40evf queue can not work properly with kernel pf driver. Eg. when
configure 8 queues pair, only 4 queues can receive packets, and half
packets will be lost if using 2 queues pair.
This issue is caused by misconfiguration of look up table, use aq command
to setup the lut to make it work properly.

Fixes: cea7a51c1750 ("i40evf: support RSS")
Cc: sta...@dpdk.org

Signed-off-by: Xiao Zhang 
---
v4 move local variable definition to the begin of the function
v3 move LUT configuration in to i40evf_configure_rss
v2 change for loop format to avoid build patch issue
---
 drivers/net/i40e/i40e_ethdev_vf.c | 32 ++--
 1 file changed, 26 insertions(+), 6 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev_vf.c 
b/drivers/net/i40e/i40e_ethdev_vf.c
index 308fb98..8c34afb 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -2598,7 +2598,10 @@ i40evf_config_rss(struct i40e_vf *vf)
struct i40e_hw *hw = I40E_VF_TO_HW(vf);
struct rte_eth_rss_conf rss_conf;
uint32_t i, j, lut = 0, nb_q = (I40E_VFQF_HLUT_MAX_INDEX + 1) * 4;
+   uint32_t rss_lut_size = (I40E_VFQF_HLUT1_MAX_INDEX + 1) * 4;
uint16_t num;
+   uint8_t *lut;
+   int ret;
 
if (vf->dev_data->dev_conf.rxmode.mq_mode != ETH_MQ_RX_RSS) {
i40evf_disable_rss(vf);
@@ -2608,12 +2611,29 @@ i40evf_config_rss(struct i40e_vf *vf)
 
num = RTE_MIN(vf->dev_data->nb_rx_queues, I40E_MAX_QP_NUM_PER_VF);
/* Fill out the look up table */
-   for (i = 0, j = 0; i < nb_q; i++, j++) {
-   if (j >= num)
-   j = 0;
-   lut = (lut << 8) | j;
-   if ((i & 3) == 3)
-   I40E_WRITE_REG(hw, I40E_VFQF_HLUT(i >> 2), lut);
+   if (!(vf->flags & I40E_FLAG_RSS_AQ_CAPABLE)) {
+   for (i = 0, j = 0; i < nb_q; i++, j++) {
+   if (j >= num)
+   j = 0;
+   lut = (lut << 8) | j;
+   if ((i & 3) == 3)
+   I40E_WRITE_REG(hw, I40E_VFQF_HLUT(i >> 2), lut);
+   }
+   } else {
+   lut = rte_zmalloc("i40e_rss_lut", rss_lut_size, 0);
+   if (!lut) {
+   PMD_DRV_LOG(ERR, "No memory can be allocated");
+   return -ENOMEM;
+   }
+
+   for (i = 0; i < rss_lut_size; i++)
+   lut[i] = i % vf->num_queue_pairs;
+
+   ret = i40evf_set_rss_lut(&vf->vsi, lut,
+rss_lut_size);
+   rte_free(lut);
+   if (ret)
+   return ret;
}
 
rss_conf = vf->dev_data->dev_conf.rx_adv_conf.rss_conf;
-- 
2.7.4

Re: [dpdk-dev] [PATCH] bpf: fix to allow ptr stack program type

[Ananyev, Konstantin]

Hi Jerin,

> 
> bpf_validate does not allow to execute
> RTE_BPF_ARG_PTR_STACK for no reason.

I believe there is a reason,
ARG_PTR_STACK is reserved for memory within BPF program internal stack only.
User that calls BPF program should never pass parameter with that type.
If the user allocates parameter for bpf function on the stack, he can
still use RTE_BPF_ARG_PTR for it.
Konstantin

> Fix it by enhancing the prog_arg.type check.
> 
> Fixes: 6e12ec4c4d6d ("bpf: add more checks")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Jerin Jacob 
> ---
>  lib/librte_bpf/bpf_validate.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/lib/librte_bpf/bpf_validate.c b/lib/librte_bpf/bpf_validate.c
> index 0cf41fa27..c75777b6d 100644
> --- a/lib/librte_bpf/bpf_validate.c
> +++ b/lib/librte_bpf/bpf_validate.c
> @@ -2216,6 +2216,7 @@ bpf_validate(struct rte_bpf *bpf)
> 
>   /* check input argument type, don't allow mbuf ptr on 32-bit */
>   if (bpf->prm.prog_arg.type != RTE_BPF_ARG_RAW &&
> + bpf->prm.prog_arg.type != RTE_BPF_ARG_PTR_STACK &&
>   bpf->prm.prog_arg.type != RTE_BPF_ARG_PTR &&
>   (sizeof(uint64_t) != sizeof(uintptr_t) ||
>   bpf->prm.prog_arg.type != RTE_BPF_ARG_PTR_MBUF)) {
> --
> 2.22.0

Re: [dpdk-dev] [EXT] [PATCH] cryptodev: extend api of asymmetric crypto by sessionless

[Anoob Joseph]

Hi Arek,

Please see inline.

Thanks,
Anoob

> -Original Message-
> From: dev  On Behalf Of Arek Kusztal
> Sent: Tuesday, June 4, 2019 1:14 AM
> To: dev@dpdk.org
> Cc: akhil.go...@nxp.com; fiona.tr...@intel.com;
> shally.ve...@caviumnetworks.com; Arek Kusztal
> 
> Subject: [EXT] [dpdk-dev] [PATCH] cryptodev: extend api of asymmetric
> crypto by sessionless
> 
> External Email
> 
> --
> Asymmetric cryptography algorithms may more likely use sessionless API so
> there is need to extend API.
> 
> Signed-off-by: Arek Kusztal 
> ---
>  lib/librte_cryptodev/rte_crypto_asym.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/lib/librte_cryptodev/rte_crypto_asym.h
> b/lib/librte_cryptodev/rte_crypto_asym.h
> index 8672f21..5d69692 100644
> --- a/lib/librte_cryptodev/rte_crypto_asym.h
> +++ b/lib/librte_cryptodev/rte_crypto_asym.h
> @@ -503,6 +503,8 @@ struct rte_crypto_dsa_op_param {  struct
> rte_crypto_asym_op {
>   struct rte_cryptodev_asym_session *session;
>   /**< Handle for the initialised session context */
> + struct rte_crypto_asym_xform *xform;
> + /**< Session-less API crypto operation parameters */

[Anoob] Shouldn't we make this a union? In symmetric mode, it is done that way 
and it makes sense also.

Something like,

   RTE_STD_C11
   union {
   struct rte_cryptodev_asym_session *session;
   /**< Handle for the initialised session context */
   struct rte_crypto_asym_xform *xform;
   /**< Session-less API crypto operation parameters */
   };
 
> 
>   __extension__
>   union {
> --
> 2.7.4

Re: [dpdk-dev] WARNING! Base virtual address hint not respected!

[Burakov, Anatoly]

On 07-Aug-19 11:51 AM, Nilesh wrote:

Hello,

We are trying to build an application over DPDK, but we are getting this 
warning when we call

rte_eal_init().

EAL: Detected 24 lcore(s)
EAL: Detected 2 NUMA nodes
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: No available hugepages reported in hugepages-1048576kB
EAL: Probing VFIO support...
EAL: WARNING! Base virtual address hint (0x15000 != 0x7f63aed91000) 
not respected!

EAL:    This may cause issues with mapping memory into secondary processes
EAL: WARNING! Base virtual address hint (0x1b000 != 0x7f63a937f000) 
not respected!

EAL:    This may cause issues with mapping memory into secondary processes
EAL: WARNING! Base virtual address hint (0x100a0c000 != 0x7f5fa780) 
not respected!

EAL:    This may cause issues with mapping memory into secondary processes
EAL: WARNING! Base virtual address hint (0x100c11000 != 0x7f63a931e000) 
not respected!

EAL:    This may cause issues with mapping memory into secondary processes

rte_eal_init() is returning successfully, but we wanted to know why this 
warning is coming and

what are the potential issues that may arise due to this warning.

Note: NIC is bound with igb_uio. Hugepages are mapped and there are 
enough free pages.


System specification :
2 machines with
Distributor ID:    Ubuntu
Description:    Ubuntu 18.04.2 LTS
Release:    18.04
Codename:    bionic

Kernel: 4.15.0-55-generic
*DPDK* version: 19.05.0

Hardware:
CPU: Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz
NIC 1: Intel Corporation Ethernet Controller XL710 for 40GbE QSFP+ (i40e)

(If any extra setup configuration information required will be provided)

Thanks,
Nilesh




Hi,

This is normal. This happens because, by default, shared memory in EAL 
is mapped starting at a specific memory offset due to certain issues 
with DPDK's multiprocess support. Sometimes these offsets will not be 
available, so things will get mapped at other addresses. Because this 
event may cause issues with subsequent secondary process mappings, EAL 
warns about this on initialization.


If you're not using secondary processes, you may disregard this warning.

--
Thanks,
Anatoly

Re: [dpdk-dev] [PATCH] remove unneeded eal header inclusion

[Burakov, Anatoly]

On 12-Aug-19 7:53 AM, David Marchand wrote:

Restrict this header inclusion to its real users.

Fixes: 028669bc9f0d ("eal: hide shared memory config")

Signed-off-by: David Marchand 
---
  app/test/test_external_mem.c  | 1 -
  app/test/test_malloc.c| 1 -
  app/test/test_memory.c| 1 -
  app/test/test_memzone.c   | 1 -
  app/test/test_tailq.c | 1 -
  drivers/bus/fslmc/fslmc_bus.c | 1 -
  drivers/bus/pci/bsd/pci.c | 1 -
  drivers/bus/pci/linux/pci.c   | 1 -
  drivers/bus/pci/linux/pci_uio.c   | 1 -
  drivers/bus/pci/linux/pci_vfio.c  | 1 -
  drivers/bus/vmbus/linux/vmbus_uio.c   | 1 -
  drivers/event/opdl/opdl_ring.c| 1 -
  drivers/net/mlx4/mlx4_mr.c| 1 +
  drivers/net/mlx4/mlx4_mr.h| 1 -
  drivers/net/mlx5/mlx5.c   | 1 -
  drivers/net/mlx5/mlx5_mr.c| 1 +
  drivers/net/mlx5/mlx5_mr.h| 1 -
  drivers/net/virtio/virtio_user/vhost_kernel.c | 1 -
  drivers/net/virtio/virtio_user/vhost_user.c   | 1 -
  drivers/raw/ifpga/ifpga_rawdev.c  | 1 -
  lib/librte_acl/rte_acl.c  | 1 +
  lib/librte_acl/rte_acl_osdep.h| 1 -
  lib/librte_eal/common/eal_common_memalloc.c   | 1 -
  lib/librte_eal/common/eal_common_memzone.c| 1 -
  lib/librte_eal/common/eal_memalloc.h  | 1 -
  lib/librte_eal/common/eal_memcfg.h| 1 -
  lib/librte_eal/common/malloc_elem.h   | 2 --
  lib/librte_eal/freebsd/eal/eal.c  | 1 -
  lib/librte_eal/freebsd/eal/eal_memory.c   | 1 -
  lib/librte_eal/linux/eal/eal.c| 1 -
  lib/librte_eal/linux/eal/eal_memalloc.c   | 1 -
  lib/librte_eal/linux/eal/eal_memory.c | 1 -
  lib/librte_rcu/rte_rcu_qsbr.c | 1 -
  33 files changed, 3 insertions(+), 31 deletions(-)

diff --git a/app/test/test_external_mem.c b/app/test/test_external_mem.c
index 97bde1c..7eb81f6 100644
--- a/app/test/test_external_mem.c
+++ b/app/test/test_external_mem.c
@@ -13,7 +13,6 @@
  #include 
  #include 
  #include 
-#include 
  #include 
  #include 
  #include 
diff --git a/app/test/test_malloc.c b/app/test/test_malloc.c
index 7243e83..a16e28c 100644
--- a/app/test/test_malloc.c
+++ b/app/test/test_malloc.c
@@ -12,7 +12,6 @@
  
  #include 

  #include 
-#include 
  #include 
  #include 
  #include 
diff --git a/app/test/test_memory.c b/app/test/test_memory.c
index 3da803e..7d5ae99 100644
--- a/app/test/test_memory.c
+++ b/app/test/test_memory.c
@@ -6,7 +6,6 @@
  #include 
  
  #include 

-#include 
  #include 
  #include 
  #include 
diff --git a/app/test/test_memzone.c b/app/test/test_memzone.c
index 7501b63..7edfd06 100644
--- a/app/test/test_memzone.c
+++ b/app/test/test_memzone.c
@@ -13,7 +13,6 @@
  #include 
  #include 
  #include 
-#include 
  #include 
  #include 
  #include 
diff --git a/app/test/test_tailq.c b/app/test/test_tailq.c
index 7c9b69f..9520219 100644
--- a/app/test/test_tailq.c
+++ b/app/test/test_tailq.c
@@ -10,7 +10,6 @@
  #include 
  
  #include 

-#include 
  #include 
  #include 
  
diff --git a/drivers/bus/fslmc/fslmc_bus.c b/drivers/bus/fslmc/fslmc_bus.c

index a2f4825..e7d240f 100644
--- a/drivers/bus/fslmc/fslmc_bus.c
+++ b/drivers/bus/fslmc/fslmc_bus.c
@@ -10,7 +10,6 @@
  
  #include 

  #include 
-#include 
  #include 
  #include 
  #include 
diff --git a/drivers/bus/pci/bsd/pci.c b/drivers/bus/pci/bsd/pci.c
index 8f07ed9..179 100644
--- a/drivers/bus/pci/bsd/pci.c
+++ b/drivers/bus/pci/bsd/pci.c
@@ -33,7 +33,6 @@
  #include 
  #include 
  #include 
-#include 
  #include 
  #include 
  #include 
diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/pci.c
index 43debaa..1ac2bff 100644
--- a/drivers/bus/pci/linux/pci.c
+++ b/drivers/bus/pci/linux/pci.c
@@ -9,7 +9,6 @@
  #include 
  #include 
  #include 
-#include 
  #include 
  #include 
  #include 
diff --git a/drivers/bus/pci/linux/pci_uio.c b/drivers/bus/pci/linux/pci_uio.c
index f240fe4..e031361 100644
--- a/drivers/bus/pci/linux/pci_uio.c
+++ b/drivers/bus/pci/linux/pci_uio.c
@@ -20,7 +20,6 @@
  #include 
  #include 
  #include 
-#include 
  #include 
  #include 
  
diff --git a/drivers/bus/pci/linux/pci_vfio.c b/drivers/bus/pci/linux/pci_vfio.c

index 1ceb1c0..faf2990 100644
--- a/drivers/bus/pci/linux/pci_vfio.c
+++ b/drivers/bus/pci/linux/pci_vfio.c
@@ -14,7 +14,6 @@
  #include 
  #include 
  #include 
-#include 
  #include 
  #include 
  #include 
diff --git a/drivers/bus/vmbus/linux/vmbus_uio.c 
b/drivers/bus/vmbus/linux/vmbus_uio.c
index be6b677..10e50c9 100644
--- a/drivers/bus/vmbus/linux/vmbus_uio.c
+++ b/drivers/bus/vmbus/linux/vmbus_uio.c
@@ -14,7 +14,6 @@
  #include 
  #include 
  #include 
-#include 
  #include 
  #include 
  #include 
diff --git a/drivers/event/opdl/opdl_ring.c b/drivers/event/opd

Re: [dpdk-dev] [PATCH] eal: change max hugepage sizes to 4

[Burakov, Anatoly]

On 07-Aug-19 2:28 PM, Hemant Agrawal wrote:

HI Thomas,


DPDK currently is supporting maximum 3 hugepage, sizes whereas
system can support more than this e.g.
64K, 2M, 32M and 1G.


You can mention ARM platform here, and that this issue starts with
kernel 5.2 (and I would try to mention this in the title as well).
This is better than an annotation that will be lost.



Having these four hugepage sizes available to use by DPDK, which is
valid in case of '--in-memory' EAL option or using 4 separate mount
points for each hugepage size;
hugepage_info_init() API reports an error.


Can you describe what is the impact from a user point of view rather
than mentioning this internal function?


Yes please, we need to understand how much it is critical.
Should we Cc sta...@dpdk.org for backport?
Should it be merged at the last minute in 19.08?



VPP usages in-memory option. So, VPP on ARM with kernel 5.2 wont' work without 
this patch.



Off-topic, but it's nice to see real-world usage for this option!

--
Thanks,
Anatoly

Re: [dpdk-dev] [PATCH] eal: change max hugepage sizes to 4

[Burakov, Anatoly]

On 08-Aug-19 8:31 AM, Thomas Monjalon wrote:

07/08/2019 15:28, Hemant Agrawal:

HI Thomas,


DPDK currently is supporting maximum 3 hugepage, sizes whereas
system can support more than this e.g.
64K, 2M, 32M and 1G.


You can mention ARM platform here, and that this issue starts with
kernel 5.2 (and I would try to mention this in the title as well).
This is better than an annotation that will be lost.



Having these four hugepage sizes available to use by DPDK, which is
valid in case of '--in-memory' EAL option or using 4 separate mount
points for each hugepage size;
hugepage_info_init() API reports an error.


Can you describe what is the impact from a user point of view rather
than mentioning this internal function?


Yes please, we need to understand how much it is critical.
Should we Cc sta...@dpdk.org for backport?
Should it be merged at the last minute in 19.08?


VPP usages in-memory option. So, VPP on ARM with kernel 5.2 wont' work without 
this patch.


Do you want to send a v2 with a better explanation?

I would suggest to restrict the change to Arm only with an ifdef,
in order to limit the risk for this release.
We can think about a dynamic hugepage scan in the next release.



I don't see how this is necessary. The 3 is an arbitrary number here, 
and the ABI isn't broken as this is an internal structure. We could 
increase it to 16 for all i care, and it wouldn't make any difference to 
the rest of the code - we never populate more than we can find anyway.


--
Thanks,
Anatoly

Re: [dpdk-dev] [PATCH] eal: change max hugepage sizes to 4

[David Marchand]

On Mon, Aug 12, 2019 at 11:43 AM Burakov, Anatoly
 wrote:
> On 08-Aug-19 8:31 AM, Thomas Monjalon wrote:
> > I would suggest to restrict the change to Arm only with an ifdef,
> > in order to limit the risk for this release.
> > We can think about a dynamic hugepage scan in the next release.
> >
>
> I don't see how this is necessary. The 3 is an arbitrary number here,
> and the ABI isn't broken as this is an internal structure. We could
> increase it to 16 for all i care, and it wouldn't make any difference to
> the rest of the code - we never populate more than we can find anyway.

I agree on the principle.
But at the time this popped up, we were really close to the release.
It seemed a way to mitigate any unforeseen issue by limiting to the
platform that was affected.


-- 
David Marchand

Re: [dpdk-dev] [EXT] [PATCH] cryptodev: extend api of asymmetric crypto by sessionless

[Kusztal, ArkadiuszX]

Hi Anoob,
 
> [Anoob] Shouldn't we make this a union? In symmetric mode, it is done that
> way and it makes sense also.
> 
> Something like,
> 
>RTE_STD_C11
>union {
>struct rte_cryptodev_asym_session *session;
>/**< Handle for the initialised session context */
>struct rte_crypto_asym_xform *xform;
>/**< Session-less API crypto operation parameters */
>};
[AK] - Agreed. I will send updated version.
> 
> >
> > __extension__
> > union {
> > --
> > 2.7.4

Re: [dpdk-dev] [PATCH] eal: change max hugepage sizes to 4

[Thomas Monjalon]

12/08/2019 11:49, David Marchand:
> On Mon, Aug 12, 2019 at 11:43 AM Burakov, Anatoly
>  wrote:
> > On 08-Aug-19 8:31 AM, Thomas Monjalon wrote:
> > > I would suggest to restrict the change to Arm only with an ifdef,
> > > in order to limit the risk for this release.
> > > We can think about a dynamic hugepage scan in the next release.
> >
> > I don't see how this is necessary. The 3 is an arbitrary number here,
> > and the ABI isn't broken as this is an internal structure. We could
> > increase it to 16 for all i care, and it wouldn't make any difference to
> > the rest of the code - we never populate more than we can find anyway.
> 
> I agree on the principle.
> But at the time this popped up, we were really close to the release.
> It seemed a way to mitigate any unforeseen issue by limiting to the
> platform that was affected.

Exactly, we were extra cautious.

Please increase the value for everybody, thanks.

Re: [dpdk-dev] [PATCH v4] eal: fix proc type auto detection

[David Marchand]

On Wed, Jul 24, 2019 at 6:08 PM Anatoly Burakov
 wrote:
>
> Currently, primary process holds an exclusive lock on the config
> file, thereby preventing other primaries from spinning up. However,
> when the primary dies, the lock is no longer being held, even though
> there might be other secondary processes still running.
>
> The fix is two-fold. First of all, downgrade the primary process's
> exclusive lock to a shared lock once we have it. Second of all,
> also take out shared locks on the config from the secondaries. We
> are using fcntl() locks, which get dropped when the file handle is
> closed, so also remove the closure of config file handle.
>
> Fixes: af75078fece3 ("first public release")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Anatoly Burakov 
> ---
>
> Notes:
> v4:
> - Fixed FreeBSD log message to match Linux version
>
> v3:
> - Added similar changes to FreeBSD version
>
> v2:
> - Adjusted indentation
>
>  lib/librte_eal/freebsd/eal/eal.c | 36 +++
>  lib/librte_eal/linux/eal/eal.c   | 37 +++-
>  2 files changed, 64 insertions(+), 9 deletions(-)
>
> diff --git a/lib/librte_eal/freebsd/eal/eal.c 
> b/lib/librte_eal/freebsd/eal/eal.c
> index d53f0fe69..69995bf8f 100644
> --- a/lib/librte_eal/freebsd/eal/eal.c
> +++ b/lib/librte_eal/freebsd/eal/eal.c
> @@ -72,6 +72,13 @@ static struct flock wr_lock = {
> .l_len = sizeof(early_mem_config.memsegs),
>  };
>
> +static struct flock rd_lock = {
> +   .l_type = F_RDLCK,
> +   .l_whence = SEEK_SET,
> +   .l_start = offsetof(struct rte_mem_config, memsegs),
> +   .l_len = sizeof(early_mem_config.memsegs),
> +};
> +
>  /* Address of global and public configuration */
>  static struct rte_config rte_config = {
> .mem_config = &early_mem_config,
> @@ -249,8 +256,21 @@ rte_eal_config_create(void)
> if (retval < 0){
> close(mem_cfg_fd);
> mem_cfg_fd = -1;
> -   RTE_LOG(ERR, EAL, "Cannot create lock on '%s'. Is another 
> primary "
> -   "process running?\n", pathname);
> +   RTE_LOG(ERR, EAL, "Cannot create exclusive lock on '%s'. "
> +   "Is another process running?\n", pathname);
> +   return -1;
> +   }
> +
> +   /* we hold an exclusive lock - now downgrade it to a read lock to 
> allow
> +* other processes to also hold onto this file while preventing other
> +* primaries from spinning up.
> +*/
> +   retval = fcntl(mem_cfg_fd, F_SETLK, &rd_lock);
> +   if (retval < 0) {
> +   close(mem_cfg_fd);
> +   mem_cfg_fd = -1;
> +   RTE_LOG(ERR, EAL, "Cannot downgrade to shared lock on '%s': 
> %s\n",
> +   pathname, strerror(errno));
> return -1;
> }
>
> @@ -292,6 +312,16 @@ rte_eal_config_attach(void)
> return -1;
> }
> }
> +   /* lock the file to prevent primary from initializing while this
> +* process is still running.
> +*/
> +   if (fcntl(mem_cfg_fd, F_SETLK, &rd_lock) < 0) {
> +   close(mem_cfg_fd);
> +   mem_cfg_fd = -1;
> +   RTE_LOG(ERR, EAL, "Cannot create shared lock on '%s': %s\n",
> +   pathname, strerror(errno));
> +   return -1;
> +   }
>
> rte_mem_cfg_addr = mmap(NULL, sizeof(*rte_config.mem_config),
> PROT_READ, MAP_SHARED, mem_cfg_fd, 0);
> @@ -330,8 +360,6 @@ rte_eal_config_reattach(void)
> mem_config = (struct rte_mem_config *) mmap(rte_mem_cfg_addr,
> sizeof(*mem_config), PROT_READ | PROT_WRITE, 
> MAP_SHARED,
> mem_cfg_fd, 0);
> -   close(mem_cfg_fd);
> -   mem_cfg_fd = -1;
>
> if (mem_config == MAP_FAILED) {
> RTE_LOG(ERR, EAL, "Cannot mmap memory for rte_config! error 
> %i (%s)\n",

We are missing a mem_cfg_fd cleanup if mmap failed.


> diff --git a/lib/librte_eal/linux/eal/eal.c b/lib/librte_eal/linux/eal/eal.c
> index 34db78753..0f0726703 100644
> --- a/lib/librte_eal/linux/eal/eal.c
> +++ b/lib/librte_eal/linux/eal/eal.c
> @@ -83,6 +83,13 @@ static struct flock wr_lock = {
> .l_len = sizeof(early_mem_config.memsegs),
>  };
>
> +static struct flock rd_lock = {
> +   .l_type = F_RDLCK,
> +   .l_whence = SEEK_SET,
> +   .l_start = offsetof(struct rte_mem_config, memsegs),
> +   .l_len = sizeof(early_mem_config.memsegs),
> +};
> +
>  /* Address of global and public configuration */
>  static struct rte_config rte_config = {
> .mem_config = &early_mem_config,
> @@ -343,8 +350,21 @@ rte_eal_config_create(void)
> if (retval < 0){
> close(mem_cfg_fd);
> mem_cfg_fd = -1;
> -   RTE_LOG(ERR, EAL, "Cannot create lock on

Re: [dpdk-dev] [PATCH] eal/freebsd: add support for base virtaddr option

[David Marchand]

On Tue, Jul 16, 2019 at 1:25 PM Anatoly Burakov
 wrote:
>
> According to our docs, only Linuxapp supports base-virtaddr option.
> That is, strictly speaking, not true because most of the things
> that are attempting to respect base-virtaddr are in common files,
> so FreeBSD already *mostly* supports this option in practice.
>
> This commit fixes the remaining bits to explicitly support
> base-virtaddr option, and moves the arg parsing from EAL to common
> options parsing code. Documentation is also updated to reflect
> that all platforms now support base-virtaddr.
>
> Signed-off-by: Anatoly Burakov 
> ---
>  doc/guides/linux_gsg/eal_args.include.rst |  6 +++
>  doc/guides/linux_gsg/linux_eal_parameters.rst |  6 ---
>  doc/guides/rel_notes/release_19_08.rst|  5 +++
>  lib/librte_eal/common/eal_common_options.c| 38 ++
>  lib/librte_eal/freebsd/eal/eal.c  | 13 ++-
>  lib/librte_eal/linux/eal/eal.c| 39 ---
>  6 files changed, 60 insertions(+), 47 deletions(-)
>
> diff --git a/doc/guides/linux_gsg/eal_args.include.rst 
> b/doc/guides/linux_gsg/eal_args.include.rst
> index cf421a56e..ed8b0e35b 100644
> --- a/doc/guides/linux_gsg/eal_args.include.rst
> +++ b/doc/guides/linux_gsg/eal_args.include.rst
> @@ -86,6 +86,12 @@ Multiprocessing-related options
>
>  Set the type of the current process.
>
> +*   ``--base-virtaddr ``
> +
> +Attempt to use a different starting address for all memory maps of the
> +primary DPDK process. This can be helpful if secondary processes cannot
> +start due to conflicts in address map.
> +

doc/guides/freebsd_gsg/freebsd_eal_parameters.rst:.. include::
../linux_gsg/eal_args.include.rst

Ok, a bit misleading to put in linux_gsg/, so writing this here if
someone else looks at this :-)


>  Memory-related options
>  ~~
>
> diff --git a/doc/guides/linux_gsg/linux_eal_parameters.rst 
> b/doc/guides/linux_gsg/linux_eal_parameters.rst
> index c63f0f49a..b2cc60e44 100644
> --- a/doc/guides/linux_gsg/linux_eal_parameters.rst
> +++ b/doc/guides/linux_gsg/linux_eal_parameters.rst
> @@ -49,12 +49,6 @@ Multiprocessing-related options
>  allows running multiple independent DPDK primary/secondary processes 
> under
>  different prefixes.
>
> -*   ``--base-virtaddr ``
> -
> -Attempt to use a different starting address for all memory maps of the
> -primary DPDK process. This can be helpful if secondary processes cannot
> -start due to conflicts in address map.
> -
>  Memory-related options
>  ~~
>
> diff --git a/doc/guides/rel_notes/release_19_08.rst 
> b/doc/guides/rel_notes/release_19_08.rst
> index 4a1fd8dd8..1b58d9282 100644
> --- a/doc/guides/rel_notes/release_19_08.rst
> +++ b/doc/guides/rel_notes/release_19_08.rst
> @@ -56,6 +56,11 @@ New Features
>   Also, make sure to start the actual text at the margin.
>   =
>
> +* **FreeBSD now supports `--base-virtaddr` EAL option.**
> +
> +  FreeBSD version now also supports setting base virtual address for mapping
> +  pages and resources into its address space.
> +
>  * **Added MCS lock.**
>
>MCS lock provides scalability by spinning on a CPU/thread local variable

Well, obviously, this needs some rebase on 19.11-rc0 :-)

> diff --git a/lib/librte_eal/common/eal_common_options.c 
> b/lib/librte_eal/common/eal_common_options.c
> index 512d5088e..156e48e19 100644
> --- a/lib/librte_eal/common/eal_common_options.c
> +++ b/lib/librte_eal/common/eal_common_options.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1095,6 +1096,36 @@ eal_parse_iova_mode(const char *name)
> return 0;
>  }
>
> +static int
> +eal_parse_base_virtaddr(const char *arg)
> +{
> +   char *end;
> +   uint64_t addr;
> +
> +   errno = 0;
> +   addr = strtoull(arg, &end, 16);
> +
> +   /* check for errors */
> +   if ((errno != 0) || (arg[0] == '\0') || end == NULL || (*end != '\0'))
> +   return -1;
> +
> +   /* make sure we don't exceed 32-bit boundary on 32-bit target */
> +#ifndef RTE_ARCH_64
> +   if (addr >= UINTPTR_MAX)
> +   return -1;
> +#endif
> +
> +   /* align the addr on 16M boundary, 16MB is the minimum huge page
> +* size on IBM Power architecture. If the addr is aligned to 16MB,
> +* it can align to 2MB for x86. So this alignment can also be used
> +* on x86 and other architectures.
> +*/
> +   internal_config.base_virtaddr =
> +   RTE_PTR_ALIGN_CEIL((uintptr_t)addr, (size_t)RTE_PGSIZE_16M);
> +
> +   return 0;
> +}
> +
>  /* caller is responsible for freeing the returned string */
>  static char *
>  available_cores(void)
> @@ -1408,6 +1439,13 @@ eal_parse_common_option(int opt, const char *optarg,
> return -1;
> }
>

Re: [dpdk-dev] [PATCH v4] eal: fix proc type auto detection

[Van Haaren, Harry]

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of David Marchand
> Sent: Monday, August 12, 2019 11:04 AM
> To: Burakov, Anatoly 
> Cc: dev ; Richardson, Bruce ;
> Stephen Hemminger ; dpdk stable 
> Subject: Re: [dpdk-dev] [PATCH v4] eal: fix proc type auto detection
> 
> On Wed, Jul 24, 2019 at 6:08 PM Anatoly Burakov
>  wrote:
> >
> > Currently, primary process holds an exclusive lock on the config
> > file, thereby preventing other primaries from spinning up. However,
> > when the primary dies, the lock is no longer being held, even though
> > there might be other secondary processes still running.
> >
> > The fix is two-fold. First of all, downgrade the primary process's
> > exclusive lock to a shared lock once we have it. Second of all,
> > also take out shared locks on the config from the secondaries. We
> > are using fcntl() locks, which get dropped when the file handle is
> > closed, so also remove the closure of config file handle.
> >
> > Fixes: af75078fece3 ("first public release")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Anatoly Burakov 


Apologies I'm late to the conversation.

Will the rte_eal_primary_proc_alive() function still detect the primary
as alive, and not confuse secondaries with primaries in this new method?

Currently, the pri_proc_alive() code uses lockf(fd, F_TEST, 0); to detect
if a primary is alive. I'm not familiar enough with shared locks to know 
if the new behavior would be consistent with the old.

-H

Re: [dpdk-dev] [PATCH] bpf: fix to allow ptr stack program type

[Jerin Jacob Kollanukkaran]

> -Original Message-
> From: Ananyev, Konstantin 
> Sent: Monday, August 12, 2019 2:20 PM
> To: Jerin Jacob Kollanukkaran ; dev@dpdk.org
> Cc: tho...@monjalon.net; sta...@dpdk.org
> Subject: [EXT] RE: [dpdk-dev] [PATCH] bpf: fix to allow ptr stack program
> type
> 
> --
> Hi Jerin,

Hi Konstantin,

> 
> >
> > bpf_validate does not allow to execute RTE_BPF_ARG_PTR_STACK for no
> > reason.
> 
> I believe there is a reason,
> ARG_PTR_STACK is reserved for memory within BPF program internal stack
> only.
> User that calls BPF program should never pass parameter with that type.

OK.
Shouldn't we remove that from public header file
(lib/librte_bpf/rte_bpf.h) then ?

> If the user allocates parameter for bpf function on the stack, he can still 
> use
> RTE_BPF_ARG_PTR for it.

I see the _stack_ is only allocated under RTE_BPF_ARG_PTR_STACK checks in 
bpf_validate.c.
Can you check? I agree that stack should be allocated for RTE_BPF_ARG_PTR as 
well.

I am writing the arm64 JIT support now, I see always stack of size of 0. I did 
not spend  much
Time on the generic piece of ebpf code(Focusing only on JIT side now).

Can you share more detail the stack allocation scheme, Is validate code parse 
the eBPF opcode and
Figure out the stack depth it by its own and pass to JIT function where Arch 
code can allocate
enough stack.



> Konstantin



> 
> > Fix it by enhancing the prog_arg.type check.
> >
> > Fixes: 6e12ec4c4d6d ("bpf: add more checks")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Jerin Jacob 
> > ---
> >  lib/librte_bpf/bpf_validate.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/lib/librte_bpf/bpf_validate.c
> > b/lib/librte_bpf/bpf_validate.c index 0cf41fa27..c75777b6d 100644
> > --- a/lib/librte_bpf/bpf_validate.c
> > +++ b/lib/librte_bpf/bpf_validate.c
> > @@ -2216,6 +2216,7 @@ bpf_validate(struct rte_bpf *bpf)
> >
> > /* check input argument type, don't allow mbuf ptr on 32-bit */
> > if (bpf->prm.prog_arg.type != RTE_BPF_ARG_RAW &&
> > +   bpf->prm.prog_arg.type !=
> RTE_BPF_ARG_PTR_STACK &&
> > bpf->prm.prog_arg.type != RTE_BPF_ARG_PTR &&
> > (sizeof(uint64_t) != sizeof(uintptr_t) ||
> > bpf->prm.prog_arg.type !=
> RTE_BPF_ARG_PTR_MBUF)) {
> > --
> > 2.22.0

Re: [dpdk-dev] [PATCH] eal: change max hugepage sizes to 4

[Burakov, Anatoly]

On 12-Aug-19 10:49 AM, David Marchand wrote:

On Mon, Aug 12, 2019 at 11:43 AM Burakov, Anatoly
 wrote:

On 08-Aug-19 8:31 AM, Thomas Monjalon wrote:

I would suggest to restrict the change to Arm only with an ifdef,
in order to limit the risk for this release.
We can think about a dynamic hugepage scan in the next release.



I don't see how this is necessary. The 3 is an arbitrary number here,
and the ABI isn't broken as this is an internal structure. We could
increase it to 16 for all i care, and it wouldn't make any difference to
the rest of the code - we never populate more than we can find anyway.


I agree on the principle.
But at the time this popped up, we were really close to the release.
It seemed a way to mitigate any unforeseen issue by limiting to the
platform that was affected.



Fair enough. A follow up is needed so. Frankly, i don't see the need to 
complicate things with "dynamic" stuff here - a static array of 8 or 16 
page sizes should be enough for everyone (TM).


--
Thanks,
Anatoly

[dpdk-dev] [PATCH v2] net/nfb: remove resources when port is closed

[Rastislav Cernay]

From: Rastislav Cernay 

The rte_eth_dev_close() function now handles freeing resources for
devices (e.g., mac_addrs).  To conform with the new close() behaviour we
are asserting the RTE_ETH_DEV_CLOSE_REMOVE flag so that
rte_eth_dev_close() releases all device level dynamic memory.

Signed-off-by: Rastislav Cernay 
Acked-by: Jan Remes 
Reviewed-by: Xiaolong Ye 
---
v2: remove unnecessary cast
 drivers/net/szedata2/rte_eth_szedata2.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/net/szedata2/rte_eth_szedata2.c 
b/drivers/net/szedata2/rte_eth_szedata2.c
index d5dec1b..99d5ca5 100644
--- a/drivers/net/szedata2/rte_eth_szedata2.c
+++ b/drivers/net/szedata2/rte_eth_szedata2.c
@@ -1157,12 +1157,15 @@ struct szedata2_tx_queue {
 static void
 eth_dev_close(struct rte_eth_dev *dev)
 {
+   struct pmd_internals *internals = dev->data->dev_private;
uint16_t i;
uint16_t nb_rx = dev->data->nb_rx_queues;
uint16_t nb_tx = dev->data->nb_tx_queues;
 
eth_dev_stop(dev);
 
+   free(internals->sze_dev_path);
+
for (i = 0; i < nb_rx; i++) {
eth_rx_queue_release(dev->data->rx_queues[i]);
dev->data->rx_queues[i] = NULL;
@@ -1173,6 +1176,9 @@ struct szedata2_tx_queue {
dev->data->tx_queues[i] = NULL;
}
dev->data->nb_tx_queues = 0;
+
+   rte_free(dev->data->mac_addrs);
+   dev->data->mac_addrs = NULL;
 }
 
 static int
@@ -1475,6 +1481,9 @@ struct szedata2_tx_queue {
PMD_INIT_LOG(INFO, "Initializing eth_dev %s (driver %s)", data->name,
RTE_STR(RTE_SZEDATA2_DRIVER_NAME));
 
+   /* Let rte_eth_dev_close() release the port resources */
+   dev->data->dev_flags |= RTE_ETH_DEV_CLOSE_REMOVE;
+
/* Fill internal private structure. */
internals->dev = dev;
/* Get index of szedata2 device file and create path to device file */
@@ -1537,12 +1546,9 @@ struct szedata2_tx_queue {
 static int
 rte_szedata2_eth_dev_uninit(struct rte_eth_dev *dev)
 {
-   struct pmd_internals *internals = (struct pmd_internals *)
-   dev->data->dev_private;
-
PMD_INIT_FUNC_TRACE();
 
-   free(internals->sze_dev_path);
+   eth_dev_close(dev);
 
PMD_DRV_LOG(INFO, "%s device %s successfully uninitialized",
RTE_STR(RTE_SZEDATA2_DRIVER_NAME), dev->data->name);
-- 
1.8.3.1

Re: [dpdk-dev] [PATCH] remove unneeded eal header inclusion

[Wiles, Keith]

> On Aug 12, 2019, at 1:53 AM, David Marchand  wrote:
> 
> Restrict this header inclusion to its real users.
> 
> Fixes: 028669bc9f0d ("eal: hide shared memory config")
> 
> Signed-off-by: David Marchand 

The only thing I would suggest is to add the name of the header file in the 
subject or body of the commit, as currently it is not obvious reading the 
commit title or body.

Regards,
Keith

Re: [dpdk-dev] [PATCH] bpf: fix to allow ptr stack program type

[Ananyev, Konstantin]

> > Hi Jerin,
> 
> Hi Konstantin,
> 
> >
> > >
> > > bpf_validate does not allow to execute RTE_BPF_ARG_PTR_STACK for no
> > > reason.
> >
> > I believe there is a reason,
> > ARG_PTR_STACK is reserved for memory within BPF program internal stack
> > only.
> > User that calls BPF program should never pass parameter with that type.
> 
> OK.
> Shouldn't we remove that from public header file
> (lib/librte_bpf/rte_bpf.h) then ?

Probably... or might be just put extra comments to mark it as internal?
The reason I left it here, so we can add new public values for enum here,
before RTE_BPF_ARG_PTR_STACK.
Of course in theory we can use for RTE_BPF_ARG_PTR_STACK some reserved
value instead.

> 
> > If the user allocates parameter for bpf function on the stack, he can still 
> > use
> > RTE_BPF_ARG_PTR for it.
> 
> I see the _stack_ is only allocated under RTE_BPF_ARG_PTR_STACK checks in 
> bpf_validate.c.
> Can you check? I agree that stack should be allocated for RTE_BPF_ARG_PTR as 
> well.

Not sure I understand your query here...
Each BPF program can use up to MAX_BPF_STACK_SIZE bytes for stack.
Though to avoid JIT to allocate unused space for the stack, in bpf_validate.c
we figure out does given BPF program really allocate things on the stack and if 
yes,
how many bytes is needed.
This info is stored in rte_bpf.stack_sz and can be used later by the JIT.
Let say for x86 jit is used in  emit_prolog().

> 
> I am writing the arm64 JIT support now, I see always stack of size of 0. I 
> did not spend  much
> Time on the generic piece of ebpf code(Focusing only on JIT side now).
> 
> Can you share more detail the stack allocation scheme, Is validate code parse 
> the eBPF opcode and
> Figure out the stack depth it by its own and pass to JIT function where Arch 
> code can allocate
> enough stack.

Yep, see above.
Konstantin


> 
> 
> >
> > > Fix it by enhancing the prog_arg.type check.
> > >
> > > Fixes: 6e12ec4c4d6d ("bpf: add more checks")
> > > Cc: sta...@dpdk.org
> > >
> > > Signed-off-by: Jerin Jacob 
> > > ---
> > >  lib/librte_bpf/bpf_validate.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/lib/librte_bpf/bpf_validate.c
> > > b/lib/librte_bpf/bpf_validate.c index 0cf41fa27..c75777b6d 100644
> > > --- a/lib/librte_bpf/bpf_validate.c
> > > +++ b/lib/librte_bpf/bpf_validate.c
> > > @@ -2216,6 +2216,7 @@ bpf_validate(struct rte_bpf *bpf)
> > >
> > >   /* check input argument type, don't allow mbuf ptr on 32-bit */
> > >   if (bpf->prm.prog_arg.type != RTE_BPF_ARG_RAW &&
> > > + bpf->prm.prog_arg.type !=
> > RTE_BPF_ARG_PTR_STACK &&
> > >   bpf->prm.prog_arg.type != RTE_BPF_ARG_PTR &&
> > >   (sizeof(uint64_t) != sizeof(uintptr_t) ||
> > >   bpf->prm.prog_arg.type !=
> > RTE_BPF_ARG_PTR_MBUF)) {
> > > --
> > > 2.22.0

[dpdk-dev] [PATCH] version: 19.11-rc0

[David Marchand]

Start a new release cycle with empty release notes.

Signed-off-by: David Marchand 
---
 VERSION|   2 +-
 doc/guides/rel_notes/release_19_11.rst | 214 +
 2 files changed, 215 insertions(+), 1 deletion(-)
 create mode 100644 doc/guides/rel_notes/release_19_11.rst

diff --git a/VERSION b/VERSION
index 909cfd6..fff18fc 100644
--- a/VERSION
+++ b/VERSION
@@ -1 +1 @@
-19.08.0
+19.11.0-rc0
diff --git a/doc/guides/rel_notes/release_19_11.rst 
b/doc/guides/rel_notes/release_19_11.rst
new file mode 100644
index 000..0bfbf19
--- /dev/null
+++ b/doc/guides/rel_notes/release_19_11.rst
@@ -0,0 +1,214 @@
+..  SPDX-License-Identifier: BSD-3-Clause
+Copyright 2019 The DPDK contributors
+
+DPDK Release 19.11
+==
+
+.. **Read this first.**
+
+   The text in the sections below explains how to update the release notes.
+
+   Use proper spelling, capitalization and punctuation in all sections.
+
+   Variable and config names should be quoted as fixed width text:
+   ``LIKE_THIS``.
+
+   Build the docs and view the output file to ensure the changes are correct::
+
+  make doc-guides-html
+
+  xdg-open build/doc/html/guides/rel_notes/release_19_11.html
+
+
+New Features
+
+
+.. This section should contain new features added in this release.
+   Sample format:
+
+   * **Add a title in the past tense with a full stop.**
+
+ Add a short 1-2 sentence description in the past tense.
+ The description should be enough to allow someone scanning
+ the release notes to understand the new feature.
+
+ If the feature adds a lot of sub-features you can use a bullet list
+ like this:
+
+ * Added feature foo to do something.
+ * Enhanced feature bar to do something else.
+
+ Refer to the previous release notes for examples.
+
+ Suggested order in release notes items:
+ * Core libs (EAL, mempool, ring, mbuf, buses)
+ * Device abstraction libs and PMDs
+   - ethdev (lib, PMDs)
+   - cryptodev (lib, PMDs)
+   - eventdev (lib, PMDs)
+   - etc
+ * Other libs
+ * Apps, Examples, Tools (if significant)
+
+ This section is a comment. Do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =
+
+
+Removed Items
+-
+
+.. This section should contain removed items in this release. Sample format:
+
+   * Add a short 1-2 sentence description of the removed item
+ in the past tense.
+
+   This section is a comment. Do not overwrite or remove it.
+   Also, make sure to start the actual text at the margin.
+   =
+
+
+API Changes
+---
+
+.. This section should contain API changes. Sample format:
+
+   * sample: Add a short 1-2 sentence description of the API change
+ which was announced in the previous releases and made in this release.
+ Start with a scope label like "ethdev:".
+ Use fixed width quotes for ``function_names`` or ``struct_names``.
+ Use the past tense.
+
+   This section is a comment. Do not overwrite or remove it.
+   Also, make sure to start the actual text at the margin.
+   =
+
+
+ABI Changes
+---
+
+.. This section should contain ABI changes. Sample format:
+
+   * sample: Add a short 1-2 sentence description of the ABI change
+ which was announced in the previous releases and made in this release.
+ Start with a scope label like "ethdev:".
+ Use fixed width quotes for ``function_names`` or ``struct_names``.
+ Use the past tense.
+
+   This section is a comment. Do not overwrite or remove it.
+   Also, make sure to start the actual text at the margin.
+   =
+
+
+Shared Library Versions
+---
+
+.. Update any library version updated in this release
+   and prepend with a ``+`` sign, like this:
+
+ libfoo.so.1
+   + libupdated.so.2
+ libbar.so.1
+
+   This section is a comment. Do not overwrite or remove it.
+   =
+
+The libraries prepended with a plus sign were incremented in this version.
+
+.. code-block:: diff
+
+ librte_acl.so.2
+ librte_bbdev.so.1
+ librte_bitratestats.so.2
+ librte_bpf.so.1
+ librte_bus_dpaa.so.2
+ librte_bus_fslmc.so.2
+ librte_bus_ifpga.so.2
+ librte_bus_pci.so.2
+ librte_bus_vdev.so.2
+ librte_bus_vmbus.so.2
+ librte_cfgfile.so.2
+ librte_cmdline.so.2
+ librte_compressdev.so.1
+ librte_cryptodev.so.7
+ librte_distributor.so.1
+ librte_eal.so.10
+ librte_efd.so.1
+ librte_ethdev.so.12
+ librte_eventdev.so.6
+ librte_flow_classify.so.1
+ librte_gro.so.1
+ librte_gso.so.1
+ librte_hash.so.2
+ librte_ip_frag.so.1
+ librte_ipsec.so.1
+ l

Re: [dpdk-dev] [v4] net/i40e: fix vf runtime queues rss config

[Aaron Conole]

Xiao Zhang  writes:

> I40evf queue can not work properly with kernel pf driver. Eg. when
> configure 8 queues pair, only 4 queues can receive packets, and half
> packets will be lost if using 2 queues pair.
> This issue is caused by misconfiguration of look up table, use aq command
> to setup the lut to make it work properly.
>
> Fixes: cea7a51c1750 ("i40evf: support RSS")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Xiao Zhang 
> ---

I see a large number of failures:

https://travis-ci.com/ovsrobot/dpdk/builds/122763118

Can you check this?

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

[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 
---
v8: Addressed v7 patch comments
v7: Updated v6 patch comments
v6: Updated comments
v5: Modified
v4: Typos corrected
v3: Modified
v2: Removed enhancement details
---
 .../prog_guide/build-sdk-meson.rst}   |   7 +-
 doc/guides/prog_guide/index.rst   |   2 +
 doc/guides/prog_guide/meson_ut.rst| 104 ++
 3 files changed, 110 insertions(+), 3 deletions(-)
 rename doc/{build-sdk-meson.txt => guides/prog_guide/build-sdk-meson.rst} (97%)
 create mode 100644 doc/guides/prog_guide/meson_ut.rst

diff --git a/doc/build-sdk-meson.txt b/doc/guides/prog_guide/build-sdk-meson.rst
similarity index 97%
rename from doc/build-sdk-meson.txt
rename to doc/guides/prog_guide/build-sdk-meson.rst
index fc7fe37b5..34c363694 100644
--- a/doc/build-sdk-meson.txt
+++ b/doc/guides/prog_guide/build-sdk-meson.rst
@@ -1,5 +1,5 @@
-INSTALLING DPDK USING THE MESON BUILD SYSTEM
--
+Installing DPDK Using the meson build system
+
 
 Summary
 
@@ -162,7 +162,8 @@ command::
 
 For example if the target machine is arm64 we can use the following
 command::
-   meson arm-build --cross-file config/arm/arm64_armv8_linux_gcc
+
+meson arm-build --cross-file config/arm/arm64_armv8_linux_gcc
 
 where config/arm/arm64_armv8_linux_gcc contains settings for the compilers
 and other build tools to be used, as well as characteristics of the target
diff --git a/doc/guides/prog_guide/index.rst b/doc/guides/prog_guide/index.rst
index 692409af8..0bab96c58 100644
--- a/doc/guides/prog_guide/index.rst
+++ b/doc/guides/prog_guide/index.rst
@@ -60,6 +60,8 @@ Programmer's Guide
 source_org
 dev_kit_build_system
 dev_kit_root_make_help
+build-sdk-meson
+meson_ut
 extend_dpdk
 build_app
 ext_app_lib_make_help
diff --git a/doc/guides/prog_guide/meson_ut.rst 
b/doc/guides/prog_guide/meson_ut.rst
new file mode 100644
index 0..45193ddde
--- /dev/null
+++ b/doc/guides/prog_guide/meson_ut.rst
@@ -0,0 +1,104 @@
+..  SPDX-License-Identifier: BSD-3-Clause
+Copyright(c) 2018-2019 Intel Corporation.
+
+Running DPDK Unit Tests with Meson
+==
+
+This section describes how to run test cases with the DPDK meson build system.
+
+Steps to build and install DPDK using meson can be referred
+in :doc:`build-sdk-meson`
+
+Grouping of test cases
+--
+
+Test cases have been classified into four different groups.
+
+* Fast tests.
+* Performance tests.
+* Driver tests.
+* Tests which produce lists of objects as output, and therefore that need
+  manual checking.
+
+These tests can be run using the argument to ``meson test`` as
+``--suite project_name:label``.
+
+For example::
+
+$ meson test -C  --suite DPDK:fast-tests
+
+If the  is current working directory,
+the ``-C `` option can be skipped as below::
+
+$ meson test --suite DPDK:fast-tests
+
+The project name is optional so the following is equivalent to the previous
+command::
+
+$ meson test --suite fast-tests
+
+The meson command to list all available tests::
+
+$ meson test --list
+
+Test cases are run serially by default for better stability.
+
+Arguments of ``test()`` that can be provided in meson.build are as below:
+
+* ``is_parallel`` is used to run test case either in parallel or non-parallel 
mode.
+* ``timeout`` is used to specify the timeout of test case.
+* ``args`` is used to specify test specific parameters.
+* ``env`` is used to specify test specific environment parameters.
+
+
+Dealing with skipped test cases
+---
+
+Some unit test cases have a dependency on external libraries, driver modules
+or config flags, without which the test cases cannot be run. Such test cases
+will be reported as skipped if they cannot run. To enable those test cases,
+the user should ensure the required dependencies are met.  Below are a few
+possible causes why tests may be skipped and how they may be resolved:
+
+#. Optional external libraries are not found.
+#. Config flags for the dependent library are not enabled.
+#. Dependent driver modules are not installed on the system.
+#. Not enough processing cores. Some tests are skipped on machines with 2 or 4 
cores.
+
+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::
+
+   $ CF

Re: [dpdk-dev] [PATCH v4] eal: fix proc type auto detection

[Burakov, Anatoly]

On 12-Aug-19 11:21 AM, Van Haaren, Harry wrote:

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of David Marchand
Sent: Monday, August 12, 2019 11:04 AM
To: Burakov, Anatoly 
Cc: dev ; Richardson, Bruce ;
Stephen Hemminger ; dpdk stable 
Subject: Re: [dpdk-dev] [PATCH v4] eal: fix proc type auto detection

On Wed, Jul 24, 2019 at 6:08 PM Anatoly Burakov
 wrote:


Currently, primary process holds an exclusive lock on the config
file, thereby preventing other primaries from spinning up. However,
when the primary dies, the lock is no longer being held, even though
there might be other secondary processes still running.

The fix is two-fold. First of all, downgrade the primary process's
exclusive lock to a shared lock once we have it. Second of all,
also take out shared locks on the config from the secondaries. We
are using fcntl() locks, which get dropped when the file handle is
closed, so also remove the closure of config file handle.

Fixes: af75078fece3 ("first public release")
Cc: sta...@dpdk.org

Signed-off-by: Anatoly Burakov 



Apologies I'm late to the conversation.

Will the rte_eal_primary_proc_alive() function still detect the primary
as alive, and not confuse secondaries with primaries in this new method?


Good question, i'll have to investigate. Maybe we'll have to change the 
lock from the fcntl() locks to flock()-based locks.




Currently, the pri_proc_alive() code uses lockf(fd, F_TEST, 0); to detect
if a primary is alive. I'm not familiar enough with shared locks to know
if the new behavior would be consistent with the old.

-H




--
Thanks,
Anatoly

Re: [dpdk-dev] [PATCH v4] eal: fix proc type auto detection

[Burakov, Anatoly]

On 12-Aug-19 11:03 AM, David Marchand wrote:

On Wed, Jul 24, 2019 at 6:08 PM Anatoly Burakov
 wrote:


Currently, primary process holds an exclusive lock on the config
file, thereby preventing other primaries from spinning up. However,
when the primary dies, the lock is no longer being held, even though
there might be other secondary processes still running.

The fix is two-fold. First of all, downgrade the primary process's
exclusive lock to a shared lock once we have it. Second of all,
also take out shared locks on the config from the secondaries. We
are using fcntl() locks, which get dropped when the file handle is
closed, so also remove the closure of config file handle.

Fixes: af75078fece3 ("first public release")
Cc: sta...@dpdk.org

Signed-off-by: Anatoly Burakov 
---





 rte_mem_cfg_addr = mmap(NULL, sizeof(*rte_config.mem_config),
 PROT_READ, MAP_SHARED, mem_cfg_fd, 0);
@@ -330,8 +360,6 @@ rte_eal_config_reattach(void)
 mem_config = (struct rte_mem_config *) mmap(rte_mem_cfg_addr,
 sizeof(*mem_config), PROT_READ | PROT_WRITE, 
MAP_SHARED,
 mem_cfg_fd, 0);
-   close(mem_cfg_fd);
-   mem_cfg_fd = -1;

 if (mem_config == MAP_FAILED) {
 RTE_LOG(ERR, EAL, "Cannot mmap memory for rte_config! error %i 
(%s)\n",


We are missing a mem_cfg_fd cleanup if mmap failed.



Good catch! Will fix.




diff --git a/lib/librte_eal/linux/eal/eal.c b/lib/librte_eal/linux/eal/eal.c
index 34db78753..0f0726703 100644
--- a/lib/librte_eal/linux/eal/eal.c
+++ b/lib/librte_eal/linux/eal/eal.c
@@ -83,6 +83,13 @@ static struct flock wr_lock = {
 .l_len = sizeof(early_mem_config.memsegs),
  };

+static struct flock rd_lock = {
+   .l_type = F_RDLCK,





-
 if (mem_config == MAP_FAILED || mem_config != rte_mem_cfg_addr) {
 if (mem_config != MAP_FAILED) {
 /* errno is stale, don't use */


Idem.

Reviewed-by: David Marchand 

With https://patchwork.dpdk.org/patch/56501/, the code is now really
close between Linux and FreeBSD, could it go to common entirely?


I would prefer to keep them separate due to upcoming Windows port.

--
Thanks,
Anatoly

Re: [dpdk-dev] [PATCH] eal/freebsd: add support for base virtaddr option

[Burakov, Anatoly]

On 12-Aug-19 11:19 AM, David Marchand wrote:

On Tue, Jul 16, 2019 at 1:25 PM Anatoly Burakov
 wrote:


According to our docs, only Linuxapp supports base-virtaddr option.
That is, strictly speaking, not true because most of the things
that are attempting to respect base-virtaddr are in common files,
so FreeBSD already *mostly* supports this option in practice.

This commit fixes the remaining bits to explicitly support
base-virtaddr option, and moves the arg parsing from EAL to common
options parsing code. Documentation is also updated to reflect
that all platforms now support base-virtaddr.

Signed-off-by: Anatoly Burakov 
---
  doc/guides/linux_gsg/eal_args.include.rst |  6 +++
  doc/guides/linux_gsg/linux_eal_parameters.rst |  6 ---
  doc/guides/rel_notes/release_19_08.rst|  5 +++
  lib/librte_eal/common/eal_common_options.c| 38 ++
  lib/librte_eal/freebsd/eal/eal.c  | 13 ++-
  lib/librte_eal/linux/eal/eal.c| 39 ---
  6 files changed, 60 insertions(+), 47 deletions(-)

diff --git a/doc/guides/linux_gsg/eal_args.include.rst 
b/doc/guides/linux_gsg/eal_args.include.rst
index cf421a56e..ed8b0e35b 100644
--- a/doc/guides/linux_gsg/eal_args.include.rst
+++ b/doc/guides/linux_gsg/eal_args.include.rst
@@ -86,6 +86,12 @@ Multiprocessing-related options

  Set the type of the current process.

+*   ``--base-virtaddr ``
+
+Attempt to use a different starting address for all memory maps of the
+primary DPDK process. This can be helpful if secondary processes cannot
+start due to conflicts in address map.
+


doc/guides/freebsd_gsg/freebsd_eal_parameters.rst:.. include::
../linux_gsg/eal_args.include.rst

Ok, a bit misleading to put in linux_gsg/, so writing this here if
someone else looks at this :-)


This was agreed upon when this file was first introduced. We don't have 
a "common" section and there's no real way to create it without 
triggering a bunch of errors in doxygen, so it was decided that putting 
this in a Linux GSG is the best way to do this.






  Memory-related options
  ~~

diff --git a/doc/guides/linux_gsg/linux_eal_parameters.rst 
b/doc/guides/linux_gsg/linux_eal_parameters.rst
index c63f0f49a..b2cc60e44 100644
--- a/doc/guides/linux_gsg/linux_eal_parameters.rst
+++ b/doc/guides/linux_gsg/linux_eal_parameters.rst
@@ -49,12 +49,6 @@ Multiprocessing-related options
  allows running multiple independent DPDK primary/secondary processes under
  different prefixes.

-*   ``--base-virtaddr ``
-
-Attempt to use a different starting address for all memory maps of the
-primary DPDK process. This can be helpful if secondary processes cannot
-start due to conflicts in address map.
-
  Memory-related options
  ~~

diff --git a/doc/guides/rel_notes/release_19_08.rst 
b/doc/guides/rel_notes/release_19_08.rst
index 4a1fd8dd8..1b58d9282 100644
--- a/doc/guides/rel_notes/release_19_08.rst
+++ b/doc/guides/rel_notes/release_19_08.rst
@@ -56,6 +56,11 @@ New Features
   Also, make sure to start the actual text at the margin.
   =

+* **FreeBSD now supports `--base-virtaddr` EAL option.**
+
+  FreeBSD version now also supports setting base virtual address for mapping
+  pages and resources into its address space.
+
  * **Added MCS lock.**

MCS lock provides scalability by spinning on a CPU/thread local variable


Well, obviously, this needs some rebase on 19.11-rc0 :-)


Yes, will do.




diff --git a/lib/librte_eal/common/eal_common_options.c 
b/lib/librte_eal/common/eal_common_options.c
index 512d5088e..156e48e19 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -20,6 +20,7 @@
  #include 
  #include 





-   rte_mem_cfg_addr = mmap(NULL, sizeof(*rte_config.mem_config),
-   PROT_READ | PROT_WRITE, MAP_SHARED, mem_cfg_fd, 
0);
+   rte_mem_cfg_addr = mmap(rte_mem_cfg_addr,
+   sizeof(*rte_config.mem_config), PROT_READ | PROT_WRITE,
+   MAP_SHARED, mem_cfg_fd, 0);

 if (rte_mem_cfg_addr == MAP_FAILED){
 RTE_LOG(ERR, EAL, "Cannot mmap memory for rte_config\n");


Nit: when compared to Linux implementation, the reattach step does not
recommend using the --base-virtaddr in case the remmapping failed.



Good catch, will fix.




diff --git a/lib/librte_eal/linux/eal/eal.c b/lib/librte_eal/linux/eal/eal.c
index 2e5499f9b..79f5d70c3 100644
--- a/lib/librte_eal/linux/eal/eal.c
+++ b/lib/librte_eal/linux/eal/eal.c
@@ -609,35 +609,6 @@ eal_parse_socket_arg(char *strval, volatile uint64_t 
*socket_arg)
 return 0;
  }





Reviewed-by: David Marchand 




--
Thanks,
Anatoly

[dpdk-dev] [RFC v1 3/3] net/ice: support the Rx/Tx burst description field in queue information

[Haiyue Wang]

According to the Rx/Tx burst function that's selected currently, format
the distinct burst description information for apps to query.

Signed-off-by: Haiyue Wang 
---
 drivers/net/ice/ice_rxtx.c | 49 ++
 1 file changed, 49 insertions(+)

diff --git a/drivers/net/ice/ice_rxtx.c b/drivers/net/ice/ice_rxtx.c
index 0282b53..9e6b1f7 100644
--- a/drivers/net/ice/ice_rxtx.c
+++ b/drivers/net/ice/ice_rxtx.c
@@ -15,6 +15,16 @@
 
 #define ICE_RX_ERR_BITS 0x3f
 
+static uint16_t ice_recv_scattered_pkts(void *rx_queue,
+   struct rte_mbuf **rx_pkts,
+   uint16_t nb_pkts);
+static uint16_t ice_recv_pkts_bulk_alloc(void *rx_queue,
+struct rte_mbuf **rx_pkts,
+uint16_t nb_pkts);
+static uint16_t ice_xmit_pkts_simple(void *tx_queue,
+struct rte_mbuf **tx_pkts,
+uint16_t nb_pkts);
+
 static enum ice_status
 ice_program_hw_rx_queue(struct ice_rx_queue *rxq)
 {
@@ -935,6 +945,30 @@ ice_rxq_info_get(struct rte_eth_dev *dev, uint16_t 
queue_id,
qinfo->conf.rx_free_thresh = rxq->rx_free_thresh;
qinfo->conf.rx_drop_en = rxq->drop_en;
qinfo->conf.rx_deferred_start = rxq->rx_deferred_start;
+
+   if (dev->rx_pkt_burst == ice_recv_scattered_pkts)
+   snprintf(qinfo->burst_info, sizeof(qinfo->burst_info),
+"Scattered Rx");
+   else if (dev->rx_pkt_burst == ice_recv_pkts_bulk_alloc)
+   snprintf(qinfo->burst_info, sizeof(qinfo->burst_info),
+"Bulk Rx");
+   else if (dev->rx_pkt_burst == ice_recv_pkts)
+   snprintf(qinfo->burst_info, sizeof(qinfo->burst_info),
+"Normal Rx");
+#ifdef RTE_ARCH_X86
+   else if (dev->rx_pkt_burst == ice_recv_scattered_pkts_vec_avx2)
+   snprintf(qinfo->burst_info, sizeof(qinfo->burst_info),
+"AVX2 Vector Scattered Rx");
+   else if (dev->rx_pkt_burst == ice_recv_scattered_pkts_vec)
+   snprintf(qinfo->burst_info, sizeof(qinfo->burst_info),
+"Vector Scattered Rx");
+   else if (dev->rx_pkt_burst == ice_recv_pkts_vec_avx2)
+   snprintf(qinfo->burst_info, sizeof(qinfo->burst_info),
+"AVX2 Vector Rx");
+   else if (dev->rx_pkt_burst == ice_recv_pkts_vec)
+   snprintf(qinfo->burst_info, sizeof(qinfo->burst_info),
+"Vector Rx");
+#endif
 }
 
 void
@@ -955,6 +989,21 @@ ice_txq_info_get(struct rte_eth_dev *dev, uint16_t 
queue_id,
qinfo->conf.tx_rs_thresh = txq->tx_rs_thresh;
qinfo->conf.offloads = txq->offloads;
qinfo->conf.tx_deferred_start = txq->tx_deferred_start;
+
+   if (dev->tx_pkt_burst == ice_xmit_pkts_simple)
+   snprintf(qinfo->burst_info, sizeof(qinfo->burst_info),
+"Simple Tx");
+   else if (dev->tx_pkt_burst == ice_xmit_pkts)
+   snprintf(qinfo->burst_info, sizeof(qinfo->burst_info),
+"Normal Tx");
+#ifdef RTE_ARCH_X86
+   else if (dev->tx_pkt_burst == ice_xmit_pkts_vec_avx2)
+   snprintf(qinfo->burst_info, sizeof(qinfo->burst_info),
+"AVX2 Vector Tx");
+   else if (dev->tx_pkt_burst == ice_xmit_pkts_vec)
+   snprintf(qinfo->burst_info, sizeof(qinfo->burst_info),
+"Vector Tx");
+#endif
 }
 
 uint32_t
-- 
2.7.4

[dpdk-dev] [RFC v1 2/3] testpmd: show the Rx/Tx burst description field in queue

[Haiyue Wang]

Add the 'Burst description' section into command 'show rxq|txq info
 ' to show the Rx/Tx burst description field in
queue information.

Signed-off-by: Haiyue Wang 
---
 app/test-pmd/config.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 1a5a5c1..69607ba 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -354,6 +354,7 @@ rx_queue_infos_display(portid_t port_id, uint16_t queue_id)
printf("\nRX scattered packets: %s",
(qinfo.scattered_rx != 0) ? "on" : "off");
printf("\nNumber of RXDs: %hu", qinfo.nb_desc);
+   printf("\nBurst description: %s\n", qinfo.burst_info);
printf("\n");
 }
 
@@ -383,6 +384,7 @@ tx_queue_infos_display(portid_t port_id, uint16_t queue_id)
printf("\nTX deferred start: %s",
(qinfo.conf.tx_deferred_start != 0) ? "on" : "off");
printf("\nNumber of TXDs: %hu", qinfo.nb_desc);
+   printf("\nBurst description: %s\n", qinfo.burst_info);
printf("\n");
 }
 
-- 
2.7.4

[dpdk-dev] [RFC v1 1/3] ethdev: add the Rx/Tx burst description field in queue information

[Haiyue Wang]

Since each PMD has different Rx/Tx burst capabilities such as Vector,
Scattered, Bulk etc, adding the Rx/Tx burst description field in queue
information to provide apps current configuration of PMD Rx/Tx burst.

This is a self-description for each PMD in its own format.

Signed-off-by: Haiyue Wang 
---
 lib/librte_ethdev/rte_ethdev.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index dc6596b..bc48c0c 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -1192,6 +1192,9 @@ struct rte_eth_dev_info {
struct rte_eth_switch_info switch_info;
 };
 
+/** Maximum information length to describe the PMD RX/TX functions */
+#define RTE_PMD_BURST_INFO_SIZE128
+
 /**
  * Ethernet device RX queue information structure.
  * Used to retrieve information about configured queue.
@@ -1201,6 +1204,8 @@ struct rte_eth_rxq_info {
struct rte_eth_rxconf conf; /**< queue config parameters. */
uint8_t scattered_rx;   /**< scattered packets RX supported. */
uint16_t nb_desc;   /**< configured number of RXDs. */
+   char burst_info[RTE_PMD_BURST_INFO_SIZE];
+   /**< Description of PMD RX function, such as Vector, Scattered etc */
 } __rte_cache_min_aligned;
 
 /**
@@ -1210,6 +1215,8 @@ struct rte_eth_rxq_info {
 struct rte_eth_txq_info {
struct rte_eth_txconf conf; /**< queue config parameters. */
uint16_t nb_desc;   /**< configured number of TXDs. */
+   char burst_info[RTE_PMD_BURST_INFO_SIZE];
+   /**< Description of PMD TX function, such as Vector, Scattered etc */
 } __rte_cache_min_aligned;
 
 /** Maximum name length for extended statistics counters */
-- 
2.7.4

[dpdk-dev] [RFC v1 0/3] show the Rx/Tx burst description field

[Haiyue Wang]

Since some PMDs have multi-path for Rx/Tx, FD.io VPP will tell you in
the Debug CLI what rx/tx function is being used:
#show hardware-interface
 
 tx burst function: ice_xmit_pkts
 rx burst function: ice_recv_scattered_pkts

But if the tx/rx is static, then 'dladdr' will return nil:

 tx burst function: (nil) │··
 rx burst function: (nil) │··

For making things consistent and gracefull, we introduce an new string
field to describe the Rx/Tx burst information. This is vendor-neutral,
it is used to identify the Rx/Tx burst selection if the PMD has more
than one.  

If a PMD supports this, then rxqinfo/txqinfo->burst_info[0] != '\0'.

This is for net/ice PMD result.

testpmd> show rxq info 0 0

* Infos for port 0 , RX queue 0  *
Mempool: mbuf_pool_socket_0
RX prefetch threshold: 0
RX host threshold: 0
RX writeback threshold: 0
RX free threshold: 32
RX drop packets: off
RX deferred start: off
RX scattered packets: on
Number of RXDs: 1024
Burst description: AVX2 Vector Scattered Rx < NEW

testpmd> show txq info 0 0

* Infos for port 0 , TX queue 0  *
TX prefetch threshold: 32
TX host threshold: 0
TX writeback threshold: 0
TX RS threshold: 32
TX free threshold: 32
TX deferred start: off
Number of TXDs: 1024
Burst description: AVX2 Vector Tx < NEW

Haiyue Wang (3):
  ethdev: add the Rx/Tx burst description field in queue information
  testpmd: show the Rx/Tx burst description field in queue
  net/ice: support the Rx/Tx burst description field in queue
information

 app/test-pmd/config.c  |  2 ++
 drivers/net/ice/ice_rxtx.c | 49 ++
 lib/librte_ethdev/rte_ethdev.h |  7 ++
 3 files changed, 58 insertions(+)

-- 
2.7.4

Re: [dpdk-dev] [RFC v1 0/3] show the Rx/Tx burst description field

[David Marchand]

On Mon, Aug 12, 2019 at 4:20 PM Haiyue Wang  wrote:
>
> Since some PMDs have multi-path for Rx/Tx, FD.io VPP will tell you in
> the Debug CLI what rx/tx function is being used:
> #show hardware-interface
>
>  tx burst function: ice_xmit_pkts
>  rx burst function: ice_recv_scattered_pkts
>
> But if the tx/rx is static, then 'dladdr' will return nil:
>
>  tx burst function: (nil) │··
>  rx burst function: (nil) │··
>
> For making things consistent and gracefull, we introduce an new string
> field to describe the Rx/Tx burst information. This is vendor-neutral,
> it is used to identify the Rx/Tx burst selection if the PMD has more
> than one.
>
> If a PMD supports this, then rxqinfo/txqinfo->burst_info[0] != '\0'.

The rx/tx handlers are the same for all queues of a ethdev port.
What is the added value to put this in a per queue api ?


-- 
David Marchand

Re: [dpdk-dev] [RFC v1 1/3] ethdev: add the Rx/Tx burst description field in queue information

[Stephen Hemminger]

On Mon, 12 Aug 2019 22:15:03 +0800
Haiyue Wang  wrote:

> Since each PMD has different Rx/Tx burst capabilities such as Vector,
> Scattered, Bulk etc, adding the Rx/Tx burst description field in queue
> information to provide apps current configuration of PMD Rx/Tx burst.
> 
> This is a self-description for each PMD in its own format.
> 
> Signed-off-by: Haiyue Wang 

I can see why it might help with diagnosing issues on VPP,
but it would have bigger impacts for other users of DPDK.

Think of a better way that doesn't break ABI.
This is not enough value to make the DPDK more unstable.

Re: [dpdk-dev] [RFC v1 0/3] show the Rx/Tx burst description field

[Stephen Hemminger]

On Mon, 12 Aug 2019 16:27:11 +0200
David Marchand  wrote:

> On Mon, Aug 12, 2019 at 4:20 PM Haiyue Wang  wrote:
> >
> > Since some PMDs have multi-path for Rx/Tx, FD.io VPP will tell you in
> > the Debug CLI what rx/tx function is being used:
> > #show hardware-interface
> >
> >  tx burst function: ice_xmit_pkts
> >  rx burst function: ice_recv_scattered_pkts
> >
> > But if the tx/rx is static, then 'dladdr' will return nil:
> >
> >  tx burst function: (nil) │··
> >  rx burst function: (nil) │··
> >
> > For making things consistent and gracefull, we introduce an new string
> > field to describe the Rx/Tx burst information. This is vendor-neutral,
> > it is used to identify the Rx/Tx burst selection if the PMD has more
> > than one.
> >
> > If a PMD supports this, then rxqinfo/txqinfo->burst_info[0] != '\0'.  
> 
> The rx/tx handlers are the same for all queues of a ethdev port.
> What is the added value to put this in a per queue api ?

With some symbol table lookup tools it is possible to do introspection
to find the symbol from the function pointer. Without breaking API/ABI.

Re: [dpdk-dev] [RFC v1 0/3] show the Rx/Tx burst description field

[Wang, Haiyue]

> -Original Message-
> From: David Marchand [mailto:david.march...@redhat.com]
> Sent: Monday, August 12, 2019 22:27
> To: Wang, Haiyue 
> Cc: dev 
> Subject: Re: [dpdk-dev] [RFC v1 0/3] show the Rx/Tx burst description field
> 
> On Mon, Aug 12, 2019 at 4:20 PM Haiyue Wang  wrote:
> >
> > Since some PMDs have multi-path for Rx/Tx, FD.io VPP will tell you in
> > the Debug CLI what rx/tx function is being used:
> > #show hardware-interface
> >
> >  tx burst function: ice_xmit_pkts
> >  rx burst function: ice_recv_scattered_pkts
> >
> > But if the tx/rx is static, then 'dladdr' will return nil:
> >
> >  tx burst function: (nil) │··
> >  rx burst function: (nil) │··
> >
> > For making things consistent and gracefull, we introduce an new string
> > field to describe the Rx/Tx burst information. This is vendor-neutral,
> > it is used to identify the Rx/Tx burst selection if the PMD has more
> > than one.
> >
> > If a PMD supports this, then rxqinfo/txqinfo->burst_info[0] != '\0'.
> 
> The rx/tx handlers are the same for all queues of a ethdev port.
> What is the added value to put this in a per queue api ?
> 

We will add support Receive Flex Descriptor per queue in 19.11:
drivers/net/ice/base/ice_lan_tx_rx.h --> enum ice_rxdid

Then the burst_info will be Vector (generic info) + RXDID info,
that's why we changed the design from const char * to char [].

> 
> --
> David Marchand

Re: [dpdk-dev] [RFC v1 0/3] show the Rx/Tx burst description field

[Wang, Haiyue]

> -Original Message-
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Monday, August 12, 2019 23:38
> To: David Marchand 
> Cc: Wang, Haiyue ; dev 
> Subject: Re: [dpdk-dev] [RFC v1 0/3] show the Rx/Tx burst description field
> 
> On Mon, 12 Aug 2019 16:27:11 +0200
> David Marchand  wrote:
> 
> > On Mon, Aug 12, 2019 at 4:20 PM Haiyue Wang  wrote:
> > >
> > > Since some PMDs have multi-path for Rx/Tx, FD.io VPP will tell you in
> > > the Debug CLI what rx/tx function is being used:
> > > #show hardware-interface
> > >
> > >  tx burst function: ice_xmit_pkts
> > >  rx burst function: ice_recv_scattered_pkts
> > >
> > > But if the tx/rx is static, then 'dladdr' will return nil:
> > >
> > >  tx burst function: (nil) │··
> > >  rx burst function: (nil) │··
> > >
> > > For making things consistent and gracefull, we introduce an new string
> > > field to describe the Rx/Tx burst information. This is vendor-neutral,
> > > it is used to identify the Rx/Tx burst selection if the PMD has more
> > > than one.
> > >
> > > If a PMD supports this, then rxqinfo/txqinfo->burst_info[0] != '\0'.
> >
> > The rx/tx handlers are the same for all queues of a ethdev port.
> > What is the added value to put this in a per queue api ?
> 
> With some symbol table lookup tools it is possible to do introspection
> to find the symbol from the function pointer. Without breaking API/ABI.

Sounds cool, any link can be reached ?

VPP uses as below, but will fail for static function.

static const char *
ptr2sname (void *p)
{
  Dl_info info = { 0 };

  if (dladdr (p, &info) == 0)
return 0;

  return info.dli_sname;
}

Re: [dpdk-dev] [RFC v1 0/3] show the Rx/Tx burst description field

[Stephen Hemminger]

On Mon, 12 Aug 2019 15:42:45 +
"Wang, Haiyue"  wrote:

> > -Original Message-
> > From: Stephen Hemminger [mailto:step...@networkplumber.org]
> > Sent: Monday, August 12, 2019 23:38
> > To: David Marchand 
> > Cc: Wang, Haiyue ; dev 
> > Subject: Re: [dpdk-dev] [RFC v1 0/3] show the Rx/Tx burst description field
> > 
> > On Mon, 12 Aug 2019 16:27:11 +0200
> > David Marchand  wrote:
> >   
> > > On Mon, Aug 12, 2019 at 4:20 PM Haiyue Wang  
> > > wrote:  
> > > >
> > > > Since some PMDs have multi-path for Rx/Tx, FD.io VPP will tell you in
> > > > the Debug CLI what rx/tx function is being used:
> > > > #show hardware-interface
> > > >
> > > >  tx burst function: ice_xmit_pkts
> > > >  rx burst function: ice_recv_scattered_pkts
> > > >
> > > > But if the tx/rx is static, then 'dladdr' will return nil:
> > > >
> > > >  tx burst function: (nil) │··
> > > >  rx burst function: (nil) │··
> > > >
> > > > For making things consistent and gracefull, we introduce an new string
> > > > field to describe the Rx/Tx burst information. This is vendor-neutral,
> > > > it is used to identify the Rx/Tx burst selection if the PMD has more
> > > > than one.
> > > >
> > > > If a PMD supports this, then rxqinfo/txqinfo->burst_info[0] != '\0'.  
> > >
> > > The rx/tx handlers are the same for all queues of a ethdev port.
> > > What is the added value to put this in a per queue api ?  
> > 
> > With some symbol table lookup tools it is possible to do introspection
> > to find the symbol from the function pointer. Without breaking API/ABI.  
> 
> Sounds cool, any link can be reached ?
> 
> VPP uses as below, but will fail for static function.
> 
> static const char *
> ptr2sname (void *p)
> {
>   Dl_info info = { 0 };
> 
>   if (dladdr (p, &info) == 0)
> return 0;
> 
>   return info.dli_sname;
> }

You need to link with -g and not strip the binary.

Re: [dpdk-dev] [RFC v1 0/3] show the Rx/Tx burst description field

[Wang, Haiyue]

> -Original Message-
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Monday, August 12, 2019 23:54
> To: Wang, Haiyue 
> Cc: David Marchand ; dev 
> Subject: Re: [dpdk-dev] [RFC v1 0/3] show the Rx/Tx burst description field
> 
> On Mon, 12 Aug 2019 15:42:45 +
> "Wang, Haiyue"  wrote:
> 
> > > -Original Message-
> > > From: Stephen Hemminger [mailto:step...@networkplumber.org]
> > > Sent: Monday, August 12, 2019 23:38
> > > To: David Marchand 
> > > Cc: Wang, Haiyue ; dev 
> > > Subject: Re: [dpdk-dev] [RFC v1 0/3] show the Rx/Tx burst description 
> > > field
> > >
> > > On Mon, 12 Aug 2019 16:27:11 +0200
> > > David Marchand  wrote:
> > >
> > > > On Mon, Aug 12, 2019 at 4:20 PM Haiyue Wang  
> > > > wrote:
> > > > >
> > > > > Since some PMDs have multi-path for Rx/Tx, FD.io VPP will tell you in
> > > > > the Debug CLI what rx/tx function is being used:
> > > > > #show hardware-interface
> > > > >
> > > > >  tx burst function: ice_xmit_pkts
> > > > >  rx burst function: ice_recv_scattered_pkts
> > > > >
> > > > > But if the tx/rx is static, then 'dladdr' will return nil:
> > > > >
> > > > >  tx burst function: (nil) │··
> > > > >  rx burst function: (nil) │··
> > > > >
> > > > > For making things consistent and gracefull, we introduce an new string
> > > > > field to describe the Rx/Tx burst information. This is vendor-neutral,
> > > > > it is used to identify the Rx/Tx burst selection if the PMD has more
> > > > > than one.
> > > > >
> > > > > If a PMD supports this, then rxqinfo/txqinfo->burst_info[0] != '\0'.
> > > >
> > > > The rx/tx handlers are the same for all queues of a ethdev port.
> > > > What is the added value to put this in a per queue api ?
> > >
> > > With some symbol table lookup tools it is possible to do introspection
> > > to find the symbol from the function pointer. Without breaking API/ABI.
> >
> > Sounds cool, any link can be reached ?
> >
> > VPP uses as below, but will fail for static function.
> >
> > static const char *
> > ptr2sname (void *p)
> > {
> >   Dl_info info = { 0 };
> >
> >   if (dladdr (p, &info) == 0)
> > return 0;
> >
> >   return info.dli_sname;
> > }
> 
> You need to link with -g and not strip the binary.

You mean gdb debug mode, I guess they will not accept this also. ;-)

Re: [dpdk-dev] [RFC v1 0/3] show the Rx/Tx burst description field

[Stephen Hemminger]

On Mon, 12 Aug 2019 16:00:27 +
"Wang, Haiyue"  wrote:

> > -Original Message-
> > From: Stephen Hemminger [mailto:step...@networkplumber.org]
> > Sent: Monday, August 12, 2019 23:54
> > To: Wang, Haiyue 
> > Cc: David Marchand ; dev 
> > Subject: Re: [dpdk-dev] [RFC v1 0/3] show the Rx/Tx burst description field
> > 
> > On Mon, 12 Aug 2019 15:42:45 +
> > "Wang, Haiyue"  wrote:
> >   
> > > > -Original Message-
> > > > From: Stephen Hemminger [mailto:step...@networkplumber.org]
> > > > Sent: Monday, August 12, 2019 23:38
> > > > To: David Marchand 
> > > > Cc: Wang, Haiyue ; dev 
> > > > Subject: Re: [dpdk-dev] [RFC v1 0/3] show the Rx/Tx burst description 
> > > > field
> > > >
> > > > On Mon, 12 Aug 2019 16:27:11 +0200
> > > > David Marchand  wrote:
> > > >  
> > > > > On Mon, Aug 12, 2019 at 4:20 PM Haiyue Wang  
> > > > > wrote:  
> > > > > >
> > > > > > Since some PMDs have multi-path for Rx/Tx, FD.io VPP will tell you 
> > > > > > in
> > > > > > the Debug CLI what rx/tx function is being used:
> > > > > > #show hardware-interface
> > > > > >
> > > > > >  tx burst function: ice_xmit_pkts
> > > > > >  rx burst function: ice_recv_scattered_pkts
> > > > > >
> > > > > > But if the tx/rx is static, then 'dladdr' will return nil:
> > > > > >
> > > > > >  tx burst function: (nil) │··
> > > > > >  rx burst function: (nil) │··
> > > > > >
> > > > > > For making things consistent and gracefull, we introduce an new 
> > > > > > string
> > > > > > field to describe the Rx/Tx burst information. This is 
> > > > > > vendor-neutral,
> > > > > > it is used to identify the Rx/Tx burst selection if the PMD has more
> > > > > > than one.
> > > > > >
> > > > > > If a PMD supports this, then rxqinfo/txqinfo->burst_info[0] != 
> > > > > > '\0'.  
> > > > >
> > > > > The rx/tx handlers are the same for all queues of a ethdev port.
> > > > > What is the added value to put this in a per queue api ?  
> > > >
> > > > With some symbol table lookup tools it is possible to do introspection
> > > > to find the symbol from the function pointer. Without breaking API/ABI. 
> > > >  
> > >
> > > Sounds cool, any link can be reached ?
> > >
> > > VPP uses as below, but will fail for static function.
> > >
> > > static const char *
> > > ptr2sname (void *p)
> > > {
> > >   Dl_info info = { 0 };
> > >
> > >   if (dladdr (p, &info) == 0)
> > > return 0;
> > >
> > >   return info.dli_sname;
> > > }  
> > 
> > You need to link with -g and not strip the binary.  
> 
> You mean gdb debug mode, I guess they will not accept this also. ;-)

There other ways to mark symbol as non-debug but -g is easiest.
One way is to not mark the function as static.
Other ways are to achieve the same think like __attribute((visibility())
and linker scripts etc.

Remember this is VPP you are talking about and it doesn't use standard
DPDK make and flags.

Re: [dpdk-dev] [RFC v1 0/3] show the Rx/Tx burst description field

[Wang, Haiyue]

> -Original Message-
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Tuesday, August 13, 2019 01:29
> To: Wang, Haiyue 
> Cc: David Marchand ; dev 
> Subject: Re: [dpdk-dev] [RFC v1 0/3] show the Rx/Tx burst description field
> 
> On Mon, 12 Aug 2019 16:00:27 +
> "Wang, Haiyue"  wrote:
> 
> > > -Original Message-
> > > From: Stephen Hemminger [mailto:step...@networkplumber.org]
> > > Sent: Monday, August 12, 2019 23:54
> > > To: Wang, Haiyue 
> > > Cc: David Marchand ; dev 
> > > Subject: Re: [dpdk-dev] [RFC v1 0/3] show the Rx/Tx burst description 
> > > field
> > >
> > > On Mon, 12 Aug 2019 15:42:45 +
> > > "Wang, Haiyue"  wrote:
> > >
> > > > > -Original Message-
> > > > > From: Stephen Hemminger [mailto:step...@networkplumber.org]
> > > > > Sent: Monday, August 12, 2019 23:38
> > > > > To: David Marchand 
> > > > > Cc: Wang, Haiyue ; dev 
> > > > > Subject: Re: [dpdk-dev] [RFC v1 0/3] show the Rx/Tx burst description 
> > > > > field
> > > > >
> > > > > On Mon, 12 Aug 2019 16:27:11 +0200
> > > > > David Marchand  wrote:
> > > > >
> > > > > > On Mon, Aug 12, 2019 at 4:20 PM Haiyue Wang  
> > > > > > wrote:
> > > > > > >
> > > > > > > Since some PMDs have multi-path for Rx/Tx, FD.io VPP will tell 
> > > > > > > you in
> > > > > > > the Debug CLI what rx/tx function is being used:
> > > > > > > #show hardware-interface
> > > > > > >
> > > > > > >  tx burst function: ice_xmit_pkts
> > > > > > >  rx burst function: ice_recv_scattered_pkts
> > > > > > >
> > > > > > > But if the tx/rx is static, then 'dladdr' will return nil:
> > > > > > >
> > > > > > >  tx burst function: (nil) │··
> > > > > > >  rx burst function: (nil) │··
> > > > > > >
> > > > > > > For making things consistent and gracefull, we introduce an new 
> > > > > > > string
> > > > > > > field to describe the Rx/Tx burst information. This is 
> > > > > > > vendor-neutral,
> > > > > > > it is used to identify the Rx/Tx burst selection if the PMD has 
> > > > > > > more
> > > > > > > than one.
> > > > > > >
> > > > > > > If a PMD supports this, then rxqinfo/txqinfo->burst_info[0] != 
> > > > > > > '\0'.
> > > > > >
> > > > > > The rx/tx handlers are the same for all queues of a ethdev port.
> > > > > > What is the added value to put this in a per queue api ?
> > > > >
> > > > > With some symbol table lookup tools it is possible to do introspection
> > > > > to find the symbol from the function pointer. Without breaking 
> > > > > API/ABI.
> > > >
> > > > Sounds cool, any link can be reached ?
> > > >
> > > > VPP uses as below, but will fail for static function.
> > > >
> > > > static const char *
> > > > ptr2sname (void *p)
> > > > {
> > > >   Dl_info info = { 0 };
> > > >
> > > >   if (dladdr (p, &info) == 0)
> > > > return 0;
> > > >
> > > >   return info.dli_sname;
> > > > }
> > >
> > > You need to link with -g and not strip the binary.
> >
> > You mean gdb debug mode, I guess they will not accept this also. ;-)
> 
> There other ways to mark symbol as non-debug but -g is easiest.
> One way is to not mark the function as static.
> Other ways are to achieve the same think like __attribute((visibility())
> and linker scripts etc.
> 
> Remember this is VPP you are talking about and it doesn't use standard
> DPDK make and flags.
> 

Yes, this calling is a little geek style, so we are trying to scratch
some code to make thing graceful, at least, this makes sense if multiple
rx /tx paths are provided.

Thanks for your quick feedback, we will try to find other possible design.

Re: [dpdk-dev] [PATCH] buildtools: lighter experimental symbol check

[Neil Horman]

On Mon, Aug 12, 2019 at 09:02:28AM +0200, David Marchand wrote:
> Dumping every object file for every symbol is too heavy.
> Use a temporary storage.
> 
> Before:
> $ rm -rf master && make defconfig O=master
> $ time make EXTRA_CFLAGS=-g O=master
> [...]
> real  2m24.063s
> user  1m16.985s
> sys   1m46.372s
> 
> After:
> $ rm -rf master && make defconfig O=master
> $ time make EXTRA_CFLAGS=-g O=master
> [...]
> real  1m37.110s
> user  0m49.417s
> sys   0m51.803s
> 
> Signed-off-by: David Marchand 
> ---
>  buildtools/check-experimental-syms.sh | 15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/buildtools/check-experimental-syms.sh 
> b/buildtools/check-experimental-syms.sh
> index 0f6c62d..47a06fc 100755
> --- a/buildtools/check-experimental-syms.sh
> +++ b/buildtools/check-experimental-syms.sh
> @@ -18,14 +18,15 @@ then
>   exit 0
>  fi
>  
> +DUMPFILE=$(mktemp -t dpdk.${0##*/}.XXX.objdump)
> +trap 'rm -f "$DUMPFILE"' EXIT
> +objdump -t $OBJFILE >$DUMPFILE
> +
When does this temporary file get deleted?

[dpdk-dev] [PATCH 0/6] build system improvements

[Thomas Monjalon]

While testing compilation of mlx drivers,
I hit some issues and misses.
The result is 6 patches of cleanup, fixes and test improvements.

Thomas Monjalon (6):
  build: remove redundant libs from pkgconfig
  drivers: add some reasons for meson disabling
  net/mlx: fix meson build with custom dependency path
  net/mlx: fix build with make and recent gcc
  devtools: test compiler availability only once
  devtools: load target-specific compilation environment

 devtools/test-meson-builds.sh | 52 +--
 drivers/baseband/turbo_sw/meson.build |  1 +
 drivers/compress/isal/meson.build |  1 -
 drivers/net/af_xdp/meson.build|  1 -
 drivers/net/memif/meson.build |  5 +--
 drivers/net/mlx4/Makefile |  3 +-
 drivers/net/mlx4/meson.build  |  9 ++---
 drivers/net/mlx5/Makefile |  3 +-
 drivers/net/mlx5/meson.build  |  7 ++--
 drivers/raw/ioat/meson.build  |  1 +
 10 files changed, 52 insertions(+), 31 deletions(-)

-- 
2.22.0

[dpdk-dev] [PATCH 1/6] build: remove redundant libs from pkgconfig

[Thomas Monjalon]

As explained in drivers/meson.build,
"
  For the find_library() case (but not with dependency()) we also
  need to specify the "-l" flags in pkgconfig_extra_libs variable
  too, so that it can be reflected in the pkgconfig output for
  static builds.
"

The commit e30b4e566f47 ("build: improve dependency handling")
must be followed up with this one in order to remove more
occurences of pkgconfig_extra_libs redundant with use of dependency().

Fixes: f1debd77efaf ("net/af_xdp: introduce AF_XDP PMD")
Cc: xiaolong...@intel.com
Fixes: 3c32e89f68e1 ("compress/isal: add skeleton ISA-L compression PMD")
Cc: lee.d...@intel.com
Cc: bl...@debian.org
Cc: sta...@dpdk.org

Signed-off-by: Thomas Monjalon 
---
 drivers/compress/isal/meson.build | 1 -
 drivers/net/af_xdp/meson.build| 1 -
 2 files changed, 2 deletions(-)

diff --git a/drivers/compress/isal/meson.build 
b/drivers/compress/isal/meson.build
index 67b5c4aae..25578880d 100644
--- a/drivers/compress/isal/meson.build
+++ b/drivers/compress/isal/meson.build
@@ -10,6 +10,5 @@ endif
 deps += 'bus_vdev'
 sources = files('isal_compress_pmd.c', 'isal_compress_pmd_ops.c')
 ext_deps += dep
-pkgconfig_extra_libs += '-lisal'
 
 allow_experimental_apis = true
diff --git a/drivers/net/af_xdp/meson.build b/drivers/net/af_xdp/meson.build
index ac679b92b..307aa0e38 100644
--- a/drivers/net/af_xdp/meson.build
+++ b/drivers/net/af_xdp/meson.build
@@ -10,7 +10,6 @@ endif
 
 if bpf_dep.found() and cc.has_header('bpf/xsk.h') and 
cc.has_header('linux/if_xdp.h')
ext_deps += bpf_dep
-   pkgconfig_extra_libs += '-lbpf'
 else
build = false
reason = 'missing dependency, "libbpf"'
-- 
2.22.0

[dpdk-dev] [PATCH 2/6] drivers: add some reasons for meson disabling

[Thomas Monjalon]

Some drivers were missing reasons text for their disabling in meson.

Signed-off-by: Thomas Monjalon 
---
 drivers/baseband/turbo_sw/meson.build | 1 +
 drivers/net/memif/meson.build | 5 +++--
 drivers/raw/ioat/meson.build  | 1 +
 3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/baseband/turbo_sw/meson.build 
b/drivers/baseband/turbo_sw/meson.build
index 33345aa01..1a1f7c9a9 100644
--- a/drivers/baseband/turbo_sw/meson.build
+++ b/drivers/baseband/turbo_sw/meson.build
@@ -7,6 +7,7 @@ if dpdk_conf.has('RTE_BBDEV_SDK_AVX2')
lib = cc.find_library('libturbo', dirs: [path + '/lib_turbo'], 
required: false)
if not lib.found()
build = false
+   reason = 'missing dependency, "libturbo"'
else
ext_deps += cc.find_library('libturbo', dirs: [path + 
'/lib_turbo'], required: true)
ext_deps += cc.find_library('libcrc', dirs: [path + 
'/lib_crc'], required: true)
diff --git a/drivers/net/memif/meson.build b/drivers/net/memif/meson.build
index bedc97311..a44d82535 100644
--- a/drivers/net/memif/meson.build
+++ b/drivers/net/memif/meson.build
@@ -1,8 +1,9 @@
 # SPDX-License-Identifier: BSD-3-Clause
 # Copyright 2018-2019 Cisco Systems, Inc.  All rights reserved.
 
-if host_machine.system() != 'linux'
-build = false
+if not is_linux
+   build = false
+   reason = 'only supported on Linux'
 endif
 
 sources = files('rte_eth_memif.c',
diff --git a/drivers/raw/ioat/meson.build b/drivers/raw/ioat/meson.build
index 247ff88bf..0878418ae 100644
--- a/drivers/raw/ioat/meson.build
+++ b/drivers/raw/ioat/meson.build
@@ -2,6 +2,7 @@
 # Copyright 2019 Intel Corporation
 
 build = dpdk_conf.has('RTE_ARCH_X86')
+reason = 'only supported on x86'
 sources = files('ioat_rawdev.c',
'ioat_rawdev_test.c')
 deps += ['rawdev', 'bus_pci', 'mbuf']
-- 
2.22.0

[dpdk-dev] [PATCH 6/6] devtools: load target-specific compilation environment

[Thomas Monjalon]

In order to re-use the same test environment as with
test-build.sh, the configuration file is loaded at each build,
after adjusting the variable DPDK_TARGET.

This is especially useful to set the variable PKG_CONFIG_PATH,
or define some meson options (without -D) in DPDK_MESON_OPTIONS.

The DPDK_TARGET values can be
aarch64-*, powerpc64-*, x86_64-*.
The matching DPDK_TARGET values for test-build.sh are
arm64-*, ppc_64-*, x86_64-*.
The advised expressions to use in the common configuration file are:
if echo $DPDK_TARGET | grep -q '^a.*64-' ; then
elif echo $DPDK_TARGET | grep -q '^p.*pc.*64' ; then
elif echo $DPDK_TARGET | grep -q '^x86_64' ; then
fi

Signed-off-by: Thomas Monjalon 
---
 devtools/test-meson-builds.sh | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index f2b0b347b..a51a04d5a 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -29,15 +29,32 @@ else
exit 1
 fi
 
+default_path=$PATH
+default_pkgpath=$PKG_CONFIG_PATH
+
+reset_env ()
+{
+   export PATH=$default_path
+   export PKG_CONFIG_PATH=$default_pkgpath
+   unset DPDK_MESON_OPTIONS
+}
+
 build () #   
 {
builddir=$1
shift
targetcc=$1
shift
+   reset_env
+   DPDK_TARGET=$($targetcc -v 2>&1 | sed -n 's,^Target: ,,p')
+   . $srcdir/devtools/load-devel-config
if command -v $CC $targetcc >/dev/null 2>&1 ; then
if [ ! -f "$builddir/build.ninja" ] ; then
-   options="--werror -Dexamples=all $*"
+   options="--werror -Dexamples=all"
+   for option in $DPDK_MESON_OPTIONS ; do
+   options="$options -D$option"
+   done
+   options="$options $*"
echo "$MESON $options $srcdir $builddir"
$MESON $options $srcdir $builddir
unset CC
-- 
2.22.0

[dpdk-dev] [PATCH 4/6] net/mlx: fix build with make and recent gcc

[Thomas Monjalon]

With VERBOSE=1, this error was seen in debug mode with gcc 9.1:

In file included from /tmp/dpdk.auto-config-h.sh.c.w0VWMi:1:
In file included from rdma-core/build/include/infiniband/mlx5dv.h:47:
In file included from rdma-core/build/include/infiniband/verbs.h:46:
In file included from rdma-core/build/include/infiniband/verbs_api.h:66:
In file included from 
rdma-core/build/include/infiniband/ib_user_ioctl_verbs.h:38:
include/rdma/ib_user_verbs.h:161:28: fatal error:
zero size arrays are an extension [-Wzero-length-array]
__aligned_u64 driver_data0;
^
1 error generated.

As a result, buildtools/auto-config-h.sh was not generating
a correct autoconf file, so the compilation was generating such error:

fatal error: redefinition of 'mlx5_ib_uapi_flow_action_packet_reformat_type'

It is fixed by disabling -pedantic option when calling auto-config-h.sh
from the makefile-based system.

Cc: adrien.mazarg...@6wind.com
Cc: sta...@dpdk.org

Signed-off-by: Thomas Monjalon 
---
 drivers/net/mlx4/Makefile | 3 ++-
 drivers/net/mlx5/Makefile | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/mlx4/Makefile b/drivers/net/mlx4/Makefile
index 8126b0dfc..25d7c7555 100644
--- a/drivers/net/mlx4/Makefile
+++ b/drivers/net/mlx4/Makefile
@@ -68,6 +68,7 @@ endif
 # User-defined CFLAGS.
 ifeq ($(CONFIG_RTE_LIBRTE_MLX4_DEBUG),y)
 CFLAGS += -pedantic -UNDEBUG -DPEDANTIC
+AUTO_CONFIG_CFLAGS += -Wno-pedantic
 else
 CFLAGS += -DNDEBUG -UPEDANTIC
 endif
@@ -77,7 +78,7 @@ include $(RTE_SDK)/mk/rte.lib.mk
 # Generate and clean-up mlx4_autoconf.h.
 
 export CC CFLAGS CPPFLAGS EXTRA_CFLAGS EXTRA_CPPFLAGS
-export AUTO_CONFIG_CFLAGS = -Wno-error
+export AUTO_CONFIG_CFLAGS += -Wno-error
 
 ifndef V
 AUTOCONF_OUTPUT := >/dev/null
diff --git a/drivers/net/mlx5/Makefile b/drivers/net/mlx5/Makefile
index dbb2a4e80..299cf3afe 100644
--- a/drivers/net/mlx5/Makefile
+++ b/drivers/net/mlx5/Makefile
@@ -83,6 +83,7 @@ endif
 # User-defined CFLAGS.
 ifeq ($(CONFIG_RTE_LIBRTE_MLX5_DEBUG),y)
 CFLAGS += -pedantic -UNDEBUG -DPEDANTIC
+AUTO_CONFIG_CFLAGS += -Wno-pedantic
 else
 CFLAGS += -DNDEBUG -UPEDANTIC
 endif
@@ -92,7 +93,7 @@ include $(RTE_SDK)/mk/rte.lib.mk
 # Generate and clean-up mlx5_autoconf.h.
 
 export CC CFLAGS CPPFLAGS EXTRA_CFLAGS EXTRA_CPPFLAGS
-export AUTO_CONFIG_CFLAGS = -Wno-error
+export AUTO_CONFIG_CFLAGS += -Wno-error
 
 ifndef V
 AUTOCONF_OUTPUT := >/dev/null
-- 
2.22.0

[dpdk-dev] [PATCH 3/6] net/mlx: fix meson build with custom dependency path

[Thomas Monjalon]

If rdma-core is not installed in a standard directory of the system,
it is possible to specify the location of the pkgconfig file via
an environment variable:
PKG_CONFIG_PATH=$PKG_CONFIG_PATH:~/rdma-core/build/lib/pkgconfig

In this case, the dependency may become mandatory to specify
for the configuration tests (checking dependency symbols or fields).

Some spacing is also fixed around.

Fixes: 8e4937640022 ("net/mlx4: add external allocator for Verbs object")
Fixes: 1dd7c7e38c19 ("net/mlx4: support meson build")
Fixes: 96d7c62a70c7 ("net/mlx5: support meson build")
Cc: sta...@dpdk.org

Suggested-by: Luca Boccassi 
Signed-off-by: Thomas Monjalon 
---
 drivers/net/mlx4/meson.build | 9 +
 drivers/net/mlx5/meson.build | 7 ---
 2 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/net/mlx4/meson.build b/drivers/net/mlx4/meson.build
index 028cd97fa..efee45776 100644
--- a/drivers/net/mlx4/meson.build
+++ b/drivers/net/mlx4/meson.build
@@ -76,7 +76,7 @@ if build
# mlx4_autoconf.h file is still generated.
# input array for meson member search:
# [ "MACRO to define if found", "header for the search",
-   #   "symbol to search","struct member to search" ]
+   #   "symbol to search", "struct member to search" ]
#
has_member_args = [
[ 'HAVE_IBV_MLX4_WQE_LSO_SEG', 'infiniband/mlx4dv.h',
@@ -93,12 +93,13 @@ if build
]
config = configuration_data()
foreach arg:has_sym_args
-   config.set(arg[0], cc.has_header_symbol(arg[1], arg[2]))
+   config.set(arg[0], cc.has_header_symbol(arg[1], arg[2],
+   dependencies: libs))
endforeach
foreach arg:has_member_args
-   file_prefix = '#include<' + arg[1] + '>'
+   file_prefix = '#include <' + arg[1] + '>'
config.set(arg[0], cc.has_member(arg[2], arg[3],
-   prefix : file_prefix))
+   prefix: file_prefix, dependencies: libs))
endforeach
configure_file(output : 'mlx4_autoconf.h', configuration : config)
 endif
diff --git a/drivers/net/mlx5/meson.build b/drivers/net/mlx5/meson.build
index 62b41caf1..3c5144c9b 100644
--- a/drivers/net/mlx5/meson.build
+++ b/drivers/net/mlx5/meson.build
@@ -177,12 +177,13 @@ if build
]
config = configuration_data()
foreach arg:has_sym_args
-   config.set(arg[0], cc.has_header_symbol(arg[1], arg[2]))
+   config.set(arg[0], cc.has_header_symbol(arg[1], arg[2],
+   dependencies: libs))
endforeach
foreach arg:has_member_args
-   file_prefix = '#include<' + arg[1] + '>'
+   file_prefix = '#include <' + arg[1] + '>'
config.set(arg[0], cc.has_member(arg[2], arg[3],
-   prefix : file_prefix))
+   prefix : file_prefix, dependencies: libs))
endforeach
configure_file(output : 'mlx5_autoconf.h', configuration : config)
 endif
-- 
2.22.0

[dpdk-dev] [PATCH 5/6] devtools: test compiler availability only once

[Thomas Monjalon]

The compilation test is skipped if the compiler is not available.
In the case of gcc/arm, it was tested both in the generic function
"build" and in the cross-compilation section.

By passing the compiler as argument of the generic function,
the test with "command" is done only once.

This small clean-up has the benefit of introducing the compiler
parameter to be used later in another improvement.

Signed-off-by: Thomas Monjalon 
---
 devtools/test-meson-builds.sh | 33 -
 1 file changed, 16 insertions(+), 17 deletions(-)

diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index 9fe0a04c9..f2b0b347b 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -29,11 +29,13 @@ else
exit 1
 fi
 
-build () #  
+build () #   
 {
builddir=$1
shift
-   if command -v $CC >/dev/null 2>&1 ; then
+   targetcc=$1
+   shift
+   if command -v $CC $targetcc >/dev/null 2>&1 ; then
if [ ! -f "$builddir/build.ninja" ] ; then
options="--werror -Dexamples=all $*"
echo "$MESON $options $srcdir $builddir"
@@ -71,7 +73,7 @@ for c in gcc clang ; do
command -v $c >/dev/null 2>&1 || continue
for s in static shared ; do
export CC="ccache $c"
-   build build-$c-$s --default-library=$s
+   build build-$c-$s $c --default-library=$s
done
 done
 
@@ -83,22 +85,19 @@ ok=$(cc -march=$default_machine -E - < /dev/null > 
/dev/null 2>&1 || echo false)
 if [ "$ok" = "false" ] ; then
default_machine='corei7'
 fi
-build build-x86-default -Dlibdir=lib -Dmachine=$default_machine $use_shared
+build build-x86-default cc -Dlibdir=lib -Dmachine=$default_machine $use_shared
 
-# enable cross compilation if gcc cross-compiler is found
 c=aarch64-linux-gnu-gcc
-if command -v $c >/dev/null 2>&1 ; then
-   # compile the general v8a also for clang to increase coverage
-   export CC="clang"
-   build build-arm64-host-clang $use_shared \
-   --cross-file $srcdir/config/arm/arm64_armv8_linux_gcc
-
-   for f in $srcdir/config/arm/arm*gcc ; do
-   export CC="ccache gcc"
-   build build-$(basename $f | tr '_' '-' | cut -d'-' -f-2) \
-   $use_shared --cross-file $f
-   done
-fi
+# generic armv8a with clang as host compiler
+export CC="clang"
+build build-arm64-host-clang $c $use_shared \
+   --cross-file $srcdir/config/arm/arm64_armv8_linux_gcc
+# all gcc/arm configurations
+for f in $srcdir/config/arm/arm*gcc ; do
+   export CC="ccache gcc"
+   build build-$(basename $f | tr '_' '-' | cut -d'-' -f-2) $c \
+   $use_shared --cross-file $f
+done
 
 # Test installation of the x86-default target, to be used for checking
 # the sample apps build using the pkg-config file for cflags and libs
-- 
2.22.0

Re: [dpdk-dev] [PATCH] version: 19.11-rc0

[Thomas Monjalon]

12/08/2019 13:43, David Marchand:
> Start a new release cycle with empty release notes.
> 
> Signed-off-by: David Marchand 
> ---
>  VERSION|   2 +-
>  doc/guides/rel_notes/release_19_11.rst | 214 
> +

doc/guides/rel_notes/release_19_11.rst: WARNING: document isn't included in any 
toctree

1/ the new file must be linked in doc/guides/rel_notes/index.rst

Please compare with the latest release notes, I see two more misses:
2/ .. include:: 
3/ increased lib versions

Thanks

Re: [dpdk-dev] [v4] net/i40e: fix vf runtime queues rss config

[Xing, Beilei]

Hi,

> -Original Message-
> From: Zhang, Xiao
> Sent: Tuesday, August 13, 2019 1:44 AM
> To: dev@dpdk.org
> Cc: Xing, Beilei ; Zhang, Xiao ;
> sta...@dpdk.org
> Subject: [v4] net/i40e: fix vf runtime queues rss config
> 
> I40evf queue can not work properly with kernel pf driver. Eg. when configure
> 8 queues pair, only 4 queues can receive packets, and half packets will be 
> lost
> if using 2 queues pair.
> This issue is caused by misconfiguration of look up table, use aq command to
> setup the lut to make it work properly.
> 
> Fixes: cea7a51c1750 ("i40evf: support RSS")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Xiao Zhang 
> ---
> v4 move local variable definition to the begin of the function
> v3 move LUT configuration in to i40evf_configure_rss
> v2 change for loop format to avoid build patch issue
> ---
>  drivers/net/i40e/i40e_ethdev_vf.c | 32 ++--
>  1 file changed, 26 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/i40e/i40e_ethdev_vf.c
> b/drivers/net/i40e/i40e_ethdev_vf.c
> index 308fb98..8c34afb 100644
> --- a/drivers/net/i40e/i40e_ethdev_vf.c
> +++ b/drivers/net/i40e/i40e_ethdev_vf.c
> @@ -2598,7 +2598,10 @@ i40evf_config_rss(struct i40e_vf *vf)
>   struct i40e_hw *hw = I40E_VF_TO_HW(vf);
>   struct rte_eth_rss_conf rss_conf;
>   uint32_t i, j, lut = 0, nb_q = (I40E_VFQF_HLUT_MAX_INDEX + 1) * 4;
> + uint32_t rss_lut_size = (I40E_VFQF_HLUT1_MAX_INDEX + 1) * 4;
>   uint16_t num;
> + uint8_t *lut;

The pointer *lut is conflict with above 'uint32_t lut = 0'.

> + int ret;
> 
>   if (vf->dev_data->dev_conf.rxmode.mq_mode != ETH_MQ_RX_RSS) {
>   i40evf_disable_rss(vf);
> @@ -2608,12 +2611,29 @@ i40evf_config_rss(struct i40e_vf *vf)
> 
>   num = RTE_MIN(vf->dev_data->nb_rx_queues,
> I40E_MAX_QP_NUM_PER_VF);
>   /* Fill out the look up table */
> - for (i = 0, j = 0; i < nb_q; i++, j++) {
> - if (j >= num)
> - j = 0;
> - lut = (lut << 8) | j;
> - if ((i & 3) == 3)
> - I40E_WRITE_REG(hw, I40E_VFQF_HLUT(i >> 2), lut);
> + if (!(vf->flags & I40E_FLAG_RSS_AQ_CAPABLE)) {
> + for (i = 0, j = 0; i < nb_q; i++, j++) {
> + if (j >= num)
> + j = 0;
> + lut = (lut << 8) | j;
> + if ((i & 3) == 3)
> + I40E_WRITE_REG(hw, I40E_VFQF_HLUT(i >>
> 2), lut);
> + }
> + } else {
> + lut = rte_zmalloc("i40e_rss_lut", rss_lut_size, 0);
> + if (!lut) {
> + PMD_DRV_LOG(ERR, "No memory can be allocated");
> + return -ENOMEM;
> + }
> +
> + for (i = 0; i < rss_lut_size; i++)
> + lut[i] = i % vf->num_queue_pairs;
> +
> + ret = i40evf_set_rss_lut(&vf->vsi, lut,
> +  rss_lut_size);
> + rte_free(lut);
> + if (ret)
> + return ret;
>   }
> 
>   rss_conf = vf->dev_data->dev_conf.rx_adv_conf.rss_conf;
> --
> 2.7.4

[dpdk-dev] [v5] net/i40e: fix vf runtime queues rss config

[Xiao Zhang]

I40evf queue can not work properly with kernel pf driver. Eg. when
configure 8 queues pair, only 4 queues can receive packets, and half
packets will be lost if using 2 queues pair.
This issue is caused by misconfiguration of look up table, use aq
command to setup the lut to make it work properly.

Fixes: cea7a51c1750 ("i40evf: support RSS")
Cc: sta...@dpdk.org

Signed-off-by: Xiao Zhang 
---
v5 fix compile issue
v4 move local variable definition to the begin of the function
v3 move LUT configuration in to i40evf_configure_rss
v2 change for loop format to avoid build patch issue
---
 drivers/net/i40e/i40e_ethdev_vf.c | 32 ++--
 1 file changed, 26 insertions(+), 6 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev_vf.c 
b/drivers/net/i40e/i40e_ethdev_vf.c
index 308fb98..c77b30c 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -2598,7 +2598,10 @@ i40evf_config_rss(struct i40e_vf *vf)
struct i40e_hw *hw = I40E_VF_TO_HW(vf);
struct rte_eth_rss_conf rss_conf;
uint32_t i, j, lut = 0, nb_q = (I40E_VFQF_HLUT_MAX_INDEX + 1) * 4;
+   uint32_t rss_lut_size = (I40E_VFQF_HLUT1_MAX_INDEX + 1) * 4;
uint16_t num;
+   uint8_t *lut_info;
+   int ret;
 
if (vf->dev_data->dev_conf.rxmode.mq_mode != ETH_MQ_RX_RSS) {
i40evf_disable_rss(vf);
@@ -2608,12 +2611,29 @@ i40evf_config_rss(struct i40e_vf *vf)
 
num = RTE_MIN(vf->dev_data->nb_rx_queues, I40E_MAX_QP_NUM_PER_VF);
/* Fill out the look up table */
-   for (i = 0, j = 0; i < nb_q; i++, j++) {
-   if (j >= num)
-   j = 0;
-   lut = (lut << 8) | j;
-   if ((i & 3) == 3)
-   I40E_WRITE_REG(hw, I40E_VFQF_HLUT(i >> 2), lut);
+   if (!(vf->flags & I40E_FLAG_RSS_AQ_CAPABLE)) {
+   for (i = 0, j = 0; i < nb_q; i++, j++) {
+   if (j >= num)
+   j = 0;
+   lut = (lut << 8) | j;
+   if ((i & 3) == 3)
+   I40E_WRITE_REG(hw, I40E_VFQF_HLUT(i >> 2), lut);
+   }
+   } else {
+   lut_info = rte_zmalloc("i40e_rss_lut", rss_lut_size, 0);
+   if (!lut_info) {
+   PMD_DRV_LOG(ERR, "No memory can be allocated");
+   return -ENOMEM;
+   }
+
+   for (i = 0; i < rss_lut_size; i++)
+   lut_info[i] = i % vf->num_queue_pairs;
+
+   ret = i40evf_set_rss_lut(&vf->vsi, lut_info,
+rss_lut_size);
+   rte_free(lut_info);
+   if (ret)
+   return ret;
}
 
rss_conf = vf->dev_data->dev_conf.rx_adv_conf.rss_conf;
-- 
2.7.4

[dpdk-dev] [PATCH 0/6] Some updates for virtio guide

[Tiwei Bie]

Tiwei Bie (6):
  net/virtio: remove remaining simple Tx related stuff
  doc: fix typo in virtio in-order Rx function name
  doc: update the description for in-order Rx path
  doc: document the devargs for virtio-user
  doc: document packed virtqueue for virtio
  doc: fix format for virtio guide

 doc/guides/nics/virtio.rst | 118 -
 drivers/net/virtio/virtio_ethdev.h |   3 -
 2 files changed, 84 insertions(+), 37 deletions(-)

-- 
2.17.1

[dpdk-dev] [PATCH 3/6] doc: update the description for in-order Rx path

[Tiwei Bie]

The virtio_recv_mergeable_pkts_inorder() has been renamed to
virtio_recv_pkts_inorder() and added the non-mergeable support
in below commit.

Fixes: efcda13648d2 ("net/virtio: add non-mergeable support to in-order path")
Cc: sta...@dpdk.org

Signed-off-by: Tiwei Bie 
---
 doc/guides/nics/virtio.rst | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/doc/guides/nics/virtio.rst b/doc/guides/nics/virtio.rst
index 08438d064..b3c356856 100644
--- a/doc/guides/nics/virtio.rst
+++ b/doc/guides/nics/virtio.rst
@@ -215,8 +215,8 @@ Rx callbacks:
Vector version without mergeable Rx buffer support, also fixes the available
ring indexes and uses vector instructions to optimize performance.
 
-#. ``virtio_recv_mergeable_pkts_inorder``:
-   In-order version with mergeable Rx buffer support.
+#. ``virtio_recv_pkts_inorder``:
+   In-order version with mergeable and non-mergeable Rx buffer support.
 
 Tx callbacks:
 
@@ -250,8 +250,7 @@ Example of using the vector version of the virtio poll mode 
driver in
 
 In-order callbacks only work on simulated virtio user vdev.
 
-*   For Rx: If mergeable Rx buffers is enabled and in-order is enabled then
-``virtio_recv_mergeable_pkts_inorder`` is used.
+*   For Rx: If in-order is enabled then ``virtio_recv_pkts_inorder`` is used.
 
 *   For Tx: If in-order is enabled then ``virtio_xmit_pkts_inorder`` is used.
 
-- 
2.17.1

[dpdk-dev] [PATCH 1/6] net/virtio: remove remaining simple Tx related stuff

[Tiwei Bie]

The simple Tx path in virtio has been removed in below commit.
This patch removes an undefined function declaration of simple
Tx and all related descriptions in the doc.

Fixes: 57f818963d80 ("net/virtio: remove simple Tx path")
Cc: sta...@dpdk.org

Signed-off-by: Tiwei Bie 
---
 doc/guides/nics/virtio.rst | 15 ++-
 drivers/net/virtio/virtio_ethdev.h |  3 ---
 2 files changed, 2 insertions(+), 16 deletions(-)

diff --git a/doc/guides/nics/virtio.rst b/doc/guides/nics/virtio.rst
index 2ae875cb4..da9cd6ba6 100644
--- a/doc/guides/nics/virtio.rst
+++ b/doc/guides/nics/virtio.rst
@@ -201,7 +201,7 @@ The packet transmission flow is:
 Virtio PMD Rx/Tx Callbacks
 --
 
-Virtio driver has 4 Rx callbacks and 3 Tx callbacks.
+Virtio driver has 4 Rx callbacks and 2 Tx callbacks.
 
 Rx callbacks:
 
@@ -223,9 +223,6 @@ Tx callbacks:
 #. ``virtio_xmit_pkts``:
Regular version.
 
-#. ``virtio_xmit_pkts_simple``:
-   Vector version fixes the available ring indexes to optimize performance.
-
 #. ``virtio_xmit_pkts_inorder``:
In-order version.
 
@@ -239,25 +236,17 @@ By default, the non-vector callbacks are used:
 
 Vector callbacks will be used when:
 
-*   ``txmode.offloads`` is set to ``0x0``, which implies:
-
-*   Single segment is specified.
-
-*   No offload support is needed.
-
 *   Mergeable Rx buffers is disabled.
 
 The corresponding callbacks are:
 
 *   For Rx: ``virtio_recv_pkts_vec``.
 
-*   For Tx: ``virtio_xmit_pkts_simple``.
-
 
 Example of using the vector version of the virtio poll mode driver in
 ``testpmd``::
 
-   testpmd -l 0-2 -n 4 -- -i --tx-offloads=0x0 --rxq=1 --txq=1 --nb-cores=1
+   testpmd -l 0-2 -n 4 -- -i --rxq=1 --txq=1 --nb-cores=1
 
 In-order callbacks only work on simulated virtio user vdev.
 
diff --git a/drivers/net/virtio/virtio_ethdev.h 
b/drivers/net/virtio/virtio_ethdev.h
index 20d331795..a10111758 100644
--- a/drivers/net/virtio/virtio_ethdev.h
+++ b/drivers/net/virtio/virtio_ethdev.h
@@ -103,9 +103,6 @@ uint16_t virtio_xmit_pkts_inorder(void *tx_queue, struct 
rte_mbuf **tx_pkts,
 uint16_t virtio_recv_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
uint16_t nb_pkts);
 
-uint16_t virtio_xmit_pkts_simple(void *tx_queue, struct rte_mbuf **tx_pkts,
-   uint16_t nb_pkts);
-
 int eth_virtio_dev_init(struct rte_eth_dev *eth_dev);
 
 void virtio_interrupt_handler(void *param);
-- 
2.17.1

[dpdk-dev] [PATCH 2/6] doc: fix typo in virtio in-order Rx function name

[Tiwei Bie]

The Rx function that will be used when in-order is enabled
should be virtio_recv_mergeable_pkts_inorder() instead of
virtio_xmit_pkts_inorder().

Fixes: 8f3bd7e8702d ("net/virtio: add in-order Rx/Tx into selection")
Cc: sta...@dpdk.org

Signed-off-by: Tiwei Bie 
---
 doc/guides/nics/virtio.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/guides/nics/virtio.rst b/doc/guides/nics/virtio.rst
index da9cd6ba6..08438d064 100644
--- a/doc/guides/nics/virtio.rst
+++ b/doc/guides/nics/virtio.rst
@@ -251,7 +251,7 @@ Example of using the vector version of the virtio poll mode 
driver in
 In-order callbacks only work on simulated virtio user vdev.
 
 *   For Rx: If mergeable Rx buffers is enabled and in-order is enabled then
-``virtio_xmit_pkts_inorder`` is used.
+``virtio_recv_mergeable_pkts_inorder`` is used.
 
 *   For Tx: If in-order is enabled then ``virtio_xmit_pkts_inorder`` is used.
 
-- 
2.17.1

[dpdk-dev] [PATCH 4/6] doc: document the devargs for virtio-user

[Tiwei Bie]

Document the devargs for virtio-user and also make it clear
that these devargs are only available in virtio-user, i.e. not
supported by the PCI virtio driver.

Signed-off-by: Tiwei Bie 
---
 doc/guides/nics/virtio.rst | 38 +++---
 1 file changed, 35 insertions(+), 3 deletions(-)

diff --git a/doc/guides/nics/virtio.rst b/doc/guides/nics/virtio.rst
index b3c356856..993e691f5 100644
--- a/doc/guides/nics/virtio.rst
+++ b/doc/guides/nics/virtio.rst
@@ -322,7 +322,7 @@ Here we use l3fwd-power as an example to show how to get 
started.
 Virtio PMD arguments
 
 
-The user can specify below argument in devargs.
+Below devargs are supported by the PCI virtio driver:
 
 #.  ``vdpa``:
 
@@ -331,12 +331,44 @@ The user can specify below argument in devargs.
 a virtio device needs to work in vDPA mode.
 (Default: 0 (disabled))
 
-#. ``mrg_rxbuf``:
+Below devargs are supported by the virtio-user vdev:
+
+#.  ``path``:
+
+It is used to specify a path to connect to vhost backend.
+
+#.  ``mac``:
+
+It is used to specify the MAC address.
+
+#.  ``cq``:
+
+It is used to enable the control queue. (Default: 0 (disabled))
+
+#.  ``queue_size``:
+
+It is used to specify the queue size. (Default: 256)
+
+#.  ``queues``:
+
+It is used to specify the queue number. (Default: 1)
+
+#.  ``iface``:
+
+It is used to specify the host interface name for vhost-kernel
+backend.
+
+#.  ``server``:
+
+It is used to enable the server mode when using vhost-user backend.
+(Default: 0 (disabled))
+
+#.  ``mrg_rxbuf``:
 
 It is used to enable virtio device mergeable Rx buffer feature.
 (Default: 1 (enabled))
 
-#. ``in_order``:
+#.  ``in_order``:
 
 It is used to enable virtio device in-order feature.
 (Default: 1 (enabled))
-- 
2.17.1

[dpdk-dev] [PATCH 5/6] doc: document packed virtqueue for virtio

[Tiwei Bie]

Document the packed virtqueue layout support in virtio net PMD.

Signed-off-by: Tiwei Bie 
---
 doc/guides/nics/virtio.rst | 63 --
 1 file changed, 47 insertions(+), 16 deletions(-)

diff --git a/doc/guides/nics/virtio.rst b/doc/guides/nics/virtio.rst
index 993e691f5..011954ff6 100644
--- a/doc/guides/nics/virtio.rst
+++ b/doc/guides/nics/virtio.rst
@@ -24,15 +24,19 @@ standard qemu vhost back end and vhost kni back end.
 Virtio Implementation in DPDK
 -
 
-For details about the virtio spec, refer to Virtio PCI Card Specification 
written by Rusty Russell.
+For details about the virtio spec, refer to the latest
+`VIRTIO (Virtual I/O) Device Specification
+`_.
 
-As a PMD, virtio provides packet reception and transmission callbacks 
virtio_recv_pkts and virtio_xmit_pkts.
+As a PMD, virtio provides packet reception and transmission callbacks.
 
-In virtio_recv_pkts, index in range [vq->vq_used_cons_idx , 
vq->vq_ring.used->idx) in vring is available for virtio to burst out.
+In Rx, packets described by the used descriptors in vring are available
+for virtio to burst out.
 
-In virtio_xmit_pkts, same index range in vring is available for virtio to 
clean.
-Virtio will enqueue to be transmitted packets into vring, advance the 
vq->vq_ring.avail->idx,
-and then notify the host back end if necessary.
+In Tx, packets described by the used descriptors in vring are available
+for virtio to clean. Virtio will enqueue to be transmitted packets into
+vring, make them available to the device, and then notify the host back
+end if necessary.
 
 Features and Limitations of virtio PMD
 --
@@ -201,37 +205,52 @@ The packet transmission flow is:
 Virtio PMD Rx/Tx Callbacks
 --
 
-Virtio driver has 4 Rx callbacks and 2 Tx callbacks.
+Virtio driver has 6 Rx callbacks and 3 Tx callbacks.
 
 Rx callbacks:
 
 #. ``virtio_recv_pkts``:
-   Regular version without mergeable Rx buffer support.
+   Regular version without mergeable Rx buffer support for split virtqueue.
 
 #. ``virtio_recv_mergeable_pkts``:
-   Regular version with mergeable Rx buffer support.
+   Regular version with mergeable Rx buffer support for split virtqueue.
 
 #. ``virtio_recv_pkts_vec``:
Vector version without mergeable Rx buffer support, also fixes the available
-   ring indexes and uses vector instructions to optimize performance.
+   ring indexes and uses vector instructions to optimize performance for split
+   virtqueue.
 
 #. ``virtio_recv_pkts_inorder``:
-   In-order version with mergeable and non-mergeable Rx buffer support.
+   In-order version with mergeable and non-mergeable Rx buffer support
+   for split virtqueue.
+
+#. ``virtio_recv_pkts_packed``:
+   Regular and in-order version without mergeable Rx buffer support for
+   packed virtqueue.
+
+#. ``virtio_recv_mergeable_pkts_packed``:
+   Regular and in-order version with mergeable Rx buffer support for packed
+   virtqueue.
 
 Tx callbacks:
 
 #. ``virtio_xmit_pkts``:
-   Regular version.
+   Regular version for split virtqueue.
 
 #. ``virtio_xmit_pkts_inorder``:
-   In-order version.
+   In-order version for split virtqueue.
+
+#. ``virtio_xmit_pkts_packed``:
+   Regular and in-order version for packed virtqueue.
 
 By default, the non-vector callbacks are used:
 
-*   For Rx: If mergeable Rx buffers is disabled then ``virtio_recv_pkts`` is
-used; otherwise ``virtio_recv_mergeable_pkts``.
+*   For Rx: If mergeable Rx buffers is disabled then ``virtio_recv_pkts``
+or ``virtio_recv_pkts_packed`` will be used, otherwise
+``virtio_recv_mergeable_pkts`` or ``virtio_recv_mergeable_pkts_packed``
+will be used.
 
-*   For Tx: ``virtio_xmit_pkts``.
+*   For Tx: ``virtio_xmit_pkts`` or ``virtio_xmit_pkts_packed`` will be used.
 
 
 Vector callbacks will be used when:
@@ -242,6 +261,8 @@ The corresponding callbacks are:
 
 *   For Rx: ``virtio_recv_pkts_vec``.
 
+There is no vector callbacks for packed virtqueue for now.
+
 
 Example of using the vector version of the virtio poll mode driver in
 ``testpmd``::
@@ -250,10 +271,15 @@ Example of using the vector version of the virtio poll 
mode driver in
 
 In-order callbacks only work on simulated virtio user vdev.
 
+For split virtqueue:
+
 *   For Rx: If in-order is enabled then ``virtio_recv_pkts_inorder`` is used.
 
 *   For Tx: If in-order is enabled then ``virtio_xmit_pkts_inorder`` is used.
 
+For packed virtqueue, the default callbacks already support the
+in-order feature.
+
 Interrupt mode
 --
 
@@ -372,3 +398,8 @@ Below devargs are supported by the virtio-user vdev:
 
 It is used to enable virtio device in-order feature.
 (Default: 1 (enabled))
+
+#.  ``packed_vq``:
+
+It is used to enable virtio device packed virtqueue feature.
+(Default: 0 (disabled))
-- 
2.17.1

[dpdk-dev] [PATCH 6/6] doc: fix format for virtio guide

[Tiwei Bie]

This patch removes an unwanted empty line in a sentence.

Fixes: 71afcefbd53e ("doc: update virtio ring size and header size")
Cc: sta...@dpdk.org

Signed-off-by: Tiwei Bie 
---
 doc/guides/nics/virtio.rst | 1 -
 1 file changed, 1 deletion(-)

diff --git a/doc/guides/nics/virtio.rst b/doc/guides/nics/virtio.rst
index 011954ff6..bd0116176 100644
--- a/doc/guides/nics/virtio.rst
+++ b/doc/guides/nics/virtio.rst
@@ -7,7 +7,6 @@ Poll Mode Driver for Emulated Virtio NIC
 Virtio is a para-virtualization framework initiated by IBM, and supported by 
KVM hypervisor.
 In the Data Plane Development Kit (DPDK),
 we provide a virtio Poll Mode Driver (PMD) as a software solution, comparing 
to SRIOV hardware solution,
-
 for fast guest VM to guest VM communication and guest VM to host communication.
 
 Vhost is a kernel acceleration module for virtio qemu backend.
-- 
2.17.1

Re: [dpdk-dev] [v5] net/i40e: fix vf runtime queues rss config

[Xing, Beilei]

> -Original Message-
> From: Zhang, Xiao
> Sent: Tuesday, August 13, 2019 6:41 PM
> To: dev@dpdk.org
> Cc: Xing, Beilei ; Zhang, Xiao ;
> sta...@dpdk.org
> Subject: [v5] net/i40e: fix vf runtime queues rss config
> 
> I40evf queue can not work properly with kernel pf driver. Eg. when configure
> 8 queues pair, only 4 queues can receive packets, and half packets will be 
> lost
> if using 2 queues pair.
> This issue is caused by misconfiguration of look up table, use aq command to
> setup the lut to make it work properly.
> 
> Fixes: cea7a51c1750 ("i40evf: support RSS")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Xiao Zhang 

Acked-by: Beilei Xing 

[dpdk-dev] [Bug 338] IP Reassembly with more 4 packets Segfault

[bugzilla]

https://bugs.dpdk.org/show_bug.cgi?id=338

Bug ID: 338
   Summary: IP Reassembly with more 4 packets Segfault
   Product: DPDK
   Version: 17.11
  Hardware: x86
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: Normal
 Component: core
  Assignee: dev@dpdk.org
  Reporter: abhijeet080...@gmail.com
  Target Milestone: ---

I have looked at previous mails on this mailing list and also elsewhere on
Google and could not find any information related to this.

Whenever I have to reassemble a valid IP packet with more than 4 fragments, I
see a crash. Stack trace below. I assume the number 4 comes from
RTE_LIBRTE_IP_FRAG_MAX_FRAG.

To trigger this, I sent a fragmented IP packet via - ping  -s
6000

(gdb) bt
#0  ip_frag_lookup (tbl=tbl@entry=0x7fff7a32ce80, key=key@entry=0x7610,
tms=tms@entry=2602613353715115, free=free@entry=0x76eeedb8, 
stale=stale@entry=0x76eeedc0) at
/usr/src/debug/dpdk-17.11.2-6.fc30.x86_64/lib/librte_ip_frag/ip_frag_internal.c:379
#1  0x77c021f6 in ip_frag_find (tbl=tbl@entry=0x7fff7a32ce80,
dr=dr@entry=0x7fff7a32c900, key=key@entry=0x7610, tms=2602613353715115)
at
/usr/src/debug/dpdk-17.11.2-6.fc30.x86_64/lib/librte_ip_frag/ip_frag_internal.c:286
#2  0x77c00280 in rte_ipv4_frag_reassemble_packet (tbl=0x7fff7a32ce80,
dr=0x7fff7a32c900, mb=0x7fff8b71b480, tms=, 
ip_hdr=) at
/usr/src/debug/dpdk-17.11.2-6.fc30.x86_64/lib/librte_ip_frag/rte_ipv4_reassembly.c:160

(gdb) f 0
#0  ip_frag_lookup (tbl=tbl@entry=0x7fff7a32ce80, key=key@entry=0x7610,
tms=tms@entry=2602613353715115, free=free@entry=0x76eeedb8, 
stale=stale@entry=0x76eeedc0) at
/usr/src/debug/dpdk-17.11.2-6.fc30.x86_64/lib/librte_ip_frag/ip_frag_internal.c:379
379 if (ip_frag_key_cmp(key, &p1[i].key) == 0)

(gdb) f 1
#1  0x77c021f6 in ip_frag_find (tbl=tbl@entry=0x7fff7a32ce80,
dr=dr@entry=0x7fff7a32c900, key=key@entry=0x7610, tms=2602613353715115)
at
/usr/src/debug/dpdk-17.11.2-6.fc30.x86_64/lib/librte_ip_frag/ip_frag_internal.c:286
286 if ((pkt = ip_frag_lookup(tbl, key, tms, &free, &stale)) == NULL) {

(gdb) f 2
#2  0x77c00280 in rte_ipv4_frag_reassemble_packet (tbl=0x7fff7a32ce80,
dr=0x7fff7a32c900, mb=0x7fff8b71b480, tms=, 
ip_hdr=) at
/usr/src/debug/dpdk-17.11.2-6.fc30.x86_64/lib/librte_ip_frag/rte_ipv4_reassembly.c:160
160 if ((fp = ip_frag_find(tbl, dr, &key, tms)) == NULL) {

Is this a known issue? Are there any workaround?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[dpdk-dev] [RFC v2 0/3] show the Rx/Tx burst description field

[Haiyue Wang]

v1: ABI breaking
http://mails.dpdk.org/archives/dev/2019-August/140916.html
  https://patchwork.dpdk.org/patch/57624/
  https://patchwork.dpdk.org/patch/57625/
  https://patchwork.dpdk.org/patch/57626/

v2: add a simple trace API to export string type information, if the
return value > 0, then valid information is generated.

testpmd> show rxq info 0 0

* Infos for port 0 , RX queue 0  *
Mempool: mbuf_pool_socket_0
RX prefetch threshold: 0
RX host threshold: 0
RX writeback threshold: 0
RX free threshold: 32
RX drop packets: off
RX deferred start: off
RX scattered packets: on
Number of RXDs: 1024
Burst description: AVX2 Vector Scattered Rx

testpmd> show txq info 0 0

* Infos for port 0 , TX queue 0  *
TX prefetch threshold: 32
TX host threshold: 0
TX writeback threshold: 0
TX RS threshold: 32
TX free threshold: 32
TX deferred start: off
Number of TXDs: 1024
Burst description: AVX2 Vector Tx

Haiyue Wang (3):
  ethdev: add the API for getting trace information
  testpmd: show the Rx/Tx burst description
  net/ice: support the Rx/Tx burst description trace

 app/test-pmd/config.c   | 12 +
 drivers/net/ice/ice_ethdev.c| 26 +++
 drivers/net/ice/ice_rxtx.c  | 52 +
 drivers/net/ice/ice_rxtx.h  |  4 +++
 lib/librte_ethdev/rte_ethdev.c  | 18 +
 lib/librte_ethdev/rte_ethdev.h  |  9 +++
 lib/librte_ethdev/rte_ethdev_core.h |  4 +++
 7 files changed, 125 insertions(+)

-- 
2.7.4

[dpdk-dev] [RFC v2 2/3] testpmd: show the Rx/Tx burst description

[Haiyue Wang]

Add the 'Burst description' section into command 'show rxq|txq info
 ' to show the Rx/Tx burst description by new trace
API.

Signed-off-by: Haiyue Wang 
---
 app/test-pmd/config.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 1a5a5c1..52814ba 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -330,6 +330,7 @@ rx_queue_infos_display(portid_t port_id, uint16_t queue_id)
struct rte_eth_rxq_info qinfo;
int32_t rc;
static const char *info_border = "*";
+   char burst_info[128];
 
rc = rte_eth_rx_queue_info_get(port_id, queue_id, &qinfo);
if (rc != 0) {
@@ -354,6 +355,11 @@ rx_queue_infos_display(portid_t port_id, uint16_t queue_id)
printf("\nRX scattered packets: %s",
(qinfo.scattered_rx != 0) ? "on" : "off");
printf("\nNumber of RXDs: %hu", qinfo.nb_desc);
+
+   if (rte_eth_trace_info_get(port_id, queue_id, ETH_TRACE_RX_BURST,
+  burst_info, sizeof(burst_info)) > 0)
+   printf("\nBurst description: %s\n", burst_info);
+
printf("\n");
 }
 
@@ -363,6 +369,7 @@ tx_queue_infos_display(portid_t port_id, uint16_t queue_id)
struct rte_eth_txq_info qinfo;
int32_t rc;
static const char *info_border = "*";
+   char burst_info[128];
 
rc = rte_eth_tx_queue_info_get(port_id, queue_id, &qinfo);
if (rc != 0) {
@@ -383,6 +390,11 @@ tx_queue_infos_display(portid_t port_id, uint16_t queue_id)
printf("\nTX deferred start: %s",
(qinfo.conf.tx_deferred_start != 0) ? "on" : "off");
printf("\nNumber of TXDs: %hu", qinfo.nb_desc);
+
+   if (rte_eth_trace_info_get(port_id, queue_id, ETH_TRACE_TX_BURST,
+  burst_info, sizeof(burst_info)) > 0)
+   printf("\nBurst description: %s\n", burst_info);
+
printf("\n");
 }
 
-- 
2.7.4

[dpdk-dev] [RFC v2 3/3] net/ice: support the Rx/Tx burst description trace

[Haiyue Wang]

According to the Rx/Tx burst function that's selected currently, format
the distinct burst description information for apps to query.

Signed-off-by: Haiyue Wang 
---
 drivers/net/ice/ice_ethdev.c | 26 ++
 drivers/net/ice/ice_rxtx.c   | 52 
 drivers/net/ice/ice_rxtx.h   |  4 
 3 files changed, 82 insertions(+)

diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
index 44a14cb..bad5c23 100644
--- a/drivers/net/ice/ice_ethdev.c
+++ b/drivers/net/ice/ice_ethdev.c
@@ -99,6 +99,8 @@ static int ice_dev_udp_tunnel_port_add(struct rte_eth_dev 
*dev,
struct rte_eth_udp_tunnel *udp_tunnel);
 static int ice_dev_udp_tunnel_port_del(struct rte_eth_dev *dev,
struct rte_eth_udp_tunnel *udp_tunnel);
+static int ice_trace_info_get(struct rte_eth_dev *dev, uint16_t queue_id,
+ enum rte_eth_trace type, char *buf, int sz);
 
 static const struct rte_pci_id pci_id_ice_map[] = {
{ RTE_PCI_DEVICE(ICE_INTEL_VENDOR_ID, ICE_DEV_ID_E810C_BACKPLANE) },
@@ -147,6 +149,7 @@ static const struct eth_dev_ops ice_eth_dev_ops = {
.vlan_pvid_set= ice_vlan_pvid_set,
.rxq_info_get = ice_rxq_info_get,
.txq_info_get = ice_txq_info_get,
+   .trace_info_get   = ice_trace_info_get,
.get_eeprom_length= ice_get_eeprom_length,
.get_eeprom   = ice_get_eeprom,
.rx_queue_count   = ice_rx_queue_count,
@@ -3765,6 +3768,29 @@ ice_dev_udp_tunnel_port_del(struct rte_eth_dev *dev,
 }
 
 static int
+ice_trace_info_get(struct rte_eth_dev *dev, uint16_t queue_id,
+  enum rte_eth_trace type, char *buf, int sz)
+{
+   int ret;
+
+   switch (type) {
+   case ETH_TRACE_RX_BURST:
+   ret = ice_rx_burst_info_get(dev, queue_id, buf, sz);
+   break;
+
+   case ETH_TRACE_TX_BURST:
+   ret = ice_tx_burst_info_get(dev, queue_id, buf, sz);
+   break;
+
+   default:
+   ret = -ENOTSUP;
+   break;
+   }
+
+   return ret;
+}
+
+static int
 ice_pci_probe(struct rte_pci_driver *pci_drv __rte_unused,
  struct rte_pci_device *pci_dev)
 {
diff --git a/drivers/net/ice/ice_rxtx.c b/drivers/net/ice/ice_rxtx.c
index 0282b53..43d52c2 100644
--- a/drivers/net/ice/ice_rxtx.c
+++ b/drivers/net/ice/ice_rxtx.c
@@ -2385,6 +2385,35 @@ ice_set_rx_function(struct rte_eth_dev *dev)
}
 }
 
+int
+ice_rx_burst_info_get(struct rte_eth_dev *dev, __rte_unused uint16_t queue_id,
+ char *buf, int sz)
+{
+   int len = 0;
+
+   if (dev->rx_pkt_burst == ice_recv_scattered_pkts)
+   len = snprintf(buf, sz, "Scattered Rx");
+   else if (dev->rx_pkt_burst == ice_recv_pkts_bulk_alloc)
+   len = snprintf(buf, sz, "Bulk Rx");
+   else if (dev->rx_pkt_burst == ice_recv_pkts)
+   len = snprintf(buf, sz, "Normal Rx");
+#ifdef RTE_ARCH_X86
+   else if (dev->rx_pkt_burst == ice_recv_scattered_pkts_vec_avx2)
+   len = snprintf(buf, sz, "AVX2 Vector Scattered Rx");
+   else if (dev->rx_pkt_burst == ice_recv_scattered_pkts_vec)
+   len = snprintf(buf, sz, "Vector Scattered Rx");
+   else if (dev->rx_pkt_burst == ice_recv_pkts_vec_avx2)
+   len = snprintf(buf, sz, "AVX2 Vector Rx");
+   else if (dev->rx_pkt_burst == ice_recv_pkts_vec)
+   len = snprintf(buf, sz, "Vector Rx");
+#endif
+
+   if (len >= sz)
+   len = -ENOSPC; /* The output was truncated */
+
+   return len;
+}
+
 void __attribute__((cold))
 ice_set_tx_function_flag(struct rte_eth_dev *dev, struct ice_tx_queue *txq)
 {
@@ -2454,6 +2483,29 @@ ice_prep_pkts(__rte_unused void *tx_queue, struct 
rte_mbuf **tx_pkts,
return i;
 }
 
+int
+ice_tx_burst_info_get(struct rte_eth_dev *dev, __rte_unused uint16_t queue_id,
+ char *buf, int sz)
+{
+   int len = 0;
+
+   if (dev->tx_pkt_burst == ice_xmit_pkts_simple)
+   len = snprintf(buf, sz, "Simple Tx");
+   else if (dev->tx_pkt_burst == ice_xmit_pkts)
+   len = snprintf(buf, sz, "Normal Tx");
+#ifdef RTE_ARCH_X86
+   else if (dev->tx_pkt_burst == ice_xmit_pkts_vec_avx2)
+   len = snprintf(buf, sz, "AVX2 Vector Tx");
+   else if (dev->tx_pkt_burst == ice_xmit_pkts_vec)
+   len = snprintf(buf, sz, "Vector Tx");
+#endif
+
+   if (len >= sz)
+   len = -ENOSPC; /* The output was truncated */
+
+   return len;
+}
+
 void __attribute__((cold))
 ice_set_tx_function(struct rte_eth_dev *dev)
 {
diff --git a/drivers/net/ice/ice_rxtx.h b/drivers/net/ice/ice_rxtx.h
index e921411..f951088 100644
--- a/drivers/net/ice/ice_rxtx.h
+++ b/drivers/net/ice/ice_rxtx.h
@@ -188,4 +188,8 @@ uint16_t ice_recv_scattered_pkts_vec

[dpdk-dev] [RFC v2 1/3] ethdev: add the API for getting trace information

[Haiyue Wang]

Enhance the PMD to support retrieving trace information like
Rx/Tx burst selection etc.

Signed-off-by: Haiyue Wang 
---
 lib/librte_ethdev/rte_ethdev.c  | 18 ++
 lib/librte_ethdev/rte_ethdev.h  |  9 +
 lib/librte_ethdev/rte_ethdev_core.h |  4 
 3 files changed, 31 insertions(+)

diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 17d183e..6098fad 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -4083,6 +4083,24 @@ rte_eth_tx_queue_info_get(uint16_t port_id, uint16_t 
queue_id,
 }
 
 int
+rte_eth_trace_info_get(uint16_t port_id, uint16_t queue_id,
+  enum rte_eth_trace type, char *buf, int sz)
+{
+   struct rte_eth_dev *dev;
+
+   RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+
+   if (buf == NULL)
+   return -EINVAL;
+
+   dev = &rte_eth_devices[port_id];
+
+   RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->trace_info_get, -ENOTSUP);
+
+   return dev->dev_ops->trace_info_get(dev, queue_id, type, buf, sz);
+}
+
+int
 rte_eth_dev_set_mc_addr_list(uint16_t port_id,
 struct rte_ether_addr *mc_addr_set,
 uint32_t nb_mc_addr)
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index dc6596b..9405157 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -404,6 +404,11 @@ struct rte_eth_rxmode {
uint64_t offloads;
 };
 
+enum rte_eth_trace {
+   ETH_TRACE_RX_BURST,
+   ETH_TRACE_TX_BURST,
+};
+
 /**
  * VLAN types to indicate if it is for single VLAN, inner VLAN or outer VLAN.
  * Note that single VLAN is treated the same as inner VLAN.
@@ -3556,6 +3561,10 @@ int rte_eth_rx_queue_info_get(uint16_t port_id, uint16_t 
queue_id,
 int rte_eth_tx_queue_info_get(uint16_t port_id, uint16_t queue_id,
struct rte_eth_txq_info *qinfo);
 
+int
+rte_eth_trace_info_get(uint16_t port_id, uint16_t queue_id,
+   enum rte_eth_trace type, char *buf, int sz);
+
 /**
  * Retrieve device registers and register attributes (number of registers and
  * register size)
diff --git a/lib/librte_ethdev/rte_ethdev_core.h 
b/lib/librte_ethdev/rte_ethdev_core.h
index 2922d5b..366bf5b 100644
--- a/lib/librte_ethdev/rte_ethdev_core.h
+++ b/lib/librte_ethdev/rte_ethdev_core.h
@@ -170,6 +170,9 @@ typedef void (*eth_rxq_info_get_t)(struct rte_eth_dev *dev,
 typedef void (*eth_txq_info_get_t)(struct rte_eth_dev *dev,
uint16_t tx_queue_id, struct rte_eth_txq_info *qinfo);
 
+typedef int (*eth_trace_info_get_t)(struct rte_eth_dev *dev,
+   uint16_t queue_id, enum rte_eth_trace type, char *buf, int sz);
+
 typedef int (*mtu_set_t)(struct rte_eth_dev *dev, uint16_t mtu);
 /**< @internal Set MTU. */
 
@@ -418,6 +421,7 @@ struct eth_dev_ops {
eth_dev_infos_get_tdev_infos_get; /**< Get device info. */
eth_rxq_info_get_t rxq_info_get; /**< retrieve RX queue 
information. */
eth_txq_info_get_t txq_info_get; /**< retrieve TX queue 
information. */
+   eth_trace_info_get_t   trace_info_get; /**< Get trace. */
eth_fw_version_get_t   fw_version_get; /**< Get firmware version. */
eth_dev_supported_ptypes_get_t dev_supported_ptypes_get;
/**< Get packet types supported and identified by device. */
-- 
2.7.4

Re: [dpdk-dev] [RFC v2 1/3] ethdev: add the API for getting trace information

[Stephen Hemminger]

On Tue, 13 Aug 2019 11:06:10 +0800
Haiyue Wang  wrote:

> Enhance the PMD to support retrieving trace information like
> Rx/Tx burst selection etc.
> 
> Signed-off-by: Haiyue Wang 
> ---
>  lib/librte_ethdev/rte_ethdev.c  | 18 ++
>  lib/librte_ethdev/rte_ethdev.h  |  9 +
>  lib/librte_ethdev/rte_ethdev_core.h |  4 
>  3 files changed, 31 insertions(+)
> 
> diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
> index 17d183e..6098fad 100644
> --- a/lib/librte_ethdev/rte_ethdev.c
> +++ b/lib/librte_ethdev/rte_ethdev.c
> @@ -4083,6 +4083,24 @@ rte_eth_tx_queue_info_get(uint16_t port_id, uint16_t 
> queue_id,
>  }
>  
>  int
> +rte_eth_trace_info_get(uint16_t port_id, uint16_t queue_id,
> +enum rte_eth_trace type, char *buf, int sz)
> +{
> + struct rte_eth_dev *dev;
> +
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> +
> + if (buf == NULL)
> + return -EINVAL;
> +
> + dev = &rte_eth_devices[port_id];
> +
> + RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->trace_info_get, -ENOTSUP);
> +
> + return dev->dev_ops->trace_info_get(dev, queue_id, type, buf, sz);

What if queueid is out of bounds?

The bigger problem is that this information is like a log message
and unstructured, which makes it device specific and useless for automation.

Why not just keep it in the log like it is now?

>  int rte_eth_tx_queue_info_get(uint16_t port_id, uint16_t queue_id,
>   struct rte_eth_txq_info *qinfo);
>  
> +int
> +rte_eth_trace_info_get(uint16_t port_id, uint16_t queue_id,
> + enum rte_eth_trace type, char *buf, int sz);
> +

You didn't run checkpatch, otherwise you would have seen complaints
about not listing API as experimental.

Also the API would have to be in the map file as well.

Docbook comments are also missing.

Re: [dpdk-dev] [PATCH] bpf: fix to allow ptr stack program type

[Jerin Jacob Kollanukkaran]

> -Original Message-
> From: Ananyev, Konstantin 
> Sent: Monday, August 12, 2019 5:08 PM
> To: Jerin Jacob Kollanukkaran ; dev@dpdk.org
> Cc: tho...@monjalon.net; sta...@dpdk.org
> Subject: [EXT] RE: [dpdk-dev] [PATCH] bpf: fix to allow ptr stack program
> type
> 
> External Email
> 
> --
> 
> > > Hi Jerin,
> >
> > Hi Konstantin,
> >
> > >
> > > >
> > > > bpf_validate does not allow to execute RTE_BPF_ARG_PTR_STACK for
> > > > no reason.
> > >
> > > I believe there is a reason,
> > > ARG_PTR_STACK is reserved for memory within BPF program internal
> > > stack only.
> > > User that calls BPF program should never pass parameter with that type.
> >
> > OK.
> > Shouldn't we remove that from public header file
> > (lib/librte_bpf/rte_bpf.h) then ?
> 
> Probably... or might be just put extra comments to mark it as internal?
> The reason I left it here, so we can add new public values for enum here,
> before RTE_BPF_ARG_PTR_STACK.
> Of course in theory we can use for RTE_BPF_ARG_PTR_STACK some
> reserved value instead.
> 
> >
> > > If the user allocates parameter for bpf function on the stack, he
> > > can still use RTE_BPF_ARG_PTR for it.
> >
> > I see the _stack_ is only allocated under RTE_BPF_ARG_PTR_STACK checks
> in bpf_validate.c.
> > Can you check? I agree that stack should be allocated for
> RTE_BPF_ARG_PTR as well.
> 
> Not sure I understand your query here...
> Each BPF program can use up to MAX_BPF_STACK_SIZE bytes for stack.
> Though to avoid JIT to allocate unused space for the stack, in bpf_validate.c
> we figure out does given BPF program really allocate things on the stack and
> if yes, how many bytes is needed.
> This info is stored in rte_bpf.stack_sz and can be used later by the JIT.
> Let say for x86 jit is used in  emit_prolog().

I thought, stack will be allocated only when user gives
RTE_BPF_ARG_PTR_STACK.
I tested following program with RTE_BPF_ARG_PTR. It allocates stacks
Properly. So everything is good.

stdw [r10-64], 0xab
mov r0, 0
exit

I will modify this patch to following to avoid any confusion to user:
1) Change RTE_BPF_ARG_PTR_STACK to RTE_BPF_ARG_RESERVED in public header file
2) In the implementation #define RTE_BPF_ARG_RESERVED BPF_ARG_PTR_STACK

Is it OK?

[dpdk-dev] DPDK failes to initailze on VMXNet3

[vikram T]

Hi,
When initialing the DPDK failed with the Below error on VMXNet3:









*Aug  9 14:05:34 vprobe rat_dpdk_sniffer[10768]: EAL: Probing VFIO
support...Aug  9 14:05:34 vprobe rat_dpdk_sniffer[10768]: EAL: PCI device
:02:00.0 on NUMA socket -1Aug  9 14:05:34 vprobe
rat_dpdk_sniffer[10768]: EAL:   Invalid NUMA socket, default to 0Aug  9
14:05:34 vprobe rat_dpdk_sniffer[10768]: EAL:   probe driver: 8086:100f
net_e1000_emAug  9 14:05:34 vprobe rat_dpdk_sniffer[10768]: EAL: PCI device
:03:00.0 on NUMA socket 0Aug  9 14:05:34 vprobe kernel: igb_uio
:03:00.0: uio device registered with irq 58Aug  9 14:05:34 vprobe
rat_dpdk_sniffer[10768]: EAL:   probe driver: 15ad:7b0 net_vmxnet3Aug  9
14:05:34 vprobe rat_dpdk_sniffer[10768]: PANIC in
rte_eth_dev_shared_data_prepare():Aug  9 14:05:34 vprobe
rat_dpdk_sniffer[10768]: Cannot allocate ethdev shared data*

With the BackTrace pointing to :













*(gdb) bt#0  0x754612c7 in raise () from /lib64/libc.so.6#1
 0x754629b8 in abort () from /lib64/libc.so.6#2  0x004eab34
in __rte_panic ()#3  0x0050cbf8 in rte_eth_dev_shared_data_prepare
()#4  0x0050de1c in rte_eth_dev_allocate ()#5  0x00667025
in eth_vmxnet3_pci_probe ()#6  0x005b4178 in pci_probe_all_drivers
()#7  0x005b42bc in rte_pci_probe ()#8  0x0053642c in
rte_bus_probe ()#9  0x005242ee in rte_eal_init ()#10
0x006c24c7 in rat::dpdk::init (cfg=...) at
../../rat/src/sniffer/dpdk_utils.cc:71*

The sample application testpmd was running successfully:



























*[root@vprobe test-pmd]# ./testpmd -l 0-3 -n 4 -- -i --portmask=0x1
--nb-cores=2EAL: Detected 16 lcore(s)EAL: Detected 4 NUMA nodesEAL:
Multi-process socket /var/run/dpdk/rte/mp_socketEAL: No free hugepages
reported in hugepages-2048kBEAL: No free hugepages reported in
hugepages-2048kBEAL: Probing VFIO support...EAL: PCI device :02:00.0 on
NUMA socket -1EAL:   Invalid NUMA socket, default to 0EAL:   probe driver:
8086:100f net_e1000_emEAL: PCI device :03:00.0 on NUMA socket 0EAL:
probe driver: 15ad:7b0 net_vmxnet3Interactive-mode selectedtestpmd: create
a new mbuf pool : n=171456, size=2176, socket=0testpmd:
preferred mempool ops selected: ring_mp_mcWarning! port-topology=paired and
odd forward ports number, the last port will pair with itself.Configuring
Port 0 (socket 0)Port 0: 00:0C:29:36:B2:F1Checking link
statuses...Donetestpmd> startio packet forwarding - ports=1 - cores=1 -
streams=1 - NUMA support enabled, MP allocation mode: nativeLogical Core 1
(socket 0) forwards packets on 1 streams:  RX P=0/Q=0 (socket 0) -> TX
P=0/Q=0 (socket 0) peer=02:00:00:00:00:00*

Additionally I observed that on this virtual machine file
*"/sys/bus/pci/devices/:03:00.0/numa_node"* is set as -1 and when
sample application are run the programs detects 4 NUMA Nodes.
But on any other physical machine it is properly set to appropriate
numa_node.


It would be of great help if I get pointers on why the initialization fails
here.

Regards
Vikram

Re: [dpdk-dev] [RFC v2 1/3] ethdev: add the API for getting trace information

[Wang, Haiyue]

> -Original Message-
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Tuesday, August 13, 2019 11:25
> To: Wang, Haiyue 
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [RFC v2 1/3] ethdev: add the API for getting trace 
> information
> 
> On Tue, 13 Aug 2019 11:06:10 +0800
> Haiyue Wang  wrote:
> 
> > Enhance the PMD to support retrieving trace information like
> > Rx/Tx burst selection etc.
> >
> > Signed-off-by: Haiyue Wang 
> > ---
> >  lib/librte_ethdev/rte_ethdev.c  | 18 ++
> >  lib/librte_ethdev/rte_ethdev.h  |  9 +
> >  lib/librte_ethdev/rte_ethdev_core.h |  4 
> >  3 files changed, 31 insertions(+)
> >
> > diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
> > index 17d183e..6098fad 100644
> > --- a/lib/librte_ethdev/rte_ethdev.c
> > +++ b/lib/librte_ethdev/rte_ethdev.c
> > @@ -4083,6 +4083,24 @@ rte_eth_tx_queue_info_get(uint16_t port_id, uint16_t 
> > queue_id,
> >  }
> >
> >  int
> > +rte_eth_trace_info_get(uint16_t port_id, uint16_t queue_id,
> > +  enum rte_eth_trace type, char *buf, int sz)
> > +{
> > +   struct rte_eth_dev *dev;
> > +
> > +   RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> > +
> > +   if (buf == NULL)
> > +   return -EINVAL;
> > +
> > +   dev = &rte_eth_devices[port_id];
> > +
> > +   RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->trace_info_get, -ENOTSUP);
> > +
> > +   return dev->dev_ops->trace_info_get(dev, queue_id, type, buf, sz);
> 
> What if queueid is out of bounds?

Some trace may not need queueid, so skip it check here, make it a little
flexible.

> 
> The bigger problem is that this information is like a log message
> and unstructured, which makes it device specific and useless for automation.
> 
> Why not just keep it in the log like it is now?

Yes, log is good now (but need run with extra options). This patch works like
run time debug tool, it identify the code running status. Not for automation
now. But if we want this kind of things, hook the code point, define a rule
to format the message.

> 
> >  int rte_eth_tx_queue_info_get(uint16_t port_id, uint16_t queue_id,
> > struct rte_eth_txq_info *qinfo);
> >
> > +int
> > +rte_eth_trace_info_get(uint16_t port_id, uint16_t queue_id,
> > +   enum rte_eth_trace type, char *buf, int sz);
> > +
> 
> You didn't run checkpatch, otherwise you would have seen complaints
> about not listing API as experimental.
> 

./devtools/checkpatches.sh ?

3/3 valid patches


> Also the API would have to be in the map file as well.
> 
> Docbook comments are also missing.
> 
> 

This is rough draft, so show the code firstly. ;-)

Re: [dpdk-dev] [v5] net/i40e: fix vf runtime queues rss config

[Ye Xiaolong]

Hi, Xiao

On 08/13, Xiao Zhang wrote:
>I40evf queue can not work properly with kernel pf driver. Eg. when
>configure 8 queues pair, only 4 queues can receive packets, and half
>packets will be lost if using 2 queues pair.
>This issue is caused by misconfiguration of look up table, use aq
>command to setup the lut to make it work properly.

So the original code of lookup table configuration is problematic? Can we just
remove them?

Thanks,
Xiaolong

>
>Fixes: cea7a51c1750 ("i40evf: support RSS")
>Cc: sta...@dpdk.org
>
>Signed-off-by: Xiao Zhang 
>---
>v5 fix compile issue
>v4 move local variable definition to the begin of the function
>v3 move LUT configuration in to i40evf_configure_rss
>v2 change for loop format to avoid build patch issue
>---
> drivers/net/i40e/i40e_ethdev_vf.c | 32 ++--
> 1 file changed, 26 insertions(+), 6 deletions(-)
>
>diff --git a/drivers/net/i40e/i40e_ethdev_vf.c 
>b/drivers/net/i40e/i40e_ethdev_vf.c
>index 308fb98..c77b30c 100644
>--- a/drivers/net/i40e/i40e_ethdev_vf.c
>+++ b/drivers/net/i40e/i40e_ethdev_vf.c
>@@ -2598,7 +2598,10 @@ i40evf_config_rss(struct i40e_vf *vf)
>   struct i40e_hw *hw = I40E_VF_TO_HW(vf);
>   struct rte_eth_rss_conf rss_conf;
>   uint32_t i, j, lut = 0, nb_q = (I40E_VFQF_HLUT_MAX_INDEX + 1) * 4;
>+  uint32_t rss_lut_size = (I40E_VFQF_HLUT1_MAX_INDEX + 1) * 4;
>   uint16_t num;
>+  uint8_t *lut_info;
>+  int ret;
> 
>   if (vf->dev_data->dev_conf.rxmode.mq_mode != ETH_MQ_RX_RSS) {
>   i40evf_disable_rss(vf);
>@@ -2608,12 +2611,29 @@ i40evf_config_rss(struct i40e_vf *vf)
> 
>   num = RTE_MIN(vf->dev_data->nb_rx_queues, I40E_MAX_QP_NUM_PER_VF);
>   /* Fill out the look up table */
>-  for (i = 0, j = 0; i < nb_q; i++, j++) {
>-  if (j >= num)
>-  j = 0;
>-  lut = (lut << 8) | j;
>-  if ((i & 3) == 3)
>-  I40E_WRITE_REG(hw, I40E_VFQF_HLUT(i >> 2), lut);
>+  if (!(vf->flags & I40E_FLAG_RSS_AQ_CAPABLE)) {
>+  for (i = 0, j = 0; i < nb_q; i++, j++) {
>+  if (j >= num)
>+  j = 0;
>+  lut = (lut << 8) | j;
>+  if ((i & 3) == 3)
>+  I40E_WRITE_REG(hw, I40E_VFQF_HLUT(i >> 2), lut);
>+  }
>+  } else {
>+  lut_info = rte_zmalloc("i40e_rss_lut", rss_lut_size, 0);
>+  if (!lut_info) {
>+  PMD_DRV_LOG(ERR, "No memory can be allocated");
>+  return -ENOMEM;
>+  }
>+
>+  for (i = 0; i < rss_lut_size; i++)
>+  lut_info[i] = i % vf->num_queue_pairs;
>+
>+  ret = i40evf_set_rss_lut(&vf->vsi, lut_info,
>+   rss_lut_size);
>+  rte_free(lut_info);
>+  if (ret)
>+  return ret;
>   }
> 
>   rss_conf = vf->dev_data->dev_conf.rx_adv_conf.rss_conf;
>-- 
>2.7.4
>

Re: [dpdk-dev] [PATCH] buildtools: lighter experimental symbol check

[David Marchand]

On Mon, Aug 12, 2019 at 10:14 PM Neil Horman  wrote:
>
> On Mon, Aug 12, 2019 at 09:02:28AM +0200, David Marchand wrote:
> > Dumping every object file for every symbol is too heavy.
> > Use a temporary storage.
> >
> > Before:
> > $ rm -rf master && make defconfig O=master
> > $ time make EXTRA_CFLAGS=-g O=master
> > [...]
> > real  2m24.063s
> > user  1m16.985s
> > sys   1m46.372s
> >
> > After:
> > $ rm -rf master && make defconfig O=master
> > $ time make EXTRA_CFLAGS=-g O=master
> > [...]
> > real  1m37.110s
> > user  0m49.417s
> > sys   0m51.803s
> >
> > Signed-off-by: David Marchand 
> > ---
> >  buildtools/check-experimental-syms.sh | 15 ---
> >  1 file changed, 8 insertions(+), 7 deletions(-)
> >
> > diff --git a/buildtools/check-experimental-syms.sh 
> > b/buildtools/check-experimental-syms.sh
> > index 0f6c62d..47a06fc 100755
> > --- a/buildtools/check-experimental-syms.sh
> > +++ b/buildtools/check-experimental-syms.sh
> > @@ -18,14 +18,15 @@ then
> >   exit 0
> >  fi
> >
> > +DUMPFILE=$(mktemp -t dpdk.${0##*/}.XXX.objdump)
> > +trap 'rm -f "$DUMPFILE"' EXIT

"If a sigspec is EXIT (0) the command arg is executed on exit from the shell."

> > +objdump -t $OBJFILE >$DUMPFILE
> > +
> When does this temporary file get deleted?

It should be enough?

-- 
David Marchand

[dpdk-dev] [PATCH] devtools: fix cleanup of temp file

[David Marchand]

The regexp part of the cleanup routine was not updated accordingly when
a common prefix for temp files was introduced.
Set the trap handler only when required.

Fixes: ff37ca5d3773 ("devtools: use a common prefix for temporary files")
Cc: sta...@dpdk.org

Signed-off-by: David Marchand 
---
 devtools/checkpatches.sh | 26 --
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/devtools/checkpatches.sh b/devtools/checkpatches.sh
index 8e2beee..b16bace 100755
--- a/devtools/checkpatches.sh
+++ b/devtools/checkpatches.sh
@@ -36,14 +36,6 @@ 
LINE_SPACING,PARENTHESIS_ALIGNMENT,NETWORKING_BLOCK_COMMENT_STYLE,\
 NEW_TYPEDEFS,COMPARISON_TO_NULL"
 options="$options $DPDK_CHECKPATCH_OPTIONS"
 
-clean_tmp_files() {
-   if echo $tmpinput | grep -q '^checkpatches\.' ; then
-   rm -f "$tmpinput"
-   fi
-}
-
-trap "clean_tmp_files" INT
-
 print_usage () {
cat <<- END_OF_HELP
usage: $(basename $0) [-q] [-v] [-nX|-r range|patch1 [patch2] ...]]
@@ -150,13 +142,16 @@ check () { #   
! $verbose || print_headline "$3"
if [ -n "$1" ] ; then
tmpinput=$1
-   elif [ -n "$2" ] ; then
-   tmpinput=$(mktemp -t dpdk.checkpatches.XX)
-   git format-patch --find-renames \
-   --no-stat --stdout -1 $commit > "$tmpinput"
else
tmpinput=$(mktemp -t dpdk.checkpatches.XX)
-   cat > "$tmpinput"
+   trap "rm -f '$tmpinput'" INT
+
+   if [ -n "$2" ] ; then
+   git format-patch --find-renames \
+   --no-stat --stdout -1 $commit > "$tmpinput"
+   else
+   cat > "$tmpinput"
+   fi
fi
 
! $verbose || printf 'Running checkpatch.pl:\n'
@@ -191,7 +186,10 @@ check () { #   
ret=1
fi
 
-   clean_tmp_files
+   if [ "$tmpinput" != "$1" ]; then
+   rm -f "$tmpinput"
+   trap - INT
+   fi
[ $ret -eq 0 ] && return 0
 
status=$(($status + 1))
-- 
1.8.3.1

Re: [dpdk-dev] [PATCH] doc: announce malloc virt2phys symbol removal

[Kinsella, Ray]

> -Original Message-
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Monday 5 August 2019 16:13
> To: David Marchand 
> Cc: dev ; Burakov, Anatoly ;
> Richardson, Bruce ; Kinsella, Ray
> ; Traynor, Kevin ; Stephen
> Hemminger 
> Subject: Re: [dpdk-dev] [PATCH] doc: announce malloc virt2phys symbol
> removal
> 
> 05/08/2019 17:05, David Marchand:
> > On Mon, Aug 5, 2019 at 4:39 PM Thomas Monjalon 
> wrote:
> > > 02/08/2019 15:29, David Marchand:
> > > > This symbol has been deprecated for quite some time.
> > > > Let's drop it in the next release.
> > > > ---
> > > > --- a/doc/guides/rel_notes/deprecation.rst
> > > > +++ b/doc/guides/rel_notes/deprecation.rst
> > > > +* eal: The ``rte_malloc_virt2phy`` function has been deprecated
> > > > +and replaced
> > > > +  by ``rte_malloc_virt2iova`` since v17.11 and will be removed
> in DPDK 19.11.
> > >
> > > For this patch and another one about removing
> > > rte_cpu_check_supported(), I have a general comment on the date of
> removal.
> > >
> > > As was stated recently in the contribution guide:
> > > http://git.dpdk.org/dpdk/commit/?id=7abe4a24cc
> > > "Deprecated APIs are removed completely just after the next
> LTS."
> > >
> > > The idea behind this policy is to avoid removals during LTS
> > > releases, in order to have at least one release before X.11 LTS for
> > > end users to prepare replacing the usage of the removed API.
> > >
> > > Does it make sense to postpone any API removal after 19.11?
> >
> > Those symbols have been marked as deprecated for a long time.
> > Users had to either disable Werror or they actually migrated to the
> new apis.
> > If they chose the lazy way of not migrating to the new apis, I
> suspect
> > they forgot about it and/or they won't look at the release notes.
> 
> Yes I agree.
> That's why they can be surprised when hitting the removal.
> Avoiding this removal in LTS release is one more care for the lazy
> users. The question: is too much caution?
> 
> > I don't particularly have a problem with waiting for 20.02, those are
> > easy to remove anyway.
> 
> 

My 2c is that if they are have signalled as deprecated since v17.11.
They are fair game for removal at this point. 

Ray K

Re: [dpdk-dev] [PATCH] bpf: fix to allow ptr stack program type

[Ananyev, Konstantin]

Hi Jerin,

> > > > >
> > > > > bpf_validate does not allow to execute RTE_BPF_ARG_PTR_STACK for
> > > > > no reason.
> > > >
> > > > I believe there is a reason,
> > > > ARG_PTR_STACK is reserved for memory within BPF program internal
> > > > stack only.
> > > > User that calls BPF program should never pass parameter with that type.
> > >
> > > OK.
> > > Shouldn't we remove that from public header file
> > > (lib/librte_bpf/rte_bpf.h) then ?
> >
> > Probably... or might be just put extra comments to mark it as internal?
> > The reason I left it here, so we can add new public values for enum here,
> > before RTE_BPF_ARG_PTR_STACK.
> > Of course in theory we can use for RTE_BPF_ARG_PTR_STACK some
> > reserved value instead.
> >
> > >
> > > > If the user allocates parameter for bpf function on the stack, he
> > > > can still use RTE_BPF_ARG_PTR for it.
> > >
> > > I see the _stack_ is only allocated under RTE_BPF_ARG_PTR_STACK checks
> > in bpf_validate.c.
> > > Can you check? I agree that stack should be allocated for
> > RTE_BPF_ARG_PTR as well.
> >
> > Not sure I understand your query here...
> > Each BPF program can use up to MAX_BPF_STACK_SIZE bytes for stack.
> > Though to avoid JIT to allocate unused space for the stack, in 
> > bpf_validate.c
> > we figure out does given BPF program really allocate things on the stack and
> > if yes, how many bytes is needed.
> > This info is stored in rte_bpf.stack_sz and can be used later by the JIT.
> > Let say for x86 jit is used in  emit_prolog().
> 
> I thought, stack will be allocated only when user gives
> RTE_BPF_ARG_PTR_STACK.
> I tested following program with RTE_BPF_ARG_PTR. It allocates stacks
> Properly. So everything is good.
> 
> stdw [r10-64], 0xab
> mov r0, 0
> exit
> 
> I will modify this patch to following to avoid any confusion to user:
> 1) Change RTE_BPF_ARG_PTR_STACK to RTE_BPF_ARG_RESERVED in public header file
> 2) In the implementation #define RTE_BPF_ARG_RESERVED BPF_ARG_PTR_STACK
> 
> Is it OK?

Yes, sounds like a good approach to me.
Thanks
Konstantin