date:20230419

RE: [dpdk-dev] [PATCH] ring: fix use after free in ring release

2023-04-19 Thread wangyunjian




> -Original Message-
> From: Honnappa Nagarahalli [mailto:honnappa.nagaraha...@arm.com]
> Sent: Wednesday, April 19, 2023 7:53 AM
> To: wangyunjian ; dev@dpdk.org
> Cc: konstantin.v.anan...@yandex.ru; luyicai ;
> sta...@dpdk.org; nd ; Honnappa Nagarahalli
> ; nd 
> Subject: RE: [dpdk-dev] [PATCH] ring: fix use after free in ring release
> 
> 
> 
> > -Original Message-
> > From: Yunjian Wang 
> > Sent: Monday, April 17, 2023 8:12 AM
> > To: dev@dpdk.org
> > Cc: Honnappa Nagarahalli ;
> > konstantin.v.anan...@yandex.ru; luyi...@huawei.com; Yunjian Wang
> > ; sta...@dpdk.org
> > Subject: [dpdk-dev] [PATCH] ring: fix use after free in ring release
> >
> > When using the ring to find out tailq entry, however it had been freed
> > by rte_memzone_free function. This change prevents that from happening.
> I am unable to follow the problem you are describing.
> After the memzone for the ring is released, the contents of the memzone are
> not being used. I understand that the variable 'r' is being used, but that 
> should
> not cause any issues.
> 
> >
> > Fixes: 4e32101f9b01 ("ring: support freeing")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Yunjian Wang 
> > ---
> >  lib/ring/rte_ring.c | 11 +--
> >  1 file changed, 5 insertions(+), 6 deletions(-)
> >
> > diff --git a/lib/ring/rte_ring.c b/lib/ring/rte_ring.c index
> > 8ed455043d..17d2d7f8a8 100644
> > --- a/lib/ring/rte_ring.c
> > +++ b/lib/ring/rte_ring.c
> > @@ -333,11 +333,6 @@ rte_ring_free(struct rte_ring *r)
> > return;
> > }
> >
> > -   if (rte_memzone_free(r->memzone) != 0) {
> > -   RTE_LOG(ERR, RING, "Cannot free memory\n");
> > -   return;
> > -   }
> Why do we need to free the memzone later?

After the memzone is freed, it is not removed from the 'rte_ring_tailq'.
If rte_ring_lookup is called at this time, it will cause a use-after-free 
problem.

Thanks,
Yunjian
> 
> > -
> > ring_list = RTE_TAILQ_CAST(rte_ring_tailq.head, rte_ring_list);
> > rte_mcfg_tailq_write_lock();
> >
> > @@ -349,7 +344,7 @@ rte_ring_free(struct rte_ring *r)
> >
> > if (te == NULL) {
> > rte_mcfg_tailq_write_unlock();
> > -   return;
> > +   goto free_memzone;
> > }
> >
> > TAILQ_REMOVE(ring_list, te, next);
> > @@ -357,6 +352,10 @@ rte_ring_free(struct rte_ring *r)
> > rte_mcfg_tailq_write_unlock();
> >
> > rte_free(te);
> > +
> > +free_memzone:
> > +   if (rte_memzone_free(r->memzone) != 0)
> > +   RTE_LOG(ERR, RING, "Cannot free memory\n");
> >  }
> >
> >  /* dump the status of the ring on the console */
> > --
> > 2.33.0

[RFC] lib: set/get max memzone segments

2023-04-19 Thread Ophir Munk

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 the max value via an rte API -
rather than changing the dpdk source code per application.  In many
organizations, the possibility to compile a private DPDK library for a
particular application does not exist at all.  With this option there is
no need to recompile DPDK and it allows using an in-box packaged DPDK.
An example usage for updating the RTE_MAX_MEMZONE 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 is not about how to optimize the application usage of
mempool nor about how to improve the mempool implementation based on
memzone.  It is about how to make the max memzone definition - run-time
customized.
This commit adds an API which must be called before rte_eal_init():
rte_memzone_max_set(int max).  If not called, the default memzone
(RTE_MAX_MEMZONE) is used.  There is also an API to query the effective
max memzone: rte_memzone_max_get().

Signed-off-by: Ophir Munk 
---
 app/test/test_func_reentrancy.c |  2 +-
 app/test/test_malloc_perf.c |  2 +-
 app/test/test_memzone.c |  2 +-
 config/rte_config.h |  1 -
 drivers/net/qede/base/bcm_osal.c| 26 +-
 drivers/net/qede/base/bcm_osal.h|  3 +++
 drivers/net/qede/qede_main.c|  7 +++
 lib/eal/common/eal_common_memzone.c | 28 +---
 lib/eal/include/rte_memzone.h   | 20 
 lib/eal/version.map |  4 
 10 files changed, 83 insertions(+), 12 deletions(-)

diff --git a/app/test/test_func_reentrancy.c b/app/test/test_func_reentrancy.c
index d1ed5d4..ae9de6f 100644
--- a/app/test/test_func_reentrancy.c
+++ b/app/test/test_func_reentrancy.c
@@ -51,7 +51,7 @@ typedef void (*case_clean_t)(unsigned lcore_id);
 #define MEMPOOL_ELT_SIZE(sizeof(uint32_t))
 #define MEMPOOL_SIZE(4)
 
-#define MAX_LCORES (RTE_MAX_MEMZONE / (MAX_ITER_MULTI * 4U))
+#define MAX_LCORES (rte_memzone_max_get() / (MAX_ITER_MULTI * 4U))
 
 static uint32_t obj_count;
 static uint32_t synchro;
diff --git a/app/test/test_malloc_perf.c b/app/test/test_malloc_perf.c
index ccec43a..9bd1662 100644
--- a/app/test/test_malloc_perf.c
+++ b/app/test/test_malloc_perf.c
@@ -165,7 +165,7 @@ test_malloc_perf(void)
return -1;
 
if (test_alloc_perf("rte_memzone_reserve", memzone_alloc, memzone_free,
-   NULL, memset_us_gb, RTE_MAX_MEMZONE - 1) < 0)
+   NULL, memset_us_gb, rte_memzone_max_get() - 1) < 0)
return -1;
 
return 0;
diff --git a/app/test/test_memzone.c b/app/test/test_memzone.c
index c9255e5..a315826 100644
--- a/app/test/test_memzone.c
+++ b/app/test/test_memzone.c
@@ -871,7 +871,7 @@ test_memzone_bounded(void)
 static int
 test_memzone_free(void)
 {
-   const struct rte_memzone *mz[RTE_MAX_MEMZONE + 1];
+   const struct rte_memzone *mz[rte_memzone_max_get() + 1];
int i;
char name[20];
 
diff --git a/config/rte_config.h b/config/rte_config.h
index 7b8c85e..400e44e 100644
--- a/config/rte_config.h
+++ b/config/rte_config.h
@@ -34,7 +34,6 @@
 #define RTE_MAX_MEM_MB_PER_LIST 32768
 #define RTE_MAX_MEMSEG_PER_TYPE 32768
 #define RTE_MAX_MEM_MB_PER_TYPE 65536
-#define RTE_MAX_MEMZONE 2560
 #define RTE_MAX_TAILQ 32
 #define RTE_LOG_DP_LEVEL RTE_LOG_INFO
 #define RTE_MAX_VFIO_CONTAINERS 64
diff --git a/drivers/net/qede/base/bcm_osal.c b/drivers/net/qede/base/bcm_osal.c
index 2c59397..f195f2c 100644
--- a/drivers/net/qede/base/bcm_osal.c
+++ b/drivers/net/qede/base/bcm_osal.c
@@ -47,10 +47,26 @@ void osal_poll_mode_dpc(osal_int_ptr_t hwfn_cookie)
 }
 
 /* Array of memzone pointers */
-static const struct rte_memzone *ecore_mz_mapping[RTE_MAX_MEMZONE];
+static const struct rte_memzone **ecore_mz_mapping;
 /* Counter to track current memzone allocated */
 static uint16_t ecore_mz_count;
 
