[PATCH v2] app/testpmd: fix secondary process not forwarding

[Shiyang He]

Under multi-process scenario, the secondary process gets queue state
from the wrong location (the global variable 'ports'). Therefore, the
secondary process can not forward since "stream_init" is not called.

This commit fixes the issue by calling 'rte_eth_rx/tx_queue_info_get'
to get queue state from shared memory.

Fixes: 3c4426db54fc ("app/testpmd: do not poll stopped queues")
Cc: sta...@dpdk.org

Signed-off-by: Shiyang He 
Acked-by: Yuying Zhang 

v2: Add function return value processing
---
 app/test-pmd/testpmd.c | 35 +--
 1 file changed, 33 insertions(+), 2 deletions(-)

diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 0c14325b8d..b450f3f6c4 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -2418,9 +2418,40 @@ start_packet_forwarding(int with_tx_first)
if (!pkt_fwd_shared_rxq_check())
return;
 
-   if (stream_init != NULL)
-   for (i = 0; i < cur_fwd_config.nb_fwd_streams; i++)
+   if (stream_init != NULL) {
+   for (i = 0; i < cur_fwd_config.nb_fwd_streams; i++) {
+   if (rte_eal_process_type() == RTE_PROC_SECONDARY) {
+   struct fwd_stream *fs = fwd_streams[i];
+   struct rte_eth_rxq_info rx_qinfo;
+   struct rte_eth_txq_info tx_qinfo;
+   int32_t rc;
+   rc = rte_eth_rx_queue_info_get(fs->rx_port,
+   fs->rx_queue, &rx_qinfo);
+   if (!rc)
+   
ports[fs->rx_port].rxq[fs->rx_queue].state =
+   rx_qinfo.queue_state;
+   else if (-ENOTSUP == rc)
+   
ports[fs->rx_port].rxq[fs->rx_queue].state =
+   RTE_ETH_QUEUE_STATE_STARTED;
+   else
+   TESTPMD_LOG(WARNING,
+   "Failed to get rx queue 
info\n");
+
+   rc = rte_eth_tx_queue_info_get(fs->tx_port,
+   fs->tx_queue, &tx_qinfo);
+   if (!rc)
+   
ports[fs->tx_port].txq[fs->tx_queue].state =
+   tx_qinfo.queue_state;
+   else if (-ENOTSUP == rc)
+   
ports[fs->tx_port].txq[fs->tx_queue].state =
+   RTE_ETH_QUEUE_STATE_STARTED;
+   else
+   TESTPMD_LOG(WARNING,
+   "Failed to get tx queue 
info\n");
+   }
stream_init(fwd_streams[i]);
+   }
+   }
 
port_fwd_begin = cur_fwd_config.fwd_eng->port_fwd_begin;
if (port_fwd_begin != NULL) {
-- 
2.37.2

dev@dpdk.org

[bugzilla]

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

Bug ID: 1163
   Summary: [dpdk-23.03-rc1] app/test-pmd/cmdline_flow meson build
failed with cflag param optimization=1 on Ubuntu22.04
&&RHEL8.6 with gcc11.3.0&&8.5.0
   Product: DPDK
   Version: 23.03
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: major
  Priority: Normal
 Component: core
  Assignee: dev@dpdk.org
  Reporter: daxuex@intel.com
  Target Milestone: ---

[DPDK version]
commit 9bd5ebca59c865aead7096358fb733e53a72007b (HEAD, tag: v23.03-rc1,
origin/main, origin/HEAD, main)
Author: Thomas Monjalon 
Date:   Mon Feb 20 16:53:44 2023 +0100

version: 23.03-rc1

Signed-off-by: Thomas Monjalon 

[OS version]
gcc11.3.0
Ubuntu22.04/5.15.0-58-generic

RHEL8.6/4.18.0-372.9.1.el8.x86_64
gcc8.5.0

[Test setup]
export RTE_TARGET=x86_64-native-linuxapp-gcc
CC=gcc meson --optimization=1 --werror -Denable_kmods=True  -Dlibdir=lib 
--default-library=static x86_64-native-linuxapp-gcc
ninja -C x86_64-native-linuxapp-gcc -j 10

[Error]
Found ninja-1.10.0.git.kitware.jobserver-1 at /usr/local/bin/ninja
ninja: Entering directory `x86_64-native-linuxapp-gcc'
[2900/3094] Compiling C object app/dpdk-testpmd.p/test-pmd_cmdline_flow.c.o
FAILED: app/dpdk-testpmd.p/test-pmd_cmdline_flow.c.o
gcc -Iapp/dpdk-testpmd.p -Iapp -I../app -Iapp/test-pmd -I../app/test-pmd
-Ilib/ethdev -I../lib/ethdev -I. -I.. -Iconfig -I../config -Ilib/eal/include
-I../lib/eal/include -Ilib/eal/linux/include -I../lib/eal/linux/include
-Ilib/eal/x86/include -I../lib/eal/x86/include -Ilib/eal/common
-I../lib/eal/common -Ilib/eal -I../lib/eal -Ilib/kvargs -I../lib/kvargs
-Ilib/metrics -I../lib/metrics -Ilib/telemetry -I../lib/telemetry -Ilib/net
-I../lib/net -Ilib/mbuf -I../lib/mbuf -Ilib/mempool -I../lib/mempool -Ilib/ring
-I../lib/ring -Ilib/meter -I../lib/meter -Ilib/cmdline -I../lib/cmdline
-Idrivers/crypto/scheduler -I../drivers/crypto/scheduler -Ilib/cryptodev
-I../lib/cryptodev -Ilib/rcu -I../lib/rcu -Idrivers/bus/vdev
-I../drivers/bus/vdev -Ilib/reorder -I../lib/reorder -Ilib/bitratestats
-I../lib/bitratestats -Ilib/bpf -I../lib/bpf -Ilib/gro -I../lib/gro -Ilib/gso
-I../lib/gso -Ilib/latencystats -I../lib/latencystats -Ilib/pdump
-I../lib/pdump -Ilib/pcapng -I../lib/pcapng -Idrivers/net/bnxt
-I../drivers/net/bnxt -Idrivers/net/bnxt/tf_ulp -I../drivers/net/bnxt/tf_ulp
-Idrivers/net/bnxt/tf_ulp/generic_templates
-I../drivers/net/bnxt/tf_ulp/generic_templates -Idrivers/net/bnxt/tf_core
-I../drivers/net/bnxt/tf_core -Idrivers/net/bnxt/hcapi/cfa
-I../drivers/net/bnxt/hcapi/cfa -Idrivers/bus/pci -I../drivers/bus/pci
-I../drivers/bus/pci/linux -Ilib/pci -I../lib/pci -Idrivers/net/i40e
-I../drivers/net/i40e -Idrivers/net/i40e/base -I../drivers/net/i40e/base
-Ilib/hash -I../lib/hash -Idrivers/net/ixgbe -I../drivers/net/ixgbe
-Idrivers/net/ixgbe/base -I../drivers/net/ixgbe/base -Ilib/security
-I../lib/security -Idrivers/bus/dpaa -I../drivers/bus/dpaa
-I../drivers/bus/dpaa/include -I../drivers/bus/dpaa/base/qbman
-Idrivers/common/dpaax -I../drivers/common/dpaax
-I../drivers/common/dpaax/caamflib -Ilib/eventdev -I../lib/eventdev -Ilib/timer
-I../lib/timer -Idrivers/mempool/dpaa -I../drivers/mempool/dpaa
-Idrivers/net/dpaa -I../drivers/net/dpaa -Idrivers/net/bonding
-I../drivers/net/bonding -Ilib/sched -I../lib/sched -Ilib/ip_frag
-I../lib/ip_frag -Idrivers/net/ice -I../drivers/net/ice -Idrivers/net/ice/base
-I../drivers/net/ice/base -Idrivers/common/iavf -I../drivers/common/iavf
-fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra
-Werror -O1 -include rte_config.h -Wcast-qual -Wdeprecated -Wformat
-Wformat-nonliteral -Wformat-security -Wmissing-declarations
-Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wpointer-arith
-Wsign-compare -Wstrict-prototypes -Wundef -Wwrite-strings
-Wno-address-of-packed-member -Wno-packed-not-aligned
-Wno-missing-field-initializers -Wno-zero-length-bounds -D_GNU_SOURCE
-march=native -DALLOW_EXPERIMENTAL_API -Wno-deprecated-declarations -MD -MQ
app/dpdk-testpmd.p/test-pmd_cmdline_flow.c.o -MF
app/dpdk-testpmd.p/test-pmd_cmdline_flow.c.o.d -o
app/dpdk-testpmd.p/test-pmd_cmdline_flow.c.o -c ../app/test-pmd/cmdline_flow.c
../app/test-pmd/cmdline_flow.c: In function ‘parse_vc_modify_field_level’:
../app/test-pmd/cmdline_flow.c:8678:53: error: ‘fp’ may be used uninitialized
in this function [-Werror=maybe-uninitialized]
 8678 | action->dst.flex_handle = fp->flex_handle;
  |   ~~^
cc1: all warnings being treated as errors
[2909/3094] Compiling C object app/dpdk-testpmd.p/test-pmd_noisy_vnf.c.o
ninja: build stopped: subcommand failed.

[Bad commit]
commit c8e25fbf1440a5eb9c022f021354b7598c60732e
Author: Rongwei Liu 
Date:   Mon Feb 6 05:39:05 2023 +0200

ethdev: add flow flex modify

Add flex

RE: [PATCH v2 2/3] doc: update outdated information for the nfp PMD

[Chaoyong He]

> On 2/20/2023 8:41 AM, Chaoyong He wrote:
> > From: Walter Heymans 
> >
> > Update nfp documentation with new information and remove outdated
> > information. The most significant changes that are updated include:
> > - Previously the NFP PMD did not support functionality to control VFs,
> >   it now does.
> 
> What I understand is DPDK supports VF but if PF is bound to Linux driver.
> 
> Previously support matrix was as following:
> 
> PFVF  is supported
>   -  --
>   Linux  DPDK Yes
>   DPDK-   Yes
>   DPDK   DPDK NO
>   DPDK   Linux?No (not recommended)
> 
> 
> Is PF:DPDK, VF:DPDK supported now?
> This requires DPDK PF driver updated to manage VFs, if so can you please list
> commits that adds this support in this commit log?

Yes, we support this mode now.
But actually, our PMD didn't do anything to support it.
After the VFIO module in kernel has support vf (not sure about the exact kernel 
version import this), we can directly use the command below to support this 
mode.
modprobe vfio-pci enable_sriov=1 disable_idle_d3=1
dpdk-devbind.py -b vfio-pci xx:yy.z
echo 2 > /sys/bus/pci/devices/\:xx\:yy.z/sriov_numvfs
And we get this information first time in this link: 
https://lwn.net/Articles/813045/

> 
> > - Previously the PF had to be bound to the kernel driver to create VFs,
> >   then VFs were created and bound to 'vfio-pci'. Currently it is
> >   possible to bind the PF to 'vfio-pci' and create VFs bound to
> >   'vfio-pci'.
> > - The name of the Linux kernel driver changed for VFs. Previously the
> >   'nfp_netvf' module was used, but now both PFs and VFs use the 'nfp'
> >   module.
> >
> > Signed-off-by: Walter Heymans 
> > Reviewed-by: Chaoyong He 
> > Reviewed-by: Niklas Söderlund 
> 
> <...>
> 
> > @@ -209,8 +207,8 @@ vNIC service will keep polling packets from the
> > firmware, and multiplex them  to the corresponding representor port.
> >
> >  In the Tx direction, the representor port will prepend the output
> > port -information into metadata for each packet, and then send it to
> > firmware through -PF vNIC.
> > +information into metadata for each packet, and then send it to the
> > +firmware through the PF vNIC.
> >
> 
> Above change belongs to first patch.

Thanks, we will move it in the next version.

[PATCH] event/cnxk: add WQE stashing support

[pbhagavatula]

From: Pavan Nikhilesh 

CN10K supports stashing the scheduled WQE carried by `rte_event` to the
cores L2 Dcache.The number of cache lines to be stashed and the offset
is configurable per HWGRP i.e. event queue.

By default, stashing is enabled on queues which have been connected to
Rx adapter. Stashing improves performance by upto 6% based on the
workload. Both MBUF and NIX_RX_WQE_HDR + NIX_RX_PARSE_S are stashed.

Add device arguments to support configuring WQE stashing.
The dictionary format for device arguments is as follows
`[Qx|stash_offset|stash_length]` here the stash offset can be a
negative integer.

  For stashing mbuf on queue 0 and mbuf + headroom on queue 1
  -a 0002:1e:00.0,stash="[0|-1|1][1|-1|2]"

Signed-off-by: Pavan Nikhilesh 
---
 doc/guides/eventdevs/cnxk.rst   | 14 ++
 drivers/common/cnxk/roc_api.h   |  3 ++
 drivers/common/cnxk/roc_features.h  | 13 ++
 drivers/common/cnxk/roc_mbox.h  | 10 +
 drivers/common/cnxk/roc_model.h |  6 +++
 drivers/common/cnxk/roc_sso.c   | 49 -
 drivers/common/cnxk/roc_sso.h   | 11 -
 drivers/common/cnxk/version.map |  1 +
 drivers/event/cnxk/cn10k_eventdev.c | 30 +
 drivers/event/cnxk/cn10k_eventdev.h |  3 ++
 drivers/event/cnxk/cnxk_eventdev.c  | 66 ++---
 drivers/event/cnxk/cnxk_eventdev.h  | 11 -
 12 files changed, 207 insertions(+), 10 deletions(-)
 create mode 100644 drivers/common/cnxk/roc_features.h

diff --git a/doc/guides/eventdevs/cnxk.rst b/doc/guides/eventdevs/cnxk.rst
index a91c947c10..c3c0bfd7b5 100644
--- a/doc/guides/eventdevs/cnxk.rst
+++ b/doc/guides/eventdevs/cnxk.rst
@@ -102,6 +102,20 @@ Runtime Config Options

 -a 0002:0e:00.0,qos=[1-50-50]

+- ``CN10K WQE stashing support``
+
+  CN10K supports stashing the scheduled WQE carried by `rte_event` to the
+  cores L2 Dcache. The number of cache lines to be stashed and the offset
+  is configurable per HWGRP i.e. event queue. The dictionary format is as
+  follows `[Qx|stash_offset|stash_length]` here the stash offset can be
+  a negative integer.
+  By default stashing is not enabled.
+
+  For example::
+
+For stashing mbuf on queue 0 and mbuf + headroom on queue 1
+-a 0002:0e:00.0,stash="[0|-1|1][1|-1|2]"
+
 - ``Force Rx Back pressure``

Force Rx back pressure when same mempool is used across ethernet device
diff --git a/drivers/common/cnxk/roc_api.h b/drivers/common/cnxk/roc_api.h
index 9d7f5417c2..993a2f7a68 100644
--- a/drivers/common/cnxk/roc_api.h
+++ b/drivers/common/cnxk/roc_api.h
@@ -47,6 +47,9 @@
 /* HW Errata */
 #include "roc_errata.h"

+/* HW Features */
+#include "roc_features.h"
+
 /* Mbox */
 #include "roc_mbox.h"

diff --git a/drivers/common/cnxk/roc_features.h 
b/drivers/common/cnxk/roc_features.h
new file mode 100644
index 00..f3948af45e
--- /dev/null
+++ b/drivers/common/cnxk/roc_features.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2022 Marvell.
+ */
+#ifndef _ROC_FEATURES_H_
+#define _ROC_FEATURES_H_
+
+static inline bool
+roc_feature_sso_has_stash(void)
+{
+   return (roc_model_is_cn103xx() | roc_model_is_cn10ka_b0()) ? true : 
false;
+}
+
+#endif
diff --git a/drivers/common/cnxk/roc_mbox.h b/drivers/common/cnxk/roc_mbox.h
index a6091a98c1..af3c10b0b0 100644
--- a/drivers/common/cnxk/roc_mbox.h
+++ b/drivers/common/cnxk/roc_mbox.h
@@ -127,6 +127,8 @@ struct mbox_msghdr {
M(SSO_CONFIG_LSW, 0x612, ssow_config_lsw, ssow_config_lsw, msg_rsp)\
M(SSO_HWS_CHNG_MSHIP, 0x613, ssow_chng_mship, ssow_chng_mship, \
  msg_rsp) \
+   M(SSO_GRP_STASH_CONFIG, 0x614, sso_grp_stash_config,   \
+ sso_grp_stash_cfg, msg_rsp)  \
/* TIM mbox IDs (range 0x800 - 0x9FF) */   \
M(TIM_LF_ALLOC, 0x800, tim_lf_alloc, tim_lf_alloc_req, \
  tim_lf_alloc_rsp)\
@@ -1374,6 +1376,14 @@ struct sso_grp_qos_cfg {
uint16_t __io iaq_thr;
 };

+struct sso_grp_stash_cfg {
+   struct mbox_msghdr hdr;
+   uint16_t __io grp;
+   uint8_t __io ena;
+   uint8_t __io offset : 4;
+   uint8_t __io num_linesm1 : 4;
+};
+
 struct sso_grp_stats {
struct mbox_msghdr hdr;
uint16_t __io grp;
diff --git a/drivers/common/cnxk/roc_model.h b/drivers/common/cnxk/roc_model.h
index 081c03915c..ba0fe577c0 100644
--- a/drivers/common/cnxk/roc_model.h
+++ b/drivers/common/cnxk/roc_model.h
@@ -244,6 +244,12 @@ roc_model_is_cn10kb(void)
return roc_model->flag & ROC_MODEL_CN103xx;
 }

+static inline uint64_t
+roc_model_is_cn103xx(void)
+{
+   return roc_model->flag & ROC_MODEL_CN103xx;
+}
+
 static inline bool
 roc_env_is_hw(void)
 {
diff --git a/drivers/common/cnxk/roc_sso.c b/drivers/common/cnxk/roc_sso.c
index 9e466f09ef..4a6a5080f7 100644

Re: [PATCH v2 2/3] doc: update outdated information for the nfp PMD

[Ferruh Yigit]

On 2/21/2023 9:04 AM, Chaoyong He wrote:
>> On 2/20/2023 8:41 AM, Chaoyong He wrote:
>>> From: Walter Heymans 
>>>
>>> Update nfp documentation with new information and remove outdated
>>> information. The most significant changes that are updated include:
>>> - Previously the NFP PMD did not support functionality to control VFs,
>>>   it now does.
>>
>> What I understand is DPDK supports VF but if PF is bound to Linux driver.
>>
>> Previously support matrix was as following:
>>
>> PFVF  is supported
>>   -  --
>>   Linux  DPDK Yes
>>   DPDK-   Yes
>>   DPDK   DPDK NO
>>   DPDK   Linux?No (not recommended)
>>
>>
>> Is PF:DPDK, VF:DPDK supported now?
>> This requires DPDK PF driver updated to manage VFs, if so can you please list
>> commits that adds this support in this commit log?
> 
> Yes, we support this mode now.
> But actually, our PMD didn't do anything to support it.
> After the VFIO module in kernel has support vf (not sure about the exact 
> kernel version import this), we can directly use the command below to support 
> this mode.
> modprobe vfio-pci enable_sriov=1 disable_idle_d3=1
> dpdk-devbind.py -b vfio-pci xx:yy.z
> echo 2 > /sys/bus/pci/devices/\:xx\:yy.z/sriov_numvfs
> And we get this information first time in this link: 
> https://lwn.net/Articles/813045/
> 

Ability to create VF via vfio-pci is one thing, as you said that support
is added unrelated to the driver.

Other thing is PF driver's capability to manage VFs, since not all
operations are supported by VF driver, sometimes VF driver sends a
request to PF driver for this, so PF should have capability to receive
and handle these requests. Is your driver working in similar way?

Following documentation is from previous version (that this set removes):
"
...
Future DPDK versions will have a PMD able to work with the PF and VFs at
the same time and with the PF implementing VF management along with
other PF-only functionalities/offloads.
"

I was expecting some code changes are required for above mentioned "PF
implementing VF management", are they done already? If so while removing
that part of the documentation it can be good to document commit IDs of
those changes.


And more directly, right now, do you support to run dpdk application on
top of both PF and VF at the *same* time?


>>
>>> - Previously the PF had to be bound to the kernel driver to create VFs,
>>>   then VFs were created and bound to 'vfio-pci'. Currently it is
>>>   possible to bind the PF to 'vfio-pci' and create VFs bound to
>>>   'vfio-pci'.
>>> - The name of the Linux kernel driver changed for VFs. Previously the
>>>   'nfp_netvf' module was used, but now both PFs and VFs use the 'nfp'
>>>   module.
>>>
>>> Signed-off-by: Walter Heymans 
>>> Reviewed-by: Chaoyong He 
>>> Reviewed-by: Niklas Söderlund 
>>
>> <...>
>>
>>> @@ -209,8 +207,8 @@ vNIC service will keep polling packets from the
>>> firmware, and multiplex them  to the corresponding representor port.
>>>
>>>  In the Tx direction, the representor port will prepend the output
>>> port -information into metadata for each packet, and then send it to
>>> firmware through -PF vNIC.
>>> +information into metadata for each packet, and then send it to the
>>> +firmware through the PF vNIC.
>>>
>>
>> Above change belongs to first patch.
> 
> Thanks, we will move it in the next version.

[PATCH v1] app/testpmd: fix flex item compilation error

[Rongwei Liu]

When configuring meson with option "--optimization=1", gcc
complains "maybe-uninitialized" warning and it was treated as
error since Werror is enabled.

Assign fp to NULL at declaration can avoid this.

Fixes: c8e25fbf1440 ("ethdev: add flow flex modify")
Cc: sta...@dpdk.org

Signed-off-by: Rongwei Liu 
---
 app/test-pmd/cmdline_flow.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index f1991a5a9a..9309607f11 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -8992,7 +8992,7 @@ parse_vc_modify_field_level(struct context *ctx, const 
struct token *token,
 unsigned int size)
 {
struct rte_flow_action_modify_field *action;
-   struct flex_item *fp;
+   struct flex_item *fp = NULL;
uint32_t val;
struct buffer *out = buf;
char *end;
-- 
2.27.0

[PATCH v2] app/testpmd: fix flex item compilation error

[Rongwei Liu]

When configuring meson with option "--optimization=1", gcc
complains "maybe-uninitialized" warning and it was treated as
error since Werror is enabled.

Assign fp to NULL at declaration can avoid this.

Bugzilla ID: 1163
Fixes: c8e25fbf1440 ("ethdev: add flow flex modify")
Cc: sta...@dpdk.org

Reported-by: gaodaxue 
Signed-off-by: Rongwei Liu 
---
 app/test-pmd/cmdline_flow.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index f1991a5a9a..9309607f11 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -8992,7 +8992,7 @@ parse_vc_modify_field_level(struct context *ctx, const 
struct token *token,
 unsigned int size)
 {
struct rte_flow_action_modify_field *action;
-   struct flex_item *fp;
+   struct flex_item *fp = NULL;
uint32_t val;
struct buffer *out = buf;
char *end;
-- 
2.27.0

Re: [PATCH v3 1/2] net/gve: fix Rx no mbufs stats counter update

[Levend Sayar]

Not only this if, there can be many places to add such branch prediction helpers
On the gve pmd code. 

I preferred to patch only the bug here and not used unlikely to minimize noise.

Imho, adding likely/unlikely to all gve pmd code can be topic of another patch 
maybe.

Levend

> On 21 Feb 2023, at 01:57, Ferruh Yigit  wrote:
> 
> On 2/20/2023 9:11 PM, Levend Sayar wrote:
>> rx no_mbufs stats counter update is added for another error case.
>> 
>> Fixes: 4f6b1dd8240c ("net/gve: support basic statistics")
>> Cc: junfeng@intel.com
>> 
>> Signed-off-by: Levend Sayar 
>> ---
>> drivers/net/gve/gve_rx.c | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/net/gve/gve_rx.c b/drivers/net/gve/gve_rx.c
>> index 66fbcf3930..d346efa57c 100644
>> --- a/drivers/net/gve/gve_rx.c
>> +++ b/drivers/net/gve/gve_rx.c
>> @@ -61,7 +61,10 @@ gve_rx_refill(struct gve_rx_queue *rxq)
>>  break;
>>  rxq->sw_ring[idx + i] = nmb;
>>  }
>> -nb_alloc = i;
>> +if (i != nb_alloc) {
>> +rxq->no_mbufs += nb_alloc - i;
>> +nb_alloc = i;
>> +}
>>  }
>>  rxq->nb_avail -= nb_alloc;
>>  next_avail += nb_alloc;
> 
> Looks good to me,
> there was a comment from Stephen to add 'unlikely()', is that issue
> resolved?

RE: [PATCH v2 2/3] doc: update outdated information for the nfp PMD

[Chaoyong He]

> On 2/21/2023 9:04 AM, Chaoyong He wrote:
> >> On 2/20/2023 8:41 AM, Chaoyong He wrote:
> >>> From: Walter Heymans 
> >>>
> >>> Update nfp documentation with new information and remove outdated
> >>> information. The most significant changes that are updated include:
> >>> - Previously the NFP PMD did not support functionality to control VFs,
> >>>   it now does.
> >>
> >> What I understand is DPDK supports VF but if PF is bound to Linux driver.
> >>
> >> Previously support matrix was as following:
> >>
> >> PFVF  is supported
> >>   -  --
> >>   Linux  DPDK Yes
> >>   DPDK-   Yes
> >>   DPDK   DPDK NO
> >>   DPDK   Linux?No (not recommended)
> >>
> >>
> >> Is PF:DPDK, VF:DPDK supported now?
> >> This requires DPDK PF driver updated to manage VFs, if so can you
> >> please list commits that adds this support in this commit log?
> >
> > Yes, we support this mode now.
> > But actually, our PMD didn't do anything to support it.
> > After the VFIO module in kernel has support vf (not sure about the exact
> kernel version import this), we can directly use the command below to
> support this mode.
> > modprobe vfio-pci enable_sriov=1 disable_idle_d3=1 dpdk-devbind.py -b
> > vfio-pci xx:yy.z echo 2 >
> > /sys/bus/pci/devices/\:xx\:yy.z/sriov_numvfs
> > And we get this information first time in this link:
> > https://lwn.net/Articles/813045/
> >
> 
> Ability to create VF via vfio-pci is one thing, as you said that support is 
> added
> unrelated to the driver.
> 
> Other thing is PF driver's capability to manage VFs, since not all operations
> are supported by VF driver, sometimes VF driver sends a request to PF driver
> for this, so PF should have capability to receive and handle these requests. 
> Is
> your driver working in similar way?
 
Our PMD doesn't has a similar way like this.
The VF either share the same operation function with PF or has a special 
operation function, or just don't implement the operation at all.
Maybe in the future we have to add something like this, but for now we don't 
have that yet.

> Following documentation is from previous version (that this set removes):
> "
> ...
> Future DPDK versions will have a PMD able to work with the PF and VFs at
> the same time and with the PF implementing VF management along with
> other PF-only functionalities/offloads.
> "
> 
> I was expecting some code changes are required for above mentioned "PF
> implementing VF management", are they done already? If so while removing
> that part of the documentation it can be good to document commit IDs of
> those changes.
How about just drop the modification of this parameter?
Is that more acceptable?  

> 
> And more directly, right now, do you support to run dpdk application on top
> of both PF and VF at the *same* time?

Yes, we support that, for example, we can run the testpmd app on top of both PF 
and VF at the same time.

> 
> >>
> >>> - Previously the PF had to be bound to the kernel driver to create VFs,
> >>>   then VFs were created and bound to 'vfio-pci'. Currently it is
> >>>   possible to bind the PF to 'vfio-pci' and create VFs bound to
> >>>   'vfio-pci'.
> >>> - The name of the Linux kernel driver changed for VFs. Previously the
> >>>   'nfp_netvf' module was used, but now both PFs and VFs use the 'nfp'
> >>>   module.
> >>>
> >>> Signed-off-by: Walter Heymans 
> >>> Reviewed-by: Chaoyong He 
> >>> Reviewed-by: Niklas Söderlund 
> >>
> >> <...>
> >>
> >>> @@ -209,8 +207,8 @@ vNIC service will keep polling packets from the
> >>> firmware, and multiplex them  to the corresponding representor port.
> >>>
> >>>  In the Tx direction, the representor port will prepend the output
> >>> port -information into metadata for each packet, and then send it to
> >>> firmware through -PF vNIC.
> >>> +information into metadata for each packet, and then send it to the
> >>> +firmware through the PF vNIC.
> >>>
> >>
> >> Above change belongs to first patch.
> >
> > Thanks, we will move it in the next version.

Re: [dpdk-dev] [RFC] testpmd: support user-id attribute

[Thomas Monjalon]

This feature assigns custom IDs to flow rules
so a complete sequence of commands can prepared in a script.
As a test application, I think it is really valuable to be able
to script a sequence.

Any other opinions?
If you want to see this feature please speak to encourage its development.


30/01/2023 11:03, Asaf Penso:
> Hello Aman,
> Can you clarify your intention? Like Eli mentioned, the group_id is less 
> relevant for that purpose. Even with the same group_id we wish to have 
> several different flows with different user-id.
> 
> All,
> Do you have any other comments?
> We would like to proceed with the process of sending v1, review, and 
> integrate.
> 
> Regards,
> Asaf Penso
> 
> >-Original Message-
> >From: Eli Britstein 
> >Sent: Sunday, 7 August 2022 10:01
> >To: Singh, Aman Deep ; dev@dpdk.org
> >Cc: Slava Ovsiienko ; Ori Kam ;
> >Asaf Penso ; Matan Azrad ; Gaetan
> >Rivet ; Nir Anteby ; Yuying
> >Zhang ; Ferruh Yigit ;
> >Andrew Rybchenko ; NBU-Contact-
> >Thomas Monjalon (EXTERNAL) 
> >Subject: RE: [dpdk-dev] [RFC] testpmd: support user-id attribute
> >
> >Hi Aman,
> >
> >No, the group attribute has its own meaning, so it cannot be used for this
> >purpose, unless I misunderstood your meaning.
> >
> >Thanks,
> >Eli
> >
> >>-Original Message-
> >>From: Singh, Aman Deep 
> >>Sent: Thursday, July 28, 2022 5:07 PM
> >>To: dev@dpdk.org; Eli Britstein 
> >>Cc: Slava Ovsiienko ; Ori Kam
> >>; Asaf Penso ; Matan Azrad
> >>; Gaetan Rivet ; Nir Anteby
> >>; Yuying Zhang ; Ferruh
> >>Yigit ; Andrew Rybchenko
> >>; NBU-Contact- Thomas Monjalon
> >>(EXTERNAL) 
> >>Subject: Re: [dpdk-dev] [RFC] testpmd: support user-id attribute
> >>
> >>External email: Use caution opening links or attachments
> >>
> >>
> >>Hi Eli,
> >>
> >>In RTE flow there is support for group_id attribute(u32).
> >>Similar to the example you gave-
> >>
> >>testpmd> flow create 0 group 0x1234 ingress pattern eth / end actions
> >>count / drop / end
> >>
> >>Please check if it fits the requirement.
> >>
> >>Regards
> >>Aman
> >>
> >>
> >>On 7/20/2022 2:14 AM, Thomas Monjalon wrote:
> >>> +Cc ethdev and testpmd maintainers
> >>>
> >>> Any feedback about this need and solution?
> >>>
> >>>
> >>> 04/07/2022 10:24, Eli Britstein:
>  Upon creation of a flow, testpmd assigns it a flow ID. Later, the
>  flow ID is used for flow operations (query, destroy, dump).
> 
>  The testpmd application allows to manage flow rules with its IDs.
>  The flow ID is known only when the flow is created.
>  In order to prepare a complete sequence of testpmd commands to
>  copy/paste, the flow IDs must be predictable.
> 
>  The idea brought here is to allow providing some user-defined ID,
>  chosen in advance of the effective flow creation.
> 
> 
>  Example:
> 
>  testpmd> flow create 0 ingress user_id 0x1234 pattern eth / end
>  testpmd> actions
>  count / drop / end
>  Flow rule #0 created, user-id 0x1234
> 
>  testpmd> flow destroy 0 user_id rule 0x1234
>  Flow rule #0 destroyed, user-id 0x1234 Here, "user_id" is a flag
>  that signifies the "rule" ID is the user-id.
> 
>  The motivation is from OVS. OVS dumps its "rte_flow_create" calls to
>  the log in testpmd commands syntax. As the flow ID testpmd would
>  assign is unkwon, it cannot log valid "flow destroy" commands.
> 
>  With the enhancement described above, valid testpmd commands can be
>  created in a log to copy/paste to testpmd.
>  The application's flows sequence can then be played back in testpmd,
>  to enable enhanced dpdk debug capabilities of the applications's
>  flows in a controlled environment of testpmd rather than a dynamic,
>  more difficult to debug environment of the application.

Re: [PATCH v1] config: make max memzones definition configurable

[Thomas Monjalon]

13/02/2023 18:04, Ophir Munk:
> Since the new rte API was "discussed in recent years" and it is also 
> dependent on different driver vendors acceptance - I suggest that the 
> compilation option will be applied now.

I think there is a misunderstanding here.

> The new rte API effort will start in parallel. Once accepted - it will 
> replace the compilation option.

The effort is just adding a single simple function.
I can work on it.


> From: Bruce Richardson 
> > On Mon, Feb 13, 2023 at 02:55:41PM +0100, Thomas Monjalon wrote:
> > > 13/02/2023 12:05, Bruce Richardson:
> > > > On Sun, Feb 12, 2023 at 10:53:19AM +0200, Ophir Munk wrote:
> > > > > In current DPDK the RTE_MAX_MEMZONE definition is unconditionally
> > > > > hard coded as 2560.  For applications requiring different values
> > > > > of this parameter – it is more convenient to set its value as part
> > > > > of the meson command line rather than changing the dpdk source
> > > > > code per application.  An example would be of an application that
> > > > > uses the DPDK mempool library which is based on DPDK memzone
> > > > > library.  The application may need to create a number of steering
> > > > > tables, each of which will require its own mempool allocation.
> > > > > This commit adds a meson optional parameter named max_memzones.
> > If
> > > > > not specified - it is set by default to 2560. The hard coded
> > > > > definition of RTE_MAX_MEMZONE is removed. During meson build time
> > > > > the RTE_MAX_MEMZONE can be optionally defined as the value of
> > max_memzones parameter.
> > > > >
> > > > > Signed-off-by: Ophir Munk  --- RFC:
> > > > >
> > https://patchwork.dpdk.org/project/dpdk/patch/20230130092302.37614
> > > > > 5-1-ophi...@nvidia.com/
> > > > >
> > > > >  config/meson.build  | 1 + config/rte_config.h | 1 -
> > > > >  meson_options.txt   | 2 ++ 3 files changed, 3 insertions(+), 1
> > > > >  deletion(-)
> > > > >
> > > > Acked-by: Bruce Richardson 
> > >
> > > Are we going to move all compilation-defined settings to
> > > meson_options.txt?  The direction discussed in recent years was to
> > > configure things at runtime, and stop adding compilation-time settings.
> > >
> > > In this case, it is quite easy to add a new function void
> > > rte_memzone_set_max(int max) to be called before rte_eal_init().  If
> > > not called, the historical default is used.
> > >
> > Good point, I admit I had forgotten that.
> > 
> > Looking at the use of RTE_MAX_MEMZONE, it is used as an array dimension
> > in a number of places, but, from what I see on cursory examination, it 
> > should
> > be replacable with a runtime value without significant pain in most cases.
> > The one that probably needs more attention is the fact that the "net/qede"
> > driver maintains an array of memzones in it's base-code layer. Therefore, we
> > probably need input from that driver maintainer to know the impact there
> > and why that array is needed in a net driver. [Adding the two maintainers on
> > CC]
> > 
> > /Bruce
> 

Re: [PATCH v3 1/2] net/gve: fix Rx no mbufs stats counter update

[Ferruh Yigit]

On 2/21/2023 10:07 AM, Levend Sayar wrote:
> Not only this if, there can be many places to add such branch prediction 
> helpers
> On the gve pmd code. 
> 
> I preferred to patch only the bug here and not used unlikely to minimize 
> noise.
> 
> Imho, adding likely/unlikely to all gve pmd code can be topic of another 
> patch maybe.
> 

ack, sounds reasonable to me

> Levend
> 
>> On 21 Feb 2023, at 01:57, Ferruh Yigit  wrote:
>>
>> On 2/20/2023 9:11 PM, Levend Sayar wrote:
>>> rx no_mbufs stats counter update is added for another error case.
>>>
>>> Fixes: 4f6b1dd8240c ("net/gve: support basic statistics")
>>> Cc: junfeng@intel.com
>>>
>>> Signed-off-by: Levend Sayar 
>>> ---
>>> drivers/net/gve/gve_rx.c | 5 -
>>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/gve/gve_rx.c b/drivers/net/gve/gve_rx.c
>>> index 66fbcf3930..d346efa57c 100644
>>> --- a/drivers/net/gve/gve_rx.c
>>> +++ b/drivers/net/gve/gve_rx.c
>>> @@ -61,7 +61,10 @@ gve_rx_refill(struct gve_rx_queue *rxq)
>>> break;
>>> rxq->sw_ring[idx + i] = nmb;
>>> }
>>> -   nb_alloc = i;
>>> +   if (i != nb_alloc) {
>>> +   rxq->no_mbufs += nb_alloc - i;
>>> +   nb_alloc = i;
>>> +   }
>>> }
>>> rxq->nb_avail -= nb_alloc;
>>> next_avail += nb_alloc;
>>
>> Looks good to me,
>> there was a comment from Stephen to add 'unlikely()', is that issue
>> resolved?
> 

[PATCH v2 0/6] fix the set flow actions

[Chaoyong He]

The former logic of set flow actions don't consider the mask filed
of control message passed to the firmware, and this caused the
firmware skip the set action logic wrongly.
This patch series aims to fix this problem.

--
v2:
* fix the compile warning.
--

Chaoyong He (6):
  net/nfp: fix the set MAC flow action
  net/nfp: fix the set IPv4 flow action
  net/nfp: fix the set IPv6 flow action
  net/nfp: fix the set TP flow action
  net/nfp: fix the set TTL flow action
  net/nfp: fix the set IPv4/v6 DSCP flow action

 drivers/net/nfp/nfp_flow.c | 29 +++--
 1 file changed, 23 insertions(+), 6 deletions(-)

-- 
2.29.3

[PATCH v2 1/6] net/nfp: fix the set MAC flow action

[Chaoyong He]

The former logic of set MAC source/destination address flow action don't
consider the mask filed of control message passed to the firmware.
This caused the firmware skip the set action logic, and the offloaded
packets don't have the right MAC address as expected.

Fixes: 4f6983154570 ("net/nfp: support MAC source flow action")
Fixes: eecc7ca3088a ("net/nfp: support MAC destination flow action")
Cc: sta...@dpdk.org

Signed-off-by: Chaoyong He 
Reviewed-by: Niklas Söderlund 
---
 drivers/net/nfp/nfp_flow.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/nfp/nfp_flow.c b/drivers/net/nfp/nfp_flow.c
index 0c38925701..f373171d7e 100644
--- a/drivers/net/nfp/nfp_flow.c
+++ b/drivers/net/nfp/nfp_flow.c
@@ -2066,6 +2066,7 @@ nfp_flow_action_set_mac(char *act_data,
bool mac_src_flag,
bool mac_set_flag)
 {
+   uint8_t i;
size_t act_size;
struct nfp_fl_act_set_eth *set_eth;
const struct rte_flow_action_set_mac *set_mac;
@@ -2084,9 +2085,13 @@ nfp_flow_action_set_mac(char *act_data,
if (mac_src_flag) {
rte_memcpy(&set_eth->eth_addr[RTE_ETHER_ADDR_LEN],
set_mac->mac_addr, RTE_ETHER_ADDR_LEN);
+   for (i = 0; i < RTE_ETHER_ADDR_LEN; i++)
+   set_eth->eth_addr_mask[RTE_ETHER_ADDR_LEN + i] = 0xff;
} else {
rte_memcpy(&set_eth->eth_addr[0],
set_mac->mac_addr, RTE_ETHER_ADDR_LEN);
+   for (i = 0; i < RTE_ETHER_ADDR_LEN; i++)
+   set_eth->eth_addr_mask[i] = 0xff;
}
 }
 
-- 
2.29.3

[PATCH v2 2/6] net/nfp: fix the set IPv4 flow action

[Chaoyong He]

The former logic of set IPv4 source/destination address flow action don't
consider the mask filed of control message passed to the firmware.
This caused the firmware skip the set action logic, and the offloaded
packets don't have the right IPv4 address as expected.

Fixes: ab80975b0a14 ("net/nfp: support IPv4 source flow action")
Fixes: f85c1e05bff3 ("net/nfp: support IPv4 destination flow action")
Cc: sta...@dpdk.org

Signed-off-by: Chaoyong He 
Reviewed-by: Niklas Söderlund 
---
 drivers/net/nfp/nfp_flow.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/nfp/nfp_flow.c b/drivers/net/nfp/nfp_flow.c
index f373171d7e..39493ce98d 100644
--- a/drivers/net/nfp/nfp_flow.c
+++ b/drivers/net/nfp/nfp_flow.c
@@ -2132,10 +2132,13 @@ nfp_flow_action_set_ip(char *act_data,
set_ip->reserved = 0;
 
set_ipv4 = (const struct rte_flow_action_set_ipv4 *)action->conf;
-   if (ip_src_flag)
+   if (ip_src_flag) {
set_ip->ipv4_src = set_ipv4->ipv4_addr;
-   else
+   set_ip->ipv4_src_mask = RTE_BE32(0x);
+   } else {
set_ip->ipv4_dst = set_ipv4->ipv4_addr;
+   set_ip->ipv4_dst_mask = RTE_BE32(0x);
+   }
 }
 
 static void
-- 
2.29.3

[PATCH v2 3/6] net/nfp: fix the set IPv6 flow action

[Chaoyong He]

The former logic of set IPv6 source/destination address flow action don't
consider the mask filed of control message passed to the firmware.
This caused the firmware skip the set action logic, and the offloaded
packets don't have the right IPv6 address as expected.

Fixes: 596ae2217214 ("net/nfp: support IPv6 source flow action")
Fixes: 51384f79b264 ("net/nfp: support IPv6 destination flow action")
Cc: sta...@dpdk.org

Signed-off-by: Chaoyong He 
Reviewed-by: Niklas Söderlund 
---
 drivers/net/nfp/nfp_flow.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/nfp/nfp_flow.c b/drivers/net/nfp/nfp_flow.c
index 39493ce98d..d1fe744758 100644
--- a/drivers/net/nfp/nfp_flow.c
+++ b/drivers/net/nfp/nfp_flow.c
@@ -2163,8 +2163,10 @@ nfp_flow_action_set_ipv6(char *act_data,
set_ip->head.len_lw = act_size >> NFP_FL_LW_SIZ;
set_ip->reserved = 0;
 
-   for (i = 0; i < 4; i++)
-   set_ip->ipv6[i].exact = set_ipv6->ipv6_addr[i];
+   for (i = 0; i < 4; i++) {
+   set_ip->ipv6[i].exact = set_ipv6->ipv6_addr[i * 4];
+   set_ip->ipv6[i].mask = RTE_BE32(0x);
+   }
 }
 
 static void
-- 
2.29.3

[PATCH v2 4/6] net/nfp: fix the set TP flow action

[Chaoyong He]

The former logic of set TP source/destination flow action don't
consider the mask filed of control message passed to the firmware.
This caused the firmware skip the set action logic, and the offloaded
packets don't have the right TP as expected.

Fixes: fc185097bbe6 ("net/nfp: support TP source flow action")
Fixes: 87986df09d75 ("net/nfp: support TP destination flow action")
Cc: sta...@dpdk.org

Signed-off-by: Chaoyong He 
Reviewed-by: Niklas Söderlund 
---
 drivers/net/nfp/nfp_flow.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/nfp/nfp_flow.c b/drivers/net/nfp/nfp_flow.c
index d1fe744758..5be4c4f18a 100644
--- a/drivers/net/nfp/nfp_flow.c
+++ b/drivers/net/nfp/nfp_flow.c
@@ -2190,10 +2190,13 @@ nfp_flow_action_set_tp(char *act_data,
set_tp->reserved = 0;
 
set_tp_conf = (const struct rte_flow_action_set_tp *)action->conf;
-   if (tp_src_flag)
+   if (tp_src_flag) {
set_tp->src_port = set_tp_conf->port;
-   else
+   set_tp->src_port_mask = RTE_BE16(0x);
+   } else {
set_tp->dst_port = set_tp_conf->port;
+   set_tp->dst_port_mask = RTE_BE16(0x);
+   }
 }
 
 static int
-- 
2.29.3

[PATCH v2 6/6] net/nfp: fix the set IPv4/v6 DSCP flow action

[Chaoyong He]

The former logic of set IPv4/v6 DSCP flow action don't consider the
mask filed of control message passed to the firmware.
This caused the firmware skip the set action logic, and the offloaded
packets don't have the right IPv4/v6 DSCP as expected.

Fixes: 9c665d70f7a7 ("net/nfp: support IPv4 DSCP flow action")
Fixes: 3202b003bec1 ("net/nfp: support IPv6 DSCP flow action")
Cc: sta...@dpdk.org

Signed-off-by: Chaoyong He 
Reviewed-by: Niklas Söderlund 
---
 drivers/net/nfp/nfp_flow.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/nfp/nfp_flow.c b/drivers/net/nfp/nfp_flow.c
index 77f249e2b9..53029d00c9 100644
--- a/drivers/net/nfp/nfp_flow.c
+++ b/drivers/net/nfp/nfp_flow.c
@@ -2300,6 +2300,7 @@ nfp_flow_action_set_tos(char *act_data,
 
tos_conf = (const struct rte_flow_action_set_dscp *)action->conf;
ttl_tos->ipv4_tos = tos_conf->dscp;
+   ttl_tos->ipv4_tos_mask = 0xff;
ttl_tos->reserved = 0;
 }
 
@@ -2323,6 +2324,7 @@ nfp_flow_action_set_tc(char *act_data,
 
tos_conf = (const struct rte_flow_action_set_dscp *)action->conf;
tc_hl->ipv6_tc = tos_conf->dscp;
+   tc_hl->ipv6_tc_mask = 0xff;
tc_hl->reserved = 0;
 }
 
-- 
2.29.3

[PATCH v2 5/6] net/nfp: fix the set TTL flow action

[Chaoyong He]

The former logic of set TTL flow action don't consider the mask
filed of control message passed to the firmware.
This caused the firmware skip the set action logic, and the offloaded
packets don't have the right TTL as expected.

Fixes: ac12e126c482 ("net/nfp: support TTL flow action")
Cc: sta...@dpdk.org

Signed-off-by: Chaoyong He 
Reviewed-by: Niklas Söderlund 
---
 drivers/net/nfp/nfp_flow.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/nfp/nfp_flow.c b/drivers/net/nfp/nfp_flow.c
index 5be4c4f18a..77f249e2b9 100644
--- a/drivers/net/nfp/nfp_flow.c
+++ b/drivers/net/nfp/nfp_flow.c
@@ -2252,6 +2252,7 @@ nfp_flow_action_set_ttl(char *act_data,
 
ttl_conf = (const struct rte_flow_action_set_ttl *)action->conf;
ttl_tos->ipv4_ttl = ttl_conf->ttl_value;
+   ttl_tos->ipv4_ttl_mask = 0xff;
ttl_tos->reserved = 0;
 }
 
@@ -2275,6 +2276,7 @@ nfp_flow_action_set_hl(char *act_data,
 
ttl_conf = (const struct rte_flow_action_set_ttl *)action->conf;
tc_hl->ipv6_hop_limit = ttl_conf->ttl_value;
+   tc_hl->ipv6_hop_limit_mask = 0xff;
tc_hl->reserved = 0;
 }
 
-- 
2.29.3

Re: [PATCH v6 4/5] vhost: use logtype instead of RTE_LOGTYPE_USER1

[David Marchand]

On Mon, Feb 20, 2023 at 7:50 PM Stephen Hemminger
 wrote:
>
> Fix instances of USER1 logtype in fdset and crypto
> sections.
>
> Acked-by: Chenbo Xia 
> Reviewed-by: Maxime Coquelin 
> Signed-off-by: Stephen Hemminger 
> ---
>  lib/vhost/fd_man.c   | 4 ++--
>  lib/vhost/vhost_crypto.c | 4 
>  2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/lib/vhost/fd_man.c b/lib/vhost/fd_man.c
> index 1876fada3354..46037d02784e 100644
> --- a/lib/vhost/fd_man.c
> +++ b/lib/vhost/fd_man.c
> @@ -10,8 +10,8 @@
>
>  #include "fd_man.h"
>
> -
> -#define RTE_LOGTYPE_VHOST_FDMAN RTE_LOGTYPE_USER1
> +RTE_LOG_REGISTER_SUFFIX(vhost_fdset_logtype, fdset, INFO);
> +#define RTE_LOGTYPE_VHOST_FDMAN vhost_fdset_logtype

Oh, I did not follow the previous revisions, but now that I see this, nice hack.

>
>  #define FDPOLLERR (POLLERR | POLLHUP | POLLNVAL)
>
> diff --git a/lib/vhost/vhost_crypto.c b/lib/vhost/vhost_crypto.c
> index f02bf865c349..ad420ea012d0 100644
> --- a/lib/vhost/vhost_crypto.c
> +++ b/lib/vhost/vhost_crypto.c
> @@ -4,6 +4,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>
> @@ -16,6 +17,9 @@
>  #define IV_OFFSET  (sizeof(struct rte_crypto_op) + \
> sizeof(struct rte_crypto_sym_op))
>
> +RTE_LOG_REGISTER_SUFFIX(vhost_crypto_logtype, crypto, INFO);
> +#define RTE_LOGTYPE_VHOST_CRYPTO   vhost_crypto_logtype
> +
>  #ifdef RTE_LIBRTE_VHOST_DEBUG
>  #define VC_LOG_ERR(fmt, args...)   \
> RTE_LOG(ERR, USER1, "[%s] %s() line %u: " fmt "\n", \

However, there is something missing here.

Existing code was directly using RTE_LOGTYPE_USER1.
We still need to update:

diff --git a/lib/vhost/vhost_crypto.c b/lib/vhost/vhost_crypto.c
index ad420ea012..d2b4af1d1c 100644
--- a/lib/vhost/vhost_crypto.c
+++ b/lib/vhost/vhost_crypto.c
@@ -22,20 +22,20 @@ RTE_LOG_REGISTER_SUFFIX(vhost_crypto_logtype, crypto, INFO);

 #ifdef RTE_LIBRTE_VHOST_DEBUG
 #define VC_LOG_ERR(fmt, args...)   \
-   RTE_LOG(ERR, USER1, "[%s] %s() line %u: " fmt "\n", \
+   RTE_LOG(ERR, VHOST_CRYPTO, "[%s] %s() line %u: " fmt "\n",  \
"Vhost-Crypto", __func__, __LINE__, ## args)
 #define VC_LOG_INFO(fmt, args...)  \
-   RTE_LOG(INFO, USER1, "[%s] %s() line %u: " fmt "\n",\
+   RTE_LOG(INFO, VHOST_CRYPTO, "[%s] %s() line %u: " fmt "\n", \
"Vhost-Crypto", __func__, __LINE__, ## args)

 #define VC_LOG_DBG(fmt, args...)   \
-   RTE_LOG(DEBUG, USER1, "[%s] %s() line %u: " fmt "\n",   \
+   RTE_LOG(DEBUG, VHOST_CRYPTO, "[%s] %s() line %u: " fmt "\n",\
"Vhost-Crypto", __func__, __LINE__, ## args)
 #else
 #define VC_LOG_ERR(fmt, args...)   \
-   RTE_LOG(ERR, USER1, "[VHOST-Crypto]: " fmt "\n", ## args)
+   RTE_LOG(ERR, VHOST_CRYPTO, "[VHOST-Crypto]: " fmt "\n", ## args)
 #define VC_LOG_INFO(fmt, args...)  \
-   RTE_LOG(INFO, USER1, "[VHOST-Crypto]: " fmt "\n", ## args)
+   RTE_LOG(INFO, VHOST_CRYPTO, "[VHOST-Crypto]: " fmt "\n", ## args)
 #define VC_LOG_DBG(fmt, args...)
 #endif


-- 
David Marchand

Re: [PATCH v6 1/5] ip_frag: use a dynamic logtype

[David Marchand]

On Mon, Feb 20, 2023 at 7:50 PM Stephen Hemminger
 wrote:
>
> DPDK libraries should not be reusing RTE_LOGTYPE_USER1 in
> lieu of doing proper logtype registration.
>
> Acked-by: Konstantin Ananyev 
> Fixes: 416707812c03 ("ip_frag: refactor reassembly code into a proper 
> library")
> Signed-off-by: Stephen Hemminger 
> ---
>  lib/ip_frag/ip_frag_common.h | 5 -
>  lib/ip_frag/rte_ip_frag_common.c | 2 ++
>  2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/lib/ip_frag/ip_frag_common.h b/lib/ip_frag/ip_frag_common.h
> index 9c0dbdeb6eb9..95f1689d476d 100644
> --- a/lib/ip_frag/ip_frag_common.h
> +++ b/lib/ip_frag/ip_frag_common.h
> @@ -8,9 +8,12 @@
>  #include "rte_ip_frag.h"
>  #include "ip_reassembly.h"
>
> +extern int ipfrag_logtype;
> +#define RTE_LOGTYPE_IPFRAG ipfrag_logtype
> +
>  /* logging macros. */
>  #ifdef RTE_LIBRTE_IP_FRAG_DEBUG
> -#defineIP_FRAG_LOG(lvl, fmt, args...)  RTE_LOG(lvl, USER1, fmt, 
> ##args)
> +#defineIP_FRAG_LOG(lvl, fmt, args...)  RTE_LOG(lvl, IPFRAG, fmt, 
> ##args)
>  #else
>  #defineIP_FRAG_LOG(lvl, fmt, args...)  do {} while(0)
>  #endif /* IP_FRAG_DEBUG */
> diff --git a/lib/ip_frag/rte_ip_frag_common.c 
> b/lib/ip_frag/rte_ip_frag_common.c
> index c1de2e81b6d0..e4af8d23ad10 100644
> --- a/lib/ip_frag/rte_ip_frag_common.c
> +++ b/lib/ip_frag/rte_ip_frag_common.c
> @@ -7,6 +7,8 @@
>
>  #include 
>
> +RTE_LOG_REGISTER_DEFAULT(ipfrag_logtype, INFO);
> +
>  #include "ip_frag_common.h"
>
>  #defineIP_FRAG_HASH_FNUM   2

There are still some parts using USER1 in this library:

lib/ip_frag/rte_ip_frag_common.c:   RTE_LOG(ERR, USER1,
"%s: invalid input parameter\n", __func__);
lib/ip_frag/rte_ip_frag_common.c:   RTE_LOG(ERR, USER1,
lib/ip_frag/rte_ip_frag_common.c:   RTE_LOG(INFO, USER1, "%s:
allocated of %zu bytes at socket %d\n",

-- 
David Marchand

Re: [PATCH v2 2/3] doc: update outdated information for the nfp PMD

[Ferruh Yigit]

On 2/21/2023 10:11 AM, Chaoyong He wrote:
>> On 2/21/2023 9:04 AM, Chaoyong He wrote:
 On 2/20/2023 8:41 AM, Chaoyong He wrote:
> From: Walter Heymans 
>
> Update nfp documentation with new information and remove outdated
> information. The most significant changes that are updated include:
> - Previously the NFP PMD did not support functionality to control VFs,
>   it now does.

 What I understand is DPDK supports VF but if PF is bound to Linux driver.

 Previously support matrix was as following:

 PFVF  is supported
   -  --
   Linux  DPDK Yes
   DPDK-   Yes
   DPDK   DPDK NO
   DPDK   Linux?No (not recommended)


 Is PF:DPDK, VF:DPDK supported now?
 This requires DPDK PF driver updated to manage VFs, if so can you
 please list commits that adds this support in this commit log?
>>>
>>> Yes, we support this mode now.
>>> But actually, our PMD didn't do anything to support it.
>>> After the VFIO module in kernel has support vf (not sure about the exact
>> kernel version import this), we can directly use the command below to
>> support this mode.
>>> modprobe vfio-pci enable_sriov=1 disable_idle_d3=1 dpdk-devbind.py -b
>>> vfio-pci xx:yy.z echo 2 >
>>> /sys/bus/pci/devices/\:xx\:yy.z/sriov_numvfs
>>> And we get this information first time in this link:
>>> https://lwn.net/Articles/813045/
>>>
>>
>> Ability to create VF via vfio-pci is one thing, as you said that support is 
>> added
>> unrelated to the driver.
>>
>> Other thing is PF driver's capability to manage VFs, since not all operations
>> are supported by VF driver, sometimes VF driver sends a request to PF driver
>> for this, so PF should have capability to receive and handle these requests. 
>> Is
>> your driver working in similar way?
>  
> Our PMD doesn't has a similar way like this.
> The VF either share the same operation function with PF or has a special 
> operation function, or just don't implement the operation at all.
> Maybe in the future we have to add something like this, but for now we don't 
> have that yet.
> 

OK, thanks for clarification. I wasn't sure about it, no more objection
from me.

>> Following documentation is from previous version (that this set removes):
>> "
>> ...
>> Future DPDK versions will have a PMD able to work with the PF and VFs at
>> the same time and with the PF implementing VF management along with
>> other PF-only functionalities/offloads.
>> "
>>
>> I was expecting some code changes are required for above mentioned "PF
>> implementing VF management", are they done already? If so while removing
>> that part of the documentation it can be good to document commit IDs of
>> those changes.
> How about just drop the modification of this parameter?
> Is that more acceptable?  
> 
>>
>> And more directly, right now, do you support to run dpdk application on top
>> of both PF and VF at the *same* time?
> 
> Yes, we support that, for example, we can run the testpmd app on top of both 
> PF and VF at the same time.
> 

ack

>>

> - Previously the PF had to be bound to the kernel driver to create VFs,
>   then VFs were created and bound to 'vfio-pci'. Currently it is
>   possible to bind the PF to 'vfio-pci' and create VFs bound to
>   'vfio-pci'.
> - The name of the Linux kernel driver changed for VFs. Previously the
>   'nfp_netvf' module was used, but now both PFs and VFs use the 'nfp'
>   module.
>
> Signed-off-by: Walter Heymans 
> Reviewed-by: Chaoyong He 
> Reviewed-by: Niklas Söderlund 

 <...>

> @@ -209,8 +207,8 @@ vNIC service will keep polling packets from the
> firmware, and multiplex them  to the corresponding representor port.
>
>  In the Tx direction, the representor port will prepend the output
> port -information into metadata for each packet, and then send it to
> firmware through -PF vNIC.
> +information into metadata for each packet, and then send it to the
> +firmware through the PF vNIC.
>

 Above change belongs to first patch.
>>>
>>> Thanks, we will move it in the next version.
> 

I can proceed with set after this minor change, thanks.

Re: [PATCH v6 0/5] Replace use of RTE_LOGTYPE_USER1 in libraries

[David Marchand]

On Mon, Feb 20, 2023 at 7:50 PM Stephen Hemminger
 wrote:
>
> The DPDK libraries and drivers should not be using the USER1 logtype.
>
> v6 - fix checkpatch warnings
>
> Stephen Hemminger (5):
>   ip_frag: use a dynamic logtype
>   reorder: use a dynamic logtype
>   latencystats: use dynamic logtype
>   vhost: use logtype instead of RTE_LOGTYPE_USER1
>   ipsec: fix usage of RTE_LOGTYPE_USER1
>
>  drivers/crypto/ipsec_mb/ipsec_mb_ops.c | 3 ++-
>  lib/ip_frag/ip_frag_common.h   | 5 -
>  lib/ip_frag/rte_ip_frag_common.c   | 2 ++
>  lib/latencystats/rte_latencystats.c| 3 ++-
>  lib/reorder/rte_reorder.c  | 6 +++---
>  lib/vhost/fd_man.c | 4 ++--
>  lib/vhost/vhost_crypto.c   | 4 
>  7 files changed, 19 insertions(+), 8 deletions(-)

Could you update the power library too?

lib/power/guest_channel.c:#define RTE_LOGTYPE_GUEST_CHANNEL RTE_LOGTYPE_USER1

Thanks.

-- 
David Marchand

Re: [PATCH v3 2/2] net/gve: add Rx/Tx queue stats as extended stats

[Levend Sayar]

Thanks Ferruh for the review.
My comments are inlined.

> On 21 Feb 2023, at 01:57, Ferruh Yigit  wrote:
> 
> On 2/20/2023 9:11 PM, Levend Sayar wrote:
>> Google Virtual NIC rx/tx queue stats are added as extended stats.
>> 
>> Signed-off-by: Levend Sayar 
> 
> Thank you for the update, mainly looks good to me, there area a few
> minor questions/comments below.
> 
> <...>
>> +static const struct gve_xstats_name_offset tx_xstats_name_offset[] = {
>> +{ "packets", offsetof(struct gve_tx_stats, packets) },
>> +{ "bytes",   offsetof(struct gve_tx_stats, bytes) },
>> +{ "errors",  offsetof(struct gve_tx_stats, errors) },
>> +};
>> +
> 
> It is possible to create macros to get offsets to prevent any mistakes
> but not quite sure if it is needed with above limited number of items,
> so up to you, I mean something like:
> 
> #define RX_QUEUE_STATS_OFFSET(x) offsetof(struct gve_rx_stats, X)
> #define TX_QUEUE_STATS_OFFSET(x) offsetof(struct gve_tx_stats, X)
> 

LS: I take dpdk code as reference and mimicked the usage on rte_ethdev.c here. 
  Your proposal surely applicable.

>> +static const struct gve_xstats_name_offset rx_xstats_name_offset[] = {
>> +{ "packets", offsetof(struct gve_rx_stats, packets) },
>> +{ "bytes",   offsetof(struct gve_rx_stats, bytes) },
>> +{ "errors",  offsetof(struct gve_rx_stats, errors) },
>> +};
>> +
> 
> Is 'no_mbufs' omitted intentionally?
> 
> <...>

LS: no_mbufs are accumulated as rx_mbuf_allocation_errors on basic stats. But 
yes, it can be queue based also. 

>> 
>> +static int
>> +gve_xstats_count(struct rte_eth_dev *dev)
>> +{
>> +uint16_t i, count = 0;
>> +
>> +for (i = 0; i < dev->data->nb_tx_queues; i++) {
>> +if (dev->data->tx_queues[i])
> 
> Normally 'dev->data->tx_queues[i]' shouldn't be NULL, but I can see
> driver checks this in a few locations.
> 
> Is there a case that 'dev->data->tx_queues[i]' can be NULL where "0 <= i
> < dev->data->nb_tx_queues" ?

LS: You’re right. On my previous patches I erased that checks but that parts 
are reviewed as noise.
  So I am aligned with the rest of the code. In fact, there is no gap like 
that. In dev_start,
  Queues are created and whenever queue can not be created, it returns 
error at that point.
  So dev_start will return an error at the end. So if device successfully 
started, all rx/tx queues must be created
  Successfully. Therefore no need to check. 

> 
>> +count += RTE_DIM(tx_xstats_name_offset);
>> +}
>> +
>> +for (i = 0; i < dev->data->nb_rx_queues; i++) {
>> +if (dev->data->rx_queues[i])
>> +count += RTE_DIM(rx_xstats_name_offset);
>> +}
>> +
>> +return count;
>> +}
>> +
>> +static int
>> +gve_xstats_get(struct rte_eth_dev *dev,
>> +struct rte_eth_xstat *xstats,
>> +unsigned int size)
>> +{
>> +uint16_t i, count = 0;
>> +
>> +if (!xstats)
>> +return (size == 0) ? gve_xstats_count(dev) : -EINVAL;
> 
> Error case (xstats == NULL && size != 0) should be handled by ethdev, so
> driver can only check "xstats == NULL" case.
> 
> btw, although we have mixed usage and not very strict on it, coding
> convention requires testing against NULL [1] instead of '!'.
> 
> [1]
> https://doc.dpdk.org/guides/contributing/coding_style.html#null-pointers

LS: You’re right. rte_eth_xstats_get checks for (xstats == NULL && size != 0).
  Let me correct that part and use NULL.   

> 
>> +
>> +for (i = 0; i < dev->data->nb_tx_queues; i++) {
>> +const struct gve_tx_queue *txq = dev->data->tx_queues[i];
>> +if (!txq)
>> +continue;
>> +
> 
> similar to above comment, I expect 'txq' not to be NULL, isn't this
> correct for the driver?
> 
>> +if (count >= size)
>> +break;
>> +
> 
> Instead of above check in a loop, it is possible to check once at the
> beginning of the function like
> 
> count = gve_xstats_count(dev)
> if (size < count)
>   return count;
> 
> Because when there is not enough room in the xstats array, API doesn't
> expect existing elements of array to be correct, returning a value
> bigger than 'size' indicates error case and content of xstats is invalid
> anyway.

LS: Let’s say NIC has 20 xstats. Your application allocates xstats memory 
enough to hold 30
and request 30 xtstats. NIC will return 20 xstats. That’s ok. But if 
application allocates memory
For 10 xstats and request 10, it’s taken as error although Nic can fill first 
10 xstats.
So size must be higher or equal to number of xstats. Right?   

> 
>> +uint16_t j = 0;
>> +const char *stats = (const char *)&txq->stats;
> 
> Can you please move variable declarations at the beginning of the scope,
> for above variables it is just after for statement, according coding
> convention.

LS: Sure I can do. I supposed minimizing scope is better approach.
But not here I guess. What is t

[PATCH] net/af_xdp: fix integer handling issues

[Shibin Koikkara Reeny]

Fix integer handling issues (NEGATIVE_RETURNS) reported
in coverity scan. Add a check to sock variable if the
value is negative return -1.

Coverity issue: 383245
Fixes: 7fc6ae50369d ("net/af_xdp: support CNI Integration")

Signed-off-by: Shibin Koikkara Reeny 
---
 drivers/net/af_xdp/rte_eth_af_xdp.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c 
b/drivers/net/af_xdp/rte_eth_af_xdp.c
index 02c874d51e..2a20a6960c 100644
--- a/drivers/net/af_xdp/rte_eth_af_xdp.c
+++ b/drivers/net/af_xdp/rte_eth_af_xdp.c
@@ -1508,6 +1508,8 @@ get_cni_fd(char *if_name)
 
memset(&server, 0, sizeof(server));
sock = init_uds_sock(&server);
+   if (sock < 0)
+   return -1;
 
/* Initiates handshake to CNI send: /connect,hostname */
snprintf(request, sizeof(request), "%s,%s", UDS_CONNECT_MSG, hostname);
-- 
2.25.1

Re: Testpmd/l3fwd port shutdown failure on Arm Altra systems

[Juraj Linkeš]

Hi Qiming,

Just a friendly reminder, would you please take a look?

Thanks,
Juraj


On Tue, Feb 7, 2023 at 3:10 AM Xing, Beilei  wrote:
>
> Hi Qiming,
>
> Could you please help on this? Thanks.
>
> BR,
> Beilei
>
> > -Original Message-
> > From: Juraj Linkeš 
> > Sent: Monday, February 6, 2023 4:53 PM
> > To: Singh, Aman Deep ; Zhang, Yuying
> > ; Xing, Beilei 
> > Cc: dev@dpdk.org; Ruifeng Wang ; Zhang, Lijian
> > ; Honnappa Nagarahalli
> > 
> > Subject: Re: Testpmd/l3fwd port shutdown failure on Arm Altra systems
> >
> > Hello i40e and testpmd maintainers,
> >
> > A gentle reminder - would you please advise how to debug the issue described
> > below?
> >
> > Thanks,
> > Juraj
> >
> > On Fri, Jan 20, 2023 at 1:07 PM Juraj Linkeš 
> > wrote:
> > >
> > > Adding the logfile.
> > >
> > >
> > >
> > > One thing that's in the logs but didn't explicitly mention is the DPDK 
> > > version
> > we've tried this with:
> > >
> > > EAL: RTE Version: 'DPDK 22.07.0'
> > >
> > >
> > >
> > > We also tried earlier versions going back to 21.08, with no luck. I also 
> > > did a
> > quick check on 22.11, also with no luck.
> > >
> > >
> > >
> > > Juraj
> > >
> > >
> > >
> > > From: Juraj Linkeš
> > > Sent: Friday, January 20, 2023 12:56 PM
> > > To: 'aman.deep.si...@intel.com' ;
> > > 'yuying.zh...@intel.com' ; Xing, Beilei
> > > 
> > > Cc: dev@dpdk.org; Ruifeng Wang ; 'Lijian Zhang'
> > > ; 'Honnappa Nagarahalli'
> > > 
> > > Subject: Testpmd/l3fwd port shutdown failure on Arm Altra systems
> > >
> > >
> > >
> > > Hello i40e and testpmd maintainers,
> > >
> > >
> > >
> > > We're hitting an issue with DPDK testpmd on Ampere Altra servers in FD.io
> > lab.
> > >
> > >
> > >
> > > A bit of background: along with VPP performance tests (which uses DPDK),
> > we're running a small number of basic DPDK testpmd and l3fwd tests in FD.io
> > as well. This is to catch any performance differences due to VPP updating 
> > its
> > DPDK version.
> > >
> > >
> > >
> > > We're running both l3fwd tests and testpmd tests. The Altra servers are 
> > > two
> > socket and the topology is TG -> DUT1 -> DUT2 -> TG, traffic flows in both
> > directions, but nothing gets forwarded (with a slight caveat - put a pin in 
> > this).
> > There's nothing special in the tests, just forwarding traffic. The NIC we're
> > testing is xl710-QDA2.
> > >
> > >
> > >
> > > The same tests are passing on all other testbeds - we have various two 
> > > node
> > (1 DUT, 1 TG) and three node (2 DUT, 1 TG) Intel and Arm testbeds and with
> > various NICs (Intel 700 and 800 series and the Intel testbeds use some
> > Mellanox NICs as well). We don't have quite the same combination of another
> > three node topology with the same NIC though, so it looks like something 
> > with
> > testpmd/l3fwd and xl710-QDA2 on Altra servers.
> > >
> > >
> > >
> > > VPP performance tests are passing, but l3fwd and testpmd fail. This leads 
> > > us
> > to believe to it's a software issue, but there could something wrong with 
> > the
> > hardware. I'll talk about testpmd from now on, but as far we can tell, the
> > behavior is the same for testpmd and l3fwd.
> > >
> > >
> > >
> > > Getting back to the caveat mentioned earlier, there seems to be something
> > wrong with port shutdown. When running testpmd on a testbed that hasn't
> > been used for a while it seems that all ports are up right away (we don't 
> > see
> > any "Port 0|1: link state change event") and the setup works fine 
> > (forwarding
> > works). After restarting testpmd (restarting on one server is sufficient), 
> > the
> > ports between DUT1 and DUT2 (but not between DUTs and TG) go down and
> > are not usable in DPDK, VPP or in Linux (with i40e kernel driver) for a 
> > while
> > (measured in minutes, sometimes dozens of minutes; the duration is seemingly
> > random). The ports eventually recover and can be used again, but there's
> > nothing in syslog suggesting what happened.
> > >
> > >
> > >
> > > What seems to be happening is testpmd put the ports into some faulty 
> > > state.
> > This only happens on the DUT1 -> DUT2 link though (the ports between the
> > two testpmds), not on TG -> DUT1 link (the TG port is left alone).
> > >
> > >
> > >
> > > Some more info:
> > >
> > > We've come across the issue with this configuration:
> > >
> > > OS: Ubuntu20.04 with kernel 5.4.0-65-generic.
> > >
> > > Old NIC firmware, never upgraded: 6.01 0x800035da 1.1747.0.
> > >
> > > Drivers versions: i40e 2.17.15 and iavf 4.3.19.
> > >
> > >
> > >
> > > As well as with this configuration:
> > >
> > > OS: Ubuntu22.04 with kernel 5.15.0-46-generic.
> > >
> > > Updated firmware: 8.30 0x8000a4ae 1.2926.0.
> > >
> > > Drivers: i40e 2.19.3 and iavf 4.5.3.
> > >
> > >
> > >
> > > Unsafe noiommu mode is disabled:
> > >
> > > cat /sys/module/vfio/parameters/enable_unsafe_noiommu_mode
> > >
> > > N
> > >
> > >
> > >
> > > We used DPDK 22.07 in manual testing and built it on DUTs, using generic
> > build:
> > >
> > > meson -Dexamples=l

RE: [EXT] Re: [PATCH v11 1/4] lib: add generic support for reading PMU events

[Konstantin Ananyev]

> >> diff --git a/lib/pmu/rte_pmu.c b/lib/pmu/rte_pmu.c new file mode
> >> 100644 index 00..950f999cb7
> >> --- /dev/null
> >> +++ b/lib/pmu/rte_pmu.c
> >> @@ -0,0 +1,460 @@
> >> +/* SPDX-License-Identifier: BSD-3-Clause
> >> + * Copyright(C) 2023 Marvell International Ltd.
> >> + */
> >> +
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +#include "pmu_private.h"
> >> +
> >> +#define EVENT_SOURCE_DEVICES_PATH "/sys/bus/event_source/devices"
> >
> >
> >I suppose that pass (as the whole implementation) is linux specific?
> >If so, wouldn't it make sense to have it under linux subdir?
> >
> 
> There are not any plans to support that elsewhere currently so flat
> directory structure is good enough.

Ok, I suppose then best choice is to ask freebsd and windows maintainers.
Guys, any thoughts here?
Thanks
Konstantin

RE: [PATCH 1/3] examples/ipsec-secgw: fix auth IV length

[Ji, Kai]

Acked-by: Kai Ji 

> -Original Message-
> From: Akhil Goyal 
> Sent: Thursday, February 16, 2023 2:25 PM
> To: dev@dpdk.org
> Cc: Nicolau, Radu ; ano...@marvell.com;
> g.si...@nxp.com; hemant.agra...@nxp.com; Ji, Kai ;
> ruifeng.w...@arm.com; sunilprakashrao.uttar...@amd.com;
> rnagadhee...@marvell.com; ma...@nvidia.com; Akhil Goyal
> ; sta...@dpdk.org
> Subject: [PATCH 1/3] examples/ipsec-secgw: fix auth IV length
> 
> Currently, cipher IV length is getting used to set auth xform IV length.
> Auth IV is needed for AES-GMAC case, and in all other cases, auth IV
> should be 0.
> Used a separate auth IV length to separate out cipher and auth cases.
> 
> Fixes: 9413c3901f31 ("examples/ipsec-secgw: support additional
> algorithms")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Akhil Goyal 
> ---

RE: [PATCH 2/3] examples/ipsec-secgw: check capabilities before session create

[Ji, Kai]

Acked-by: Kai Ji 

> -Original Message-
> From: Akhil Goyal 
> Sent: Thursday, February 16, 2023 2:25 PM
> To: dev@dpdk.org
> Cc: Nicolau, Radu ; ano...@marvell.com;
> g.si...@nxp.com; hemant.agra...@nxp.com; Ji, Kai ;
> ruifeng.w...@arm.com; sunilprakashrao.uttar...@amd.com;
> rnagadhee...@marvell.com; ma...@nvidia.com; Akhil Goyal
> 
> Subject: [PATCH 2/3] examples/ipsec-secgw: check capabilities before
> session create
> 
> Currently, sessions are created without checking the device
> capabilities, which may result in failure at a later stage.
> 
> Device capabilities are now checked before creating the security/crypto
> session.
> 
> Signed-off-by: Akhil Goyal 
> ---

RE: [PATCH 3/3] examples/ipsec-secgw: refactor inline capability check

[Ji, Kai]

Acked-by: Kai Ji 

> -Original Message-
> From: Akhil Goyal 
> Sent: Thursday, February 16, 2023 2:25 PM
> To: dev@dpdk.org
> Cc: Nicolau, Radu ; ano...@marvell.com;
> g.si...@nxp.com; hemant.agra...@nxp.com; Ji, Kai ;
> ruifeng.w...@arm.com; sunilprakashrao.uttar...@amd.com;
> rnagadhee...@marvell.com; ma...@nvidia.com; Akhil Goyal
> 
> Subject: [PATCH 3/3] examples/ipsec-secgw: refactor inline capability
> check
> 
> In cases of inline IPsec, the supported ol_flags are retrieved from
> security capability of device.
> Now that capability checks are added before creating the session,
> ol_flags can be retrieved from the same function call.
> 
> Signed-off-by: Akhil Goyal 
> ---

Re: [PATCH] net/af_xdp: fix integer handling issues

[Ferruh Yigit]

On 2/21/2023 11:14 AM, Shibin Koikkara Reeny wrote:
> Fix integer handling issues (NEGATIVE_RETURNS) reported
> in coverity scan. Add a check to sock variable if the
> value is negative return -1.
> 
> Coverity issue: 383245
> Fixes: 7fc6ae50369d ("net/af_xdp: support CNI Integration")
> 
> Signed-off-by: Shibin Koikkara Reeny 

Acked-by: Ferruh Yigit 

Applied to dpdk-next-net/main, thanks.

[PATCH v4] net/gve: add Rx/Tx queue stats as extended stats

[Levend Sayar]

Google Virtual NIC rx/tx queue stats are added as extended stats.

Signed-off-by: Levend Sayar 
---
 drivers/net/gve/gve_ethdev.c | 137 +++
 drivers/net/gve/gve_ethdev.h |  28 +--
 drivers/net/gve/gve_rx.c |  12 +--
 drivers/net/gve/gve_tx.c |  11 +--
 4 files changed, 157 insertions(+), 31 deletions(-)

diff --git a/drivers/net/gve/gve_ethdev.c b/drivers/net/gve/gve_ethdev.c
index fef2458a16..a95bb041ea 100644
--- a/drivers/net/gve/gve_ethdev.c
+++ b/drivers/net/gve/gve_ethdev.c
@@ -6,9 +6,26 @@
 #include "base/gve_adminq.h"
 #include "base/gve_register.h"
 
+#define TX_QUEUE_STATS_OFFSET(x) offsetof(struct gve_tx_stats, x)
+#define RX_QUEUE_STATS_OFFSET(x) offsetof(struct gve_rx_stats, x)
+
 const char gve_version_str[] = GVE_VERSION;
 static const char gve_version_prefix[] = GVE_VERSION_PREFIX;
 
+static const struct gve_xstats_name_offset tx_xstats_name_offset[] = {
+   { "packets", TX_QUEUE_STATS_OFFSET(packets) },
+   { "bytes",   TX_QUEUE_STATS_OFFSET(bytes) },
+   { "errors",  TX_QUEUE_STATS_OFFSET(errors) },
+};
+
+static const struct gve_xstats_name_offset rx_xstats_name_offset[] = {
+   { "packets",RX_QUEUE_STATS_OFFSET(packets) },
+   { "bytes",  RX_QUEUE_STATS_OFFSET(bytes) },
+   { "errors", RX_QUEUE_STATS_OFFSET(errors) },
+   { "mbuf_alloc_errors",  RX_QUEUE_STATS_OFFSET(no_mbufs) },
+   { "mbuf_alloc_errors_bulk", RX_QUEUE_STATS_OFFSET(no_mbufs_bulk) },
+};
+
 static void
 gve_write_version(uint8_t *driver_version_register)
 {
@@ -328,9 +345,9 @@ gve_dev_stats_get(struct rte_eth_dev *dev, struct 
rte_eth_stats *stats)
if (txq == NULL)
continue;
 
-   stats->opackets += txq->packets;
-   stats->obytes += txq->bytes;
-   stats->oerrors += txq->errors;
+   stats->opackets += txq->stats.packets;
+   stats->obytes += txq->stats.bytes;
+   stats->oerrors += txq->stats.errors;
}
 
for (i = 0; i < dev->data->nb_rx_queues; i++) {
@@ -338,10 +355,10 @@ gve_dev_stats_get(struct rte_eth_dev *dev, struct 
rte_eth_stats *stats)
if (rxq == NULL)
continue;
 
-   stats->ipackets += rxq->packets;
-   stats->ibytes += rxq->bytes;
-   stats->ierrors += rxq->errors;
-   stats->rx_nombuf += rxq->no_mbufs;
+   stats->ipackets += rxq->stats.packets;
+   stats->ibytes += rxq->stats.bytes;
+   stats->ierrors += rxq->stats.errors;
+   stats->rx_nombuf += rxq->stats.no_mbufs;
}
 
return 0;
@@ -357,9 +374,7 @@ gve_dev_stats_reset(struct rte_eth_dev *dev)
if (txq == NULL)
continue;
 
-   txq->packets  = 0;
-   txq->bytes = 0;
-   txq->errors = 0;
+   memset(&txq->stats, 0, sizeof(txq->stats));
}
 
for (i = 0; i < dev->data->nb_rx_queues; i++) {
@@ -367,10 +382,7 @@ gve_dev_stats_reset(struct rte_eth_dev *dev)
if (rxq == NULL)
continue;
 
-   rxq->packets  = 0;
-   rxq->bytes = 0;
-   rxq->errors = 0;
-   rxq->no_mbufs = 0;
+   memset(&rxq->stats, 0, sizeof(rxq->stats));
}
 
return 0;
@@ -403,6 +415,101 @@ gve_dev_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
return 0;
 }
 
+static int
+gve_xstats_count(struct rte_eth_dev *dev)
+{
+   uint16_t i, count = 0;
+
+   for (i = 0; i < dev->data->nb_tx_queues; i++) {
+   if (dev->data->tx_queues[i])
+   count += RTE_DIM(tx_xstats_name_offset);
+   }
+
+   for (i = 0; i < dev->data->nb_rx_queues; i++) {
+   if (dev->data->rx_queues[i])
+   count += RTE_DIM(rx_xstats_name_offset);
+   }
+
+   return count;
+}
+
+static int
+gve_xstats_get(struct rte_eth_dev *dev,
+   struct rte_eth_xstat *xstats,
+   unsigned int size)
+{
+   uint16_t i, j, count = gve_xstats_count(dev);
+   const char *stats;
+
+   if ((xstats == NULL) || (size < count))
+   return count;
+
+   count = 0;
+
+   for (i = 0; i < dev->data->nb_tx_queues; i++) {
+   const struct gve_tx_queue *txq = dev->data->tx_queues[i];
+   if (txq == NULL)
+   continue;
+
+   stats = (const char *)&txq->stats;
+   for (j = 0; j < RTE_DIM(tx_xstats_name_offset); j++, count++) {
+   xstats[count].id = count;
+   xstats[count].value = *(const uint64_t *)
+   (stats + tx_xstats_name_offset[j].offset);
+   }
+   }
+
+   for (i = 0; i < dev->data->nb_rx_queues; i++) {
+   const struct gv

[PATCH v5] net/gve: add Rx/Tx queue stats as extended stats

[Levend Sayar]

Google Virtual NIC rx/tx queue stats are added as extended stats.

Signed-off-by: Levend Sayar 
---
 drivers/net/gve/gve_ethdev.c | 137 +++
 drivers/net/gve/gve_ethdev.h |  28 +--
 drivers/net/gve/gve_rx.c |  12 +--
 drivers/net/gve/gve_tx.c |  11 +--
 4 files changed, 157 insertions(+), 31 deletions(-)

diff --git a/drivers/net/gve/gve_ethdev.c b/drivers/net/gve/gve_ethdev.c
index fef2458a16..21f0c0fca2 100644
--- a/drivers/net/gve/gve_ethdev.c
+++ b/drivers/net/gve/gve_ethdev.c
@@ -6,9 +6,26 @@
 #include "base/gve_adminq.h"
 #include "base/gve_register.h"
 
+#define TX_QUEUE_STATS_OFFSET(x) offsetof(struct gve_tx_stats, x)
+#define RX_QUEUE_STATS_OFFSET(x) offsetof(struct gve_rx_stats, x)
+
 const char gve_version_str[] = GVE_VERSION;
 static const char gve_version_prefix[] = GVE_VERSION_PREFIX;
 
+static const struct gve_xstats_name_offset tx_xstats_name_offset[] = {
+   { "packets", TX_QUEUE_STATS_OFFSET(packets) },
+   { "bytes",   TX_QUEUE_STATS_OFFSET(bytes) },
+   { "errors",  TX_QUEUE_STATS_OFFSET(errors) },
+};
+
+static const struct gve_xstats_name_offset rx_xstats_name_offset[] = {
+   { "packets",RX_QUEUE_STATS_OFFSET(packets) },
+   { "bytes",  RX_QUEUE_STATS_OFFSET(bytes) },
+   { "errors", RX_QUEUE_STATS_OFFSET(errors) },
+   { "mbuf_alloc_errors",  RX_QUEUE_STATS_OFFSET(no_mbufs) },
+   { "mbuf_alloc_errors_bulk", RX_QUEUE_STATS_OFFSET(no_mbufs_bulk) },
+};
+
 static void
 gve_write_version(uint8_t *driver_version_register)
 {
@@ -328,9 +345,9 @@ gve_dev_stats_get(struct rte_eth_dev *dev, struct 
rte_eth_stats *stats)
if (txq == NULL)
continue;
 
-   stats->opackets += txq->packets;
-   stats->obytes += txq->bytes;
-   stats->oerrors += txq->errors;
+   stats->opackets += txq->stats.packets;
+   stats->obytes += txq->stats.bytes;
+   stats->oerrors += txq->stats.errors;
}
 
for (i = 0; i < dev->data->nb_rx_queues; i++) {
@@ -338,10 +355,10 @@ gve_dev_stats_get(struct rte_eth_dev *dev, struct 
rte_eth_stats *stats)
if (rxq == NULL)
continue;
 
-   stats->ipackets += rxq->packets;
-   stats->ibytes += rxq->bytes;
-   stats->ierrors += rxq->errors;
-   stats->rx_nombuf += rxq->no_mbufs;
+   stats->ipackets += rxq->stats.packets;
+   stats->ibytes += rxq->stats.bytes;
+   stats->ierrors += rxq->stats.errors;
+   stats->rx_nombuf += rxq->stats.no_mbufs;
}
 
return 0;
@@ -357,9 +374,7 @@ gve_dev_stats_reset(struct rte_eth_dev *dev)
if (txq == NULL)
continue;
 
-   txq->packets  = 0;
-   txq->bytes = 0;
-   txq->errors = 0;
+   memset(&txq->stats, 0, sizeof(txq->stats));
}
 
for (i = 0; i < dev->data->nb_rx_queues; i++) {
@@ -367,10 +382,7 @@ gve_dev_stats_reset(struct rte_eth_dev *dev)
if (rxq == NULL)
continue;
 
-   rxq->packets  = 0;
-   rxq->bytes = 0;
-   rxq->errors = 0;
-   rxq->no_mbufs = 0;
+   memset(&rxq->stats, 0, sizeof(rxq->stats));
}
 
return 0;
@@ -403,6 +415,101 @@ gve_dev_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
return 0;
 }
 
+static int
+gve_xstats_count(struct rte_eth_dev *dev)
+{
+   uint16_t i, count = 0;
+
+   for (i = 0; i < dev->data->nb_tx_queues; i++) {
+   if (dev->data->tx_queues[i])
+   count += RTE_DIM(tx_xstats_name_offset);
+   }
+
+   for (i = 0; i < dev->data->nb_rx_queues; i++) {
+   if (dev->data->rx_queues[i])
+   count += RTE_DIM(rx_xstats_name_offset);
+   }
+
+   return count;
+}
+
+static int
+gve_xstats_get(struct rte_eth_dev *dev,
+   struct rte_eth_xstat *xstats,
+   unsigned int size)
+{
+   uint16_t i, j, count = gve_xstats_count(dev);
+   const char *stats;
+
+   if (xstats == NULL || size < count)
+   return count;
+
+   count = 0;
+
+   for (i = 0; i < dev->data->nb_tx_queues; i++) {
+   const struct gve_tx_queue *txq = dev->data->tx_queues[i];
+   if (txq == NULL)
+   continue;
+
+   stats = (const char *)&txq->stats;
+   for (j = 0; j < RTE_DIM(tx_xstats_name_offset); j++, count++) {
+   xstats[count].id = count;
+   xstats[count].value = *(const uint64_t *)
+   (stats + tx_xstats_name_offset[j].offset);
+   }
+   }
+
+   for (i = 0; i < dev->data->nb_rx_queues; i++) {
+   const struct gve_rx

[PATCH v1 0/2] net/octeon_ep: support device close and port kind

[Sathesh Edara]

This patch set adds device close functionality
and 2nd patch adds port kind functionality.

Sathesh Edara (2):
  net/octeon_ep: support device close
  net/octeon_ep: support port kind

 drivers/net/octeon_ep/otx_ep_common.h |  1 +
 drivers/net/octeon_ep/otx_ep_ethdev.c | 65 +--
 drivers/net/octeon_ep/otx_ep_rxtx.c   | 16 +++
 3 files changed, 39 insertions(+), 43 deletions(-)

-- 
2.31.1

[PATCH v1 2/2] net/octeon_ep: support port kind

[Sathesh Edara]

Added port kind functionality.

Signed-off-by: Sathesh Edara 
---
 drivers/net/octeon_ep/otx_ep_common.h |  1 +
 drivers/net/octeon_ep/otx_ep_ethdev.c |  2 +-
 drivers/net/octeon_ep/otx_ep_rxtx.c   | 16 
 3 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/net/octeon_ep/otx_ep_common.h 
b/drivers/net/octeon_ep/otx_ep_common.h
index 7eb50af75a..e4c92270d4 100644
--- a/drivers/net/octeon_ep/otx_ep_common.h
+++ b/drivers/net/octeon_ep/otx_ep_common.h
@@ -32,6 +32,7 @@
 #define OTX_EP_PCI_RING_ALIGN   65536
 #define SDP_PKIND 40
 #define SDP_OTX2_PKIND 57
+#define SDP_OTX2_PKIND_FS0 0
 
 #define  ORDERED_TAG 0
 #define  ATOMIC_TAG  1
diff --git a/drivers/net/octeon_ep/otx_ep_ethdev.c 
b/drivers/net/octeon_ep/otx_ep_ethdev.c
index 0930efedce..f43db1e398 100644
--- a/drivers/net/octeon_ep/otx_ep_ethdev.c
+++ b/drivers/net/octeon_ep/otx_ep_ethdev.c
@@ -495,7 +495,7 @@ otx_ep_eth_dev_init(struct rte_eth_dev *eth_dev)
 
otx_epdev_init(otx_epvf);
if (pdev->id.device_id == PCI_DEVID_CN9K_EP_NET_VF)
-   otx_epvf->pkind = SDP_OTX2_PKIND;
+   otx_epvf->pkind = SDP_OTX2_PKIND_FS0;
else
otx_epvf->pkind = SDP_PKIND;
otx_ep_info("using pkind %d\n", otx_epvf->pkind);
diff --git a/drivers/net/octeon_ep/otx_ep_rxtx.c 
b/drivers/net/octeon_ep/otx_ep_rxtx.c
index 59df6ad857..6912ca2401 100644
--- a/drivers/net/octeon_ep/otx_ep_rxtx.c
+++ b/drivers/net/octeon_ep/otx_ep_rxtx.c
@@ -17,7 +17,8 @@
 #include "otx_ep_rxtx.h"
 
 /* SDP_LENGTH_S specifies packet length and is of 8-byte size */
-#define INFO_SIZE 8
+#define OTX_EP_INFO_SIZE 8
+#define OTX_EP_FSZ_FS0 0
 #define DROQ_REFILL_THRESHOLD 16
 
 static void
@@ -678,7 +679,7 @@ otx2_ep_xmit_pkts(void *tx_queue, struct rte_mbuf **pkts, 
uint16_t nb_pkts)
iqcmd2.irh.u64 = 0;
 
/* ih invars */
-   iqcmd2.ih.s.fsz = OTX2_EP_FSZ;
+   iqcmd2.ih.s.fsz = OTX_EP_FSZ_FS0;
iqcmd2.ih.s.pkind = otx_ep->pkind; /* The SDK decided PKIND value */
/* irh invars */
iqcmd2.irh.s.opcode = OTX_EP_NW_PKT_OP;
@@ -875,12 +876,11 @@ otx_ep_droq_read_packet(struct otx_ep_device *otx_ep,
 
info->length = rte_bswap64(info->length);
/* Deduce the actual data size */
-   total_pkt_len = info->length + INFO_SIZE;
+   total_pkt_len = info->length + OTX_EP_INFO_SIZE;
if (total_pkt_len <= droq->buffer_size) {
-   info->length -=  OTX_EP_RH_SIZE;
droq_pkt  = droq->recv_buf_list[droq->read_idx];
if (likely(droq_pkt != NULL)) {
-   droq_pkt->data_off += OTX_EP_DROQ_INFO_SIZE;
+   droq_pkt->data_off += OTX_EP_INFO_SIZE;
/* otx_ep_dbg("OQ: pkt_len[%ld], buffer_size %d\n",
 * (long)info->length, droq->buffer_size);
 */
@@ -917,11 +917,11 @@ otx_ep_droq_read_packet(struct otx_ep_device *otx_ep,
droq_pkt->port = otx_ep->port_id;
if (!pkt_len) {
droq_pkt->data_off +=
-   OTX_EP_DROQ_INFO_SIZE;
+   OTX_EP_INFO_SIZE;
droq_pkt->pkt_len =
-   cpy_len - OTX_EP_DROQ_INFO_SIZE;
+   cpy_len - OTX_EP_INFO_SIZE;
droq_pkt->data_len =
-   cpy_len - OTX_EP_DROQ_INFO_SIZE;
+   cpy_len - OTX_EP_INFO_SIZE;
} else {
droq_pkt->pkt_len = cpy_len;
droq_pkt->data_len = cpy_len;
-- 
2.31.1

Re: unable to bind to vfio-pci

[Bruce Richardson]

On Tue, Feb 21, 2023 at 08:05:20PM +0530, Nagendra Prabhu A T wrote:
>Hi All,
>I am trying to bind vfio-pci using dpdk-devbind.py, But i am seeing teh
>following error :
>root@nat-kvm:/usr/src/dpdk-22.11/usertools# dpdk-devbind.py
>--bind=vfio-pci :51:00.0 Error: bind failed for :51:00.0 -
>Cannot bind to driver vfio-pci: [Errno 22] Invalid argument
>root@nat-kvm:/usr/src/dpdk-22.11/usertools#
>I see that Sarosh has faced the same issue earlier. I saw the mail
>thread and followed all the steps mentioned there. But it dint help.
>Can you please help.

An error like that I would attribute to one of two possible likely causes.
[There may be other causes, but these two come to mind immediately].

1. No IOMMU available for use. In this case you need to enable no-iommu
   mode for VFIO and see if that works.
2. You have other ports on the same card bound to a kernel driver. You
   cannot use one port bound to the kernel (and therefore using IOMMU
   mappings for the kernel), while another port on the same card is bound
   to userspace vfio (and therefore looking for userspace IOMMU mappings).
   If this is the case, you need to unbind the other port from the kernel,
   and leave it unbound or else also bound to vfio. It's possible that
   no-iommu mode may help here too, but I have never tested that.

Regards,
/Bruce

Re: [PATCH v8 04/22] efd: replace RTE_LOGTYPE_EFD with dynamic type

[David Marchand]

On Tue, Feb 21, 2023 at 12:36 AM Stephen Hemminger
 wrote:
>
> Replace all uses of the global logtype with a dynamic log type.
>
> Signed-off-by: Stephen Hemminger 
> ---
>  lib/eal/common/eal_common_log.c | 1 -
>  lib/eal/include/rte_log.h   | 2 +-
>  lib/efd/rte_efd.c   | 4 
>  3 files changed, 5 insertions(+), 2 deletions(-)

[snip]

> diff --git a/lib/efd/rte_efd.c b/lib/efd/rte_efd.c
> index 686a13775742..9edb11799c89 100644
> --- a/lib/efd/rte_efd.c
> +++ b/lib/efd/rte_efd.c
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>
> +#include 
>  #include 
>  #include 
>  #include 

This is unrelated, isn't it?


-- 
David Marchand

[PATCH v1 1/2] net/octeon_ep: support device close

[Sathesh Edara]

Added dev close functionality in the ethdev ops
and moves input and output queue deletion
functionality into it from otx_epdev_exit()
routine.

Signed-off-by: Sathesh Edara 
---
 drivers/net/octeon_ep/otx_ep_ethdev.c | 63 ---
 1 file changed, 29 insertions(+), 34 deletions(-)

diff --git a/drivers/net/octeon_ep/otx_ep_ethdev.c 
b/drivers/net/octeon_ep/otx_ep_ethdev.c
index c8f4abe4ca..0930efedce 100644
--- a/drivers/net/octeon_ep/otx_ep_ethdev.c
+++ b/drivers/net/octeon_ep/otx_ep_ethdev.c
@@ -395,6 +395,34 @@ otx_ep_dev_stats_get(struct rte_eth_dev *eth_dev,
return 0;
 }
 
+static int
+otx_ep_dev_close(struct rte_eth_dev *eth_dev)
+{
+   struct otx_ep_device *otx_epvf = OTX_EP_DEV(eth_dev);
+   uint32_t num_queues, q_no;
+
+   otx_epvf->fn_list.disable_io_queues(otx_epvf);
+   num_queues = otx_epvf->nb_rx_queues;
+   for (q_no = 0; q_no < num_queues; q_no++) {
+   if (otx_ep_delete_oqs(otx_epvf, q_no)) {
+   otx_ep_err("Failed to delete OQ:%d\n", q_no);
+   return -EINVAL;
+   }
+   }
+   otx_ep_dbg("Num OQs:%d freed\n", otx_epvf->nb_rx_queues);
+
+   num_queues = otx_epvf->nb_tx_queues;
+   for (q_no = 0; q_no < num_queues; q_no++) {
+   if (otx_ep_delete_iqs(otx_epvf, q_no)) {
+   otx_ep_err("Failed to delete IQ:%d\n", q_no);
+   return -EINVAL;
+   }
+   }
+   otx_ep_dbg("Num IQs:%d freed\n", otx_epvf->nb_tx_queues);
+
+   return 0;
+}
+
 static int
 otx_ep_dev_link_update(struct rte_eth_dev *eth_dev, int wait_to_complete)
 {
@@ -424,47 +452,14 @@ static const struct eth_dev_ops otx_ep_eth_dev_ops = {
.stats_get  = otx_ep_dev_stats_get,
.stats_reset= otx_ep_dev_stats_reset,
.link_update= otx_ep_dev_link_update,
+   .dev_close  = otx_ep_dev_close,
 };
 
-static int
-otx_epdev_exit(struct rte_eth_dev *eth_dev)
-{
-   struct otx_ep_device *otx_epvf;
-   uint32_t num_queues, q;
-
-   otx_ep_info("%s:\n", __func__);
-
-   otx_epvf = OTX_EP_DEV(eth_dev);
-
-   otx_epvf->fn_list.disable_io_queues(otx_epvf);
-
-   num_queues = otx_epvf->nb_rx_queues;
-   for (q = 0; q < num_queues; q++) {
-   if (otx_ep_delete_oqs(otx_epvf, q)) {
-   otx_ep_err("Failed to delete OQ:%d\n", q);
-   return -EINVAL;
-   }
-   }
-   otx_ep_info("Num OQs:%d freed\n", otx_epvf->nb_rx_queues);
-
-   num_queues = otx_epvf->nb_tx_queues;
-   for (q = 0; q < num_queues; q++) {
-   if (otx_ep_delete_iqs(otx_epvf, q)) {
-   otx_ep_err("Failed to delete IQ:%d\n", q);
-   return -EINVAL;
-   }
-   }
-   otx_ep_dbg("Num IQs:%d freed\n", otx_epvf->nb_tx_queues);
-
-   return 0;
-}
-
 static int
 otx_ep_eth_dev_uninit(struct rte_eth_dev *eth_dev)
 {
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
return 0;
-   otx_epdev_exit(eth_dev);
 
eth_dev->dev_ops = NULL;
eth_dev->rx_pkt_burst = NULL;
-- 
2.31.1

Re: [PATCH v8 21/22] hash: move rte_hash_set_alg out header

[David Marchand]

On Tue, Feb 21, 2023 at 12:38 AM Stephen Hemminger
 wrote:
>
> The code for setting algorithm for hash is not at all perf sensitive,
> and doing it inline has a couple of problems. First, it means that if
> multiple files include the header, then the initialization gets done
> multiple times. But also, it makes it harder to fix usage of RTE_LOG().
>
> Despite what the checking script say. This is not an ABI change, the
> previous version inlined the same code; therefore both old and new code
> will work the same.

I suppose you are referring to:
http://mails.dpdk.org/archives/test-report/2023-February/356872.html
ERROR: symbol rte_hash_crc_set_alg is added in the DPDK_23 section,
but is expected to be added in the EXPERIMENTAL section of the version
map

I agree that this is irrelevant and can be ignored in this particular case.


-- 
David Marchand

Re: [PATCH 1/2] net/bonding: add independent LACP sending function

[Simon Horman]

On Thu, Feb 16, 2023 at 11:47:27AM -0800, Stephen Hemminger wrote:
> On Thu, 16 Feb 2023 15:15:13 +0800
> Chaoyong He  wrote:
> 
> > +void
> > +rte_eth_bond_8023ad_lacp_send_one(void *queue)
> > +{
> > + uint32_t i;
> > + uint16_t slave_tx_count;
> > + uint16_t active_slave_count;
> > + uint16_t active_slave_ids[RTE_MAX_ETHPORTS];
> 
> Thinking ahead, all of bonding driver should remove the usage of the
> terms master and slave.  Perhaps you don't want to introduce new
> usages that will have to be fixed.
> 
> FYI - there is no usage of master/slave in any of the IEEE standards,
> or operating systems other than Linux.

Thanks Stephen,

could we agree on alternative language?

unable to bind to vfio-pci

[Nagendra Prabhu A T]

Hi All,

I am trying to bind vfio-pci using dpdk-devbind.py, But i am seeing teh
following error :

root@nat-kvm:/usr/src/dpdk-22.11/usertools# dpdk-devbind.py --bind=vfio-pci
:51:00.0 Error: bind failed for :51:00.0 - Cannot bind to driver
vfio-pci: [Errno 22] Invalid argument
root@nat-kvm:/usr/src/dpdk-22.11/usertools#


I see that Sarosh has faced the same issue earlier. I saw the mail thread
and followed all the steps mentioned there. But it dint help.

Can you please help.

Thanks
Nagendra

Re: [PATCH v8 21/22] hash: move rte_hash_set_alg out header

[David Marchand]

On Tue, Feb 21, 2023 at 12:38 AM Stephen Hemminger
 wrote:
> diff --git a/lib/hash/rte_hash_crc.c b/lib/hash/rte_hash_crc.c
> new file mode 100644
> index ..c59eebccb1eb
> --- /dev/null
> +++ b/lib/hash/rte_hash_crc.c
> @@ -0,0 +1,63 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(c) 2010-2014 Intel Corporation
> + */
> +
> +#include 
> +#include 
> +
> +#include "rte_hash_crc.h"
> +
> +/**
> + * Allow or disallow use of SSE4.2/ARMv8 intrinsics for CRC32 hash
> + * calculation.
> + *
> + * @param alg
> + *   An OR of following flags:
> + *   - (CRC32_SW) Don't use SSE4.2/ARMv8 intrinsics (default non-[x86/ARMv8])
> + *   - (CRC32_SSE42) Use SSE4.2 intrinsics if available
> + *   - (CRC32_SSE42_x64) Use 64-bit SSE4.2 intrinsic if available (default 
> x86)
> + *   - (CRC32_ARM64) Use ARMv8 CRC intrinsic if available (default ARMv8)
> + *
> + */
> +void
> +rte_hash_crc_set_alg(uint8_t alg)
> +{
> +   crc32_alg = CRC32_SW;
> +
> +   if (alg == CRC32_SW)
> +   return;
> +
> +#if defined RTE_ARCH_X86
> +   if (!(alg & CRC32_SSE42_x64))
> +   RTE_LOG(WARNING, HASH,
> +   "Unsupported CRC32 algorithm requested using 
> CRC32_x64/CRC32_SSE42\n");
> +   if (!rte_cpu_get_flag_enabled(RTE_CPUFLAG_EM64T) || alg == 
> CRC32_SSE42)
> +   crc32_alg = CRC32_SSE42;
> +   else
> +   crc32_alg = CRC32_SSE42_x64;
> +#endif
> +
> +#if defined RTE_ARCH_ARM64
> +   if (!(alg & CRC32_ARM64))
> +   RTE_LOG(WARNING, HASH,
> +   "Unsupported CRC32 algorithm requested using 
> CRC32_ARM64\n");
> +   if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_CRC32))
> +   crc32_alg = CRC32_ARM64;
> +#endif
> +
> +   if (crc32_alg == CRC32_SW)
> +   RTE_LOG(WARNING, HASH,
> +   "Unsupported CRC32 algorithm requested using 
> CRC32_SW\n");
> +}
> +
> +/* Setting the best available algorithm */
> +RTE_INIT(rte_hash_crc_init_alg)
> +{
> +#if defined(RTE_ARCH_X86)
> +   rte_hash_crc_set_alg(CRC32_SSE42_x64);
> +#elif defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_CRC32)
> +   rte_hash_crc_set_alg(CRC32_ARM64);
> +#else
> +   rte_hash_crc_set_alg(CRC32_SW);
> +#endif
> +}
> diff --git a/lib/hash/rte_hash_crc.h b/lib/hash/rte_hash_crc.h
> index 0249ad16c5b6..e4acd99a0c81 100644
> --- a/lib/hash/rte_hash_crc.h
> +++ b/lib/hash/rte_hash_crc.h
> @@ -20,8 +20,6 @@ extern "C" {
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
>
>  #include "rte_crc_sw.h"
>
> @@ -53,48 +51,8 @@ static uint8_t crc32_alg = CRC32_SW;
>   *   - (CRC32_ARM64) Use ARMv8 CRC intrinsic if available (default ARMv8)
>   *
>   */
> -static inline void
> -rte_hash_crc_set_alg(uint8_t alg)
> -{
> -   crc32_alg = CRC32_SW;
> -
> -   if (alg == CRC32_SW)
> -   return;
> -
> -#if defined RTE_ARCH_X86
> -   if (!(alg & CRC32_SSE42_x64))
> -   RTE_LOG(WARNING, HASH,
> -   "Unsupported CRC32 algorithm requested using 
> CRC32_x64/CRC32_SSE42\n");
> -   if (!rte_cpu_get_flag_enabled(RTE_CPUFLAG_EM64T) || alg == 
> CRC32_SSE42)
> -   crc32_alg = CRC32_SSE42;
> -   else
> -   crc32_alg = CRC32_SSE42_x64;
> -#endif
> -
> -#if defined RTE_ARCH_ARM64
> -   if (!(alg & CRC32_ARM64))
> -   RTE_LOG(WARNING, HASH,
> -   "Unsupported CRC32 algorithm requested using 
> CRC32_ARM64\n");
> -   if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_CRC32))
> -   crc32_alg = CRC32_ARM64;
> -#endif
> -
> -   if (crc32_alg == CRC32_SW)
> -   RTE_LOG(WARNING, HASH,
> -   "Unsupported CRC32 algorithm requested using 
> CRC32_SW\n");
> -}
> -
> -/* Setting the best available algorithm */
> -RTE_INIT(rte_hash_crc_init_alg)
> -{
> -#if defined(RTE_ARCH_X86)
> -   rte_hash_crc_set_alg(CRC32_SSE42_x64);
> -#elif defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_CRC32)
> -   rte_hash_crc_set_alg(CRC32_ARM64);
> -#else
> -   rte_hash_crc_set_alg(CRC32_SW);
> -#endif
> -}
> +void
> +rte_hash_crc_set_alg(uint8_t alg);

There is likely something unfinished with this code move.
See test report from GHA.
http://mails.dpdk.org/archives/test-report/2023-February/356932.html

[174/3761] Compiling C object 'lib/76b5a35@@rte_hash at
sta/hash_rte_fbk_hash.c.o'.
FAILED: lib/76b5a35@@rte_hash at sta/hash_rte_fbk_hash.c.o
ccache powerpc64le-linux-gnu-gcc -Ilib/76b5a35@@rte_hash at sta -Ilib
-I../lib -Ilib/hash -I../lib/hash -I. -I../ -Iconfig -I../config
-Ilib/eal/include -I../lib/eal/include -Ilib/eal/linux/include
-I../lib/eal/linux/include -Ilib/eal/ppc/include
-I../lib/eal/ppc/include -Ilib/eal/common -I../lib/eal/common
-Ilib/eal -I../lib/eal -Ilib/kvargs -I../lib/kvargs
-Ilib/telemetry/../metrics -I../lib/telemetry/../metrics
-Ilib/telemetry -I../lib/telemetry -Ilib/net -I../lib/net -Ilib/mbuf
-I../lib/mbuf -Ilib/mempool -I../lib/mempoo

Re: [dpdk-dev] [RFC] testpmd: support user-id attribute

[Singh, Aman Deep]

As per RFC, I guess possible testpmd implementation will have a mapping between
user-id(new) <=> rule-id (old/testpmd)
And this mapping will be maintained in testpmd code.
Please check, if that is how it is planned?

Another option I feel that this mapping done outside, by intermediate script
OVS_log (with user id) => script => testpmd flow commands

Any other options/comments are welcome.

Thanks
Aman

On 2/21/2023 3:56 PM, Thomas Monjalon wrote:

This feature assigns custom IDs to flow rules
so a complete sequence of commands can prepared in a script.
As a test application, I think it is really valuable to be able
to script a sequence.

Any other opinions?
If you want to see this feature please speak to encourage its development.


30/01/2023 11:03, Asaf Penso:

Hello Aman,
Can you clarify your intention? Like Eli mentioned, the group_id is less 
relevant for that purpose. Even with the same group_id we wish to have several 
different flows with different user-id.

All,
Do you have any other comments?
We would like to proceed with the process of sending v1, review, and integrate.

Regards,
Asaf Penso


-Original Message-
From: Eli Britstein 
Sent: Sunday, 7 August 2022 10:01
To: Singh, Aman Deep ; dev@dpdk.org
Cc: Slava Ovsiienko ; Ori Kam ;
Asaf Penso ; Matan Azrad ; Gaetan
Rivet ; Nir Anteby ; Yuying
Zhang ; Ferruh Yigit ;
Andrew Rybchenko ; NBU-Contact-
Thomas Monjalon (EXTERNAL) 
Subject: RE: [dpdk-dev] [RFC] testpmd: support user-id attribute

Hi Aman,

No, the group attribute has its own meaning, so it cannot be used for this
purpose, unless I misunderstood your meaning.

Thanks,
Eli


-Original Message-
From: Singh, Aman Deep 
Sent: Thursday, July 28, 2022 5:07 PM
To: dev@dpdk.org; Eli Britstein 
Cc: Slava Ovsiienko ; Ori Kam
; Asaf Penso ; Matan Azrad
; Gaetan Rivet ; Nir Anteby
; Yuying Zhang ; Ferruh
Yigit ; Andrew Rybchenko
; NBU-Contact- Thomas Monjalon
(EXTERNAL) 
Subject: Re: [dpdk-dev] [RFC] testpmd: support user-id attribute

External email: Use caution opening links or attachments


Hi Eli,

In RTE flow there is support for group_id attribute(u32).
Similar to the example you gave-

testpmd> flow create 0 group 0x1234 ingress pattern eth / end actions
count / drop / end

Please check if it fits the requirement.

Regards
Aman


On 7/20/2022 2:14 AM, Thomas Monjalon wrote:

+Cc ethdev and testpmd maintainers

Any feedback about this need and solution?


04/07/2022 10:24, Eli Britstein:

Upon creation of a flow, testpmd assigns it a flow ID. Later, the
flow ID is used for flow operations (query, destroy, dump).

The testpmd application allows to manage flow rules with its IDs.
The flow ID is known only when the flow is created.
In order to prepare a complete sequence of testpmd commands to
copy/paste, the flow IDs must be predictable.

The idea brought here is to allow providing some user-defined ID,
chosen in advance of the effective flow creation.


Example:

testpmd> flow create 0 ingress user_id 0x1234 pattern eth / end
testpmd> actions
count / drop / end
Flow rule #0 created, user-id 0x1234

testpmd> flow destroy 0 user_id rule 0x1234
Flow rule #0 destroyed, user-id 0x1234 Here, "user_id" is a flag
that signifies the "rule" ID is the user-id.

The motivation is from OVS. OVS dumps its "rte_flow_create" calls to
the log in testpmd commands syntax. As the flow ID testpmd would
assign is unkwon, it cannot log valid "flow destroy" commands.

With the enhancement described above, valid testpmd commands can be
created in a log to copy/paste to testpmd.
The application's flows sequence can then be played back in testpmd,
to enable enhanced dpdk debug capabilities of the applications's
flows in a controlled environment of testpmd rather than a dynamic,
more difficult to debug environment of the application.

Re: [PATCH v5] net/gve: add Rx/Tx queue stats as extended stats

[Ferruh Yigit]

On 2/21/2023 2:18 PM, Levend Sayar wrote:
> Google Virtual NIC rx/tx queue stats are added as extended stats.
> 
> Signed-off-by: Levend Sayar 

Reviewed-by: Ferruh Yigit 

<...>

> @@ -20,6 +20,7 @@ gve_rx_refill(struct gve_rx_queue *rxq)
>   if (nb_alloc <= rxq->nb_avail) {
>   diag = rte_pktmbuf_alloc_bulk(rxq->mpool, &rxq->sw_ring[idx], 
> nb_alloc);
>   if (diag < 0) {
> + rxq->stats.no_mbufs_bulk++;

It is not common to record bulk alloc failures, but as 'no_mbufs'
already recorded conventionally, I guess it is OK to keep this extra
stat if it is helpful.

Re: [PATCH v3 1/2] net/gve: fix Rx no mbufs stats counter update

[Ferruh Yigit]

On 2/20/2023 9:11 PM, Levend Sayar wrote:
> rx no_mbufs stats counter update is added for another error case.
> 
> Fixes: 4f6b1dd8240c ("net/gve: support basic statistics")
> Cc: junfeng@intel.com
> 
> Signed-off-by: Levend Sayar 

Reviewed-by: Ferruh Yigit 


(No problem for this time, but for future contributions, it is expected
to have new versions as a whole patchset, otherwise that becomes too
difficult to manage for maintainers to cherry pick various versions of
individual patches in a set, specially on peak time of release.
Also harder to backtrace from patchwork/list if someone wants the check
the history.)

Re: unable to bind to vfio-pci

[Bruce Richardson]

On Tue, Feb 21, 2023 at 09:30:15PM +0530, Nagendra Prabhu A T wrote:
>HI Bruce,
>Thanks for your reply.
>I have removed the binding of all other ports. So , i can confirm that
>#2 is taken care of.
>I tried using a different driver "uio_pci_generic". I still see the
>same issue for that driver as well.
>The problem seems to be because the write operation is not happening in
>"bind" file.
>Infact tried doing the following step manually. That also failed
>echo sh -c :51:00.0 > /sys/bus/pci/drivers/uio_pci_generic/bind
>bash: echo: write error: No such device

The "sh -c" doesn't look right in that command. It should just echo the
device id to the bind file. However, it's generally recommended just to use
the devbind script, as more writes to sysfs may be necessary first, e.g. to
register the device ids first.

>I have required permission for the file.
>I tried doing with "sudo"
>I dont have selinux running
>So not sure whats blocking me. Infact , even
>"cat /sys/bus/pci/drivers/uio_pci_generic/bind" is failing
>Can you please help.

To track down issues other than the obvious, I think we need more
information. For example, what NIC card is this? Are there any useful error
messages in dmesg?

/Bruce

Re: [PATCH v3] vhost: exclude VM hugepages from coredumps

[Maxime Coquelin]

Hi Mike,

On 2/10/23 22:12, Mike Pattrick wrote:

On Fri, Feb 10, 2023 at 10:53 AM David Marchand
 wrote:


Hello Mike,

On Wed, Dec 7, 2022 at 5:54 PM Mike Pattrick  wrote:


Currently if an application wants to include shared hugepages in
coredumps in conjunction with the vhost library, the coredump will be
larger than expected and include unneeded virtual machine memory.

This patch will mark all vhost huge pages as DONTDUMP, except for some
select pages used by DPDK.

Signed-off-by: Mike Pattrick 


I noticed the following warnings today on my f37 kernel, while running
a vhost-user/virtio-user testpmd setup on next-virtio branch.
Linux dmarchan 6.1.9-200.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Feb  2
00:21:48 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
My system has 2M hugepages, only.


$ rm vhost-net; strace -e trace=madvise -f
./build-clang/app/dpdk-testpmd --in-memory --no-pci
--vdev=net_vhost0,iface=./vhost-net,client=1 -- -i

$ ./build-clang/app/dpdk-testpmd --in-memory --single-file-segment
--no-pci --vdev
'net_virtio_user0,mac=00:01:02:03:04:05,path=./vhost-net,server=1'  --
-i

Then, on the "vhost side" testpmd:
...
VHOST_CONFIG: (./vhost-net) read message VHOST_USER_SET_VRING_NUM
VHOST_CONFIG: (./vhost-net) read message VHOST_USER_SET_VRING_BASE
VHOST_CONFIG: (./vhost-net) vring base idx:0 last_used_idx:0 last_avail_idx:0.
VHOST_CONFIG: (./vhost-net) read message VHOST_USER_SET_VRING_ADDR
VHOST_CONFIG: (./vhost-net) read message VHOST_USER_SET_VRING_KICK
VHOST_CONFIG: (./vhost-net) vring kick idx:0 file:391
[pid 59565] madvise(0x7fa6d8da4000, 2052, MADV_DODUMP) = -1 EINVAL
(Invalid argument)
VHOST_CONFIG: could not set coredump preference (Invalid argument).
[pid 59565] madvise(0x7fa6d8da5000, 2052, MADV_DODUMP) = -1 EINVAL
(Invalid argument)
VHOST_CONFIG: could not set coredump preference (Invalid argument).
[pid 59565] madvise(0x7fa6d8da6000, 2052, MADV_DODUMP) = -1 EINVAL
(Invalid argument)
VHOST_CONFIG: could not set coredump preference (Invalid argument).
VHOST_CONFIG: (./vhost-net) read message VHOST_USER_SET_VRING_NUM
VHOST_CONFIG: (./vhost-net) read message VHOST_USER_SET_VRING_BASE

Looking at the whole trace, only madvise calls with MADV_DODUMP (with
all of them for a 2052 size) fail.

I did not investigate further.
Could you have a look please?



I tried it on that exact kernel and also ran into this issue. I'll
check it out in more depth.


Gentle reminder, have you found the root cause for this issue?

Thanks,
Maxime


-M



--
David Marchand

Re: unable to bind to vfio-pci

[Bruce Richardson]

On Tue, Feb 21, 2023 at 09:46:30PM +0530, Nagendra Prabhu A T wrote:
>These are the messages i am seeing dmesg
>[16588.298660] vfio-pci: probe of :8a:00.2 failed with error -22
>[16591.574630] i40e :8a:00.3: i40e_ptp_stop: removed PHC on
>enp138s0f3
>[16593.138613] vfio-pci: probe of :8a:00.3 failed with error -22
>[16593.138674] vfio-pci: probe of :8a:00.3 failed with error -22
>[16627.551866] vfio-pci: probe of :51:00.0 failed with error -22
>[16627.551922] vfio-pci: probe of :51:00.0 failed with error -22
>[16716.344530] vfio-pci: probe of :51:00.0 failed with error -22
>[16716.344585] vfio-pci: probe of :51:00.0 failed with error -22
>[17859.876566] vfio-pci: probe of :51:00.0 failed with error -22
>[17859.876622] vfio-pci: probe of :51:00.0 failed with error -22
>root@nat-kvm:/home/nat# cat /boot/config-$(uname -r) | grep NOIOMMU
>CONFIG_VFIO_NOIOMMU=y
>root@nat-kvm:/home/nat#
>Interface type :
>Other Network devices
>=
>:51:00.0 'Ethernet Controller X710 for 10GbE SFP+ 1572'
>unused=i40e,vfio-pci
>:51:00.1 'Ethernet Controller X710 for 10GbE SFP+ 1572'
>unused=i40e,vfio-pci
>:51:00.2 'Ethernet Controller X710 for 10GbE SFP+ 1572'
>unused=i40e,vfio-pci
>:51:00.3 'Ethernet Controller X710 for 10GbE SFP+ 1572'
>unused=i40e,vfio-pci
>:8a:00.0 'Ethernet Controller X710 for 10GbE SFP+ 1572'
>unused=i40e,vfio-pci
>:8a:00.1 'Ethernet Controller X710 for 10GbE SFP+ 1572'
>unused=i40e,vfio-pci
>:8a:00.2 'Ethernet Controller X710 for 10GbE SFP+ 1572'
>unused=i40e,vfio-pci
>:8a:00.3 'Ethernet Controller X710 for 10GbE SFP+ 1572'
>unused=i40e,vfio-pci
> 

Please try the following:

echo 1 > /sys/module/vfio/parameters/enable_unsafe_noiommu_mode
dpdk-devbind.py -b vfio-pci 8a:00.*

Does anything change then?

/Bruce

PS: For mailing list discussions, please don't top-post. Replies are easier
to follow if posted immediately below the relevant content.

>On Tue, Feb 21, 2023 at 9:37 PM Bruce Richardson
><[1]bruce.richard...@intel.com> wrote:
> 
>  On Tue, Feb 21, 2023 at 09:30:15PM +0530, Nagendra Prabhu A T wrote:
>  >HI Bruce,
>  >Thanks for your reply.
>  >I have removed the binding of all other ports. So , i can
>  confirm that
>  >#2 is taken care of.
>  >I tried using a different driver "uio_pci_generic". I still see
>  the
>  >same issue for that driver as well.
>  >The problem seems to be because the write operation is not
>  happening in
>  >"bind" file.
>  >Infact tried doing the following step manually. That also
>  failed
>  >echo sh -c :51:00.0 >
>  /sys/bus/pci/drivers/uio_pci_generic/bind
>  >bash: echo: write error: No such device
>  The "sh -c" doesn't look right in that command. It should just echo
>  the
>  device id to the bind file. However, it's generally recommended just
>  to use
>  the devbind script, as more writes to sysfs may be necessary first,
>  e.g. to
>  register the device ids first.
>  >I have required permission for the file.
>  >I tried doing with "sudo"
>  >I dont have selinux running
>  >So not sure whats blocking me. Infact , even
>  >"cat /sys/bus/pci/drivers/uio_pci_generic/bind" is failing
>  >Can you please help.
>  To track down issues other than the obvious, I think we need more
>  information. For example, what NIC card is this? Are there any
>  useful error
>  messages in dmesg?
>  /Bruce
> 
> References
> 
>1. mailto:bruce.richard...@intel.com

[PATCH v4] net/ark: support for single function with multiple port

[Ed Czeck]

Support the creation of multiple ports from one ark device via
the use of ark pmd extension, though the assignment of queues
to port.

Add unique dev_private data for each port.

This patch repairs a latent issue uncovered during testing.

Signed-off-by: Ed Czeck 
---
v3:
* Backport to LTS version is not recommended since firmware
  changes are required and limited
* remove unused num_queues field from struct ark_adapter
v4:
* additional comments
* separate patch from unrelated patch in series
---
 drivers/net/ark/ark_ethdev.c| 15 ++-
 drivers/net/ark/ark_ethdev_rx.c |  6 +++---
 drivers/net/ark/ark_ethdev_tx.c |  2 +-
 drivers/net/ark/ark_global.h|  3 +++
 4 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ark/ark_ethdev.c b/drivers/net/ark/ark_ethdev.c
index b2995427c8..24c1cb3932 100644
--- a/drivers/net/ark/ark_ethdev.c
+++ b/drivers/net/ark/ark_ethdev.c
@@ -300,6 +300,7 @@ eth_ark_dev_init(struct rte_eth_dev *dev)
int ret;
int port_count = 1;
int p;
+   uint16_t num_queues;
bool rqpacing = false;
 
ark->eth_dev = dev;
@@ -427,6 +428,7 @@ eth_ark_dev_init(struct rte_eth_dev *dev)
ark->user_ext.dev_get_port_count(dev,
 ark->user_data[dev->data->port_id]);
ark->num_ports = port_count;
+   num_queues = ark_api_num_queues_per_port(ark->mpurx.v, port_count);
 
for (p = 0; p < port_count; p++) {
struct rte_eth_dev *eth_dev;
@@ -452,7 +454,18 @@ eth_ark_dev_init(struct rte_eth_dev *dev)
}
 
eth_dev->device = &pci_dev->device;
-   eth_dev->data->dev_private = ark;
+   /* Device requires new dev_private data */
+   eth_dev->data->dev_private =
+   rte_zmalloc_socket(name,
+  sizeof(struct ark_adapter),
+  RTE_CACHE_LINE_SIZE,
+  rte_socket_id());
+
+   memcpy(eth_dev->data->dev_private, ark,
+  sizeof(struct ark_adapter));
+   ark = eth_dev->data->dev_private;
+   ark->qbase = p * num_queues;
+
eth_dev->dev_ops = ark->eth_dev->dev_ops;
eth_dev->tx_pkt_burst = ark->eth_dev->tx_pkt_burst;
eth_dev->rx_pkt_burst = ark->eth_dev->rx_pkt_burst;
diff --git a/drivers/net/ark/ark_ethdev_rx.c b/drivers/net/ark/ark_ethdev_rx.c
index cbc0416bc2..38bc69dff4 100644
--- a/drivers/net/ark/ark_ethdev_rx.c
+++ b/drivers/net/ark/ark_ethdev_rx.c
@@ -68,7 +68,7 @@ struct ark_rx_queue {
 static int
 eth_ark_rx_hw_setup(struct rte_eth_dev *dev,
struct ark_rx_queue *queue,
-   uint16_t rx_queue_id __rte_unused, uint16_t rx_queue_idx)
+   uint16_t rx_queue_idx)
 {
rte_iova_t queue_base;
rte_iova_t phys_addr_q_base;
@@ -124,7 +124,7 @@ eth_ark_dev_rx_queue_setup(struct rte_eth_dev *dev,
uint32_t i;
int status;
 
-   int qidx = queue_idx;
+   int qidx = ark->qbase + queue_idx;
 
/* We may already be setup, free memory prior to re-allocation */
if (dev->data->rx_queues[queue_idx] != NULL) {
@@ -215,7 +215,7 @@ eth_ark_dev_rx_queue_setup(struct rte_eth_dev *dev,
}
/* MPU Setup */
if (status == 0)
-   status = eth_ark_rx_hw_setup(dev, queue, qidx, queue_idx);
+   status = eth_ark_rx_hw_setup(dev, queue, queue_idx);
 
if (unlikely(status != 0)) {
struct rte_mbuf **mbuf;
diff --git a/drivers/net/ark/ark_ethdev_tx.c b/drivers/net/ark/ark_ethdev_tx.c
index 5940a592a2..4792754f19 100644
--- a/drivers/net/ark/ark_ethdev_tx.c
+++ b/drivers/net/ark/ark_ethdev_tx.c
@@ -229,7 +229,7 @@ eth_ark_tx_queue_setup(struct rte_eth_dev *dev,
struct ark_tx_queue *queue;
int status;
 
-   int qidx = queue_idx;
+   int qidx = ark->qbase + queue_idx;
 
if (!rte_is_power_of_2(nb_desc)) {
ARK_PMD_LOG(ERR,
diff --git a/drivers/net/ark/ark_global.h b/drivers/net/ark/ark_global.h
index 71d0b53e03..2f198edfe4 100644
--- a/drivers/net/ark/ark_global.h
+++ b/drivers/net/ark/ark_global.h
@@ -112,7 +112,10 @@ struct ark_adapter {
ark_pkt_chkr_t pc;
ark_pkt_dir_t pd;
 
+   /* For single function, multiple ports */
int num_ports;
+   uint16_t qbase;
+
bool isvf;
 
/* Packet generator/checker args */
-- 
2.34.1

RE: [EXT] Re: [PATCH v2] examples/ipsec-secgw: set AES-CTR IV length to 16

[Tejasree Kondoj]

Hi Radu,

Shall I change AES-128-CTR iv_len field in cipher_algos struct of sa.c from 8 
to 16 and
revert below change?

Thanks
Tejasree

> -Original Message-
> From: Nicolau, Radu 
> Sent: Wednesday, February 1, 2023 8:08 PM
> To: Akhil Goyal 
> Cc: Anoob Joseph ; dev@dpdk.org; Tejasree Kondoj
> 
> Subject: [EXT] Re: [PATCH v2] examples/ipsec-secgw: set AES-CTR IV length to
> 16
> 
> External Email
> 
> --
> Hi
> 
> On 2/1/2023 2:16 PM, Akhil Goyal wrote:
> > Hi Radu,
> >
> >> Subject: [PATCH v2] examples/ipsec-secgw: set AES-CTR IV length to 16
> >>
> >> Set AES-CTR IV length as 16 instead of taking from SA config option
> >> since the application populates 16B IV in the datapath. AES-CTR
> >> requires 16B IV constructed from nonce and counter.
> >>
> >> Signed-off-by: Tejasree Kondoj 
> > Do you have a comment on this?
> 
> No real objection, only that there is already an inconsistency in the
> definitions of the aes-xxx-ctr entries, 128 bit IV is 8 bytes, 192 and
> 256 are 16 bytes. Maybe it would be better to change the 128 bit variant
> definition? In any case:
> 
> Reviewed-by: Radu Nicolau 

Re: [PATCH v3 1/2] net/gve: fix Rx no mbufs stats counter update

[Levend Sayar]

Thanks Ferruh for the heads up.

It was a little confusion for me to decide what to do either. I will do as 
expected for future.
I did not want to overwrite any commit that is already acked.
So pushed new versions only for the ones needs recommits.

Levend 


> On 21 Feb 2023, at 18:58, Ferruh Yigit  wrote:
> 
> On 2/20/2023 9:11 PM, Levend Sayar wrote:
>> rx no_mbufs stats counter update is added for another error case.
>> 
>> Fixes: 4f6b1dd8240c ("net/gve: support basic statistics")
>> Cc: junfeng@intel.com
>> 
>> Signed-off-by: Levend Sayar 
> 
> Reviewed-by: Ferruh Yigit 
> 
> 
> (No problem for this time, but for future contributions, it is expected
> to have new versions as a whole patchset, otherwise that becomes too
> difficult to manage for maintainers to cherry pick various versions of
> individual patches in a set, specially on peak time of release.
> Also harder to backtrace from patchwork/list if someone wants the check
> the history.)
> 

Re: [PATCH v5] net/gve: add Rx/Tx queue stats as extended stats

[Levend Sayar]

Thanks Ferruh for the review.

> On 21 Feb 2023, at 18:58, Ferruh Yigit  wrote:
> 
> On 2/21/2023 2:18 PM, Levend Sayar wrote:
>> Google Virtual NIC rx/tx queue stats are added as extended stats.
>> 
>> Signed-off-by: Levend Sayar 
> 
> Reviewed-by: Ferruh Yigit 
> 
> <...>
> 
>> @@ -20,6 +20,7 @@ gve_rx_refill(struct gve_rx_queue *rxq)
>>  if (nb_alloc <= rxq->nb_avail) {
>>  diag = rte_pktmbuf_alloc_bulk(rxq->mpool, &rxq->sw_ring[idx], 
>> nb_alloc);
>>  if (diag < 0) {
>> +rxq->stats.no_mbufs_bulk++;
> 
> It is not common to record bulk alloc failures, but as 'no_mbufs'
> already recorded conventionally, I guess it is OK to keep this extra
> stat if it is helpful.
> 

[PATCH v4] hash: add XOR32 hash function

[Bili Dong]

An XOR32 hash is needed in the Software Switch (SWX) Pipeline for its
use case in P4. We implement it in this patch so it could be easily
registered in the pipeline later.

Signed-off-by: Bili Dong 
---
 .mailmap   |  1 +
 app/test/test_hash_functions.c | 33 +--
 lib/hash/rte_hash_xor.h| 76 ++
 3 files changed, 107 insertions(+), 3 deletions(-)
 create mode 100644 lib/hash/rte_hash_xor.h

diff --git a/.mailmap b/.mailmap
index 5015494210..176dd93b66 100644
--- a/.mailmap
+++ b/.mailmap
@@ -159,6 +159,7 @@ Bernard Iremonger 
 Bert van Leeuwen 
 Bhagyada Modali 
 Bharat Mota 
+Bili Dong 
 Bill Hong 
 Billy McFall 
 Billy O'Mahony 
diff --git a/app/test/test_hash_functions.c b/app/test/test_hash_functions.c
index 76d51b6e71..df8c14d7c5 100644
--- a/app/test/test_hash_functions.c
+++ b/app/test/test_hash_functions.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "test.h"
 
@@ -22,8 +23,8 @@
  * Hash values calculated for key sizes from array "hashtest_key_lens"
  * and for initial values from array "hashtest_initvals.
  * Each key will be formed by increasing each byte by 1:
- * e.g.: key size = 4, key = 0x03020100
- *   key size = 8, key = 0x0706050403020100
+ * e.g.: key size = 4, key = 0x00010203
+ *   key size = 8, key = 0x0001020304050607
  */
 static uint32_t hash_values_jhash[2][12] = {{
0x8ba9414b, 0xdf0d39c9,
@@ -51,6 +52,19 @@ static uint32_t hash_values_crc[2][12] = {{
0x789c104f, 0x53028d3e
 }
 };
+static uint32_t hash_values_xor[2][12] = {{
+   0x, 0x0001,
+   0x00010203, 0x04040404, 0x, 0x,
+   0x, 0x, 0x0c040404, 0x000d0e0f,
+   0x04212223, 0x04040404
+},
+{
+   0xdeadbeef, 0xdeacbeef,
+   0xdeacbcec, 0xdaa9baeb, 0xdeadbeef, 0xdeadbeef,
+   0xdeadbeef, 0xdeadbeef, 0xd2a9baeb, 0xdea0b0e0,
+   0xda8c9ccc, 0xdaa9baeb
+}
+};
 
 
/***
  * Hash function performance test configuration section. Each performance test
@@ -61,7 +75,7 @@ static uint32_t hash_values_crc[2][12] = {{
  */
 #define HASHTEST_ITERATIONS 100
 #define MAX_KEYSIZE 64
-static rte_hash_function hashtest_funcs[] = {rte_jhash, rte_hash_crc};
+static rte_hash_function hashtest_funcs[] = {rte_jhash, rte_hash_crc, 
rte_hash_xor32};
 static uint32_t hashtest_initvals[] = {0, 0xdeadbeef};
 static uint32_t hashtest_key_lens[] = {
1, 2, /* Unusual key sizes */
@@ -85,6 +99,9 @@ get_hash_name(rte_hash_function f)
if (f == rte_hash_crc)
return "rte_hash_crc";
 
+   if (f == rte_hash_xor32)
+   return "rte_hash_xor32";
+
return "UnknownHash";
 }
 
@@ -173,6 +190,16 @@ verify_precalculated_hash_func_tests(void)
   hash_values_crc[j][i], hash);
return -1;
}
+
+   hash = rte_hash_xor32(key, hashtest_key_lens[i],
+   hashtest_initvals[j]);
+   if (hash != hash_values_xor[j][i]) {
+   printf("XOR32 for %u bytes with initial value 
0x%x."
+  " Expected 0x%x, but got 0x%x\n",
+  hashtest_key_lens[i], 
hashtest_initvals[j],
+  hash_values_xor[j][i], hash);
+   return -1;
+   }
}
}
 
diff --git a/lib/hash/rte_hash_xor.h b/lib/hash/rte_hash_xor.h
new file mode 100644
index 00..0b5a7bef09
--- /dev/null
+++ b/lib/hash/rte_hash_xor.h
@@ -0,0 +1,76 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2023 Intel Corporation
+ */
+
+#ifndef _RTE_HASH_XOR_H_
+#define _RTE_HASH_XOR_H_
+
+/**
+ * @file
+ *
+ * RTE XOR Hash
+ */
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include 
+
+#include 
+
+/**
+ * Calculate XOR32 hash on user-supplied byte array.
+ *
+ * @param data
+ *   Data to perform hash on.
+ * @param data_len
+ *   How many bytes to use to calculate hash value.
+ * @param init_val
+ *   Value to initialise hash generator.
+ * @return
+ *   32bit calculated hash value.
+ */
+static inline uint32_t
+rte_hash_xor32(const void *data, uint32_t data_len, uint32_t init_val)
+{
+   /* Operate in big endian from here on. */
+   /* So we don't need to convert byte orders in the loop. */
+
+   uint64_t hash64 = rte_cpu_to_be_32(init_val);
+   const uint8_t *data8 = data;
+
+   uint32_t i;
+   for (i = 0; i < data_len / 8; i++) {
+   hash64 ^= *(const uint64_t *)data8;
+   data8 += 8;
+   }
+
+   if (data_len & 0x4) {
+   hash64 ^= *(const uint32_t *)data8;
+   data8 += 4;
+   }
+
+   /* Operate in host endian from here on. */
+   /* Becaus

Re: [PATCH 2/2] ethdev: fix race condition in fast-path ops setup

[Stephen Hemminger]

On Tue, 21 Feb 2023 07:24:19 +
Ruifeng Wang  wrote:

> > -Original Message-
> > From: fengchengwen 
> > Sent: Monday, February 20, 2023 2:58 PM
> > To: Ashok Kaladi ; jer...@marvell.com; 
> > tho...@monjalon.net
> > Cc: dev@dpdk.org; s.v.naga.haris...@intel.com; erik.g.carri...@intel.com;
> > abhinandan.guj...@intel.com; sta...@dpdk.org; Ruifeng Wang 
> > 
> > Subject: Re: [PATCH 2/2] ethdev: fix race condition in fast-path ops setup
> > 
> > On 2023/2/20 14:08, Ashok Kaladi wrote:  
> > > If ethdev enqueue or dequeue function is called during
> > > eth_dev_fp_ops_setup(), it may get pre-empted after setting the
> > > function pointers, but before setting the pointer to port data.
> > > In this case the newly registered enqueue/dequeue function will use
> > > dummy port data and end up in seg fault.
> > >
> > > This patch moves the updation of each data pointers before updating
> > > corresponding function pointers.
> > >
> > > Fixes: c87d435a4d79 ("ethdev: copy fast-path API into separate
> > > structure")
> > > Cc: sta...@dpdk.org

Why is something calling enqueue/dequeue when device is not fully started.
A correctly written application would not call rx/tx burst until after
ethdev start had finished.

Would something like this work better?

Note: there is another bug in current code. The check for link state interrupt
and link_ops could return -ENOTSUP and leave device in indeterminate state.
The check should be done before calling PMD.

diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index 0266cc82acb6..d6c163ed85e7 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -1582,6 +1582,14 @@ rte_eth_dev_start(uint16_t port_id)
return 0;
}
 
+   if (dev->data->dev_conf.intr_conf.lsc == 0 &&
+   dev->dev_ops->link_update == NULL) {
+   RTE_ETHDEV_LOG(INFO,
+  "Device with port_id=%"PRIu16" link update not 
supported\n",
+  port_id);
+   return -ENOTSUP;
+   }
+
ret = rte_eth_dev_info_get(port_id, &dev_info);
if (ret != 0)
return ret;
@@ -1591,9 +1599,7 @@ rte_eth_dev_start(uint16_t port_id)
eth_dev_mac_restore(dev, &dev_info);
 
diag = (*dev->dev_ops->dev_start)(dev);
-   if (diag == 0)
-   dev->data->dev_started = 1;
-   else
+   if (diag != 0)
return eth_err(port_id, diag);
 
ret = eth_dev_config_restore(dev, &dev_info, port_id);
@@ -1611,16 +1617,18 @@ rte_eth_dev_start(uint16_t port_id)
return ret;
}
 
-   if (dev->data->dev_conf.intr_conf.lsc == 0) {
-   if (*dev->dev_ops->link_update == NULL)
-   return -ENOTSUP;
-   (*dev->dev_ops->link_update)(dev, 0);
-   }
-
/* expose selection of PMD fast-path functions */
eth_dev_fp_ops_setup(rte_eth_fp_ops + port_id, dev);
 
+   /* ensure state is set before marking device ready */
+   rte_smp_wmb();
+
rte_ethdev_trace_start(port_id);
+
+   /* Update current link state */
+   if (dev->data->dev_conf.intr_conf.lsc == 0)
+   (*dev->dev_ops->link_update)(dev, 0);
+
return 0;
 }
 

Re: unable to bind to vfio-pci

[Stephen Hemminger]

On Tue, 21 Feb 2023 16:27:31 +
Bruce Richardson  wrote:

> On Tue, Feb 21, 2023 at 09:46:30PM +0530, Nagendra Prabhu A T wrote:
> >These are the messages i am seeing dmesg
> >[16588.298660] vfio-pci: probe of :8a:00.2 failed with error -22
> >[16591.574630] i40e :8a:00.3: i40e_ptp_stop: removed PHC on
> >enp138s0f3
> >[16593.138613] vfio-pci: probe of :8a:00.3 failed with error -22
> >[16593.138674] vfio-pci: probe of :8a:00.3 failed with error -22
> >[16627.551866] vfio-pci: probe of :51:00.0 failed with error -22
> >[16627.551922] vfio-pci: probe of :51:00.0 failed with error -22
> >[16716.344530] vfio-pci: probe of :51:00.0 failed with error -22
> >[16716.344585] vfio-pci: probe of :51:00.0 failed with error -22
> >[17859.876566] vfio-pci: probe of :51:00.0 failed with error -22
> >[17859.876622] vfio-pci: probe of :51:00.0 failed with error -22
> >root@nat-kvm:/home/nat# cat /boot/config-$(uname -r) | grep NOIOMMU
> >CONFIG_VFIO_NOIOMMU=y
> >root@nat-kvm:/home/nat#
> >Interface type :
> >Other Network devices
> >=
> >:51:00.0 'Ethernet Controller X710 for 10GbE SFP+ 1572'
> >unused=i40e,vfio-pci
> >:51:00.1 'Ethernet Controller X710 for 10GbE SFP+ 1572'
> >unused=i40e,vfio-pci
> >:51:00.2 'Ethernet Controller X710 for 10GbE SFP+ 1572'
> >unused=i40e,vfio-pci
> >:51:00.3 'Ethernet Controller X710 for 10GbE SFP+ 1572'
> >unused=i40e,vfio-pci
> >:8a:00.0 'Ethernet Controller X710 for 10GbE SFP+ 1572'
> >unused=i40e,vfio-pci
> >:8a:00.1 'Ethernet Controller X710 for 10GbE SFP+ 1572'
> >unused=i40e,vfio-pci
> >:8a:00.2 'Ethernet Controller X710 for 10GbE SFP+ 1572'
> >unused=i40e,vfio-pci
> >:8a:00.3 'Ethernet Controller X710 for 10GbE SFP+ 1572'
> >unused=i40e,vfio-pci
> >   
> 
> Please try the following:
> 
>   echo 1 > /sys/module/vfio/parameters/enable_unsafe_noiommu_mode
>   dpdk-devbind.py -b vfio-pci 8a:00.*
> 
> Does anything change then?
> 
> /Bruce
> 
> PS: For mailing list discussions, please don't top-post. Replies are easier
> to follow if posted immediately below the relevant content.
> 
> >On Tue, Feb 21, 2023 at 9:37 PM Bruce Richardson
> ><[1]bruce.richard...@intel.com> wrote:
> > 
> >  On Tue, Feb 21, 2023 at 09:30:15PM +0530, Nagendra Prabhu A T wrote:  
> >  >HI Bruce,
> >  >Thanks for your reply.
> >  >I have removed the binding of all other ports. So , i can  
> >  confirm that  
> >  >#2 is taken care of.
> >  >I tried using a different driver "uio_pci_generic". I still see  
> >  the  
> >  >same issue for that driver as well.
> >  >The problem seems to be because the write operation is not  
> >  happening in  
> >  >"bind" file.
> >  >Infact tried doing the following step manually. That also  
> >  failed  
> >  >echo sh -c :51:00.0 >  
> >  /sys/bus/pci/drivers/uio_pci_generic/bind  
> >  >bash: echo: write error: No such device  
> >  The "sh -c" doesn't look right in that command. It should just echo
> >  the
> >  device id to the bind file. However, it's generally recommended just
> >  to use
> >  the devbind script, as more writes to sysfs may be necessary first,
> >  e.g. to
> >  register the device ids first.  
> >  >I have required permission for the file.
> >  >I tried doing with "sudo"
> >  >I dont have selinux running
> >  >So not sure whats blocking me. Infact , even
> >  >"cat /sys/bus/pci/drivers/uio_pci_generic/bind" is failing
> >  >Can you please help.  
> >  To track down issues other than the obvious, I think we need more
> >  information. For example, what NIC card is this? Are there any
> >  useful error
> >  messages in dmesg?
> >  /Bruce
> > 
> > References
> > 
> >1. mailto:bruce.richard...@intel.com  

Another possibility is that the hardware shares IOMMU channels.
One machine I was using had multiple PCI devices sharing same IOMMU channel and 
kernel
would not let it work unless all of them were unbound from kernel.

Re: [PATCH v8 04/22] efd: replace RTE_LOGTYPE_EFD with dynamic type

[Stephen Hemminger]

On Tue, 21 Feb 2023 15:55:29 +0100
David Marchand  wrote:

> On Tue, Feb 21, 2023 at 12:36 AM Stephen Hemminger
>  wrote:
> >
> > Replace all uses of the global logtype with a dynamic log type.
> >
> > Signed-off-by: Stephen Hemminger 
> > ---
> >  lib/eal/common/eal_common_log.c | 1 -
> >  lib/eal/include/rte_log.h   | 2 +-
> >  lib/efd/rte_efd.c   | 4 
> >  3 files changed, 5 insertions(+), 2 deletions(-)  
> 
> [snip]
> 
> > diff --git a/lib/efd/rte_efd.c b/lib/efd/rte_efd.c
> > index 686a13775742..9edb11799c89 100644
> > --- a/lib/efd/rte_efd.c
> > +++ b/lib/efd/rte_efd.c
> > @@ -9,6 +9,7 @@
> >  #include 
> >  #include 
> >
> > +#include 
> >  #include 
> >  #include 
> >  #include   
> 
> This is unrelated, isn't it?

Not really, the old code worked only because it would get rte_cpuflags.h
included via rte_hash_crc.h.  When rte_hash_crc.h was fixed to not
do per-cpu setup in inline, then the cpu flags did not need to be
included there.

RE: [PATCH 1/2] net/mana: add version information for dependencies

[Long Li]

> Subject: Re: [PATCH 1/2] net/mana: add version information for dependencies
> 
> On 1/20/2023 2:19 AM, lon...@linuxonhyperv.com wrote:
> 
> > From: Long Li 
> >
> > The required dependencies for mana from rdma-core and Linux kernel
> > have been released. Add those information to the doc.
> >
> > Fixes: 517ed6e2d590 ("net/mana: add basic driver with build
> > environment")
> > Signed-off-by: Long Li 
> > ---
> >  doc/guides/nics/mana.rst | 8 +++-
> >  1 file changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/doc/guides/nics/mana.rst b/doc/guides/nics/mana.rst index
> > 005c0b2ca7..341146c4e7 100644
> > --- a/doc/guides/nics/mana.rst
> > +++ b/doc/guides/nics/mana.rst
> > @@ -29,6 +29,7 @@ and must be installed separately:
> >It allows slow and privileged operations
> >(context initialization, hardware resources allocations)
> >to be managed by the kernel and fast operations to never leave user 
> > space.
> > +  The minimum required rdma-core version is v44.
> >
> >In most cases, rdma-core is shipped as a package with an OS distribution.
> >User can also install the upstream version of the rdma-core from @@
> > -39,15 +40,14 @@ and must be installed separately:
> >Low-level user space driver library
> >for Microsoft Azure Network Adapter devices,
> >it is automatically loaded by libibverbs.
> > -
> > -  The support of MANA is not merged in rdma-core 42.
> > +  The minimum required version of rdma-core with libmana is v44.
> >
> >  - **Kernel modules**
> >
> >They provide the kernel-side verbs API and low level device drivers
> >that manage actual hardware initialization
> >and resources sharing with user space processes.
> > -  The minimum required Linux kernel version is 6.1.
> > +  The minimum required Linux kernel version is 6.2.
> >
> 
> Hi Long,
> 
> Linux 6.2 seems release, can you please confirm required dependency is part
> of 6.2 release.

Hi Ferruh,

I can confirm the required dependency is in Linux 6.2.

Thanks,
Long

> 
> >Unlike most other PMDs, these modules must remain loaded
> >and bound to their devices:
> > @@ -56,8 +56,6 @@ and must be installed separately:
> >- mana_ib: InifiniBand device driver.
> >- ib_uverbs: user space driver for verbs (entry point for libibverbs).
> >
> > -  The support of MANA is planned in Linux 6.2.
> > -
> >  Driver compilation and testing
> >  --
> >
> > --
> > 2.17.1
> >

[PATCH] config: added support for NVIDIA ARM implementer ID

[cburdick]

From: Cliff Burdick 

NVIDIA's Jetson Xavier is an ARM chip with NVIDIA as the implementer ID
and a new part number. This patch adds support for this implementer ID
and the part number.

Signed-off-by: Cliff Burdick 
---
 .mailmap   |  1 +
 config/arm/meson.build | 21 +
 2 files changed, 22 insertions(+)

diff --git a/.mailmap b/.mailmap
index 6a91c11be4..2cb0d9e41b 100644
--- a/.mailmap
+++ b/.mailmap
@@ -230,6 +230,7 @@ Cian Ferriter 
 Ciara Loftus 
 Ciara Power 
 Claire Murphy 
+Cliff Burdick 
 Cody Doucette 
 Congwen Zhang 
 Conor Fogarty 
diff --git a/config/arm/meson.build b/config/arm/meson.build
index 6442ec9596..6c3de22f16 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -159,6 +159,26 @@ implementer_cavium = {
 }
 }
 
+implementer_nvidia = {
+'description': 'NVIDIA',
+'flags': [
+['RTE_CACHE_LINE_SIZE', 64]
+],
+'part_number_config': {
+'0x4': {
+'march': 'armv8-a',
+'march_features': ['crc', 'crypto', 'lse'],
+'compiler_options': ['-march=armv8-a+crc+lse+simd'],
+'flags': [
+['RTE_USE_C11_MEM_MODEL', true],
+['RTE_MAX_LCORE', 8],
+['RTE_MAX_NUMA_NODES', 1],
+['RTE_MACHINE', '"armv8a"']
+]
+}
+}
+}
+
 implementer_ampere = {
 'description': 'Ampere Computing',
 'flags': [
@@ -261,6 +281,7 @@ implementers = {
 '0x41': implementer_arm,
 '0x43': implementer_cavium,
 '0x48': implementer_hisilicon,
+'0x4e': implementer_nvidia,
 '0x50': implementer_ampere,
 '0x51': implementer_qualcomm,
 '0x70': implementer_phytium,
-- 
2.17.1

[PATCH] config: added support for NVIDIA ARM implementer ID

[cburdick]

From: Cliff Burdick 

NVIDIA's Jetson Xavier is an ARM chip with NVIDIA as the implementer ID
and a new part number. This patch adds support for this implementer ID
and the part number.

Signed-off-by: Cliff Burdick 
---
 .mailmap   |  1 +
 config/arm/meson.build | 21 +
 2 files changed, 22 insertions(+)

diff --git a/.mailmap b/.mailmap
index 6a91c11be4..2cb0d9e41b 100644
--- a/.mailmap
+++ b/.mailmap
@@ -230,6 +230,7 @@ Cian Ferriter 
 Ciara Loftus 
 Ciara Power 
 Claire Murphy 
+Cliff Burdick 
 Cody Doucette 
 Congwen Zhang 
 Conor Fogarty 
diff --git a/config/arm/meson.build b/config/arm/meson.build
index 6442ec9596..6c3de22f16 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -159,6 +159,26 @@ implementer_cavium = {
 }
 }
 
+implementer_nvidia = {
+'description': 'NVIDIA',
+'flags': [
+['RTE_CACHE_LINE_SIZE', 64]
+],
+'part_number_config': {
+'0x4': {
+'march': 'armv8-a',
+'march_features': ['crc', 'crypto', 'lse'],
+'compiler_options': ['-march=armv8-a+crc+lse+simd'],
+'flags': [
+['RTE_USE_C11_MEM_MODEL', true],
+['RTE_MAX_LCORE', 8],
+['RTE_MAX_NUMA_NODES', 1],
+['RTE_MACHINE', '"armv8a"']
+]
+}
+}
+}
+
 implementer_ampere = {
 'description': 'Ampere Computing',
 'flags': [
@@ -261,6 +281,7 @@ implementers = {
 '0x41': implementer_arm,
 '0x43': implementer_cavium,
 '0x48': implementer_hisilicon,
+'0x4e': implementer_nvidia,
 '0x50': implementer_ampere,
 '0x51': implementer_qualcomm,
 '0x70': implementer_phytium,
-- 
2.17.1

[PATCH v5] hash: add XOR32 hash function

[Bili Dong]

An XOR32 hash is needed in the Software Switch (SWX) Pipeline for its
use case in P4. We implement it in this patch so it could be easily
registered in the pipeline later.

Signed-off-by: Bili Dong 
---
 .mailmap   |  1 +
 app/test/test_hash_functions.c | 33 +--
 lib/hash/rte_hash_xor.h| 76 ++
 3 files changed, 107 insertions(+), 3 deletions(-)
 create mode 100644 lib/hash/rte_hash_xor.h

diff --git a/.mailmap b/.mailmap
index a9f4f28fba..3e9bec29d5 100644
--- a/.mailmap
+++ b/.mailmap
@@ -159,6 +159,7 @@ Bernard Iremonger 
 Bert van Leeuwen 
 Bhagyada Modali 
 Bharat Mota 
+Bili Dong 
 Bill Hong 
 Billy McFall 
 Billy O'Mahony 
diff --git a/app/test/test_hash_functions.c b/app/test/test_hash_functions.c
index 76d51b6e71..53e296fec4 100644
--- a/app/test/test_hash_functions.c
+++ b/app/test/test_hash_functions.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "test.h"
 
@@ -22,8 +23,8 @@
  * Hash values calculated for key sizes from array "hashtest_key_lens"
  * and for initial values from array "hashtest_initvals.
  * Each key will be formed by increasing each byte by 1:
- * e.g.: key size = 4, key = 0x03020100
- *   key size = 8, key = 0x0706050403020100
+ * e.g.: key size = 4, key = 0x00010203
+ *   key size = 8, key = 0x0001020304050607
  */
 static uint32_t hash_values_jhash[2][12] = {{
0x8ba9414b, 0xdf0d39c9,
@@ -51,6 +52,19 @@ static uint32_t hash_values_crc[2][12] = {{
0x789c104f, 0x53028d3e
 }
 };
+static uint32_t hash_values_xor32[2][12] = {{
+   0x, 0x0001,
+   0x00010203, 0x04040404, 0x, 0x,
+   0x, 0x, 0x0c040404, 0x000d0e0f,
+   0x04212223, 0x04040404
+},
+{
+   0xdeadbeef, 0xdeacbeef,
+   0xdeacbcec, 0xdaa9baeb, 0xdeadbeef, 0xdeadbeef,
+   0xdeadbeef, 0xdeadbeef, 0xd2a9baeb, 0xdea0b0e0,
+   0xda8c9ccc, 0xdaa9baeb
+}
+};
 
 
/***
  * Hash function performance test configuration section. Each performance test
@@ -61,7 +75,7 @@ static uint32_t hash_values_crc[2][12] = {{
  */
 #define HASHTEST_ITERATIONS 100
 #define MAX_KEYSIZE 64
-static rte_hash_function hashtest_funcs[] = {rte_jhash, rte_hash_crc};
+static rte_hash_function hashtest_funcs[] = {rte_jhash, rte_hash_crc, 
rte_hash_xor32};
 static uint32_t hashtest_initvals[] = {0, 0xdeadbeef};
 static uint32_t hashtest_key_lens[] = {
1, 2, /* Unusual key sizes */
@@ -85,6 +99,9 @@ get_hash_name(rte_hash_function f)
if (f == rte_hash_crc)
return "rte_hash_crc";
 
+   if (f == rte_hash_xor32)
+   return "rte_hash_xor32";
+
return "UnknownHash";
 }
 
@@ -173,6 +190,16 @@ verify_precalculated_hash_func_tests(void)
   hash_values_crc[j][i], hash);
return -1;
}
+
+   hash = rte_hash_xor32(key, hashtest_key_lens[i],
+   hashtest_initvals[j]);
+   if (hash != hash_values_xor32[j][i]) {
+   printf("XOR32 for %u bytes with initial value 
0x%x."
+  " Expected 0x%x, but got 0x%x\n",
+  hashtest_key_lens[i], 
hashtest_initvals[j],
+  hash_values_xor32[j][i], hash);
+   return -1;
+   }
}
}
 
diff --git a/lib/hash/rte_hash_xor.h b/lib/hash/rte_hash_xor.h
new file mode 100644
index 00..0b5a7bef09
--- /dev/null
+++ b/lib/hash/rte_hash_xor.h
@@ -0,0 +1,76 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2023 Intel Corporation
+ */
+
+#ifndef _RTE_HASH_XOR_H_
+#define _RTE_HASH_XOR_H_
+
+/**
+ * @file
+ *
+ * RTE XOR Hash
+ */
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include 
+
+#include 
+
+/**
+ * Calculate XOR32 hash on user-supplied byte array.
+ *
+ * @param data
+ *   Data to perform hash on.
+ * @param data_len
+ *   How many bytes to use to calculate hash value.
+ * @param init_val
+ *   Value to initialise hash generator.
+ * @return
+ *   32bit calculated hash value.
+ */
+static inline uint32_t
+rte_hash_xor32(const void *data, uint32_t data_len, uint32_t init_val)
+{
+   /* Operate in big endian from here on. */
+   /* So we don't need to convert byte orders in the loop. */
+
+   uint64_t hash64 = rte_cpu_to_be_32(init_val);
+   const uint8_t *data8 = data;
+
+   uint32_t i;
+   for (i = 0; i < data_len / 8; i++) {
+   hash64 ^= *(const uint64_t *)data8;
+   data8 += 8;
+   }
+
+   if (data_len & 0x4) {
+   hash64 ^= *(const uint32_t *)data8;
+   data8 += 4;
+   }
+
+   /* Operate in host endian from here on. */
+   /* 

Re: [PATCH v6 0/5] Replace use of RTE_LOGTYPE_USER1 in libraries

[Stephen Hemminger]

On Tue, 21 Feb 2023 11:42:45 +0100
David Marchand  wrote:

> On Mon, Feb 20, 2023 at 7:50 PM Stephen Hemminger
>  wrote:
> >
> > The DPDK libraries and drivers should not be using the USER1 logtype.
> >
> > v6 - fix checkpatch warnings
> >
> > Stephen Hemminger (5):
> >   ip_frag: use a dynamic logtype
> >   reorder: use a dynamic logtype
> >   latencystats: use dynamic logtype
> >   vhost: use logtype instead of RTE_LOGTYPE_USER1
> >   ipsec: fix usage of RTE_LOGTYPE_USER1
> >
> >  drivers/crypto/ipsec_mb/ipsec_mb_ops.c | 3 ++-
> >  lib/ip_frag/ip_frag_common.h   | 5 -
> >  lib/ip_frag/rte_ip_frag_common.c   | 2 ++
> >  lib/latencystats/rte_latencystats.c| 3 ++-
> >  lib/reorder/rte_reorder.c  | 6 +++---
> >  lib/vhost/fd_man.c | 4 ++--
> >  lib/vhost/vhost_crypto.c   | 4 
> >  7 files changed, 19 insertions(+), 8 deletions(-)  
> 
> Could you update the power library too?
> 
> lib/power/guest_channel.c:#define RTE_LOGTYPE_GUEST_CHANNEL RTE_LOGTYPE_USER1

I picked that up in the other patch set because lib/power should be using
its own logtype.

[PATCH v7 0/5] Convert us of RTE_LOGTYPE_USER1 in libraries

[Stephen Hemminger]

The DPDK libraries and drivers should not be using the USER1 logtype.

v7 - fix review comments. Replace USER1 in ip_frag and vhost crypto.

Stephen Hemminger (5):
  ip_frag: use a dynamic logtype
  reorder: use a dynamic logtype
  latencystats: use dynamic logtype
  vhost: use logtype instead of RTE_LOGTYPE_USER1
  ipsec: fix usage of RTE_LOGTYPE_USER1

 drivers/crypto/ipsec_mb/ipsec_mb_ops.c |  3 ++-
 lib/ip_frag/ip_frag_common.h   |  5 -
 lib/ip_frag/rte_ip_frag_common.c   |  8 +---
 lib/latencystats/rte_latencystats.c|  3 ++-
 lib/reorder/rte_reorder.c  |  6 +++---
 lib/vhost/fd_man.c |  4 ++--
 lib/vhost/vhost_crypto.c   | 22 +++---
 7 files changed, 29 insertions(+), 22 deletions(-)

-- 
2.39.1

[PATCH v7 1/5] ip_frag: use a dynamic logtype

[Stephen Hemminger]

DPDK libraries should not be reusing RTE_LOGTYPE_USER1 in
lieu of doing proper logtype registration.

Acked-by: Konstantin Ananyev 
Fixes: 416707812c03 ("ip_frag: refactor reassembly code into a proper library")
Signed-off-by: Stephen Hemminger 
---
 lib/ip_frag/ip_frag_common.h | 5 -
 lib/ip_frag/rte_ip_frag_common.c | 8 +---
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/lib/ip_frag/ip_frag_common.h b/lib/ip_frag/ip_frag_common.h
index 9c0dbdeb6eb9..95f1689d476d 100644
--- a/lib/ip_frag/ip_frag_common.h
+++ b/lib/ip_frag/ip_frag_common.h
@@ -8,9 +8,12 @@
 #include "rte_ip_frag.h"
 #include "ip_reassembly.h"
 
+extern int ipfrag_logtype;
+#define RTE_LOGTYPE_IPFRAG ipfrag_logtype
+
 /* logging macros. */
 #ifdef RTE_LIBRTE_IP_FRAG_DEBUG
-#defineIP_FRAG_LOG(lvl, fmt, args...)  RTE_LOG(lvl, USER1, fmt, ##args)
+#defineIP_FRAG_LOG(lvl, fmt, args...)  RTE_LOG(lvl, IPFRAG, fmt, 
##args)
 #else
 #defineIP_FRAG_LOG(lvl, fmt, args...)  do {} while(0)
 #endif /* IP_FRAG_DEBUG */
diff --git a/lib/ip_frag/rte_ip_frag_common.c b/lib/ip_frag/rte_ip_frag_common.c
index c1de2e81b6d0..eed399da6bc5 100644
--- a/lib/ip_frag/rte_ip_frag_common.c
+++ b/lib/ip_frag/rte_ip_frag_common.c
@@ -7,6 +7,8 @@
 
 #include 
 
+RTE_LOG_REGISTER_DEFAULT(ipfrag_logtype, INFO);
+
 #include "ip_frag_common.h"
 
 #defineIP_FRAG_HASH_FNUM   2
@@ -52,20 +54,20 @@ rte_ip_frag_table_create(uint32_t bucket_num, uint32_t 
bucket_entries,
if (rte_is_power_of_2(bucket_entries) == 0 ||
nb_entries > UINT32_MAX || nb_entries == 0 ||
nb_entries < max_entries) {
-   RTE_LOG(ERR, USER1, "%s: invalid input parameter\n", __func__);
+   RTE_LOG(ERR, IPFRAG, "%s: invalid input parameter\n", __func__);
return NULL;
}
 
sz = sizeof (*tbl) + nb_entries * sizeof (tbl->pkt[0]);
if ((tbl = rte_zmalloc_socket(__func__, sz, RTE_CACHE_LINE_SIZE,
socket_id)) == NULL) {
-   RTE_LOG(ERR, USER1,
+   RTE_LOG(ERR, IPFRAG,
"%s: allocation of %zu bytes at socket %d failed do\n",
__func__, sz, socket_id);
return NULL;
}
 
-   RTE_LOG(INFO, USER1, "%s: allocated of %zu bytes at socket %d\n",
+   RTE_LOG(INFO, IPFRAG, "%s: allocated of %zu bytes at socket %d\n",
__func__, sz, socket_id);
 
tbl->max_cycles = max_cycles;
-- 
2.39.1

[PATCH v7 2/5] reorder: use a dynamic logtype

[Stephen Hemminger]

Libraries should not be reusing RTE_LOGTYPE_USER1 instead
of doing proper logtype registration.

Fixes: b70b56032bff ("reorder: new library")
Cc: sergio.gonzalez.mon...@intel.com
Signed-off-by: Stephen Hemminger 
---
 lib/reorder/rte_reorder.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/reorder/rte_reorder.c b/lib/reorder/rte_reorder.c
index 6e029c9e02fd..7a3a97972cb7 100644
--- a/lib/reorder/rte_reorder.c
+++ b/lib/reorder/rte_reorder.c
@@ -15,6 +15,9 @@
 
 #include "rte_reorder.h"
 
+RTE_LOG_REGISTER_DEFAULT(reorder_logtype, INFO);
+#define RTE_LOGTYPE_REORDER reorder_logtype
+
 TAILQ_HEAD(rte_reorder_list, rte_tailq_entry);
 
 static struct rte_tailq_elem rte_reorder_tailq = {
@@ -26,9 +29,6 @@ EAL_REGISTER_TAILQ(rte_reorder_tailq)
 #define RTE_REORDER_PREFIX "RO_"
 #define RTE_REORDER_NAMESIZE 32
 
-/* Macros for printing using RTE_LOG */
-#define RTE_LOGTYPE_REORDERRTE_LOGTYPE_USER1
-
 #define RTE_REORDER_SEQN_DYNFIELD_NAME "rte_reorder_seqn_dynfield"
 int rte_reorder_seqn_dynfield_offset = -1;
 
-- 
2.39.1

[PATCH v7 3/5] latencystats: use dynamic logtype

[Stephen Hemminger]

Libraries should not reuse RTE_LOGTYPE_USER1 for their
logging. Instead they should register their own type.

Fixes: 5cd3cac9ed22 ("latency: added new library for latency stats")
Cc: reshma.pat...@intel.com
Signed-off-by: Stephen Hemminger 
---
 lib/latencystats/rte_latencystats.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/latencystats/rte_latencystats.c 
b/lib/latencystats/rte_latencystats.c
index 8985a377db4e..f3c1746cca00 100644
--- a/lib/latencystats/rte_latencystats.c
+++ b/lib/latencystats/rte_latencystats.c
@@ -26,7 +26,8 @@ latencystat_cycles_per_ns(void)
 }
 
 /* Macros for printing using RTE_LOG */
-#define RTE_LOGTYPE_LATENCY_STATS RTE_LOGTYPE_USER1
+RTE_LOG_REGISTER_DEFAULT(latencystat_logtype, INFO);
+#define RTE_LOGTYPE_LATENCY_STATS latencystat_logtype
 
 static uint64_t timestamp_dynflag;
 static int timestamp_dynfield_offset = -1;
-- 
2.39.1

[PATCH v7 4/5] vhost: use logtype instead of RTE_LOGTYPE_USER1

[Stephen Hemminger]

Fix instances of USER1 logtype in fdset and crypto
sections.

Acked-by: Chenbo Xia 
Reviewed-by: Maxime Coquelin 
Signed-off-by: Stephen Hemminger 
---
 lib/vhost/fd_man.c   |  4 ++--
 lib/vhost/vhost_crypto.c | 22 +++---
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/lib/vhost/fd_man.c b/lib/vhost/fd_man.c
index 1876fada3354..46037d02784e 100644
--- a/lib/vhost/fd_man.c
+++ b/lib/vhost/fd_man.c
@@ -10,8 +10,8 @@
 
 #include "fd_man.h"
 
-
-#define RTE_LOGTYPE_VHOST_FDMAN RTE_LOGTYPE_USER1
+RTE_LOG_REGISTER_SUFFIX(vhost_fdset_logtype, fdset, INFO);
+#define RTE_LOGTYPE_VHOST_FDMAN vhost_fdset_logtype
 
 #define FDPOLLERR (POLLERR | POLLHUP | POLLNVAL)
 
diff --git a/lib/vhost/vhost_crypto.c b/lib/vhost/vhost_crypto.c
index f02bf865c349..fa49ffa07099 100644
--- a/lib/vhost/vhost_crypto.c
+++ b/lib/vhost/vhost_crypto.c
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -16,22 +17,21 @@
 #define IV_OFFSET  (sizeof(struct rte_crypto_op) + \
sizeof(struct rte_crypto_sym_op))
 
-#ifdef RTE_LIBRTE_VHOST_DEBUG
+RTE_LOG_REGISTER_SUFFIX(vhost_crypto_logtype, crypto, INFO);
+#define RTE_LOGTYPE_VHOST_CRYPTO   vhost_crypto_logtype
+
 #define VC_LOG_ERR(fmt, args...)   \
-   RTE_LOG(ERR, USER1, "[%s] %s() line %u: " fmt "\n", \
-   "Vhost-Crypto", __func__, __LINE__, ## args)
+   RTE_LOG(ERR, VHOST_CRYPTO, "%s() line %u: " fmt "\n",   \
+   __func__, __LINE__, ## args)
 #define VC_LOG_INFO(fmt, args...)  \
-   RTE_LOG(INFO, USER1, "[%s] %s() line %u: " fmt "\n",\
-   "Vhost-Crypto", __func__, __LINE__, ## args)
+   RTE_LOG(INFO, VHOST_CRYPTO, "%s() line %u: " fmt "\n",  \
+   __func__, __LINE__, ## args)
 
+#ifdef RTE_LIBRTE_VHOST_DEBUG
 #define VC_LOG_DBG(fmt, args...)   \
-   RTE_LOG(DEBUG, USER1, "[%s] %s() line %u: " fmt "\n",   \
-   "Vhost-Crypto", __func__, __LINE__, ## args)
+   RTE_LOG(DEBUG, VHOST_CRYPTO, "%s() line %u: " fmt "\n", \
+   __func__, __LINE__, ## args)
 #else
-#define VC_LOG_ERR(fmt, args...)   \
-   RTE_LOG(ERR, USER1, "[VHOST-Crypto]: " fmt "\n", ## args)
-#define VC_LOG_INFO(fmt, args...)  \
-   RTE_LOG(INFO, USER1, "[VHOST-Crypto]: " fmt "\n", ## args)
 #define VC_LOG_DBG(fmt, args...)
 #endif
 
-- 
2.39.1

[PATCH v7 5/5] ipsec: fix usage of RTE_LOGTYPE_USER1

[Stephen Hemminger]

There already is a logtype in this driver, use it!

Fixes: b35848bc01f6 ("crypto/ipsec_mb: add multi-process IPC request handler")
Cc: kai...@intel.com
Signed-off-by: Stephen Hemminger 
---
 drivers/crypto/ipsec_mb/ipsec_mb_ops.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/crypto/ipsec_mb/ipsec_mb_ops.c 
b/drivers/crypto/ipsec_mb/ipsec_mb_ops.c
index 3e52f9567401..e9eb0d15b794 100644
--- a/drivers/crypto/ipsec_mb/ipsec_mb_ops.c
+++ b/drivers/crypto/ipsec_mb/ipsec_mb_ops.c
@@ -7,6 +7,7 @@
 
 #include 
 #include 
+#include 
 
 #include "ipsec_mb_private.h"
 
@@ -125,7 +126,7 @@ ipsec_mb_secondary_qp_op(int dev_id, int qp_id,
qp_req_msg.num_fds = 0;
ret = rte_mp_request_sync(&qp_req_msg, &qp_resp, &ts);
if (ret) {
-   RTE_LOG(ERR, USER1, "Create MR request to primary process 
failed.");
+   IPSEC_MB_LOG(ERR, "Create MR request to primary process 
failed.");
return -1;
}
qp_resp_msg = &qp_resp.msgs[0];
-- 
2.39.1

[PATCH v9 00/22] Convert static logtypes in libraries

[Stephen Hemminger]

This patchset removes the main uses of static LOGTYPE's in DPDK
libraries. It starts with the easy one and goes on to the more complex ones.

There are several options on how to treat the old static types:
leave them there, mark as deprecated, or remove them.
This version removes them since there is no guarantee in current
DPDK policies that says they can't be removed.

Note: there is one patch in this series that will get
flagged incorrectly as an ABI change.

v9 - fix handling of crc32 alg in lib/hash.
 make it an internal global variable.
 fix gfni stubs for case where they are not used.

Stephen Hemminger (22):
  gso: don't log message on non TCP/UDP
  eal: drop no longer used GSO logtype
  log: drop unused RTE_LOGTYPE_TIMER
  efd: replace RTE_LOGTYPE_EFD with dynamic type
  mbuf: replace RTE_LOGTYPE_MBUF with dynamic type
  acl: replace LOGTYPE_ACL with dynamic type
  examples/power: replace use of RTE_LOGTYPE_POWER
  examples/l3fwd-power: replace use of RTE_LOGTYPE_POWER
  power: replace RTE_LOGTYPE_POWER with dynamic type
  ring: replace RTE_LOGTYPE_RING with dynamic type
  mempool: replace RTE_LOGTYPE_MEMPOOL with dynamic type
  lpm: replace RTE_LOGTYPE_LPM with dynamic types
  kni: replace RTE_LOGTYPE_KNI with dynamic type
  sched: replace RTE_LOGTYPE_SCHED with dynamic type
  examples/ipsecgw: replace RTE_LOGTYPE_PORT
  port: replace RTE_LOGTYPE_PORT with dynamic type
  table: convert RTE_LOGTYPE_TABLE to dynamic logtype
  app/test: remove use of RTE_LOGTYPE_PIPELINE
  pipeline: replace RTE_LOGTYPE_PIPELINE with dynamic type
  hash: move rte_thash_gfni stubs out of header file
  hash: move rte_hash_set_alg out header
  hash: convert RTE_LOGTYPE_HASH to dynamic type

 app/test/test_acl.c   |  3 +-
 app/test/test_table_acl.c | 50 +++
 app/test/test_table_pipeline.c| 40 +-
 examples/distributor/main.c   |  2 +-
 examples/ipsec-secgw/sa.c |  6 +--
 examples/l3fwd-power/main.c   | 15 +++
 lib/acl/acl_bld.c |  1 +
 lib/acl/acl_gen.c |  1 +
 lib/acl/acl_log.h |  4 ++
 lib/acl/rte_acl.c |  4 ++
 lib/acl/tb_mem.c  |  3 +-
 lib/eal/common/eal_common_log.c   | 17 
 lib/eal/include/rte_log.h | 34 
 lib/efd/rte_efd.c |  4 ++
 lib/fib/fib_log.h |  4 ++
 lib/fib/rte_fib.c |  3 ++
 lib/fib/rte_fib6.c|  2 +
 lib/gso/rte_gso.c |  5 +--
 lib/gso/rte_gso.h |  1 +
 lib/hash/meson.build  |  9 +++-
 lib/hash/rte_crc_arm64.h  |  8 ++--
 lib/hash/rte_crc_x86.h| 10 ++---
 lib/hash/rte_cuckoo_hash.c|  5 +++
 lib/hash/rte_fbk_hash.c   |  5 +++
 lib/hash/rte_hash_crc.c   | 68 +++
 lib/hash/rte_hash_crc.h   | 48 ++
 lib/hash/rte_thash.c  |  3 ++
 lib/hash/rte_thash_gfni.c | 50 +++
 lib/hash/rte_thash_gfni.h | 28 +++--
 lib/hash/version.map  | 11 +
 lib/kni/rte_kni.c |  3 ++
 lib/lpm/lpm_log.h |  4 ++
 lib/lpm/rte_lpm.c |  3 ++
 lib/lpm/rte_lpm6.c|  1 +
 lib/mbuf/mbuf_log.h   |  4 ++
 lib/mbuf/rte_mbuf.c   |  4 ++
 lib/mbuf/rte_mbuf_dyn.c   |  2 +
 lib/mbuf/rte_mbuf_pool_ops.c  |  2 +
 lib/mempool/rte_mempool.c |  2 +
 lib/mempool/rte_mempool.h |  8 
 lib/mempool/version.map   |  3 ++
 lib/pipeline/rte_pipeline.c   |  3 ++
 lib/port/rte_port_ethdev.c|  3 ++
 lib/port/rte_port_eventdev.c  |  4 ++
 lib/port/rte_port_fd.c|  3 ++
 lib/port/rte_port_frag.c  |  3 ++
 lib/port/rte_port_kni.c   |  3 ++
 lib/port/rte_port_ras.c   |  3 ++
 lib/port/rte_port_ring.c  |  3 ++
 lib/port/rte_port_sched.c |  3 ++
 lib/port/rte_port_source_sink.c   |  3 ++
 lib/port/rte_port_sym_crypto.c|  3 ++
 lib/power/guest_channel.c |  3 +-
 lib/power/power_common.c  |  2 +
 lib/power/power_common.h  |  3 +-
 lib/power/power_kvm_vm.c  |  1 +
 lib/power/rte_power.c |  1 +
 lib/rib/rib_log.h |  4 ++
 lib/rib/rte_rib.c |  3 ++
 lib/rib/rte_rib6.c|  3 ++
 lib/ring/rte_ring.c   |  3 ++
 lib/sched/rte_pie.c   |  1 +
 lib/sched/rte_sched.c |  5 +++
 lib/sched/rte_sched_log.h |  4 ++
 lib/table/rte_table_acl.c |  3 ++
 lib/table/rte_table_array.c   |  3 ++
 lib/table/rte_table_hash_cuckoo.c |  3 ++
 lib/table/rte_table_hash_ext.c|  3 ++
 lib/table/rte_table_hash_key16.c  |  3 ++
 lib/table/rte_table_hash_key32.c  |  5 ++-
 lib/table/rte_table_hash_key8.c   |  5 ++-
 lib/table/rte_table_hash_lru.c|  3 ++
 lib/table/rte_table_lpm.c |  3 

[PATCH v9 02/22] eal: drop no longer used GSO logtype

[Stephen Hemminger]

The message that used this was replaced in previous patch.

Signed-off-by: Stephen Hemminger 
---
 lib/eal/common/eal_common_log.c | 1 -
 lib/eal/include/rte_log.h   | 2 +-
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/lib/eal/common/eal_common_log.c b/lib/eal/common/eal_common_log.c
index bd7b188ceb4a..894701e8c19c 100644
--- a/lib/eal/common/eal_common_log.c
+++ b/lib/eal/common/eal_common_log.c
@@ -368,7 +368,6 @@ static const struct logtype logtype_strings[] = {
{RTE_LOGTYPE_CRYPTODEV,  "lib.cryptodev"},
{RTE_LOGTYPE_EFD,"lib.efd"},
{RTE_LOGTYPE_EVENTDEV,   "lib.eventdev"},
-   {RTE_LOGTYPE_GSO,"lib.gso"},
{RTE_LOGTYPE_USER1,  "user1"},
{RTE_LOGTYPE_USER2,  "user2"},
{RTE_LOGTYPE_USER3,  "user3"},
diff --git a/lib/eal/include/rte_log.h b/lib/eal/include/rte_log.h
index 6d2b0856a565..11d517806054 100644
--- a/lib/eal/include/rte_log.h
+++ b/lib/eal/include/rte_log.h
@@ -46,7 +46,7 @@ extern "C" {
 #define RTE_LOGTYPE_CRYPTODEV 17 /**< Log related to cryptodev. */
 #define RTE_LOGTYPE_EFD   18 /**< Log related to EFD. */
 #define RTE_LOGTYPE_EVENTDEV  19 /**< Log related to eventdev. */
-#define RTE_LOGTYPE_GSO   20 /**< Log related to GSO. */
+/* was RTE_LOGTYPE_GSO */
 
 /* these log types can be used in an application */
 #define RTE_LOGTYPE_USER1 24 /**< User-defined log type 1. */
-- 
2.39.1

[PATCH v9 01/22] gso: don't log message on non TCP/UDP

[Stephen Hemminger]

If a large packet is passed into GSO routines of unknown protocol
then library would log a message.
Better to tell the application instead of logging.

Fixes: 119583797b6a ("gso: support TCP/IPv4 GSO")
Reviewed-by: Jiayu Hu 
Signed-off-by: Stephen Hemminger 
---
 lib/gso/rte_gso.c | 5 ++---
 lib/gso/rte_gso.h | 1 +
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/gso/rte_gso.c b/lib/gso/rte_gso.c
index 4b59217c16ee..c8e67c2d4b48 100644
--- a/lib/gso/rte_gso.c
+++ b/lib/gso/rte_gso.c
@@ -80,9 +80,8 @@ rte_gso_segment(struct rte_mbuf *pkt,
ret = gso_udp4_segment(pkt, gso_size, direct_pool,
indirect_pool, pkts_out, nb_pkts_out);
} else {
-   /* unsupported packet, skip */
-   RTE_LOG(DEBUG, GSO, "Unsupported packet type\n");
-   ret = 0;
+   ret = -ENOTSUP; /* only UDP or TCP allowed */
+
}
 
if (ret < 0) {
diff --git a/lib/gso/rte_gso.h b/lib/gso/rte_gso.h
index 40922524df42..23d6980aff9f 100644
--- a/lib/gso/rte_gso.h
+++ b/lib/gso/rte_gso.h
@@ -114,6 +114,7 @@ struct rte_gso_ctx {
  *  - The number of GSO segments filled in pkts_out on success.
  *  - Return 0 if it does not need to be GSO'd.
  *  - Return -ENOMEM if run out of memory in MBUF pools.
+ *  - Return -ENOTSUP for protocols that can not be segmentd (not UDP or TCP)
  *  - Return -EINVAL for invalid parameters.
  */
 int rte_gso_segment(struct rte_mbuf *pkt,
-- 
2.39.1

[PATCH v9 03/22] log: drop unused RTE_LOGTYPE_TIMER

[Stephen Hemminger]

The timer code does not use rte_log.

Signed-off-by: Stephen Hemminger 
---
 lib/eal/common/eal_common_log.c | 1 -
 lib/eal/include/rte_log.h   | 2 +-
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/lib/eal/common/eal_common_log.c b/lib/eal/common/eal_common_log.c
index 894701e8c19c..5421da008f5b 100644
--- a/lib/eal/common/eal_common_log.c
+++ b/lib/eal/common/eal_common_log.c
@@ -352,7 +352,6 @@ static const struct logtype logtype_strings[] = {
{RTE_LOGTYPE_MALLOC, "lib.malloc"},
{RTE_LOGTYPE_RING,   "lib.ring"},
{RTE_LOGTYPE_MEMPOOL,"lib.mempool"},
-   {RTE_LOGTYPE_TIMER,  "lib.timer"},
{RTE_LOGTYPE_PMD,"pmd"},
{RTE_LOGTYPE_HASH,   "lib.hash"},
{RTE_LOGTYPE_LPM,"lib.lpm"},
diff --git a/lib/eal/include/rte_log.h b/lib/eal/include/rte_log.h
index 11d517806054..16d6ea31583d 100644
--- a/lib/eal/include/rte_log.h
+++ b/lib/eal/include/rte_log.h
@@ -30,7 +30,7 @@ extern "C" {
 #define RTE_LOGTYPE_MALLOC 1 /**< Log related to malloc. */
 #define RTE_LOGTYPE_RING   2 /**< Log related to ring. */
 #define RTE_LOGTYPE_MEMPOOL3 /**< Log related to mempool. */
-#define RTE_LOGTYPE_TIMER  4 /**< Log related to timers. */
+/* was RTE_LOGTYPE_TIMER */
 #define RTE_LOGTYPE_PMD5 /**< Log related to poll mode driver. */
 #define RTE_LOGTYPE_HASH   6 /**< Log related to hash table. */
 #define RTE_LOGTYPE_LPM7 /**< Log related to LPM. */
-- 
2.39.1

[PATCH v9 04/22] efd: replace RTE_LOGTYPE_EFD with dynamic type

[Stephen Hemminger]

Replace all uses of the global logtype with a dynamic log type.

Signed-off-by: Stephen Hemminger 
---
 lib/eal/common/eal_common_log.c | 1 -
 lib/eal/include/rte_log.h   | 2 +-
 lib/efd/rte_efd.c   | 4 
 3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/lib/eal/common/eal_common_log.c b/lib/eal/common/eal_common_log.c
index 5421da008f5b..25bb17938cc1 100644
--- a/lib/eal/common/eal_common_log.c
+++ b/lib/eal/common/eal_common_log.c
@@ -365,7 +365,6 @@ static const struct logtype logtype_strings[] = {
{RTE_LOGTYPE_PIPELINE,   "lib.pipeline"},
{RTE_LOGTYPE_MBUF,   "lib.mbuf"},
{RTE_LOGTYPE_CRYPTODEV,  "lib.cryptodev"},
-   {RTE_LOGTYPE_EFD,"lib.efd"},
{RTE_LOGTYPE_EVENTDEV,   "lib.eventdev"},
{RTE_LOGTYPE_USER1,  "user1"},
{RTE_LOGTYPE_USER2,  "user2"},
diff --git a/lib/eal/include/rte_log.h b/lib/eal/include/rte_log.h
index 16d6ea31583d..0b39795b4d06 100644
--- a/lib/eal/include/rte_log.h
+++ b/lib/eal/include/rte_log.h
@@ -44,7 +44,7 @@ extern "C" {
 #define RTE_LOGTYPE_PIPELINE  15 /**< Log related to pipeline. */
 #define RTE_LOGTYPE_MBUF  16 /**< Log related to mbuf. */
 #define RTE_LOGTYPE_CRYPTODEV 17 /**< Log related to cryptodev. */
-#define RTE_LOGTYPE_EFD   18 /**< Log related to EFD. */
+/* was RTE_LOGTYPE_EFD */
 #define RTE_LOGTYPE_EVENTDEV  19 /**< Log related to eventdev. */
 /* was RTE_LOGTYPE_GSO */
 
diff --git a/lib/efd/rte_efd.c b/lib/efd/rte_efd.c
index 686a13775742..9edb11799c89 100644
--- a/lib/efd/rte_efd.c
+++ b/lib/efd/rte_efd.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -28,6 +29,9 @@
 #include "rte_efd_arm64.h"
 #endif
 
+RTE_LOG_REGISTER_DEFAULT(efd_logtype, INFO);
+#define RTE_LOGTYPE_EFDefd_logtype
+
 #define EFD_KEY(key_idx, table) (table->keys + ((key_idx) * table->key_len))
 /** Hash function used to determine chunk_id and bin_id for a group */
 #define EFD_HASH(key, table) \
-- 
2.39.1

[PATCH v9 05/22] mbuf: replace RTE_LOGTYPE_MBUF with dynamic type

[Stephen Hemminger]

Introduce a new dynamic logtype for mbuf related messages.
Since this is used in multiple files put one macro in mbuf_log.h

Signed-off-by: Stephen Hemminger 
---
 lib/eal/common/eal_common_log.c | 1 -
 lib/eal/include/rte_log.h   | 2 +-
 lib/mbuf/mbuf_log.h | 4 
 lib/mbuf/rte_mbuf.c | 4 
 lib/mbuf/rte_mbuf_dyn.c | 2 ++
 lib/mbuf/rte_mbuf_pool_ops.c| 2 ++
 6 files changed, 13 insertions(+), 2 deletions(-)
 create mode 100644 lib/mbuf/mbuf_log.h

diff --git a/lib/eal/common/eal_common_log.c b/lib/eal/common/eal_common_log.c
index 25bb17938cc1..d4389e436913 100644
--- a/lib/eal/common/eal_common_log.c
+++ b/lib/eal/common/eal_common_log.c
@@ -363,7 +363,6 @@ static const struct logtype logtype_strings[] = {
{RTE_LOGTYPE_PORT,   "lib.port"},
{RTE_LOGTYPE_TABLE,  "lib.table"},
{RTE_LOGTYPE_PIPELINE,   "lib.pipeline"},
-   {RTE_LOGTYPE_MBUF,   "lib.mbuf"},
{RTE_LOGTYPE_CRYPTODEV,  "lib.cryptodev"},
{RTE_LOGTYPE_EVENTDEV,   "lib.eventdev"},
{RTE_LOGTYPE_USER1,  "user1"},
diff --git a/lib/eal/include/rte_log.h b/lib/eal/include/rte_log.h
index 0b39795b4d06..941fbe51fd30 100644
--- a/lib/eal/include/rte_log.h
+++ b/lib/eal/include/rte_log.h
@@ -42,7 +42,7 @@ extern "C" {
 #define RTE_LOGTYPE_PORT  13 /**< Log related to port. */
 #define RTE_LOGTYPE_TABLE 14 /**< Log related to table. */
 #define RTE_LOGTYPE_PIPELINE  15 /**< Log related to pipeline. */
-#define RTE_LOGTYPE_MBUF  16 /**< Log related to mbuf. */
+/* was RTE_LOGTYPE_MBUF */
 #define RTE_LOGTYPE_CRYPTODEV 17 /**< Log related to cryptodev. */
 /* was RTE_LOGTYPE_EFD */
 #define RTE_LOGTYPE_EVENTDEV  19 /**< Log related to eventdev. */
diff --git a/lib/mbuf/mbuf_log.h b/lib/mbuf/mbuf_log.h
new file mode 100644
index ..d759a9a25501
--- /dev/null
+++ b/lib/mbuf/mbuf_log.h
@@ -0,0 +1,4 @@
+/* SPDX-License-Identifier: BSD-3-Clause */
+
+extern int mbuf_logtype;
+#define RTE_LOGTYPE_MBUF   mbuf_logtype
diff --git a/lib/mbuf/rte_mbuf.c b/lib/mbuf/rte_mbuf.c
index cfd8062f1e6a..4a379a5185d5 100644
--- a/lib/mbuf/rte_mbuf.c
+++ b/lib/mbuf/rte_mbuf.c
@@ -20,6 +20,10 @@
 #include 
 #include 
 
+#include "mbuf_log.h"
+
+RTE_LOG_REGISTER_DEFAULT(mbuf_logtype, INFO);
+
 /*
  * pktmbuf pool constructor, given as a callback function to
  * rte_mempool_create(), or called directly if using
diff --git a/lib/mbuf/rte_mbuf_dyn.c b/lib/mbuf/rte_mbuf_dyn.c
index 35839e938cc5..01654db03fc8 100644
--- a/lib/mbuf/rte_mbuf_dyn.c
+++ b/lib/mbuf/rte_mbuf_dyn.c
@@ -17,6 +17,8 @@
 #include 
 #include 
 
+#include "mbuf_log.h"
+
 #define RTE_MBUF_DYN_MZNAME "rte_mbuf_dyn"
 
 struct mbuf_dynfield_elt {
diff --git a/lib/mbuf/rte_mbuf_pool_ops.c b/lib/mbuf/rte_mbuf_pool_ops.c
index 4c91f4ce8569..5318430126cb 100644
--- a/lib/mbuf/rte_mbuf_pool_ops.c
+++ b/lib/mbuf/rte_mbuf_pool_ops.c
@@ -8,6 +8,8 @@
 #include 
 #include 
 
+#include "mbuf_log.h"
+
 int
 rte_mbuf_set_platform_mempool_ops(const char *ops_name)
 {
-- 
2.39.1

[PATCH v9 06/22] acl: replace LOGTYPE_ACL with dynamic type

[Stephen Hemminger]

Get rid of RTE_LOGTYPE_ACL and RTE_LOGTYPE_MALLOC.
For ACL library use a dynamic type.
The one message using RTE_LOGTYPE_MALLOC should have been
under the ACL logtype anyway.

The test code should not have been using fixed log type
so just change that to stderr.

Signed-off-by: Stephen Hemminger 
---
 app/test/test_acl.c | 3 ++-
 lib/acl/acl_bld.c   | 1 +
 lib/acl/acl_gen.c   | 1 +
 lib/acl/acl_log.h   | 4 
 lib/acl/rte_acl.c   | 4 
 lib/acl/tb_mem.c| 3 ++-
 lib/eal/common/eal_common_log.c | 2 --
 lib/eal/include/rte_log.h   | 4 ++--
 8 files changed, 16 insertions(+), 6 deletions(-)
 create mode 100644 lib/acl/acl_log.h

diff --git a/app/test/test_acl.c b/app/test/test_acl.c
index 623f34682e69..75588978a720 100644
--- a/app/test/test_acl.c
+++ b/app/test/test_acl.c
@@ -154,7 +154,8 @@ rte_acl_ipv4vlan_add_rules(struct rte_acl_ctx *ctx,
for (i = 0; i != num; i++) {
rc = acl_ipv4vlan_check_rule(rules + i);
if (rc != 0) {
-   RTE_LOG(ERR, ACL, "%s: rule #%u is invalid\n",
+   fprintf(stderr,
+   "%s: rule #%u is invalid\n",
__func__, i + 1);
return rc;
}
diff --git a/lib/acl/acl_bld.c b/lib/acl/acl_bld.c
index 2816632803bd..f38e6478315f 100644
--- a/lib/acl/acl_bld.c
+++ b/lib/acl/acl_bld.c
@@ -5,6 +5,7 @@
 #include 
 #include "tb_mem.h"
 #include "acl.h"
+#include "acl_log.h"
 
 #defineACL_POOL_ALIGN  8
 #defineACL_POOL_ALLOC_MIN  0x80
diff --git a/lib/acl/acl_gen.c b/lib/acl/acl_gen.c
index e759a2ca1598..54ec485d0c58 100644
--- a/lib/acl/acl_gen.c
+++ b/lib/acl/acl_gen.c
@@ -4,6 +4,7 @@
 
 #include 
 #include "acl.h"
+#include "acl_log.h"
 
 #defineQRANGE_MIN  ((uint8_t)INT8_MIN)
 
diff --git a/lib/acl/acl_log.h b/lib/acl/acl_log.h
new file mode 100644
index ..b55573cbe207
--- /dev/null
+++ b/lib/acl/acl_log.h
@@ -0,0 +1,4 @@
+/* SPDX-License-Identifier: BSD-3-Clause */
+
+extern int acl_logtype;
+#define RTE_LOGTYPE_ACLacl_logtype
diff --git a/lib/acl/rte_acl.c b/lib/acl/rte_acl.c
index a61c3ba188da..a29decb1f6ca 100644
--- a/lib/acl/rte_acl.c
+++ b/lib/acl/rte_acl.c
@@ -6,8 +6,12 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "acl.h"
+#include "acl_log.h"
+
+RTE_LOG_REGISTER_DEFAULT(acl_logtype, INFO);
 
 TAILQ_HEAD(rte_acl_list, rte_tailq_entry);
 
diff --git a/lib/acl/tb_mem.c b/lib/acl/tb_mem.c
index f14d7b4fa26e..6a9d96aaeda2 100644
--- a/lib/acl/tb_mem.c
+++ b/lib/acl/tb_mem.c
@@ -3,6 +3,7 @@
  */
 
 #include "tb_mem.h"
+#include "acl_log.h"
 
 /*
  *  Memory management routines for temporary memory.
@@ -25,7 +26,7 @@ tb_pool(struct tb_mem_pool *pool, size_t sz)
size = sz + pool->alignment - 1;
block = calloc(1, size + sizeof(*pool->block));
if (block == NULL) {
-   RTE_LOG(ERR, MALLOC, "%s(%zu)\n failed, currently allocated "
+   RTE_LOG(ERR, ACL, "%s(%zu)\n failed, currently allocated "
"by pool: %zu bytes\n", __func__, sz, pool->alloc);
siglongjmp(pool->fail, -ENOMEM);
return NULL;
diff --git a/lib/eal/common/eal_common_log.c b/lib/eal/common/eal_common_log.c
index d4389e436913..9e853addb717 100644
--- a/lib/eal/common/eal_common_log.c
+++ b/lib/eal/common/eal_common_log.c
@@ -349,14 +349,12 @@ struct logtype {
 
 static const struct logtype logtype_strings[] = {
{RTE_LOGTYPE_EAL,"lib.eal"},
-   {RTE_LOGTYPE_MALLOC, "lib.malloc"},
{RTE_LOGTYPE_RING,   "lib.ring"},
{RTE_LOGTYPE_MEMPOOL,"lib.mempool"},
{RTE_LOGTYPE_PMD,"pmd"},
{RTE_LOGTYPE_HASH,   "lib.hash"},
{RTE_LOGTYPE_LPM,"lib.lpm"},
{RTE_LOGTYPE_KNI,"lib.kni"},
-   {RTE_LOGTYPE_ACL,"lib.acl"},
{RTE_LOGTYPE_POWER,  "lib.power"},
{RTE_LOGTYPE_METER,  "lib.meter"},
{RTE_LOGTYPE_SCHED,  "lib.sched"},
diff --git a/lib/eal/include/rte_log.h b/lib/eal/include/rte_log.h
index 941fbe51fd30..1408722b2c2f 100644
--- a/lib/eal/include/rte_log.h
+++ b/lib/eal/include/rte_log.h
@@ -27,7 +27,7 @@ extern "C" {
 
 /* SDK log type */
 #define RTE_LOGTYPE_EAL0 /**< Log related to eal. */
-#define RTE_LOGTYPE_MALLOC 1 /**< Log related to malloc. */
+/* was RTE_LOGTYPE_MALLOC */
 #define RTE_LOGTYPE_RING   2 /**< Log related to ring. */
 #define RTE_LOGTYPE_MEMPOOL3 /**< Log related to mempool. */
 /* was RTE_LOGTYPE_TIMER */
@@ -35,7 +35,7 @@ extern "C" {
 #define RTE_LOGTYPE_HASH   6 /**< Log related to hash table. */
 #define RTE_LOGTYPE_LPM7 /**< Log related to LPM. */
 #define RTE_LOGTYPE_KNI8 /**< Log related to KNI. */
-#define RTE_LOGTYPE_ACL9 /**< Log 

[PATCH v9 07/22] examples/power: replace use of RTE_LOGTYPE_POWER

[Stephen Hemminger]

Don't use static logtype in sample application.

Signed-off-by: Stephen Hemminger 
---
 examples/distributor/main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/examples/distributor/main.c b/examples/distributor/main.c
index 21304d661873..542f76cf9664 100644
--- a/examples/distributor/main.c
+++ b/examples/distributor/main.c
@@ -679,7 +679,7 @@ init_power_library(void)
/* init power management library */
ret = rte_power_init(lcore_id);
if (ret) {
-   RTE_LOG(ERR, POWER,
+   fprintf(stderr,
"Library initialization failed on core %u\n",
lcore_id);
/*
-- 
2.39.1

[PATCH v9 08/22] examples/l3fwd-power: replace use of RTE_LOGTYPE_POWER

[Stephen Hemminger]

Convert to using a dynamic logtype for the application.

Signed-off-by: Stephen Hemminger 
---
 examples/l3fwd-power/main.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/examples/l3fwd-power/main.c b/examples/l3fwd-power/main.c
index f57c54d2b57c..76b890b76c88 100644
--- a/examples/l3fwd-power/main.c
+++ b/examples/l3fwd-power/main.c
@@ -51,7 +51,8 @@
 #include "perf_core.h"
 #include "main.h"
 
-#define RTE_LOGTYPE_L3FWD_POWER RTE_LOGTYPE_USER1
+RTE_LOG_REGISTER(l3fwd_power_logtype, l3fwd.power, INFO);
+#define RTE_LOGTYPE_L3FWD_POWER l3fwd_power_logtype
 
 #define MAX_PKT_BURST 32
 
@@ -2236,7 +2237,7 @@ init_power_library(void)
/* init power management library */
ret = rte_power_init(lcore_id);
if (ret) {
-   RTE_LOG(ERR, POWER,
+   RTE_LOG(ERR, L3FWD_POWER,
"Library initialization failed on core %u\n",
lcore_id);
return ret;
@@ -2245,7 +2246,7 @@ init_power_library(void)
env = rte_power_get_env();
if (env != PM_ENV_ACPI_CPUFREQ &&
env != PM_ENV_PSTATE_CPUFREQ) {
-   RTE_LOG(ERR, POWER,
+   RTE_LOG(ERR, L3FWD_POWER,
"Only ACPI and PSTATE mode are supported\n");
return -1;
}
@@ -2263,7 +2264,7 @@ deinit_power_library(void)
/* deinit power management library */
ret = rte_power_exit(lcore_id);
if (ret) {
-   RTE_LOG(ERR, POWER,
+   RTE_LOG(ERR, L3FWD_POWER,
"Library deinitialization failed on core %u\n",
lcore_id);
return ret;
@@ -2332,7 +2333,7 @@ update_telemetry(__rte_unused struct rte_timer *tim,
ret = rte_metrics_update_values(RTE_METRICS_GLOBAL, telstats_index,
values, RTE_DIM(values));
if (ret < 0)
-   RTE_LOG(WARNING, POWER, "failed to update metrics\n");
+   RTE_LOG(WARNING, L3FWD_POWER, "failed to update metrics\n");
 }
 
 static int
@@ -2381,7 +2382,7 @@ launch_timer(unsigned int lcore_id)
rte_get_main_lcore());
}
 
-   RTE_LOG(INFO, POWER, "Bring up the Timer\n");
+   RTE_LOG(INFO, L3FWD_POWER, "Bring up the Timer\n");
 
telemetry_setup_timer();
 
@@ -2397,7 +2398,7 @@ launch_timer(unsigned int lcore_id)
}
}
 
-   RTE_LOG(INFO, POWER, "Timer_subsystem is done\n");
+   RTE_LOG(INFO, L3FWD_POWER, "Timer_subsystem is done\n");
 
return 0;
 }
-- 
2.39.1

[PATCH v9 09/22] power: replace RTE_LOGTYPE_POWER with dynamic type

[Stephen Hemminger]

Use dynamic log type for power library.
Also replace use of RTE_LOGTYPE_USER1 with lib.power.guest.

Signed-off-by: Stephen Hemminger 
---
 lib/eal/common/eal_common_log.c | 1 -
 lib/eal/include/rte_log.h   | 2 +-
 lib/power/guest_channel.c   | 3 ++-
 lib/power/power_common.c| 2 ++
 lib/power/power_common.h| 3 ++-
 lib/power/power_kvm_vm.c| 1 +
 lib/power/rte_power.c   | 1 +
 7 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/lib/eal/common/eal_common_log.c b/lib/eal/common/eal_common_log.c
index 9e853addb717..39e1e6680dea 100644
--- a/lib/eal/common/eal_common_log.c
+++ b/lib/eal/common/eal_common_log.c
@@ -355,7 +355,6 @@ static const struct logtype logtype_strings[] = {
{RTE_LOGTYPE_HASH,   "lib.hash"},
{RTE_LOGTYPE_LPM,"lib.lpm"},
{RTE_LOGTYPE_KNI,"lib.kni"},
-   {RTE_LOGTYPE_POWER,  "lib.power"},
{RTE_LOGTYPE_METER,  "lib.meter"},
{RTE_LOGTYPE_SCHED,  "lib.sched"},
{RTE_LOGTYPE_PORT,   "lib.port"},
diff --git a/lib/eal/include/rte_log.h b/lib/eal/include/rte_log.h
index 1408722b2c2f..7d4345acceca 100644
--- a/lib/eal/include/rte_log.h
+++ b/lib/eal/include/rte_log.h
@@ -36,7 +36,7 @@ extern "C" {
 #define RTE_LOGTYPE_LPM7 /**< Log related to LPM. */
 #define RTE_LOGTYPE_KNI8 /**< Log related to KNI. */
 /* was RTE_LOGTYPE_ACL */
-#define RTE_LOGTYPE_POWER 10 /**< Log related to power. */
+/* was RTE_LOGTYPE_POWER */
 #define RTE_LOGTYPE_METER 11 /**< Log related to QoS meter. */
 #define RTE_LOGTYPE_SCHED 12 /**< Log related to QoS port scheduler. */
 #define RTE_LOGTYPE_PORT  13 /**< Log related to port. */
diff --git a/lib/power/guest_channel.c b/lib/power/guest_channel.c
index 969a9e5aaa06..efc326d520ca 100644
--- a/lib/power/guest_channel.c
+++ b/lib/power/guest_channel.c
@@ -17,7 +17,8 @@
 
 #include "guest_channel.h"
 
-#define RTE_LOGTYPE_GUEST_CHANNEL RTE_LOGTYPE_USER1
+RTE_LOG_REGISTER_SUFFIX(guest_channel_logtype, guest, INFO);
+#define RTE_LOGTYPE_GUEST_CHANNEL guest_channel_logtype
 
 /* Timeout for incoming message in milliseconds. */
 #define TIMEOUT 10
diff --git a/lib/power/power_common.c b/lib/power/power_common.c
index 1e09facb863f..bf77eafa886b 100644
--- a/lib/power/power_common.c
+++ b/lib/power/power_common.c
@@ -12,6 +12,8 @@
 
 #include "power_common.h"
 
+RTE_LOG_REGISTER_DEFAULT(power_logtype, INFO);
+
 #define POWER_SYSFILE_SCALING_DRIVER   \
"/sys/devices/system/cpu/cpu%u/cpufreq/scaling_driver"
 #define POWER_SYSFILE_GOVERNOR  \
diff --git a/lib/power/power_common.h b/lib/power/power_common.h
index c1c713927621..63a3a443509e 100644
--- a/lib/power/power_common.h
+++ b/lib/power/power_common.h
@@ -5,11 +5,12 @@
 #ifndef _POWER_COMMON_H_
 #define _POWER_COMMON_H_
 
-
 #include 
 
 #define RTE_POWER_INVALID_FREQ_INDEX (~0)
 
+extern int power_logtype;
+#define RTE_LOGTYPE_POWER power_logtype
 
 #ifdef RTE_LIBRTE_POWER_DEBUG
 #define POWER_DEBUG_TRACE(fmt, args...) \
diff --git a/lib/power/power_kvm_vm.c b/lib/power/power_kvm_vm.c
index 6a8109d44959..db031f43105a 100644
--- a/lib/power/power_kvm_vm.c
+++ b/lib/power/power_kvm_vm.c
@@ -8,6 +8,7 @@
 
 #include "rte_power_guest_channel.h"
 #include "guest_channel.h"
+#include "power_common.h"
 #include "power_kvm_vm.h"
 
 #define FD_PATH "/dev/virtio-ports/virtio.serial.port.poweragent"
diff --git a/lib/power/rte_power.c b/lib/power/rte_power.c
index 63a43bd8f5ae..db0e7705a9ef 100644
--- a/lib/power/rte_power.c
+++ b/lib/power/rte_power.c
@@ -10,6 +10,7 @@
 #include "rte_power.h"
 #include "power_acpi_cpufreq.h"
 #include "power_cppc_cpufreq.h"
+#include "power_common.h"
 #include "power_kvm_vm.h"
 #include "power_pstate_cpufreq.h"
 
-- 
2.39.1

[PATCH v9 10/22] ring: replace RTE_LOGTYPE_RING with dynamic type

[Stephen Hemminger]

The logtype for ring only used in library.

Signed-off-by: Stephen Hemminger 
---
 lib/eal/common/eal_common_log.c | 1 -
 lib/eal/include/rte_log.h   | 2 +-
 lib/ring/rte_ring.c | 3 +++
 3 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/lib/eal/common/eal_common_log.c b/lib/eal/common/eal_common_log.c
index 39e1e6680dea..5f15e312f15b 100644
--- a/lib/eal/common/eal_common_log.c
+++ b/lib/eal/common/eal_common_log.c
@@ -349,7 +349,6 @@ struct logtype {
 
 static const struct logtype logtype_strings[] = {
{RTE_LOGTYPE_EAL,"lib.eal"},
-   {RTE_LOGTYPE_RING,   "lib.ring"},
{RTE_LOGTYPE_MEMPOOL,"lib.mempool"},
{RTE_LOGTYPE_PMD,"pmd"},
{RTE_LOGTYPE_HASH,   "lib.hash"},
diff --git a/lib/eal/include/rte_log.h b/lib/eal/include/rte_log.h
index 7d4345acceca..31a2ee2f6b6f 100644
--- a/lib/eal/include/rte_log.h
+++ b/lib/eal/include/rte_log.h
@@ -28,7 +28,7 @@ extern "C" {
 /* SDK log type */
 #define RTE_LOGTYPE_EAL0 /**< Log related to eal. */
 /* was RTE_LOGTYPE_MALLOC */
-#define RTE_LOGTYPE_RING   2 /**< Log related to ring. */
+/* was RTE_LOGTYPE_RING */
 #define RTE_LOGTYPE_MEMPOOL3 /**< Log related to mempool. */
 /* was RTE_LOGTYPE_TIMER */
 #define RTE_LOGTYPE_PMD5 /**< Log related to poll mode driver. */
diff --git a/lib/ring/rte_ring.c b/lib/ring/rte_ring.c
index cddaf6b2876f..8c5f2575d6ef 100644
--- a/lib/ring/rte_ring.c
+++ b/lib/ring/rte_ring.c
@@ -26,6 +26,9 @@
 #include "rte_ring.h"
 #include "rte_ring_elem.h"
 
+RTE_LOG_REGISTER_DEFAULT(ring_logtype, INFO);
+#define RTE_LOGTYPE_RING ring_logtype
+
 TAILQ_HEAD(rte_ring_list, rte_tailq_entry);
 
 static struct rte_tailq_elem rte_ring_tailq = {
-- 
2.39.1

[PATCH v9 11/22] mempool: replace RTE_LOGTYPE_MEMPOOL with dynamic type

[Stephen Hemminger]

Convert from RTE_LOGTYPE_MEMPOOL to logtype_mempool.

Signed-off-by: Stephen Hemminger 
---
 lib/eal/common/eal_common_log.c | 1 -
 lib/eal/include/rte_log.h   | 2 +-
 lib/mempool/rte_mempool.c   | 2 ++
 lib/mempool/rte_mempool.h   | 8 
 lib/mempool/version.map | 3 +++
 5 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/lib/eal/common/eal_common_log.c b/lib/eal/common/eal_common_log.c
index 5f15e312f15b..4025d2039d55 100644
--- a/lib/eal/common/eal_common_log.c
+++ b/lib/eal/common/eal_common_log.c
@@ -349,7 +349,6 @@ struct logtype {
 
 static const struct logtype logtype_strings[] = {
{RTE_LOGTYPE_EAL,"lib.eal"},
-   {RTE_LOGTYPE_MEMPOOL,"lib.mempool"},
{RTE_LOGTYPE_PMD,"pmd"},
{RTE_LOGTYPE_HASH,   "lib.hash"},
{RTE_LOGTYPE_LPM,"lib.lpm"},
diff --git a/lib/eal/include/rte_log.h b/lib/eal/include/rte_log.h
index 31a2ee2f6b6f..9f86bfdd0198 100644
--- a/lib/eal/include/rte_log.h
+++ b/lib/eal/include/rte_log.h
@@ -29,7 +29,7 @@ extern "C" {
 #define RTE_LOGTYPE_EAL0 /**< Log related to eal. */
 /* was RTE_LOGTYPE_MALLOC */
 /* was RTE_LOGTYPE_RING */
-#define RTE_LOGTYPE_MEMPOOL3 /**< Log related to mempool. */
+/* was RTE_LOGTYPE_MEMPOOL */
 /* was RTE_LOGTYPE_TIMER */
 #define RTE_LOGTYPE_PMD5 /**< Log related to poll mode driver. */
 #define RTE_LOGTYPE_HASH   6 /**< Log related to hash table. */
diff --git a/lib/mempool/rte_mempool.c b/lib/mempool/rte_mempool.c
index cf5dea2304a7..b609a94fdf9d 100644
--- a/lib/mempool/rte_mempool.c
+++ b/lib/mempool/rte_mempool.c
@@ -31,6 +31,8 @@
 #include "mempool_trace.h"
 #include "rte_mempool.h"
 
+RTE_LOG_REGISTER_DEFAULT(rte_mempool_logtype, INFO);
+
 TAILQ_HEAD(rte_mempool_list, rte_tailq_entry);
 
 static struct rte_tailq_elem rte_mempool_tailq = {
diff --git a/lib/mempool/rte_mempool.h b/lib/mempool/rte_mempool.h
index 9f530db24ba1..db01acc19b02 100644
--- a/lib/mempool/rte_mempool.h
+++ b/lib/mempool/rte_mempool.h
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -175,6 +176,13 @@ struct rte_mempool_objtlr {
 
 #endif
 
+
+/**
+ * @internal Logtype used for mempool related messages.
+ */
+extern int rte_mempool_logtype;
+#define RTE_LOGTYPE_MEMPOOLrte_mempool_logtype
+
 /**
  * A list of memory where objects are stored
  */
diff --git a/lib/mempool/version.map b/lib/mempool/version.map
index dff2d1cb..eb2c12127560 100644
--- a/lib/mempool/version.map
+++ b/lib/mempool/version.map
@@ -57,4 +57,7 @@ INTERNAL {
# added in 21.11
rte_mempool_event_callback_register;
rte_mempool_event_callback_unregister;
+
+   # added in 23.07
+   rte_mempool_logtype;
 };
-- 
2.39.1

[PATCH v9 12/22] lpm: replace RTE_LOGTYPE_LPM with dynamic types

[Stephen Hemminger]

Split lpm and lpm6 into separate log types since they
are in different files and user may want to change log
levels for IPv4 vs IPv6.

For rib and fib libraries give them own types as well.

Signed-off-by: Stephen Hemminger 
---
 lib/eal/common/eal_common_log.c | 1 -
 lib/eal/include/rte_log.h   | 2 +-
 lib/fib/fib_log.h   | 4 
 lib/fib/rte_fib.c   | 3 +++
 lib/fib/rte_fib6.c  | 2 ++
 lib/lpm/lpm_log.h   | 4 
 lib/lpm/rte_lpm.c   | 3 +++
 lib/lpm/rte_lpm6.c  | 1 +
 lib/rib/rib_log.h   | 4 
 lib/rib/rte_rib.c   | 3 +++
 lib/rib/rte_rib6.c  | 3 +++
 11 files changed, 28 insertions(+), 2 deletions(-)
 create mode 100644 lib/fib/fib_log.h
 create mode 100644 lib/lpm/lpm_log.h
 create mode 100644 lib/rib/rib_log.h

diff --git a/lib/eal/common/eal_common_log.c b/lib/eal/common/eal_common_log.c
index 4025d2039d55..6e2007e6ed4f 100644
--- a/lib/eal/common/eal_common_log.c
+++ b/lib/eal/common/eal_common_log.c
@@ -351,7 +351,6 @@ static const struct logtype logtype_strings[] = {
{RTE_LOGTYPE_EAL,"lib.eal"},
{RTE_LOGTYPE_PMD,"pmd"},
{RTE_LOGTYPE_HASH,   "lib.hash"},
-   {RTE_LOGTYPE_LPM,"lib.lpm"},
{RTE_LOGTYPE_KNI,"lib.kni"},
{RTE_LOGTYPE_METER,  "lib.meter"},
{RTE_LOGTYPE_SCHED,  "lib.sched"},
diff --git a/lib/eal/include/rte_log.h b/lib/eal/include/rte_log.h
index 9f86bfdd0198..115a48bf05f5 100644
--- a/lib/eal/include/rte_log.h
+++ b/lib/eal/include/rte_log.h
@@ -33,7 +33,7 @@ extern "C" {
 /* was RTE_LOGTYPE_TIMER */
 #define RTE_LOGTYPE_PMD5 /**< Log related to poll mode driver. */
 #define RTE_LOGTYPE_HASH   6 /**< Log related to hash table. */
-#define RTE_LOGTYPE_LPM7 /**< Log related to LPM. */
+/* was RTE_LOGTYPE_LPM */
 #define RTE_LOGTYPE_KNI8 /**< Log related to KNI. */
 /* was RTE_LOGTYPE_ACL */
 /* was RTE_LOGTYPE_POWER */
diff --git a/lib/fib/fib_log.h b/lib/fib/fib_log.h
new file mode 100644
index ..c731c820f621
--- /dev/null
+++ b/lib/fib/fib_log.h
@@ -0,0 +1,4 @@
+/* SPDX-License-Identifier: BSD-3-Clause */
+
+extern int fib_logtype;
+#define RTE_LOGTYPE_LPM fib_logtype
diff --git a/lib/fib/rte_fib.c b/lib/fib/rte_fib.c
index 8af4c4091908..5b1815881415 100644
--- a/lib/fib/rte_fib.c
+++ b/lib/fib/rte_fib.c
@@ -16,6 +16,9 @@
 #include 
 
 #include "dir24_8.h"
+#include "fib_log.h"
+
+RTE_LOG_REGISTER_DEFAULT(fib_logtype, INFO);
 
 TAILQ_HEAD(rte_fib_list, rte_tailq_entry);
 static struct rte_tailq_elem rte_fib_tailq = {
diff --git a/lib/fib/rte_fib6.c b/lib/fib/rte_fib6.c
index 4b8e22b142b9..762d195fb798 100644
--- a/lib/fib/rte_fib6.c
+++ b/lib/fib/rte_fib6.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -16,6 +17,7 @@
 #include 
 
 #include "trie.h"
+#include "fib_log.h"
 
 TAILQ_HEAD(rte_fib6_list, rte_tailq_entry);
 static struct rte_tailq_elem rte_fib6_tailq = {
diff --git a/lib/lpm/lpm_log.h b/lib/lpm/lpm_log.h
new file mode 100644
index ..a0621b70a5fe
--- /dev/null
+++ b/lib/lpm/lpm_log.h
@@ -0,0 +1,4 @@
+/* SPDX-License-Identifier: BSD-3-Clause */
+
+extern int lpm_logtype;
+#define RTE_LOGTYPE_LPM lpm_logtype
diff --git a/lib/lpm/rte_lpm.c b/lib/lpm/rte_lpm.c
index cdcd1b7f9e47..0ca82147866a 100644
--- a/lib/lpm/rte_lpm.c
+++ b/lib/lpm/rte_lpm.c
@@ -18,6 +18,9 @@
 #include 
 
 #include "rte_lpm.h"
+#include "lpm_log.h"
+
+RTE_LOG_REGISTER_DEFAULT(lpm_logtype, INFO);
 
 TAILQ_HEAD(rte_lpm_list, rte_tailq_entry);
 
diff --git a/lib/lpm/rte_lpm6.c b/lib/lpm/rte_lpm6.c
index 8d21aeddb83c..873cc8bc267d 100644
--- a/lib/lpm/rte_lpm6.c
+++ b/lib/lpm/rte_lpm6.c
@@ -20,6 +20,7 @@
 #include 
 
 #include "rte_lpm6.h"
+#include "lpm_log.h"
 
 #define RTE_LPM6_TBL24_NUM_ENTRIES(1 << 24)
 #define RTE_LPM6_TBL8_GROUP_NUM_ENTRIES 256
diff --git a/lib/rib/rib_log.h b/lib/rib/rib_log.h
new file mode 100644
index ..f3ee513ca854
--- /dev/null
+++ b/lib/rib/rib_log.h
@@ -0,0 +1,4 @@
+/* SPDX-License-Identifier: BSD-3-Clause */
+
+extern int rib_logtype;
+#define RTE_LOGTYPE_LPM rib_logtype
diff --git a/lib/rib/rte_rib.c b/lib/rib/rte_rib.c
index b0794edf66f5..5597c8b899c8 100644
--- a/lib/rib/rte_rib.c
+++ b/lib/rib/rte_rib.c
@@ -15,6 +15,9 @@
 
 #include 
 
+RTE_LOG_REGISTER_DEFAULT(rib_logtype, INFO);
+#define RTE_LOGTYPE_LPM rib_logtype
+
 TAILQ_HEAD(rte_rib_list, rte_tailq_entry);
 static struct rte_tailq_elem rte_rib_tailq = {
.name = "RTE_RIB",
diff --git a/lib/rib/rte_rib6.c b/lib/rib/rte_rib6.c
index 19e4ff97c479..917bede27d24 100644
--- a/lib/rib/rte_rib6.c
+++ b/lib/rib/rte_rib6.c
@@ -8,6 +8,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -15,6 +16,8 @@
 
 #include 
 
+#include "rib_log.h"
+
 #define RTE

[PATCH v9 13/22] kni: replace RTE_LOGTYPE_KNI with dynamic type

[Stephen Hemminger]

Even though KNI will eventually disappear, fix the
logtype now.

Signed-off-by: Stephen Hemminger 
---
 lib/eal/common/eal_common_log.c | 1 -
 lib/eal/include/rte_log.h   | 2 +-
 lib/kni/rte_kni.c   | 3 +++
 3 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/lib/eal/common/eal_common_log.c b/lib/eal/common/eal_common_log.c
index 6e2007e6ed4f..70d5bb7b1951 100644
--- a/lib/eal/common/eal_common_log.c
+++ b/lib/eal/common/eal_common_log.c
@@ -351,7 +351,6 @@ static const struct logtype logtype_strings[] = {
{RTE_LOGTYPE_EAL,"lib.eal"},
{RTE_LOGTYPE_PMD,"pmd"},
{RTE_LOGTYPE_HASH,   "lib.hash"},
-   {RTE_LOGTYPE_KNI,"lib.kni"},
{RTE_LOGTYPE_METER,  "lib.meter"},
{RTE_LOGTYPE_SCHED,  "lib.sched"},
{RTE_LOGTYPE_PORT,   "lib.port"},
diff --git a/lib/eal/include/rte_log.h b/lib/eal/include/rte_log.h
index 115a48bf05f5..dc2454a0d9de 100644
--- a/lib/eal/include/rte_log.h
+++ b/lib/eal/include/rte_log.h
@@ -34,7 +34,7 @@ extern "C" {
 #define RTE_LOGTYPE_PMD5 /**< Log related to poll mode driver. */
 #define RTE_LOGTYPE_HASH   6 /**< Log related to hash table. */
 /* was RTE_LOGTYPE_LPM */
-#define RTE_LOGTYPE_KNI8 /**< Log related to KNI. */
+/* was RTE_LOGTYPE_KNI */
 /* was RTE_LOGTYPE_ACL */
 /* was RTE_LOGTYPE_POWER */
 #define RTE_LOGTYPE_METER 11 /**< Log related to QoS meter. */
diff --git a/lib/kni/rte_kni.c b/lib/kni/rte_kni.c
index 8ab6c4715314..9c37bcabcadd 100644
--- a/lib/kni/rte_kni.c
+++ b/lib/kni/rte_kni.c
@@ -23,6 +23,9 @@
 #include 
 #include "rte_kni_fifo.h"
 
+RTE_LOG_REGISTER_DEFAULT(kni_logtype, INFO);
+#define RTE_LOGTYPE_KNI kni_logtype
+
 #define MAX_MBUF_BURST_NUM32
 
 /* Maximum number of ring entries */
-- 
2.39.1

[PATCH v9 14/22] sched: replace RTE_LOGTYPE_SCHED with dynamic type

[Stephen Hemminger]

Also can remove unused RTE_LOGTYPE_METER

Signed-off-by: Stephen Hemminger 
---
 lib/eal/common/eal_common_log.c | 2 --
 lib/eal/include/rte_log.h   | 4 ++--
 lib/sched/rte_pie.c | 1 +
 lib/sched/rte_sched.c   | 5 +
 lib/sched/rte_sched_log.h   | 4 
 5 files changed, 12 insertions(+), 4 deletions(-)
 create mode 100644 lib/sched/rte_sched_log.h

diff --git a/lib/eal/common/eal_common_log.c b/lib/eal/common/eal_common_log.c
index 70d5bb7b1951..d4b7088b5cbb 100644
--- a/lib/eal/common/eal_common_log.c
+++ b/lib/eal/common/eal_common_log.c
@@ -351,8 +351,6 @@ static const struct logtype logtype_strings[] = {
{RTE_LOGTYPE_EAL,"lib.eal"},
{RTE_LOGTYPE_PMD,"pmd"},
{RTE_LOGTYPE_HASH,   "lib.hash"},
-   {RTE_LOGTYPE_METER,  "lib.meter"},
-   {RTE_LOGTYPE_SCHED,  "lib.sched"},
{RTE_LOGTYPE_PORT,   "lib.port"},
{RTE_LOGTYPE_TABLE,  "lib.table"},
{RTE_LOGTYPE_PIPELINE,   "lib.pipeline"},
diff --git a/lib/eal/include/rte_log.h b/lib/eal/include/rte_log.h
index dc2454a0d9de..f185fcbc5a94 100644
--- a/lib/eal/include/rte_log.h
+++ b/lib/eal/include/rte_log.h
@@ -37,8 +37,8 @@ extern "C" {
 /* was RTE_LOGTYPE_KNI */
 /* was RTE_LOGTYPE_ACL */
 /* was RTE_LOGTYPE_POWER */
-#define RTE_LOGTYPE_METER 11 /**< Log related to QoS meter. */
-#define RTE_LOGTYPE_SCHED 12 /**< Log related to QoS port scheduler. */
+/* was RTE_LOGTYPE_METER */
+/* was RTE_LOGTYPE_SCHED */
 #define RTE_LOGTYPE_PORT  13 /**< Log related to port. */
 #define RTE_LOGTYPE_TABLE 14 /**< Log related to table. */
 #define RTE_LOGTYPE_PIPELINE  15 /**< Log related to pipeline. */
diff --git a/lib/sched/rte_pie.c b/lib/sched/rte_pie.c
index 947e2a059f6f..cce0ce762da8 100644
--- a/lib/sched/rte_pie.c
+++ b/lib/sched/rte_pie.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 
+#include "rte_sched_log.h"
 #include "rte_pie.h"
 
 #ifdef __INTEL_COMPILER
diff --git a/lib/sched/rte_sched.c b/lib/sched/rte_sched.c
index 19768d8c38b0..27e98e46df7a 100644
--- a/lib/sched/rte_sched.c
+++ b/lib/sched/rte_sched.c
@@ -16,9 +16,12 @@
 #include 
 
 #include "rte_sched.h"
+#include "rte_sched_log.h"
 #include "rte_sched_common.h"
+
 #include "rte_approx.h"
 
+
 #ifdef __INTEL_COMPILER
 #pragma warning(disable:2259) /* conversion may lose significant bits */
 #endif
@@ -3002,3 +3005,5 @@ rte_sched_port_dequeue(struct rte_sched_port *port, 
struct rte_mbuf **pkts, uint
 
return count;
 }
+
+RTE_LOG_REGISTER_DEFAULT(sched_logtype, INFO);
diff --git a/lib/sched/rte_sched_log.h b/lib/sched/rte_sched_log.h
new file mode 100644
index ..fde051f49d62
--- /dev/null
+++ b/lib/sched/rte_sched_log.h
@@ -0,0 +1,4 @@
+/* SPDX-License-Identifier: BSD-3-Clause */
+
+extern int sched_logtype;
+#define RTE_LOGTYPE_SCHED sched_logtype
-- 
2.39.1

[PATCH v9 15/22] examples/ipsecgw: replace RTE_LOGTYPE_PORT

[Stephen Hemminger]

Looks like some code got copy/paste in to the IPSEC gateway
example from another place. Shouldn't be using RTE_LOGTYPE_PORT
here.

Fixes: ec17993a145a ("examples/ipsec-secgw: support security offload")
Cc: akhil.go...@nxp.com
Signed-off-by: Stephen Hemminger 
---
 examples/ipsec-secgw/sa.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
index 7da9444a7b8a..67327fda8dbc 100644
--- a/examples/ipsec-secgw/sa.c
+++ b/examples/ipsec-secgw/sa.c
@@ -1127,7 +1127,7 @@ check_eth_dev_caps(uint16_t portid, uint32_t inbound, 
uint32_t tso)
if (inbound) {
if ((dev_info.rx_offload_capa &
RTE_ETH_RX_OFFLOAD_SECURITY) == 0) {
-   RTE_LOG(WARNING, PORT,
+   RTE_LOG(WARNING, IPSEC,
"hardware RX IPSec offload is not supported\n");
return -EINVAL;
}
@@ -1135,13 +1135,13 @@ check_eth_dev_caps(uint16_t portid, uint32_t inbound, 
uint32_t tso)
} else { /* outbound */
if ((dev_info.tx_offload_capa &
RTE_ETH_TX_OFFLOAD_SECURITY) == 0) {
-   RTE_LOG(WARNING, PORT,
+   RTE_LOG(WARNING, IPSEC,
"hardware TX IPSec offload is not supported\n");
return -EINVAL;
}
if (tso && (dev_info.tx_offload_capa &
RTE_ETH_TX_OFFLOAD_TCP_TSO) == 0) {
-   RTE_LOG(WARNING, PORT,
+   RTE_LOG(WARNING, IPSEC,
"hardware TCP TSO offload is not supported\n");
return -EINVAL;
}
-- 
2.39.1

[PATCH v9 16/22] port: replace RTE_LOGTYPE_PORT with dynamic type

[Stephen Hemminger]

Split up the single static RTE_LOGTYPE_PORT into separate
sub types for each component: port.ethdev, port.evendev, ...

Signed-off-by: Stephen Hemminger 
---
 lib/eal/common/eal_common_log.c | 1 -
 lib/eal/include/rte_log.h   | 2 +-
 lib/port/rte_port_ethdev.c  | 3 +++
 lib/port/rte_port_eventdev.c| 4 
 lib/port/rte_port_fd.c  | 3 +++
 lib/port/rte_port_frag.c| 3 +++
 lib/port/rte_port_kni.c | 3 +++
 lib/port/rte_port_ras.c | 3 +++
 lib/port/rte_port_ring.c| 3 +++
 lib/port/rte_port_sched.c   | 3 +++
 lib/port/rte_port_source_sink.c | 3 +++
 lib/port/rte_port_sym_crypto.c  | 3 +++
 12 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/lib/eal/common/eal_common_log.c b/lib/eal/common/eal_common_log.c
index d4b7088b5cbb..7f1d2c8a256d 100644
--- a/lib/eal/common/eal_common_log.c
+++ b/lib/eal/common/eal_common_log.c
@@ -351,7 +351,6 @@ static const struct logtype logtype_strings[] = {
{RTE_LOGTYPE_EAL,"lib.eal"},
{RTE_LOGTYPE_PMD,"pmd"},
{RTE_LOGTYPE_HASH,   "lib.hash"},
-   {RTE_LOGTYPE_PORT,   "lib.port"},
{RTE_LOGTYPE_TABLE,  "lib.table"},
{RTE_LOGTYPE_PIPELINE,   "lib.pipeline"},
{RTE_LOGTYPE_CRYPTODEV,  "lib.cryptodev"},
diff --git a/lib/eal/include/rte_log.h b/lib/eal/include/rte_log.h
index f185fcbc5a94..b11aec69af78 100644
--- a/lib/eal/include/rte_log.h
+++ b/lib/eal/include/rte_log.h
@@ -39,7 +39,7 @@ extern "C" {
 /* was RTE_LOGTYPE_POWER */
 /* was RTE_LOGTYPE_METER */
 /* was RTE_LOGTYPE_SCHED */
-#define RTE_LOGTYPE_PORT  13 /**< Log related to port. */
+/* was RTE_LOGTYPE_PORT */
 #define RTE_LOGTYPE_TABLE 14 /**< Log related to table. */
 #define RTE_LOGTYPE_PIPELINE  15 /**< Log related to pipeline. */
 /* was RTE_LOGTYPE_MBUF */
diff --git a/lib/port/rte_port_ethdev.c b/lib/port/rte_port_ethdev.c
index 0da7890261e9..6685d304a6e9 100644
--- a/lib/port/rte_port_ethdev.c
+++ b/lib/port/rte_port_ethdev.c
@@ -10,6 +10,9 @@
 
 #include "rte_port_ethdev.h"
 
+RTE_LOG_REGISTER_SUFFIX(port_ethdev_logtype, ethdev, INFO);
+#define RTE_LOGTYPE_PORT port_ethdev_logtype
+
 /*
  * Port ETHDEV Reader
  */
diff --git a/lib/port/rte_port_eventdev.c b/lib/port/rte_port_eventdev.c
index fd7dac9a5661..04447bd7f7bc 100644
--- a/lib/port/rte_port_eventdev.c
+++ b/lib/port/rte_port_eventdev.c
@@ -5,11 +5,15 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 
 #include "rte_port_eventdev.h"
 
+RTE_LOG_REGISTER_SUFFIX(port_eventdev_logtype, eventdev, INFO);
+#define RTE_LOGTYPE_PORT port_eventdev_logtype
+
 /*
  * Port EVENTDEV Reader
  */
diff --git a/lib/port/rte_port_fd.c b/lib/port/rte_port_fd.c
index 932ecd324e05..b2412e7706ee 100644
--- a/lib/port/rte_port_fd.c
+++ b/lib/port/rte_port_fd.c
@@ -10,6 +10,9 @@
 
 #include "rte_port_fd.h"
 
+RTE_LOG_REGISTER_SUFFIX(port_fd_logtype, fd, INFO);
+#define RTE_LOGTYPE_PORT port_fd_logtype
+
 /*
  * Port FD Reader
  */
diff --git a/lib/port/rte_port_frag.c b/lib/port/rte_port_frag.c
index e1f1892176c4..9adcbba47da1 100644
--- a/lib/port/rte_port_frag.c
+++ b/lib/port/rte_port_frag.c
@@ -7,6 +7,9 @@
 
 #include "rte_port_frag.h"
 
+RTE_LOG_REGISTER_SUFFIX(port_frag_logtype, frag, INFO);
+#define RTE_LOGTYPE_PORT port_frag_logtype
+
 /* Max number of fragments per packet allowed */
 #defineRTE_PORT_FRAG_MAX_FRAGS_PER_PACKET 0x80
 
diff --git a/lib/port/rte_port_kni.c b/lib/port/rte_port_kni.c
index 1c7a6cb200ea..d4ac08b4cff0 100644
--- a/lib/port/rte_port_kni.c
+++ b/lib/port/rte_port_kni.c
@@ -9,6 +9,9 @@
 
 #include "rte_port_kni.h"
 
+RTE_LOG_REGISTER_SUFFIX(port_kni_logtype, kni, INFO);
+#define RTE_LOGTYPE_PORT port_kni_logtype
+
 /*
  * Port KNI Reader
  */
diff --git a/lib/port/rte_port_ras.c b/lib/port/rte_port_ras.c
index e5de57da42ea..5a610b1ba5b5 100644
--- a/lib/port/rte_port_ras.c
+++ b/lib/port/rte_port_ras.c
@@ -9,6 +9,9 @@
 
 #include "rte_port_ras.h"
 
+RTE_LOG_REGISTER_SUFFIX(port_ras_logtype, ras, INFO);
+#define RTE_LOGTYPE_PORT port_ras_logtype
+
 #ifndef RTE_PORT_RAS_N_BUCKETS
 #define RTE_PORT_RAS_N_BUCKETS 4094
 #endif
diff --git a/lib/port/rte_port_ring.c b/lib/port/rte_port_ring.c
index 52b2d8e557f0..32a90e836579 100644
--- a/lib/port/rte_port_ring.c
+++ b/lib/port/rte_port_ring.c
@@ -10,6 +10,9 @@
 
 #include "rte_port_ring.h"
 
+RTE_LOG_REGISTER_SUFFIX(port_ring_logtype, ring, INFO);
+#define RTE_LOGTYPE_PORT port_ring_logtype
+
 /*
  * Port RING Reader
  */
diff --git a/lib/port/rte_port_sched.c b/lib/port/rte_port_sched.c
index 8a7d815ef323..6e0a8aba5419 100644
--- a/lib/port/rte_port_sched.c
+++ b/lib/port/rte_port_sched.c
@@ -7,6 +7,9 @@
 
 #include "rte_port_sched.h"
 
+RTE_LOG_REGISTER_SUFFIX(port_sched_logtype, sched, INFO);
+#define RTE_LOGTYPE_PORT port_sched_logtype
+
 /*
 

[PATCH v9 17/22] table: convert RTE_LOGTYPE_TABLE to dynamic logtype

[Stephen Hemminger]

Use logtype suffixes for various components of this library.

Signed-off-by: Stephen Hemminger 
---
 lib/eal/common/eal_common_log.c   | 1 -
 lib/eal/include/rte_log.h | 2 +-
 lib/table/rte_table_acl.c | 3 +++
 lib/table/rte_table_array.c   | 3 +++
 lib/table/rte_table_hash_cuckoo.c | 3 +++
 lib/table/rte_table_hash_ext.c| 3 +++
 lib/table/rte_table_hash_key16.c  | 3 +++
 lib/table/rte_table_hash_key32.c  | 5 -
 lib/table/rte_table_hash_key8.c   | 5 -
 lib/table/rte_table_hash_lru.c| 3 +++
 lib/table/rte_table_lpm.c | 3 +++
 lib/table/rte_table_lpm_ipv6.c| 3 +++
 lib/table/rte_table_stub.c| 3 +++
 13 files changed, 36 insertions(+), 4 deletions(-)

diff --git a/lib/eal/common/eal_common_log.c b/lib/eal/common/eal_common_log.c
index 7f1d2c8a256d..d640ed3c88b9 100644
--- a/lib/eal/common/eal_common_log.c
+++ b/lib/eal/common/eal_common_log.c
@@ -351,7 +351,6 @@ static const struct logtype logtype_strings[] = {
{RTE_LOGTYPE_EAL,"lib.eal"},
{RTE_LOGTYPE_PMD,"pmd"},
{RTE_LOGTYPE_HASH,   "lib.hash"},
-   {RTE_LOGTYPE_TABLE,  "lib.table"},
{RTE_LOGTYPE_PIPELINE,   "lib.pipeline"},
{RTE_LOGTYPE_CRYPTODEV,  "lib.cryptodev"},
{RTE_LOGTYPE_EVENTDEV,   "lib.eventdev"},
diff --git a/lib/eal/include/rte_log.h b/lib/eal/include/rte_log.h
index b11aec69af78..934bddff9dfa 100644
--- a/lib/eal/include/rte_log.h
+++ b/lib/eal/include/rte_log.h
@@ -40,7 +40,7 @@ extern "C" {
 /* was RTE_LOGTYPE_METER */
 /* was RTE_LOGTYPE_SCHED */
 /* was RTE_LOGTYPE_PORT */
-#define RTE_LOGTYPE_TABLE 14 /**< Log related to table. */
+/* was RTE_LOGTYPE_TABLE */
 #define RTE_LOGTYPE_PIPELINE  15 /**< Log related to pipeline. */
 /* was RTE_LOGTYPE_MBUF */
 #define RTE_LOGTYPE_CRYPTODEV 17 /**< Log related to cryptodev. */
diff --git a/lib/table/rte_table_acl.c b/lib/table/rte_table_acl.c
index 53fd5c66adb5..f44a25a89405 100644
--- a/lib/table/rte_table_acl.c
+++ b/lib/table/rte_table_acl.c
@@ -11,6 +11,9 @@
 
 #include "rte_table_acl.h"
 
+RTE_LOG_REGISTER_SUFFIX(table_acl_logtype, acl, INFO);
+#define RTE_LOGTYPE_TABLE table_acl_logtype
+
 #ifdef RTE_TABLE_STATS_COLLECT
 
 #define RTE_TABLE_ACL_STATS_PKTS_IN_ADD(table, val) \
diff --git a/lib/table/rte_table_array.c b/lib/table/rte_table_array.c
index 54a0c42f7dd2..a7849beaecd6 100644
--- a/lib/table/rte_table_array.c
+++ b/lib/table/rte_table_array.c
@@ -11,6 +11,9 @@
 
 #include "rte_table_array.h"
 
+RTE_LOG_REGISTER_SUFFIX(table_array_logtype, array, INFO);
+#define RTE_LOGTYPE_TABLE table_array_logtype
+
 #ifdef RTE_TABLE_STATS_COLLECT
 
 #define RTE_TABLE_ARRAY_STATS_PKTS_IN_ADD(table, val) \
diff --git a/lib/table/rte_table_hash_cuckoo.c 
b/lib/table/rte_table_hash_cuckoo.c
index c77eccf52722..12db0b84142f 100644
--- a/lib/table/rte_table_hash_cuckoo.c
+++ b/lib/table/rte_table_hash_cuckoo.c
@@ -10,6 +10,9 @@
 
 #include "rte_table_hash_cuckoo.h"
 
+RTE_LOG_REGISTER_SUFFIX(table_hash_logtype, hash, INFO);
+#define RTE_LOGTYPE_TABLE table_hash_logtype
+
 #ifdef RTE_TABLE_STATS_COLLECT
 
 #define RTE_TABLE_HASH_CUCKOO_STATS_PKTS_IN_ADD(table, val) \
diff --git a/lib/table/rte_table_hash_ext.c b/lib/table/rte_table_hash_ext.c
index 70ea84fa2e51..147ecdf082cb 100644
--- a/lib/table/rte_table_hash_ext.c
+++ b/lib/table/rte_table_hash_ext.c
@@ -11,6 +11,9 @@
 
 #include "rte_table_hash.h"
 
+RTE_LOG_REGISTER_SUFFIX(table_hash_ext_logtype, hash.ext, INFO);
+#define RTE_LOGTYPE_TABLE table_hash_ext_logtype
+
 #define KEYS_PER_BUCKET4
 
 struct bucket {
diff --git a/lib/table/rte_table_hash_key16.c b/lib/table/rte_table_hash_key16.c
index 04d7fd64bd97..09fef5f14ce7 100644
--- a/lib/table/rte_table_hash_key16.c
+++ b/lib/table/rte_table_hash_key16.c
@@ -11,6 +11,9 @@
 #include "rte_table_hash.h"
 #include "rte_lru.h"
 
+RTE_LOG_REGISTER_SUFFIX(table_hash16_logtype, hash16, INFO);
+#define RTE_LOGTYPE_TABLE table_hash16_logtype
+
 #define KEY_SIZE   16
 
 #define KEYS_PER_BUCKET4
diff --git a/lib/table/rte_table_hash_key32.c b/lib/table/rte_table_hash_key32.c
index 88d8f69c72ed..1abc459eee87 100644
--- a/lib/table/rte_table_hash_key32.c
+++ b/lib/table/rte_table_hash_key32.c
@@ -11,7 +11,10 @@
 #include "rte_table_hash.h"
 #include "rte_lru.h"
 
-#define KEY_SIZE   32
+RTE_LOG_REGISTER_SUFFIX(table_hash32_logtype, hash32, INFO);
+#define RTE_LOGTYPE_TABLE table_hash32_logtype
+
+#define KEY_SIZE   32
 
 #define KEYS_PER_BUCKET4
 
diff --git a/lib/table/rte_table_hash_key8.c b/lib/table/rte_table_hash_key8.c
index 035d24276946..d4bcdf9e 100644
--- a/lib/table/rte_table_hash_key8.c
+++ b/lib/ta

[PATCH v9 18/22] app/test: remove use of RTE_LOGTYPE_PIPELINE

[Stephen Hemminger]

Instead of using static type PIPELINE for logging in test application
use stderr instead.  If not testing RTE_LOG() better to not use
it since log also goes to syslog.

Signed-off-by: Stephen Hemminger 
---
 app/test/test_table_acl.c  | 50 --
 app/test/test_table_pipeline.c | 40 +--
 2 files changed, 43 insertions(+), 47 deletions(-)

diff --git a/app/test/test_table_acl.c b/app/test/test_table_acl.c
index e66f06b84d0a..dff9bddfb948 100644
--- a/app/test/test_table_acl.c
+++ b/app/test/test_table_acl.c
@@ -165,7 +165,7 @@ parse_cb_ipv4_rule(char *str, struct 
rte_table_acl_rule_add_params *v)
&v->field_value[SRC_FIELD_IPV4].value.u32,
&v->field_value[SRC_FIELD_IPV4].mask_range.u32);
if (rc != 0) {
-   RTE_LOG(ERR, PIPELINE, "failed to read src address/mask: %s\n",
+   fprintf(stderr, "failed to read src address/mask: %s\n",
in[CB_FLD_SRC_ADDR]);
return rc;
}
@@ -178,7 +178,7 @@ parse_cb_ipv4_rule(char *str, struct 
rte_table_acl_rule_add_params *v)
&v->field_value[DST_FIELD_IPV4].value.u32,
&v->field_value[DST_FIELD_IPV4].mask_range.u32);
if (rc != 0) {
-   RTE_LOG(ERR, PIPELINE, "failed to read dest address/mask: %s\n",
+   fprintf(stderr, "failed to read dest address/mask: %s\n",
in[CB_FLD_DST_ADDR]);
return rc;
}
@@ -190,7 +190,7 @@ parse_cb_ipv4_rule(char *str, struct 
rte_table_acl_rule_add_params *v)
&v->field_value[SRCP_FIELD_IPV4].value.u16,
&v->field_value[SRCP_FIELD_IPV4].mask_range.u16);
if (rc != 0) {
-   RTE_LOG(ERR, PIPELINE, "failed to read source port range: %s\n",
+   fprintf(stderr, "failed to read source port range: %s\n",
in[CB_FLD_SRC_PORT_RANGE]);
return rc;
}
@@ -202,7 +202,7 @@ parse_cb_ipv4_rule(char *str, struct 
rte_table_acl_rule_add_params *v)
&v->field_value[DSTP_FIELD_IPV4].value.u16,
&v->field_value[DSTP_FIELD_IPV4].mask_range.u16);
if (rc != 0) {
-   RTE_LOG(ERR, PIPELINE, "failed to read dest port range: %s\n",
+   fprintf(stderr, "failed to read dest port range: %s\n",
in[CB_FLD_DST_PORT_RANGE]);
return rc;
}
@@ -254,7 +254,7 @@ parse_cb_ipv4_rule_del(char *str, struct 
rte_table_acl_rule_delete_params *v)
&v->field_value[SRC_FIELD_IPV4].value.u32,
&v->field_value[SRC_FIELD_IPV4].mask_range.u32);
if (rc != 0) {
-   RTE_LOG(ERR, PIPELINE, "failed to read src address/mask: %s\n",
+   fprintf(stderr, "failed to read src address/mask: %s\n",
in[CB_FLD_SRC_ADDR]);
return rc;
}
@@ -267,7 +267,7 @@ parse_cb_ipv4_rule_del(char *str, struct 
rte_table_acl_rule_delete_params *v)
&v->field_value[DST_FIELD_IPV4].value.u32,
&v->field_value[DST_FIELD_IPV4].mask_range.u32);
if (rc != 0) {
-   RTE_LOG(ERR, PIPELINE, "failed to read dest address/mask: %s\n",
+   fprintf(stderr, "failed to read dest address/mask: %s\n",
in[CB_FLD_DST_ADDR]);
return rc;
}
@@ -279,7 +279,7 @@ parse_cb_ipv4_rule_del(char *str, struct 
rte_table_acl_rule_delete_params *v)
&v->field_value[SRCP_FIELD_IPV4].value.u16,
&v->field_value[SRCP_FIELD_IPV4].mask_range.u16);
if (rc != 0) {
-   RTE_LOG(ERR, PIPELINE, "failed to read source port range: %s\n",
+   fprintf(stderr, "failed to read source port range: %s\n",
in[CB_FLD_SRC_PORT_RANGE]);
return rc;
}
@@ -291,7 +291,7 @@ parse_cb_ipv4_rule_del(char *str, struct 
rte_table_acl_rule_delete_params *v)
&v->field_value[DSTP_FIELD_IPV4].value.u16,
&v->field_value[DSTP_FIELD_IPV4].mask_range.u16);
if (rc != 0) {
-   RTE_LOG(ERR, PIPELINE, "failed to read dest port range: %s\n",
+   fprintf(stderr, "failed to read dest port range: %s\n",
in[CB_FLD_DST_PORT_RANGE]);
return rc;
}
@@ -346,7 +346,7 @@ setup_acl_pipeline(void)
/* Pipeline configuration */
p = rte_pipeline_create(&pipeline_params);
if (p == NULL) {
-   RTE_LOG(INFO, PIPELINE, "%s: Failed to configure pipeline\n",
+   fprintf(stderr, "%s: Failed to configure pipeline\n",
__func__);
goto fail;
}
@@ -410,7 +410,7 @@ setup_acl_pipeline(void)
table_params.f_action_miss = NULL;
table_params.action_data_size = 0;
 
-   RTE_LOG(INFO, PIPELINE, 

[PATCH v9 19/22] pipeline: replace RTE_LOGTYPE_PIPELINE with dynamic type

[Stephen Hemminger]

Use a dynamically allocated logtype.

Signed-off-by: Stephen Hemminger 
---
 lib/eal/common/eal_common_log.c | 1 -
 lib/eal/include/rte_log.h   | 2 +-
 lib/pipeline/rte_pipeline.c | 3 +++
 3 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/lib/eal/common/eal_common_log.c b/lib/eal/common/eal_common_log.c
index d640ed3c88b9..a3498d1a2faf 100644
--- a/lib/eal/common/eal_common_log.c
+++ b/lib/eal/common/eal_common_log.c
@@ -351,7 +351,6 @@ static const struct logtype logtype_strings[] = {
{RTE_LOGTYPE_EAL,"lib.eal"},
{RTE_LOGTYPE_PMD,"pmd"},
{RTE_LOGTYPE_HASH,   "lib.hash"},
-   {RTE_LOGTYPE_PIPELINE,   "lib.pipeline"},
{RTE_LOGTYPE_CRYPTODEV,  "lib.cryptodev"},
{RTE_LOGTYPE_EVENTDEV,   "lib.eventdev"},
{RTE_LOGTYPE_USER1,  "user1"},
diff --git a/lib/eal/include/rte_log.h b/lib/eal/include/rte_log.h
index 934bddff9dfa..7473fd53505a 100644
--- a/lib/eal/include/rte_log.h
+++ b/lib/eal/include/rte_log.h
@@ -41,7 +41,7 @@ extern "C" {
 /* was RTE_LOGTYPE_SCHED */
 /* was RTE_LOGTYPE_PORT */
 /* was RTE_LOGTYPE_TABLE */
-#define RTE_LOGTYPE_PIPELINE  15 /**< Log related to pipeline. */
+/* was RTE_LOGTYPE_PIPELINE */
 /* was RTE_LOGTYPE_MBUF */
 #define RTE_LOGTYPE_CRYPTODEV 17 /**< Log related to cryptodev. */
 /* was RTE_LOGTYPE_EFD */
diff --git a/lib/pipeline/rte_pipeline.c b/lib/pipeline/rte_pipeline.c
index ff86c7cf96bf..30919cd9fe30 100644
--- a/lib/pipeline/rte_pipeline.c
+++ b/lib/pipeline/rte_pipeline.c
@@ -12,6 +12,9 @@
 
 #include "rte_pipeline.h"
 
+RTE_LOG_REGISTER_DEFAULT(pipeline_logtype, INFO);
+#define RTE_LOGTYPE_PIPELINE pipeline_logtype
+
 #define RTE_TABLE_INVALID UINT32_MAX
 
 #ifdef RTE_PIPELINE_STATS_COLLECT
-- 
2.39.1

[PATCH v9 20/22] hash: move rte_thash_gfni stubs out of header file

[Stephen Hemminger]

Having stubs in header file makes it harder to update
RTE_LOG(). Also modify to only print warning once.

Signed-off-by: Stephen Hemminger 
---
 lib/hash/meson.build  |  8 ++-
 lib/hash/rte_thash_gfni.c | 47 +++
 lib/hash/rte_thash_gfni.h | 28 +--
 lib/hash/version.map  |  4 
 4 files changed, 63 insertions(+), 24 deletions(-)
 create mode 100644 lib/hash/rte_thash_gfni.c

diff --git a/lib/hash/meson.build b/lib/hash/meson.build
index 2f757d45f9bc..e56ee8572564 100644
--- a/lib/hash/meson.build
+++ b/lib/hash/meson.build
@@ -17,7 +17,13 @@ indirect_headers += files(
 'rte_thash_x86_gfni.h',
 )
 
-sources = files('rte_cuckoo_hash.c', 'rte_fbk_hash.c', 'rte_thash.c')
+sources = files(
+'rte_cuckoo_hash.c',
+'rte_fbk_hash.c',
+'rte_thash.c',
+'rte_thash_gfni.c'
+)
+
 deps += ['net']
 deps += ['ring']
 deps += ['rcu']
diff --git a/lib/hash/rte_thash_gfni.c b/lib/hash/rte_thash_gfni.c
new file mode 100644
index ..eb334185725c
--- /dev/null
+++ b/lib/hash/rte_thash_gfni.c
@@ -0,0 +1,47 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2021 Intel Corporation
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+
+#ifndef RTE_THASH_GFNI_DEFINED
+
+uint32_t
+rte_thash_gfni(const uint64_t *mtrx __rte_unused,
+  const uint8_t *key __rte_unused, int len __rte_unused)
+{
+   static bool warned;
+
+   if (!warned) {
+   warned = true;
+   RTE_LOG(ERR, HASH,
+   "%s is undefined under given arch\n", __func__);
+   }
+
+   return 0;
+}
+
+void
+rte_thash_gfni_bulk(const uint64_t *mtrx __rte_unused,
+   int len __rte_unused, uint8_t *tuple[] __rte_unused,
+   uint32_t val[], uint32_t num)
+{
+   unsigned int i;
+
+   static bool warned;
+
+   if (!warned) {
+   warned = true;
+   RTE_LOG(ERR, HASH,
+   "%s is undefined under given arch\n", __func__);
+   }
+
+   for (i = 0; i < num; i++)
+   val[i] = 0;
+}
+
+#endif
diff --git a/lib/hash/rte_thash_gfni.h b/lib/hash/rte_thash_gfni.h
index ef90faa302d1..86208eb45ebb 100644
--- a/lib/hash/rte_thash_gfni.h
+++ b/lib/hash/rte_thash_gfni.h
@@ -9,13 +9,8 @@
 extern "C" {
 #endif
 
-#include 
-#include 
-
 #ifdef RTE_ARCH_X86
-
 #include 
-
 #endif
 
 #ifndef RTE_THASH_GFNI_DEFINED
@@ -38,13 +33,8 @@ extern "C" {
  *  Calculated Toeplitz hash value.
  */
 __rte_experimental
-static inline uint32_t
-rte_thash_gfni(const uint64_t *mtrx __rte_unused,
-   const uint8_t *key __rte_unused, int len __rte_unused)
-{
-   RTE_LOG(ERR, HASH, "%s is undefined under given arch\n", __func__);
-   return 0;
-}
+uint32_t
+rte_thash_gfni(const uint64_t *mtrx, const uint8_t *key, int len);
 
 /**
  * Bulk implementation for Toeplitz hash.
@@ -67,17 +57,9 @@ rte_thash_gfni(const uint64_t *mtrx __rte_unused,
  *  Number of tuples to hash.
  */
 __rte_experimental
-static inline void
-rte_thash_gfni_bulk(const uint64_t *mtrx __rte_unused,
-   int len __rte_unused, uint8_t *tuple[] __rte_unused,
-   uint32_t val[], uint32_t num)
-{
-   unsigned int i;
-
-   RTE_LOG(ERR, HASH, "%s is undefined under given arch\n", __func__);
-   for (i = 0; i < num; i++)
-   val[i] = 0;
-}
+void
+rte_thash_gfni_bulk(const uint64_t *mtrx, int len, uint8_t *tuple[],
+   uint32_t val[], uint32_t num);
 
 #endif /* RTE_THASH_GFNI_DEFINED */
 
diff --git a/lib/hash/version.map b/lib/hash/version.map
index bdcebd19c29b..f03b047b2eec 100644
--- a/lib/hash/version.map
+++ b/lib/hash/version.map
@@ -51,4 +51,8 @@ EXPERIMENTAL {
rte_thash_complete_matrix;
rte_thash_get_gfni_matrices;
rte_thash_gfni_supported;
+
+   # added in 22.07
+   rte_thash_gfni;
+   rte_thash_gfni_bulk;
 };
-- 
2.39.1

[PATCH v9 21/22] hash: move rte_hash_set_alg out header

[Stephen Hemminger]

The code for setting algorithm for hash is not at all perf sensitive,
and doing it inline has a couple of problems. First, it means that if
multiple files include the header, then the initialization gets done
multiple times. But also, it makes it harder to fix usage of RTE_LOG().

Despite what the checking script say. This is not an ABI change, the
previous version inlined the same code; therefore both old and new code
will work the same.

Signed-off-by: Stephen Hemminger 
---
 lib/hash/meson.build |  1 +
 lib/hash/rte_crc_arm64.h |  8 ++---
 lib/hash/rte_crc_x86.h   | 10 +++---
 lib/hash/rte_hash_crc.c  | 68 
 lib/hash/rte_hash_crc.h  | 48 ++--
 lib/hash/version.map |  7 +
 6 files changed, 88 insertions(+), 54 deletions(-)
 create mode 100644 lib/hash/rte_hash_crc.c

diff --git a/lib/hash/meson.build b/lib/hash/meson.build
index e56ee8572564..c345c6f561fc 100644
--- a/lib/hash/meson.build
+++ b/lib/hash/meson.build
@@ -19,6 +19,7 @@ indirect_headers += files(
 
 sources = files(
 'rte_cuckoo_hash.c',
+'rte_hash_crc.c',
 'rte_fbk_hash.c',
 'rte_thash.c',
 'rte_thash_gfni.c'
diff --git a/lib/hash/rte_crc_arm64.h b/lib/hash/rte_crc_arm64.h
index c9f52510871b..414fe065caa8 100644
--- a/lib/hash/rte_crc_arm64.h
+++ b/lib/hash/rte_crc_arm64.h
@@ -53,7 +53,7 @@ crc32c_arm64_u64(uint64_t data, uint32_t init_val)
 static inline uint32_t
 rte_hash_crc_1byte(uint8_t data, uint32_t init_val)
 {
-   if (likely(crc32_alg & CRC32_ARM64))
+   if (likely(rte_hash_crc32_alg & CRC32_ARM64))
return crc32c_arm64_u8(data, init_val);
 
return crc32c_1byte(data, init_val);
@@ -67,7 +67,7 @@ rte_hash_crc_1byte(uint8_t data, uint32_t init_val)
 static inline uint32_t
 rte_hash_crc_2byte(uint16_t data, uint32_t init_val)
 {
-   if (likely(crc32_alg & CRC32_ARM64))
+   if (likely(rte_hash_crc32_alg & CRC32_ARM64))
return crc32c_arm64_u16(data, init_val);
 
return crc32c_2bytes(data, init_val);
@@ -81,7 +81,7 @@ rte_hash_crc_2byte(uint16_t data, uint32_t init_val)
 static inline uint32_t
 rte_hash_crc_4byte(uint32_t data, uint32_t init_val)
 {
-   if (likely(crc32_alg & CRC32_ARM64))
+   if (likely(rte_hash_crc32_alg & CRC32_ARM64))
return crc32c_arm64_u32(data, init_val);
 
return crc32c_1word(data, init_val);
@@ -95,7 +95,7 @@ rte_hash_crc_4byte(uint32_t data, uint32_t init_val)
 static inline uint32_t
 rte_hash_crc_8byte(uint64_t data, uint32_t init_val)
 {
-   if (likely(crc32_alg & CRC32_ARM64))
+   if (likely(rte_hash_crc32_alg & CRC32_ARM64))
return crc32c_arm64_u64(data, init_val);
 
return crc32c_2words(data, init_val);
diff --git a/lib/hash/rte_crc_x86.h b/lib/hash/rte_crc_x86.h
index 205bc182be77..3b865e251db2 100644
--- a/lib/hash/rte_crc_x86.h
+++ b/lib/hash/rte_crc_x86.h
@@ -67,7 +67,7 @@ crc32c_sse42_u64(uint64_t data, uint64_t init_val)
 static inline uint32_t
 rte_hash_crc_1byte(uint8_t data, uint32_t init_val)
 {
-   if (likely(crc32_alg & CRC32_SSE42))
+   if (likely(rte_hash_crc32_alg & CRC32_SSE42))
return crc32c_sse42_u8(data, init_val);
 
return crc32c_1byte(data, init_val);
@@ -81,7 +81,7 @@ rte_hash_crc_1byte(uint8_t data, uint32_t init_val)
 static inline uint32_t
 rte_hash_crc_2byte(uint16_t data, uint32_t init_val)
 {
-   if (likely(crc32_alg & CRC32_SSE42))
+   if (likely(rte_hash_crc32_alg & CRC32_SSE42))
return crc32c_sse42_u16(data, init_val);
 
return crc32c_2bytes(data, init_val);
@@ -95,7 +95,7 @@ rte_hash_crc_2byte(uint16_t data, uint32_t init_val)
 static inline uint32_t
 rte_hash_crc_4byte(uint32_t data, uint32_t init_val)
 {
-   if (likely(crc32_alg & CRC32_SSE42))
+   if (likely(rte_hash_crc32_alg & CRC32_SSE42))
return crc32c_sse42_u32(data, init_val);
 
return crc32c_1word(data, init_val);
@@ -110,11 +110,11 @@ static inline uint32_t
 rte_hash_crc_8byte(uint64_t data, uint32_t init_val)
 {
 #ifdef RTE_ARCH_X86_64
-   if (likely(crc32_alg == CRC32_SSE42_x64))
+   if (likely(rte_hash_crc32_alg == CRC32_SSE42_x64))
return crc32c_sse42_u64(data, init_val);
 #endif
 
-   if (likely(crc32_alg & CRC32_SSE42))
+   if (likely(rte_hash_crc32_alg & CRC32_SSE42))
return crc32c_sse42_u64_mimic(data, init_val);
 
return crc32c_2words(data, init_val);
diff --git a/lib/hash/rte_hash_crc.c b/lib/hash/rte_hash_crc.c
new file mode 100644
index ..1439d8a71f6a
--- /dev/null
+++ b/lib/hash/rte_hash_crc.c
@@ -0,0 +1,68 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2010-2014 Intel Corporation
+ */
+
+#include 
+#include 
+
+#include "rte_hash_crc.h"
+
+RTE_LOG_REGISTER_SUFFIX(hash_crc_logtype, crc, INFO);
+#define RTE_LOGTYPE_HASH_CRC hash_crc_logtype
+
+uint8_t rte_hash_crc32_alg = CRC32_SW;
+
+/**
+ * Allow or disall

[PATCH v9 22/22] hash: convert RTE_LOGTYPE_HASH to dynamic type

[Stephen Hemminger]

Use dynamic type for hash and add subtypes for crc and gfni.

Signed-off-by: Stephen Hemminger 
---
 lib/eal/common/eal_common_log.c | 1 -
 lib/eal/include/rte_log.h   | 2 +-
 lib/hash/rte_cuckoo_hash.c  | 5 +
 lib/hash/rte_fbk_hash.c | 5 +
 lib/hash/rte_thash.c| 3 +++
 lib/hash/rte_thash_gfni.c   | 3 +++
 6 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/lib/eal/common/eal_common_log.c b/lib/eal/common/eal_common_log.c
index a3498d1a2faf..704924e822d0 100644
--- a/lib/eal/common/eal_common_log.c
+++ b/lib/eal/common/eal_common_log.c
@@ -350,7 +350,6 @@ struct logtype {
 static const struct logtype logtype_strings[] = {
{RTE_LOGTYPE_EAL,"lib.eal"},
{RTE_LOGTYPE_PMD,"pmd"},
-   {RTE_LOGTYPE_HASH,   "lib.hash"},
{RTE_LOGTYPE_CRYPTODEV,  "lib.cryptodev"},
{RTE_LOGTYPE_EVENTDEV,   "lib.eventdev"},
{RTE_LOGTYPE_USER1,  "user1"},
diff --git a/lib/eal/include/rte_log.h b/lib/eal/include/rte_log.h
index 7473fd53505a..29db07881a5a 100644
--- a/lib/eal/include/rte_log.h
+++ b/lib/eal/include/rte_log.h
@@ -32,7 +32,7 @@ extern "C" {
 /* was RTE_LOGTYPE_MEMPOOL */
 /* was RTE_LOGTYPE_TIMER */
 #define RTE_LOGTYPE_PMD5 /**< Log related to poll mode driver. */
-#define RTE_LOGTYPE_HASH   6 /**< Log related to hash table. */
+/* was RTE_LOGTYPE_HASH */
 /* was RTE_LOGTYPE_LPM */
 /* was RTE_LOGTYPE_KNI */
 /* was RTE_LOGTYPE_ACL */
diff --git a/lib/hash/rte_cuckoo_hash.c b/lib/hash/rte_cuckoo_hash.c
index 829b79c89a27..e2b07bfbad71 100644
--- a/lib/hash/rte_cuckoo_hash.c
+++ b/lib/hash/rte_cuckoo_hash.c
@@ -24,6 +24,11 @@
 #include 
 
 #include "rte_hash.h"
+
+/* needs to be before rte_cuckoo_hash.h */
+RTE_LOG_REGISTER_DEFAULT(hash_logtype, INFO);
+#define RTE_LOGTYPE_HASH hash_logtype
+
 #include "rte_cuckoo_hash.h"
 
 /* Mask of all flags supported by this version */
diff --git a/lib/hash/rte_fbk_hash.c b/lib/hash/rte_fbk_hash.c
index 538b23a4030a..b4c4c191abdc 100644
--- a/lib/hash/rte_fbk_hash.c
+++ b/lib/hash/rte_fbk_hash.c
@@ -8,6 +8,8 @@
 #include 
 
 #include 
+
+#include 
 #include 
 #include 
 #include 
@@ -18,6 +20,9 @@
 
 #include "rte_fbk_hash.h"
 
+RTE_LOG_REGISTER_SUFFIX(fbk_hash_logtype, fbk, INFO);
+#define RTE_LOGTYPE_HASH fbk_hash_logtype
+
 TAILQ_HEAD(rte_fbk_hash_list, rte_tailq_entry);
 
 static struct rte_tailq_elem rte_fbk_hash_tailq = {
diff --git a/lib/hash/rte_thash.c b/lib/hash/rte_thash.c
index 0249883b8d07..c1fd2e34c9d4 100644
--- a/lib/hash/rte_thash.c
+++ b/lib/hash/rte_thash.c
@@ -13,6 +13,9 @@
 #include 
 #include 
 
+RTE_LOG_REGISTER_SUFFIX(thash_logtype, thash, INFO);
+#define RTE_LOGTYPE_HASH thash_logtype
+
 #define THASH_NAME_LEN 64
 #define TOEPLITZ_HASH_LEN  32
 
diff --git a/lib/hash/rte_thash_gfni.c b/lib/hash/rte_thash_gfni.c
index eb334185725c..35206d575153 100644
--- a/lib/hash/rte_thash_gfni.c
+++ b/lib/hash/rte_thash_gfni.c
@@ -10,6 +10,9 @@
 
 #ifndef RTE_THASH_GFNI_DEFINED
 
+RTE_LOG_REGISTER_SUFFIX(hash_gfni_logtype, gfni, INFO);
+#define RTE_LOGTYPE_HASH hash_gfni_logtype
+
 uint32_t
 rte_thash_gfni(const uint64_t *mtrx __rte_unused,
   const uint8_t *key __rte_unused, int len __rte_unused)
-- 
2.39.1

[PATCH v6] hash: add XOR32 hash function

[Bili Dong]

An XOR32 hash is needed in the Software Switch (SWX) Pipeline for its
use case in P4. We implement it in this patch so it could be easily
registered in the pipeline later.

Signed-off-by: Bili Dong 
---
 .mailmap   |  1 +
 app/test/test_hash_functions.c | 33 +++--
 lib/hash/rte_hash_xor.h| 87 ++
 3 files changed, 118 insertions(+), 3 deletions(-)
 create mode 100644 lib/hash/rte_hash_xor.h

diff --git a/.mailmap b/.mailmap
index a9f4f28fba..3e9bec29d5 100644
--- a/.mailmap
+++ b/.mailmap
@@ -159,6 +159,7 @@ Bernard Iremonger 
 Bert van Leeuwen 
 Bhagyada Modali 
 Bharat Mota 
+Bili Dong 
 Bill Hong 
 Billy McFall 
 Billy O'Mahony 
diff --git a/app/test/test_hash_functions.c b/app/test/test_hash_functions.c
index 76d51b6e71..53e296fec4 100644
--- a/app/test/test_hash_functions.c
+++ b/app/test/test_hash_functions.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "test.h"
 
@@ -22,8 +23,8 @@
  * Hash values calculated for key sizes from array "hashtest_key_lens"
  * and for initial values from array "hashtest_initvals.
  * Each key will be formed by increasing each byte by 1:
- * e.g.: key size = 4, key = 0x03020100
- *   key size = 8, key = 0x0706050403020100
+ * e.g.: key size = 4, key = 0x00010203
+ *   key size = 8, key = 0x0001020304050607
  */
 static uint32_t hash_values_jhash[2][12] = {{
0x8ba9414b, 0xdf0d39c9,
@@ -51,6 +52,19 @@ static uint32_t hash_values_crc[2][12] = {{
0x789c104f, 0x53028d3e
 }
 };
+static uint32_t hash_values_xor32[2][12] = {{
+   0x, 0x0001,
+   0x00010203, 0x04040404, 0x, 0x,
+   0x, 0x, 0x0c040404, 0x000d0e0f,
+   0x04212223, 0x04040404
+},
+{
+   0xdeadbeef, 0xdeacbeef,
+   0xdeacbcec, 0xdaa9baeb, 0xdeadbeef, 0xdeadbeef,
+   0xdeadbeef, 0xdeadbeef, 0xd2a9baeb, 0xdea0b0e0,
+   0xda8c9ccc, 0xdaa9baeb
+}
+};
 
 
/***
  * Hash function performance test configuration section. Each performance test
@@ -61,7 +75,7 @@ static uint32_t hash_values_crc[2][12] = {{
  */
 #define HASHTEST_ITERATIONS 100
 #define MAX_KEYSIZE 64
-static rte_hash_function hashtest_funcs[] = {rte_jhash, rte_hash_crc};
+static rte_hash_function hashtest_funcs[] = {rte_jhash, rte_hash_crc, 
rte_hash_xor32};
 static uint32_t hashtest_initvals[] = {0, 0xdeadbeef};
 static uint32_t hashtest_key_lens[] = {
1, 2, /* Unusual key sizes */
@@ -85,6 +99,9 @@ get_hash_name(rte_hash_function f)
if (f == rte_hash_crc)
return "rte_hash_crc";
 
+   if (f == rte_hash_xor32)
+   return "rte_hash_xor32";
+
return "UnknownHash";
 }
 
@@ -173,6 +190,16 @@ verify_precalculated_hash_func_tests(void)
   hash_values_crc[j][i], hash);
return -1;
}
+
+   hash = rte_hash_xor32(key, hashtest_key_lens[i],
+   hashtest_initvals[j]);
+   if (hash != hash_values_xor32[j][i]) {
+   printf("XOR32 for %u bytes with initial value 
0x%x."
+  " Expected 0x%x, but got 0x%x\n",
+  hashtest_key_lens[i], 
hashtest_initvals[j],
+  hash_values_xor32[j][i], hash);
+   return -1;
+   }
}
}
 
diff --git a/lib/hash/rte_hash_xor.h b/lib/hash/rte_hash_xor.h
new file mode 100644
index 00..366adbe64c
--- /dev/null
+++ b/lib/hash/rte_hash_xor.h
@@ -0,0 +1,87 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2023 Intel Corporation
+ */
+
+#ifndef _RTE_HASH_XOR_H_
+#define _RTE_HASH_XOR_H_
+
+/**
+ * @file
+ *
+ * RTE XOR Hash
+ */
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include 
+
+#include 
+
+/**
+ * Calculate XOR32 hash on user-supplied byte array.
+ *
+ * @param data
+ *   Data to perform hash on.
+ * @param data_len
+ *   How many bytes to use to calculate hash value.
+ * @param init_val
+ *   Value to initialise hash generator.
+ * @return
+ *   32bit calculated hash value.
+ */
+static inline uint32_t
+rte_hash_xor32(const void *data, uint32_t data_len, uint32_t init_val)
+{
+   uint32_t hash32;
+   const uint8_t *data8 = data;
+
+   /* Minimize byte order conversions depending on data length. */
+   if (data_len >= 8) {
+   /* For longer arrays, operate in big endian. */
+   uint64_t hash64 = rte_cpu_to_be_32(init_val);
+
+   uint32_t i;
+   for (i = 0; i < data_len / 8; i++) {
+   hash64 ^= *(const uint64_t *)data8;
+   data8 += 8;
+   }
+
+   if (data_len & 0x4) {
+   has

Re: [PATCH v2] app/testpmd: fix flex item compilation error

[Thomas Monjalon]

21/02/2023 11:02, Rongwei Liu:
> When configuring meson with option "--optimization=1", gcc
> complains "maybe-uninitialized" warning and it was treated as
> error since Werror is enabled.
> 
> Assign fp to NULL at declaration can avoid this.

That's probably a false positive,
but I'm OK to workaround it this way, especially in a test application.

> Bugzilla ID: 1163
> Fixes: c8e25fbf1440 ("ethdev: add flow flex modify")
> Cc: sta...@dpdk.org
> 
> Reported-by: gaodaxue 
> Signed-off-by: Rongwei Liu 
> ---
> - struct flex_item *fp;
> + struct flex_item *fp = NULL;

Applied, thanks.

RE: [PATCH v2 2/2] test/mempool: add zero-copy API's

[Kamalakshitha Aligeri]

Hi Thomas,

Do you want me to squash the unit tests in the mempool lib patch or do I have 
to wait for the reviews from mempool maintainers


Thanks,
Kamalakshitha

> -Original Message-
> From: Thomas Monjalon 
> Sent: Monday, February 20, 2023 5:53 AM
> To: olivier.m...@6wind.com; andrew.rybche...@oktetlabs.ru; Morten
> Brørup 
> Cc: Kamalakshitha Aligeri ;
> yuying.zh...@intel.com; beilei.x...@intel.com;
> bruce.richard...@intel.com; konstantin.anan...@huawei.com; Honnappa
> Nagarahalli ; Ruifeng Wang
> ; Feifei Wang ;
> david.march...@redhat.com; dev@dpdk.org; nd 
> Subject: Re: [PATCH v2 2/2] test/mempool: add zero-copy API's
> 
> 10/02/2023 08:33, Morten Brørup:
> > > From: Kamalakshitha Aligeri [mailto:kamalakshitha.alig...@arm.com]
> > > Sent: Friday, 10 February 2023 07.54
> > >
> > > Added mempool test cases with zero-copy get and put API's
> > >
> > > Signed-off-by: Kamalakshitha Aligeri 
> > > Reviewed-by: Ruifeng Wang 
> > > Reviewed-by: Feifei Wang 
> >
> > I already acked v1 of this patch, but here it is again for Patchwork:
> >
> > Acked-by: Morten Brørup 
> >
> > > ---
> > > Link:
> > >
> https://patchwork.dpdk.org/project/dpdk/patch/20230209145833.129986-1-
> > > m...@smartsharesystems.com/
> >
> > @David, here's the zero-copy mempool cache API test cases you were
> asking for.
> 
> The unit tests should be squashed in the mempool lib patch.
> 
> Also I would to see a review from the mempool maintainers.
> 

Updated invitation with note: DTS Working Group - DPDK @ Every 2 weeks from 9am to 10am on Wednesday from Wed Oct 19, 2022 to Tue Feb 21 (EDT) (dev@dpdk.org)

[nsouthern]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:America/Detroit
X-LIC-LOCATION:America/Detroit
BEGIN:DAYLIGHT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
DTSTART:19700308T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
DTSTART:19701101T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=America/Detroit:20221019T09
DTEND;TZID=America/Detroit:20221019T10
RRULE:FREQ=WEEKLY;WKST=SU;UNTIL=20230208T045959Z;INTERVAL=2;BYDAY=WE
DTSTAMP:20230221T202018Z
ORGANIZER;CN=DPDK (Data Plane Development Kit):mailto:c_f567a7194b6c395c324
 36bd7b5fbb888db5102d6adfd5fd9f8f8eff1511a1...@group.calendar.google.com
UID:6s3tlf8sg4soovm7bjkoqsg...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;RSVP=TRU
 E;CN=Lincoln Lavoie;X-NUM-GUESTS=0:mailto:lylav...@iol.unh.edu
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=lijuan...@intel.com;X-NUM-GUESTS=0:mailto:lijuan...@intel.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=n...@arm.com;X-NUM-GUESTS=0:mailto:n...@arm.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=honnappanagaraha...@gmail.com;X-NUM-GUESTS=0:mailto:honnappanagarah
 a...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=nsouth...@linuxfoundation.org;X-NUM-GUESTS=0:mailto:nsouthern@linux
 foundation.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=honnappa.nagaraha...@arm.com;X-NUM-GUESTS=0:mailto:honnappa.nagarah
 a...@arm.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=ohily...@iol.unh.edu;X-NUM-GUESTS=0:mailto:ohily...@iol.unh.edu
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=dev@dpdk.org;X-NUM-GUESTS=0:mailto:dev@dpdk.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=d...@dpdk.org;X-NUM-GUESTS=0:mailto:d...@dpdk.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=juraj.lin...@pantheon.tech;X-NUM-GUESTS=0:mailto:juraj.linkes@panth
 eon.tech
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN="Boyer, Andrew";X-NUM-GUESTS=0:mailto:andrew.bo...@amd.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=hemal.s...@broadcom.com;X-NUM-GUESTS=0:mailto:hemal.shah@broadcom.c
 om
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=kumaraparames...@gmail.com;X-NUM-GUESTS=0:mailto:kumaraparamesh92@gmail
 .com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;RSVP=TRU
 E;CN=pr...@iol.unh.edu;X-NUM-GUESTS=0:mailto:pr...@iol.unh.edu
X-MICROSOFT-CDO-OWNERAPPTID:398660684
CREATED:20221013T172652Z
DESCRIPTION:DPDK Project is inviting you to a scheduled Zoom meeting.Topic: DTS Working Group - DPDKTime: Oct 20\, 2022 09:00 AM Eastern T
 ime (US and Canada) \;  \;  \;  \; Every 2 weeks on Thu
 \, until Dec 14\, 2023\, 31 occurrence(s) \;  \;  \;  \
 ; Oct 20\, 2022 09:00 AM \;  \;  \;  \; Nov 3\, 2022 09
 :00 AM \;  \;  \;  \; Nov 17\, 2022 09:00 AM \;
   \;  \;  \; Dec 1\, 2022 09:00 AM \;  \;  \; &
 nbsp\; Dec 15\, 2022 09:00 AM \;  \;  \;  \; Dec 29\, 2
 022 09:00 AM \;  \;  \;  \; Jan 12\, 2023 09:00 AM&
 nbsp\;  \;  \;  \; Jan 26\, 2023 09:00 AM \;  \; &n
 bsp\;  \; Feb 9\, 2023 09:00 AM \;  \;  \;  \; Feb 
 23\, 2023 09:00 AM \;  \;  \;  \; Mar 9\, 2023 09:00 AM
  \;  \;  \;  \; Mar 23\, 2023 09:00 AM \;  
 \;  \;  \; Apr 6\, 2023 09:00 AM \;  \;  \;  \;
  Apr 20\, 2023 09:00 AM \;  \;  \;  \; May 4\, 2023 09:
 00 AM \;  \;  \;  \; May 18\, 2023 09:00 AM \; 
  \;  \;  \; Jun 1\, 2023 09:00 AM \;  \;  \; &n
 bsp\; Jun 15\, 2023 09:00 AM \;  \;  \;  \; Jun 29\, 20
 23 09:00 AM \;  \;  \;  \; Jul 13\, 2023 09:00 AM&n
 bsp\;  \;  \;  \; Jul 27\, 2023 09:00 AM \;  \; &nb
 sp\;  \; Aug 10\, 2023 09:00 AM \;  \;  \;  \; Aug 
 24\, 2023 09:00 AM \;  \;  \;  \; Sep 7\, 2023 09:00 AM
  \;  \;  \;  \; Sep 21\, 2023 09:00 AM \;  
 \;  \;  \; Oct 5\, 2023 09:00 AM \;  \;  \;  \;
  Oct 19\, 2023 09:00 AM \;  \;  \;  \; Nov 2\, 2023 09:
 00 AM \;  \;  \;  \; Nov 16\, 2023 09:00 AM \; 
  \;  \;  \; Nov 30\, 2023 09:00 AM \;  \;  \; &
 nbsp\; Dec 14\, 2023 09:00 AMPlease download and import the following i
 Calendar (.ics) files to your calendar system.Weekly: https://zoom.us/me
 eting/tJIodumhqDoiGddm__jlxmO14AUoLwAA_SST/ics?icsToken=98tyKuCuqzoqE9KUuBq
 ERowAGYj4c_Pwpn5HjadZkSDaCSxLbyynYsN3PZ5oMfnvJoin Zoom Meeting<
 br>https://zoom.us/j/96510961833?pwd=YUJHWXF0bjAzWHFkTnRRNThkT0xXQ
 T09">https://zoom.us/j/96510961833?pwd=YUJHWXF0bjAzWHFkTnRRNThkT0xXQT09
 Meeting ID: 965 1096 1833Passcode: 046886One tap mobile
 +13126266799\,\,96510961833#\,\,\,\,

Updated invitation with note: DTS Working Group - DPDK @ Every 2 weeks from 9am to 10am on Wednesday from Wed Feb 8 to Tue Feb 21 (EST) (dev@dpdk.org)

[nsouthern]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:America/Detroit
X-LIC-LOCATION:America/Detroit
BEGIN:DAYLIGHT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
DTSTART:19700308T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
DTSTART:19701101T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=America/Detroit:20230208T09
DTEND;TZID=America/Detroit:20230208T10
RRULE:FREQ=WEEKLY;WKST=SU;UNTIL=20230222T045959Z;INTERVAL=2;BYDAY=WE
DTSTAMP:20230221T202019Z
ORGANIZER;CN=DPDK (Data Plane Development Kit):mailto:c_f567a7194b6c395c324
 36bd7b5fbb888db5102d6adfd5fd9f8f8eff1511a1...@group.calendar.google.com
UID:6s3tlf8sg4soovm7bjkoqsghhr_r20230208t140...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;RSVP=TRU
 E;CN=Lincoln Lavoie;X-NUM-GUESTS=0:mailto:lylav...@iol.unh.edu
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=lijuan...@intel.com;X-NUM-GUESTS=0:mailto:lijuan...@intel.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=n...@arm.com;X-NUM-GUESTS=0:mailto:n...@arm.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=honnappanagaraha...@gmail.com;X-NUM-GUESTS=0:mailto:honnappanagarah
 a...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=nsouth...@linuxfoundation.org;X-NUM-GUESTS=0:mailto:nsouthern@linux
 foundation.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=honnappa.nagaraha...@arm.com;X-NUM-GUESTS=0:mailto:honnappa.nagarah
 a...@arm.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=DECLINED;RSVP=TRUE
 ;CN=ohily...@iol.unh.edu;X-NUM-GUESTS=0:mailto:ohily...@iol.unh.edu
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=juraj.lin...@pantheon.tech;X-NUM-GUESTS=0:mailto:juraj.linkes@pantheon.
 tech
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=hemal.s...@broadcom.com;X-NUM-GUESTS=0:mailto:hemal.shah@broadcom.c
 om
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=kumaraparames...@gmail.com;X-NUM-GUESTS=0:mailto:kumaraparamesh92@gmail
 .com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;RSVP=TRU
 E;CN=pr...@iol.unh.edu;X-NUM-GUESTS=0:mailto:pr...@iol.unh.edu
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;RSVP=TRU
 E;CN=srikanthyalavar...@gmail.com;X-NUM-GUESTS=0:mailto:srikanthyalavarthi@
 gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=rfo...@redhat.com;X-NUM-GUESTS=0:mailto:rfo...@redhat.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=dev@dpdk.org;X-NUM-GUESTS=0:mailto:dev@dpdk.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=d...@dpdk.org;X-NUM-GUESTS=0:mailto:d...@dpdk.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN="Boyer, Andrew";X-NUM-GUESTS=0:mailto:andrew.bo...@amd.com
X-MICROSOFT-CDO-OWNERAPPTID:1550386620
CREATED:20221013T172652Z
DESCRIPTION:DPDK Project is inviting you to a scheduled Zoom meeting.Topic: DTS Working Group - DPDKTime: Oct 20\, 2022 09:00 AM Eastern T
 ime (US and Canada) \;  \;  \;  \; Every 2 weeks on Thu
 \, until Dec 14\, 2023\, 31 occurrence(s) \;  \;  \;  \
 ; Oct 20\, 2022 09:00 AM \;  \;  \;  \; Nov 3\, 2022 09
 :00 AM \;  \;  \;  \; Nov 17\, 2022 09:00 AM \;
   \;  \;  \; Dec 1\, 2022 09:00 AM \;  \;  \; &
 nbsp\; Dec 15\, 2022 09:00 AM \;  \;  \;  \; Dec 29\, 2
 022 09:00 AM \;  \;  \;  \; Jan 12\, 2023 09:00 AM&
 nbsp\;  \;  \;  \; Jan 26\, 2023 09:00 AM \;  \; &n
 bsp\;  \; Feb 9\, 2023 09:00 AM \;  \;  \;  \; Feb 
 23\, 2023 09:00 AM \;  \;  \;  \; Mar 9\, 2023 09:00 AM
  \;  \;  \;  \; Mar 23\, 2023 09:00 AM \;  
 \;  \;  \; Apr 6\, 2023 09:00 AM \;  \;  \;  \;
  Apr 20\, 2023 09:00 AM \;  \;  \;  \; May 4\, 2023 09:
 00 AM \;  \;  \;  \; May 18\, 2023 09:00 AM \; 
  \;  \;  \; Jun 1\, 2023 09:00 AM \;  \;  \; &n
 bsp\; Jun 15\, 2023 09:00 AM \;  \;  \;  \; Jun 29\, 20
 23 09:00 AM \;  \;  \;  \; Jul 13\, 2023 09:00 AM&n
 bsp\;  \;  \;  \; Jul 27\, 2023 09:00 AM \;  \; &nb
 sp\;  \; Aug 10\, 2023 09:00 AM \;  \;  \;  \; Aug 
 24\, 2023 09:00 AM \;  \;  \;  \; Sep 7\, 2023 09:00 AM
  \;  \;  \;  \; Sep 21\, 2023 09:00 AM \;  
 \;  \;  \; Oct 5\, 2023 09:00 AM \;  \;  \;  \;
  Oct 19\, 2023 09:00 AM \;  \;  \;  \; Nov 2\, 2023 09:
 00 AM \;  \;  \;  \; Nov 16\, 2023 09:00 AM \; 
  \;  \;  \; Nov 30\, 2023 09:00 AM \;  \;  \; &
 nbsp\; Dec 14\, 2023 09:00 AMPlease download and import the following i
 Calendar (.ics) files to your calendar system.Weekly: https://zoom.us/me
 eting/tJIodumhqDoiGddm__jlxmO14AUoLwAA_SST/ics?icsToken=98tyKuC

DTS Working Group Cancellation

[Nathan Southern]

Dear DPDK Community,

For the time being the DPDK DTS Working Group, starting tomorrow, has been
officially cancelled per internal request.

Any questions, let me know. Thank you!

Nathan

Nathan C. Southern, Project Coordinator

Data Plane Development Kit

The Linux Foundation

248.835.4812 (mobile)

nsouth...@linuxfoundation.org

[PATCH] net/mana: use RTE_LOG_DP for logs on datapath

[longli]

From: Long Li 

Change all the logging statements on the datapath to use RTE_LOG_DP() to
reduce CPU overhead when logging is not enabled for datapath.

Fixes: 517ed6e2d5 ("net/mana: add basic driver with build environment")
Cc: sta...@dpdk.org
Signed-off-by: Long Li 
---
 drivers/net/mana/gdma.c | 56 +++---
 drivers/net/mana/mana.h |  3 ++
 drivers/net/mana/mp.c   |  4 +--
 drivers/net/mana/mr.c   | 77 -
 drivers/net/mana/rx.c   | 32 -
 drivers/net/mana/tx.c   | 66 +--
 6 files changed, 120 insertions(+), 118 deletions(-)

diff --git a/drivers/net/mana/gdma.c b/drivers/net/mana/gdma.c
index 3d4039014f..f637084137 100644
--- a/drivers/net/mana/gdma.c
+++ b/drivers/net/mana/gdma.c
@@ -14,12 +14,12 @@ gdma_get_wqe_pointer(struct mana_gdma_queue *queue)
(queue->head * GDMA_WQE_ALIGNMENT_UNIT_SIZE) &
(queue->size - 1);
 
-   DRV_LOG(DEBUG, "txq sq_head %u sq_size %u offset_in_bytes %u",
-   queue->head, queue->size, offset_in_bytes);
+   DP_LOG(DEBUG, "txq sq_head %u sq_size %u offset_in_bytes %u",
+  queue->head, queue->size, offset_in_bytes);
 
if (offset_in_bytes + GDMA_WQE_ALIGNMENT_UNIT_SIZE > queue->size)
-   DRV_LOG(ERR, "fatal error: offset_in_bytes %u too big",
-   offset_in_bytes);
+   DP_LOG(ERR, "fatal error: offset_in_bytes %u too big",
+  offset_in_bytes);
 
return ((uint8_t *)queue->buffer) + offset_in_bytes;
 }
@@ -39,11 +39,11 @@ write_dma_client_oob(uint8_t *work_queue_buffer_pointer,
client_oob_size / sizeof(uint32_t);
header->client_data_unit = work_request->client_data_unit;
 
-   DRV_LOG(DEBUG, "queue buf %p sgl %u oob_h %u du %u oob_buf %p oob_b %u",
-   work_queue_buffer_pointer, header->num_sgl_entries,
-   header->inline_client_oob_size_in_dwords,
-   header->client_data_unit, work_request->inline_oob_data,
-   work_request->inline_oob_size_in_bytes);
+   DP_LOG(DEBUG, "queue buf %p sgl %u oob_h %u du %u oob_buf %p oob_b %u",
+  work_queue_buffer_pointer, header->num_sgl_entries,
+  header->inline_client_oob_size_in_dwords,
+  header->client_data_unit, work_request->inline_oob_data,
+  work_request->inline_oob_size_in_bytes);
 
p += sizeof(struct gdma_wqe_dma_oob);
if (work_request->inline_oob_data &&
@@ -73,8 +73,8 @@ write_scatter_gather_list(uint8_t *work_queue_head_pointer,
uint32_t size_to_queue_end;
uint32_t sge_list_size;
 
-   DRV_LOG(DEBUG, "work_queue_cur_pointer %p work_request->flags %x",
-   work_queue_cur_pointer, work_request->flags);
+   DP_LOG(DEBUG, "work_queue_cur_pointer %p work_request->flags %x",
+  work_queue_cur_pointer, work_request->flags);
 
num_sge = work_request->num_sgl_elements;
sge_list = work_request->sgl;
@@ -110,9 +110,9 @@ write_scatter_gather_list(uint8_t *work_queue_head_pointer,
sge_list_size = size;
}
 
-   DRV_LOG(DEBUG, "sge %u address 0x%" PRIx64 " size %u key %u list_s %u",
-   num_sge, sge_list->address, sge_list->size,
-   sge_list->memory_key, sge_list_size);
+   DP_LOG(DEBUG, "sge %u address 0x%" PRIx64 " size %u key %u list_s %u",
+  num_sge, sge_list->address, sge_list->size,
+  sge_list->memory_key, sge_list_size);
 
return sge_list_size;
 }
@@ -141,13 +141,13 @@ gdma_post_work_request(struct mana_gdma_queue *queue,
uint32_t queue_free_units = queue->count - (queue->head - queue->tail);
 
if (wqe_size / GDMA_WQE_ALIGNMENT_UNIT_SIZE > queue_free_units) {
-   DRV_LOG(DEBUG, "WQE size %u queue count %u head %u tail %u",
-   wqe_size, queue->count, queue->head, queue->tail);
+   DP_LOG(DEBUG, "WQE size %u queue count %u head %u tail %u",
+  wqe_size, queue->count, queue->head, queue->tail);
return -EBUSY;
}
 
-   DRV_LOG(DEBUG, "client_oob_size %u sgl_data_size %u wqe_size %u",
-   client_oob_size, sgl_data_size, wqe_size);
+   DP_LOG(DEBUG, "client_oob_size %u sgl_data_size %u wqe_size %u",
+  client_oob_size, sgl_data_size, wqe_size);
 
if (wqe_info) {
wqe_info->wqe_index =
@@ -242,15 +242,15 @@ mana_ring_doorbell(void *db_page, enum gdma_queue_types 
queue_type,
break;
 
default:
-   DRV_LOG(ERR, "Unsupported queue type %d", queue_type);
+   DP_LOG(ERR, "Unsupported queue type %d", queue_type);
return -1;
}
 
/* Ensure all writes are done before ringing doorbell */
rte_wmb();
 
-   DRV_LOG(DEBUG, "db_page %p addr %p queue_id %u type %u tail %u arm 

Re: [PATCH v6] hash: add XOR32 hash function

[Bili Dong]

The reported performance issue
 is a
mystery to me. Does anyone have an idea what's going on?

Thanks,
Bili

On Tue, Feb 21, 2023 at 11:37 AM Bili Dong  wrote:

> An XOR32 hash is needed in the Software Switch (SWX) Pipeline for its
> use case in P4. We implement it in this patch so it could be easily
> registered in the pipeline later.
>
> Signed-off-by: Bili Dong 
> ---
>  .mailmap   |  1 +
>  app/test/test_hash_functions.c | 33 +++--
>  lib/hash/rte_hash_xor.h| 87 ++
>  3 files changed, 118 insertions(+), 3 deletions(-)
>  create mode 100644 lib/hash/rte_hash_xor.h
>
> diff --git a/.mailmap b/.mailmap
> index a9f4f28fba..3e9bec29d5 100644
> --- a/.mailmap
> +++ b/.mailmap
> @@ -159,6 +159,7 @@ Bernard Iremonger 
>  Bert van Leeuwen 
>  Bhagyada Modali 
>  Bharat Mota 
> +Bili Dong 
>  Bill Hong 
>  Billy McFall 
>  Billy O'Mahony 
> diff --git a/app/test/test_hash_functions.c
> b/app/test/test_hash_functions.c
> index 76d51b6e71..53e296fec4 100644
> --- a/app/test/test_hash_functions.c
> +++ b/app/test/test_hash_functions.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "test.h"
>
> @@ -22,8 +23,8 @@
>   * Hash values calculated for key sizes from array "hashtest_key_lens"
>   * and for initial values from array "hashtest_initvals.
>   * Each key will be formed by increasing each byte by 1:
> - * e.g.: key size = 4, key = 0x03020100
> - *   key size = 8, key = 0x0706050403020100
> + * e.g.: key size = 4, key = 0x00010203
> + *   key size = 8, key = 0x0001020304050607
>   */
>  static uint32_t hash_values_jhash[2][12] = {{
> 0x8ba9414b, 0xdf0d39c9,
> @@ -51,6 +52,19 @@ static uint32_t hash_values_crc[2][12] = {{
> 0x789c104f, 0x53028d3e
>  }
>  };
> +static uint32_t hash_values_xor32[2][12] = {{
> +   0x, 0x0001,
> +   0x00010203, 0x04040404, 0x, 0x,
> +   0x, 0x, 0x0c040404, 0x000d0e0f,
> +   0x04212223, 0x04040404
> +},
> +{
> +   0xdeadbeef, 0xdeacbeef,
> +   0xdeacbcec, 0xdaa9baeb, 0xdeadbeef, 0xdeadbeef,
> +   0xdeadbeef, 0xdeadbeef, 0xd2a9baeb, 0xdea0b0e0,
> +   0xda8c9ccc, 0xdaa9baeb
> +}
> +};
>
>
>  
> /***
>   * Hash function performance test configuration section. Each performance
> test
> @@ -61,7 +75,7 @@ static uint32_t hash_values_crc[2][12] = {{
>   */
>  #define HASHTEST_ITERATIONS 100
>  #define MAX_KEYSIZE 64
> -static rte_hash_function hashtest_funcs[] = {rte_jhash, rte_hash_crc};
> +static rte_hash_function hashtest_funcs[] = {rte_jhash, rte_hash_crc,
> rte_hash_xor32};
>  static uint32_t hashtest_initvals[] = {0, 0xdeadbeef};
>  static uint32_t hashtest_key_lens[] = {
> 1, 2, /* Unusual key sizes */
> @@ -85,6 +99,9 @@ get_hash_name(rte_hash_function f)
> if (f == rte_hash_crc)
> return "rte_hash_crc";
>
> +   if (f == rte_hash_xor32)
> +   return "rte_hash_xor32";
> +
> return "UnknownHash";
>  }
>
> @@ -173,6 +190,16 @@ verify_precalculated_hash_func_tests(void)
>hash_values_crc[j][i], hash);
> return -1;
> }
> +
> +   hash = rte_hash_xor32(key, hashtest_key_lens[i],
> +   hashtest_initvals[j]);
> +   if (hash != hash_values_xor32[j][i]) {
> +   printf("XOR32 for %u bytes with initial
> value 0x%x."
> +  " Expected 0x%x, but got 0x%x\n",
> +  hashtest_key_lens[i],
> hashtest_initvals[j],
> +  hash_values_xor32[j][i], hash);
> +   return -1;
> +   }
> }
> }
>
> diff --git a/lib/hash/rte_hash_xor.h b/lib/hash/rte_hash_xor.h
> new file mode 100644
> index 00..366adbe64c
> --- /dev/null
> +++ b/lib/hash/rte_hash_xor.h
> @@ -0,0 +1,87 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(c) 2023 Intel Corporation
> + */
> +
> +#ifndef _RTE_HASH_XOR_H_
> +#define _RTE_HASH_XOR_H_
> +
> +/**
> + * @file
> + *
> + * RTE XOR Hash
> + */
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +#include 
> +
> +#include 
> +
> +/**
> + * Calculate XOR32 hash on user-supplied byte array.
> + *
> + * @param data
> + *   Data to perform hash on.
> + * @param data_len
> + *   How many bytes to use to calculate hash value.
> + * @param init_val
> + *   Value to initialise hash generator.
> + * @return
> + *   32bit calculated hash value.
> + */
> +static inline uint32_t
> +rte_hash_xor32(const void *data, uint32_t data_len, uint32_t init_val)
> +{
> +   uint32_t hash32;
> +   

Reminder - DPDK Techboard Meeting - Tomorrow Wed. 2/22/23 @ 7am PT/10am ET/1600h CET

[Nathan Southern]

Good evening,

Tomorrow, Wednesday Feb. 22, 2023, the DPDK tech board will meet at 7am
PT/10am ET/1600h CET.

An agenda will be placed here by the tech board members:

https://annuel.framapad.org/p/r.0c3cc4d1e011214183872a98f6b5c7db

Link to sign into the meeting

https://meet.jit.si/dpdk


Thanks,

Nathan

Nathan C. Southern, Project Coordinator

Data Plane Development Kit

The Linux Foundation

248.835.4812 (mobile)

nsouth...@linuxfoundation.org

Re: [PATCH 1/2] net/mana: add version information for dependencies

[Ferruh Yigit]

On 1/20/2023 2:19 AM, lon...@linuxonhyperv.com wrote:
> From: Long Li 
> 
> The required dependencies for mana from rdma-core and Linux kernel have
> been released. Add those information to the doc.
> 
> Fixes: 517ed6e2d590 ("net/mana: add basic driver with build environment")
> Signed-off-by: Long Li 

For series,
Acked-by: Ferruh Yigit 

Series applied to dpdk-next-net/main, thanks.