+int ecore_mz_mapping_alloc(void)
+{
+   ecore_mz_mapping = rte_malloc("ecore_mz_map", 0,
+   rte_memzone_max_get() * sizeof(struct rte_memzone *));
+
+   if (!ecore_mz_mapping)
+   return -ENOMEM;
+
+   return 0;
+}
+
+void ecore_mz_mapping_free(void)
+{
+   rte_free(ecore_mz_mapping);
+}
+
 unsigned long qede_log2_align(unsigned long n)
 {
unsigned long ret = n ? 1 : 0;
@@ -132,9 +148,9 @@ void *osal_dma_alloc_coherent(struct ecore_dev *p_dev,
uint32_t core_id = rte_lcore_id();
unsigned int socket_id;
 
-   if (ecore_mz_count >= RTE_MAX_MEMZONE) {
+   if (ecore_mz_count >= rte_memzone_max_get()) {
DP_ERR(p_dev, "Memzone allocation count exceeds %u\n",
-

RE: 20.11.8 patches review and test

2023-04-19 Thread Ali Alnubani

> -Original Message-
> From: Ali Alnubani 
> Sent: Wednesday, April 12, 2023 6:15 PM
> To: luca.bocca...@gmail.com; sta...@dpdk.org
> Cc: dev@dpdk.org; Abhishek Marathe ;
> benjamin.wal...@intel.com; David Christensen ;
> Hemant Agrawal ; Ian Stokes
> ; Jerin Jacob ; John McNamara
> ; Ju-Hyoung Lee ;
> Kevin Traynor ; Luca Boccassi ;
> Pei Zhang ; qian.q...@intel.com; Raslan Darawsheh
> ; NBU-Contact-Thomas Monjalon (EXTERNAL)
> ; Yanghang Liu ;
> yuan.p...@intel.com; zhaoyan.c...@intel.com
> Subject: RE: 20.11.8 patches review and test
> 
> > -Original Message-
> > From: luca.bocca...@gmail.com 
> > Sent: Friday, March 31, 2023 9:20 PM
> > To: sta...@dpdk.org
> > Cc: dev@dpdk.org; Abhishek Marathe
> ;
> > Ali Alnubani ; benjamin.wal...@intel.com; David
> > Christensen ; Hemant Agrawal
> > ; Ian Stokes ; Jerin
> > Jacob ; John McNamara
> ;
> > Ju-Hyoung Lee ; Kevin Traynor
> > ; Luca Boccassi ; Pei Zhang
> > ; qian.q...@intel.com; Raslan Darawsheh
> > ; NBU-Contact-Thomas Monjalon (EXTERNAL)
> > ; Yanghang Liu ;
> > yuan.p...@intel.com; zhaoyan.c...@intel.com
> > Subject: 20.11.8 patches review and test
> >
> > Hi all,
> >
> > Here is a list of patches targeted for stable release 20.11.8.
> >
> > The planned date for the final release is April 17th.
> >
> > Please help with testing and validation of your use cases and report
> > any issues/results with reply-all to this mail. For the final release
> > the fixes and reported validations will be added to the release notes.
> >
> > A release candidate tarball can be found at:
> >
> > https://dpdk.org/browse/dpdk-stable/tag/?id=v20.11.8-rc1
> >
> > These patches are located at branch 20.11 of dpdk-stable repo:
> > https://dpdk.org/browse/dpdk-stable/
> >
> > Thanks.
> >
> > Luca Boccassi
> >
> > ---
> 
> Hello,
> 
> We ran the following functional tests with Nvidia hardware on v20.11.8-rc1:
> - Basic functionality:
>   Send and receive multiple types of traffic.
> - testpmd xstats counter test.
> - testpmd timestamp test.
> - Changing/checking link status through testpmd.
> - rte_flow tests.
> - Some RSS tests.
> - VLAN filtering, stripping and insertion tests.
> - Checksum and TSO tests.
> - ptype tests.
> - link_status_interrupt example application tests.
> - l3fwd-power example application tests.
> - Multi-process example applications tests.
> - Hardware LRO tests.
> 
> Functional tests ran on:
> - NIC: ConnectX-6 Dx / OS: Ubuntu 20.04 / Driver: MLNX_OFED_LINUX-5.9-
> 0.5.6.0 / Firmware: 22.36.1010
> - NIC: ConnectX-7 / OS: Ubuntu 20.04 / Driver: MLNX_OFED_LINUX-5.9-
> 0.5.6.0 / Firmware: 22.36.1010
> - DPU: BlueField-2 / DOCA SW version: 1.5.1 / Firmware: 24.35.2000
> 
> Additionally, we ran compilation tests with multiple configurations in the
> following OS/driver combinations:
> - Ubuntu 20.04.5 with MLNX_OFED_LINUX-5.9-0.5.6.0.
> - Ubuntu 20.04.5 with rdma-core master (f0a079f).
> - Ubuntu 20.04.5 with rdma-core v28.0.
> - Ubuntu 18.04.6 with rdma-core v17.1.
> - Ubuntu 18.04.6 with rdma-core master (f0a079f) (i386).
> - Fedora 37 with rdma-core v41.0.
> - Fedora 39 (Rawhide) with rdma-core v44.0.
> - CentOS 7 7.9.2009 with rdma-core master (f0a079f).
> - CentOS 7 7.9.2009 with MLNX_OFED_LINUX-5.9-0.5.6.0.
> - CentOS 8 8.4.2105 with rdma-core master (f0a079f).
> - OpenSUSE Leap 15.4 with rdma-core v38.1.
> - Windows Server 2019 with Clang 11.0.0.
> 
> We don't see new issues caused by the changes in this release.
> 
> Please note that not all the functional tests mentioned above fall under
> "Basic functionality with testpmd" like reported in the release notes for
> previous releases:
> https://git.dpdk.org/dpdk-
> stable/commit/?h=v20.11.7&id=62865fef48cb93042e8b9f85821eb02e1031e8f
> 0
> Some of them test other applications.
> 
> Thanks,
> Ali

Hello,

I see this documentation build failure on Fedora 37:

$ ninja-build -C build doc
[..]
[2/4] Generating doc/api/doxygen with a custom command
FAILED: doc/api/html
/root/dpdk/doc/api/generate_doxygen.sh doc/api/doxy-api.conf doc/api/html 
/root/dpdk/doc/api/doxy-html-custom.sh
/root/dpdk/lib/librte_cryptodev/rte_cryptodev_pmd.h:489: error: found 
documented return type for rte_cryptodev_pmd_callback_process that does not 
return anything (warning treated as error, aborting now)
[..]
ninja: build stopped: subcommand failed.

Re: [RFC 05/27] vhost: add helper for IOTLB entries shared page check

2023-04-19 Thread Maxime Coquelin


Hi Mike,

On 4/17/23 21:39, Mike Pattrick wrote:

Hi Maxime,

On Fri, Mar 31, 2023 at 11:43 AM Maxime Coquelin
 wrote:


This patch introduces a helper to check whether two IOTLB
entries share a page.

Signed-off-by: Maxime Coquelin 
---
  lib/vhost/iotlb.c | 25 -
  1 file changed, 20 insertions(+), 5 deletions(-)

diff --git a/lib/vhost/iotlb.c b/lib/vhost/iotlb.c
index e8f1cb661e..d919f74704 100644
--- a/lib/vhost/iotlb.c
+++ b/lib/vhost/iotlb.c
@@ -23,6 +23,23 @@ struct vhost_iotlb_entry {

  #define IOTLB_CACHE_SIZE 2048

+static bool
+vhost_user_iotlb_share_page(struct vhost_iotlb_entry *a, struct 
vhost_iotlb_entry *b,
+   uint64_t align)
+{
+   uint64_t a_end, b_start;
+
+   if (a == NULL || b == NULL)
+   return false;
+
+   /* Assumes entry a lower than entry b */
+   RTE_ASSERT(a->uaddr < b->uaddr);
+   a_end = RTE_ALIGN_CEIL(a->uaddr + a->size, align);
+   b_start = RTE_ALIGN_FLOOR(b->uaddr, align);
+
+   return a_end > b_start;


This may be a very minor detail, but it might improve readability if
the a_end calculation used addr + size - 1 and the return conditional
used >=.


That's actually how I initially implemented it, but discussing with
David we agreed it would be better that way for consistency with
vhost_user_iotlb_clear_dump().

Regards,
Maxime



Cheers,
M



+}
+
  static void
  vhost_user_iotlb_set_dump(struct virtio_net *dev, struct vhost_iotlb_entry 
*node)
  {
@@ -37,16 +54,14 @@ static void
  vhost_user_iotlb_clear_dump(struct virtio_net *dev, struct vhost_iotlb_entry 
*node,
 struct vhost_iotlb_entry *prev, struct vhost_iotlb_entry *next)
  {
-   uint64_t align, mask;
+   uint64_t align;

 align = hua_to_alignment(dev->mem, (void *)(uintptr_t)node->uaddr);
-   mask = ~(align - 1);

 /* Don't disable coredump if the previous node is in the same page */
-   if (prev == NULL || (node->uaddr & mask) != ((prev->uaddr + prev->size - 1) 
& mask)) {
+   if (!vhost_user_iotlb_share_page(prev, node, align)) {
 /* Don't disable coredump if the next node is in the same page 
*/
-   if (next == NULL ||
-   ((node->uaddr + node->size - 1) & mask) != 
(next->uaddr & mask))
+   if (!vhost_user_iotlb_share_page(node, next, align))
 mem_set_dump((void *)(uintptr_t)node->uaddr, 
node->size, false, align);
 }
  }
--
2.39.2

[RFC PATCH 1/5] eventdev: add power monitoring API on event port

2023-04-19 Thread Sivaprasad Tummala

A new API to allow power monitoring condition on event port to
optimize power when no events are arriving on an event port for
the worker core to process in an eventdev based pipelined application.

Signed-off-by: Sivaprasad Tummala 
---
 lib/eventdev/eventdev_pmd.h | 23 +++
 lib/eventdev/rte_eventdev.c | 24 
 lib/eventdev/rte_eventdev.h | 25 +
 3 files changed, 72 insertions(+)

diff --git a/lib/eventdev/eventdev_pmd.h b/lib/eventdev/eventdev_pmd.h
index aebab26852..7b12f80f57 100644
--- a/lib/eventdev/eventdev_pmd.h
+++ b/lib/eventdev/eventdev_pmd.h
@@ -481,6 +481,26 @@ typedef int (*eventdev_port_unlink_t)(struct rte_eventdev 
*dev, void *port,
 typedef int (*eventdev_port_unlinks_in_progress_t)(struct rte_eventdev *dev,
void *port);
 
+/**
+ * @internal
+ * Get address of memory location whose contents will change whenever there is
+ * new data to be received on an Event port.
+ *
+ * @param port
+ *   Eventdev port pointer.
+ * @param pmc
+ *   The pointer to power-optimized monitoring condition structure.
+ * @return
+ *   Negative errno value on error, 0 on success.
+ *
+ * @retval 0
+ *   Success
+ * @retval -EINVAL
+ *   Invalid parameters
+ */
+typedef int (*event_get_monitor_addr_t)(void *port,
+   struct rte_power_monitor_cond *pmc);
+
 /**
  * Converts nanoseconds to *timeout_ticks* value for rte_event_dequeue()
  *
@@ -1376,6 +1396,9 @@ struct eventdev_ops {
eventdev_dump_t dump;
/* Dump internal information */
 
+   /** Get power monitoring condition for event port */
+   event_get_monitor_addr_t get_monitor_addr;
+
eventdev_xstats_get_t xstats_get;
/**< Get extended device statistics. */
eventdev_xstats_get_names_t xstats_get_names;
diff --git a/lib/eventdev/rte_eventdev.c b/lib/eventdev/rte_eventdev.c
index 6ab4524332..ff77194783 100644
--- a/lib/eventdev/rte_eventdev.c
+++ b/lib/eventdev/rte_eventdev.c
@@ -860,6 +860,30 @@ rte_event_port_attr_get(uint8_t dev_id, uint8_t port_id, 
uint32_t attr_id,
return 0;
 }
 
+int
+rte_event_port_get_monitor_addr(uint8_t dev_id, uint8_t port_id,
+   struct rte_power_monitor_cond *pmc)
+{
+   struct rte_eventdev *dev;
+
+   RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, -EINVAL);
+   dev = &rte_eventdevs[dev_id];
+   if (!is_valid_port(dev, port_id)) {
+   RTE_EDEV_LOG_ERR("Invalid port_id=%" PRIu8, port_id);
+   return -EINVAL;
+   }
+
+   if (pmc == NULL) {
+   RTE_EDEV_LOG_ERR("devid %u port %u power monitor condition is 
NULL\n",
+   dev_id, port_id);
+   return -EINVAL;
+   }
+
+   if (*dev->dev_ops->get_monitor_addr == NULL)
+   return -ENOTSUP;
+   return (*dev->dev_ops->get_monitor_addr)(dev->data->ports[port_id], 
pmc);
+}
+
 int
 rte_event_queue_attr_get(uint8_t dev_id, uint8_t queue_id, uint32_t attr_id,
uint32_t *attr_value)
diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h
index a90e23ac8b..841b1fb9b5 100644
--- a/lib/eventdev/rte_eventdev.h
+++ b/lib/eventdev/rte_eventdev.h
@@ -215,6 +215,7 @@ extern "C" {
 #include 
 #include 
 #include 
+#include 
 
 #include "rte_eventdev_trace_fp.h"
 
@@ -984,6 +985,30 @@ int
 rte_event_port_attr_get(uint8_t dev_id, uint8_t port_id, uint32_t attr_id,
uint32_t *attr_value);
 
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Retrieve the monitor condition for a given event port.
+ *
+ * @param dev_id
+ *   Eventdev id
+ * @param port_id
+ *   Eventdev port id
+ * @param pmc
+ *   The pointer to power-optimized monitoring condition structure.
+ *
+ * @return
+ *   - 0: Success.
+ *   -ENOTSUP: Operation not supported.
+ *   -EINVAL: Invalid parameters.
+ *   -ENODEV: Invalid device ID.
+ */
+__rte_experimental
+int
+rte_event_port_get_monitor_addr(uint8_t dev_id, uint8_t port_id,
+   struct rte_power_monitor_cond *pmc);
+
 /**
  * Start an event device.
  *
-- 
2.34.1

[RFC PATCH 2/5] event/sw: support power monitor

2023-04-19 Thread Sivaprasad Tummala

Currently sw eventdev pmd does not support ``rte_power_monitor`` api.
This patch adds support by adding monitor callback that is called
whenever we enter sleep state and need to check if it is time to
wake up.

Signed-off-by: Sivaprasad Tummala 
---
 drivers/event/sw/sw_evdev.c|  2 ++
 drivers/event/sw/sw_evdev.h|  2 ++
 drivers/event/sw/sw_evdev_worker.c | 27 +++
 3 files changed, 31 insertions(+)

diff --git a/drivers/event/sw/sw_evdev.c b/drivers/event/sw/sw_evdev.c
index cfd659d774..448253cdc3 100644
--- a/drivers/event/sw/sw_evdev.c
+++ b/drivers/event/sw/sw_evdev.c
@@ -958,6 +958,8 @@ sw_probe(struct rte_vdev_device *vdev)
.port_unlink = sw_port_unlink,
.port_unlinks_in_progress = sw_port_unlinks_in_progress,
 
+   .get_monitor_addr = sw_event_get_monitor_addr,
+
.eth_rx_adapter_caps_get = sw_eth_rx_adapter_caps_get,
 
.timer_adapter_caps_get = sw_timer_adapter_caps_get,
diff --git a/drivers/event/sw/sw_evdev.h b/drivers/event/sw/sw_evdev.h
index c7b943a72b..26aa2fe283 100644
--- a/drivers/event/sw/sw_evdev.h
+++ b/drivers/event/sw/sw_evdev.h
@@ -312,6 +312,8 @@ int sw_xstats_reset(struct rte_eventdev *dev,
int16_t queue_port_id,
const uint64_t ids[],
uint32_t nb_ids);
+int sw_event_get_monitor_addr(void *port,
+   struct rte_power_monitor_cond *pmc);
 
 int test_sw_eventdev(void);
 
diff --git a/drivers/event/sw/sw_evdev_worker.c 
b/drivers/event/sw/sw_evdev_worker.c
index 063b919c7e..139c98cfe2 100644
--- a/drivers/event/sw/sw_evdev_worker.c
+++ b/drivers/event/sw/sw_evdev_worker.c
@@ -10,6 +10,33 @@
 
 #define PORT_ENQUEUE_MAX_BURST_SIZE 64
 
+static int
+sw_event_ring_monitor_callback(const uint64_t value,
+   const uint64_t arg[RTE_POWER_MONITOR_OPAQUE_SZ])
+{
+   /* Check if the head pointer has changed */
+   return value != arg[0];
+}
+
+int
+sw_event_get_monitor_addr(void *port, struct rte_power_monitor_cond *pmc)
+{
+   struct sw_port *p = (void *)port;
+   struct rte_event_ring *ev_ring = p->cq_worker_ring;
+   struct rte_ring *rng = &ev_ring->r;
+
+   /*
+* Monitor event ring producer tail since if
+* prod.tail moves there are events to dequeue
+*/
+   pmc->addr = &rng->prod.tail;
+   pmc->size = sizeof(rng->prod.tail);
+   pmc->opaque[0] = rng->prod.tail;
+   pmc->fn = sw_event_ring_monitor_callback;
+
+   return 0;
+}
+
 static inline void
 sw_event_release(struct sw_port *p, uint8_t index)
 {
-- 
2.34.1

[RFC PATCH 3/5] eventdev: support optional dequeue callbacks

2023-04-19 Thread Sivaprasad Tummala

Add optional support for inline event processing within dequeue call.
For a dequeue callback, events dequeued from the event port were
passed them to a callback function if configured, to allow
additional processing. e.g. unpack batch of packets from each event
on dequeue, before passing back to the application.

Signed-off-by: Sivaprasad Tummala 
---
 lib/eventdev/eventdev_pmd.h  |  17 
 lib/eventdev/eventdev_private.c  |  17 
 lib/eventdev/rte_eventdev.c  |  78 +
 lib/eventdev/rte_eventdev.h  | 145 ++-
 lib/eventdev/rte_eventdev_core.h |  12 ++-
 lib/eventdev/version.map |   6 ++
 6 files changed, 272 insertions(+), 3 deletions(-)

diff --git a/lib/eventdev/eventdev_pmd.h b/lib/eventdev/eventdev_pmd.h
index 7b12f80f57..c87e06993f 100644
--- a/lib/eventdev/eventdev_pmd.h
+++ b/lib/eventdev/eventdev_pmd.h
@@ -97,6 +97,19 @@ struct rte_eventdev_global {
uint8_t nb_devs;/**< Number of devices found */
 };
 
+/**
+ * @internal
+ * Structure used to hold information about the callbacks to be called for a
+ * port on dequeue.
+ */
+struct rte_event_dequeue_callback {
+   struct rte_event_dequeue_callback *next;
+   union{
+   rte_dequeue_callback_fn dequeue;
+   } fn;
+   void *param;
+};
+
 /**
  * @internal
  * The data part, with no function pointers, associated with each device.
@@ -173,6 +186,10 @@ struct rte_eventdev {
/**< Pointer to PMD dequeue burst function. */
event_maintain_t maintain;
/**< Pointer to PMD port maintenance function. */
+   struct rte_event_dequeue_callback 
*post_dequeue_burst_cbs[RTE_EVENT_MAX_PORTS_PER_DEV];
+   /**<  User-supplied functions called from dequeue_burst to post-process
+* received packets before passing them to the user
+*/
event_tx_adapter_enqueue_t txa_enqueue_same_dest;
/**< Pointer to PMD eth Tx adapter burst enqueue function with
 * events destined to same Eth port & Tx queue.
diff --git a/lib/eventdev/eventdev_private.c b/lib/eventdev/eventdev_private.c
index 1d3d9d357e..6d1cbdb17d 100644
--- a/lib/eventdev/eventdev_private.c
+++ b/lib/eventdev/eventdev_private.c
@@ -118,4 +118,21 @@ event_dev_fp_ops_set(struct rte_event_fp_ops *fp_op,
fp_op->txa_enqueue_same_dest = dev->txa_enqueue_same_dest;
fp_op->ca_enqueue = dev->ca_enqueue;
fp_op->data = dev->data->ports;
+   fp_op->ev_port.clbk = (void **)(uintptr_t)dev->post_dequeue_burst_cbs;
+   fp_op->ev_port.data = dev->data->ports;
+}
+
+uint16_t
+rte_event_dequeue_callbacks(uint8_t dev_id, uint8_t port_id,
+   struct rte_event *ev, uint16_t nb_events, void *opaque)
+{
+   static uint16_t nb_rx;
+   const struct rte_event_dequeue_callback *cb = opaque;
+
+   while (cb != NULL) {
+   nb_rx = cb->fn.dequeue(dev_id, port_id, ev,
+   nb_events, cb->param);
+   cb = cb->next;
+   }
+   return nb_rx;
 }
diff --git a/lib/eventdev/rte_eventdev.c b/lib/eventdev/rte_eventdev.c
index ff77194783..0d43cb2d0a 100644
--- a/lib/eventdev/rte_eventdev.c
+++ b/lib/eventdev/rte_eventdev.c
@@ -38,6 +38,9 @@ static struct rte_eventdev_global eventdev_globals = {
 /* Public fastpath APIs. */
 struct rte_event_fp_ops rte_event_fp_ops[RTE_EVENT_MAX_DEVS];
 
+/* spinlock for add/remove dequeue callbacks */
+static rte_spinlock_t event_dev_dequeue_cb_lock = RTE_SPINLOCK_INITIALIZER;
+
 /* Event dev north bound API implementation */
 
 uint8_t
@@ -860,6 +863,81 @@ rte_event_port_attr_get(uint8_t dev_id, uint8_t port_id, 
uint32_t attr_id,
return 0;
 }
 
+const struct rte_event_dequeue_callback *
+rte_event_add_dequeue_callback(uint8_t dev_id, uint8_t port_id,
+   rte_dequeue_callback_fn fn, void *user_param)
+{
+   struct rte_eventdev *dev;
+   struct rte_event_dequeue_callback *cb;
+   struct rte_event_dequeue_callback *tail;
+
+   /* check input parameters */
+   RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, NULL);
+   dev = &rte_eventdevs[dev_id];
+   if (!is_valid_port(dev, port_id)) {
+   RTE_EDEV_LOG_ERR("Invalid port_id=%" PRIu8, port_id);
+   return NULL;
+   }
+
+   cb = rte_zmalloc(NULL, sizeof(*cb), 0);
+   if (cb == NULL) {
+   rte_errno = ENOMEM;
+   return NULL;
+   }
+   cb->fn.dequeue = fn;
+   cb->param = user_param;
+
+   rte_spinlock_lock(&event_dev_dequeue_cb_lock);
+   /* Add the callbacks in fifo order. */
+   tail = rte_eventdevs[dev_id].post_dequeue_burst_cbs[port_id];
+   if (!tail) {
+   /* Stores to cb->fn and cb->param should complete before
+* cb is visible to data plane.
+*/
+   __atomic_store_n(
+   &rte_eventdevs[dev_id].post_dequeue_burst_cbs[port_id],
+   cb, __ATOMIC_RELEASE);
+

[RFC PATCH 4/5] power: add eventdev support for power management

2023-04-19 Thread Sivaprasad Tummala

Add eventdev support to enable power saving when no events
are arriving. It is based on counting the number of empty
polls and, when the number reaches a certain threshold, entering
an architecture-defined optimized power state that will either wait
until a TSC timestamp expires, or when events arrive.

This API mandates a core-to-single-port mapping (i.e. one core polling
multiple ports of event device is not supported). This should be ok
as the general use case will have one CPU core using one port to
enqueue/dequeue events from an eventdev.

This design is using Eventdev PMD Dequeue callbacks.

1. MWAITX/MONITORX:

   When a certain threshold of empty polls is reached, the core will go
   into a power optimized sleep while waiting on an address of next RX
   descriptor to be written to.

2. Pause instruction

   This method uses the pause instruction to avoid busy polling.

Signed-off-by: Sivaprasad Tummala 
---
 lib/power/meson.build  |   2 +-
 lib/power/rte_power_pmd_mgmt.c | 226 +
 lib/power/rte_power_pmd_mgmt.h |  55 
 lib/power/version.map  |   4 +
 4 files changed, 286 insertions(+), 1 deletion(-)

diff --git a/lib/power/meson.build b/lib/power/meson.build
index 1ce8b7c07d..528340e291 100644
--- a/lib/power/meson.build
+++ b/lib/power/meson.build
@@ -31,4 +31,4 @@ headers = files(
 if cc.has_argument('-Wno-cast-qual')
 cflags += '-Wno-cast-qual'
 endif
-deps += ['timer', 'ethdev']
+deps += ['timer', 'ethdev', 'eventdev']
diff --git a/lib/power/rte_power_pmd_mgmt.c b/lib/power/rte_power_pmd_mgmt.c
index ca1840387c..3c194872c3 100644
--- a/lib/power/rte_power_pmd_mgmt.c
+++ b/lib/power/rte_power_pmd_mgmt.c
@@ -9,8 +9,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
+#include 
 #include "rte_power_pmd_mgmt.h"
 #include "power_common.h"
 
@@ -53,6 +55,7 @@ struct queue_list_entry {
uint64_t n_empty_polls;
uint64_t n_sleeps;
const struct rte_eth_rxtx_callback *cb;
+   const struct rte_event_dequeue_callback *evt_cb;
 };
 
 struct pmd_core_cfg {
@@ -414,6 +417,64 @@ cfg_queues_stopped(struct pmd_core_cfg *queue_cfg)
return 1;
 }
 
+static uint16_t
+evt_clb_umwait(uint8_t dev_id, uint8_t port_id, struct rte_event *ev 
__rte_unused,
+   uint16_t nb_events, void *arg)
+{
+   struct queue_list_entry *queue_conf = arg;
+
+   /* this callback can't do more than one queue, omit multiqueue logic */
+   if (unlikely(nb_events == 0)) {
+   queue_conf->n_empty_polls++;
+   if (unlikely(queue_conf->n_empty_polls > emptypoll_max)) {
+   struct rte_power_monitor_cond pmc;
+   int ret;
+
+   /* use monitoring condition to sleep */
+   ret = rte_event_port_get_monitor_addr(dev_id, port_id,
+   &pmc);
+   if (ret == 0)
+   rte_power_monitor(&pmc, UINT64_MAX);
+   }
+   } else
+   queue_conf->n_empty_polls = 0;
+
+   return nb_events;
+}
+
+static uint16_t
+evt_clb_pause(uint8_t dev_id __rte_unused, uint8_t port_id __rte_unused,
+   struct rte_event *ev __rte_unused,
+   uint16_t nb_events, void *arg)
+{
+   const unsigned int lcore = rte_lcore_id();
+   struct queue_list_entry *queue_conf = arg;
+   struct pmd_core_cfg *lcore_conf;
+   const bool empty = nb_events == 0;
+   uint32_t pause_duration = rte_power_pmd_mgmt_get_pause_duration();
+
+   lcore_conf = &lcore_cfgs[lcore];
+
+   if (likely(!empty))
+   /* early exit */
+   queue_reset(lcore_conf, queue_conf);
+   else {
+   /* can this queue sleep? */
+   if (!queue_can_sleep(lcore_conf, queue_conf))
+   return nb_events;
+
+   /* can this lcore sleep? */
+   if (!lcore_can_sleep(lcore_conf))
+   return nb_events;
+
+   uint64_t i;
+   for (i = 0; i < global_data.pause_per_us * pause_duration; i++)
+   rte_pause();
+   }
+
+   return nb_events;
+}
+
 static int
 check_scale(unsigned int lcore)
 {
@@ -479,6 +540,171 @@ get_monitor_callback(void)
clb_multiwait : clb_umwait;
 }
 
+static int
+check_evt_monitor(struct pmd_core_cfg *cfg __rte_unused,
+   const union queue *qdata)
+{
+   struct rte_power_monitor_cond dummy;
+
+   /* check if rte_power_monitor is supported */
+   if (!global_data.intrinsics_support.power_monitor) {
+   RTE_LOG(DEBUG, POWER, "Monitoring intrinsics are not 
supported\n");
+   return -ENOTSUP;
+   }
+
+   /* check if the device supports the necessary PMD API */
+   if (rte_event_port_get_monitor_addr((uint8_t)qdata->portid, 
(uint8_t)qdata->qid,
+   &dummy) == -ENOTSUP) {
+

[RFC PATCH 5/5] examples/eventdev_p: add eventdev power management

2023-04-19 Thread Sivaprasad Tummala

From: Sivaprasad Tummala 

Add power management feature support to eventdev_pipeline sample app.

Signed-off-by: Sivaprasad Tummala 
---
 examples/eventdev_pipeline/main.c | 15 ++-
 examples/eventdev_pipeline/pipeline_common.h  |  1 +
 .../eventdev_pipeline/pipeline_worker_generic.c   |  1 +
 3 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/examples/eventdev_pipeline/main.c 
b/examples/eventdev_pipeline/main.c
index 8d6c90f15d..bd6d568b78 100644
--- a/examples/eventdev_pipeline/main.c
+++ b/examples/eventdev_pipeline/main.c
@@ -430,7 +430,20 @@ main(int argc, char **argv)
continue;
 
dump_core_info(lcore_id, worker_data, worker_idx);
-
+   {
+   if (fdata->worker_core[lcore_id]) {
+   err = rte_power_eventdev_pmgmt_port_enable(
+   lcore_id, 
worker_data[worker_idx].dev_id,
+   
worker_data[worker_idx].port_id,
+   
RTE_POWER_MGMT_TYPE_MONITOR);
+   if (err) {
+   RTE_LOG(ERR, POWER,
+   "Power Management enabled 
failed on core %u\n",
+   lcore_id);
+   continue;
+   }
+   }
+   }
err = rte_eal_remote_launch(fdata->cap.worker,
&worker_data[worker_idx], lcore_id);
if (err) {
diff --git a/examples/eventdev_pipeline/pipeline_common.h 
b/examples/eventdev_pipeline/pipeline_common.h
index 28b6ab85ff..b33162adfb 100644
--- a/examples/eventdev_pipeline/pipeline_common.h
+++ b/examples/eventdev_pipeline/pipeline_common.h
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define MAX_NUM_STAGES 8
 #define BATCH_SIZE 16
diff --git a/examples/eventdev_pipeline/pipeline_worker_generic.c 
b/examples/eventdev_pipeline/pipeline_worker_generic.c
index 783f68c91e..22d644bd51 100644
--- a/examples/eventdev_pipeline/pipeline_worker_generic.c
+++ b/examples/eventdev_pipeline/pipeline_worker_generic.c
@@ -6,6 +6,7 @@
 
 #include 
 
+#include 
 #include "pipeline_common.h"
 
 static __rte_always_inline int
-- 
2.34.1

Re: [RFC PATCH 1/5] eventdev: add power monitoring API on event port

2023-04-19 Thread Jerin Jacob

On Wed, Apr 19, 2023 at 3:24 PM Sivaprasad Tummala
 wrote:
>
> A new API to allow power monitoring condition on event port to
> optimize power when no events are arriving on an event port for
> the worker core to process in an eventdev based pipelined application.
>
> Signed-off-by: Sivaprasad Tummala 
> + *
> + * @param dev_id
> + *   Eventdev id
> + * @param port_id
> + *   Eventdev port id
> + * @param pmc
> + *   The pointer to power-optimized monitoring condition structure.
> + *
> + * @return
> + *   - 0: Success.
> + *   -ENOTSUP: Operation not supported.
> + *   -EINVAL: Invalid parameters.
> + *   -ENODEV: Invalid device ID.
> + */
> +__rte_experimental
> +int
> +rte_event_port_get_monitor_addr(uint8_t dev_id, uint8_t port_id,
> +   struct rte_power_monitor_cond *pmc);

+ eventdev driver maintainers

I think, we don't need to expose this application due to applications
1)To make applications to be transparent whether power saving is enabled or not?
2)Some HW and Arch already supports power managent in driver and in HW
(Not using  CPU architecture directly)

If so, that will be translated to following,
a) Add rte_event_port_power_saving_ena_dis(uint8_t dev_id, uint8_t
port_id, bool ena) for controlling power saving in slowpath.
b) Create reusable PMD private function based on the CPU architecture
power saving primitive to cover the PMD don't have native power saving
support.
c)Update rte_event_dequeue_burst() burst of PMD callback to use (b).

> +
>  /**
>   * Start an event device.
>   *
> --
> 2.34.1
>

[PATCH] net/ice: CVL support double vlan

2023-04-19 Thread Mingjin Ye

Aligned with kernel driver, optimized for inner and outer VLAN handling
in DPDK, and implemented double vlan insertion and stripping support.

1.adjust vlan stripping
Remove the judgment on dvm, vlan stripping only operates inner vlan.

2.support QinQ stripping
This patch support ice outer vlan strip on and off in QinQ mode with mask
bit of DEV_RX_OFFLOAD_QINQ_STRIP, users canuse "vlan set qinq_strip on 0"
to enable or "vlan setqinq_strip off 0" to disable ice outer vlan strip
when try with testpmd app.
Note: Due to hardware limitations, QinQ stripping containing two tagged RX
packets with the same EtherType (for example, two VLANs with EtherType =`
ETH_P_8021Q`) is not supported.

3.Support outer tag type switching
Add implementation of ethdev `vlan_tpid_set` api to enable Outer tags supp
-ort processing `ETH_P_8021Q` `ETH_P_8021AD` `ETH_P_QINQ1` outer tag types.

4.Support outer port insertion
If dvm is enabled, will support outer port vlan. User can use "tx_vlan set
pvid 0 45 on" to enable or "tx_vlan set pvid 0 45 off" to disable ice outer
vlan insertion try with testpmd app.

Signed-off-by: Mingjin Ye 
---
 drivers/net/ice/ice_ethdev.c | 426 +--
 drivers/net/ice/ice_ethdev.h |   1 +
 2 files changed, 413 insertions(+), 14 deletions(-)

diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
index 0bc739daf0..a945403328 100644
--- a/drivers/net/ice/ice_ethdev.c
+++ b/drivers/net/ice/ice_ethdev.c
@@ -54,6 +54,24 @@ static const char * const ice_valid_args[] = {
 
 #define PPS_OUT_DELAY_NS  1
 
+/* Maximum number of VSI */
+#define ICE_MAX_NUM_VSIS  (768UL)
+
+/* The 119 bit offset of the LAN Rx queue context is the L2TSEL control bit. */
+#define ICE_L2TSEL_QRX_CONTEXT_REG_IDX 3
+#define ICE_L2TSEL_BIT_OFFSET 23
+enum ice_l2tsel {
+   ICE_L2TSEL_EXTRACT_FIRST_TAG_L2TAG2_2ND,
+   ICE_L2TSEL_EXTRACT_FIRST_TAG_L2TAG1,
+};
+
+/* 802.1Q VLAN Extended Header */
+#define ETH_P_8021Q0x8100
+/* 802.1ad Service VLAN */
+#define ETH_P_8021AD   0x88A8
+/* deprecated QinQ VLAN [ NOT AN OFFICIALLY REGISTERED ID ] */
+#define ETH_P_QINQ10x9100
+
 struct proto_xtr_ol_flag {
const struct rte_mbuf_dynflag param;
bool required;
@@ -128,6 +146,9 @@ static int ice_fw_version_get(struct rte_eth_dev *dev, char 
*fw_version,
  size_t fw_size);
 static int ice_vlan_pvid_set(struct rte_eth_dev *dev,
 uint16_t pvid, int on);
+static int ice_vlan_tpid_set(struct rte_eth_dev *dev,
+  enum rte_vlan_type vlan_type,
+  uint16_t tpid);
 static int ice_get_eeprom_length(struct rte_eth_dev *dev);
 static int ice_get_eeprom(struct rte_eth_dev *dev,
  struct rte_dev_eeprom_info *eeprom);
@@ -250,6 +271,7 @@ static const struct eth_dev_ops ice_eth_dev_ops = {
.rx_queue_intr_disable= ice_rx_queue_intr_disable,
.fw_version_get   = ice_fw_version_get,
.vlan_pvid_set= ice_vlan_pvid_set,
+   .vlan_tpid_set= ice_vlan_tpid_set,
.rxq_info_get = ice_rxq_info_get,
.txq_info_get = ice_txq_info_get,
.rx_burst_mode_get= ice_rx_burst_mode_get,
@@ -1579,6 +1601,9 @@ ice_setup_vsi(struct ice_pf *pf, enum ice_vsi_type type)
hw->func_caps.common_cap.rss_table_size;
pf->flags |= ICE_FLAG_RSS_AQ_CAPABLE;
 
+   /* Defines the type of outer tag expected */
+   pf->outer_ethertype = ETH_P_8021Q;
+
memset(&vsi_ctx, 0, sizeof(vsi_ctx));
switch (type) {
case ICE_VSI_PF:
@@ -1603,6 +1628,8 @@ ice_setup_vsi(struct ice_pf *pf, enum ice_vsi_type type)
 ICE_AQ_VSI_OUTER_VLAN_TX_MODE_S) &
ICE_AQ_VSI_OUTER_VLAN_TX_MODE_M;
vsi_ctx.info.outer_vlan_flags |=
+   (ICE_AQ_VSI_OUTER_VLAN_EMODE_NOTHING <<
+   ICE_AQ_VSI_OUTER_VLAN_EMODE_S) |
(ICE_AQ_VSI_OUTER_TAG_VLAN_8100 <<
 ICE_AQ_VSI_OUTER_TAG_TYPE_S) &
ICE_AQ_VSI_OUTER_TAG_TYPE_M;
@@ -4406,11 +4433,87 @@ ice_vsi_dis_inner_stripping(struct ice_vsi *vsi)
return ice_vsi_manage_vlan_stripping(vsi, false);
 }
 
-static int ice_vsi_ena_outer_stripping(struct ice_vsi *vsi)
+/**
+ * tpid_to_vsi_outer_vlan_type - convert from TPID to VSI context based 
tag_type
+ * @tpid: tpid used to translate into VSI context based tag_type
+ * @tag_type: output variable to hold the VSI context based tag type
+ */
+static int tpid_to_vsi_outer_vlan_type(u16 tpid, u8 *tag_type)
+{
+   switch (tpid) {
+   case ETH_P_8021Q:
+   *tag_type = ICE_AQ_VSI_OUTER_TAG_VLAN_8100;
+   break;
+   case ETH_P_8021AD:
+   *tag_type = ICE_AQ_VS

Re: 21.11.4 patches review and test

2023-04-19 Thread YangHang Liu

Hi, Kevin

RedHat QE does not find new issues about the v21.11.4-rc1 dpdk during the
tests.

We tested below 18 scenarios and all got PASS on RHEL9:

   - Guest with device assignment(PF) throughput testing(1G hugepage size):
   PASS
   - Guest with device assignment(PF) throughput testing(2M hugepage size)
   : PASS
   - Guest with device assignment(VF) throughput testing: PASS
   - PVP (host dpdk testpmd as vswitch) 1Q: throughput testing: PASS
   - PVP vhost-user 2Q throughput testing: PASS
   - PVP vhost-user 1Q - cross numa node throughput testing: PASS
   - Guest with vhost-user 2 queues throughput testing: PASS
   - vhost-user reconnect with dpdk-client, qemu-server qemu reconnect: PASS
   - vhost-user reconnect with dpdk-client, qemu-server ovs reconnect: PASS
   - PVP  reconnect with dpdk-client, qemu-server: PASS
   - PVP 1Q live migration testing: PASS
   - PVP 1Q cross numa node live migration testing: PASS
   - Guest with ovs+dpdk+vhost-user 1Q live migration testing: PASS
   - Guest with ovs+dpdk+vhost-user 1Q live migration testing (2M): PASS
   - Guest with ovs+dpdk+vhost-user 2Q live migration testing: PASS
   - Guest with ovs+dpdk+vhost-user 4Q live migration testing: PASS
   - Host PF + DPDK testing: PASS
   - Host VF + DPDK testing: PASS

Test Versions:

   - qemu-kvm-6.2.0
   - kernel 5.14
   - dpdk 21.11.4-rc1

git log -1

commit f7dce59377b34750fdda7d1780d527233c84663f

Author: Kevin Traynor 

Date: Thu Apr 6 09:11:25 2023 +0100

version: 21.11.4-rc1

Signed-off-by: Kevin Traynor 


   - Test device : X540-AT2 NIC(ixgbe, 10G)

Best Regards,
YangHang Liu

On Thu, Apr 13, 2023 at 2:13 PM Xu, HailinX  wrote:

> > -Original Message-
> > From: Kevin Traynor 
> > Sent: Thursday, April 6, 2023 7:38 PM
> > To: sta...@dpdk.org
> > Cc: dev@dpdk.org; Abhishek Marathe ;
> > Ali Alnubani ; Walker, Benjamin
> > ; David Christensen ;
> > Hemant Agrawal ; Stokes, Ian
> > ; Jerin Jacob ; Mcnamara, John
> > ; Ju-Hyoung Lee ; Kevin
> > Traynor ; Luca Boccassi ; Pei
> > Zhang ; Xu, Qian Q ; Raslan
> > Darawsheh ; Thomas Monjalon
> > ; yangh...@redhat.com; Peng, Yuan
> > ; Chen, Zhaoyan 
> > Subject: 21.11.4 patches review and test
> >
> > Hi all,
> >
> > Here is a list of patches targeted for stable release 21.11.4.
> >
> > The planned date for the final release is 25th April.
> >
> > Please help with testing and validation of your use cases and report any
> > issues/results with reply-all to this mail. For the final release the
> fixes and
> > reported validations will be added to the release notes.
> >
> > A release candidate tarball can be found at:
> >
> > https://dpdk.org/browse/dpdk-stable/tag/?id=v21.11.4-rc1
> >
> > These patches are located at branch 21.11 of dpdk-stable repo:
> > https://dpdk.org/browse/dpdk-stable/
> >
> > Thanks.
> >
> > Kevin
>
> HI All,
>
> Update the test status for Intel part. Till now dpdk21.11.4-rc1 validation
> test rate is 85%. No critical issue is found.
> 2 new bugs are found, 1 new issue is under confirming by Intel Dev.
> New bugs:   --20.11.8-rc1 also has these two issues
>   1. pvp_qemu_multi_paths_port_restart:perf_pvp_qemu_vector_rx_mac:
> performance drop about 23.5% when send small packets
> https://bugs.dpdk.org/show_bug.cgi?id=1212-- no fix yet
>   2. some of the virtio tests are failing:-- Intel dev is under
> investigating
> # Basic Intel(R) NIC testing
> * Build & CFLAG compile: cover the build test combination with latest
> GCC/Clang version and the popular OS revision such as
>   Ubuntu20.04, Ubuntu22.04, Fedora35, Fedora37, RHEL8.6, RHEL8.4,
> FreeBSD13.1, SUSE15, CentOS7.9, etc.
> - All test done. No new dpdk issue is found.
> * PF(i40e, ixgbe): test scenarios including
> RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc.
> - All test done. No new dpdk issue is found.
> * VF(i40e, ixgbe): test scenarios including
> VF-RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc.
> - All test done. No new dpdk issue is found.
> * PF/VF(ice): test scenarios including Switch features/Package
> Management/Flow Director/Advanced Tx/Advanced RSS/ACL/DCF/Flexible
> Descriptor, etc.
> - All test done. No new dpdk issue is found.
> * Intel NIC single core/NIC performance: test scenarios including PF/VF
> single core performance test, etc.
> - All test done. No new dpdk issue is found.
> * IPsec: test scenarios including ipsec/ipsec-gw/ipsec library basic test
> - QAT&SW/FIB library, etc.
> - On going.
>
> # Basic cryptodev and virtio testing
> * Virtio: both function and performance test are covered. Such as
> PVP/Virtio_loopback/virtio-user loopback/virtio-net VM2VM perf
> testing/VMAWARE ESXI 8.0, etc.
> - All test done. found bug1.
> * Cryptodev:
>   *Function test: test scenarios including Cryptodev API
> testing/CompressDev ISA-L/QAT/ZLIB PMD Testing/FIPS, etc.
> - Execution rate is 90%. found bug2.
>   *Performance test: test scenarios including Thoughput
> Performance/Cryptodev Latency, etc.
> - All test don

Re: Event device early back-pressure indication

2023-04-19 Thread Jerin Jacob

On Mon, Apr 17, 2023 at 9:06 PM Mattias Rönnblom
 wrote:
>
> On 2023-04-17 14:52, Jerin Jacob wrote:
> > On Thu, Apr 13, 2023 at 12:24 PM Mattias Rönnblom
> >  wrote:
> >>
> >>
> >> void
> >> rte_event_return_new_credits(...);
> >>
> >> Thoughts?
> >
> > I see the following cons on this approach.
> >
>
> Does the use case in my original e-mail seem like a reasonable one to
> you? If yes, is there some way one could solve this problem with a
> clever use of the current Eventdev API? That would obviously be preferable.

I think, the use case is reasonable. For me, most easy path to achieve
the functionality
is setting rte_event_dev_config::nb_events_limit as for a given
application always
targeted to work X number of packets per second. Giving that upfront
kind of make
life easy for application writers and drivers at the cost of
allocating required memory.

>
> > # Adding multiple APIs in fast path to driver layer may not
> > performance effective solution.
>
> For event devices with a software-managed credit system, pre-allocation
> would be very cheap. And, if an application prefer to handle back
> pressure after-the-fact, that option is still available.

I am worried about exposing PMD calls and application starts calling per packet,
e.s.p with burst size = 1 for latency critical applications.

>
> > # At least for cnxk HW, credits are for device, not per port. So cnxk
> > HW implementation can not use this scheme.
> >
>
> DSW's credit pool is also per device, but are cached on a per-port
> basis. Does cnxk driver rely on the hardware to signal "new event" back
> pressure? (From the driver code it looks like that is the case.)

Yes. But we can not really cache it per port without introducing
complex atomic logic.

>
> > Alternative solution could be, adding new flag for
> > rte_enqueue_new_burst(), where drivers waits until credit is available
> > to reduce the application overhead > and support in different HW 
> > implementations if this use case critical.
> >
> >   #define RTE_EVENT_FLAG_WAIT_TILL_CREDIT_AVILABLE (UINT32_C(1) << 0)
> >
> >
>
> This solution only works if the event device is the only source of work
> for the EAL thread. That is a really nice model, but I wouldn't trust on
> that to always be the case.

For non EAL thread, I am assuming it is HW event adapter kind of case,
In such case, they don't need to wait. I think, for SW EAL threads case only
we need to wait as application is expecting to make sure wait till
the credit is available to avoid error handling in application.

>
> Also, there may be work that should only be performed, if the system is
> not under very high load. Credits being available, especially combined
> with a flexible new even threshold would be an indicator.
>
> Another way would be to just provide an API call that gave an indication
> of a particular threshold has been reached (or simply return an
> approximation of the number of in-flight events). Such a mechanism
> wouldn't be able to leave any guarantees, but could make a future
> enqueue operation very likely to succeed.

Giving rte_event_dev_credits_avaiable(device_id) should be OK provided
it is not expecting fine-grained accuracy.  But my worry is applications starts
calling that per packet. Marking correct documentation may help. Not sure.

>
> >>
> >> Best regards,
> >>  Mattias
>

Re: Consult the official release version of dpdk-kmod

2023-04-19 Thread Thomas Monjalon

Hello,

I don't know what should be a release of dpdk-kmod.
When to have a new tag?

About your need for Linux, there is only igb_uio which is considered as 
deprecated.
It is better replaced with VFIO (note there is a no-iommu option).
Why do you really need igb_uio?


13/04/2023 15:14, wangzengyuan:
> Dear Tyler Retzlaff,
> 
> Thank you for reply. 
> 
> We are using Linux and would like to inquire about the release versions of 
> dpdk-kmod. Could you kindly provide us with this information, or direct us to 
> the appropriate channels to find it?
> 
> Thank you for your assistance.
> 
> Best regards,
> Zengyuan Wang
> 
> -邮件原件-
> 发件人: Tyler Retzlaff [mailto:roret...@linux.microsoft.com] 
> 发送时间: 2023年4月12日 23:23
> 收件人: wangzengyuan 
> 抄送: dev@dpdk.org; tho...@monjalon.net; david.march...@redhat.com; luyicai 
> ; zhangxu (BA) 
> 主题: Re: Consult the official release version of dpdk-kmod
> 
> On Mon, Apr 10, 2023 at 12:34:28PM +, wangzengyuan wrote:
> > Hi,
> > 
> > We are honored to use dpdk and dpdk-kmod, two outstanding open source 
> > softwares. However, according to the company's open source software usage 
> > standards, only officially released versions can be introduced as open 
> > source software. As far as I know, there is no official release of 
> > dpdk-kmod. Can the community release an official version for users?
> 
> are you asking about the linux or windows components? i can speak to plans 
> for the windows components if that's what is being asked.
> 
> > 
> > Thank you for your time.
> > 
> > Yours sincerely
> > 
> > Zengyuan Wang
>

Re: [PATCH v5] enhance NUMA affinity heuristic

2023-04-19 Thread Thomas Monjalon

13/04/2023 02:56, You, KaisenX:
> From: You, KaisenX
> > From: Thomas Monjalon 
> > >
> > > I'm not comfortable with this patch.
> > >
> > > First, there is no comment in the code which helps to understand the 
> > > logic.
> > > Second, I'm afraid changing the value of the per-core variable
> > > _socket_id may have an impact on some applications.
> > >
> Hi Thomas, I'm sorry to bother you again, but we can't think of a better 
> solution for now,
> would you please give me some suggestion, and then I will modify it 
> accordingly.

You need to better explain the logic
both in the commit message and in code comments.
When it will be done, it will be easier to have a discussion
with other maintainers and community experts.
Thank you

> > Thank you for your reply.
> > First, about comments, I can submit a new patch to add comments to help
> > understand.
> > Second, if you do not change the value of the per-core variable_ socket_ id,
> > /lib/eal/common/malloc_heap.c
> > malloc_get_numa_socket(void)
> > {
> > const struct internal_config *conf = 
> > eal_get_internal_configuration();
> > unsigned int socket_id = rte_socket_id();   // The return value of
> > "rte_socket_id()" is 1
> > unsigned int idx;
> > 
> > if (socket_id != (unsigned int)SOCKET_ID_ANY)
> > return socket_id;//so return here
> > 
> > This will cause return here, This function returns the socket_id of 
> > unallocated
> > memory.
> > 
> > If you have a better solution, I can modify it.

Re: [PATCH v4] app/testpmd: txonly multiflow port change support

2023-04-19 Thread Singh, Aman Deep




On 4/12/2023 11:46 PM, Joshua Washington wrote:

Google cloud routes traffic using IP addresses without the support of MAC
addresses, so changing source IP address for txonly-multi-flow can have
negative performance implications for net/gve when using testpmd. This
patch updates txonly multiflow mode to modify source ports instead of
source IP addresses.


Generally routing is based on DST IP addresses, was SRC IP also having an
impact in your case ?



The change can be tested with the following command:
dpdk-testpmd -- --forward-mode=txonly --txonly-multi-flow \
 --txip=,


Missing "-" in command: --tx-ip=,



Signed-off-by: Joshua Washington 
Reviewed-by: Rushil Gupta 
---
  app/test-pmd/txonly.c | 34 ++
  1 file changed, 18 insertions(+), 16 deletions(-)

diff --git a/app/test-pmd/txonly.c b/app/test-pmd/txonly.c
index b3d6873104..7fc743b508 100644
--- a/app/test-pmd/txonly.c
+++ b/app/test-pmd/txonly.c
@@ -56,7 +56,7 @@ uint32_t tx_ip_dst_addr = (198U << 24) | (18 << 16) | (0 << 
8) | 2;
  #define IP_DEFTTL  64   /* from RFC 1340. */
  
  static struct rte_ipv4_hdr pkt_ip_hdr; /**< IP header of transmitted packets. */

-RTE_DEFINE_PER_LCORE(uint8_t, _ip_var); /**< IP address variation */
+RTE_DEFINE_PER_LCORE(uint16_t, _src_var); /**< Source port variation */
  static struct rte_udp_hdr pkt_udp_hdr; /**< UDP header of tx packets. */
  
  static uint64_t timestamp_mask; /**< Timestamp dynamic flag mask */

@@ -230,28 +230,30 @@ pkt_burst_prepare(struct rte_mbuf *pkt, struct 
rte_mempool *mbp,
copy_buf_to_pkt(eth_hdr, sizeof(*eth_hdr), pkt, 0);
copy_buf_to_pkt(&pkt_ip_hdr, sizeof(pkt_ip_hdr), pkt,
sizeof(struct rte_ether_hdr));
+   copy_buf_to_pkt(&pkt_udp_hdr, sizeof(pkt_udp_hdr), pkt,
+   sizeof(struct rte_ether_hdr) +
+   sizeof(struct rte_ipv4_hdr));
if (txonly_multi_flow) {
-   uint8_t  ip_var = RTE_PER_LCORE(_ip_var);
-   struct rte_ipv4_hdr *ip_hdr;
-   uint32_t addr;
+   uint16_t src_var = RTE_PER_LCORE(_src_var);
+   struct rte_udp_hdr *udp_hdr;
+   uint16_t port;
  
-		ip_hdr = rte_pktmbuf_mtod_offset(pkt,

-   struct rte_ipv4_hdr *,
-   sizeof(struct rte_ether_hdr));
+   udp_hdr = rte_pktmbuf_mtod_offset(pkt,
+   struct rte_udp_hdr *,
+   sizeof(struct rte_ether_hdr) +
+   sizeof(struct rte_ipv4_hdr));
/*
-* Generate multiple flows by varying IP src addr. This
-* enables packets are well distributed by RSS in
+* Generate multiple flows by varying UDP source port.
+* This enables packets are well distributed by RSS in
 * receiver side if any and txonly mode can be a decent
 * packet generator for developer's quick performance
 * regression test.
 */
-   addr = (tx_ip_dst_addr | (ip_var++ << 8)) + rte_lcore_id();


Good to have feature where last IP octet had lcore_id.
Helped to identify, packet came from which core.


-   ip_hdr->src_addr = rte_cpu_to_be_32(addr);
-   RTE_PER_LCORE(_ip_var) = ip_var;
+
+   port = src_var++;
+   udp_hdr->src_port = rte_cpu_to_be_16(port);
+   RTE_PER_LCORE(_src_var) = src_var;


To be safe, can we use the Ephemeral port range [49152  to 65535]
and adjust lcore_id within it.


}
-   copy_buf_to_pkt(&pkt_udp_hdr, sizeof(pkt_udp_hdr), pkt,
-   sizeof(struct rte_ether_hdr) +
-   sizeof(struct rte_ipv4_hdr));
  
  	if (unlikely(tx_pkt_split == TX_PKT_SPLIT_RND) || txonly_multi_flow)

update_pkt_header(pkt, pkt_len);
@@ -393,7 +395,7 @@ pkt_burst_transmit(struct fwd_stream *fs)
nb_tx = common_fwd_stream_transmit(fs, pkts_burst, nb_pkt);
  
  	if (txonly_multi_flow)

-   RTE_PER_LCORE(_ip_var) -= nb_pkt - nb_tx;
+   RTE_PER_LCORE(_src_var) -= nb_pkt - nb_tx;
  
  	if (unlikely(nb_tx < nb_pkt)) {

if (verbose_level > 0 && fs->fwd_dropped == 0)

Re: 20.11.8 patches review and test

2023-04-19 Thread Luca Boccassi

On Wed, 19 Apr 2023 at 10:22, Ali Alnubani  wrote:
>
> > -Original Message-
> > From: Ali Alnubani 
> > Sent: Wednesday, April 12, 2023 6:15 PM
> > To: luca.bocca...@gmail.com; sta...@dpdk.org
> > Cc: dev@dpdk.org; Abhishek Marathe ;
> > benjamin.wal...@intel.com; David Christensen ;
> > Hemant Agrawal ; Ian Stokes
> > ; Jerin Jacob ; John McNamara
> > ; Ju-Hyoung Lee ;
> > Kevin Traynor ; Luca Boccassi ;
> > Pei Zhang ; qian.q...@intel.com; Raslan Darawsheh
> > ; NBU-Contact-Thomas Monjalon (EXTERNAL)
> > ; Yanghang Liu ;
> > yuan.p...@intel.com; zhaoyan.c...@intel.com
> > Subject: RE: 20.11.8 patches review and test
> >
> > > -Original Message-
> > > From: luca.bocca...@gmail.com 
> > > Sent: Friday, March 31, 2023 9:20 PM
> > > To: sta...@dpdk.org
> > > Cc: dev@dpdk.org; Abhishek Marathe
> > ;
> > > Ali Alnubani ; benjamin.wal...@intel.com; David
> > > Christensen ; Hemant Agrawal
> > > ; Ian Stokes ; Jerin
> > > Jacob ; John McNamara
> > ;
> > > Ju-Hyoung Lee ; Kevin Traynor
> > > ; Luca Boccassi ; Pei Zhang
> > > ; qian.q...@intel.com; Raslan Darawsheh
> > > ; NBU-Contact-Thomas Monjalon (EXTERNAL)
> > > ; Yanghang Liu ;
> > > yuan.p...@intel.com; zhaoyan.c...@intel.com
> > > Subject: 20.11.8 patches review and test
> > >
> > > Hi all,
> > >
> > > Here is a list of patches targeted for stable release 20.11.8.
> > >
> > > The planned date for the final release is April 17th.
> > >
> > > Please help with testing and validation of your use cases and report
> > > any issues/results with reply-all to this mail. For the final release
> > > the fixes and reported validations will be added to the release notes.
> > >
> > > A release candidate tarball can be found at:
> > >
> > > https://dpdk.org/browse/dpdk-stable/tag/?id=v20.11.8-rc1
> > >
> > > These patches are located at branch 20.11 of dpdk-stable repo:
> > > https://dpdk.org/browse/dpdk-stable/
> > >
> > > Thanks.
> > >
> > > Luca Boccassi
> > >
> > > ---
> >
> > Hello,
> >
> > We ran the following functional tests with Nvidia hardware on v20.11.8-rc1:
> > - Basic functionality:
> >   Send and receive multiple types of traffic.
> > - testpmd xstats counter test.
> > - testpmd timestamp test.
> > - Changing/checking link status through testpmd.
> > - rte_flow tests.
> > - Some RSS tests.
> > - VLAN filtering, stripping and insertion tests.
> > - Checksum and TSO tests.
> > - ptype tests.
> > - link_status_interrupt example application tests.
> > - l3fwd-power example application tests.
> > - Multi-process example applications tests.
> > - Hardware LRO tests.
> >
> > Functional tests ran on:
> > - NIC: ConnectX-6 Dx / OS: Ubuntu 20.04 / Driver: MLNX_OFED_LINUX-5.9-
> > 0.5.6.0 / Firmware: 22.36.1010
> > - NIC: ConnectX-7 / OS: Ubuntu 20.04 / Driver: MLNX_OFED_LINUX-5.9-
> > 0.5.6.0 / Firmware: 22.36.1010
> > - DPU: BlueField-2 / DOCA SW version: 1.5.1 / Firmware: 24.35.2000
> >
> > Additionally, we ran compilation tests with multiple configurations in the
> > following OS/driver combinations:
> > - Ubuntu 20.04.5 with MLNX_OFED_LINUX-5.9-0.5.6.0.
> > - Ubuntu 20.04.5 with rdma-core master (f0a079f).
> > - Ubuntu 20.04.5 with rdma-core v28.0.
> > - Ubuntu 18.04.6 with rdma-core v17.1.
> > - Ubuntu 18.04.6 with rdma-core master (f0a079f) (i386).
> > - Fedora 37 with rdma-core v41.0.
> > - Fedora 39 (Rawhide) with rdma-core v44.0.
> > - CentOS 7 7.9.2009 with rdma-core master (f0a079f).
> > - CentOS 7 7.9.2009 with MLNX_OFED_LINUX-5.9-0.5.6.0.
> > - CentOS 8 8.4.2105 with rdma-core master (f0a079f).
> > - OpenSUSE Leap 15.4 with rdma-core v38.1.
> > - Windows Server 2019 with Clang 11.0.0.
> >
> > We don't see new issues caused by the changes in this release.
> >
> > Please note that not all the functional tests mentioned above fall under
> > "Basic functionality with testpmd" like reported in the release notes for
> > previous releases:
> > https://git.dpdk.org/dpdk-
> > stable/commit/?h=v20.11.7&id=62865fef48cb93042e8b9f85821eb02e1031e8f
> > 0
> > Some of them test other applications.
> >
> > Thanks,
> > Ali
>
> Hello,
>
> I see this documentation build failure on Fedora 37:
>
> $ ninja-build -C build doc
> [..]
> [2/4] Generating doc/api/doxygen with a custom command
> FAILED: doc/api/html
> /root/dpdk/doc/api/generate_doxygen.sh doc/api/doxy-api.conf doc/api/html 
> /root/dpdk/doc/api/doxy-html-custom.sh
> /root/dpdk/lib/librte_cryptodev/rte_cryptodev_pmd.h:489: error: found 
> documented return type for rte_cryptodev_pmd_callback_process that does not 
> return anything (warning treated as error, aborting now)
> [..]
> ninja: build stopped: subcommand failed.

I cannot reproduce this on Debian. Does it start working again if you
revert commit 6500e9e4d8d556a3d29c26b5fe2c9d5f2c6acd1a ?

RE: 20.11.8 patches review and test

2023-04-19 Thread Ali Alnubani

> -Original Message-
> From: Luca Boccassi 
> Sent: Wednesday, April 19, 2023 4:02 PM
> To: Ali Alnubani 
> Cc: sta...@dpdk.org; dev@dpdk.org; John McNamara
> ; Kevin Traynor ;
> Raslan Darawsheh ; NBU-Contact-Thomas Monjalon
> (EXTERNAL) 
> Subject: Re: 20.11.8 patches review and test
> 
> On Wed, 19 Apr 2023 at 10:22, Ali Alnubani  wrote:
> >
> > > -Original Message-
> > > From: Ali Alnubani 
> > > Sent: Wednesday, April 12, 2023 6:15 PM
> > > To: luca.bocca...@gmail.com; sta...@dpdk.org
> > > Cc: dev@dpdk.org; Abhishek Marathe
> ;
> > > benjamin.wal...@intel.com; David Christensen
> ;
> > > Hemant Agrawal ; Ian Stokes
> > > ; Jerin Jacob ; John
> McNamara
> > > ; Ju-Hyoung Lee ;
> > > Kevin Traynor ; Luca Boccassi
> ;
> > > Pei Zhang ; qian.q...@intel.com; Raslan
> Darawsheh
> > > ; NBU-Contact-Thomas Monjalon (EXTERNAL)
> > > ; Yanghang Liu ;
> > > yuan.p...@intel.com; zhaoyan.c...@intel.com
> > > Subject: RE: 20.11.8 patches review and test
> > >
> > > > -Original Message-
> > > > From: luca.bocca...@gmail.com 
> > > > Sent: Friday, March 31, 2023 9:20 PM
> > > > To: sta...@dpdk.org
> > > > Cc: dev@dpdk.org; Abhishek Marathe
> > > ;
> > > > Ali Alnubani ; benjamin.wal...@intel.com; David
> > > > Christensen ; Hemant Agrawal
> > > > ; Ian Stokes ;
> Jerin
> > > > Jacob ; John McNamara
> > > ;
> > > > Ju-Hyoung Lee ; Kevin Traynor
> > > > ; Luca Boccassi ; Pei Zhang
> > > > ; qian.q...@intel.com; Raslan Darawsheh
> > > > ; NBU-Contact-Thomas Monjalon (EXTERNAL)
> > > > ; Yanghang Liu ;
> > > > yuan.p...@intel.com; zhaoyan.c...@intel.com
> > > > Subject: 20.11.8 patches review and test
> > > >
> > > > Hi all,
> > > >
> > > > Here is a list of patches targeted for stable release 20.11.8.
> > > >
> > > > The planned date for the final release is April 17th.
> > > >
> > > > Please help with testing and validation of your use cases and report
> > > > any issues/results with reply-all to this mail. For the final release
> > > > the fixes and reported validations will be added to the release notes.
> > > >
> > > > A release candidate tarball can be found at:
> > > >
> > > > https://dpdk.org/browse/dpdk-stable/tag/?id=v20.11.8-rc1
> > > >
> > > > These patches are located at branch 20.11 of dpdk-stable repo:
> > > > https://dpdk.org/browse/dpdk-stable/
> > > >
> > > > Thanks.
> > > >
> > > > Luca Boccassi
> > > >
> > > > ---
> > >
> > > Hello,
> > >
> > > We ran the following functional tests with Nvidia hardware on v20.11.8-
> rc1:
> > > - Basic functionality:
> > >   Send and receive multiple types of traffic.
> > > - testpmd xstats counter test.
> > > - testpmd timestamp test.
> > > - Changing/checking link status through testpmd.
> > > - rte_flow tests.
> > > - Some RSS tests.
> > > - VLAN filtering, stripping and insertion tests.
> > > - Checksum and TSO tests.
> > > - ptype tests.
> > > - link_status_interrupt example application tests.
> > > - l3fwd-power example application tests.
> > > - Multi-process example applications tests.
> > > - Hardware LRO tests.
> > >
> > > Functional tests ran on:
> > > - NIC: ConnectX-6 Dx / OS: Ubuntu 20.04 / Driver: MLNX_OFED_LINUX-
> 5.9-
> > > 0.5.6.0 / Firmware: 22.36.1010
> > > - NIC: ConnectX-7 / OS: Ubuntu 20.04 / Driver: MLNX_OFED_LINUX-5.9-
> > > 0.5.6.0 / Firmware: 22.36.1010
> > > - DPU: BlueField-2 / DOCA SW version: 1.5.1 / Firmware: 24.35.2000
> > >
> > > Additionally, we ran compilation tests with multiple configurations in the
> > > following OS/driver combinations:
> > > - Ubuntu 20.04.5 with MLNX_OFED_LINUX-5.9-0.5.6.0.
> > > - Ubuntu 20.04.5 with rdma-core master (f0a079f).
> > > - Ubuntu 20.04.5 with rdma-core v28.0.
> > > - Ubuntu 18.04.6 with rdma-core v17.1.
> > > - Ubuntu 18.04.6 with rdma-core master (f0a079f) (i386).
> > > - Fedora 37 with rdma-core v41.0.
> > > - Fedora 39 (Rawhide) with rdma-core v44.0.
> > > - CentOS 7 7.9.2009 with rdma-core master (f0a079f).
> > > - CentOS 7 7.9.2009 with MLNX_OFED_LINUX-5.9-0.5.6.0.
> > > - CentOS 8 8.4.2105 with rdma-core master (f0a079f).
> > > - OpenSUSE Leap 15.4 with rdma-core v38.1.
> > > - Windows Server 2019 with Clang 11.0.0.
> > >
> > > We don't see new issues caused by the changes in this release.
> > >
> > > Please note that not all the functional tests mentioned above fall under
> > > "Basic functionality with testpmd" like reported in the release notes for
> > > previous releases:
> > > https://git.dpdk.org/dpdk-
> > >
> stable/commit/?h=v20.11.7&id=62865fef48cb93042e8b9f85821eb02e1031e8f
> > > 0
> > > Some of them test other applications.
> > >
> > > Thanks,
> > > Ali
> >
> > Hello,
> >
> > I see this documentation build failure on Fedora 37:
> >
> > $ ninja-build -C build doc
> > [..]
> > [2/4] Generating doc/api/doxygen with a custom command
> > FAILED: doc/api/html
> > /root/dpdk/doc/api/generate_doxygen.sh doc/api/doxy-api.conf
> doc/api/html /root/dpdk/doc/api/doxy-html-custom.sh
> > /root/dpdk/lib/librte_cryptodev/rte_cryptodev_pmd.h:489: error: found
> d

Re: 20.11.8 patches review and test

2023-04-19 Thread David Marchand

Hello Ali,

On Wed, Apr 19, 2023 at 11:22 AM Ali Alnubani  wrote:
> I see this documentation build failure on Fedora 37:
>
> $ ninja-build -C build doc
> [..]
> [2/4] Generating doc/api/doxygen with a custom command
> FAILED: doc/api/html
> /root/dpdk/doc/api/generate_doxygen.sh doc/api/doxy-api.conf doc/api/html 
> /root/dpdk/doc/api/doxy-html-custom.sh
> /root/dpdk/lib/librte_cryptodev/rte_cryptodev_pmd.h:489: error: found 
> documented return type for rte_cryptodev_pmd_callback_process that does not 
> return anything (warning treated as error, aborting now)
> [..]
> ninja: build stopped: subcommand failed.

This looks a lot like: 16de054160e3 ("lib: remove empty return types
from doxygen comments")

I don't think this function prototype is really different in the 20.11
stable branch (putting the __rte_internal tag aside).
Can you trigger this issue on the main branch?


-- 
David Marchand

RE: 20.11.8 patches review and test

2023-04-19 Thread Ali Alnubani

> -Original Message-
> From: David Marchand 
> Sent: Wednesday, April 19, 2023 4:12 PM
> To: Ali Alnubani 
> Cc: luca.bocca...@gmail.com; sta...@dpdk.org; dev@dpdk.org; Abhishek
> Marathe ;
> benjamin.wal...@intel.com; David Christensen ;
> Hemant Agrawal ; Ian Stokes
> ; Jerin Jacob ; John McNamara
> ; Ju-Hyoung Lee ;
> Kevin Traynor ; Luca Boccassi ;
> Pei Zhang ; qian.q...@intel.com; Raslan Darawsheh
> ; NBU-Contact-Thomas Monjalon (EXTERNAL)
> ; Yanghang Liu ;
> yuan.p...@intel.com; zhaoyan.c...@intel.com
> Subject: Re: 20.11.8 patches review and test
> 
> Hello Ali,
> 
> On Wed, Apr 19, 2023 at 11:22 AM Ali Alnubani  wrote:
> > I see this documentation build failure on Fedora 37:
> >
> > $ ninja-build -C build doc
> > [..]
> > [2/4] Generating doc/api/doxygen with a custom command
> > FAILED: doc/api/html
> > /root/dpdk/doc/api/generate_doxygen.sh doc/api/doxy-api.conf
> doc/api/html /root/dpdk/doc/api/doxy-html-custom.sh
> > /root/dpdk/lib/librte_cryptodev/rte_cryptodev_pmd.h:489: error: found
> documented return type for rte_cryptodev_pmd_callback_process that
> does not return anything (warning treated as error, aborting now)
> > [..]
> > ninja: build stopped: subcommand failed.
> 
> This looks a lot like: 16de054160e3 ("lib: remove empty return types
> from doxygen comments")

Yes, that's probably the case.

> 
> I don't think this function prototype is really different in the 20.11
> stable branch (putting the __rte_internal tag aside).
> Can you trigger this issue on the main branch?
> 

The main branch doesn't reproduce on the same environment.

> 
> --
> David Marchand

RE: 21.11.4 patches review and test

2023-04-19 Thread Ali Alnubani

> -Original Message-
> From: Kevin Traynor 
> Sent: Thursday, April 6, 2023 2:38 PM
> To: sta...@dpdk.org
> Cc: dev@dpdk.org; Abhishek Marathe ;
> Ali Alnubani ; benjamin.wal...@intel.com; David
> Christensen ; Hemant Agrawal
> ; Ian Stokes ; Jerin
> Jacob ; John McNamara ;
> Ju-Hyoung Lee ; Kevin Traynor
> ; Luca Boccassi ; Pei Zhang
> ; qian.q...@intel.com; Raslan Darawsheh
> ; NBU-Contact-Thomas Monjalon (EXTERNAL)
> ; yangh...@redhat.com; yuan.p...@intel.com;
> zhaoyan.c...@intel.com
> Subject: 21.11.4 patches review and test
> 
> Hi all,
> 
> Here is a list of patches targeted for stable release 21.11.4.
> 
> The planned date for the final release is 25th April.
> 
> Please help with testing and validation of your use cases and report
> any issues/results with reply-all to this mail. For the final release
> the fixes and reported validations will be added to the release notes.
> 
> A release candidate tarball can be found at:
> 
> https://dpdk.org/browse/dpdk-stable/tag/?id=v21.11.4-rc1
> 
> These patches are located at branch 21.11 of dpdk-stable repo:
> https://dpdk.org/browse/dpdk-stable/
> 
> Thanks.
> 
> Kevin
> 
> ---

We ran the following functional tests with Nvidia hardware on 21.11.4-rc1:
- Basic functionality:
  Send and receive multiple types of traffic.
- testpmd xstats counter test.
- testpmd timestamp test.
- Changing/checking link status through testpmd.
- rte_flow tests.
- Some RSS tests.
- VLAN filtering, stripping and insertion tests.
- Checksum and TSO tests.
- ptype tests.
- link_status_interrupt example application tests.
- l3fwd-power example application tests.
- Multi-process example applications tests.
- Hardware LRO tests.
- Regex application tests.
- Buffer Split tests.
- Tx scheduling tests.

Functional tests ran on:
- NIC: ConnectX-6 Dx / OS: Ubuntu 20.04 / Driver: MLNX_OFED_LINUX-5.9-0.5.6.0 / 
Firmware: 22.36.1010
- NIC: ConnectX-7 / OS: Ubuntu 20.04 / Driver: MLNX_OFED_LINUX-5.9-0.5.6.0 / 
Firmware: 22.36.1010
- DPU: BlueField-2 / DOCA SW version: 1.5.1 / Firmware: 24.35.2000

Additionally, we ran compilation tests with multiple configurations in the 
following OS/driver combinations:
- Ubuntu 20.04.5 with MLNX_OFED_LINUX-5.9-0.5.6.0.
- Ubuntu 20.04.5 with rdma-core master (f0a079f).
- Ubuntu 20.04.5 with rdma-core v28.0.
- Ubuntu 18.04.6 with rdma-core v17.1.
- Ubuntu 18.04.6 with rdma-core master (f0a079f) (i386).
- Fedora 37 with rdma-core v41.0.
- Fedora 39 (Rawhide) with rdma-core v44.0.
- CentOS 7 7.9.2009 with rdma-core master (f0a079f).
- CentOS 7 7.9.2009 with MLNX_OFED_LINUX-5.9-0.5.6.0.
- CentOS 8 8.4.2105 with rdma-core master (f0a079f).
- OpenSUSE Leap 15.4 with rdma-core v38.1.
- Windows Server 2019 with Clang 11.0.0.

We don't see new issues caused by the changes in this release.

Please note that not all the functional tests mentioned above fall under "Basic 
functionality with testpmd" like reported in the release notes for previous 
releases:
https://git.dpdk.org/dpdk-stable/commit/?h=v21.11.3&id=31608e4db56893c896375288671b5ee38723a211
Some of them test other applications.

Thanks,
Ali

Re: 20.11.8 patches review and test

2023-04-19 Thread David Marchand

On Wed, Apr 19, 2023 at 3:14 PM Ali Alnubani  wrote:
> >
> > I don't think this function prototype is really different in the 20.11
> > stable branch (putting the __rte_internal tag aside).
> > Can you trigger this issue on the main branch?
> >
>
> The main branch doesn't reproduce on the same environment.

Ok, same for me, I reproduced for 20.11 but not for main.

I think I have the reason.
We filter headers to be processed by doxygen via a name filter:

FILE_PATTERNS   = rte_*.h \

But this rte_cryptodev_pmd.h driver header has been renamed as
cryptodev_pmd.h in 21.11.
So the issue you reported only affects 20.11.

-- 
David Marchand

RE: [PATCH] test/crypto: add cryptodev reconfig test

2023-04-19 Thread O'Donovan, Saoirse

Hi Aakash,

> -Original Message-
> From: Aakash Sasidharan 
> Sent: Wednesday 5 April 2023 08:41
> To: Akhil Goyal ; Fan Zhang
> 
> Cc: jer...@marvell.com; ano...@marvell.com; dev@dpdk.org;
> asasidha...@marvell.com
> Subject: [PATCH] test/crypto: add cryptodev reconfig test
> 
> Add cryptodev tests to verify that the device supports reconfiguration any
> number of times via rte_cryptodev_configure API.
> 
> Signed-off-by: Aakash Sasidharan 
> ---
>  app/test/test_cryptodev.c | 81
> +++
>  1 file changed, 81 insertions(+)

Tested on the following PMDs: QAT + SW Crypto PMDs 
(snow3g, null, chachapoly, kasumi, aesni_mb, aesni_gcm, zuc)
The test results for the testcase were a mix of skipped and passed, based on 
the capabilities of each PMD, no failures. 

Tested-by: Saoirse O'Donovan

RE: [EXT] [RFC] lib: set/get max memzone segments

2023-04-19 Thread Devendra Singh Rawat


>diff --git a/drivers/net/qede/base/bcm_osal.c
>b/drivers/net/qede/base/bcm_osal.c
>index 2c59397..f195f2c 100644
>--- a/drivers/net/qede/base/bcm_osal.c
>+++ b/drivers/net/qede/base/bcm_osal.c
>@@ -47,10 +47,26 @@ void osal_poll_mode_dpc(osal_int_ptr_t
>hwfn_cookie)  }
>
> /* Array of memzone pointers */
>-static const struct rte_memzone
>*ecore_mz_mapping[RTE_MAX_MEMZONE];
>+static const struct rte_memzone **ecore_mz_mapping;
> /* Counter to track current memzone allocated */  static uint16_t
>ecore_mz_count;
>
>+int ecore_mz_mapping_alloc(void)
>+{
>+  ecore_mz_mapping = rte_malloc("ecore_mz_map", 0,
>+  rte_memzone_max_get() * sizeof(struct rte_memzone *));

Second parameter of rte_malloc() should be size and Third parameter should be 
alignment 0 in this case.

Check 
https://doc.dpdk.org/api/rte__malloc_8h.html#a247c99e8d36300c52729c9ee58c2b489

>diff --git a/drivers/net/qede/base/bcm_osal.h
>b/drivers/net/qede/base/bcm_osal.h
>index 67e7f75..97e261d 100644
>--- a/drivers/net/qede/base/bcm_osal.h
>+++ b/drivers/net/qede/base/bcm_osal.h
>@@ -477,4 +477,7 @@ enum dbg_status
>   qed_dbg_alloc_user_data(struct ecore_hwfn *p_hwfn,
>   qed_dbg_alloc_user_data(p_hwfn, user_data_ptr)  #define
>OSAL_DB_REC_OCCURRED(p_hwfn) nothing
>
>+int ecore_mz_mapping_alloc(void);
>+void ecore_mz_mapping_free(void);
>+
> #endif /* __BCM_OSAL_H */
>diff --git a/drivers/net/qede/qede_main.c b/drivers/net/qede/qede_main.c
>index 0303903..f116e86 100644
>--- a/drivers/net/qede/qede_main.c
>+++ b/drivers/net/qede/qede_main.c
>@@ -78,6 +78,12 @@ qed_probe(struct ecore_dev *edev, struct
>rte_pci_device *pci_dev,
>   return rc;
>   }
>
>+  rc = ecore_mz_mapping_alloc();

ecore_mz_mapping_alloc() should be called prior to calling ecore_hw_prepare().

>+  if (rc) {
>+  DP_ERR(edev, "mem zones array allocation failed\n");
>+  return rc;
>+  }
>+
>   return rc;
> }
>
>@@ -721,6 +727,7 @@ static void qed_remove(struct ecore_dev *edev)
>   if (!edev)
>   return;
>
>+  ecore_mz_mapping_free();
>   ecore_hw_remove(edev);
> }

ecore_mz_mapping_free() should be called after ecore_hw_remove();

Re: 20.11.8 patches review and test

2023-04-19 Thread Luca Boccassi

On Wed, 19 Apr 2023 at 14:25, David Marchand  wrote:
>
> On Wed, Apr 19, 2023 at 3:14 PM Ali Alnubani  wrote:
> > >
> > > I don't think this function prototype is really different in the 20.11
> > > stable branch (putting the __rte_internal tag aside).
> > > Can you trigger this issue on the main branch?
> > >
> >
> > The main branch doesn't reproduce on the same environment.
>
> Ok, same for me, I reproduced for 20.11 but not for main.
>
>
> I think I have the reason.
> We filter headers to be processed by doxygen via a name filter:
>
> FILE_PATTERNS   = rte_*.h \
>
> But this rte_cryptodev_pmd.h driver header has been renamed as
> cryptodev_pmd.h in 21.11.
> So the issue you reported only affects 20.11.

I can reproduce in debian testing, after backporting the mentioned
commit from main it seems fine, can you confirm as well that it works
in fedora?

https://github.com/bluca/dpdk-stable/commit/77f65b61f955fd817b3791049dda3032c459ac59

Re: 21.11.4 patches review and test

2023-04-19 Thread Kevin Traynor


On 19/04/2023 14:24, Ali Alnubani wrote:

-Original Message-
From: Kevin Traynor 
Sent: Thursday, April 6, 2023 2:38 PM
To: sta...@dpdk.org
Cc: dev@dpdk.org; Abhishek Marathe ;
Ali Alnubani ; benjamin.wal...@intel.com; David
Christensen ; Hemant Agrawal
; Ian Stokes ; Jerin
Jacob ; John McNamara ;
Ju-Hyoung Lee ; Kevin Traynor
; Luca Boccassi ; Pei Zhang
; qian.q...@intel.com; Raslan Darawsheh
; NBU-Contact-Thomas Monjalon (EXTERNAL)
; yangh...@redhat.com; yuan.p...@intel.com;
zhaoyan.c...@intel.com
Subject: 21.11.4 patches review and test

Hi all,

Here is a list of patches targeted for stable release 21.11.4.

The planned date for the final release is 25th April.

Please help with testing and validation of your use cases and report
any issues/results with reply-all to this mail. For the final release
the fixes and reported validations will be added to the release notes.

A release candidate tarball can be found at:

 https://dpdk.org/browse/dpdk-stable/tag/?id=v21.11.4-rc1

These patches are located at branch 21.11 of dpdk-stable repo:
 https://dpdk.org/browse/dpdk-stable/

Thanks.

Kevin

---


We ran the following functional tests with Nvidia hardware on 21.11.4-rc1:
- Basic functionality:
   Send and receive multiple types of traffic.
- testpmd xstats counter test.
- testpmd timestamp test.
- Changing/checking link status through testpmd.
- rte_flow tests.
- Some RSS tests.
- VLAN filtering, stripping and insertion tests.
- Checksum and TSO tests.
- ptype tests.
- link_status_interrupt example application tests.
- l3fwd-power example application tests.
- Multi-process example applications tests.
- Hardware LRO tests.
- Regex application tests.
- Buffer Split tests.
- Tx scheduling tests.

Functional tests ran on:
- NIC: ConnectX-6 Dx / OS: Ubuntu 20.04 / Driver: MLNX_OFED_LINUX-5.9-0.5.6.0 / 
Firmware: 22.36.1010
- NIC: ConnectX-7 / OS: Ubuntu 20.04 / Driver: MLNX_OFED_LINUX-5.9-0.5.6.0 / 
Firmware: 22.36.1010
- DPU: BlueField-2 / DOCA SW version: 1.5.1 / Firmware: 24.35.2000

Additionally, we ran compilation tests with multiple configurations in the 
following OS/driver combinations:
- Ubuntu 20.04.5 with MLNX_OFED_LINUX-5.9-0.5.6.0.
- Ubuntu 20.04.5 with rdma-core master (f0a079f).
- Ubuntu 20.04.5 with rdma-core v28.0.
- Ubuntu 18.04.6 with rdma-core v17.1.
- Ubuntu 18.04.6 with rdma-core master (f0a079f) (i386).
- Fedora 37 with rdma-core v41.0.
- Fedora 39 (Rawhide) with rdma-core v44.0.
- CentOS 7 7.9.2009 with rdma-core master (f0a079f).
- CentOS 7 7.9.2009 with MLNX_OFED_LINUX-5.9-0.5.6.0.
- CentOS 8 8.4.2105 with rdma-core master (f0a079f).
- OpenSUSE Leap 15.4 with rdma-core v38.1.
- Windows Server 2019 with Clang 11.0.0.

We don't see new issues caused by the changes in this release.



Great, thanks for testing and reporting Ali.
Kevin.


Please note that not all the functional tests mentioned above fall under "Basic 
functionality with testpmd" like reported in the release notes for previous releases:
https://git.dpdk.org/dpdk-stable/commit/?h=v21.11.3&id=31608e4db56893c896375288671b5ee38723a211
Some of them test other applications.

Thanks,
Ali

RE: 20.11.8 patches review and test

2023-04-19 Thread Ali Alnubani

> -Original Message-
> From: Luca Boccassi 
> Sent: Wednesday, April 19, 2023 5:15 PM
> To: David Marchand 
> Cc: Ali Alnubani ; sta...@dpdk.org; dev@dpdk.org;
> Abhishek Marathe ;
> benjamin.wal...@intel.com; David Christensen ;
> Hemant Agrawal ; Ian Stokes
> ; Jerin Jacob ; John McNamara
> ; Ju-Hyoung Lee ;
> Kevin Traynor ; Pei Zhang ;
> qian.q...@intel.com; Raslan Darawsheh ; NBU-
> Contact-Thomas Monjalon (EXTERNAL) ; Yanghang
> Liu ; yuan.p...@intel.com;
> zhaoyan.c...@intel.com
> Subject: Re: 20.11.8 patches review and test
> 
> On Wed, 19 Apr 2023 at 14:25, David Marchand
>  wrote:
> >
> > On Wed, Apr 19, 2023 at 3:14 PM Ali Alnubani  wrote:
> > > >
> > > > I don't think this function prototype is really different in the 20.11
> > > > stable branch (putting the __rte_internal tag aside).
> > > > Can you trigger this issue on the main branch?
> > > >
> > >
> > > The main branch doesn't reproduce on the same environment.
> >
> > Ok, same for me, I reproduced for 20.11 but not for main.
> >
> >
> > I think I have the reason.
> > We filter headers to be processed by doxygen via a name filter:
> >
> > FILE_PATTERNS   = rte_*.h \
> >
> > But this rte_cryptodev_pmd.h driver header has been renamed as
> > cryptodev_pmd.h in 21.11.
> > So the issue you reported only affects 20.11.
> 
> I can reproduce in debian testing, after backporting the mentioned
> commit from main it seems fine, can you confirm as well that it works
> in fedora?
> 
> https://github.com/bluca/dpdk-
> stable/commit/77f65b61f955fd817b3791049dda3032c459ac59

Now I see a different error:

[2/4] Generating doc/api/doxygen with a custom command
FAILED: doc/api/html
/tmp/dpdk/doc/api/generate_doxygen.sh doc/api/doxy-api.conf doc/api/html 
/tmp/dpdk/doc/api/doxy-html-custom.sh
/tmp/dpdk/lib/librte_vhost/rte_vhost_async.h:49: error: 
rte_vhost_async_channel_ops::transfer_data has @param documentation sections 
but no arguments (warning treated as error, aborting now)

Re: 20.11.8 patches review and test

2023-04-19 Thread Kevin Traynor

On 19/04/2023 15:23, Ali Alnubani wrote:

-Original Message-
From: Luca Boccassi 
Sent: Wednesday, April 19, 2023 5:15 PM
To: David Marchand 
Cc: Ali Alnubani ; sta...@dpdk.org; dev@dpdk.org;
Abhishek Marathe ;
benjamin.wal...@intel.com; David Christensen ;
Hemant Agrawal ; Ian Stokes
; Jerin Jacob ; John McNamara
; Ju-Hyoung Lee ;
Kevin Traynor ; Pei Zhang ;
qian.q...@intel.com; Raslan Darawsheh ; NBU-
Contact-Thomas Monjalon (EXTERNAL) ; Yanghang
Liu ; yuan.p...@intel.com;
zhaoyan.c...@intel.com
Subject: Re: 20.11.8 patches review and test

On Wed, 19 Apr 2023 at 14:25, David Marchand
 wrote:

On Wed, Apr 19, 2023 at 3:14 PM Ali Alnubani  wrote:

I don't think this function prototype is really different in the 20.11
stable branch (putting the __rte_internal tag aside).
Can you trigger this issue on the main branch?

The main branch doesn't reproduce on the same environment.

Ok, same for me, I reproduced for 20.11 but not for main.

I think I have the reason.
We filter headers to be processed by doxygen via a name filter:

FILE_PATTERNS   = rte_*.h \

But this rte_cryptodev_pmd.h driver header has been renamed as
cryptodev_pmd.h in 21.11.
So the issue you reported only affects 20.11.

I can reproduce in debian testing, after backporting the mentioned
commit from main it seems fine, can you confirm as well that it works
in fedora?

https://github.com/bluca/dpdk-
stable/commit/77f65b61f955fd817b3791049dda3032c459ac59

Now I see a different error:

[2/4] Generating doc/api/doxygen with a custom command
FAILED: doc/api/html
/tmp/dpdk/doc/api/generate_doxygen.sh doc/api/doxy-api.conf doc/api/html 
/tmp/dpdk/doc/api/doxy-html-custom.sh
/tmp/dpdk/lib/librte_vhost/rte_vhost_async.h:49: error: 
rte_vhost_async_channel_ops::transfer_data has @param documentation sections 
but no arguments (warning treated as error, aborting now)

See 
https://git.dpdk.org/dpdk-stable/commit/?h=21.11&id=adeaf361f0a5bb3992756fd4e727dd11ecca0943

Re: 20.11.8 patches review and test

2023-04-19 Thread Luca Boccassi

On Wed, 19 Apr 2023 at 15:26, Kevin Traynor  wrote:
>
> On 19/04/2023 15:23, Ali Alnubani wrote:
> >> -Original Message-
> >> From: Luca Boccassi 
> >> Sent: Wednesday, April 19, 2023 5:15 PM
> >> To: David Marchand 
> >> Cc: Ali Alnubani ; sta...@dpdk.org; dev@dpdk.org;
> >> Abhishek Marathe ;
> >> benjamin.wal...@intel.com; David Christensen ;
> >> Hemant Agrawal ; Ian Stokes
> >> ; Jerin Jacob ; John McNamara
> >> ; Ju-Hyoung Lee ;
> >> Kevin Traynor ; Pei Zhang ;
> >> qian.q...@intel.com; Raslan Darawsheh ; NBU-
> >> Contact-Thomas Monjalon (EXTERNAL) ; Yanghang
> >> Liu ; yuan.p...@intel.com;
> >> zhaoyan.c...@intel.com
> >> Subject: Re: 20.11.8 patches review and test
> >>
> >> On Wed, 19 Apr 2023 at 14:25, David Marchand
> >>  wrote:
> >>>
> >>> On Wed, Apr 19, 2023 at 3:14 PM Ali Alnubani  wrote:
> >
> > I don't think this function prototype is really different in the 20.11
> > stable branch (putting the __rte_internal tag aside).
> > Can you trigger this issue on the main branch?
> >
> 
>  The main branch doesn't reproduce on the same environment.
> >>>
> >>> Ok, same for me, I reproduced for 20.11 but not for main.
> >>>
> >>>
> >>> I think I have the reason.
> >>> We filter headers to be processed by doxygen via a name filter:
> >>>
> >>> FILE_PATTERNS   = rte_*.h \
> >>>
> >>> But this rte_cryptodev_pmd.h driver header has been renamed as
> >>> cryptodev_pmd.h in 21.11.
> >>> So the issue you reported only affects 20.11.
> >>
> >> I can reproduce in debian testing, after backporting the mentioned
> >> commit from main it seems fine, can you confirm as well that it works
> >> in fedora?
> >>
> >> https://github.com/bluca/dpdk-
> >> stable/commit/77f65b61f955fd817b3791049dda3032c459ac59
> >
> > Now I see a different error:
> >
> > [2/4] Generating doc/api/doxygen with a custom command
> > FAILED: doc/api/html
> > /tmp/dpdk/doc/api/generate_doxygen.sh doc/api/doxy-api.conf doc/api/html 
> > /tmp/dpdk/doc/api/doxy-html-custom.sh
> > /tmp/dpdk/lib/librte_vhost/rte_vhost_async.h:49: error: 
> > rte_vhost_async_channel_ops::transfer_data has @param documentation 
> > sections but no arguments (warning treated as error, aborting now)
>
> See
> https://git.dpdk.org/dpdk-stable/commit/?h=21.11&id=adeaf361f0a5bb3992756fd4e727dd11ecca0943

Thanks, any more errors with
https://github.com/bluca/dpdk-stable/commit/b75ebf643de0204d0092a56fbec63f0bcd10e89f
?

RE: 20.11.8 patches review and test

2023-04-19 Thread Ali Alnubani

> -Original Message-
> From: Luca Boccassi 
> Sent: Wednesday, April 19, 2023 5:30 PM
> To: Kevin Traynor 
> Cc: Ali Alnubani ; David Marchand
> ; sta...@dpdk.org; dev@dpdk.org;
> Abhishek Marathe ;
> benjamin.wal...@intel.com; David Christensen ;
> Hemant Agrawal ; Ian Stokes
> ; Jerin Jacob ; John McNamara
> ; Ju-Hyoung Lee ; Pei
> Zhang ; qian.q...@intel.com; Raslan Darawsheh
> ; NBU-Contact-Thomas Monjalon (EXTERNAL)
> ; Yanghang Liu ;
> yuan.p...@intel.com; zhaoyan.c...@intel.com
> Subject: Re: 20.11.8 patches review and test
> 
> On Wed, 19 Apr 2023 at 15:26, Kevin Traynor  wrote:
> >
> > On 19/04/2023 15:23, Ali Alnubani wrote:
> > >> -Original Message-
> > >> From: Luca Boccassi 
> > >> Sent: Wednesday, April 19, 2023 5:15 PM
> > >> To: David Marchand 
> > >> Cc: Ali Alnubani ; sta...@dpdk.org;
> dev@dpdk.org;
> > >> Abhishek Marathe ;
> > >> benjamin.wal...@intel.com; David Christensen
> ;
> > >> Hemant Agrawal ; Ian Stokes
> > >> ; Jerin Jacob ; John
> McNamara
> > >> ; Ju-Hyoung Lee
> ;
> > >> Kevin Traynor ; Pei Zhang
> ;
> > >> qian.q...@intel.com; Raslan Darawsheh ; NBU-
> > >> Contact-Thomas Monjalon (EXTERNAL) ;
> Yanghang
> > >> Liu ; yuan.p...@intel.com;
> > >> zhaoyan.c...@intel.com
> > >> Subject: Re: 20.11.8 patches review and test
> > >>
> > >> On Wed, 19 Apr 2023 at 14:25, David Marchand
> > >>  wrote:
> > >>>
> > >>> On Wed, Apr 19, 2023 at 3:14 PM Ali Alnubani 
> wrote:
> > >
> > > I don't think this function prototype is really different in the 20.11
> > > stable branch (putting the __rte_internal tag aside).
> > > Can you trigger this issue on the main branch?
> > >
> > 
> >  The main branch doesn't reproduce on the same environment.
> > >>>
> > >>> Ok, same for me, I reproduced for 20.11 but not for main.
> > >>>
> > >>>
> > >>> I think I have the reason.
> > >>> We filter headers to be processed by doxygen via a name filter:
> > >>>
> > >>> FILE_PATTERNS   = rte_*.h \
> > >>>
> > >>> But this rte_cryptodev_pmd.h driver header has been renamed as
> > >>> cryptodev_pmd.h in 21.11.
> > >>> So the issue you reported only affects 20.11.
> > >>
> > >> I can reproduce in debian testing, after backporting the mentioned
> > >> commit from main it seems fine, can you confirm as well that it works
> > >> in fedora?
> > >>
> > >> https://github.com/bluca/dpdk-
> > >> stable/commit/77f65b61f955fd817b3791049dda3032c459ac59
> > >
> > > Now I see a different error:
> > >
> > > [2/4] Generating doc/api/doxygen with a custom command
> > > FAILED: doc/api/html
> > > /tmp/dpdk/doc/api/generate_doxygen.sh doc/api/doxy-api.conf
> doc/api/html /tmp/dpdk/doc/api/doxy-html-custom.sh
> > > /tmp/dpdk/lib/librte_vhost/rte_vhost_async.h:49: error:
> rte_vhost_async_channel_ops::transfer_data has @param documentation
> sections but no arguments (warning treated as error, aborting now)
> >
> > See
> > https://git.dpdk.org/dpdk-
> stable/commit/?h=21.11&id=adeaf361f0a5bb3992756fd4e727dd11ecca0943
> 
> Thanks, any more errors with
> https://github.com/bluca/dpdk-
> stable/commit/b75ebf643de0204d0092a56fbec63f0bcd10e89f
> ?

Build on Fedora with Doxygen 1.9.5 now passes with both patches:
https://github.com/bluca/dpdk-stable/commit/77f65b61f955fd817b3791049dda3032c459ac59.patch
https://github.com/bluca/dpdk-stable/commit/b75ebf643de0204d0092a56fbec63f0bcd10e89f.patch

Thanks!

Re: 20.11.8 patches review and test

2023-04-19 Thread David Marchand

On Wed, Apr 19, 2023 at 4:30 PM Luca Boccassi  wrote:
>
> On Wed, 19 Apr 2023 at 15:26, Kevin Traynor  wrote:
> >
> > On 19/04/2023 15:23, Ali Alnubani wrote:
> > >> -Original Message-
> > >> From: Luca Boccassi 
> > >> Sent: Wednesday, April 19, 2023 5:15 PM
> > >> To: David Marchand 
> > >> Cc: Ali Alnubani ; sta...@dpdk.org; dev@dpdk.org;
> > >> Abhishek Marathe ;
> > >> benjamin.wal...@intel.com; David Christensen ;
> > >> Hemant Agrawal ; Ian Stokes
> > >> ; Jerin Jacob ; John McNamara
> > >> ; Ju-Hyoung Lee ;
> > >> Kevin Traynor ; Pei Zhang ;
> > >> qian.q...@intel.com; Raslan Darawsheh ; NBU-
> > >> Contact-Thomas Monjalon (EXTERNAL) ; Yanghang
> > >> Liu ; yuan.p...@intel.com;
> > >> zhaoyan.c...@intel.com
> > >> Subject: Re: 20.11.8 patches review and test
> > >>
> > >> On Wed, 19 Apr 2023 at 14:25, David Marchand
> > >>  wrote:
> > >>>
> > >>> On Wed, Apr 19, 2023 at 3:14 PM Ali Alnubani  wrote:
> > >
> > > I don't think this function prototype is really different in the 20.11
> > > stable branch (putting the __rte_internal tag aside).
> > > Can you trigger this issue on the main branch?
> > >
> > 
> >  The main branch doesn't reproduce on the same environment.
> > >>>
> > >>> Ok, same for me, I reproduced for 20.11 but not for main.
> > >>>
> > >>>
> > >>> I think I have the reason.
> > >>> We filter headers to be processed by doxygen via a name filter:
> > >>>
> > >>> FILE_PATTERNS   = rte_*.h \
> > >>>
> > >>> But this rte_cryptodev_pmd.h driver header has been renamed as
> > >>> cryptodev_pmd.h in 21.11.
> > >>> So the issue you reported only affects 20.11.
> > >>
> > >> I can reproduce in debian testing, after backporting the mentioned
> > >> commit from main it seems fine, can you confirm as well that it works
> > >> in fedora?
> > >>
> > >> https://github.com/bluca/dpdk-
> > >> stable/commit/77f65b61f955fd817b3791049dda3032c459ac59
> > >
> > > Now I see a different error:
> > >
> > > [2/4] Generating doc/api/doxygen with a custom command
> > > FAILED: doc/api/html
> > > /tmp/dpdk/doc/api/generate_doxygen.sh doc/api/doxy-api.conf doc/api/html 
> > > /tmp/dpdk/doc/api/doxy-html-custom.sh
> > > /tmp/dpdk/lib/librte_vhost/rte_vhost_async.h:49: error: 
> > > rte_vhost_async_channel_ops::transfer_data has @param documentation 
> > > sections but no arguments (warning treated as error, aborting now)
> >
> > See
> > https://git.dpdk.org/dpdk-stable/commit/?h=21.11&id=adeaf361f0a5bb3992756fd4e727dd11ecca0943
>
> Thanks, any more errors with
> https://github.com/bluca/dpdk-stable/commit/b75ebf643de0204d0092a56fbec63f0bcd10e89f

With those two backports, it works for me.

b75ebf643d - (HEAD -> 20.11, bluca/20.11) vhost: fix doxygen warnings
(6 minutes ago) 
77f65b61f9 - lib: remove empty return types from doxygen comments (23
minutes ago) 
a75247cbdc - (stable/20.11) crypto/snow3g: fix snow3g enqueue stat
increment (24 hours ago) 


-- 
David Marchand

Re: 20.11.8 patches review and test

2023-04-19 Thread Luca Boccassi

On Wed, 19 Apr 2023 at 15:36, David Marchand  wrote:
>
> On Wed, Apr 19, 2023 at 4:30 PM Luca Boccassi  wrote:
> >
> > On Wed, 19 Apr 2023 at 15:26, Kevin Traynor  wrote:
> > >
> > > On 19/04/2023 15:23, Ali Alnubani wrote:
> > > >> -Original Message-
> > > >> From: Luca Boccassi 
> > > >> Sent: Wednesday, April 19, 2023 5:15 PM
> > > >> To: David Marchand 
> > > >> Cc: Ali Alnubani ; sta...@dpdk.org; dev@dpdk.org;
> > > >> Abhishek Marathe ;
> > > >> benjamin.wal...@intel.com; David Christensen ;
> > > >> Hemant Agrawal ; Ian Stokes
> > > >> ; Jerin Jacob ; John McNamara
> > > >> ; Ju-Hyoung Lee ;
> > > >> Kevin Traynor ; Pei Zhang ;
> > > >> qian.q...@intel.com; Raslan Darawsheh ; NBU-
> > > >> Contact-Thomas Monjalon (EXTERNAL) ; Yanghang
> > > >> Liu ; yuan.p...@intel.com;
> > > >> zhaoyan.c...@intel.com
> > > >> Subject: Re: 20.11.8 patches review and test
> > > >>
> > > >> On Wed, 19 Apr 2023 at 14:25, David Marchand
> > > >>  wrote:
> > > >>>
> > > >>> On Wed, Apr 19, 2023 at 3:14 PM Ali Alnubani  
> > > >>> wrote:
> > > >
> > > > I don't think this function prototype is really different in the 
> > > > 20.11
> > > > stable branch (putting the __rte_internal tag aside).
> > > > Can you trigger this issue on the main branch?
> > > >
> > > 
> > >  The main branch doesn't reproduce on the same environment.
> > > >>>
> > > >>> Ok, same for me, I reproduced for 20.11 but not for main.
> > > >>>
> > > >>>
> > > >>> I think I have the reason.
> > > >>> We filter headers to be processed by doxygen via a name filter:
> > > >>>
> > > >>> FILE_PATTERNS   = rte_*.h \
> > > >>>
> > > >>> But this rte_cryptodev_pmd.h driver header has been renamed as
> > > >>> cryptodev_pmd.h in 21.11.
> > > >>> So the issue you reported only affects 20.11.
> > > >>
> > > >> I can reproduce in debian testing, after backporting the mentioned
> > > >> commit from main it seems fine, can you confirm as well that it works
> > > >> in fedora?
> > > >>
> > > >> https://github.com/bluca/dpdk-
> > > >> stable/commit/77f65b61f955fd817b3791049dda3032c459ac59
> > > >
> > > > Now I see a different error:
> > > >
> > > > [2/4] Generating doc/api/doxygen with a custom command
> > > > FAILED: doc/api/html
> > > > /tmp/dpdk/doc/api/generate_doxygen.sh doc/api/doxy-api.conf 
> > > > doc/api/html /tmp/dpdk/doc/api/doxy-html-custom.sh
> > > > /tmp/dpdk/lib/librte_vhost/rte_vhost_async.h:49: error: 
> > > > rte_vhost_async_channel_ops::transfer_data has @param documentation 
> > > > sections but no arguments (warning treated as error, aborting now)
> > >
> > > See
> > > https://git.dpdk.org/dpdk-stable/commit/?h=21.11&id=adeaf361f0a5bb3992756fd4e727dd11ecca0943
> >
> > Thanks, any more errors with
> > https://github.com/bluca/dpdk-stable/commit/b75ebf643de0204d0092a56fbec63f0bcd10e89f
>
> With those two backports, it works for me.
>
> b75ebf643d - (HEAD -> 20.11, bluca/20.11) vhost: fix doxygen warnings
> (6 minutes ago) 
> 77f65b61f9 - lib: remove empty return types from doxygen comments (23
> minutes ago) 
> a75247cbdc - (stable/20.11) crypto/snow3g: fix snow3g enqueue stat
> increment (24 hours ago) 

Alright, ship it

Re: [PATCH v4] app/testpmd: txonly multiflow port change support

2023-04-19 Thread Stephen Hemminger

On Wed, 19 Apr 2023 17:51:18 +0530
"Singh, Aman Deep"  wrote:

> On 4/12/2023 11:46 PM, Joshua Washington wrote:
> > Google cloud routes traffic using IP addresses without the support of MAC
> > addresses, so changing source IP address for txonly-multi-flow can have
> > negative performance implications for net/gve when using testpmd. This
> > patch updates txonly multiflow mode to modify source ports instead of
> > source IP addresses.  
> 
> Generally routing is based on DST IP addresses, was SRC IP also having an
> impact in your case ?

Most hypervisor infrastructures will not allow a guest to use a source
address that has not been allocated to that guest. Therefore when using
multiple source addresses, either the guest has to be configured to have
all the addresses it will use, or the test needs to only use one source address.

Re: [PATCH v2] kni: fix build with Linux 6.3

2023-04-19 Thread David Marchand

> On Fri, Apr 14, 2023 at 5:25 PM Ferruh Yigit  wrote:
> >
> > KNI calls `get_user_pages_remote()` API which is using `FOLL_TOUCH`
> > flag, but `FOLL_TOUCH` is no more in public headers since v6.3,
> > causing a build error.
> >
> > `FOLL_*` defines in Linux kernel first moved to another header [1],
> > later some of them moved to memory subsystem internal header [2] for 6.3
> >
> > `get_user_pages_remote()` already sets `FOLL_TOUCH` internally,
> > no need to set this flag externally anyway, moving flag from the call
> > altogether.
> >
> > [1]
> > Commit b5054174ac7c ("mm: move FOLL_* defs to mm_types.h")
> >
> > [2]
> > Commit 2c2241081f7d ("mm/gup: move private gup FOLL_ flags to internal.h")
> >
> > Signed-off-by: Ferruh Yigit 
>
> Reviewed-by: David Marchand 

Applied, thanks Ferruh.


-- 
David Marchand

Re: [RFC] lib: set/get max memzone segments

2023-04-19 Thread Stephen Hemminger

On Wed, 19 Apr 2023 11:36:34 +0300
Ophir Munk  wrote:

> +int ecore_mz_mapping_alloc(void)
> +{
> + ecore_mz_mapping = rte_malloc("ecore_mz_map", 0,
> + rte_memzone_max_get() * sizeof(struct rte_memzone *));

Why not use rte_calloc(), and devices should be using NUMA aware
allocation to put the memzone on same NUMA node as the PCI device.

Re: [PATCH v5 3/3] net/ixgbe: implement recycle buffer mode

2023-04-19 Thread Ferruh Yigit

On 3/30/2023 7:29 AM, Feifei Wang wrote:
> Define specific function implementation for ixgbe driver.
> Currently, recycle buffer mode can support 128bit
> vector path. And can be enabled both in fast free and
> no fast free mode.
> 
> Suggested-by: Honnappa Nagarahalli 
> Signed-off-by: Feifei Wang 
> Reviewed-by: Ruifeng Wang 
> Reviewed-by: Honnappa Nagarahalli 
> ---
>  drivers/net/ixgbe/ixgbe_ethdev.c |   1 +
>  drivers/net/ixgbe/ixgbe_ethdev.h |   3 +
>  drivers/net/ixgbe/ixgbe_rxtx.c   | 153 +++
>  drivers/net/ixgbe/ixgbe_rxtx.h   |   4 +
>  4 files changed, 161 insertions(+)
> 

What do you think to extract buf_recycle related code in drivers into
its own file, this may help to manager maintainership of code easier?

<...>

> +uint16_t
> +ixgbe_tx_buf_stash_vec(void *tx_queue,
> + struct rte_eth_rxq_buf_recycle_info *rxq_buf_recycle_info)
> +{
> + struct ixgbe_tx_queue *txq = tx_queue;
> + struct ixgbe_tx_entry *txep;
> + struct rte_mbuf **rxep;
> + struct rte_mbuf *m[RTE_IXGBE_TX_MAX_FREE_BUF_SZ];
> + int i, j, n;
> + uint32_t status;
> + uint16_t avail = 0;
> + uint16_t buf_ring_size = rxq_buf_recycle_info->buf_ring_size;
> + uint16_t mask = rxq_buf_recycle_info->buf_ring_size - 1;
> + uint16_t refill_request = rxq_buf_recycle_info->refill_request;
> + uint16_t refill_head = *rxq_buf_recycle_info->refill_head;
> + uint16_t receive_tail = *rxq_buf_recycle_info->receive_tail;
> +
> + /* Get available recycling Rx buffers. */
> + avail = (buf_ring_size - (refill_head - receive_tail)) & mask;
> +
> + /* Check Tx free thresh and Rx available space. */
> + if (txq->nb_tx_free > txq->tx_free_thresh || avail <= txq->tx_rs_thresh)
> + return 0;
> +
> + /* check DD bits on threshold descriptor */
> + status = txq->tx_ring[txq->tx_next_dd].wb.status;
> + if (!(status & IXGBE_ADVTXD_STAT_DD))
> + return 0;
> +
> + n = txq->tx_rs_thresh;
> +
> + /* Buffer recycle can only support no ring buffer wraparound.
> +  * Two case for this:
> +  *
> +  * case 1: The refill head of Rx buffer ring needs to be aligned with
> +  * buffer ring size. In this case, the number of Tx freeing buffers
> +  * should be equal to refill_request.
> +  *
> +  * case 2: The refill head of Rx ring buffer does not need to be aligned
> +  * with buffer ring size. In this case, the update of refill head can 
> not
> +  * exceed the Rx buffer ring size.
> +  */
> + if (refill_request != n ||
> + (!refill_request && (refill_head + n > buf_ring_size)))
> + return 0;
> +
> + /* First buffer to free from S/W ring is at index
> +  * tx_next_dd - (tx_rs_thresh-1).
> +  */
> + txep = &txq->sw_ring[txq->tx_next_dd - (n - 1)];
> + rxep = rxq_buf_recycle_info->buf_ring;
> + rxep += refill_head;
> +
> + if (txq->offloads & RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE) {
> + /* Directly put mbufs from Tx to Rx. */
> + for (i = 0; i < n; i++, rxep++, txep++)
> + *rxep = txep[0].mbuf;
> + } else {
> + for (i = 0, j = 0; i < n; i++) {
> + /* Avoid txq contains buffers from expected mempoo. */

mempool (unless trying to introduce a new concept :)

Re: [PATCH v5 1/3] ethdev: add API for buffer recycle mode

2023-04-19 Thread Ferruh Yigit

On 3/30/2023 7:29 AM, Feifei Wang wrote:
> There are 4 upper APIs for buffer recycle mode:
> 1. 'rte_eth_rx_queue_buf_recycle_info_get'
> This is to retrieve buffer ring information about given ports's Rx
> queue in buffer recycle mode. And due to this, buffer recycle can
> be no longer limited to the same driver in Rx and Tx.
> 
> 2. 'rte_eth_dev_buf_recycle'
> Users can call this API to enable buffer recycle mode in data path.
> There are 2 internal APIs in it, which is separately for Rx and TX.
> 

Overall, can we have a namespace in the functions related to the buffer
recycle, to clarify API usage, something like (just putting as sample to
clarify my point):

rte_eth_recycle_buf
rte_eth_recycle_tx_buf_stash
rte_eth_recycle_rx_descriptors_refill
rte_eth_recycle_rx_queue_info_get


> 3. 'rte_eth_tx_buf_stash'
> Internal API for buffer recycle mode. This is to stash Tx used
> buffers into Rx buffer ring.
> 

This API is to move/recycle descriptors from Tx queue to Rx queue, but
name on its own, 'rte_eth_tx_buf_stash', reads like we are stashing
something to Tx queue. What do you think, can naming be improved?

> 4. 'rte_eth_rx_descriptors_refill'
> Internal API for buffer recycle mode. This is to refill Rx
> descriptors.
> 
> Above all APIs are just implemented at the upper level.
> For different APIs, we need to define specific functions separately.
> 
> Suggested-by: Honnappa Nagarahalli 
> Suggested-by: Ruifeng Wang 
> Signed-off-by: Feifei Wang 
> Reviewed-by: Ruifeng Wang 
> Reviewed-by: Honnappa Nagarahalli 

<...>

>  
> +int
> +rte_eth_rx_queue_buf_recycle_info_get(uint16_t port_id, uint16_t queue_id,
> + struct rte_eth_rxq_buf_recycle_info *rxq_buf_recycle_info)
> +{
> + struct rte_eth_dev *dev;
> +
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> + dev = &rte_eth_devices[port_id];
> +
> + if (queue_id >= dev->data->nb_rx_queues) {
> + RTE_ETHDEV_LOG(ERR, "Invalid Rx queue_id=%u\n", queue_id);
> + return -EINVAL;
> + }
> +
> + RTE_ASSERT(rxq_buf_recycle_info != NULL);
> +

This is slow path API, I think better to validate parameter and return
an error instead of assert().

<...>

> --- a/lib/ethdev/rte_ethdev_core.h
> +++ b/lib/ethdev/rte_ethdev_core.h
> @@ -56,6 +56,13 @@ typedef int (*eth_rx_descriptor_status_t)(void *rxq, 
> uint16_t offset);
>  /** @internal Check the status of a Tx descriptor */
>  typedef int (*eth_tx_descriptor_status_t)(void *txq, uint16_t offset);
>  
> +/** @internal Stash Tx used buffers into RX ring in buffer recycle mode */
> +typedef uint16_t (*eth_tx_buf_stash_t)(void *txq,
> + struct rte_eth_rxq_buf_recycle_info *rxq_buf_recycle_info);
> +
> +/** @internal Refill Rx descriptors in buffer recycle mode */
> +typedef uint16_t (*eth_rx_descriptors_refill_t)(void *rxq, uint16_t nb);
> +

Since there is only single API exposed to the application, is it really
required to have two dev_ops, why not have a single one?

Re: [RFC] lib: set/get max memzone segments

2023-04-19 Thread Tyler Retzlaff

On Wed, Apr 19, 2023 at 11:36:34AM +0300, 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 the max value via an rte API -
> rather than changing the dpdk source code per application.  In many
> organizations, the possibility to compile a private DPDK library for a
> particular application does not exist at all.  With this option there is
> no need to recompile DPDK and it allows using an in-box packaged DPDK.
> An example usage for updating the RTE_MAX_MEMZONE 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 is not about how to optimize the application usage of
> mempool nor about how to improve the mempool implementation based on
> memzone.  It is about how to make the max memzone definition - run-time
> customized.
> This commit adds an API which must be called before rte_eal_init():
> rte_memzone_max_set(int max).  If not called, the default memzone
> (RTE_MAX_MEMZONE) is used.  There is also an API to query the effective
> max memzone: rte_memzone_max_get().
> 
> Signed-off-by: Ophir Munk 
> ---

the use case of each application may want a different non-hard coded
value makes sense.

it's less clear to me that requiring it be called before eal init makes
sense over just providing it as configuration to eal init so that it is
composed.

can you elaborate further on why you need get if you have a one-shot
set? why would the application not know the value if you can only ever
call it once before init?

>  app/test/test_func_reentrancy.c |  2 +-
>  app/test/test_malloc_perf.c |  2 +-
>  app/test/test_memzone.c |  2 +-
>  config/rte_config.h |  1 -
>  drivers/net/qede/base/bcm_osal.c| 26 +-
>  drivers/net/qede/base/bcm_osal.h|  3 +++
>  drivers/net/qede/qede_main.c|  7 +++
>  lib/eal/common/eal_common_memzone.c | 28 +---
>  lib/eal/include/rte_memzone.h   | 20 
>  lib/eal/version.map |  4 
>  10 files changed, 83 insertions(+), 12 deletions(-)
> 
> diff --git a/app/test/test_func_reentrancy.c b/app/test/test_func_reentrancy.c
> index d1ed5d4..ae9de6f 100644
> --- a/app/test/test_func_reentrancy.c
> +++ b/app/test/test_func_reentrancy.c
> @@ -51,7 +51,7 @@ typedef void (*case_clean_t)(unsigned lcore_id);
>  #define MEMPOOL_ELT_SIZE(sizeof(uint32_t))
>  #define MEMPOOL_SIZE(4)
>  
> -#define MAX_LCORES   (RTE_MAX_MEMZONE / (MAX_ITER_MULTI * 4U))
> +#define MAX_LCORES   (rte_memzone_max_get() / (MAX_ITER_MULTI * 4U))
>  
>  static uint32_t obj_count;
>  static uint32_t synchro;
> diff --git a/app/test/test_malloc_perf.c b/app/test/test_malloc_perf.c
> index ccec43a..9bd1662 100644
> --- a/app/test/test_malloc_perf.c
> +++ b/app/test/test_malloc_perf.c
> @@ -165,7 +165,7 @@ test_malloc_perf(void)
>   return -1;
>  
>   if (test_alloc_perf("rte_memzone_reserve", memzone_alloc, memzone_free,
> - NULL, memset_us_gb, RTE_MAX_MEMZONE - 1) < 0)
> + NULL, memset_us_gb, rte_memzone_max_get() - 1) < 0)
>   return -1;
>  
>   return 0;
> diff --git a/app/test/test_memzone.c b/app/test/test_memzone.c
> index c9255e5..a315826 100644
> --- a/app/test/test_memzone.c
> +++ b/app/test/test_memzone.c
> @@ -871,7 +871,7 @@ test_memzone_bounded(void)
>  static int
>  test_memzone_free(void)
>  {
> - const struct rte_memzone *mz[RTE_MAX_MEMZONE + 1];
> + const struct rte_memzone *mz[rte_memzone_max_get() + 1];

please no more VLAs even if in tests.

>   int i;
>   char name[20];
>  
> diff --git a/config/rte_config.h b/config/rte_config.h
> index 7b8c85e..400e44e 100644
> --- a/config/rte_config.h
> +++ b/config/rte_config.h
> @@ -34,7 +34,6 @@
>  #define RTE_MAX_MEM_MB_PER_LIST 32768
>  #define RTE_MAX_MEMSEG_PER_TYPE 32768
>  #define RTE_MAX_MEM_MB_PER_TYPE 65536
> -#define RTE_MAX_MEMZONE 2560
>  #define RTE_MAX_TAILQ 32
>  #define RTE_LOG_DP_LEVEL RTE_LOG_INFO
>  #define RTE_MAX_VFIO_CONTAINERS 64
> diff --git a/drivers/net/qede/base/bcm_osal.c 
> b/drivers/net/qede/base/bcm_osal.c
> index 2c59397..f195f2c 100644
> --- a/drivers/net/qede/base/bcm_osal.c
> +++ b/drivers/net/qede/base/bcm_osal.c
> @@ -47,10 +47,26 @@ void osal_poll_mode_dpc(osal_int_ptr_t hwfn_cookie)
>  }
>  
>  /* Array of memzone pointers */
> -static const struct rte_memzone *ecore_mz_mapping[RTE_MAX_MEMZONE];
> +static const struct rte_memzone **ecore_mz_mapping;
>  /* Counter to track current memzone allocated */
>  static uint16_t ecore_mz_count;
>  
> +int ecore_mz_mapping_alloc(void)
> +{
> + ecore_mz_mapping = rte_malloc("ecore_

Re: [RFC 05/27] vhost: add helper for IOTLB entries shared page check

2023-04-19 Thread Mike Pattrick

On Wed, Apr 19, 2023 at 5:35 AM Maxime Coquelin
 wrote:
>
> Hi Mike,
>
> On 4/17/23 21:39, Mike Pattrick wrote:
> > Hi Maxime,
> >
> > On Fri, Mar 31, 2023 at 11:43 AM Maxime Coquelin
> >  wrote:
> >>
> >> This patch introduces a helper to check whether two IOTLB
> >> entries share a page.
> >>
> >> Signed-off-by: Maxime Coquelin 
> >> ---
> >>   lib/vhost/iotlb.c | 25 -
> >>   1 file changed, 20 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/lib/vhost/iotlb.c b/lib/vhost/iotlb.c
> >> index e8f1cb661e..d919f74704 100644
> >> --- a/lib/vhost/iotlb.c
> >> +++ b/lib/vhost/iotlb.c
> >> @@ -23,6 +23,23 @@ struct vhost_iotlb_entry {
> >>
> >>   #define IOTLB_CACHE_SIZE 2048
> >>
> >> +static bool
> >> +vhost_user_iotlb_share_page(struct vhost_iotlb_entry *a, struct 
> >> vhost_iotlb_entry *b,
> >> +   uint64_t align)
> >> +{
> >> +   uint64_t a_end, b_start;
> >> +
> >> +   if (a == NULL || b == NULL)
> >> +   return false;
> >> +
> >> +   /* Assumes entry a lower than entry b */
> >> +   RTE_ASSERT(a->uaddr < b->uaddr);
> >> +   a_end = RTE_ALIGN_CEIL(a->uaddr + a->size, align);
> >> +   b_start = RTE_ALIGN_FLOOR(b->uaddr, align);
> >> +
> >> +   return a_end > b_start;
> >
> > This may be a very minor detail, but it might improve readability if
> > the a_end calculation used addr + size - 1 and the return conditional
> > used >=.
>
> That's actually how I initially implemented it, but discussing with
> David we agreed it would be better that way for consistency with
> vhost_user_iotlb_clear_dump().

I can get behind consistency.

Acked-by: Mike Pattrick 

>
> Regards,
> Maxime
>
> >
> > Cheers,
> > M
> >
> >
> >> +}
> >> +
> >>   static void
> >>   vhost_user_iotlb_set_dump(struct virtio_net *dev, struct 
> >> vhost_iotlb_entry *node)
> >>   {
> >> @@ -37,16 +54,14 @@ static void
> >>   vhost_user_iotlb_clear_dump(struct virtio_net *dev, struct 
> >> vhost_iotlb_entry *node,
> >>  struct vhost_iotlb_entry *prev, struct vhost_iotlb_entry 
> >> *next)
> >>   {
> >> -   uint64_t align, mask;
> >> +   uint64_t align;
> >>
> >>  align = hua_to_alignment(dev->mem, (void 
> >> *)(uintptr_t)node->uaddr);
> >> -   mask = ~(align - 1);
> >>
> >>  /* Don't disable coredump if the previous node is in the same 
> >> page */
> >> -   if (prev == NULL || (node->uaddr & mask) != ((prev->uaddr + 
> >> prev->size - 1) & mask)) {
> >> +   if (!vhost_user_iotlb_share_page(prev, node, align)) {
> >>  /* Don't disable coredump if the next node is in the same 
> >> page */
> >> -   if (next == NULL ||
> >> -   ((node->uaddr + node->size - 1) & mask) != 
> >> (next->uaddr & mask))
> >> +   if (!vhost_user_iotlb_share_page(node, next, align))
> >>  mem_set_dump((void *)(uintptr_t)node->uaddr, 
> >> node->size, false, align);
> >>  }
> >>   }
> >> --
> >> 2.39.2
> >>
> >
>

Re: [PATCH v5 0/3] Recycle buffers from Tx to Rx

2023-04-19 Thread Ferruh Yigit

On 3/30/2023 7:29 AM, Feifei Wang wrote:
> Currently, the transmit side frees the buffers into the lcore cache and
> the receive side allocates buffers from the lcore cache. The transmit
> side typically frees 32 buffers resulting in 32*8=256B of stores to
> lcore cache. The receive side allocates 32 buffers and stores them in
> the receive side software ring, resulting in 32*8=256B of stores and
> 256B of load from the lcore cache.
> 
> This patch proposes a mechanism to avoid freeing to/allocating from
> the lcore cache. i.e. the receive side will free the buffers from
> transmit side directly into its software ring. This will avoid the 256B
> of loads and stores introduced by the lcore cache. It also frees up the
> cache lines used by the lcore cache. And we can call this mode as buffer
> recycle mode.
> 
> In the latest version, buffer recycle mode is packaged as a separate API. 
> This allows for the users to change rxq/txq pairing in real time in data 
> plane,
> according to the analysis of the packet flow by the application, for example:
> ---
> Step 1: upper application analyse the flow direction
> Step 2: rxq_buf_recycle_info = rte_eth_rx_buf_recycle_info_get(rx_portid, 
> rx_queueid)
> Step 3: rte_eth_dev_buf_recycle(rx_portid, rx_queueid, tx_portid, tx_queueid, 
> rxq_buf_recycle_info);
> Step 4: rte_eth_rx_burst(rx_portid,rx_queueid);
> Step 5: rte_eth_tx_burst(tx_portid,tx_queueid);
> ---
> Above can support user to change rxq/txq pairing  at runtime and user does 
> not need to
> know the direction of flow in advance. This can effectively expand buffer 
> recycle mode's
> use scenarios.
> 
> Furthermore, buffer recycle mode is no longer limited to the same pmd,
> it can support moving buffers between different vendor pmds, even can put the 
> buffer
> anywhere into your Rx buffer ring as long as the address of the buffer ring 
> can be provided.
> In the latest version, we enable direct-rearm in i40e pmd and ixgbe pmd, and 
> also try to
> use i40e driver in Rx, ixgbe driver in Tx, and then achieve 7-9% performance 
> improvement
> by buffer recycle mode.
> 
> Difference between buffer recycle, ZC API used in mempool and general path
> For general path: 
> Rx: 32 pkts memcpy from mempool cache to rx_sw_ring
> Tx: 32 pkts memcpy from tx_sw_ring to temporary variable + 32 
> pkts memcpy from temporary variable to mempool cache
> For ZC API used in mempool:
> Rx: 32 pkts memcpy from mempool cache to rx_sw_ring
> Tx: 32 pkts memcpy from tx_sw_ring to zero-copy mempool cache
> Refer link: 
> http://patches.dpdk.org/project/dpdk/patch/20230221055205.22984-2-kamalakshitha.alig...@arm.com/
> For buffer recycle:
> Rx/Tx: 32 pkts memcpy from tx_sw_ring to rx_sw_ring
> Thus we can see in the one loop, compared to general path, buffer recycle 
> reduce 32+32=64 pkts memcpy;
> Compared to ZC API used in mempool, we can see buffer recycle reduce 32 pkts 
> memcpy in each loop.
> So, buffer recycle has its own benefits.
> 
> Testing status:
> (1) dpdk l3fwd test with multiple drivers:
> port 0: 82599 NIC   port 1: XL710 NIC
> -
>   Without fast free   With fast free
> Thunderx2:  +7.53%+13.54%
> -
> 
> (2) dpdk l3fwd test with same driver:
> port 0 && 1: XL710 NIC
> -
>   Without fast free   With fast free
> Ampere altra:   +12.61%   +11.42%
> n1sdp:+8.30%  +3.85%
> x86-sse:  +8.43%  +3.72%
> -
> 
> (3) Performance comparison with ZC_mempool used
> port 0 && 1: XL710 NIC
> with fast free
> -
>   With recycle buffer With zc_mempool
> Ampere altra: 11.42%  3.54%
> -
> 

Thanks for the perf test reports.

Since test is done on Intel NICs, it would be great to get some testing
and performance numbers from Intel side too, if possible.

> V2:
> 1. Use data-plane API to enable direct-rearm (Konstantin, Honnappa)
> 2. Add 'txq_data_get' API to get txq info for Rx (Konstantin)
> 3. Use input parameter to enable direct rearm in l3fwd (Konstantin)
> 4. Add condition detection for direct rearm API (Morten, Andrew Rybchenko)
> 
> V3:
> 1. Seperate Rx and Tx operation with two APIs in direct-rearm (Konstantin)
> 2. Delete L3fwd change for direct rearm (Jerin)
> 3. enable direct rearm in ixgbe driver in Arm
> 
> v4:
> 1. Rename direct-rearm as buffer recycle. Base

[PATCH] devtools: add script to check for non inclusive naming

2023-04-19 Thread Stephen Hemminger

Script to find words that should not be used.
Really just a wrapper around git grep command.
By default it prints matches.

Uses the word lists from Inclusive Naming Initiative
see https://inclusivenaming.org/word-lists/

Examples:
$ ./devtools/check-naming-policy.sh -c
app/test-compress-perf/comp_perf_test_cyclecount.c:1
uapp/test-compress-perf/comp_perf_test_throughput.c:1
app/test-compress-perf/comp_perf_test_verify.c:1
app/test/test_common.c:1
...

$ ./devtools/check-naming-policy.py lib/pcapng
lib/pcapng/rte_pcapng.c:/* sanity check that is really a pcapng 
mbuf */

$ ./devtools/check-naming-policy.py -l lib/eal
lib/eal/common/eal_common_memory.c
lib/eal/common/eal_common_proc.c
lib/eal/common/eal_common_trace.c
lib/eal/common/eal_memcfg.h
lib/eal/common/rte_malloc.c
lib/eal/freebsd/eal.c
lib/eal/include/generic/rte_power_intrinsics.h
lib/eal/include/generic/rte_rwlock.h
lib/eal/include/generic/rte_spinlock.h
lib/eal/include/rte_debug.h
lib/eal/include/rte_seqlock.h
lib/eal/linux/eal.c
lib/eal/windows/eal.c
lib/eal/x86/include/rte_rtm.h
lib/eal/x86/include/rte_spinlock.h
lib/eal/x86/rte_power_intrinsics.c

$ ./devtools/check-inclusive-naming -h
usage: check-inclusive-naming.py [-h] [-c] [-d] [-l] [-t {0,1,2,3}]
 [-x EXCLUDE] [--url URL]
 [paths ...]

Identify word usage not aligned with inclusive naming

positional arguments:
  paths files and directory to scan

options:
  -h, --helpshow this help message and exit
  -c, --count   Show the nuber of lines that match
  -d, --debug   Debug this script
  -l, --files-with-matches
Show only names of files with hits
  -t {0,1,2,3}, --tier {0,1,2,3}
Show non-conforming words of particular tier
  -x EXCLUDE, --exclude EXCLUDE
Exclude path from scan
  --url URL URL for the non-inclusive naming word list

Signed-off-by: Stephen Hemminger 
---
v4 - fix python lint warnings and spelling

 MAINTAINERS|   1 +
 devtools/check-inclusive-naming.py | 137 +
 2 files changed, 138 insertions(+)
 create mode 100755 devtools/check-inclusive-naming.py

diff --git a/MAINTAINERS b/MAINTAINERS
index 8df23e50999f..141d70596020 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -89,6 +89,7 @@ F: devtools/check-doc-vs-code.sh
 F: devtools/check-dup-includes.sh
 F: devtools/check-maintainers.sh
 F: devtools/check-forbidden-tokens.awk
+F: devtools/check-inclusive-naming.py
 F: devtools/check-git-log.sh
 F: devtools/check-spdx-tag.sh
 F: devtools/check-symbol-change.sh
diff --git a/devtools/check-inclusive-naming.py 
b/devtools/check-inclusive-naming.py
new file mode 100755
index ..916d49aa2ecf
--- /dev/null
+++ b/devtools/check-inclusive-naming.py
@@ -0,0 +1,137 @@
+#!/usr/bin/env python3
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright 2023 Stephen Hemminger
+#
+# This script scans the source tree and creates list of files
+# containing words that are recommended to avoided by the
+# Inclusive Naming Initiative.
+# See: https://inclusivenaming.org/word-lists/
+
+"""Script to run git grep to finds strings in inclusive naming word list."""
+
+import argparse
+import json
+import subprocess
+import sys
+from urllib.request import urlopen
+
+WORDLIST_URL = 'https://inclusivenaming.org/word-lists/index.json'
+
+# These give false positives
+dont_scan = [
+'doc/guides/rel_notes/',
+'doc/guides/contributing/coding_style.rst'
+'doc/guides/prog_guide/glossary.rst'
+]
+
+
+def args_parse():
+"parse arguments and return the argument object back to main"
+
+parser = argparse.ArgumentParser(
+description="Identify word usage not aligned with inclusive naming")
+parser.add_argument("-c",
+"--count",
+help="Show the number of lines that match",
+action='store_true')
+parser.add_argument("-d",
+"--debug",
+default=False,
+help="Debug this script",
+action='store_true')
+parser.add_argument("-l",
+"--files-with-matches",
+help="Show only names of files with hits",
+action='store_true')
+parser.add_argument("-n",
+"--line-number",
+help="Prefix with line number to matching lines",
+action='store_true')
+# note: tier 0 is "OK to use"
+parser.add_argument("-t",
+"--tier",
+type=int,
+choices=range(0, 4),
+action='append',
+help="Show non-conforming words of particular tier")
+parser.add_argument('-x',
+"--exclude",
+

Re: [dpdk-web] [RFC PATCH] process: new library approval in principle

2023-04-19 Thread Kevin Traynor


On 13/02/2023 09:26, jer...@marvell.com wrote:

From: Jerin Jacob 

Based on TB meeting[1] action item, defining
the process for new library approval in principle.

[1]
https://mails.dpdk.org/archives/dev/2023-January/260035.html

Signed-off-by: Jerin Jacob 
---
  content/process/_index.md | 33 +
  1 file changed, 33 insertions(+)
  create mode 100644 content/process/_index.md

diff --git a/content/process/_index.md b/content/process/_index.md
new file mode 100644
index 000..21c2642
--- /dev/null
+++ b/content/process/_index.md
@@ -0,0 +1,33 @@

+title = "Process"
+weight = "9"

+
+## Process for new library approval in principle
+
+### Rational
+
+Adding a new library to DPDK codebase with proper RFC and then full patch-sets 
is
+significant work and getting early approval-in-principle that a library help 
DPDK contributors
+avoid wasted effort if it is not suitable for various reasons.
+
+### Process
+
+1. When a contributor would like to add a new library to DPDK code base, the 
contributor must send
+the following items to DPDK mailing list for TB approval-in-principle.
+
+   - Purpose of the library.
+   - Scope of the library.
+   - Any licensing constraints.
+   - Justification for adding to DPDK.
+   - Any other implementations of the same functionality in other 
libs/products and how this version differs.


- Dependencies

(Need to know if it's introducing new dependencies to the project)


+   - Public API specification header file as RFC
+   - Optional and good to have.
+   - TB may additionally request this collateral if needed to get more 
clarity on scope and purpose.
+
+2. TB to schedule discussion on this in upcoming TB meeting along with author. 
Based on the TB
+schedule and/or author availability, TB may need maximum three TB meeting 
slots.
+
+3. Based on mailing list and TB meeting discussions, TB to vote for 
approval-in-principle and share
+the decision in the mailing list.
+


How about having three outcomes:
- Approval in principal
- Not approved
- Further information needed

RE: [EXT] [PATCH 1/2] lib/cryptodev/: Add SM3_HMAC/SM4_CFB/SM4_OFB support in DPDK

2023-04-19 Thread Kusztal, ArkadiuszX



> -Original Message-
> From: Sunyang Wu 
> Sent: Saturday, March 18, 2023 2:00 PM
> To: Akhil Goyal ; dev@dpdk.org
> Cc: Ji, Kai 
> Subject: 回复: [EXT] [PATCH 1/2] lib/cryptodev/: Add
> SM3_HMAC/SM4_CFB/SM4_OFB support in DPDK
> 
> Hi all:
> SM3 and SM4 are widely used in China, and they are Chinese national standards.
> I'm very to tell you that I didn't find the relevant RFC documents for SM3 and
> SM4, but I found the national standards for SM3 and SM4 in the full text
> disclosure system of Chinese national standards, but they are all in Chinese. 
> The
> links are shown below:
> SM3:
> http://c.gb688.cn/bzgk/gb/showGb?type=online&hcno=45B1A67F20F3BF33921
> 1C391E9278F5E
> SM4:
> http://c.gb688.cn/bzgk/gb/showGb?type=online&hcno=7803DE42D3BC5E80B0
> C3E5D8E873D56A
> If these modes(SM3_HMAC / SM4_OFB / SM4_CFB) are not necessary, I can
> resubmit a patch, delete the corresponding test cases for these modes, and
> retain only the test cases for the mods currently supported by DPdK.
> 
> -邮件原件-
> 发件人: Akhil Goyal 
> 发送时间: 2023年3月16日 18:43
> 收件人: Sunyang Wu ; dev@dpdk.org
> 抄送: kai...@intel.com
> 主题: RE: [EXT] [PATCH 1/2] lib/cryptodev/: Add
> SM3_HMAC/SM4_CFB/SM4_OFB support in DPDK
> 
> > Add SM3_HMAC/SM4_CFB/SM4_OFB support in DPDK.
> >
> 
> Can you give reference to some documentation for each of these modes.
> Cannot find RFCs for SM3_HMAC etc.

HMAC is supposed to work with any iterated hash function. Since we already have 
SM3 in the API, I would not worry about lack of RFC for specific SM3 + HMAC 
combination.

> 
> > Signed-off-by: Sunyang Wu 
> > ---
> >  lib/cryptodev/rte_crypto_sym.h | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)

[PATCH 1/2] crypto/qat: add hash mode 2

2023-04-19 Thread Arek Kusztal

This commit adds hash mode 2 to the Intel
QuickAssist Technology symmetric crypto PMD.

Signed-off-by: Arek Kusztal 
---
 drivers/common/qat/qat_adf/icp_qat_fw_la.h | 10 ++
 drivers/crypto/qat/qat_sym_session.h   |  2 ++
 2 files changed, 12 insertions(+)

diff --git a/drivers/common/qat/qat_adf/icp_qat_fw_la.h 
b/drivers/common/qat/qat_adf/icp_qat_fw_la.h
index c4901eb869..fe57d8e488 100644
--- a/drivers/common/qat/qat_adf/icp_qat_fw_la.h
+++ b/drivers/common/qat/qat_adf/icp_qat_fw_la.h
@@ -80,6 +80,10 @@ struct icp_qat_fw_la_bulk_req {
 #define ICP_QAT_FW_LA_PARTIAL_END 2
 #define QAT_LA_PARTIAL_BITPOS 0
 #define QAT_LA_PARTIAL_MASK 0x3
+#define QAT_FW_LA_MODE2_BITPOS 5
+#define QAT_FW_LA_MODE2 1
+#define QAT_FW_LA_NO_MODE2 0
+#define QAT_FW_LA_MODE2_MASK 0x1
 #define ICP_QAT_FW_LA_FLAGS_BUILD(zuc_proto, gcm_iv_len, auth_rslt, proto, \
cmp_auth, ret_auth, update_state, \
ciph_iv, ciphcfg, partial) \
@@ -187,6 +191,12 @@ struct icp_qat_fw_la_bulk_req {
QAT_FIELD_SET(flags, val, QAT_LA_PARTIAL_BITPOS, \
QAT_LA_PARTIAL_MASK)
 
+#define ICP_QAT_FW_HASH_FLAG_MODE2_SET(flags, val) \
+   QAT_FIELD_SET(flags, \
+   val, \
+   QAT_FW_LA_MODE2_BITPOS, \
+   QAT_FW_LA_MODE2_MASK)
+
 struct icp_qat_fw_cipher_req_hdr_cd_pars {
union {
struct {
diff --git a/drivers/crypto/qat/qat_sym_session.h 
b/drivers/crypto/qat/qat_sym_session.h
index 6322d7e3bc..d487bca11f 100644
--- a/drivers/crypto/qat/qat_sym_session.h
+++ b/drivers/crypto/qat/qat_sym_session.h
@@ -47,6 +47,7 @@
ICP_QAT_HW_CIPHER_DECRYPT)
 
 #define QAT_AES_CMAC_CONST_RB 0x87
+#define QAT_PREFIX_TABLE_SZ128
 
 #define QAT_CRYPTO_SLICE_SPC   1
 #define QAT_CRYPTO_SLICE_UCS   2
@@ -77,6 +78,7 @@ typedef int (*qat_sym_build_request_t)(void *in_op, struct 
qat_sym_session *ctx,
 struct qat_sym_cd {
struct icp_qat_hw_cipher_algo_blk cipher;
struct icp_qat_hw_auth_algo_blk hash;
+   uint8_t prefix_state[QAT_PREFIX_TABLE_SZ] __rte_cache_aligned;
 } __rte_packed __rte_cache_aligned;
 
 struct qat_sym_session {
-- 
2.25.1

[PATCH 2/2] crypto/qat: add sm3 hmac

2023-04-19 Thread Arek Kusztal

This commit adds SM3-HMAC algorithm to the Intel
QuickAssist Technology symmetric crypto PMD.

Signed-off-by: Arek Kusztal 
---
 drivers/crypto/qat/qat_sym_session.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/crypto/qat/qat_sym_session.c 
b/drivers/crypto/qat/qat_sym_session.c
index 6ad6c7ee3a..50b4a6391d 100644
--- a/drivers/crypto/qat/qat_sym_session.c
+++ b/drivers/crypto/qat/qat_sym_session.c
@@ -695,6 +695,9 @@ qat_sym_session_configure_auth(struct rte_cryptodev *dev,
session->digest_length = auth_xform->digest_length;
 
switch (auth_xform->algo) {
+   case RTE_CRYPTO_AUTH_SM3_HMAC:
+   session->qat_hash_alg = ICP_QAT_HW_AUTH_ALGO_SM3;
+   session->auth_mode = ICP_QAT_HW_AUTH_MODE2;
case RTE_CRYPTO_AUTH_SM3:
session->qat_hash_alg = ICP_QAT_HW_AUTH_ALGO_SM3;
session->auth_mode = ICP_QAT_HW_AUTH_MODE0;
-- 
2.25.1

[PATCH 1/3] event/cnxk: use LMTST for enqueue new burst

2023-04-19 Thread pbhagavatula

From: Pavan Nikhilesh 

Use LMTST when all events in the burst are enqueue with
rte_event:op as RTE_EVENT_OP_NEW i.e. events are enqueued
with the `rte_event_enqueue_new_burst` API.

Signed-off-by: Pavan Nikhilesh 
---
 drivers/common/cnxk/hw/sso.h|   1 +
 drivers/common/cnxk/roc_sso.c   |  10 +-
 drivers/common/cnxk/roc_sso.h   |   3 +
 drivers/event/cnxk/cn10k_eventdev.c |   9 +-
 drivers/event/cnxk/cn10k_eventdev.h |   6 +-
 drivers/event/cnxk/cn10k_worker.c   | 304 +++-
 drivers/event/cnxk/cn9k_eventdev.c  |   2 +-
 drivers/event/cnxk/cnxk_eventdev.c  |  15 +-
 drivers/event/cnxk/cnxk_eventdev.h  |   4 +-
 9 files changed, 338 insertions(+), 16 deletions(-)

diff --git a/drivers/common/cnxk/hw/sso.h b/drivers/common/cnxk/hw/sso.h
index 25deaa4c14..09b8d4955f 100644
--- a/drivers/common/cnxk/hw/sso.h
+++ b/drivers/common/cnxk/hw/sso.h
@@ -157,6 +157,7 @@
 #define SSO_LF_GGRP_AQ_CNT  (0x1c0ull)
 #define SSO_LF_GGRP_AQ_THR  (0x1e0ull)
 #define SSO_LF_GGRP_MISC_CNT(0x200ull)
+#define SSO_LF_GGRP_OP_AW_LMTST (0x400ull)
 
 #define SSO_AF_IAQ_FREE_CNT_MASK  0x3FFFull
 #define SSO_AF_IAQ_RSVD_FREE_MASK 0x3FFFull
diff --git a/drivers/common/cnxk/roc_sso.c b/drivers/common/cnxk/roc_sso.c
index 4a6a5080f7..78e98bbdd6 100644
--- a/drivers/common/cnxk/roc_sso.c
+++ b/drivers/common/cnxk/roc_sso.c
@@ -6,6 +6,7 @@
 #include "roc_priv.h"
 
 #define SSO_XAQ_CACHE_CNT (0x7)
+#define SSO_XAQ_SLACK(16)
 
 /* Private functions. */
 int
@@ -493,9 +494,13 @@ sso_hwgrp_init_xaq_aura(struct dev *dev, struct 
roc_sso_xaq_data *xaq,
 
xaq->nb_xae = nb_xae;
 
-   /* Taken from HRM 14.3.3(4) */
+   /** SSO will reserve upto 0x4 XAQ buffers per group when GetWork engine
+* is inactive and it might prefetch an additional 0x3 buffers due to
+* pipelining.
+*/
xaq->nb_xaq = (SSO_XAQ_CACHE_CNT * nb_hwgrp);
xaq->nb_xaq += PLT_MAX(1 + ((xaq->nb_xae - 1) / xae_waes), xaq->nb_xaq);
+   xaq->nb_xaq += SSO_XAQ_SLACK;
 
xaq->mem = plt_zmalloc(xaq_buf_size * xaq->nb_xaq, xaq_buf_size);
if (xaq->mem == NULL) {
@@ -537,7 +542,8 @@ sso_hwgrp_init_xaq_aura(struct dev *dev, struct 
roc_sso_xaq_data *xaq,
 * There should be a minimum headroom of 7 XAQs per HWGRP for SSO
 * to request XAQ to cache them even before enqueue is called.
 */
-   xaq->xaq_lmt = xaq->nb_xaq - (nb_hwgrp * SSO_XAQ_CACHE_CNT);
+   xaq->xaq_lmt =
+   xaq->nb_xaq - (nb_hwgrp * SSO_XAQ_CACHE_CNT) - SSO_XAQ_SLACK;
 
return 0;
 npa_fill_fail:
diff --git a/drivers/common/cnxk/roc_sso.h b/drivers/common/cnxk/roc_sso.h
index e67797b046..a2bb6fcb22 100644
--- a/drivers/common/cnxk/roc_sso.h
+++ b/drivers/common/cnxk/roc_sso.h
@@ -7,6 +7,9 @@
 
 #include "hw/ssow.h"
 
+#define ROC_SSO_AW_PER_LMT_LINE_LOG2 3
+#define ROC_SSO_XAE_PER_XAQ 352
+
 struct roc_sso_hwgrp_qos {
uint16_t hwgrp;
uint8_t xaq_prcnt;
diff --git a/drivers/event/cnxk/cn10k_eventdev.c 
b/drivers/event/cnxk/cn10k_eventdev.c
index 071ea5a212..855c92da83 100644
--- a/drivers/event/cnxk/cn10k_eventdev.c
+++ b/drivers/event/cnxk/cn10k_eventdev.c
@@ -91,8 +91,10 @@ cn10k_sso_hws_setup(void *arg, void *hws, uintptr_t grp_base)
uint64_t val;
 
ws->grp_base = grp_base;
-   ws->fc_mem = (uint64_t *)dev->fc_iova;
+   ws->fc_mem = (int64_t *)dev->fc_iova;
ws->xaq_lmt = dev->xaq_lmt;
+   ws->fc_cache_space = dev->fc_cache_space;
+   ws->aw_lmt = ws->lmt_base;
 
/* Set get_work timeout for HWS */
val = NSEC2USEC(dev->deq_tmo_ns);
@@ -624,6 +626,7 @@ cn10k_sso_info_get(struct rte_eventdev *event_dev,
 
dev_info->driver_name = RTE_STR(EVENTDEV_NAME_CN10K_PMD);
cnxk_sso_info_get(dev, dev_info);
+   dev_info->max_event_port_enqueue_depth = UINT32_MAX;
 }
 
 static int
@@ -632,7 +635,7 @@ cn10k_sso_dev_configure(const struct rte_eventdev 
*event_dev)
struct cnxk_sso_evdev *dev = cnxk_sso_pmd_priv(event_dev);
int rc;
 
-   rc = cnxk_sso_dev_validate(event_dev);
+   rc = cnxk_sso_dev_validate(event_dev, 1, UINT32_MAX);
if (rc < 0) {
plt_err("Invalid event device configuration");
return -EINVAL;
@@ -871,7 +874,7 @@ cn10k_sso_set_priv_mem(const struct rte_eventdev 
*event_dev, void *lookup_mem)
for (i = 0; i < dev->nb_event_ports; i++) {
struct cn10k_sso_hws *ws = event_dev->data->ports[i];
ws->xaq_lmt = dev->xaq_lmt;
-   ws->fc_mem = (uint64_t *)dev->fc_iova;
+   ws->fc_mem = (int64_t *)dev->fc_iova;
ws->tstamp = dev->tstamp;
if (lookup_mem)
ws->lookup_mem = lookup_mem;
diff --git a/drivers/event/cnxk/cn10k_eventdev.h 
b/drivers/event/cnxk/cn10k_eventdev.h
index aaa01d1ec1..29567728cd 100644
--- a/drivers/event/cnxk/cn10k_eventdev.h
+++ b/drivers/event/cnxk/cn10k_eve

[PATCH 2/3] app/eventdev: use enqueue new event burst routine

2023-04-19 Thread pbhagavatula

From: Pavan Nikhilesh 

Use the `rte_event_enqueue_new_burst` routine to enqueue events
with rte_event::op as RTE_EVENT_OP_NEW. This allows PMDs to use
optimized enqueue routines.

Signed-off-by: Pavan Nikhilesh 
---
 app/test-eventdev/evt_options.c  |  2 +-
 app/test-eventdev/test_perf_common.c | 58 +---
 2 files changed, 37 insertions(+), 23 deletions(-)

diff --git a/app/test-eventdev/evt_options.c b/app/test-eventdev/evt_options.c
index b175c067cd..03fb3bfce0 100644
--- a/app/test-eventdev/evt_options.c
+++ b/app/test-eventdev/evt_options.c
@@ -27,7 +27,7 @@ evt_options_default(struct evt_options *opt)
opt->nb_flows = 1024;
opt->socket_id = SOCKET_ID_ANY;
opt->pool_sz = 16 * 1024;
-   opt->prod_enq_burst_sz = 1;
+   opt->prod_enq_burst_sz = 0;
opt->wkr_deq_dep = 16;
opt->nb_pkts = (1ULL << 26); /* do ~64M packets */
opt->nb_timers = 1E8;
diff --git a/app/test-eventdev/test_perf_common.c 
b/app/test-eventdev/test_perf_common.c
index fd434666cb..68af3cb346 100644
--- a/app/test-eventdev/test_perf_common.c
+++ b/app/test-eventdev/test_perf_common.c
@@ -131,8 +131,10 @@ perf_producer(void *arg)
uint32_t flow_counter = 0;
uint64_t count = 0;
struct perf_elt *m[BURST_SIZE + 1] = {NULL};
+   uint8_t enable_fwd_latency;
struct rte_event ev;
 
+   enable_fwd_latency = opt->fwd_latency;
if (opt->verbose_level > 1)
printf("%s(): lcore %d dev_id %d port=%d queue %d\n", __func__,
rte_lcore_id(), dev_id, port, p->queue_id);
@@ -151,13 +153,16 @@ perf_producer(void *arg)
for (i = 0; i < BURST_SIZE; i++) {
ev.flow_id = flow_counter++ % nb_flows;
ev.event_ptr = m[i];
-   m[i]->timestamp = rte_get_timer_cycles();
-   while (rte_event_enqueue_burst(dev_id,
-  port, &ev, 1) != 1) {
+   if (enable_fwd_latency)
+   m[i]->timestamp = rte_get_timer_cycles();
+   while (rte_event_enqueue_new_burst(dev_id, port, &ev,
+  1) != 1) {
if (t->done)
break;
rte_pause();
-   m[i]->timestamp = rte_get_timer_cycles();
+   if (enable_fwd_latency)
+   m[i]->timestamp =
+   rte_get_timer_cycles();
}
}
count += BURST_SIZE;
@@ -171,7 +176,6 @@ perf_producer_burst(void *arg)
 {
uint32_t i;
uint64_t timestamp;
-   struct rte_event_dev_info dev_info;
struct prod_data *p  = arg;
struct test_perf *t = p->t;
struct evt_options *opt = t->opt;
@@ -183,15 +187,13 @@ perf_producer_burst(void *arg)
uint32_t flow_counter = 0;
uint16_t enq = 0;
uint64_t count = 0;
-   struct perf_elt *m[MAX_PROD_ENQ_BURST_SIZE + 1];
-   struct rte_event ev[MAX_PROD_ENQ_BURST_SIZE + 1];
+   struct perf_elt *m[opt->prod_enq_burst_sz + 1];
+   struct rte_event ev[opt->prod_enq_burst_sz + 1];
uint32_t burst_size = opt->prod_enq_burst_sz;
+   uint8_t enable_fwd_latency;
 
-   memset(m, 0, sizeof(*m) * (MAX_PROD_ENQ_BURST_SIZE + 1));
-   rte_event_dev_info_get(dev_id, &dev_info);
-   if (dev_info.max_event_port_enqueue_depth < burst_size)
-   burst_size = dev_info.max_event_port_enqueue_depth;
-
+   enable_fwd_latency = opt->fwd_latency;
+   memset(m, 0, sizeof(*m) * (opt->prod_enq_burst_sz + 1));
if (opt->verbose_level > 1)
printf("%s(): lcore %d dev_id %d port=%d queue %d\n", __func__,
rte_lcore_id(), dev_id, port, p->queue_id);
@@ -212,19 +214,21 @@ perf_producer_burst(void *arg)
for (i = 0; i < burst_size; i++) {
ev[i].flow_id = flow_counter++ % nb_flows;
ev[i].event_ptr = m[i];
-   m[i]->timestamp = timestamp;
+   if (enable_fwd_latency)
+   m[i]->timestamp = timestamp;
}
-   enq = rte_event_enqueue_burst(dev_id, port, ev, burst_size);
+   enq = rte_event_enqueue_new_burst(dev_id, port, ev, burst_size);
while (enq < burst_size) {
-   enq += rte_event_enqueue_burst(dev_id, port,
-   ev + enq,
-   burst_size - enq);
+   enq += rte_event_enqueue_new_burst(
+   dev_id, port, ev + enq, burst_size - enq)

[PATCH 3/3] app/eventdev: prevent mempool exhaustion

2023-04-19 Thread pbhagavatula

From: Pavan Nikhilesh 

Prevent mempool exhaustion due to elements being stuck in lcore
local caches.

Signed-off-by: Pavan Nikhilesh 
---
 app/test-eventdev/test_perf_common.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/app/test-eventdev/test_perf_common.c 
b/app/test-eventdev/test_perf_common.c
index 68af3cb346..5e0255cfeb 100644
--- a/app/test-eventdev/test_perf_common.c
+++ b/app/test-eventdev/test_perf_common.c
@@ -1859,34 +1859,35 @@ int
 perf_mempool_setup(struct evt_test *test, struct evt_options *opt)
 {
struct test_perf *t = evt_test_priv(test);
+   unsigned int cache_sz;
 
+   cache_sz = RTE_MIN(RTE_MEMPOOL_CACHE_MAX_SIZE, (opt->pool_sz / 1.5) / 
t->nb_workers);
if (opt->prod_type == EVT_PROD_TYPE_SYNT ||
opt->prod_type == EVT_PROD_TYPE_EVENT_TIMER_ADPTR) {
t->pool = rte_mempool_create(test->name, /* mempool name */
opt->pool_sz, /* number of elements*/
sizeof(struct perf_elt), /* element size*/
-   512, /* cache size*/
+   cache_sz, /* cache size*/
0, NULL, NULL,
perf_elt_init, /* obj constructor */
NULL, opt->socket_id, 0); /* flags */
} else if (opt->prod_type == EVT_PROD_TYPE_EVENT_CRYPTO_ADPTR &&
-   opt->crypto_op_type == RTE_CRYPTO_OP_TYPE_ASYMMETRIC)  {
+  opt->crypto_op_type == RTE_CRYPTO_OP_TYPE_ASYMMETRIC) {
t->pool = rte_mempool_create(test->name, /* mempool name */
opt->pool_sz, /* number of elements*/
sizeof(struct perf_elt) + 
modex_test_case.result_len,
/* element size*/
-   512, /* cache size*/
+   cache_sz, /* cache size*/
0, NULL, NULL,
NULL, /* obj constructor */
NULL, opt->socket_id, 0); /* flags */
} else {
t->pool = rte_pktmbuf_pool_create(test->name, /* mempool name */
opt->pool_sz, /* number of elements*/
-   512, /* cache size*/
+   cache_sz, /* cache size*/
0,
RTE_MBUF_DEFAULT_BUF_SIZE,
opt->socket_id); /* flags */
-
}
 
if (t->pool == NULL) {
-- 
2.25.1

[PATCH 00/11] sync Truflow support with latest release

2023-04-19 Thread Randy Schacher

Update Truflow support to latest release, deprecating code, updating
the copyright date and hsi structure, syncing the truflow core,
adding ULP shared session support, RSS action support, Queue
action support, rte meter support, and more.

Kishore Padmanabha (1):
  net/bnxt: fix multi-root card support

Randy Schacher (9):
  net/bnxt: remove deprecated features
  net/bnxt: update bnxt hsi structure
  net/bnxt: update copyright date and cleanup whitespace
  net/bnxt: update Truflow core
  net/bnxt: update ULP shared session support
  net/bnxt: add support for RSS action and Queue action
  net/bnxt: add ulp support for rte meter
  net/bnxt: update PTP support on Thor
  net/bnxt: add ulp support for ecpri

Shuanglin Wang (1):
  net/bnxt: Avoid submitting hwrm rss request when rss mode disabled

 drivers/net/bnxt/bnxt.h   |77 +-
 drivers/net/bnxt/bnxt_cpr.c   | 2 +-
 drivers/net/bnxt/bnxt_cpr.h   | 2 +-
 drivers/net/bnxt/bnxt_ethdev.c|   211 +-
 drivers/net/bnxt/bnxt_filter.c| 2 +-
 drivers/net/bnxt/bnxt_filter.h| 6 +-
 drivers/net/bnxt/bnxt_flow.c  |75 +-
 drivers/net/bnxt/bnxt_hwrm.c  |   272 +-
 drivers/net/bnxt/bnxt_hwrm.h  |40 +-
 drivers/net/bnxt/bnxt_irq.c   | 2 +-
 drivers/net/bnxt/bnxt_irq.h   | 3 +-
 drivers/net/bnxt/bnxt_nvm_defs.h  | 3 +-
 drivers/net/bnxt/bnxt_reps.c  | 4 +-
 drivers/net/bnxt/bnxt_reps.h  | 2 +-
 drivers/net/bnxt/bnxt_ring.c  | 7 +-
 drivers/net/bnxt/bnxt_ring.h  | 3 +-
 drivers/net/bnxt/bnxt_rxq.c   |   159 +-
 drivers/net/bnxt/bnxt_rxq.h   | 2 +-
 drivers/net/bnxt/bnxt_rxr.c   |15 +-
 drivers/net/bnxt/bnxt_rxr.h   | 3 +-
 drivers/net/bnxt/bnxt_rxtx_vec_avx2.c | 2 +-
 drivers/net/bnxt/bnxt_rxtx_vec_common.h   | 2 +-
 drivers/net/bnxt/bnxt_rxtx_vec_neon.c | 2 +-
 drivers/net/bnxt/bnxt_rxtx_vec_sse.c  | 2 +-
 drivers/net/bnxt/bnxt_stats.c | 2 +-
 drivers/net/bnxt/bnxt_stats.h | 2 +-
 drivers/net/bnxt/bnxt_txq.c   | 3 +-
 drivers/net/bnxt/bnxt_txq.h   | 2 +-
 drivers/net/bnxt/bnxt_txr.c   |95 +-
 drivers/net/bnxt/bnxt_txr.h   | 4 +-
 drivers/net/bnxt/bnxt_util.c  | 2 +-
 drivers/net/bnxt/bnxt_util.h  | 3 +-
 drivers/net/bnxt/bnxt_vnic.c  |   974 +-
 drivers/net/bnxt/bnxt_vnic.h  |80 +-
 drivers/net/bnxt/hsi_struct_def_dpdk.h|  5723 ++-
 drivers/net/bnxt/meson.build  | 5 +-
 drivers/net/bnxt/rte_pmd_bnxt.c   | 2 +-
 drivers/net/bnxt/rte_pmd_bnxt.h   | 2 +-
 drivers/net/bnxt/tf_core/bitalloc.c   | 3 +-
 drivers/net/bnxt/tf_core/bitalloc.h   | 3 +-
 drivers/net/bnxt/tf_core/cfa_resource_types.h | 5 +-
 drivers/net/bnxt/tf_core/cfa_tcam_mgr.c   |  2116 +
 drivers/net/bnxt/tf_core/cfa_tcam_mgr.h   |   523 +
 .../net/bnxt/tf_core/cfa_tcam_mgr_device.h|   101 +
 .../net/bnxt/tf_core/cfa_tcam_mgr_hwop_msg.c  |   201 +
 .../net/bnxt/tf_core/cfa_tcam_mgr_hwop_msg.h  |28 +
 drivers/net/bnxt/tf_core/cfa_tcam_mgr_p4.c|   921 +
 drivers/net/bnxt/tf_core/cfa_tcam_mgr_p4.h|20 +
 drivers/net/bnxt/tf_core/cfa_tcam_mgr_p58.c   |   926 +
 drivers/net/bnxt/tf_core/cfa_tcam_mgr_p58.h   |20 +
 drivers/net/bnxt/tf_core/cfa_tcam_mgr_sbmp.h  |   126 +
 .../net/bnxt/tf_core/cfa_tcam_mgr_session.c   |   377 +
 .../net/bnxt/tf_core/cfa_tcam_mgr_session.h   |54 +
 drivers/net/bnxt/tf_core/dpool.c  | 3 +-
 drivers/net/bnxt/tf_core/dpool.h  | 3 +-
 drivers/net/bnxt/tf_core/ll.c | 2 +-
 drivers/net/bnxt/tf_core/ll.h | 2 +-
 drivers/net/bnxt/tf_core/lookup3.h| 1 -
 drivers/net/bnxt/tf_core/meson.build  |38 +-
 drivers/net/bnxt/tf_core/rand.c   | 2 +-
 drivers/net/bnxt/tf_core/rand.h   | 3 +-
 drivers/net/bnxt/tf_core/stack.c  | 2 +-
 drivers/net/bnxt/tf_core/stack.h  | 3 +-
 drivers/net/bnxt/tf_core/tf_common.h  | 3 +-
 drivers/net/bnxt/tf_core/tf_core.c|56 +-
 drivers/net/bnxt/tf_core/tf_core.h|   189 +-
 drivers/net/bnxt/tf_core/tf_device.c  |53 +-
 drivers/net/bnxt/tf_core/tf_device.h  | 9 +-
 drivers/net/bnxt/tf_core/tf_device_p4.c   |24 +-
 drivers/net/bnxt/tf_core/tf_device_p4.h   | 3 +-
 drivers/net/bnxt/tf_core/tf_device_p58.c  |94 +-
 drivers/net/bnxt/tf_core/tf_device_p58.h  | 2 +-
 drivers/net/bnxt/tf_core/tf_em.

[PATCH 01/11] net/bnxt: remove deprecated features

2023-04-19 Thread Randy Schacher

- Deprecate shadow identifier
- Deprecate shadow tcam

Signed-off-by: Kishore Padmanabha 
Reviewed-by: Peter Spreadborough 
---
 drivers/net/bnxt/bnxt_hwrm.c  |  53 --
 drivers/net/bnxt/bnxt_hwrm.h  |  10 -
 drivers/net/bnxt/tf_core/meson.build  |   2 -
 drivers/net/bnxt/tf_core/tf_core.c|   2 -
 drivers/net/bnxt/tf_core/tf_core.h|  91 +-
 drivers/net/bnxt/tf_core/tf_device.c  |  35 -
 drivers/net/bnxt/tf_core/tf_device.h  |   6 -
 drivers/net/bnxt/tf_core/tf_device_p4.c   |  10 -
 drivers/net/bnxt/tf_core/tf_device_p58.c  |  10 -
 drivers/net/bnxt/tf_core/tf_identifier.c  | 108 ---
 drivers/net/bnxt/tf_core/tf_identifier.h  |   4 -
 drivers/net/bnxt/tf_core/tf_if_tbl.h  |   8 -
 drivers/net/bnxt/tf_core/tf_session.c |  49 +-
 drivers/net/bnxt/tf_core/tf_session.h |  18 +-
 .../net/bnxt/tf_core/tf_shadow_identifier.c   | 190 
 .../net/bnxt/tf_core/tf_shadow_identifier.h   | 229 -
 drivers/net/bnxt/tf_core/tf_shadow_tcam.c | 837 --
 drivers/net/bnxt/tf_core/tf_shadow_tcam.h | 195 
 drivers/net/bnxt/tf_core/tf_tcam.c| 243 -
 drivers/net/bnxt/tf_core/tf_tcam.h|  38 +-
 drivers/net/bnxt/tf_core/tf_util.c|   2 -
 drivers/net/bnxt/tf_ulp/bnxt_ulp.c|   3 -
 22 files changed, 28 insertions(+), 2115 deletions(-)
 delete mode 100644 drivers/net/bnxt/tf_core/tf_shadow_identifier.c
 delete mode 100644 drivers/net/bnxt/tf_core/tf_shadow_identifier.h
 delete mode 100644 drivers/net/bnxt/tf_core/tf_shadow_tcam.c
 delete mode 100644 drivers/net/bnxt/tf_core/tf_shadow_tcam.h

diff --git a/drivers/net/bnxt/bnxt_hwrm.c b/drivers/net/bnxt/bnxt_hwrm.c
index d86ac73293..3f273df6f3 100644
--- a/drivers/net/bnxt/bnxt_hwrm.c
+++ b/drivers/net/bnxt/bnxt_hwrm.c
@@ -407,59 +407,6 @@ int bnxt_hwrm_tf_message_direct(struct bnxt *bp,
return rc;
 }
 
-int bnxt_hwrm_tf_message_tunneled(struct bnxt *bp,
- bool use_kong_mb,
- uint16_t tf_type,
- uint16_t tf_subtype,
- uint32_t *tf_response_code,
- void *msg,
- uint32_t msg_len,
- void *response,
- uint32_t response_len)
-{
-   int rc = 0;
-   struct hwrm_cfa_tflib_input req = { .req_type = 0 };
-   struct hwrm_cfa_tflib_output *resp = bp->hwrm_cmd_resp_addr;
-   bool mailbox = BNXT_USE_CHIMP_MB;
-
-   if (msg_len > sizeof(req.tf_req))
-   return -ENOMEM;
-
-   if (use_kong_mb)
-   mailbox = BNXT_USE_KONG(bp);
-
-   HWRM_PREP(&req, HWRM_TF, mailbox);
-   /* Build request using the user supplied request payload.
-* TLV request size is checked at build time against HWRM
-* request max size, thus no checking required.
-*/
-   req.tf_type = tf_type;
-   req.tf_subtype = tf_subtype;
-   memcpy(req.tf_req, msg, msg_len);
-
-   rc = bnxt_hwrm_send_message(bp, &req, sizeof(req), mailbox);
-   HWRM_CHECK_RESULT();
-
-   /* Copy the resp to user provided response buffer */
-   if (response != NULL)
-   /* Post process response data. We need to copy only
-* the 'payload' as the HWRM data structure really is
-* HWRM header + msg header + payload and the TFLIB
-* only provided a payload place holder.
-*/
-   if (response_len != 0) {
-   memcpy(response,
-  resp->tf_resp,
-  response_len);
-   }
-
-   /* Extract the internal tflib response code */
-   *tf_response_code = resp->tf_resp_code;
-   HWRM_UNLOCK();
-
-   return rc;
-}
-
 int bnxt_hwrm_cfa_l2_clear_rx_mask(struct bnxt *bp, struct bnxt_vnic_info 
*vnic)
 {
int rc = 0;
diff --git a/drivers/net/bnxt/bnxt_hwrm.h b/drivers/net/bnxt/bnxt_hwrm.h
index a82d9fb3ef..f9d9fe0ef2 100644
--- a/drivers/net/bnxt/bnxt_hwrm.h
+++ b/drivers/net/bnxt/bnxt_hwrm.h
@@ -79,16 +79,6 @@ struct hwrm_func_qstats_output;
bp->rx_cos_queue[x].profile =   \
resp->queue_id##x##_service_profile
 
-int bnxt_hwrm_tf_message_tunneled(struct bnxt *bp,
- bool use_kong_mb,
- uint16_t tf_type,
- uint16_t tf_subtype,
- uint32_t *tf_response_code,
- void *msg,
- uint32_t msg_len,
- void *response,
- uint32_t response_len);
-
 int bnxt_hwrm_tf_message_direct(struct bnxt *bp,
bool use_kong_mb,

[PATCH 03/11] net/bnxt: update copyright date and cleanup whitespace

2023-04-19 Thread Randy Schacher

Update the Copyright to 2023
Clean up extra blank lines
Clean up other whitespace issues

Signed-off-by: Michael Baucom 
Reviewed-by: Kishore Padmanabha 
---
 drivers/net/bnxt/bnxt_cpr.c| 2 +-
 drivers/net/bnxt/bnxt_cpr.h| 2 +-
 drivers/net/bnxt/bnxt_filter.c | 2 +-
 drivers/net/bnxt/bnxt_irq.c| 2 +-
 drivers/net/bnxt/bnxt_irq.h| 2 +-
 drivers/net/bnxt/bnxt_nvm_defs.h   | 2 +-
 drivers/net/bnxt/bnxt_reps.h   | 2 +-
 drivers/net/bnxt/bnxt_ring.h   | 2 +-
 drivers/net/bnxt/bnxt_rxq.h| 2 +-
 drivers/net/bnxt/bnxt_rxr.h| 2 +-
 drivers/net/bnxt/bnxt_rxtx_vec_avx2.c  | 2 +-
 drivers/net/bnxt/bnxt_rxtx_vec_common.h| 2 +-
 drivers/net/bnxt/bnxt_rxtx_vec_neon.c  | 2 +-
 drivers/net/bnxt/bnxt_rxtx_vec_sse.c   | 2 +-
 drivers/net/bnxt/bnxt_stats.c  | 2 +-
 drivers/net/bnxt/bnxt_stats.h  | 2 +-
 drivers/net/bnxt/bnxt_txq.h| 2 +-
 drivers/net/bnxt/bnxt_util.c   | 2 +-
 drivers/net/bnxt/bnxt_util.h   | 2 +-
 drivers/net/bnxt/meson.build   | 2 +-
 drivers/net/bnxt/rte_pmd_bnxt.c| 2 +-
 drivers/net/bnxt/rte_pmd_bnxt.h| 2 +-
 drivers/net/bnxt/tf_core/bitalloc.c| 3 +--
 drivers/net/bnxt/tf_core/bitalloc.h| 3 +--
 drivers/net/bnxt/tf_core/cfa_resource_types.h  | 3 +--
 drivers/net/bnxt/tf_core/dpool.c   | 3 ++-
 drivers/net/bnxt/tf_core/dpool.h   | 3 +--
 drivers/net/bnxt/tf_core/ll.c  | 2 +-
 drivers/net/bnxt/tf_core/ll.h  | 2 +-
 drivers/net/bnxt/tf_core/lookup3.h | 1 -
 drivers/net/bnxt/tf_core/rand.c| 2 +-
 drivers/net/bnxt/tf_core/rand.h| 3 +--
 drivers/net/bnxt/tf_core/stack.c   | 2 +-
 drivers/net/bnxt/tf_core/stack.h   | 3 +--
 drivers/net/bnxt/tf_core/tf_common.h   | 3 +--
 drivers/net/bnxt/tf_core/tf_core.h | 1 -
 drivers/net/bnxt/tf_core/tf_device.h   | 1 -
 drivers/net/bnxt/tf_core/tf_device_p4.h| 3 +--
 drivers/net/bnxt/tf_core/tf_device_p58.h   | 2 +-
 drivers/net/bnxt/tf_core/tf_em.h   | 3 +--
 drivers/net/bnxt/tf_core/tf_em_common.c| 8 +---
 drivers/net/bnxt/tf_core/tf_em_common.h| 4 +---
 drivers/net/bnxt/tf_core/tf_em_hash_internal.c | 2 +-
 drivers/net/bnxt/tf_core/tf_em_host.c  | 3 +--
 drivers/net/bnxt/tf_core/tf_em_internal.c  | 3 ++-
 drivers/net/bnxt/tf_core/tf_ext_flow_handle.h  | 4 +---
 drivers/net/bnxt/tf_core/tf_global_cfg.c   | 2 +-
 drivers/net/bnxt/tf_core/tf_global_cfg.h   | 3 +--
 drivers/net/bnxt/tf_core/tf_hash.c | 2 +-
 drivers/net/bnxt/tf_core/tf_hash.h | 3 +--
 drivers/net/bnxt/tf_core/tf_identifier.c   | 2 +-
 drivers/net/bnxt/tf_core/tf_identifier.h   | 3 +--
 drivers/net/bnxt/tf_core/tf_if_tbl.h   | 3 +--
 drivers/net/bnxt/tf_core/tf_msg_common.h   | 3 +--
 drivers/net/bnxt/tf_core/tf_project.h  | 3 +--
 drivers/net/bnxt/tf_core/tf_resources.h| 3 +--
 drivers/net/bnxt/tf_core/tf_rm.h   | 6 +-
 drivers/net/bnxt/tf_core/tf_session.h  | 1 -
 drivers/net/bnxt/tf_core/tf_sram_mgr.h | 1 -
 drivers/net/bnxt/tf_core/tf_tbl.h  | 4 +---
 drivers/net/bnxt/tf_core/tf_tbl_sram.h | 6 +-
 drivers/net/bnxt/tf_core/tf_tcam.h | 3 +--
 drivers/net/bnxt/tf_core/tf_tcam_shared.h  | 1 -
 drivers/net/bnxt/tf_core/tf_util.c | 3 +--
 drivers/net/bnxt/tf_core/tf_util.h | 3 +--
 drivers/net/bnxt/tf_core/tfp.c | 2 +-
 drivers/net/bnxt/tf_core/tfp.h | 4 +---
 drivers/net/bnxt/tf_ulp/bnxt_tf_common.h   | 3 +--
 drivers/net/bnxt/tf_ulp/bnxt_tf_pmd_shim.h | 1 -
 drivers/net/bnxt/tf_ulp/bnxt_ulp.h | 1 -
 drivers/net/bnxt/tf_ulp/ulp_fc_mgr.h   | 1 -
 drivers/net/bnxt/tf_ulp/ulp_flow_db.h  | 1 -
 drivers/net/bnxt/tf_ulp/ulp_gen_hash.c | 2 +-
 drivers/net/bnxt/tf_ulp/ulp_gen_hash.h | 3 +--
 drivers/net/bnxt/tf_ulp/ulp_gen_tbl.h  | 1 -
 drivers/net/bnxt/tf_ulp/ulp_ha_mgr.h   | 1 -
 drivers/net/bnxt/tf_ulp/ulp_mapper.h   | 1 -
 drivers/net/bnxt/tf_ulp/ulp_mark_mgr.c | 2 +-
 drivers/net/bnxt/tf_ulp/ulp_mark_mgr.h | 3 +--
 drivers/net/bnxt/tf_ulp/ulp_matcher.h  | 3 +--
 drivers/net/bnxt/tf_ulp/ulp_port_db.h  | 1 -
 drivers/net/bnxt/tf_ulp/ulp_rte_parser.h   | 1 -
 drivers/net/bnxt/tf_ulp/ulp_template_struct.h  | 1 -
 drivers/net/bnxt/tf_ulp/ulp_tun.c  | 2 +-
 drivers/net/bnxt/tf_ulp/ulp_tun.h  | 3 +--
 drivers/net/bnxt/tf_ulp/ulp_utils.c| 2 +-
 drivers/net/bnxt/tf_ulp/ulp_utils.h| 3 +--
 87 files changed, 73

[PATCH 07/11] net/bnxt: add ulp support for rte meter

2023-04-19 Thread Randy Schacher

Add RTE meter support into the ULP layer

Signed-off-by: Kishore Padmanabha 
Reviewed-by: Jay Ding 
---
 drivers/net/bnxt/bnxt.h   |   2 +
 drivers/net/bnxt/bnxt_ethdev.c|   1 +
 drivers/net/bnxt/tf_ulp/bnxt_ulp.c|   8 +
 drivers/net/bnxt/tf_ulp/bnxt_ulp.h|   3 +
 drivers/net/bnxt/tf_ulp/bnxt_ulp_meter.c  | 909 ++
 drivers/net/bnxt/tf_ulp/meson.build   |   1 +
 drivers/net/bnxt/tf_ulp/ulp_rte_handler_tbl.c |   4 +-
 drivers/net/bnxt/tf_ulp/ulp_rte_parser.c  |  29 +
 drivers/net/bnxt/tf_ulp/ulp_rte_parser.h  |   5 +
 9 files changed, 960 insertions(+), 2 deletions(-)
 create mode 100644 drivers/net/bnxt/tf_ulp/bnxt_ulp_meter.c

diff --git a/drivers/net/bnxt/bnxt.h b/drivers/net/bnxt/bnxt.h
index bbbc21fbaf..09b108e297 100644
--- a/drivers/net/bnxt/bnxt.h
+++ b/drivers/net/bnxt/bnxt.h
@@ -1025,6 +1025,7 @@ bnxt_udp_tunnel_port_add_op(struct rte_eth_dev *eth_dev,
struct rte_eth_udp_tunnel *udp_tunnel);
 
 extern const struct rte_flow_ops bnxt_flow_ops;
+extern const struct rte_flow_ops bnxt_flow_meter_ops;
 
 #define bnxt_acquire_flow_lock(bp) \
pthread_mutex_lock(&(bp)->flow_lock)
@@ -1076,6 +1077,7 @@ int bnxt_flow_ops_get_op(struct rte_eth_dev *dev,
 int bnxt_dev_start_op(struct rte_eth_dev *eth_dev);
 int bnxt_dev_stop_op(struct rte_eth_dev *eth_dev);
 void bnxt_handle_vf_cfg_change(void *arg);
+int bnxt_flow_meter_ops_get(struct rte_eth_dev *eth_dev, void *arg);
 struct bnxt_vnic_info *bnxt_get_default_vnic(struct bnxt *bp);
 struct tf *bnxt_get_tfp_session(struct bnxt *bp, enum bnxt_session_type type);
 #endif
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index d275d8cb26..033ec176bf 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -4095,6 +4095,7 @@ static const struct eth_dev_ops bnxt_dev_ops = {
.timesync_adjust_time = bnxt_timesync_adjust_time,
.timesync_read_rx_timestamp = bnxt_timesync_read_rx_timestamp,
.timesync_read_tx_timestamp = bnxt_timesync_read_tx_timestamp,
+   .mtr_ops_get = bnxt_flow_meter_ops_get,
 };
 
 static uint32_t bnxt_map_reset_regs(struct bnxt *bp, uint32_t reg)
diff --git a/drivers/net/bnxt/tf_ulp/bnxt_ulp.c 
b/drivers/net/bnxt/tf_ulp/bnxt_ulp.c
index 873619e081..1d0b11e73c 100644
--- a/drivers/net/bnxt/tf_ulp/bnxt_ulp.c
+++ b/drivers/net/bnxt/tf_ulp/bnxt_ulp.c
@@ -1681,6 +1681,14 @@ bnxt_ulp_init(struct bnxt *bp,
return rc;
}
 
+   if (ulp_dev_id == BNXT_ULP_DEVICE_ID_THOR) {
+   rc = bnxt_flow_meter_init(bp);
+   if (rc) {
+   BNXT_TF_DBG(ERR, "Failed to config meter\n");
+   goto jump_to_error;
+   }
+   }
+
BNXT_TF_DBG(DEBUG, "ulp ctx has been initialized\n");
return rc;
 
diff --git a/drivers/net/bnxt/tf_ulp/bnxt_ulp.h 
b/drivers/net/bnxt/tf_ulp/bnxt_ulp.h
index 53d76e1465..a6ad5c1eaa 100644
--- a/drivers/net/bnxt/tf_ulp/bnxt_ulp.h
+++ b/drivers/net/bnxt/tf_ulp/bnxt_ulp.h
@@ -371,6 +371,9 @@ bnxt_ulp_vxlan_ip_port_set(struct bnxt_ulp_context *ulp_ctx,
 unsigned int
 bnxt_ulp_vxlan_ip_port_get(struct bnxt_ulp_context *ulp_ctx);
 
+int32_t
+bnxt_flow_meter_init(struct bnxt *bp);
+
 uint32_t
 bnxt_ulp_cntxt_convert_dev_id(uint32_t ulp_dev_id);
 
diff --git a/drivers/net/bnxt/tf_ulp/bnxt_ulp_meter.c 
b/drivers/net/bnxt/tf_ulp/bnxt_ulp_meter.c
new file mode 100644
index 00..2461c46f90
--- /dev/null
+++ b/drivers/net/bnxt/tf_ulp/bnxt_ulp_meter.c
@@ -0,0 +1,909 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2014-2023 Broadcom
+ * All rights reserved.
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "bnxt.h"
+#include "bnxt_filter.h"
+#include "bnxt_hwrm.h"
+#include "bnxt_ring.h"
+#include "bnxt_rxq.h"
+#include "bnxt_rxr.h"
+#include "bnxt_vnic.h"
+#include "hsi_struct_def_dpdk.h"
+
+#include "tfp.h"
+#include "bnxt_tf_common.h"
+#include "ulp_rte_parser.h"
+#include "ulp_matcher.h"
+#include "ulp_flow_db.h"
+#include "ulp_mapper.h"
+#include "ulp_fc_mgr.h"
+#include "ulp_port_db.h"
+#include "ulp_ha_mgr.h"
+#include "ulp_tun.h"
+#include 
+
+/**
+ * Meter init status
+ */
+int bnxt_meter_initialized;
+
+/**
+ * Internal api to config global config.
+ * returns 0 on success.
+ */
+static int32_t
+bnxt_meter_global_cfg_update(struct bnxt *bp,
+enum tf_dir dir,
+enum tf_global_config_type type,
+uint32_t offset,
+uint32_t value,
+uint32_t set_flag)
+{
+   uint32_t global_cfg = 0;
+   struct tf_global_cfg_parms parms = { 0 };
+   struct tf *tfp;
+   int32_t rc = 0;
+
+   parms.dir = dir,
+   parms.type = type,
+   parms.offset = offset,
+   parms.config =

[PATCH 08/11] net/bnxt: update PTP support on Thor

2023-04-19 Thread Randy Schacher

add locking and time stamp checks to ptp feature

Signed-off-by: Shahaji Bhosle 
Reviewed-by: Ajit Khaparde 
---
 drivers/net/bnxt/bnxt.h|  5 ++
 drivers/net/bnxt/bnxt_ethdev.c | 11 +
 drivers/net/bnxt/bnxt_hwrm.c   | 11 -
 drivers/net/bnxt/bnxt_ring.c   |  3 ++
 drivers/net/bnxt/bnxt_rxr.c|  8 +++-
 drivers/net/bnxt/bnxt_txq.c|  1 +
 drivers/net/bnxt/bnxt_txr.c| 85 --
 drivers/net/bnxt/bnxt_txr.h|  1 +
 8 files changed, 119 insertions(+), 6 deletions(-)

diff --git a/drivers/net/bnxt/bnxt.h b/drivers/net/bnxt/bnxt.h
index 09b108e297..9dd663e0c2 100644
--- a/drivers/net/bnxt/bnxt.h
+++ b/drivers/net/bnxt/bnxt.h
@@ -349,6 +349,7 @@ struct bnxt_ptp_cfg {
 BNXT_PTP_MSG_PDELAY_RESP)
uint8_t tx_tstamp_en:1;
int rx_filter;
+   uint8_t filter_all;
 
 #define BNXT_PTP_RX_TS_L   0
 #define BNXT_PTP_RX_TS_H   1
@@ -372,6 +373,8 @@ struct bnxt_ptp_cfg {
/* On P5, the Rx timestamp is present in the Rx completion record */
uint64_trx_timestamp;
uint64_tcurrent_time;
+   uint64_told_time;
+   rte_spinlock_t  ptp_lock;
 };
 
 struct bnxt_coal {
@@ -733,6 +736,7 @@ struct bnxt {
 #define BNXT_FW_CAP_LINK_ADMIN BIT(7)
 #define BNXT_FW_CAP_TRUFLOW_EN BIT(8)
 #define BNXT_FW_CAP_VLAN_TX_INSERT BIT(9)
+#define BNXT_FW_CAP_RX_ALL_PKT_TS  BIT(10)
 #define BNXT_TRUFLOW_EN(bp)((bp)->fw_cap & BNXT_FW_CAP_TRUFLOW_EN &&\
 (bp)->app_id != 0xFF)
 
@@ -860,6 +864,7 @@ struct bnxt {
struct bnxt_led_info*leds;
uint8_t ieee_1588;
struct bnxt_ptp_cfg *ptp_cfg;
+   uint8_t ptp_all_rx_tstamp;
uint16_tvf_resv_strategy;
struct bnxt_ctx_mem_info*ctx;
 
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index 033ec176bf..feba137959 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -1441,8 +1441,11 @@ static void bnxt_ptp_get_current_time(void *arg)
if (!ptp)
return;
 
+   rte_spinlock_lock(&ptp->ptp_lock);
+   ptp->old_time = ptp->current_time;
bnxt_hwrm_port_ts_query(bp, BNXT_PTP_FLAGS_CURRENT_TIME,
&ptp->current_time);
+   rte_spinlock_unlock(&ptp->ptp_lock);
rc = rte_eal_alarm_set(US_PER_S, bnxt_ptp_get_current_time, (void *)bp);
if (rc != 0) {
PMD_DRV_LOG(ERR, "Failed to re-schedule PTP alarm\n");
@@ -1458,8 +1461,11 @@ static int bnxt_schedule_ptp_alarm(struct bnxt *bp)
if (bp->flags2 & BNXT_FLAGS2_PTP_ALARM_SCHEDULED)
return 0;
 
+   rte_spinlock_lock(&ptp->ptp_lock);
bnxt_hwrm_port_ts_query(bp, BNXT_PTP_FLAGS_CURRENT_TIME,
&ptp->current_time);
+   ptp->old_time = ptp->current_time;
+   rte_spinlock_unlock(&ptp->ptp_lock);
 
 
rc = rte_eal_alarm_set(US_PER_S, bnxt_ptp_get_current_time, (void *)bp);
@@ -3615,12 +3621,15 @@ bnxt_timesync_enable(struct rte_eth_dev *dev)
 
ptp->rx_filter = 1;
ptp->tx_tstamp_en = 1;
+   ptp->filter_all = 1;
ptp->rxctl = BNXT_PTP_MSG_EVENTS;
 
rc = bnxt_hwrm_ptp_cfg(bp);
if (rc)
return rc;
 
+   rte_spinlock_init(&ptp->ptp_lock);
+   bp->ptp_all_rx_tstamp = 1;
memset(&ptp->tc, 0, sizeof(struct rte_timecounter));
memset(&ptp->rx_tstamp_tc, 0, sizeof(struct rte_timecounter));
memset(&ptp->tx_tstamp_tc, 0, sizeof(struct rte_timecounter));
@@ -3657,9 +3666,11 @@ bnxt_timesync_disable(struct rte_eth_dev *dev)
ptp->rx_filter = 0;
ptp->tx_tstamp_en = 0;
ptp->rxctl = 0;
+   ptp->filter_all = 0;
 
bnxt_hwrm_ptp_cfg(bp);
 
+   bp->ptp_all_rx_tstamp = 0;
if (!BNXT_CHIP_P5(bp))
bnxt_unmap_ptp_regs(bp);
else
diff --git a/drivers/net/bnxt/bnxt_hwrm.c b/drivers/net/bnxt/bnxt_hwrm.c
index 38da3a114c..0c4b29 100644
--- a/drivers/net/bnxt/bnxt_hwrm.c
+++ b/drivers/net/bnxt/bnxt_hwrm.c
@@ -669,6 +669,11 @@ int bnxt_hwrm_ptp_cfg(struct bnxt *bp)
flags |=
HWRM_PORT_MAC_CFG_INPUT_FLAGS_PTP_TX_TS_CAPTURE_DISABLE;
 
+   if (ptp->filter_all)
+   flags |=  
HWRM_PORT_MAC_CFG_INPUT_FLAGS_ALL_RX_TS_CAPTURE_ENABLE;
+   else if (bp->fw_cap & BNXT_FW_CAP_RX_ALL_PKT_TS)
+   flags |= 
HWRM_PORT_MAC_CFG_INPUT_FLAGS_ALL_RX_TS_CAPTURE_DISABLE;
+
req.flags = rte_cpu_to_le_32(flags);
req.enables = rte_cpu_to_le_32
(HWRM_PORT_MAC_CFG_INPUT_ENABLES_RX_TS_CAPTURE_PTP_MSG_TYPE);
@@ -810,7 +815,7 @@ static int __bnxt_hwrm_func_qcaps(struct bnxt *bp)
struct hwrm_func_qca

[PATCH 09/11] net/bnxt: fix multi-root card support

2023-04-19 Thread Randy Schacher

From: Kishore Padmanabha 

Changed the logic to use device serial number to identify that
different ports belong to same physical card instead of the PCI
domain address.

Signed-off-by: Kishore Padmanabha 
Reviewed-by: Shahaji Bhosle 
---
 drivers/net/bnxt/bnxt.h|  3 +++
 drivers/net/bnxt/bnxt_hwrm.c   |  1 +
 drivers/net/bnxt/tf_ulp/bnxt_ulp.c | 11 ---
 drivers/net/bnxt/tf_ulp/bnxt_ulp.h |  2 ++
 4 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/net/bnxt/bnxt.h b/drivers/net/bnxt/bnxt.h
index 9dd663e0c2..ea678d40d2 100644
--- a/drivers/net/bnxt/bnxt.h
+++ b/drivers/net/bnxt/bnxt.h
@@ -138,6 +138,7 @@
 #define BNXT_NUM_CMPL_DMA_AGGR 36
 #define BNXT_CMPL_AGGR_DMA_TMR_DURING_INT  50
 #define BNXT_NUM_CMPL_DMA_AGGR_DURING_INT  12
+#define BNXT_DEVICE_SERIAL_NUM_SIZE8
 
 #defineBNXT_DEFAULT_VNIC_STATE_MASK\

HWRM_ASYNC_EVENT_CMPL_DEFAULT_VNIC_CHANGE_EVENT_DATA1_DEF_VNIC_STATE_MASK
@@ -874,6 +875,8 @@ struct bnxt {
uint16_tnum_reps;
struct bnxt_rep_info*rep_info;
uint16_t*cfa_code_map;
+   /* Device Serial Number */
+   uint8_t dsn[BNXT_DEVICE_SERIAL_NUM_SIZE];
/* Struct to hold adapter error recovery related info */
struct bnxt_error_recovery_info *recovery_info;
 #define BNXT_MARK_TABLE_SZ (sizeof(struct bnxt_mark_info)  * 64 * 1024)
diff --git a/drivers/net/bnxt/bnxt_hwrm.c b/drivers/net/bnxt/bnxt_hwrm.c
index 0c4b29..7c0d2faa8b 100644
--- a/drivers/net/bnxt/bnxt_hwrm.c
+++ b/drivers/net/bnxt/bnxt_hwrm.c
@@ -863,6 +863,7 @@ static int __bnxt_hwrm_func_qcaps(struct bnxt *bp)
bp->max_l2_ctx, bp->max_vnics);
bp->max_stat_ctx = rte_le_to_cpu_16(resp->max_stat_ctx);
bp->max_mcast_addr = rte_le_to_cpu_32(resp->max_mcast_filters);
+   memcpy(bp->dsn, resp->device_serial_number, sizeof(bp->dsn));
 
if (BNXT_PF(bp))
bp->pf->total_vnics = rte_le_to_cpu_16(resp->max_vnics);
diff --git a/drivers/net/bnxt/tf_ulp/bnxt_ulp.c 
b/drivers/net/bnxt/tf_ulp/bnxt_ulp.c
index 1d0b11e73c..f80e76e69c 100644
--- a/drivers/net/bnxt/tf_ulp/bnxt_ulp.c
+++ b/drivers/net/bnxt/tf_ulp/bnxt_ulp.c
@@ -1318,9 +1318,13 @@ ulp_get_session(struct bnxt *bp, struct rte_pci_addr 
*pci_addr)
 
/* if multi root capability is enabled, then ignore the pci bus id */
STAILQ_FOREACH(session, &bnxt_ulp_session_list, next) {
-   if (session->pci_info.domain == pci_addr->domain &&
-   (BNXT_MULTIROOT_EN(bp) ||
-   session->pci_info.bus == pci_addr->bus)) {
+   if (BNXT_MULTIROOT_EN(bp)) {
+   if (!memcmp(bp->dsn, session->dsn,
+   sizeof(session->dsn))) {
+   return session;
+   }
+   } else if (session->pci_info.domain == pci_addr->domain &&
+  session->pci_info.bus == pci_addr->bus) {
return session;
}
}
@@ -1364,6 +1368,7 @@ ulp_session_init(struct bnxt *bp,
/* Add it to the queue */
session->pci_info.domain = pci_addr->domain;
session->pci_info.bus = pci_addr->bus;
+   memcpy(session->dsn, bp->dsn, sizeof(session->dsn));
rc = pthread_mutex_init(&session->bnxt_ulp_mutex, NULL);
if (rc) {
BNXT_TF_DBG(ERR, "mutex create failed\n");
diff --git a/drivers/net/bnxt/tf_ulp/bnxt_ulp.h 
b/drivers/net/bnxt/tf_ulp/bnxt_ulp.h
index a6ad5c1eaa..92db7751fe 100644
--- a/drivers/net/bnxt/tf_ulp/bnxt_ulp.h
+++ b/drivers/net/bnxt/tf_ulp/bnxt_ulp.h
@@ -131,11 +131,13 @@ struct bnxt_ulp_pci_info {
uint8_t bus;
 };
 
+#define BNXT_ULP_DEVICE_SERIAL_NUM_SIZE 8
 struct bnxt_ulp_session_state {
STAILQ_ENTRY(bnxt_ulp_session_state)next;
boolbnxt_ulp_init;
pthread_mutex_t bnxt_ulp_mutex;
struct bnxt_ulp_pci_infopci_info;
+   uint8_t dsn[BNXT_ULP_DEVICE_SERIAL_NUM_SIZE];
struct bnxt_ulp_data*cfg_data;
struct tf   *g_tfp[BNXT_ULP_SESSION_MAX];
uint32_tsession_opened[BNXT_ULP_SESSION_MAX];
-- 
2.25.1

[PATCH 10/11] net/bnxt: add ulp support for ecpri

2023-04-19 Thread Randy Schacher

Add RTE ECPRI support into the ULP layer

Signed-off-by: Shahaji Bhosle 
Reviewed-by: Manish Kurup 
---
 drivers/net/bnxt/bnxt.h   |   4 +
 drivers/net/bnxt/bnxt_ethdev.c|  35 +
 drivers/net/bnxt/bnxt_hwrm.c  |  17 +++
 drivers/net/bnxt/bnxt_txr.c   |  10 +-
 drivers/net/bnxt/bnxt_vnic.c  |   5 +-
 drivers/net/bnxt/tf_ulp/bnxt_tf_pmd_shim.c|   7 +-
 drivers/net/bnxt/tf_ulp/bnxt_tf_pmd_shim.h|   1 +
 drivers/net/bnxt/tf_ulp/bnxt_ulp.c|  24 
 drivers/net/bnxt/tf_ulp/bnxt_ulp.h|   9 +-
 drivers/net/bnxt/tf_ulp/ulp_mapper.c  |  18 +++
 drivers/net/bnxt/tf_ulp/ulp_rte_handler_tbl.c |   4 +
 drivers/net/bnxt/tf_ulp/ulp_rte_parser.c  | 120 +-
 drivers/net/bnxt/tf_ulp/ulp_rte_parser.h  |   5 +
 drivers/net/bnxt/tf_ulp/ulp_template_struct.h |   2 +
 14 files changed, 254 insertions(+), 7 deletions(-)

diff --git a/drivers/net/bnxt/bnxt.h b/drivers/net/bnxt/bnxt.h
index ea678d40d2..43e122a641 100644
--- a/drivers/net/bnxt/bnxt.h
+++ b/drivers/net/bnxt/bnxt.h
@@ -855,10 +855,14 @@ struct bnxt {
uint8_t port_cnt;
uint8_t vxlan_port_cnt;
uint8_t geneve_port_cnt;
+   uint8_t ecpri_port_cnt;
uint16_tvxlan_port;
uint16_tgeneve_port;
+   uint16_tecpri_port;
uint16_tvxlan_fw_dst_port_id;
uint16_tgeneve_fw_dst_port_id;
+   uint16_tecpri_fw_dst_port_id;
+   uint16_tecpri_upar_in_use;
uint32_tfw_ver;
uint32_thwrm_spec_code;
 
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index feba137959..72494ee1da 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -2405,6 +2405,20 @@ bnxt_udp_tunnel_port_add_op(struct rte_eth_dev *eth_dev,
tunnel_type =
HWRM_TUNNEL_DST_PORT_ALLOC_INPUT_TUNNEL_TYPE_GENEVE;
break;
+   case RTE_ETH_TUNNEL_TYPE_ECPRI:
+   if (bp->ecpri_port_cnt) {
+   PMD_DRV_LOG(ERR, "Tunnel Port %d already programmed\n",
+   udp_tunnel->udp_port);
+   if (bp->ecpri_port != udp_tunnel->udp_port) {
+   PMD_DRV_LOG(ERR, "Only one port allowed\n");
+   return -ENOSPC;
+   }
+   bp->ecpri_port_cnt++;
+   return 0;
+   }
+   tunnel_type =
+   HWRM_TUNNEL_DST_PORT_ALLOC_INPUT_TUNNEL_TYPE_ECPRI;
+   break;
default:
PMD_DRV_LOG(ERR, "Tunnel type is not supported\n");
return -ENOTSUP;
@@ -2423,6 +2437,10 @@ bnxt_udp_tunnel_port_add_op(struct rte_eth_dev *eth_dev,
HWRM_TUNNEL_DST_PORT_ALLOC_INPUT_TUNNEL_TYPE_GENEVE)
bp->geneve_port_cnt++;
 
+   if (tunnel_type ==
+   HWRM_TUNNEL_DST_PORT_ALLOC_INPUT_TUNNEL_TYPE_ECPRI)
+   bp->ecpri_port_cnt++;
+
return rc;
 }
 
@@ -2474,6 +2492,23 @@ bnxt_udp_tunnel_port_del_op(struct rte_eth_dev *eth_dev,
HWRM_TUNNEL_DST_PORT_FREE_INPUT_TUNNEL_TYPE_GENEVE;
port = bp->geneve_fw_dst_port_id;
break;
+   case RTE_ETH_TUNNEL_TYPE_ECPRI:
+   if (!bp->ecpri_port_cnt) {
+   PMD_DRV_LOG(ERR, "No Tunnel port configured yet\n");
+   return -EINVAL;
+   }
+   if (bp->ecpri_port != udp_tunnel->udp_port) {
+   PMD_DRV_LOG(ERR, "Req Port: %d. Configured port: %d\n",
+   udp_tunnel->udp_port, bp->ecpri_port);
+   return -EINVAL;
+   }
+   if (--bp->ecpri_port_cnt)
+   return 0;
+
+   tunnel_type =
+   HWRM_TUNNEL_DST_PORT_FREE_INPUT_TUNNEL_TYPE_ECPRI;
+   port = bp->ecpri_fw_dst_port_id;
+   break;
default:
PMD_DRV_LOG(ERR, "Tunnel type is not supported\n");
return -ENOTSUP;
diff --git a/drivers/net/bnxt/bnxt_hwrm.c b/drivers/net/bnxt/bnxt_hwrm.c
index 7c0d2faa8b..24a892bacf 100644
--- a/drivers/net/bnxt/bnxt_hwrm.c
+++ b/drivers/net/bnxt/bnxt_hwrm.c
@@ -2969,6 +2969,10 @@ bnxt_free_tunnel_ports(struct bnxt *bp)
if (bp->geneve_port_cnt)
bnxt_hwrm_tunnel_dst_port_free(bp, bp->geneve_fw_dst_port_id,
HWRM_TUNNEL_DST_PORT_FREE_INPUT_TUNNEL_TYPE_GENEVE);
+
+   if (bp->ecpri_port_cnt)
+   bnxt_hwrm_tunnel_dst_port_free(bp, bp->ecpri_fw_dst_port_id,
+   HWRM_TUNNEL_DST_PORT_FREE_INPUT_TUNNEL_TYPE

[PATCH 11/11] net/bnxt: Avoid submitting hwrm rss request when rss mode disabled

2023-04-19 Thread Randy Schacher

From: Shuanglin Wang 

On WH+, if rss mode isn't enabled, then there is no rss context.
Submitting HWRM_VNIC_RSS_CFG request to firmware would hit a failure.

The fix is to check the rss context. If no rss context, then don't
submit the hwrm request.

Signed-off-by: Kishore Padmanabha 
Reviewed-by: Michael Baucom 
Reviewed-by: Shuanglin Wang 
---
 drivers/net/bnxt/bnxt_hwrm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/bnxt/bnxt_hwrm.c b/drivers/net/bnxt/bnxt_hwrm.c
index 24a892bacf..d63bf227a6 100644
--- a/drivers/net/bnxt/bnxt_hwrm.c
+++ b/drivers/net/bnxt/bnxt_hwrm.c
@@ -2405,6 +2405,9 @@ bnxt_hwrm_vnic_rss_cfg_non_p5(struct bnxt *bp, struct 
bnxt_vnic_info *vnic)
struct hwrm_vnic_rss_cfg_output *resp = bp->hwrm_cmd_resp_addr;
int rc = 0;
 
+   if (vnic->num_lb_ctxts == 0)
+   return rc;
+
HWRM_PREP(&req, HWRM_VNIC_RSS_CFG, BNXT_USE_CHIMP_MB);
 
req.hash_type = rte_cpu_to_le_32(vnic->hash_type);
-- 
2.25.1

RE: [dpdk-dev] [PATCH] ring: fix use after free in ring release

2023-04-19 Thread Honnappa Nagarahalli



> >
> > > -Original Message-
> > > From: Yunjian Wang 
> > > Sent: Monday, April 17, 2023 8:12 AM
> > > To: dev@dpdk.org
> > > Cc: Honnappa Nagarahalli ;
> > > konstantin.v.anan...@yandex.ru; luyi...@huawei.com; Yunjian Wang
> > > ; sta...@dpdk.org
> > > Subject: [dpdk-dev] [PATCH] ring: fix use after free in ring release
> > >
> > > When using the ring to find out tailq entry, however it had been
> > > freed by rte_memzone_free function. This change prevents that from
> happening.
> > I am unable to follow the problem you are describing.
> > After the memzone for the ring is released, the contents of the
> > memzone are not being used. I understand that the variable 'r' is
> > being used, but that should not cause any issues.
> >
> > >
> > > Fixes: 4e32101f9b01 ("ring: support freeing")
> > > Cc: sta...@dpdk.org
> > >
> > > Signed-off-by: Yunjian Wang 
> > > ---
> > >  lib/ring/rte_ring.c | 11 +--
> > >  1 file changed, 5 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/lib/ring/rte_ring.c b/lib/ring/rte_ring.c index
> > > 8ed455043d..17d2d7f8a8 100644
> > > --- a/lib/ring/rte_ring.c
> > > +++ b/lib/ring/rte_ring.c
> > > @@ -333,11 +333,6 @@ rte_ring_free(struct rte_ring *r)
> > >   return;
> > >   }
> > >
> > > - if (rte_memzone_free(r->memzone) != 0) {
> > > - RTE_LOG(ERR, RING, "Cannot free memory\n");
> > > - return;
> > > - }
> > Why do we need to free the memzone later?
> 
> After the memzone is freed, it is not removed from the 'rte_ring_tailq'.
> If rte_ring_lookup is called at this time, it will cause a use-after-free 
> problem.
Thanks, understood

> 
> Thanks,
> Yunjian
> >
> > > -
> > >   ring_list = RTE_TAILQ_CAST(rte_ring_tailq.head, rte_ring_list);
> > >   rte_mcfg_tailq_write_lock();
> > >
> > > @@ -349,7 +344,7 @@ rte_ring_free(struct rte_ring *r)
> > >
> > >   if (te == NULL) {
> > >   rte_mcfg_tailq_write_unlock();
> > > - return;
> > > + goto free_memzone;
We do not need this. If 'te == NULL' is true, then the ring was not found or 
possibly already freed.

> > >   }
> > >
> > >   TAILQ_REMOVE(ring_list, te, next); @@ -357,6 +352,10 @@
> > > rte_ring_free(struct rte_ring *r)
We should free the memzone here while holding the lock

> > >   rte_mcfg_tailq_write_unlock();
> > >
> > >   rte_free(te);
> > > +
> > > +free_memzone:
> > > + if (rte_memzone_free(r->memzone) != 0)
> > > + RTE_LOG(ERR, RING, "Cannot free memory\n");
> > >  }
Should be moved up as mentioned above

> > >
> > >  /* dump the status of the ring on the console */
> > > --
> > > 2.33.0

Re: [PATCH 1/2] config/arm: Do not require processor information

2023-04-19 Thread Akihiko Odaki

On 2023/04/17 16:41, Ruifeng Wang wrote:

-Original Message-
From: Akihiko Odaki 
Sent: Friday, April 14, 2023 8:42 PM
To: Ruifeng Wang ; Bruce Richardson 

Cc: dev@dpdk.org; Akihiko Odaki 
Subject: [PATCH 1/2] config/arm: Do not require processor information

DPDK can be built even without exact processor information for x86 and ppc so 
allow to
build for Arm even if we don't know the targeted processor is unknown.

Hi Akihiko,

The design idea was to require an explicit generic build.
Default/native build doesn't fall back to generic build when SoC info is not on 
the list.
So the user has less chance to generate a suboptimal binary by accident.

Hi,

It is true that the suboptimal binary can result, but the rationale here 
is that we tolerate that for x86 and ppc so it should not really matter 
for Arm too. On x86 and ppc you don't need to modify meson.build just to 
run dts on a development machine.

Regards,
Akihiko Odaki

RE: [GRO] check whether ip_id continuity needs to be checked when two TCP packets are merged.

2023-04-19 Thread Hu, Jiayu

Hi Cheng,

> -Original Message-
> From: jiangheng (G) 
> Sent: Saturday, April 15, 2023 10:46 PM
> To: us...@dpdk.org; Hu, Jiayu ; dev@dpdk.org
> Subject: [GRO] check whether ip_id continuity needs to be checked when
> two TCP packets are merged.
> 
> Hi jiayu.hu
> 
> It cannot be guaranteed that 16bit identification field of ip packets in the
> same tcp stream will be continuous.
> Please help check whether ip_id continuity needs to be checked when two
> TCP packets are merged?
> Seems to modify the following code, gro will aggregate better, and work
> better:
> 
> diff --git a/lib/gro/gro_tcp4.h b/lib/gro/gro_tcp4.h index
> 212f97a042..06faead7b5 100644
> --- a/lib/gro/gro_tcp4.h
> +++ b/lib/gro/gro_tcp4.h
> @@ -291,12 +291,10 @@ check_seq_option(struct gro_tcp4_item *item,
> /* check if the two packets are neighbors */
> len = pkt_orig->pkt_len - l2_offset - pkt_orig->l2_len -
> pkt_orig->l3_len - tcp_hl_orig;
> -   if ((sent_seq == item->sent_seq + len) && (is_atomic ||
> -   (ip_id == item->ip_id + 1)))
> +   if (sent_seq == item->sent_seq + len)

For atomic packets, the IP ID field is ignored, as it can be set in various 
ways.
For non-atomic packets, it follows Linux kernel tcp_gro_receive().

Is this change specific to your case? Can you give more details on why it helps?

Thanks,
Jiayu
> /* append the new packet */
> return 1;
> -   else if ((sent_seq + tcp_dl == item->sent_seq) && (is_atomic ||
> -   (ip_id + item->nb_merged == item->ip_id)))
> +   else if (sent_seq + tcp_dl == item->sent_seq)
> /* pre-pend the new packet */
> return -1;

RE: 21.11.4 patches review and test

2023-04-19 Thread Xu, HailinX

> -Original Message-
> From: Xu, HailinX 
> Sent: Thursday, April 13, 2023 2:13 PM
> To: Kevin Traynor ; sta...@dpdk.org
> Cc: dev@dpdk.org; Abhishek Marathe ;
> Ali Alnubani ; Walker, Benjamin
> ; David Christensen ;
> Hemant Agrawal ; Stokes, Ian
> ; Jerin Jacob ; Mcnamara, John
> ; Ju-Hyoung Lee ; Luca
> Boccassi ; Pei Zhang ; Xu, Qian Q
> ; Raslan Darawsheh ; Thomas
> Monjalon ; yangh...@redhat.com; Peng, Yuan
> ; Chen, Zhaoyan 
> Subject: RE: 21.11.4 patches review and test
> 
> > -Original Message-
> > From: Kevin Traynor 
> > Sent: Thursday, April 6, 2023 7:38 PM
> > To: sta...@dpdk.org
> > Cc: dev@dpdk.org; Abhishek Marathe ;
> > Ali Alnubani ; Walker, Benjamin
> > ; David Christensen
> > ; Hemant Agrawal ;
> > Stokes, Ian ; Jerin Jacob ;
> > Mcnamara, John ; Ju-Hyoung Lee
> > ; Kevin Traynor ; Luca
> > Boccassi ; Pei Zhang ; Xu, Qian
> > Q ; Raslan Darawsheh ;
> Thomas
> > Monjalon ; yangh...@redhat.com; Peng, Yuan
> > ; Chen, Zhaoyan 
> > Subject: 21.11.4 patches review and test
> >
> > Hi all,
> >
> > Here is a list of patches targeted for stable release 21.11.4.
> >
> > The planned date for the final release is 25th April.
> >
> > Please help with testing and validation of your use cases and report
> > any issues/results with reply-all to this mail. For the final release
> > the fixes and reported validations will be added to the release notes.
> >
> > A release candidate tarball can be found at:
> >
> > https://dpdk.org/browse/dpdk-stable/tag/?id=v21.11.4-rc1
> >
> > These patches are located at branch 21.11 of dpdk-stable repo:
> > https://dpdk.org/browse/dpdk-stable/
> >
> > Thanks.
> >
> > Kevin
> 
> HI All,
> 
> Update the test status for Intel part. Till now dpdk21.11.4-rc1 validation 
> test
> rate is 85%. No critical issue is found.
> 2 new bugs are found, 1 new issue is under confirming by Intel Dev.
> New bugs:   --20.11.8-rc1 also has these two issues
>   1. pvp_qemu_multi_paths_port_restart:perf_pvp_qemu_vector_rx_mac:
> performance drop about 23.5% when send small packets
>   https://bugs.dpdk.org/show_bug.cgi?id=1212-- no fix yet
>   2. some of the virtio tests are failing:-- Intel dev is under 
> investigating
> # Basic Intel(R) NIC testing
> * Build & CFLAG compile: cover the build test combination with latest
> GCC/Clang version and the popular OS revision such as
>   Ubuntu20.04, Ubuntu22.04, Fedora35, Fedora37, RHEL8.6, RHEL8.4,
> FreeBSD13.1, SUSE15, CentOS7.9, etc.
> - All test done. No new dpdk issue is found.
> * PF(i40e, ixgbe): test scenarios including
> RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc.
> - All test done. No new dpdk issue is found.
> * VF(i40e, ixgbe): test scenarios including
> VF-RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc.
> - All test done. No new dpdk issue is found.
> * PF/VF(ice): test scenarios including Switch features/Package
> Management/Flow Director/Advanced Tx/Advanced RSS/ACL/DCF/Flexible
> Descriptor, etc.
> - All test done. No new dpdk issue is found.
> * Intel NIC single core/NIC performance: test scenarios including PF/VF single
> core performance test, etc.
> - All test done. No new dpdk issue is found.
> * IPsec: test scenarios including ipsec/ipsec-gw/ipsec library basic test -
> QAT&SW/FIB library, etc.
> - On going.
> 
> # Basic cryptodev and virtio testing
> * Virtio: both function and performance test are covered. Such as
> PVP/Virtio_loopback/virtio-user loopback/virtio-net VM2VM perf
> testing/VMAWARE ESXI 8.0, etc.
> - All test done. found bug1.
> * Cryptodev:
>   *Function test: test scenarios including Cryptodev API testing/CompressDev
> ISA-L/QAT/ZLIB PMD Testing/FIPS, etc.
> - Execution rate is 90%. found bug2.
>   *Performance test: test scenarios including Thoughput
> Performance/Cryptodev Latency, etc.
> - All test done. No new dpdk issue is found.
> 
> Regards,
> Xu, Hailin
Update the test status for Intel part. completed dpdk21.11.4-rc1 all 
validation. No critical issue is found.
2 new bugs are found, 1 new issue is under confirming by Intel Dev.
New bugs: --20.11.8-rc1 also has these two issues
  1. pvp_qemu_multi_paths_port_restart:perf_pvp_qemu_vector_rx_mac: performance 
drop about 23.5% when send small packets 
https://bugs.dpdk.org/show_bug.cgi?id=1212  --not fix yet, Only the 
specified platform exists
  2. some of the virtio tests are failing: -- Intel dev is under investigating
# Basic Intel(R) NIC testing
* Build & CFLAG compile: cover the build test combination with latest GCC/Clang 
version and the popular OS revision such as
  Ubuntu20.04, Ubuntu22.04, Fedora35, Fedora37, RHEL8.6, RHEL8.4, FreeBSD13.1, 
SUSE15, CentOS7.9, etc.
- All test done. No new dpdk issue is found.
* PF(i40e, ixgbe): test scenarios including RTE_FLOW/TSO/Jumboframe/checksum 
offload/VLAN/VXLAN, etc. 
- All test done. No new dpdk issue is found.
* VF(i40e, ixgbe): test scenarios including VF-RTE_FLOW/TSO/Jumboframe/checksum 
offload/VLAN/VXLAN, etc.

Re: [GRO] check whether ip_id continuity needs to be checked when two TCP packets are merged.

2023-04-19 Thread Stephen Hemminger

On Thu, 20 Apr 2023 02:30:41 +
"Hu, Jiayu"  wrote:

> Hi Cheng,
> 
> > -Original Message-
> > From: jiangheng (G) 
> > Sent: Saturday, April 15, 2023 10:46 PM
> > To: us...@dpdk.org; Hu, Jiayu ; dev@dpdk.org
> > Subject: [GRO] check whether ip_id continuity needs to be checked when
> > two TCP packets are merged.
> > 
> > Hi jiayu.hu
> > 
> > It cannot be guaranteed that 16bit identification field of ip packets in the
> > same tcp stream will be continuous.
> > Please help check whether ip_id continuity needs to be checked when two
> > TCP packets are merged?
> > Seems to modify the following code, gro will aggregate better, and work
> > better:
> > 
> > diff --git a/lib/gro/gro_tcp4.h b/lib/gro/gro_tcp4.h index
> > 212f97a042..06faead7b5 100644
> > --- a/lib/gro/gro_tcp4.h
> > +++ b/lib/gro/gro_tcp4.h
> > @@ -291,12 +291,10 @@ check_seq_option(struct gro_tcp4_item *item,
> > /* check if the two packets are neighbors */
> > len = pkt_orig->pkt_len - l2_offset - pkt_orig->l2_len -
> > pkt_orig->l3_len - tcp_hl_orig;
> > -   if ((sent_seq == item->sent_seq + len) && (is_atomic ||
> > -   (ip_id == item->ip_id + 1)))
> > +   if (sent_seq == item->sent_seq + len)  
> 
> For atomic packets, the IP ID field is ignored, as it can be set in various 
> ways.
> For non-atomic packets, it follows Linux kernel tcp_gro_receive().
> 
> Is this change specific to your case? Can you give more details on why it 
> helps?

Many OS's don't change IP ID if DF bit is set.
See RFC 6864 for details
   >> The IPv4 ID field MUST NOT be used for purposes other than
  fragmentation and reassembly.

[dpdk-dev][PATCH] ethdev: add send queue flow matching item

2023-04-19 Thread kirankumark

From: Kiran Kumar K 

Adding support for send queue flow matching item.
This item is valid only for egress rules.
An example use case would be that application can
set different vlan insert rules with different PCP values
based on tx queue number.

Signed-off-by: Kiran Kumar K 
---
 app/test-pmd/cmdline_flow.c | 28 +++
 doc/guides/prog_guide/rte_flow.rst  |  7 +
 doc/guides/rel_notes/release_23_07.rst  | 31 ++---
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  4 +++
 lib/ethdev/rte_flow.c   |  1 +
 lib/ethdev/rte_flow.h   | 26 +
 6 files changed, 68 insertions(+), 29 deletions(-)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 58939ec321..a68a6080a8 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -496,6 +496,8 @@ enum index {
ITEM_QUOTA_STATE_NAME,
ITEM_AGGR_AFFINITY,
ITEM_AGGR_AFFINITY_VALUE,
+   ITEM_TX_QUEUE,
+   ITEM_TX_QUEUE_VALUE,
 
/* Validate/create actions. */
ACTIONS,
@@ -1452,6 +1454,7 @@ static const enum index next_item[] = {
ITEM_METER,
ITEM_QUOTA,
ITEM_AGGR_AFFINITY,
+   ITEM_TX_QUEUE,
END_SET,
ZERO,
 };
@@ -1953,6 +1956,12 @@ static const enum index item_aggr_affinity[] = {
ZERO,
 };
 
+static const enum index item_tx_queue[] = {
+   ITEM_TX_QUEUE_VALUE,
+   ITEM_NEXT,
+   ZERO,
+};
+
 static const enum index next_action[] = {
ACTION_END,
ACTION_VOID,
@@ -6945,6 +6954,22 @@ static const struct token token_list[] = {
.args = ARGS(ARGS_ENTRY(struct rte_flow_item_aggr_affinity,
affinity)),
},
+   [ITEM_TX_QUEUE] = {
+   .name = "tx_queue",
+   .help = "match on the tx queue of send packet",
+   .priv = PRIV_ITEM(TX_QUEUE,
+ sizeof(struct rte_flow_item_tx_queue)),
+   .next = NEXT(item_tx_queue),
+   .call = parse_vc,
+   },
+   [ITEM_TX_QUEUE_VALUE] = {
+   .name = "tx_queue_value",
+   .help = "tx queue value",
+   .next = NEXT(item_tx_queue, NEXT_ENTRY(COMMON_UNSIGNED),
+item_param),
+   .args = ARGS(ARGS_ENTRY(struct rte_flow_item_tx_queue,
+   tx_queue)),
+   },
 };
 
 /** Remove and return last entry from argument stack. */
@@ -11849,6 +11874,9 @@ flow_item_default_mask(const struct rte_flow_item *item)
case RTE_FLOW_ITEM_TYPE_AGGR_AFFINITY:
mask = &rte_flow_item_aggr_affinity_mask;
break;
+   case RTE_FLOW_ITEM_TYPE_TX_QUEUE:
+   mask = &rte_flow_item_tx_queue_mask;
+   break;
default:
break;
}
diff --git a/doc/guides/prog_guide/rte_flow.rst 
b/doc/guides/prog_guide/rte_flow.rst
index 32fc45516a..7154b56330 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1486,6 +1486,13 @@ This item is meant to use the same structure as `Item: 
PORT_REPRESENTOR`_.
 
 See also `Action: REPRESENTED_PORT`_.
 
+Item: ``TX_QUEUE``
+^^^
+
+Matches on the tx queue of send packet .
+
+- ``tx_queue``: Tx queue.
+
 Item: ``AGGR_AFFINITY``
 ^^^
 
diff --git a/doc/guides/rel_notes/release_23_07.rst 
b/doc/guides/rel_notes/release_23_07.rst
index a9b1293689..631cbd2b58 100644
--- a/doc/guides/rel_notes/release_23_07.rst
+++ b/doc/guides/rel_notes/release_23_07.rst
@@ -24,36 +24,9 @@ DPDK Release 23.07
 New Features
 
 
-.. This section should contain new features added in this release.
-   Sample format:
+* **Added flow matching of tx queue.**
 
-   * **Add a title in the past tense with a full stop.**
-
- Add a short 1-2 sentence description in the past tense.
- The description should be enough to allow someone scanning
- the release notes to understand the new feature.
-
- If the feature adds a lot of sub-features you can use a bullet list
- like this:
-
- * Added feature foo to do something.
- * Enhanced feature bar to do something else.
-
- Refer to the previous release notes for examples.
-
- Suggested order in release notes items:
- * Core libs (EAL, mempool, ring, mbuf, buses)
- * Device abstraction libs and PMDs (ordered alphabetically by vendor name)
-   - ethdev (lib, PMDs)
-   - cryptodev (lib, PMDs)
-   - eventdev (lib, PMDs)
-   - etc
- * Other libs
- * Apps, Examples, Tools (if significant)
-
- This section is a comment. Do not overwrite or remove it.
- Also, make sure to start the actual text at the margin.
- ===
+  Added ``RTE_FLOW_ITEM_TYPE_TX_QUEUE`` to match tx queue of send packet.
 
 
 Removed

[PATCH] doc: add PMD known issue

2023-04-19 Thread Mingjin Ye

Add a known issue: ASLR feature causes core dump.

Signed-off-by: Mingjin Ye 
---
 doc/guides/nics/ixgbe.rst | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/doc/guides/nics/ixgbe.rst b/doc/guides/nics/ixgbe.rst
index b1d77ab7ab..c346e377e2 100644
--- a/doc/guides/nics/ixgbe.rst
+++ b/doc/guides/nics/ixgbe.rst
@@ -461,3 +461,18 @@ show bypass config
 Show the bypass configuration for a bypass enabled NIC using the lowest port 
on the NIC::
 
testpmd> show bypass config (port_id)
+
+ASLR feature causes core dump
+~
+
+Core dump may occur when we start secondary processes on the vf port.
+Mainstream Linux distributions have the ASLR feature enabled by default,
+and the text segment of the process's memory space is randomized.
+The secondary process calls the function address shared by the primary
+process, resulting in a core dump.
+
+   .. Note::
+
+ Support for ASLR features varies by distribution. Redhat and
+ Centos series distributions work fine. Ubuntu distributions
+ will core dump, other Linux distributions are unknown.
-- 
2.25.1

[PATCH] net/ice: CVL support double vlan

2023-04-19 Thread Mingjin Ye

Aligned with kernel driver, optimized for inner and outer VLAN handling
in DPDK, and implemented double vlan insertion and stripping support.

1.adjust vlan stripping
Remove the judgment on dvm, vlan stripping only operates inner vlan.

2.support QinQ stripping
This patch support ice outer vlan strip on and off in QinQ mode with mask
bit of DEV_RX_OFFLOAD_QINQ_STRIP, users canuse "vlan set qinq_strip on 0"
to enable or "vlan setqinq_strip off 0" to disable ice outer vlan strip
when try with testpmd app.
Note: Due to hardware limitations, QinQ stripping containing two tagged RX
packets with the same EtherType (for example, two VLANs with EtherType =`
ETH_P_8021Q`) is not supported.

3.Support outer tag type switching
Add implementation of ethdev `vlan_tpid_set` api to enable Outer tags supp
-ort processing `ETH_P_8021Q` `ETH_P_8021AD` `ETH_P_QINQ1` outer tag types.

4.Support outer port insertion
If dvm is enabled, will support outer port vlan. User can use "tx_vlan set
pvid 0 45 on" to enable or "tx_vlan set pvid 0 45 off" to disable ice outer
vlan insertion try with testpmd app.

Signed-off-by: Mingjin Ye 
---
 drivers/net/ice/ice_ethdev.c | 427 +--
 drivers/net/ice/ice_ethdev.h |   1 +
 2 files changed, 414 insertions(+), 14 deletions(-)

diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
index 9a88cf9796..e4e22044ab 100644
--- a/drivers/net/ice/ice_ethdev.c
+++ b/drivers/net/ice/ice_ethdev.c
@@ -56,6 +56,24 @@ static const char * const ice_valid_args[] = {
 
 #define PPS_OUT_DELAY_NS  1
 
+/* Maximum number of VSI */
+#define ICE_MAX_NUM_VSIS  (768UL)
+
+/* The 119 bit offset of the LAN Rx queue context is the L2TSEL control bit. */
+#define ICE_L2TSEL_QRX_CONTEXT_REG_IDX 3
+#define ICE_L2TSEL_BIT_OFFSET 23
+enum ice_l2tsel {
+   ICE_L2TSEL_EXTRACT_FIRST_TAG_L2TAG2_2ND,
+   ICE_L2TSEL_EXTRACT_FIRST_TAG_L2TAG1,
+};
+
+/* 802.1Q VLAN Extended Header */
+#define ETH_P_8021Q0x8100
+/* 802.1ad Service VLAN */
+#define ETH_P_8021AD   0x88A8
+/* deprecated QinQ VLAN [ NOT AN OFFICIALLY REGISTERED ID ] */
+#define ETH_P_QINQ10x9100
+
 struct proto_xtr_ol_flag {
const struct rte_mbuf_dynflag param;
bool required;
@@ -130,6 +148,9 @@ static int ice_fw_version_get(struct rte_eth_dev *dev, char 
*fw_version,
  size_t fw_size);
 static int ice_vlan_pvid_set(struct rte_eth_dev *dev,
 uint16_t pvid, int on);
+static int ice_vlan_tpid_set(struct rte_eth_dev *dev,
+  enum rte_vlan_type vlan_type,
+  uint16_t tpid);
 static int ice_get_eeprom_length(struct rte_eth_dev *dev);
 static int ice_get_eeprom(struct rte_eth_dev *dev,
  struct rte_dev_eeprom_info *eeprom);
@@ -252,6 +273,7 @@ static const struct eth_dev_ops ice_eth_dev_ops = {
.rx_queue_intr_disable= ice_rx_queue_intr_disable,
.fw_version_get   = ice_fw_version_get,
.vlan_pvid_set= ice_vlan_pvid_set,
+   .vlan_tpid_set= ice_vlan_tpid_set,
.rxq_info_get = ice_rxq_info_get,
.txq_info_get = ice_txq_info_get,
.rx_burst_mode_get= ice_rx_burst_mode_get,
@@ -1588,6 +1610,9 @@ ice_setup_vsi(struct ice_pf *pf, enum ice_vsi_type type)
hw->func_caps.common_cap.rss_table_size;
pf->flags |= ICE_FLAG_RSS_AQ_CAPABLE;
 
+   /* Defines the type of outer tag expected */
+   pf->outer_ethertype = ETH_P_8021Q;
+
memset(&vsi_ctx, 0, sizeof(vsi_ctx));
switch (type) {
case ICE_VSI_PF:
@@ -1615,6 +1640,9 @@ ice_setup_vsi(struct ice_pf *pf, enum ice_vsi_type type)
(ICE_AQ_VSI_OUTER_TAG_VLAN_8100 <<
 ICE_AQ_VSI_OUTER_TAG_TYPE_S) &
ICE_AQ_VSI_OUTER_TAG_TYPE_M;
+   vsi_ctx.info.outer_vlan_flags |=
+   (ICE_AQ_VSI_OUTER_VLAN_EMODE_NOTHING <<
+   ICE_AQ_VSI_OUTER_VLAN_EMODE_S);
}
 
/* FDIR */
@@ -4431,11 +4459,87 @@ ice_vsi_dis_inner_stripping(struct ice_vsi *vsi)
return ice_vsi_manage_vlan_stripping(vsi, false);
 }
 
-static int ice_vsi_ena_outer_stripping(struct ice_vsi *vsi)
+/**
+ * tpid_to_vsi_outer_vlan_type - convert from TPID to VSI context based 
tag_type
+ * @tpid: tpid used to translate into VSI context based tag_type
+ * @tag_type: output variable to hold the VSI context based tag type
+ */
+static int tpid_to_vsi_outer_vlan_type(u16 tpid, u8 *tag_type)
+{
+   switch (tpid) {
+   case ETH_P_8021Q:
+   *tag_type = ICE_AQ_VSI_OUTER_TAG_VLAN_8100;
+   break;
+   case ETH_P_8021AD:
+   *tag_type = ICE_AQ_VSI_OUTER_TAG_STAG;
+   break;
+   case ETH_P_QINQ1:
+   *tag

[dpdk-dev] [PATCH v2] ring: fix use after free in ring release

2023-04-19 Thread Yunjian Wang

After the memzone is freed, it is not removed from the 'rte_ring_tailq'.
If rte_ring_lookup is called at this time, it will cause a use-after-free
problem. This change prevents that from happening.

Fixes: 4e32101f9b01 ("ring: support freeing")
Cc: sta...@dpdk.org

Suggested-by: Honnappa Nagarahalli 
Signed-off-by: Yunjian Wang 
---
v2: update code suggested by Honnappa Nagarahalli
---
 lib/ring/rte_ring.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/lib/ring/rte_ring.c b/lib/ring/rte_ring.c
index 8ed455043d..2755323b8a 100644
--- a/lib/ring/rte_ring.c
+++ b/lib/ring/rte_ring.c
@@ -333,11 +333,6 @@ rte_ring_free(struct rte_ring *r)
return;
}
 
-   if (rte_memzone_free(r->memzone) != 0) {
-   RTE_LOG(ERR, RING, "Cannot free memory\n");
-   return;
-   }
-
ring_list = RTE_TAILQ_CAST(rte_ring_tailq.head, rte_ring_list);
rte_mcfg_tailq_write_lock();
 
@@ -354,6 +349,9 @@ rte_ring_free(struct rte_ring *r)
 
TAILQ_REMOVE(ring_list, te, next);
 
+   if (rte_memzone_free(r->memzone) != 0)
+   RTE_LOG(ERR, RING, "Cannot free memory\n");
+
rte_mcfg_tailq_write_unlock();
 
rte_free(te);
-- 
2.33.0

RE: [dpdk-dev] [PATCH] ring: fix use after free in ring release

2023-04-19 Thread wangyunjian

> -Original Message-
> From: Honnappa Nagarahalli [mailto:honnappa.nagaraha...@arm.com]
> Sent: Thursday, April 20, 2023 5:44 AM
> To: wangyunjian ; dev@dpdk.org
> Cc: konstantin.v.anan...@yandex.ru; luyicai ;
> sta...@dpdk.org; nd ; nd 
> Subject: RE: [dpdk-dev] [PATCH] ring: fix use after free in ring release
> 
> 
> 
> > >
> > > > -Original Message-
> > > > From: Yunjian Wang 
> > > > Sent: Monday, April 17, 2023 8:12 AM
> > > > To: dev@dpdk.org
> > > > Cc: Honnappa Nagarahalli ;
> > > > konstantin.v.anan...@yandex.ru; luyi...@huawei.com; Yunjian Wang
> > > > ; sta...@dpdk.org
> > > > Subject: [dpdk-dev] [PATCH] ring: fix use after free in ring
> > > > release
> > > >
> > > > When using the ring to find out tailq entry, however it had been
> > > > freed by rte_memzone_free function. This change prevents that from
> > happening.
> > > I am unable to follow the problem you are describing.
> > > After the memzone for the ring is released, the contents of the
> > > memzone are not being used. I understand that the variable 'r' is
> > > being used, but that should not cause any issues.
> > >
> > > >
> > > > Fixes: 4e32101f9b01 ("ring: support freeing")
> > > > Cc: sta...@dpdk.org
> > > >
> > > > Signed-off-by: Yunjian Wang 
> > > > ---
> > > >  lib/ring/rte_ring.c | 11 +--
> > > >  1 file changed, 5 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/lib/ring/rte_ring.c b/lib/ring/rte_ring.c index
> > > > 8ed455043d..17d2d7f8a8 100644
> > > > --- a/lib/ring/rte_ring.c
> > > > +++ b/lib/ring/rte_ring.c
> > > > @@ -333,11 +333,6 @@ rte_ring_free(struct rte_ring *r)
> > > > return;
> > > > }
> > > >
> > > > -   if (rte_memzone_free(r->memzone) != 0) {
> > > > -   RTE_LOG(ERR, RING, "Cannot free memory\n");
> > > > -   return;
> > > > -   }
> > > Why do we need to free the memzone later?
> >
> > After the memzone is freed, it is not removed from the 'rte_ring_tailq'.
> > If rte_ring_lookup is called at this time, it will cause a use-after-free 
> > problem.
> Thanks, understood
> 
> >
> > Thanks,
> > Yunjian
> > >
> > > > -
> > > > ring_list = RTE_TAILQ_CAST(rte_ring_tailq.head, rte_ring_list);
> > > > rte_mcfg_tailq_write_lock();
> > > >
> > > > @@ -349,7 +344,7 @@ rte_ring_free(struct rte_ring *r)
> > > >
> > > > if (te == NULL) {
> > > > rte_mcfg_tailq_write_unlock();
> > > > -   return;
> > > > +   goto free_memzone;
> We do not need this. If 'te == NULL' is true, then the ring was not found or
> possibly already freed.

OK

> 
> > > > }
> > > >
> > > > TAILQ_REMOVE(ring_list, te, next); @@ -357,6 +352,10 @@
> > > > rte_ring_free(struct rte_ring *r)
> We should free the memzone here while holding the lock

OK, You are right. I fix it on your suggestions.

https://patchwork.dpdk.org/project/dpdk/patch/c23b1135e1b0676ef7d82969b39a21df992d418f.1681972694.git.wangyunj...@huawei.com/

Thanks,
Yunjian

> 
> > > > rte_mcfg_tailq_write_unlock();
> > > >
> > > > rte_free(te);
> > > > +
> > > > +free_memzone:
> > > > +   if (rte_memzone_free(r->memzone) != 0)
> > > > +   RTE_LOG(ERR, RING, "Cannot free memory\n");
> > > >  }
> Should be moved up as mentioned above
> 
> > > >
> > > >  /* dump the status of the ring on the console */
> > > > --
> > > > 2.33.0

[PATCH] doc: add PMD known issue

2023-04-19 Thread Mingjin Ye

Add a known issue: ASLR feature causes core dump.

Signed-off-by: Mingjin Ye 
---
 doc/guides/nics/ixgbe.rst | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/doc/guides/nics/ixgbe.rst b/doc/guides/nics/ixgbe.rst
index b1d77ab7ab..459d0d8380 100644
--- a/doc/guides/nics/ixgbe.rst
+++ b/doc/guides/nics/ixgbe.rst
@@ -461,3 +461,18 @@ show bypass config
 Show the bypass configuration for a bypass enabled NIC using the lowest port 
on the NIC::
 
testpmd> show bypass config (port_id)
+
+ASLR feature causes core dump
+~
+
+Core dump may occur when we start secondary processes on the vf port.
+Mainstream Linux distributions have the ASLR feature enabled by default,
+and the text segment of the process memory space is randomized.
+The secondary process calls the function address shared by the primary
+process, resulting in a core dump.
+
+   .. Note::
+
+ Support for ASLR features varies by distribution. Redhat and
+ Centos series distributions work fine. Ubuntu distributions
+ will core dump, other Linux distributions are unknown.
-- 
2.25.1

[PATCH] crypto/uadk: set queue pair in dev_configure

2023-04-19 Thread Zhangfei Gao

By default, uadk only alloc two queues for each algorithm, which
will impact performance.
Set queue pair number as required in dev_configure.
The default max queue pair number is 8, which can be modified
via para: max_nb_queue_pairs

Example:
sudo dpdk-test-crypto-perf -l 0-10 --vdev crypto_uadk,max_nb_queue_pairs=10
-- --devtype crypto_uadk --optype cipher-only --buffer-sz 8192

lcore idBuf Size  Burst Size  Gbps  Cycles/Buf

   38192  327.5226  871.19
   78192  327.5225  871.20
   18192  327.5225  871.20
   48192  327.5224  871.21
   58192  327.5224  871.21
  108192  327.5223  871.22
   98192  327.5223  871.23
   28192  327.5222  871.23
   88192  327.5222  871.23
   68192  327.5218  871.28

Signed-off-by: Zhangfei Gao 
---
 drivers/crypto/uadk/uadk_crypto_pmd.c | 19 +--
 drivers/crypto/uadk/uadk_crypto_pmd_private.h |  1 +
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/uadk/uadk_crypto_pmd.c 
b/drivers/crypto/uadk/uadk_crypto_pmd.c
index 4f729e0f07..34aae99342 100644
--- a/drivers/crypto/uadk/uadk_crypto_pmd.c
+++ b/drivers/crypto/uadk/uadk_crypto_pmd.c
@@ -357,8 +357,15 @@ static const struct rte_cryptodev_capabilities 
uadk_crypto_v2_capabilities[] = {
 /* Configure device */
 static int
 uadk_crypto_pmd_config(struct rte_cryptodev *dev __rte_unused,
-  struct rte_cryptodev_config *config __rte_unused)
+  struct rte_cryptodev_config *config)
 {
+   char env[128];
+
+   /* set queue pairs num via env */
+   sprintf(env, "sync:%d@0", config->nb_queue_pairs);
+   setenv("WD_CIPHER_CTX_NUM", env, 1);
+   setenv("WD_DIGEST_CTX_NUM", env, 1);
+
return 0;
 }
 
@@ -434,7 +441,7 @@ uadk_crypto_pmd_info_get(struct rte_cryptodev *dev,
if (dev_info != NULL) {
dev_info->driver_id = dev->driver_id;
dev_info->driver_name = dev->device->driver->name;
-   dev_info->max_nb_queue_pairs = 128;
+   dev_info->max_nb_queue_pairs = priv->max_nb_qpairs;
/* No limit of number of sessions */
dev_info->sym.max_nb_sessions = 0;
dev_info->feature_flags = dev->feature_flags;
@@ -1015,6 +1022,7 @@ uadk_cryptodev_probe(struct rte_vdev_device *vdev)
struct uadk_crypto_priv *priv;
struct rte_cryptodev *dev;
struct uacce_dev *udev;
+   const char *input_args;
const char *name;
 
udev = wd_get_accel_dev("cipher");
@@ -1030,6 +1038,9 @@ uadk_cryptodev_probe(struct rte_vdev_device *vdev)
if (name == NULL)
return -EINVAL;
 
+   input_args = rte_vdev_device_args(vdev);
+   rte_cryptodev_pmd_parse_input_args(&init_params, input_args);
+
dev = rte_cryptodev_pmd_create(name, &vdev->device, &init_params);
if (dev == NULL) {
UADK_LOG(ERR, "driver %s: create failed", init_params.name);
@@ -1044,6 +1055,7 @@ uadk_cryptodev_probe(struct rte_vdev_device *vdev)
 RTE_CRYPTODEV_FF_SYMMETRIC_CRYPTO;
priv = dev->data->dev_private;
priv->version = version;
+   priv->max_nb_qpairs = init_params.max_nb_queue_pairs;
 
rte_cryptodev_pmd_probing_finish(dev);
 
@@ -1078,4 +1090,7 @@ static struct cryptodev_driver uadk_crypto_drv;
 RTE_PMD_REGISTER_VDEV(UADK_CRYPTO_DRIVER_NAME, uadk_crypto_pmd);
 RTE_PMD_REGISTER_CRYPTO_DRIVER(uadk_crypto_drv, uadk_crypto_pmd.driver,
   uadk_cryptodev_driver_id);
+RTE_PMD_REGISTER_PARAM_STRING(UADK_CRYPTO_DRIVER_NAME,
+ "max_nb_queue_pairs= "
+ "socket_id=");
 RTE_LOG_REGISTER_DEFAULT(uadk_crypto_logtype, INFO);
diff --git a/drivers/crypto/uadk/uadk_crypto_pmd_private.h 
b/drivers/crypto/uadk/uadk_crypto_pmd_private.h
index 9075f0f058..5a7dbff117 100644
--- a/drivers/crypto/uadk/uadk_crypto_pmd_private.h
+++ b/drivers/crypto/uadk/uadk_crypto_pmd_private.h
@@ -67,6 +67,7 @@ struct uadk_crypto_priv {
bool env_cipher_init;
bool env_auth_init;
enum uadk_crypto_version version;
+   unsigned int max_nb_qpairs;
 } __rte_cache_aligned;
 
 extern int uadk_crypto_logtype;
-- 
2.39.2 (Apple Git-143)

68 matches

Mail list logo