Re: [PATCH] eal/linux: prevent deadlocks on rte init and cleanup

[Jonathan Erb]

David,

Thanks for the follow-up. The proposed patch below from Artemy will work 
for me.


Jonathan


On 9/29/23 10:32, David Marchand wrote:

Hello Jonathan,

On Thu, Jul 20, 2023 at 7:19 AM Jonathan Erb
  wrote:

Resolves a deadlock that can occur when multiple secondary
processes are starting and stopping. A deadlock can occur because
eal_memalloc_init() is taking a second unnecessary read lock.
If another DPDK process that is terminating enters rte_eal_memory_detach()
and acquires a write lock wait state before the starting process can
acquire it's second read lock then no process will be able to proceed.

Cc:sta...@dpdk.org

Signed-off-by: Jonathan Erb

Thanks for the report and fix and sorry for the late reply.

Artemy came with a similar report and a more complete fix.
Could you confirm it works for you?

https://patchwork.dpdk.org/project/dpdk/list/?series=29463&state=%2A&archive=both


Thanks,


--
Jonathan Erb
Software Engineer
*Phone:* 1.855.765.4925
jonathan@threatblockr.com 
threatblockr.com 
Threat Blockr Logo 

[PATCH v5 0/3] Introduce event link profiles

[pbhagavatula]

From: Pavan Nikhilesh 

A collection of event queues linked to an event port can be associated
with unique identifier called as a link profile, multiple such profiles
can be configured based on the event device capability using the function
`rte_event_port_profile_links_set` which takes arguments similar to
`rte_event_port_link` in addition to the profile identifier.

The maximum link profiles that are supported by an event device is
advertised through the structure member
`rte_event_dev_info::max_profiles_per_port`.

By default, event ports are configured to use the link profile 0 on
initialization.

Once multiple link profiles are set up and the event device is started, the
application can use the function `rte_event_port_profile_switch` to change
the currently active profile on an event port. This effects the next
`rte_event_dequeue_burst` call, where the event queues associated with the
newly active link profile will participate in scheduling.

Rudementary work flow would something like:

Config path:

uint8_t lq[4] = {4, 5, 6, 7};
uint8_t hq[4] = {0, 1, 2, 3};

if (rte_event_dev_info.max_profiles_per_port < 2)
return -ENOTSUP;

rte_event_port_profile_links_set(0, 0, hq, NULL, 4, 0);
rte_event_port_profile_links_set(0, 0, lq, NULL, 4, 1);

Worker path:

empty_high_deq = 0;
empty_low_deq = 0;
is_low_deq = 0;
while (1) {
deq = rte_event_dequeue_burst(0, 0, &ev, 1, 0);
if (deq == 0) {
/**
 * Change link profile based on work activity on current
 * active profile
 */
if (is_low_deq) {
empty_low_deq++;
if (empty_low_deq == MAX_LOW_RETRY) {
rte_event_port_profile_switch(0, 0, 0);
is_low_deq = 0;
empty_low_deq = 0;
}
continue;
}

if (empty_high_deq == MAX_HIGH_RETRY) {
rte_event_port_profile_switch(0, 0, 1);
is_low_deq = 1;
empty_high_deq = 0;
}
continue;
}

// Process the event received.

if (is_low_deq++ == MAX_LOW_EVENTS) {
rte_event_port_profile_switch(0, 0, 0);
is_low_deq = 0;
}
}

An application could use heuristic data of load/activity of a given event
port and change its active profile to adapt to the traffic pattern.

An unlink function `rte_event_port_profile_unlink` is provided to
modify the links associated to a profile, and
`rte_event_port_profile_links_get` can be used to retrieve the links
associated with a profile.

Using Link profiles can reduce the overhead of linking/unlinking and
waiting for unlinks in progress in fast-path and gives applications
the ability to switch between preset profiles on the fly.

v5 Changes:
--
- Rebase on next-event

v4 Changes:
--
- Address review comments (Jerin).

v3 Changes:
--
- Rebase to next-eventdev
- Rename testcase name to match API.

v2 Changes:
--
- Fix compilation.

Pavan Nikhilesh (3):
  eventdev: introduce link profiles
  event/cnxk: implement event link profiles
  test/event: add event link profile test

 app/test/test_eventdev.c  | 117 +++
 config/rte_config.h   |   1 +
 doc/guides/eventdevs/cnxk.rst |   1 +
 doc/guides/eventdevs/features/cnxk.ini|   3 +-
 doc/guides/eventdevs/features/default.ini |   1 +
 doc/guides/prog_guide/eventdev.rst|  40 
 doc/guides/rel_notes/release_23_11.rst|  13 ++
 drivers/common/cnxk/roc_nix_inl_dev.c |   4 +-
 drivers/common/cnxk/roc_sso.c |  18 +-
 drivers/common/cnxk/roc_sso.h |   8 +-
 drivers/common/cnxk/roc_sso_priv.h|   4 +-
 drivers/event/cnxk/cn10k_eventdev.c   |  45 +++--
 drivers/event/cnxk/cn10k_worker.c |  11 ++
 drivers/event/cnxk/cn10k_worker.h |   1 +
 drivers/event/cnxk/cn9k_eventdev.c|  74 ---
 drivers/event/cnxk/cn9k_worker.c  |  22 +++
 drivers/event/cnxk/cn9k_worker.h  |   2 +
 drivers/event/cnxk/cnxk_eventdev.c|  37 ++--
 drivers/event/cnxk/cnxk_eventdev.h|  10 +-
 lib/eventdev/eventdev_pmd.h   |  59 +-
 lib/eventdev/eventdev_private.c   |   9 +
 lib/eventdev/eventdev_trace.h |  32 +++
 lib/eventdev/eventdev_trace_points.c  |  12 ++
 lib/eventdev/rte_eventdev.c   | 150 +++---
 lib/eventdev/rte_eventdev.h   | 231 ++
 lib/eventdev/rte_eventdev_core.h  |   5 +
 lib/eventdev/rte_eventdev_trace_fp.h  |   8 +
 lib/eventdev/version.map  |   4 +
 28 files changed, 813 insertions(+), 109 deletions(-)

--
2.25.1

[PATCH v5 1/3] eventdev: introduce link profiles

[pbhagavatula]

From: Pavan Nikhilesh 

A collection of event queues linked to an event port can be
associated with a unique identifier called as a link profile, multiple
such profiles can be created based on the event device capability
using the function `rte_event_port_profile_links_set` which takes
arguments similar to `rte_event_port_link` in addition to the profile
identifier.

The maximum link profiles that are supported by an event device
is advertised through the structure member
`rte_event_dev_info::max_profiles_per_port`.
By default, event ports are configured to use the link profile 0
on initialization.

Once multiple link profiles are set up and the event device is started,
the application can use the function `rte_event_port_profile_switch`
to change the currently active profile on an event port. This effects
the next `rte_event_dequeue_burst` call, where the event queues
associated with the newly active link profile will participate in
scheduling.

An unlink function `rte_event_port_profile_unlink` is provided
to modify the links associated to a profile, and
`rte_event_port_profile_links_get` can be used to retrieve the
links associated with a profile.

Using Link profiles can reduce the overhead of linking/unlinking and
waiting for unlinks in progress in fast-path and gives applications
the ability to switch between preset profiles on the fly.

Signed-off-by: Pavan Nikhilesh 
Acked-by: Jerin Jacob 
---
 config/rte_config.h   |   1 +
 doc/guides/eventdevs/features/default.ini |   1 +
 doc/guides/prog_guide/eventdev.rst|  40 
 doc/guides/rel_notes/release_23_11.rst|  11 ++
 lib/eventdev/eventdev_pmd.h   |  59 +-
 lib/eventdev/eventdev_private.c   |   9 +
 lib/eventdev/eventdev_trace.h |  32 +++
 lib/eventdev/eventdev_trace_points.c  |  12 ++
 lib/eventdev/rte_eventdev.c   | 150 +++---
 lib/eventdev/rte_eventdev.h   | 231 ++
 lib/eventdev/rte_eventdev_core.h  |   5 +
 lib/eventdev/rte_eventdev_trace_fp.h  |   8 +
 lib/eventdev/version.map  |   4 +
 13 files changed, 535 insertions(+), 28 deletions(-)

diff --git a/config/rte_config.h b/config/rte_config.h
index 401727703f..a06189d0b5 100644
--- a/config/rte_config.h
+++ b/config/rte_config.h
@@ -73,6 +73,7 @@
 #define RTE_EVENT_MAX_DEVS 16
 #define RTE_EVENT_MAX_PORTS_PER_DEV 255
 #define RTE_EVENT_MAX_QUEUES_PER_DEV 255
+#define RTE_EVENT_MAX_PROFILES_PER_PORT 8
 #define RTE_EVENT_TIMER_ADAPTER_NUM_MAX 32
 #define RTE_EVENT_ETH_INTR_RING_SIZE 1024
 #define RTE_EVENT_CRYPTO_ADAPTER_MAX_INSTANCE 32
diff --git a/doc/guides/eventdevs/features/default.ini 
b/doc/guides/eventdevs/features/default.ini
index 73a52d915b..e980ae134a 100644
--- a/doc/guides/eventdevs/features/default.ini
+++ b/doc/guides/eventdevs/features/default.ini
@@ -18,6 +18,7 @@ multiple_queue_port=
 carry_flow_id  =
 maintenance_free   =
 runtime_queue_attr =
+profile_links  =
 
 ;
 ; Features of a default Ethernet Rx adapter.
diff --git a/doc/guides/prog_guide/eventdev.rst 
b/doc/guides/prog_guide/eventdev.rst
index ff55115d0d..8c15c678bf 100644
--- a/doc/guides/prog_guide/eventdev.rst
+++ b/doc/guides/prog_guide/eventdev.rst
@@ -317,6 +317,46 @@ can be achieved like this:
 }
 int links_made = rte_event_port_link(dev_id, tx_port_id, 
&single_link_q, &priority, 1);
 
+Linking Queues to Ports with link profiles
+~~
+
+An application can use link profiles if supported by the underlying event 
device to setup up
+multiple link profile per port and change them run time depending up on 
heuristic data.
+Using Link profiles can reduce the overhead of linking/unlinking and wait for 
unlinks in progress
+in fast-path and gives applications the ability to switch between preset 
profiles on the fly.
+
+An Example use case could be as follows.
+
+Config path:
+
+.. code-block:: c
+
+uint8_t lq[4] = {4, 5, 6, 7};
+uint8_t hq[4] = {0, 1, 2, 3};
+
+if (rte_event_dev_info.max_profiles_per_port < 2)
+return -ENOTSUP;
+
+rte_event_port_profile_links_set(0, 0, hq, NULL, 4, 0);
+rte_event_port_profile_links_set(0, 0, lq, NULL, 4, 1);
+
+Worker path:
+
+.. code-block:: c
+
+uint8_t profile_id_to_switch;
+
+while (1) {
+deq = rte_event_dequeue_burst(0, 0, &ev, 1, 0);
+if (deq == 0) {
+profile_id_to_switch = app_find_profile_id_to_switch();
+rte_event_port_profile_switch(0, 0, profile_id_to_switch);
+continue;
+}
+
+// Process the event received.
+}
+
 Starting the EventDev
 ~
 
diff --git a/doc/guides/rel_notes/release_23_11.rst 
b/doc/guides/rel_notes/release_23_11.rst
index b66c364e21..fe6656bed2 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_no

[PATCH v5 2/3] event/cnxk: implement event link profiles

[pbhagavatula]

From: Pavan Nikhilesh 

Implement event link profiles support on CN10K and CN9K.
Both the platforms support up to 2 link profiles.

Signed-off-by: Pavan Nikhilesh 
---
 doc/guides/eventdevs/cnxk.rst  |  1 +
 doc/guides/eventdevs/features/cnxk.ini |  3 +-
 doc/guides/rel_notes/release_23_11.rst |  2 +
 drivers/common/cnxk/roc_nix_inl_dev.c  |  4 +-
 drivers/common/cnxk/roc_sso.c  | 18 +++
 drivers/common/cnxk/roc_sso.h  |  8 +--
 drivers/common/cnxk/roc_sso_priv.h |  4 +-
 drivers/event/cnxk/cn10k_eventdev.c| 45 +++-
 drivers/event/cnxk/cn10k_worker.c  | 11 
 drivers/event/cnxk/cn10k_worker.h  |  1 +
 drivers/event/cnxk/cn9k_eventdev.c | 74 --
 drivers/event/cnxk/cn9k_worker.c   | 22 
 drivers/event/cnxk/cn9k_worker.h   |  2 +
 drivers/event/cnxk/cnxk_eventdev.c | 37 +++--
 drivers/event/cnxk/cnxk_eventdev.h | 10 ++--
 15 files changed, 161 insertions(+), 81 deletions(-)

diff --git a/doc/guides/eventdevs/cnxk.rst b/doc/guides/eventdevs/cnxk.rst
index 1a59233282..cccb8a0304 100644
--- a/doc/guides/eventdevs/cnxk.rst
+++ b/doc/guides/eventdevs/cnxk.rst
@@ -48,6 +48,7 @@ Features of the OCTEON cnxk SSO PMD are:
 - HW managed event vectorization on CN10K for packets enqueued from ethdev to
   eventdev configurable per each Rx queue in Rx adapter.
 - Event vector transmission via Tx adapter.
+- Up to 2 event link profiles.
 
 Prerequisites and Compilation procedure
 ---
diff --git a/doc/guides/eventdevs/features/cnxk.ini 
b/doc/guides/eventdevs/features/cnxk.ini
index bee69bf8f4..5d353e3670 100644
--- a/doc/guides/eventdevs/features/cnxk.ini
+++ b/doc/guides/eventdevs/features/cnxk.ini
@@ -12,7 +12,8 @@ runtime_port_link  = Y
 multiple_queue_port= Y
 carry_flow_id  = Y
 maintenance_free   = Y
-runtime_queue_attr = y
+runtime_queue_attr = Y
+profile_links  = Y
 
 [Eth Rx adapter Features]
 internal_port  = Y
diff --git a/doc/guides/rel_notes/release_23_11.rst 
b/doc/guides/rel_notes/release_23_11.rst
index fe6656bed2..66c4ddf37c 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -105,6 +105,8 @@ New Features
 
   * Added support for ``remaining_ticks_get`` timer adapter PMD callback
 to get the remaining ticks to expire for a given event timer.
+  * Added link profiles support for Marvell CNXK event device driver,
+up to two link profiles are supported per event port.
 
 
 Removed Items
diff --git a/drivers/common/cnxk/roc_nix_inl_dev.c 
b/drivers/common/cnxk/roc_nix_inl_dev.c
index d76158e30d..690d47c045 100644
--- a/drivers/common/cnxk/roc_nix_inl_dev.c
+++ b/drivers/common/cnxk/roc_nix_inl_dev.c
@@ -285,7 +285,7 @@ nix_inl_sso_setup(struct nix_inl_dev *inl_dev)
}
 
/* Setup hwgrp->hws link */
-   sso_hws_link_modify(0, inl_dev->ssow_base, NULL, hwgrp, 1, true);
+   sso_hws_link_modify(0, inl_dev->ssow_base, NULL, hwgrp, 1, 0, true);
 
/* Enable HWGRP */
plt_write64(0x1, inl_dev->sso_base + SSO_LF_GGRP_QCTL);
@@ -315,7 +315,7 @@ nix_inl_sso_release(struct nix_inl_dev *inl_dev)
nix_inl_sso_unregister_irqs(inl_dev);
 
/* Unlink hws */
-   sso_hws_link_modify(0, inl_dev->ssow_base, NULL, hwgrp, 1, false);
+   sso_hws_link_modify(0, inl_dev->ssow_base, NULL, hwgrp, 1, 0, false);
 
/* Release XAQ aura */
sso_hwgrp_release_xaq(&inl_dev->dev, 1);
diff --git a/drivers/common/cnxk/roc_sso.c b/drivers/common/cnxk/roc_sso.c
index c37da685da..748d287bad 100644
--- a/drivers/common/cnxk/roc_sso.c
+++ b/drivers/common/cnxk/roc_sso.c
@@ -186,8 +186,8 @@ sso_rsrc_get(struct roc_sso *roc_sso)
 }
 
 void
-sso_hws_link_modify(uint8_t hws, uintptr_t base, struct plt_bitmap *bmp,
-   uint16_t hwgrp[], uint16_t n, uint16_t enable)
+sso_hws_link_modify(uint8_t hws, uintptr_t base, struct plt_bitmap *bmp, 
uint16_t hwgrp[],
+   uint16_t n, uint8_t set, uint16_t enable)
 {
uint64_t reg;
int i, j, k;
@@ -204,7 +204,7 @@ sso_hws_link_modify(uint8_t hws, uintptr_t base, struct 
plt_bitmap *bmp,
k = n % 4;
k = k ? k : 4;
for (j = 0; j < k; j++) {
-   mask[j] = hwgrp[i + j] | enable << 14;
+   mask[j] = hwgrp[i + j] | (uint32_t)set << 12 | enable 
<< 14;
if (bmp) {
enable ? plt_bitmap_set(bmp, hwgrp[i + j]) :
 plt_bitmap_clear(bmp, hwgrp[i + j]);
@@ -290,8 +290,8 @@ roc_sso_ns_to_gw(struct roc_sso *roc_sso, uint64_t ns)
 }
 
 int
-roc_sso_hws_link(struct roc_sso *roc_sso, uint8_t hws, uint16_t hwgrp[],
-uint16_t nb_hwgrp)
+roc_sso_hws_link(struct roc_sso *roc_sso, uint8_t hws, uint16_t hwgrp[], 
uint16_t nb_hwgrp,
+uin

[PATCH v5 3/3] test/event: add event link profile test

[pbhagavatula]

From: Pavan Nikhilesh 

Add test case to verify event link profiles.

Signed-off-by: Pavan Nikhilesh 
---
 app/test/test_eventdev.c | 117 +++
 1 file changed, 117 insertions(+)

diff --git a/app/test/test_eventdev.c b/app/test/test_eventdev.c
index c51c93bdbd..0ecfa7db02 100644
--- a/app/test/test_eventdev.c
+++ b/app/test/test_eventdev.c
@@ -1129,6 +1129,121 @@ test_eventdev_link_get(void)
return TEST_SUCCESS;
 }
 
+static int
+test_eventdev_profile_switch(void)
+{
+#define MAX_RETRIES   4
+   uint8_t priorities[RTE_EVENT_MAX_QUEUES_PER_DEV];
+   uint8_t queues[RTE_EVENT_MAX_QUEUES_PER_DEV];
+   struct rte_event_queue_conf qcfg;
+   struct rte_event_port_conf pcfg;
+   struct rte_event_dev_info info;
+   struct rte_event ev;
+   uint8_t q, re;
+   int rc;
+
+   rte_event_dev_info_get(TEST_DEV_ID, &info);
+
+   if (info.max_profiles_per_port <= 1)
+   return TEST_SKIPPED;
+
+   if (info.max_event_queues <= 1)
+   return TEST_SKIPPED;
+
+   rc = rte_event_port_default_conf_get(TEST_DEV_ID, 0, &pcfg);
+   TEST_ASSERT_SUCCESS(rc, "Failed to get port0 default config");
+   rc = rte_event_port_setup(TEST_DEV_ID, 0, &pcfg);
+   TEST_ASSERT_SUCCESS(rc, "Failed to setup port0");
+
+   rc = rte_event_queue_default_conf_get(TEST_DEV_ID, 0, &qcfg);
+   TEST_ASSERT_SUCCESS(rc, "Failed to get queue0 default config");
+   rc = rte_event_queue_setup(TEST_DEV_ID, 0, &qcfg);
+   TEST_ASSERT_SUCCESS(rc, "Failed to setup queue0");
+
+   q = 0;
+   rc = rte_event_port_profile_links_set(TEST_DEV_ID, 0, &q, NULL, 1, 0);
+   TEST_ASSERT(rc == 1, "Failed to link queue 0 to port 0 with profile 0");
+   q = 1;
+   rc = rte_event_port_profile_links_set(TEST_DEV_ID, 0, &q, NULL, 1, 1);
+   TEST_ASSERT(rc == 1, "Failed to link queue 1 to port 0 with profile 1");
+
+   rc = rte_event_port_profile_links_get(TEST_DEV_ID, 0, queues, 
priorities, 0);
+   TEST_ASSERT(rc == 1, "Failed to links");
+   TEST_ASSERT(queues[0] == 0, "Invalid queue found in link");
+
+   rc = rte_event_port_profile_links_get(TEST_DEV_ID, 0, queues, 
priorities, 1);
+   TEST_ASSERT(rc == 1, "Failed to links");
+   TEST_ASSERT(queues[0] == 1, "Invalid queue found in link");
+
+   rc = rte_event_dev_start(TEST_DEV_ID);
+   TEST_ASSERT_SUCCESS(rc, "Failed to start event device");
+
+   ev.event_type = RTE_EVENT_TYPE_CPU;
+   ev.queue_id = 0;
+   ev.op = RTE_EVENT_OP_NEW;
+   ev.flow_id = 0;
+   ev.u64 = 0xBADF00D0;
+   rc = rte_event_enqueue_burst(TEST_DEV_ID, 0, &ev, 1);
+   TEST_ASSERT(rc == 1, "Failed to enqueue event");
+   ev.queue_id = 1;
+   ev.flow_id = 1;
+   rc = rte_event_enqueue_burst(TEST_DEV_ID, 0, &ev, 1);
+   TEST_ASSERT(rc == 1, "Failed to enqueue event");
+
+   ev.event = 0;
+   ev.u64 = 0;
+
+   rc = rte_event_port_profile_switch(TEST_DEV_ID, 0, 1);
+   TEST_ASSERT_SUCCESS(rc, "Failed to change profile");
+
+   re = MAX_RETRIES;
+   while (re--) {
+   rc = rte_event_dequeue_burst(TEST_DEV_ID, 0, &ev, 1, 0);
+   printf("rc %d\n", rc);
+   if (rc)
+   break;
+   }
+
+   TEST_ASSERT(rc == 1, "Failed to dequeue event from profile 1");
+   TEST_ASSERT(ev.flow_id == 1, "Incorrect flow identifier from profile 
1");
+   TEST_ASSERT(ev.queue_id == 1, "Incorrect queue identifier from profile 
1");
+
+   re = MAX_RETRIES;
+   while (re--) {
+   rc = rte_event_dequeue_burst(TEST_DEV_ID, 0, &ev, 1, 0);
+   TEST_ASSERT(rc == 0, "Unexpected event dequeued from active 
profile");
+   }
+
+   rc = rte_event_port_profile_switch(TEST_DEV_ID, 0, 0);
+   TEST_ASSERT_SUCCESS(rc, "Failed to change profile");
+
+   re = MAX_RETRIES;
+   while (re--) {
+   rc = rte_event_dequeue_burst(TEST_DEV_ID, 0, &ev, 1, 0);
+   if (rc)
+   break;
+   }
+
+   TEST_ASSERT(rc == 1, "Failed to dequeue event from profile 1");
+   TEST_ASSERT(ev.flow_id == 0, "Incorrect flow identifier from profile 
0");
+   TEST_ASSERT(ev.queue_id == 0, "Incorrect queue identifier from profile 
0");
+
+   re = MAX_RETRIES;
+   while (re--) {
+   rc = rte_event_dequeue_burst(TEST_DEV_ID, 0, &ev, 1, 0);
+   TEST_ASSERT(rc == 0, "Unexpected event dequeued from active 
profile");
+   }
+
+   q = 0;
+   rc = rte_event_port_profile_unlink(TEST_DEV_ID, 0, &q, 1, 0);
+   TEST_ASSERT(rc == 1, "Failed to unlink queue 0 to port 0 with profile 
0");
+   q = 1;
+   rc = rte_event_port_profile_unlink(TEST_DEV_ID, 0, &q, 1, 1);
+   TEST_ASSERT(rc == 1, "Failed to unlink queue 1 to port 0 with profile 
1");
+
+   return TEST_SUCCESS;
+}
+
 static int
 test_eventdev_close(void)
 {
@@ -1187,6 +1302,8 @@ static struct u

RE: [PATCH 1/2] event/sw: add self tests to fast tests

[Van Haaren, Harry]

> -Original Message-
> From: Jerin Jacob 
> Sent: Tuesday, October 3, 2023 7:23 AM
> To: Richardson, Bruce ; Van Haaren, Harry
> 
> Cc: dev@dpdk.org
> Subject: Re: [PATCH 1/2] event/sw: add self tests to fast tests
> 
> On Thu, Sep 28, 2023 at 9:01 PM Bruce Richardson
>  wrote:
> >
> > By reducing the iterations for the final stage of the self-test, the SW
> > eventdev tests can be fast enough for consideration in the fast-tests
> > suite. This enables them to be run as part of the regular patch CI
> > tests, and therefore increases the chances of catching any errors in
> > patches that may affect this component.
> >
> > Signed-off-by: Bruce Richardson 
> 
> Looks like  --to-cmd ./scripts/get_maintainer.pl not used in sending patches.
> @Van Haaren, Harry  Could you review and Ack it to merge?

Thanks for the loop-in Jerin,

Acked-by: Harry van Haaren 

Re: [PATCH v4] net/af_xdp: fix missing UMEM feature

[Ferruh Yigit]

On 10/2/2023 2:23 PM, Bruce Richardson wrote:
> On Mon, Oct 02, 2023 at 02:15:51PM +0100, Ferruh Yigit wrote:
>> On 10/2/2023 2:01 PM, Bruce Richardson wrote:
>>> On Mon, Oct 02, 2023 at 12:48:52PM +, Shibin Koikkara Reeny wrote:
 Shared UMEM feature is missing in the af_xdp driver build
 after the commit 33d66940e9ba ("build: use C11 standard").

 Runtime Error log while using Shared UMEM feature:
 rte_pmd_af_xdp_probe(): Initializing pmd_af_xdp for net_af_xdp0
 init_internals(): Shared UMEM feature not available. Check kernel
 and libbpf version
 rte_pmd_af_xdp_probe(): Failed to init internals
 vdev_probe(): failed to initialize net_af_xdp0 device
 EAL: Bus (vdev) probe failed.

 Reason for the missing UMEM feature is because the C11 standard
 doesn't include the GNU compiler extensions typeof and asm, used
 by the libbpf and libxdp header files.

 Meson error log:
  In file included from
 dpdk/build/meson-private/tmpf74nkhqd/testfile.c:5:
 /usr/local/include/bpf/xsk.h: In function 'xsk_prod_nb_free':
 /usr/local/include/bpf/xsk.h:165:26: error: expected ';' before '___p1'
   165 | r->cached_cons = libbpf_smp_load_acquire(r->consumer);
   |  ^~~
 /usr/local/include/bpf/xsk.h:165:26: error: 'asm' undeclared (first use
 in this function)
 ...
 /usr/local/include/bpf/xsk.h:199:9: error: unknown type name 'typeof'
   199 | libbpf_smp_store_release(prod->producer, *prod->producer
   + nb);
   | ^~~~

 Fix is to provide alternative keywords by using macros [1].

 Fixes: 33d66940e9ba ("build: use C11 standard")

 [1] https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html

 v4: Updated the commit message.
 v3: Used alternative keywords fix.
 v2: Added original commit causing the issue.

 Signed-off-by: Shibin Koikkara Reeny 
>>>
>>> Reviewed-by: Bruce Richardson 
>>>
>>
>> I already merged the v3, and updated the commit log while merging,
>> can you please check the next-net [1] if the commit log is good as it is?
>>
>> [1]
>> https://git.dpdk.org/next/dpdk-next-net/commit/?id=a499de2602df505e0313ae468817863b29f2311e
>>
> 
> LGTM anyway. 
>

Shibin, if you also don't have any objection, I will keep the merged
version as it is.

[PATCH v6 0/3] Introduce event link profiles

[pbhagavatula]

From: Pavan Nikhilesh 

A collection of event queues linked to an event port can be associated
with unique identifier called as a link profile, multiple such profiles
can be configured based on the event device capability using the function
`rte_event_port_profile_links_set` which takes arguments similar to
`rte_event_port_link` in addition to the profile identifier.

The maximum link profiles that are supported by an event device is
advertised through the structure member
`rte_event_dev_info::max_profiles_per_port`.

By default, event ports are configured to use the link profile 0 on
initialization.

Once multiple link profiles are set up and the event device is started, the
application can use the function `rte_event_port_profile_switch` to change
the currently active profile on an event port. This effects the next
`rte_event_dequeue_burst` call, where the event queues associated with the
newly active link profile will participate in scheduling.

Rudementary work flow would something like:

Config path:

uint8_t lq[4] = {4, 5, 6, 7};
uint8_t hq[4] = {0, 1, 2, 3};

if (rte_event_dev_info.max_profiles_per_port < 2)
return -ENOTSUP;

rte_event_port_profile_links_set(0, 0, hq, NULL, 4, 0);
rte_event_port_profile_links_set(0, 0, lq, NULL, 4, 1);

Worker path:

empty_high_deq = 0;
empty_low_deq = 0;
is_low_deq = 0;
while (1) {
deq = rte_event_dequeue_burst(0, 0, &ev, 1, 0);
if (deq == 0) {
/**
 * Change link profile based on work activity on current
 * active profile
 */
if (is_low_deq) {
empty_low_deq++;
if (empty_low_deq == MAX_LOW_RETRY) {
rte_event_port_profile_switch(0, 0, 0);
is_low_deq = 0;
empty_low_deq = 0;
}
continue;
}

if (empty_high_deq == MAX_HIGH_RETRY) {
rte_event_port_profile_switch(0, 0, 1);
is_low_deq = 1;
empty_high_deq = 0;
}
continue;
}

// Process the event received.

if (is_low_deq++ == MAX_LOW_EVENTS) {
rte_event_port_profile_switch(0, 0, 0);
is_low_deq = 0;
}
}

An application could use heuristic data of load/activity of a given event
port and change its active profile to adapt to the traffic pattern.

An unlink function `rte_event_port_profile_unlink` is provided to
modify the links associated to a profile, and
`rte_event_port_profile_links_get` can be used to retrieve the links
associated with a profile.

Using Link profiles can reduce the overhead of linking/unlinking and
waiting for unlinks in progress in fast-path and gives applications
the ability to switch between preset profiles on the fly.

v6 Changes:
--
- Fix compilation.

v5 Changes:
--
- Rebase on next-event

v4 Changes:
--
- Address review comments (Jerin).

v3 Changes:
--
- Rebase to next-eventdev
- Rename testcase name to match API.

v2 Changes:
--
- Fix compilation.

Pavan Nikhilesh (3):
  eventdev: introduce link profiles
  event/cnxk: implement event link profiles
  test/event: add event link profile test

 app/test/test_eventdev.c  | 117 +++
 config/rte_config.h   |   1 +
 doc/guides/eventdevs/cnxk.rst |   1 +
 doc/guides/eventdevs/features/cnxk.ini|   3 +-
 doc/guides/eventdevs/features/default.ini |   1 +
 doc/guides/prog_guide/eventdev.rst|  40 
 doc/guides/rel_notes/release_23_11.rst|  13 ++
 drivers/common/cnxk/roc_nix_inl_dev.c |   4 +-
 drivers/common/cnxk/roc_sso.c |  18 +-
 drivers/common/cnxk/roc_sso.h |   8 +-
 drivers/common/cnxk/roc_sso_priv.h|   4 +-
 drivers/event/cnxk/cn10k_eventdev.c   |  45 +++--
 drivers/event/cnxk/cn10k_worker.c |  11 ++
 drivers/event/cnxk/cn10k_worker.h |   1 +
 drivers/event/cnxk/cn9k_eventdev.c|  74 ---
 drivers/event/cnxk/cn9k_worker.c  |  22 +++
 drivers/event/cnxk/cn9k_worker.h  |   2 +
 drivers/event/cnxk/cnxk_eventdev.c|  37 ++--
 drivers/event/cnxk/cnxk_eventdev.h|  10 +-
 lib/eventdev/eventdev_pmd.h   |  59 +-
 lib/eventdev/eventdev_private.c   |   9 +
 lib/eventdev/eventdev_trace.h |  32 +++
 lib/eventdev/eventdev_trace_points.c  |  12 ++
 lib/eventdev/rte_eventdev.c   | 150 +++---
 lib/eventdev/rte_eventdev.h   | 231 ++
 lib/eventdev/rte_eventdev_core.h  |   5 +
 lib/eventdev/rte_eventdev_trace_fp.h  |   8 +
 lib/eventdev/version.map  |   4 +
 28 files changed, 813 insertions(+), 109 deletions(-)

--
2.25.1

[PATCH v6 1/3] eventdev: introduce link profiles

[pbhagavatula]

From: Pavan Nikhilesh 

A collection of event queues linked to an event port can be
associated with a unique identifier called as a link profile, multiple
such profiles can be created based on the event device capability
using the function `rte_event_port_profile_links_set` which takes
arguments similar to `rte_event_port_link` in addition to the profile
identifier.

The maximum link profiles that are supported by an event device
is advertised through the structure member
`rte_event_dev_info::max_profiles_per_port`.
By default, event ports are configured to use the link profile 0
on initialization.

Once multiple link profiles are set up and the event device is started,
the application can use the function `rte_event_port_profile_switch`
to change the currently active profile on an event port. This effects
the next `rte_event_dequeue_burst` call, where the event queues
associated with the newly active link profile will participate in
scheduling.

An unlink function `rte_event_port_profile_unlink` is provided
to modify the links associated to a profile, and
`rte_event_port_profile_links_get` can be used to retrieve the
links associated with a profile.

Using Link profiles can reduce the overhead of linking/unlinking and
waiting for unlinks in progress in fast-path and gives applications
the ability to switch between preset profiles on the fly.

Signed-off-by: Pavan Nikhilesh 
Acked-by: Jerin Jacob 
---
 config/rte_config.h   |   1 +
 doc/guides/eventdevs/features/default.ini |   1 +
 doc/guides/prog_guide/eventdev.rst|  40 
 doc/guides/rel_notes/release_23_11.rst|  11 ++
 drivers/event/cnxk/cnxk_eventdev.c|   2 +-
 lib/eventdev/eventdev_pmd.h   |  59 +-
 lib/eventdev/eventdev_private.c   |   9 +
 lib/eventdev/eventdev_trace.h |  32 +++
 lib/eventdev/eventdev_trace_points.c  |  12 ++
 lib/eventdev/rte_eventdev.c   | 150 +++---
 lib/eventdev/rte_eventdev.h   | 231 ++
 lib/eventdev/rte_eventdev_core.h  |   5 +
 lib/eventdev/rte_eventdev_trace_fp.h  |   8 +
 lib/eventdev/version.map  |   4 +
 14 files changed, 536 insertions(+), 29 deletions(-)

diff --git a/config/rte_config.h b/config/rte_config.h
index 401727703f..a06189d0b5 100644
--- a/config/rte_config.h
+++ b/config/rte_config.h
@@ -73,6 +73,7 @@
 #define RTE_EVENT_MAX_DEVS 16
 #define RTE_EVENT_MAX_PORTS_PER_DEV 255
 #define RTE_EVENT_MAX_QUEUES_PER_DEV 255
+#define RTE_EVENT_MAX_PROFILES_PER_PORT 8
 #define RTE_EVENT_TIMER_ADAPTER_NUM_MAX 32
 #define RTE_EVENT_ETH_INTR_RING_SIZE 1024
 #define RTE_EVENT_CRYPTO_ADAPTER_MAX_INSTANCE 32
diff --git a/doc/guides/eventdevs/features/default.ini 
b/doc/guides/eventdevs/features/default.ini
index 73a52d915b..e980ae134a 100644
--- a/doc/guides/eventdevs/features/default.ini
+++ b/doc/guides/eventdevs/features/default.ini
@@ -18,6 +18,7 @@ multiple_queue_port=
 carry_flow_id  =
 maintenance_free   =
 runtime_queue_attr =
+profile_links  =
 
 ;
 ; Features of a default Ethernet Rx adapter.
diff --git a/doc/guides/prog_guide/eventdev.rst 
b/doc/guides/prog_guide/eventdev.rst
index ff55115d0d..8c15c678bf 100644
--- a/doc/guides/prog_guide/eventdev.rst
+++ b/doc/guides/prog_guide/eventdev.rst
@@ -317,6 +317,46 @@ can be achieved like this:
 }
 int links_made = rte_event_port_link(dev_id, tx_port_id, 
&single_link_q, &priority, 1);
 
+Linking Queues to Ports with link profiles
+~~
+
+An application can use link profiles if supported by the underlying event 
device to setup up
+multiple link profile per port and change them run time depending up on 
heuristic data.
+Using Link profiles can reduce the overhead of linking/unlinking and wait for 
unlinks in progress
+in fast-path and gives applications the ability to switch between preset 
profiles on the fly.
+
+An Example use case could be as follows.
+
+Config path:
+
+.. code-block:: c
+
+uint8_t lq[4] = {4, 5, 6, 7};
+uint8_t hq[4] = {0, 1, 2, 3};
+
+if (rte_event_dev_info.max_profiles_per_port < 2)
+return -ENOTSUP;
+
+rte_event_port_profile_links_set(0, 0, hq, NULL, 4, 0);
+rte_event_port_profile_links_set(0, 0, lq, NULL, 4, 1);
+
+Worker path:
+
+.. code-block:: c
+
+uint8_t profile_id_to_switch;
+
+while (1) {
+deq = rte_event_dequeue_burst(0, 0, &ev, 1, 0);
+if (deq == 0) {
+profile_id_to_switch = app_find_profile_id_to_switch();
+rte_event_port_profile_switch(0, 0, profile_id_to_switch);
+continue;
+}
+
+// Process the event received.
+}
+
 Starting the EventDev
 ~
 
diff --git a/doc/guides/rel_notes/release_23_11.rst 
b/doc/guides/rel_notes/release_23_11.rst
index b66c364e21..fe6656bed2 100644
--- a/doc/guides

[PATCH v6 2/3] event/cnxk: implement event link profiles

[pbhagavatula]

From: Pavan Nikhilesh 

Implement event link profiles support on CN10K and CN9K.
Both the platforms support up to 2 link profiles.

Signed-off-by: Pavan Nikhilesh 
---
 doc/guides/eventdevs/cnxk.rst  |  1 +
 doc/guides/eventdevs/features/cnxk.ini |  3 +-
 doc/guides/rel_notes/release_23_11.rst |  2 +
 drivers/common/cnxk/roc_nix_inl_dev.c  |  4 +-
 drivers/common/cnxk/roc_sso.c  | 18 +++
 drivers/common/cnxk/roc_sso.h  |  8 +--
 drivers/common/cnxk/roc_sso_priv.h |  4 +-
 drivers/event/cnxk/cn10k_eventdev.c| 45 +++-
 drivers/event/cnxk/cn10k_worker.c  | 11 
 drivers/event/cnxk/cn10k_worker.h  |  1 +
 drivers/event/cnxk/cn9k_eventdev.c | 74 --
 drivers/event/cnxk/cn9k_worker.c   | 22 
 drivers/event/cnxk/cn9k_worker.h   |  2 +
 drivers/event/cnxk/cnxk_eventdev.c | 37 +++--
 drivers/event/cnxk/cnxk_eventdev.h | 10 ++--
 15 files changed, 161 insertions(+), 81 deletions(-)

diff --git a/doc/guides/eventdevs/cnxk.rst b/doc/guides/eventdevs/cnxk.rst
index 1a59233282..cccb8a0304 100644
--- a/doc/guides/eventdevs/cnxk.rst
+++ b/doc/guides/eventdevs/cnxk.rst
@@ -48,6 +48,7 @@ Features of the OCTEON cnxk SSO PMD are:
 - HW managed event vectorization on CN10K for packets enqueued from ethdev to
   eventdev configurable per each Rx queue in Rx adapter.
 - Event vector transmission via Tx adapter.
+- Up to 2 event link profiles.
 
 Prerequisites and Compilation procedure
 ---
diff --git a/doc/guides/eventdevs/features/cnxk.ini 
b/doc/guides/eventdevs/features/cnxk.ini
index bee69bf8f4..5d353e3670 100644
--- a/doc/guides/eventdevs/features/cnxk.ini
+++ b/doc/guides/eventdevs/features/cnxk.ini
@@ -12,7 +12,8 @@ runtime_port_link  = Y
 multiple_queue_port= Y
 carry_flow_id  = Y
 maintenance_free   = Y
-runtime_queue_attr = y
+runtime_queue_attr = Y
+profile_links  = Y
 
 [Eth Rx adapter Features]
 internal_port  = Y
diff --git a/doc/guides/rel_notes/release_23_11.rst 
b/doc/guides/rel_notes/release_23_11.rst
index fe6656bed2..66c4ddf37c 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -105,6 +105,8 @@ New Features
 
   * Added support for ``remaining_ticks_get`` timer adapter PMD callback
 to get the remaining ticks to expire for a given event timer.
+  * Added link profiles support for Marvell CNXK event device driver,
+up to two link profiles are supported per event port.
 
 
 Removed Items
diff --git a/drivers/common/cnxk/roc_nix_inl_dev.c 
b/drivers/common/cnxk/roc_nix_inl_dev.c
index d76158e30d..690d47c045 100644
--- a/drivers/common/cnxk/roc_nix_inl_dev.c
+++ b/drivers/common/cnxk/roc_nix_inl_dev.c
@@ -285,7 +285,7 @@ nix_inl_sso_setup(struct nix_inl_dev *inl_dev)
}
 
/* Setup hwgrp->hws link */
-   sso_hws_link_modify(0, inl_dev->ssow_base, NULL, hwgrp, 1, true);
+   sso_hws_link_modify(0, inl_dev->ssow_base, NULL, hwgrp, 1, 0, true);
 
/* Enable HWGRP */
plt_write64(0x1, inl_dev->sso_base + SSO_LF_GGRP_QCTL);
@@ -315,7 +315,7 @@ nix_inl_sso_release(struct nix_inl_dev *inl_dev)
nix_inl_sso_unregister_irqs(inl_dev);
 
/* Unlink hws */
-   sso_hws_link_modify(0, inl_dev->ssow_base, NULL, hwgrp, 1, false);
+   sso_hws_link_modify(0, inl_dev->ssow_base, NULL, hwgrp, 1, 0, false);
 
/* Release XAQ aura */
sso_hwgrp_release_xaq(&inl_dev->dev, 1);
diff --git a/drivers/common/cnxk/roc_sso.c b/drivers/common/cnxk/roc_sso.c
index c37da685da..748d287bad 100644
--- a/drivers/common/cnxk/roc_sso.c
+++ b/drivers/common/cnxk/roc_sso.c
@@ -186,8 +186,8 @@ sso_rsrc_get(struct roc_sso *roc_sso)
 }
 
 void
-sso_hws_link_modify(uint8_t hws, uintptr_t base, struct plt_bitmap *bmp,
-   uint16_t hwgrp[], uint16_t n, uint16_t enable)
+sso_hws_link_modify(uint8_t hws, uintptr_t base, struct plt_bitmap *bmp, 
uint16_t hwgrp[],
+   uint16_t n, uint8_t set, uint16_t enable)
 {
uint64_t reg;
int i, j, k;
@@ -204,7 +204,7 @@ sso_hws_link_modify(uint8_t hws, uintptr_t base, struct 
plt_bitmap *bmp,
k = n % 4;
k = k ? k : 4;
for (j = 0; j < k; j++) {
-   mask[j] = hwgrp[i + j] | enable << 14;
+   mask[j] = hwgrp[i + j] | (uint32_t)set << 12 | enable 
<< 14;
if (bmp) {
enable ? plt_bitmap_set(bmp, hwgrp[i + j]) :
 plt_bitmap_clear(bmp, hwgrp[i + j]);
@@ -290,8 +290,8 @@ roc_sso_ns_to_gw(struct roc_sso *roc_sso, uint64_t ns)
 }
 
 int
-roc_sso_hws_link(struct roc_sso *roc_sso, uint8_t hws, uint16_t hwgrp[],
-uint16_t nb_hwgrp)
+roc_sso_hws_link(struct roc_sso *roc_sso, uint8_t hws, uint16_t hwgrp[], 
uint16_t nb_hwgrp,
+uin

[PATCH v6 3/3] test/event: add event link profile test

[pbhagavatula]

From: Pavan Nikhilesh 

Add test case to verify event link profiles.

Signed-off-by: Pavan Nikhilesh 
---
 app/test/test_eventdev.c | 117 +++
 1 file changed, 117 insertions(+)

diff --git a/app/test/test_eventdev.c b/app/test/test_eventdev.c
index c51c93bdbd..0ecfa7db02 100644
--- a/app/test/test_eventdev.c
+++ b/app/test/test_eventdev.c
@@ -1129,6 +1129,121 @@ test_eventdev_link_get(void)
return TEST_SUCCESS;
 }
 
+static int
+test_eventdev_profile_switch(void)
+{
+#define MAX_RETRIES   4
+   uint8_t priorities[RTE_EVENT_MAX_QUEUES_PER_DEV];
+   uint8_t queues[RTE_EVENT_MAX_QUEUES_PER_DEV];
+   struct rte_event_queue_conf qcfg;
+   struct rte_event_port_conf pcfg;
+   struct rte_event_dev_info info;
+   struct rte_event ev;
+   uint8_t q, re;
+   int rc;
+
+   rte_event_dev_info_get(TEST_DEV_ID, &info);
+
+   if (info.max_profiles_per_port <= 1)
+   return TEST_SKIPPED;
+
+   if (info.max_event_queues <= 1)
+   return TEST_SKIPPED;
+
+   rc = rte_event_port_default_conf_get(TEST_DEV_ID, 0, &pcfg);
+   TEST_ASSERT_SUCCESS(rc, "Failed to get port0 default config");
+   rc = rte_event_port_setup(TEST_DEV_ID, 0, &pcfg);
+   TEST_ASSERT_SUCCESS(rc, "Failed to setup port0");
+
+   rc = rte_event_queue_default_conf_get(TEST_DEV_ID, 0, &qcfg);
+   TEST_ASSERT_SUCCESS(rc, "Failed to get queue0 default config");
+   rc = rte_event_queue_setup(TEST_DEV_ID, 0, &qcfg);
+   TEST_ASSERT_SUCCESS(rc, "Failed to setup queue0");
+
+   q = 0;
+   rc = rte_event_port_profile_links_set(TEST_DEV_ID, 0, &q, NULL, 1, 0);
+   TEST_ASSERT(rc == 1, "Failed to link queue 0 to port 0 with profile 0");
+   q = 1;
+   rc = rte_event_port_profile_links_set(TEST_DEV_ID, 0, &q, NULL, 1, 1);
+   TEST_ASSERT(rc == 1, "Failed to link queue 1 to port 0 with profile 1");
+
+   rc = rte_event_port_profile_links_get(TEST_DEV_ID, 0, queues, 
priorities, 0);
+   TEST_ASSERT(rc == 1, "Failed to links");
+   TEST_ASSERT(queues[0] == 0, "Invalid queue found in link");
+
+   rc = rte_event_port_profile_links_get(TEST_DEV_ID, 0, queues, 
priorities, 1);
+   TEST_ASSERT(rc == 1, "Failed to links");
+   TEST_ASSERT(queues[0] == 1, "Invalid queue found in link");
+
+   rc = rte_event_dev_start(TEST_DEV_ID);
+   TEST_ASSERT_SUCCESS(rc, "Failed to start event device");
+
+   ev.event_type = RTE_EVENT_TYPE_CPU;
+   ev.queue_id = 0;
+   ev.op = RTE_EVENT_OP_NEW;
+   ev.flow_id = 0;
+   ev.u64 = 0xBADF00D0;
+   rc = rte_event_enqueue_burst(TEST_DEV_ID, 0, &ev, 1);
+   TEST_ASSERT(rc == 1, "Failed to enqueue event");
+   ev.queue_id = 1;
+   ev.flow_id = 1;
+   rc = rte_event_enqueue_burst(TEST_DEV_ID, 0, &ev, 1);
+   TEST_ASSERT(rc == 1, "Failed to enqueue event");
+
+   ev.event = 0;
+   ev.u64 = 0;
+
+   rc = rte_event_port_profile_switch(TEST_DEV_ID, 0, 1);
+   TEST_ASSERT_SUCCESS(rc, "Failed to change profile");
+
+   re = MAX_RETRIES;
+   while (re--) {
+   rc = rte_event_dequeue_burst(TEST_DEV_ID, 0, &ev, 1, 0);
+   printf("rc %d\n", rc);
+   if (rc)
+   break;
+   }
+
+   TEST_ASSERT(rc == 1, "Failed to dequeue event from profile 1");
+   TEST_ASSERT(ev.flow_id == 1, "Incorrect flow identifier from profile 
1");
+   TEST_ASSERT(ev.queue_id == 1, "Incorrect queue identifier from profile 
1");
+
+   re = MAX_RETRIES;
+   while (re--) {
+   rc = rte_event_dequeue_burst(TEST_DEV_ID, 0, &ev, 1, 0);
+   TEST_ASSERT(rc == 0, "Unexpected event dequeued from active 
profile");
+   }
+
+   rc = rte_event_port_profile_switch(TEST_DEV_ID, 0, 0);
+   TEST_ASSERT_SUCCESS(rc, "Failed to change profile");
+
+   re = MAX_RETRIES;
+   while (re--) {
+   rc = rte_event_dequeue_burst(TEST_DEV_ID, 0, &ev, 1, 0);
+   if (rc)
+   break;
+   }
+
+   TEST_ASSERT(rc == 1, "Failed to dequeue event from profile 1");
+   TEST_ASSERT(ev.flow_id == 0, "Incorrect flow identifier from profile 
0");
+   TEST_ASSERT(ev.queue_id == 0, "Incorrect queue identifier from profile 
0");
+
+   re = MAX_RETRIES;
+   while (re--) {
+   rc = rte_event_dequeue_burst(TEST_DEV_ID, 0, &ev, 1, 0);
+   TEST_ASSERT(rc == 0, "Unexpected event dequeued from active 
profile");
+   }
+
+   q = 0;
+   rc = rte_event_port_profile_unlink(TEST_DEV_ID, 0, &q, 1, 0);
+   TEST_ASSERT(rc == 1, "Failed to unlink queue 0 to port 0 with profile 
0");
+   q = 1;
+   rc = rte_event_port_profile_unlink(TEST_DEV_ID, 0, &q, 1, 1);
+   TEST_ASSERT(rc == 1, "Failed to unlink queue 1 to port 0 with profile 
1");
+
+   return TEST_SUCCESS;
+}
+
 static int
 test_eventdev_close(void)
 {
@@ -1187,6 +1302,8 @@ static struct u

Re: [PATCH 0/2] Add eventdev tests to test suites

[Jerin Jacob]

On Sat, Sep 30, 2023 at 6:31 AM David Marchand
 wrote:
>
> On Thu, Sep 28, 2023 at 5:14 PM Bruce Richardson
>  wrote:
> >
> > The eventdev library includes a selftest API which can be used by
> > drivers for testing. Add the relevant automated self-test commands
> > into meson test suites as appropriate.
> >
> > Bruce Richardson (2):
> >   event/sw: add self tests to fast tests
> >   event/*: add driver selftests to driver-tests suite
> >
> >  app/test/test_eventdev.c | 10 +-
> >  drivers/event/sw/sw_evdev_selftest.c |  2 +-
> >  2 files changed, 6 insertions(+), 6 deletions(-)
> >
>
> On the principle, the series lgtm.
> Acked-by: David Marchand 

Changed second patch subject to  test/event: add driver selftests to
driver-tests suite

Series applied to dpdk-next-net-eventdev/for-main. Thanks


>
>
> --
> David Marchand
>

Re: [PATCH v4] bus/pci: fix legacy device IO port map in secondary process

[David Marchand]

On Wed, Aug 30, 2023 at 7:07 AM Wenwu Ma  wrote:
>
> When doing IO port mapping for legacy device in secondary process, the
> region information is missing, so, we need to refill it.
>
> Fixes: 4b741542ecde ("bus/pci: avoid depending on private kernel value")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Wenwu Ma 
>
> ---
>  drivers/bus/pci/linux/pci_vfio.c | 43 ++--
>  1 file changed, 41 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/bus/pci/linux/pci_vfio.c 
> b/drivers/bus/pci/linux/pci_vfio.c
> index e634de8322..5ef26c98d1 100644
> --- a/drivers/bus/pci/linux/pci_vfio.c
> +++ b/drivers/bus/pci/linux/pci_vfio.c
> @@ -1314,6 +1314,27 @@ pci_vfio_ioport_map(struct rte_pci_device *dev, int 
> bar,
> return -1;
> }
>
> +   if (rte_eal_process_type() == RTE_PROC_SECONDARY) {
> +   struct vfio_device_info device_info = { .argsz = 
> sizeof(device_info) };
> +   char pci_addr[PATH_MAX];
> +   int vfio_dev_fd;
> +   struct rte_pci_addr *loc = &dev->addr;
> +   int ret;
> +   /* store PCI address string */
> +   snprintf(pci_addr, sizeof(pci_addr), PCI_PRI_FMT,
> +   loc->domain, loc->bus, loc->devid, 
> loc->function);
> +
> +   ret = rte_vfio_setup_device(rte_pci_get_sysfs_path(), 
> pci_addr,
> +   &vfio_dev_fd, &device_info);

>From a pci bus API pov, nothing prevents a driver from mixing memory
mapped with vfio and ioport resources (iow, calls to
rte_pci_map_resource() and rte_pci_ioport_map()).
IOW, it may not be the case with the net/virtio driver but, in theory,
rte_pci_ioport_map()/pci_vfio_ioport_map() may be called after a
rte_pci_map_resource() call.

In a similar manner, from the API pov,
rte_pci_ioport_map()/pci_vfio_ioport_map() may be called for multiple
bars.

In summary, nothing in this patch checks that vfio has been configured
already and I think we need a refcount to handle those situations.

Nipun, Chenbo, WDYT?


> +   if (ret)
> +   return -1;

ret value is not used, so there is no need for this variable.

if (rte_vfio_setup_device(rte_pci_get_sysfs_path(), pci_addr,
&vfio_dev_fd, &device_info) != 0)
return -1;

> +
> +   ret = pci_vfio_fill_regions(dev, vfio_dev_fd, &device_info);
> +   if (ret)
> +   return -1;

Same here, ret is not needed.


> +
> +   }
> +
> if (pci_vfio_get_region(dev, bar, &size, &offset) != 0) {
> RTE_LOG(ERR, EAL, "Cannot get offset of region %d.\n", bar);
> return -1;
> @@ -1361,8 +1382,26 @@ pci_vfio_ioport_write(struct rte_pci_ioport *p,
>  int
>  pci_vfio_ioport_unmap(struct rte_pci_ioport *p)
>  {
> -   RTE_SET_USED(p);
> -   return -1;
> +   char pci_addr[PATH_MAX] = {0};
> +   struct rte_pci_addr *loc = &p->dev->addr;
> +   int ret, vfio_dev_fd;
> +
> +   /* store PCI address string */
> +   snprintf(pci_addr, sizeof(pci_addr), PCI_PRI_FMT,
> +   loc->domain, loc->bus, loc->devid, loc->function);
> +
> +   vfio_dev_fd = rte_intr_dev_fd_get(p->dev->intr_handle);
> +   if (vfio_dev_fd < 0)
> +   return -1;

This check is odd and does not seem related.


> +
> +   ret = rte_vfio_release_device(rte_pci_get_sysfs_path(), pci_addr,
> + vfio_dev_fd);
> +   if (ret < 0) {
> +   RTE_LOG(ERR, EAL, "Cannot release VFIO device\n");
> +   return ret;
> +   }


-- 
David Marchand

Re: [PATCH v6 0/3] Introduce event link profiles

[Jerin Jacob]

On Tue, Oct 3, 2023 at 3:17 PM  wrote:
>
> From: Pavan Nikhilesh 
>
> A collection of event queues linked to an event port can be associated
> with unique identifier called as a link profile, multiple such profiles
> can be configured based on the event device capability using the function
> `rte_event_port_profile_links_set` which takes arguments similar to
> `rte_event_port_link` in addition to the profile identifier.
>
> The maximum link profiles that are supported by an event device is
> advertised through the structure member

...

>
> v6 Changes:

Series applied to dpdk-next-net-eventdev/for-main with following changes. Thanks

[for-main]dell[dpdk-next-eventdev] $ git diff
diff --git a/doc/guides/prog_guide/eventdev.rst
b/doc/guides/prog_guide/eventdev.rst
index 8c15c678bf..e177ca6bdb 100644
--- a/doc/guides/prog_guide/eventdev.rst
+++ b/doc/guides/prog_guide/eventdev.rst
@@ -325,7 +325,7 @@ multiple link profile per port and change them run
time depending up on heuristi
 Using Link profiles can reduce the overhead of linking/unlinking and
wait for unlinks in progress
 in fast-path and gives applications the ability to switch between
preset profiles on the fly.

-An Example use case could be as follows.
+An example use case could be as follows.

 Config path:

diff --git a/doc/guides/rel_notes/release_23_11.rst
b/doc/guides/rel_notes/release_23_11.rst
index 66c4ddf37c..261594aacc 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -105,8 +105,7 @@ New Features

   * Added support for ``remaining_ticks_get`` timer adapter PMD callback
 to get the remaining ticks to expire for a given event timer.
-  * Added link profiles support for Marvell CNXK event device driver,
-up to two link profiles are supported per event port.
+  * Added link profiles support, up to two link profiles are supported.

Re: [PATCH v2 0/3] rte_ether_unformat_addr changes

[Ferruh Yigit]

On 10/2/2023 7:37 PM, Stephen Hemminger wrote:
> This patchset makes rte_ether_unformat_addr allow other formats
> for MAC address. Need to remove some inputs from existing
> cmdline_etheraddr test, and add a new test in test suite
> to cover this.  There is some overlap between the two tests
> but that is fine.
> 
> Stephen Hemminger (3):
>   test: remove some strings from cmdline_etheraddr tests
>   rte_ether_unformat: accept more inputs
>   test: add tests for rte_ether routines
> 

Thanks Stephen,

This enables using the API as replacement to the tap PMD's local parse
implementation:
https://patchwork.dpdk.org/project/dpdk/patch/20230323170145.129901-1-...@linux.vnet.ibm.com/

Re: [PATCH v2 1/3] test: remove some strings from cmdline_etheraddr tests

[Ferruh Yigit]

On 10/2/2023 7:37 PM, Stephen Hemminger wrote:
> Some of the ethernet address formats which were invalid will
> now become valid inputs when rte_ether_unformat_addr is modified
> to allow leading zeros.
> 
> Also, make local variables static.
> 
> Signed-off-by: Stephen Hemminger 
> 

<...>

> @@ -61,10 +60,8 @@ const char * ether_addr_invalid_strs[] = {
>   "INVA:LIDC:HARS",
>   /* misc */
>   "01 23 45 67 89 AB",
> - "01.23.45.67.89.AB",
>   "01,23,45,67,89,AB",
> - "01:23:45\0:67:89:AB",
> - "01:23:45#:67:89:AB",
>

Why these two are valid now?

And I guess second one is still not valid, but first one is parsed as
[1], is this expected?

[1] 00:01:00:23:00:45

[PATCH v2 1/5] net: add headers for TLS/DTLS packets

[Anoob Joseph]

From: Akhil Goyal 

Added TLS and DTLS packet headers for L4 security applications.

Signed-off-by: Akhil Goyal 
Signed-off-by: Anoob Joseph 
Signed-off-by: Vidya Sagar Velumuri 
---
 doc/api/doxy-api-index.md |  2 ++
 lib/net/meson.build   |  2 ++
 lib/net/rte_dtls.h| 61 +++
 lib/net/rte_tls.h | 48 ++
 4 files changed, 113 insertions(+)
 create mode 100644 lib/net/rte_dtls.h
 create mode 100644 lib/net/rte_tls.h

diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
index fdeda13932..03e2445bb1 100644
--- a/doc/api/doxy-api-index.md
+++ b/doc/api/doxy-api-index.md
@@ -128,6 +128,8 @@ The public API headers are grouped by topics:
   [eCPRI](@ref rte_ecpri.h),
   [PDCP hdr](@ref rte_pdcp_hdr.h),
   [PDCP](@ref rte_pdcp.h),
+  [TLS](@ref rte_tls.h),
+  [DTLS](@ref rte_dtls.h),
   [L2TPv2](@ref rte_l2tpv2.h),
   [PPP](@ref rte_ppp.h),
   [IB](@ref rte_ib.h)
diff --git a/lib/net/meson.build b/lib/net/meson.build
index b1bc27bad5..0b69138949 100644
--- a/lib/net/meson.build
+++ b/lib/net/meson.build
@@ -5,6 +5,8 @@ headers = files(
 'rte_ip.h',
 'rte_tcp.h',
 'rte_udp.h',
+'rte_tls.h',
+'rte_dtls.h',
 'rte_esp.h',
 'rte_sctp.h',
 'rte_icmp.h',
diff --git a/lib/net/rte_dtls.h b/lib/net/rte_dtls.h
new file mode 100644
index 00..49bded1d96
--- /dev/null
+++ b/lib/net/rte_dtls.h
@@ -0,0 +1,61 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2023 Marvell.
+ */
+
+#ifndef RTE_DTLS_H
+#define RTE_DTLS_H
+
+/**
+ * @file
+ *
+ * Datagram transport layer security(DTLS) related defines.
+ */
+
+#include 
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#define RTE_DTLS_TYPE_INVALID  0 /**< Invalid DTLS message 
type. */
+#define RTE_DTLS_TYPE_CHANGE_CIPHER_SPEC   20 /**< Change cipher spec 
message. */
+#define RTE_DTLS_TYPE_ALERT21 /**< Alert message. */
+#define RTE_DTLS_TYPE_HANDSHAKE22 /**< Handshake 
message for DTLS. */
+#define RTE_DTLS_TYPE_APPDATA  23 /**< DTLS application data 
message. */
+#define RTE_DTLS_TYPE_HEARTBEAT24 /**< DTLS 1.3 
heartbeat message. */
+#define RTE_DTLS_TYPE_CIPHERTEXT_WITH_CID  25 /**< DTLS 1.3 ciphertext 
with CID message. */
+#define RTE_DTLS_TYPE_ACK  26 /**< DTLS 1.3 ACK message. */
+#define RTE_DTLS_TYPE_MAX  255 /**< Maximum value as DTLS 
content type. */
+
+#define RTE_DTLS_VERSION_1_2   0xFEFD /**< DTLS 1.2 version. 1's complement of 
1.2. */
+#define RTE_DTLS_VERSION_1_3   0xFEFC /**< DTLS 1.3 version. 1's complement of 
1.3. */
+
+/**
+ * DTLS Header
+ */
+__extension__
+struct rte_dtls_hdr {
+   /** Content type of DTLS packet. Defined as RTE_DTLS_TYPE_*. */
+   uint8_t type;
+   /** DTLS Version defined as RTE_DTLS_VERSION*. */
+   rte_be16_t version;
+#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
+   /** The sequence number for the DTLS record. */
+   uint64_t sequence_number : 48;
+   /** A counter value that is incremented on every cipher state change. */
+   uint64_t epoch : 16;
+#elif RTE_BYTE_ORDER == RTE_BIG_ENDIAN
+   /** A counter value that is incremented on every cipher state change. */
+   uint64_t epoch : 16;
+   /** The sequence number for the DTLS record. */
+   uint64_t sequence_number : 48;
+#endif
+   /** The length (in bytes) of the following DTLS packet. */
+   rte_be16_t length;
+} __rte_packed;
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* RTE_DTLS_H */
diff --git a/lib/net/rte_tls.h b/lib/net/rte_tls.h
new file mode 100644
index 00..ee1e3aa249
--- /dev/null
+++ b/lib/net/rte_tls.h
@@ -0,0 +1,48 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2023 Marvell.
+ */
+
+#ifndef RTE_TLS_H
+#define RTE_TLS_H
+
+/**
+ * @file
+ *
+ * Transport layer security(TLS) related defines.
+ */
+
+#include 
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#define RTE_TLS_TYPE_INVALID   0 /**< Invalid TLS message type. */
+#define RTE_TLS_TYPE_CHANGE_CIPHER_SPEC20 /**< Change cipher spec 
message. */
+#define RTE_TLS_TYPE_ALERT 21 /**< Alert message. */
+#define RTE_TLS_TYPE_HANDSHAKE 22 /**< Handshake message for TLS. */
+#define RTE_TLS_TYPE_APPDATA   23 /**< TLS application data message. */
+#define RTE_TLS_TYPE_HEARTBEAT 24 /**< TLS 1.3 heartbeat message. */
+#define RTE_TLS_TYPE_MAX   255 /**< Maximum value as TLS content 
type. */
+
+#define RTE_TLS_VERSION_1_20x0303 /**< TLS 1.2 version. */
+#define RTE_TLS_VERSION_1_30x0304 /**< TLS 1.3 version. */
+
+/**
+ * TLS Header
+ */
+__extension__
+struct rte_tls_hdr {
+   /** Content type of TLS packet. Defined as RTE_TLS_TYPE_*. */
+   uint8_t type;
+   /** TLS Version defined as RTE_TLS_VERSION*. */
+   rte_be16_t version;
+   /** The le

[PATCH v2 0/5] add TLS record processing security offload

[Anoob Joseph]

Add Transport Layer Security (TLS) and Datagram Transport Layer Security
(DTLS). The protocols provide communications privacy for L4 protocols
such as TCP & UDP.

TLS (and DTLS) protocol is composed of two layers,
1. TLS Record Protocol
2. TLS Handshake Protocol

While TLS Handshake Protocol helps in establishing security parameters
by which client and server can communicate, TLS Record Protocol provides
the connection security. TLS Record Protocol leverages symmetric
cryptographic operations such as data encryption and authentication for
providing security to the communications.

Cryptodevs that are capable of offloading TLS Record Protocol may
perform other operations like IV generation, header insertion, atomic
sequence number updates and anti-replay window check in addition to
cryptographic transformations.

In record write operations, message content type is a per packet field
which is used in constructing the TLS header. One session is expected
to handle all types of content types and so, 'rte_crypto_op.aux_flags'
is used for passing the same.

Support for TLS record protocol is added for TLS 1.2, TLS 1.3 and
DTLS 1.2.

Changes in v2:
- Replaced CCS with CHANGE_CIPHER_SPEC (Harry)
- Split patches to clarify lifetime tracking and notification of the
  same in rte_crypto_op (Harry)
- Use 8 bits reserved space in rte_crypto_op to pass content type from
  application to PMD (in case of record write) and from PMD to
  application (in case of of record read). TLS 1.3 has content type as
  part of trailer which would be encrypted and would be removed by PMD.
- Updated documentation (Harry)

Akhil Goyal (1):
  net: add headers for TLS/DTLS packets

Anoob Joseph (2):
  security: add TLS record processing
  security: support extra padding with TLS

Vidya Sagar Velumuri (2):
  security: support TLS record lifetime notification
  cryptodev: add details of datapath handling of TLS records

 doc/api/doxy-api-index.md  |   2 +
 doc/guides/prog_guide/rte_security.rst |  74 +
 doc/guides/rel_notes/release_23_11.rst |   6 ++
 lib/cryptodev/rte_crypto.h |  50 -
 lib/net/meson.build|   2 +
 lib/net/rte_dtls.h |  61 +++
 lib/net/rte_tls.h  |  48 +
 lib/security/rte_security.c|   4 +
 lib/security/rte_security.h| 144 +
 9 files changed, 388 insertions(+), 3 deletions(-)
 create mode 100644 lib/net/rte_dtls.h
 create mode 100644 lib/net/rte_tls.h

-- 
2.25.1

[PATCH v2 2/5] security: add TLS record processing

[Anoob Joseph]

Add Transport Layer Security (TLS) and Datagram Transport Layer Security
(DTLS). The protocols provide communications privacy for L4 protocols
such as TCP & UDP.

TLS (and DTLS) protocol is composed of two layers,
1. TLS Record Protocol
2. TLS Handshake Protocol

While TLS Handshake Protocol helps in establishing security parameters
by which client and server can communicate, TLS Record Protocol provides
the connection security. TLS Record Protocol leverages symmetric
cryptographic operations such as data encryption and authentication for
providing security to the communications.

Cryptodevs that are capable of offloading TLS Record Protocol may
perform other operations like IV generation, header insertion, atomic
sequence number updates and anti-replay window check in addition to
cryptographic transformations.

Support for TLS record protocol is added for TLS 1.2, TLS 1.3 and
DTLS 1.2.

Signed-off-by: Akhil Goyal 
Signed-off-by: Anoob Joseph 
Signed-off-by: Vidya Sagar Velumuri 
---
 doc/guides/prog_guide/rte_security.rst |  62 ++
 lib/security/rte_security.c|   4 +
 lib/security/rte_security.h| 110 +
 3 files changed, 176 insertions(+)

diff --git a/doc/guides/prog_guide/rte_security.rst 
b/doc/guides/prog_guide/rte_security.rst
index ad8c6374bd..f90dee5df0 100644
--- a/doc/guides/prog_guide/rte_security.rst
+++ b/doc/guides/prog_guide/rte_security.rst
@@ -399,6 +399,66 @@ The API ``rte_security_macsec_sc_create`` returns a handle 
for SC,
 and this handle is set in ``rte_security_macsec_xform``
 to create a MACsec session using ``rte_security_session_create``.
 
+TLS-Record Protocol
+~~~
+
+The Transport Layer Protocol provides communications security over the 
Internet. The protocol
+allows client/server applications to communicate in a way that is designed to 
prevent eavesdropping,
+tampering, or message forgery.
+
+TLS protocol is composed of two layers: the TLS Record Protocol and the TLS 
Handshake Protocol. At
+the lowest level, layered on top of some reliable transport protocol (e.g., 
TCP), is the TLS Record
+Protocol. The TLS Record Protocol provides connection security that has two 
basic properties:
+
+   -  The connection is private.  Symmetric cryptography is used for data
+  encryption (e.g., AES, DES, etc.).  The keys for this symmetric 
encryption
+  are generated uniquely for each connection and are based on a secret
+  negotiated during TLS Handshake Protocol. The Record Protocol can also be
+  used without encryption.
+
+   -  The connection is reliable.  Message transport includes a message
+  integrity check using a keyed MAC.  Secure hash functions (e.g.,
+  SHA-1, etc.) are used for MAC computations. The Record Protocol can
+  operate without a MAC when it is being used as a transport for 
negotiating
+  security parameters by another protocol.
+
+.. code-block:: c
+
+ Record Write   Record Read
+    ---
+
+ TLSPlaintext  TLSCiphertext
+  |  |
+  ~  ~
+  |  |
+  V  V
+   +--|---+   +--|---+
+   | Generate sequence no.|   | Generate sequence no.|
+   +--|---+   +--+
+  |   |AR check (DTLS)   |
+   +--|---+   +--|---+
+   |  Insert TLS header   |  |
+   | & trailer.   |   +--|---+
+   | (including padding)  |   | Decrypt & MAC verify |
+   +--|---+   +--|---+
+  |  |
++-|---+   +--|---+
+|MAC generate &   |   |  Remove TLS header   |
+|  Encrypt|   |  & trailer.  |
++-|---+   | (including padding)  |
+  |   +--|---+
+  |  |
+  ~  ~
+  |  |
+  V  V
+TLSCiphertext  TLSPlaintext
+
+Supported Versions
+^^
+
+* TLS 1.2
+* TLS 1.3
+* DTLS 1.2
 
 Device Features and Capabilities
 -
@@ -701,6 +761,8 @@ PDCP related configuration parameters are defined in 
``rte_security_pdcp_xform``
 
 DOCSIS related configuration parameters are defined in 
``rte_security_docsis_xform``
 
+TLS record related configuration parameters are defined in 
``rte_security_tls_record_xform``
+
 
 Security API
 ~~~

[PATCH v2 3/5] security: support extra padding with TLS

[Anoob Joseph]

In TLS record write protocol (encrypt), application may request for
extra padding in addition to the default padding which ensures that
crypto payload is aligned to block size. This is required to hide
the size of the traffic from an observer.

Extend the usage of ``rte_crypto_op.aux_flags`` to allow users to
provide extra padding in units of 8B. It is an optional feature and any
device that supports the same can declare so by making use of
corresponding capability.

Signed-off-by: Anoob Joseph 
Signed-off-by: Vidya Sagar Velumuri 
---
 lib/cryptodev/rte_crypto.h  | 14 +-
 lib/security/rte_security.h | 16 
 2 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/lib/cryptodev/rte_crypto.h b/lib/cryptodev/rte_crypto.h
index 9b8d0331a4..7b8f2bdc6d 100644
--- a/lib/cryptodev/rte_crypto.h
+++ b/lib/cryptodev/rte_crypto.h
@@ -99,8 +99,20 @@ struct rte_crypto_op {
/**< operation session type */
uint8_t aux_flags;
/**< Operation specific auxiliary/additional flags.
-* These flags carry additional information from the
+* These flags carry additional information from/to the
 * operation. Processing of the same is optional.
+*
+* The flags are defined as RTE_CRYPTO_OP_AUX_FLAGS_* 
and would be set by
+* PMD for application consumption when the status is
+* RTE_CRYPTO_OP_STATUS_SUCCESS. In case of errors, the 
value of this
+* field is undefined.
+*
+* With TLS record offload 
(RTE_SECURITY_PROTOCOL_TLS_RECORD),
+* application may provide the extra padding required 
for the plaintext
+* provided. This field can be used for passing the 
same in units of 8B. The
+* value would be set by application for PMD 
consumption.
+*
+* @see struct rte_security_tls_record_sess_options
 */
uint8_t reserved[2];
/**< Reserved bytes to fill 64 bits for
diff --git a/lib/security/rte_security.h b/lib/security/rte_security.h
index 54c32c1147..89e61e10ad 100644
--- a/lib/security/rte_security.h
+++ b/lib/security/rte_security.h
@@ -636,6 +636,22 @@ struct rte_security_tls_record_sess_options {
 *  and application is not required to provide IV.
 */
uint32_t iv_gen_disable : 1;
+   /** Enable extra padding
+*
+*  TLS allows user to pad the plain text to hide the actual size of 
the record. This is
+*  required to achieve traffic flow confidentiality in case of 
TLS/DTLS flows. This padding
+*  is in addition to the default padding performed by PMD (which 
ensures ciphertext is
+*  aligned to block size).
+*
+*  On supported devices, application may pass the required additional 
padding via
+*  ``rte_crypto_op.aux_flags`` field.
+*
+* 1 : Enable extra padding of the plain text provided. The extra 
padding value would be
+* read from ``rte_crypto_op.aux_flags``.
+*
+* 0 : Disable extra padding
+*/
+   uint32_t extra_padding_enable : 1;
 };
 
 /**
-- 
2.25.1

[PATCH v2 4/5] security: support TLS record lifetime notification

[Anoob Joseph]

From: Vidya Sagar Velumuri 

Support TLS record lifetime notification. TLS record sessions may need
to be renegotiated after a specific number of records are processed. For
devices that are capable of tracking lifetime, application may request
to do so by configuring the lifetime parameters in session. Upon soft
expiry, PMD will set the notification in `rte_crypto_op.aux_flags` field.

Hard expiration of the session would mean any subsequent crypto
operation would fail.

Extend `rte_crypto_op.aux_flags` to support all sessions that may have a
lifetime notification and include TLS record lifetime under the same.

Signed-off-by: Anoob Joseph 
Signed-off-by: Vidya Sagar Velumuri 
---
 lib/cryptodev/rte_crypto.h  | 11 ++-
 lib/security/rte_security.h | 18 ++
 2 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/lib/cryptodev/rte_crypto.h b/lib/cryptodev/rte_crypto.h
index 7b8f2bdc6d..9fe3e3d529 100644
--- a/lib/cryptodev/rte_crypto.h
+++ b/lib/cryptodev/rte_crypto.h
@@ -64,9 +64,18 @@ enum rte_crypto_op_sess_type {
RTE_CRYPTO_OP_SECURITY_SESSION  /**< Security session crypto operation 
*/
 };
 
+/* Auxiliary flags related to crypto operation */
+#define RTE_CRYPTO_OP_AUX_FLAGS_SESS_SOFT_EXPIRY (1 << 0)
+/**< Session soft expiry limit has been reached. Applicable for any session 
that has a soft lifetime
+ * feature supported.
+ *
+ * @see rte_security_ipsec_lifetime
+ * @see rte_security_tls_record_lifetime
+ */
+
 /* Auxiliary flags related to IPsec offload with RTE_SECURITY */
 
-#define RTE_CRYPTO_OP_AUX_FLAGS_IPSEC_SOFT_EXPIRY (1 << 0)
+#define RTE_CRYPTO_OP_AUX_FLAGS_IPSEC_SOFT_EXPIRY 
RTE_CRYPTO_OP_AUX_FLAGS_SESS_SOFT_EXPIRY
 /**< SA soft expiry limit has been reached */
 
 /**
diff --git a/lib/security/rte_security.h b/lib/security/rte_security.h
index 89e61e10ad..00d2a29a01 100644
--- a/lib/security/rte_security.h
+++ b/lib/security/rte_security.h
@@ -654,6 +654,22 @@ struct rte_security_tls_record_sess_options {
uint32_t extra_padding_enable : 1;
 };
 
+/**
+ * Configure soft and hard lifetime of a TLS record session
+ *
+ * Lifetime of a TLS record session would specify the maximum number of 
packets that can be
+ * processed. TLS record processing operations would start failing once hard 
limit is reached.
+ *
+ * Soft limits can be specified to generate notification when the TLS record 
session is approaching
+ * hard limits for lifetime. This would result in a warning returned in 
``rte_crypto_op.aux_flags``.
+ */
+struct rte_security_tls_record_lifetime {
+   /** Soft expiry limit in number of packets */
+   uint64_t packets_soft_limit;
+   /** Hard expiry limit in number of packets */
+   uint64_t packets_hard_limit;
+};
+
 /**
  * TLS record protocol session configuration.
  *
@@ -666,6 +682,8 @@ struct rte_security_tls_record_xform {
enum rte_security_tls_sess_type type;
/** TLS record session options. */
struct rte_security_tls_record_sess_options options;
+   /** TLS record session lifetime. */
+   struct rte_security_tls_record_lifetime life;
union {
/** TLS 1.2 parameters. */
struct {
-- 
2.25.1

[PATCH v2 5/5] cryptodev: add details of datapath handling of TLS records

[Anoob Joseph]

From: Vidya Sagar Velumuri 

TLS/DTLS record processing requires content type to be provided per
packet (for record write operation). Extend usage of reserved fields in
rte_crypto_op for the same purpose.

Signed-off-by: Anoob Joseph 
Signed-off-by: Vidya Sagar Velumuri 
---
 doc/guides/prog_guide/rte_security.rst | 12 
 doc/guides/rel_notes/release_23_11.rst |  6 ++
 lib/cryptodev/rte_crypto.h | 25 -
 3 files changed, 42 insertions(+), 1 deletion(-)

diff --git a/doc/guides/prog_guide/rte_security.rst 
b/doc/guides/prog_guide/rte_security.rst
index f90dee5df0..7a25a7e649 100644
--- a/doc/guides/prog_guide/rte_security.rst
+++ b/doc/guides/prog_guide/rte_security.rst
@@ -453,6 +453,18 @@ Protocol. The TLS Record Protocol provides connection 
security that has two basi
   V  V
 TLSCiphertext  TLSPlaintext
 
+TLS and DTLS header formation (in record write operation) would depend on
+type of content. It is a per packet variable and would need to be handled by
+the same session. Application may pass this info to a cryptodev performing
+lookaside protocol offload by passing the same in ``rte_crypto_op.param1``.
+
+In record read operation, application is required to preserve any info it may
+need from the TLS/DTLS header (such as content type and sequence number) as the
+cryptodev would remove the header and padding as part of the lookaside protocol
+processing. With TLS 1.3, the actual content type is part of the trailer 
(before
+padding) and would be stripped by the PMD. For applications that may need this
+info, PMD would return the value in ``rte_crypto_op.param1`` field.
+
 Supported Versions
 ^^
 
diff --git a/doc/guides/rel_notes/release_23_11.rst 
b/doc/guides/rel_notes/release_23_11.rst
index 250735efa9..663d1e9cf9 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -83,6 +83,12 @@ New Features
   Similar to out of place processing support for lookaside security session, 
added
   the same support for inline ingress security session.
 
+* **Added support for TLS and DTLS record in rte_security.**
+
+  Added TLS and DTLS record transform for rte_security session and added
+  enhancements to ``rte_crypto_op`` fields to handle all datapath requirements
+  of TLS and DTLS. The support is added for TLS 1.2, TLS 1.3 and DTLS 1.2.
+
 * **Updated ipsec_mb crypto driver.**
 
   Added support for digest encrypted to AESNI_MB asynchronous crypto driver.
diff --git a/lib/cryptodev/rte_crypto.h b/lib/cryptodev/rte_crypto.h
index 9fe3e3d529..34aacd9312 100644
--- a/lib/cryptodev/rte_crypto.h
+++ b/lib/cryptodev/rte_crypto.h
@@ -123,7 +123,30 @@ struct rte_crypto_op {
 *
 * @see struct rte_security_tls_record_sess_options
 */
-   uint8_t reserved[2];
+   union {
+   struct {
+   uint8_t content_type;
+   /**< Content type. The field can act 
both as input
+* and output.
+*
+* As input, for passing message type 
in case of record
+* write (encrypt) operation. 
Applicable for,
+* 1. TLS 1.2
+* 2. TLS 1.3
+* 3. DTLS 1.2
+*
+* As output, for returning message 
type in case of record
+* read (decrypt) operation. Applicable 
for,
+* 1. TLS 1.3
+*
+* Message types are listed as 
RTE_TLS_TYPE_* and
+* RTE_DTLS_TYPE_*.
+*/
+   } tls_record;
+   /**< TLS record */
+   } param1;
+   /**< Additional per operation parameter 1. */
+   uint8_t reserved[1];
/**< Reserved bytes to fill 64 bits for
 * future additions
 */
-- 
2.25.1

Re: [PATCH v2 1/3] test: remove some strings from cmdline_etheraddr tests

[Ferruh Yigit]

On 10/3/2023 11:47 AM, Ferruh Yigit wrote:
> On 10/2/2023 7:37 PM, Stephen Hemminger wrote:
>> Some of the ethernet address formats which were invalid will
>> now become valid inputs when rte_ether_unformat_addr is modified
>> to allow leading zeros.
>>
>> Also, make local variables static.
>>
>> Signed-off-by: Stephen Hemminger 
>>
> 
> <...>
> 
>> @@ -61,10 +60,8 @@ const char * ether_addr_invalid_strs[] = {
>>  "INVA:LIDC:HARS",
>>  /* misc */
>>  "01 23 45 67 89 AB",
>> -"01.23.45.67.89.AB",
>>  "01,23,45,67,89,AB",
>> -"01:23:45\0:67:89:AB",
>> -"01:23:45#:67:89:AB",
>>
> 
> Why these two are valid now?
> 
> And I guess second one is still not valid, but first one is parsed as
> [1], is this expected?
> 
> [1] 00:01:00:23:00:45
> 
> 

Ah, I guess it is taken as "::" format, but number of digit
is not enforced, so "1:2:3" is a valid format, should we add this to API
documentation as example format? Or is this unintended side effect?

[PATCH v2] net/axgbe: use CPUID to identify cpu

[Selwin Sebastian]

Using root complex to identify cpu will not work for vm passthrough.
CPUID is used to get family and modelid to identify cpu

Fixes: b0db927b5eba ("net/axgbe: use PCI root complex device to distinguish 
device")
Cc: sta...@dpdk.org

Signed-off-by: Selwin Sebastian 
---
 drivers/net/axgbe/axgbe_ethdev.c | 106 ++-
 1 file changed, 63 insertions(+), 43 deletions(-)

diff --git a/drivers/net/axgbe/axgbe_ethdev.c b/drivers/net/axgbe/axgbe_ethdev.c
index 48714eebe6..4fdb0ae168 100644
--- a/drivers/net/axgbe/axgbe_ethdev.c
+++ b/drivers/net/axgbe/axgbe_ethdev.c
@@ -12,6 +12,12 @@
 
 #include "eal_filesystem.h"
 
+#ifdef RTE_ARCH_X86
+#include 
+#else
+#define __cpuid (n, a, b, c, d)
+#endif
+
 static int eth_axgbe_dev_init(struct rte_eth_dev *eth_dev);
 static int  axgbe_dev_configure(struct rte_eth_dev *dev);
 static int  axgbe_dev_start(struct rte_eth_dev *dev);
@@ -172,9 +178,14 @@ static const struct axgbe_xstats axgbe_xstats_strings[] = {
 
 /* The set of PCI devices this driver supports */
 #define AMD_PCI_VENDOR_ID   0x1022
-#define AMD_PCI_RV_ROOT_COMPLEX_ID 0x15d0
-#define AMD_PCI_YC_ROOT_COMPLEX_ID 0x14b5
-#define AMD_PCI_SNOWY_ROOT_COMPLEX_ID  0x1450
+
+#defineFam17h  0x17
+#defineFam19h  0x19
+
+#defineCPUID_VENDOR_AuthenticAMD_ebx   0x68747541
+#defineCPUID_VENDOR_AuthenticAMD_ecx   0x444d4163
+#defineCPUID_VENDOR_AuthenticAMD_edx   0x69746e65
+
 #define AMD_PCI_AXGBE_DEVICE_V2A 0x1458
 #define AMD_PCI_AXGBE_DEVICE_V2B 0x1459
 
@@ -2111,29 +2122,6 @@ static void axgbe_default_config(struct axgbe_port 
*pdata)
pdata->power_down = 0;
 }
 
-/*
- * Return PCI root complex device id on success else 0
- */
-static uint16_t
-get_pci_rc_devid(void)
-{
-   char pci_sysfs[PATH_MAX];
-   const struct rte_pci_addr pci_rc_addr = {0, 0, 0, 0};
-   unsigned long device_id;
-
-   snprintf(pci_sysfs, sizeof(pci_sysfs), "%s/" PCI_PRI_FMT "/device",
-rte_pci_get_sysfs_path(), pci_rc_addr.domain,
-pci_rc_addr.bus, pci_rc_addr.devid, pci_rc_addr.function);
-
-   /* get device id */
-   if (eal_parse_sysfs_value(pci_sysfs, &device_id) < 0) {
-   PMD_INIT_LOG(ERR, "Error in reading PCI sysfs\n");
-   return 0;
-   }
-
-   return (uint16_t)device_id;
-}
-
 /* Used in dev_start by primary process and then
  * in dev_init by secondary process when attaching to an existing ethdev.
  */
@@ -2186,6 +2174,9 @@ eth_axgbe_dev_init(struct rte_eth_dev *eth_dev)
uint32_t len;
int ret;
 
+   unsigned int eax = 0, ebx = 0, ecx = 0, edx = 0;
+   unsigned char cpu_family = 0, cpu_model = 0;
+
eth_dev->dev_ops = &axgbe_eth_dev_ops;
 
eth_dev->rx_descriptor_status = axgbe_dev_rx_descriptor_status;
@@ -2230,26 +2221,55 @@ eth_axgbe_dev_init(struct rte_eth_dev *eth_dev)
pdata->vdata = &axgbe_v2b;
 
/*
-* Use PCI root complex device ID to identify the CPU
+* Use CPUID to get Family and model ID to identify the CPU
 */
-   switch (get_pci_rc_devid()) {
-   case AMD_PCI_RV_ROOT_COMPLEX_ID:
-   pdata->xpcs_window_def_reg = PCS_V2_RV_WINDOW_DEF;
-   pdata->xpcs_window_sel_reg = PCS_V2_RV_WINDOW_SELECT;
-   break;
-   case AMD_PCI_YC_ROOT_COMPLEX_ID:
-   pdata->xpcs_window_def_reg = PCS_V2_YC_WINDOW_DEF;
-   pdata->xpcs_window_sel_reg = PCS_V2_YC_WINDOW_SELECT;
-   /* Yellow Carp devices do not need cdr workaround */
-   pdata->vdata->an_cdr_workaround = 0;
+   __cpuid(0x0, eax, ebx, ecx, edx);
+
+   if (ebx == CPUID_VENDOR_AuthenticAMD_ebx &&
+   edx == CPUID_VENDOR_AuthenticAMD_edx &&
+   ecx == CPUID_VENDOR_AuthenticAMD_ecx) {
+   int unknown_cpu = 0;
+   eax = 0, ebx = 0, ecx = 0, edx = 0;
+
+   __cpuid(0x1, eax, ebx, ecx, edx);
+
+   cpu_family = ((GET_BITS(eax, 8, 4)) + (GET_BITS(eax, 20, 8)));
+   cpu_model = ((GET_BITS(eax, 4, 4)) | (((GET_BITS(eax, 16, 4)) 
<< 4) & 0xF0));
+
+   switch (cpu_family) {
+   case Fam17h:
+   /* V1000/R1000 */
+   if (cpu_model >= 0x10 && cpu_model <= 0x1F) {
+   pdata->xpcs_window_def_reg = PCS_V2_RV_WINDOW_DEF;
+   pdata->xpcs_window_sel_reg = PCS_V2_RV_WINDOW_SELECT;
+   /* EPYC 3000 */
+   } else if (cpu_model >= 0x01 && cpu_model <= 0x0F) {
+   pdata->xpcs_window_def_reg = PCS_V2_WINDOW_DEF;
+   pdata->xpcs_window_sel_reg = PCS_V2_WINDOW_SELECT;
+   } else {
+   unknown_cpu = 1;
+   }
break;
-   case AMD_PCI_SNOWY_ROOT_COMPLEX_ID:
-   pdata->xpcs_window_def_reg = PCS_V2_WINDOW_DEF;
-   pdata->xpcs_window_sel_reg = PCS_V2_WINDOW

Re: [PATCH v1 1/7] bbdev: add FFT version member in driver info

[Maxime Coquelin]

On 9/28/23 18:33, Chautru, Nicolas wrote:

HI Maxime,



-Original Message-
From: Maxime Coquelin 
Sent: Thursday, September 28, 2023 1:27 AM
To: Chautru, Nicolas ; hemant.agra...@nxp.com;
dev@dpdk.org
Cc: david.march...@redhat.com; Vargas, Hernan 
Subject: Re: [PATCH v1 1/7] bbdev: add FFT version member in driver info

Hi Nicolas,

On 9/28/23 01:50, Chautru, Nicolas wrote:

Hi Maxime, Hemant,

I wanted initially to keep it fairly open hence a hash table for the windows

profiles, but it is also possible to expose something more descriptive, that
would work as well actually.

Ie.

+   /** FFT windowing width for 2048 FFT. */
+   uint16_t fft_window_width[RTE_BBDEV_MAX_FFT_WIN];

The provides the width of each windows shape which is enough to

distinguish major variants and to estimate noise factor.

That sounds much better IMHO.

Regarding the array and values sizes:
1. Should it only covers 2048 points FFT? I see some references about
4096 FFT for 5G and satellites  communications 2. Is uint16_t enough for all the
usecases?


That is a misunderstanding, probably because I did not include the definition 
and value of RTE_BBDEV_MAX_FFT_WIN on the snippet above.
The dimension of the array is purely the number of windows to choose from, ie. 
16.


Ok, where is the number of windows made available?


That is NOT an array matching the size of the FFT. In effect that width value 
is for the reference for 2048 FFT, but the actual width would be scaled down 
when a lower FFT is being set or higher for bigger FFT, so this doesn’t make 
assumption on the max FFT size, just a given portion using a reference 
resolution for 2048 FFT.


Ok, if you could document this with example that would be great.
Maybe you have some existing links explaining that?


Uint16_t is more than enough, that width cannot be more than 1024 based on 
reference above.



Since this array is quite big, could it be exposed to the application via 
dedicated
APIs instead of a field? An API to query the length of the array so that the
application can allocate required meory, and an API to copy the data in the
allocated mem?

Maybe overkill, but I feel different FFT size could be supported in the future, 
so
that would be both future proof and more memory efficient for apps that
don't need this.


Note above, let me know if unclear.


It is not clear to me how this representation is generic or specific to
your device.

Thanks,
Maxime






Let me know of opinion.


Thanks for suggesting this,
Maxime


Thanks
Nic


-Original Message-
From: Maxime Coquelin 
Sent: Tuesday, September 26, 2023 3:00 AM
To: Chautru, Nicolas ;
hemant.agra...@nxp.com; dev@dpdk.org
Cc: david.march...@redhat.com; Vargas, Hernan

Subject: Re: [PATCH v1 1/7] bbdev: add FFT version member in driver
info



On 9/22/23 18:41, Chautru, Nicolas wrote:

Hi Maxime,


-Original Message-
From: Maxime Coquelin 
Sent: Friday, September 22, 2023 1:15 AM
To: Chautru, Nicolas ;
hemant.agra...@nxp.com; dev@dpdk.org
Cc: david.march...@redhat.com; Vargas, Hernan

Subject: Re: [PATCH v1 1/7] bbdev: add FFT version member in driver
info

Hi Nicolas,

On 9/19/23 22:51, Chautru, Nicolas wrote:

Hi Maxime,

This is neither part of 3GPP per se, nor specific to VRB device.
Let me provide

more context.

The SRS processing chain

(https://doc.dpdk.org/guides/prog_guide/bbdev.html#bbdev-fft-operat
io
n) includes a pointwise multiplication by time window.

The generic API include some control of these windowing function
but still

the actual shape need to be programmed onto any device (ie.
rectangular, taped, sinc, different width or offset, any abritraty
shape defined as an array of scalars). These degrees of liberties
cannot be exposed through a generic API (information is multi-kB,
ie the data itself) and can be user specific (external to the HW IP
itself or

outside of Intel control).


Thanks for the explanations. I also did my homework as my FFT
knowledge was buried quite deep in my memory. :)

So this is a vendor-specific way to express generic paramaters.


Unsure this is that vendor specific. At least the interface allows
to know a

hash of the table being loaded (which is just pointwise data really,
non- proprietary format). I did not state the content is a simple
md5sum of the bin file being loaded from linux.

Ok, I think it would be better to provide an API to get the table
directly, and have the format being described in the documentation.

With that, we can also provide the hash as you'd like, but the method
to calculate the hash should also be provided. Or the application can
perform the hash itself if it needs it.

The fact that it is several KB is not an issue, as this information
would only be queried once at init time if really needed.

An non-DPDK alternative could be to pass such information to the pod
via the device plugin (as a mounted file for instance, or variable).


Regarding VRB device, is this table per device or per VF?
Could it be confi

Re: [PATCH v3 02/12] baseband/acc: add FFT window width in the VRB PMD

[Maxime Coquelin]

On 9/29/23 18:35, Nicolas Chautru wrote:

This allows to expose the FFT window width being introduced in
previous commit based on what is configured dynamically on the
device platform.

Signed-off-by: Nicolas Chautru 
---
  drivers/baseband/acc/acc_common.h  |  3 +++
  drivers/baseband/acc/rte_vrb_pmd.c | 29 +
  2 files changed, 32 insertions(+)

diff --git a/drivers/baseband/acc/acc_common.h 
b/drivers/baseband/acc/acc_common.h
index 5bb00746c3..7d24c644c0 100644
--- a/drivers/baseband/acc/acc_common.h
+++ b/drivers/baseband/acc/acc_common.h
@@ -512,6 +512,8 @@ struct acc_deq_intr_details {
  enum {
ACC_VF2PF_STATUS_REQUEST = 1,
ACC_VF2PF_USING_VF = 2,
+   ACC_VF2PF_LUT_VER_REQUEST = 3,
+   ACC_VF2PF_FFT_WIN_REQUEST = 4,
  };
  
  
@@ -558,6 +560,7 @@ struct acc_device {

queue_offset_fun_t queue_offset;  /* Device specific queue offset */
uint16_t num_qgroups;
uint16_t num_aqs;
+   uint16_t fft_window_width[RTE_BBDEV_MAX_FFT_WIN]; /* FFT windowing 
width. */
  };
  
  /* Structure associated with each queue. */

diff --git a/drivers/baseband/acc/rte_vrb_pmd.c 
b/drivers/baseband/acc/rte_vrb_pmd.c
index 9e5a73c9c7..c5a74bae11 100644
--- a/drivers/baseband/acc/rte_vrb_pmd.c
+++ b/drivers/baseband/acc/rte_vrb_pmd.c
@@ -298,6 +298,34 @@ vrb_device_status(struct rte_bbdev *dev)
return reg;
  }
  
+/* Request device FFT windowing information. */

+static inline void
+vrb_device_fft_win(struct rte_bbdev *dev, struct rte_bbdev_driver_info 
*dev_info)
+{
+   struct acc_device *d = dev->data->dev_private;
+   uint32_t reg, time_out = 0, win;
+
+   if (d->pf_device)
+   return;
+
+   /* Check from the device the first time. */
+   if (d->fft_window_width[0] == 0) {


O is not a possible value? Might not be a big deal as it would just
perform reading of 16 x 2 registers every time .info_get() is called,
just wondering.


+   for (win = 0; win < RTE_BBDEV_MAX_FFT_WIN; win++) {
+   vrb_vf2pf(d, ACC_VF2PF_FFT_WIN_REQUEST | win);


That looks broken, as extending RTE_BBDEV_MAX_FFT_WIN to support other
devices may break this implementation.

To me, it tends to show how this fft_window_width array is more device
specific than generic.


+   reg = acc_reg_read(d, d->reg_addr->pf2vf_doorbell);
+   while ((time_out < ACC_STATUS_TO) && (reg == 
RTE_BBDEV_DEV_NOSTATUS)) {
+   usleep(ACC_STATUS_WAIT); /*< Wait or VF->PF->VF 
Comms */
+   reg = acc_reg_read(d, 
d->reg_addr->pf2vf_doorbell);
+   time_out++;
+   }
+   d->fft_window_width[win] = reg;
+   }
+   }
+
+   for (win = 0; win < RTE_BBDEV_MAX_FFT_WIN; win++)
+   dev_info->fft_window_width[win] = d->fft_window_width[win];
+}
+
  /* Checks PF Info Ring to find the interrupt cause and handles it 
accordingly. */
  static inline void
  vrb_check_ir(struct acc_device *acc_dev)
@@ -1100,6 +1128,7 @@ vrb_dev_info_get(struct rte_bbdev *dev, struct 
rte_bbdev_driver_info *dev_info)
fetch_acc_config(dev);
/* Check the status of device. */
dev_info->device_status = vrb_device_status(dev);
+   vrb_device_fft_win(dev, dev_info);
  
  	/* Exposed number of queues. */

dev_info->num_queues[RTE_BBDEV_OP_NONE] = 0;

Re: [PATCH v3 03/12] baseband/acc: remove the 4G SO capability for VRB1

[Maxime Coquelin]

On 9/29/23 18:35, Nicolas Chautru wrote:

This removes the specific capability and support of LTE Decoder
Soft Output option on the VRB1 PMD.

This is triggered as a vendor decision to defeature the related optional
capability so that to avoid theoretical risk of race conditions
impacting the device reliability. That optional APP LLR output is
not impacting the actual decoder hard output.

Signed-off-by: Nicolas Chautru 
---
  doc/guides/bbdevs/vrb1.rst |  4 
  drivers/baseband/acc/rte_vrb_pmd.c | 10 ++
  2 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/doc/guides/bbdevs/vrb1.rst b/doc/guides/bbdevs/vrb1.rst
index 9c48d30964..fdefb20651 100644
--- a/doc/guides/bbdevs/vrb1.rst
+++ b/doc/guides/bbdevs/vrb1.rst
@@ -71,11 +71,7 @@ The Intel vRAN Boost v1.0 PMD supports the following bbdev 
capabilities:
 - ``RTE_BBDEV_TURBO_EARLY_TERMINATION``: set early termination feature.
 - ``RTE_BBDEV_TURBO_DEC_SCATTER_GATHER``: supports scatter-gather for 
input/output data.
 - ``RTE_BBDEV_TURBO_HALF_ITERATION_EVEN``: set half iteration granularity.
-   - ``RTE_BBDEV_TURBO_SOFT_OUTPUT``: set the APP LLR soft output.
-   - ``RTE_BBDEV_TURBO_EQUALIZER``: set the turbo equalizer feature.
-   - ``RTE_BBDEV_TURBO_SOFT_OUT_SATURATE``: set the soft output saturation.
 - ``RTE_BBDEV_TURBO_CONTINUE_CRC_MATCH``: set to run an extra odd 
iteration after CRC match.
-   - ``RTE_BBDEV_TURBO_NEG_LLR_1_BIT_SOFT_OUT``: set if negative APP LLR 
output supported.
 - ``RTE_BBDEV_TURBO_MAP_DEC``: supports flexible parallel MAP engine 
decoding.
  
  * For the FFT operation:

diff --git a/drivers/baseband/acc/rte_vrb_pmd.c 
b/drivers/baseband/acc/rte_vrb_pmd.c
index c5a74bae11..f11882f90e 100644
--- a/drivers/baseband/acc/rte_vrb_pmd.c
+++ b/drivers/baseband/acc/rte_vrb_pmd.c
@@ -1025,15 +1025,11 @@ vrb_dev_info_get(struct rte_bbdev *dev, struct 
rte_bbdev_driver_info *dev_info)
RTE_BBDEV_TURBO_SUBBLOCK_DEINTERLEAVE |
RTE_BBDEV_TURBO_CRC_TYPE_24B |
RTE_BBDEV_TURBO_DEC_CRC_24B_DROP |
-   RTE_BBDEV_TURBO_EQUALIZER |
-   RTE_BBDEV_TURBO_SOFT_OUT_SATURATE |
RTE_BBDEV_TURBO_HALF_ITERATION_EVEN |
RTE_BBDEV_TURBO_CONTINUE_CRC_MATCH |
-   RTE_BBDEV_TURBO_SOFT_OUTPUT |
RTE_BBDEV_TURBO_EARLY_TERMINATION |
RTE_BBDEV_TURBO_DEC_INTERRUPTS |
RTE_BBDEV_TURBO_NEG_LLR_1_BIT_IN |
-   RTE_BBDEV_TURBO_NEG_LLR_1_BIT_SOFT_OUT |
RTE_BBDEV_TURBO_MAP_DEC |
RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP |
RTE_BBDEV_TURBO_DEC_SCATTER_GATHER,
@@ -1982,6 +1978,12 @@ enqueue_dec_one_op_cb(struct acc_queue *q, struct 
rte_bbdev_dec_op *op,
struct rte_mbuf *input, *h_output_head, *h_output,
*s_output_head, *s_output;
  
+	if ((q->d->device_variant == VRB1_VARIANT) &&

+   (check_bit(op->turbo_dec.op_flags, 
RTE_BBDEV_TURBO_SOFT_OUTPUT))) {
+   /* SO not supported for VRB1. */
+   return -EPERM;
+   }
+


A better option would be to have a pointer on the device capabilities in
the acc_device struct, doing so would be more future-proof. Maybe it
could be considered?

But in the mean time, it addresses this specific issue:
Reviewed-by: Maxime Coquelin 

Thanks,
Maxime


desc = acc_desc(q, total_enqueued_cbs);
vrb_fcw_td_fill(op, &desc->req.fcw_td);
  

Re: [PATCH v3] vhost: add IRQ suppression

[Eelco Chaudron]

On 29 Sep 2023, at 12:38, Maxime Coquelin wrote:

> Guest notifications offloading, which has been introduced
> in v23.07, aims at offloading syscalls out of the datapath.
>
> This patch optimizes the offloading by not offloading the
> guest notification for a given virtqueue if one is already
> being offloaded by the application.
>
> With a single VDUSE device, we can already see few
> notifications being suppressed when doing throughput
> testing with Iperf3. We can expect to see much more being
> suppressed when the offloading thread is under pressure.
>
> Signed-off-by: Maxime Coquelin 

Thanks for adding this Maxime. I did some tests with OVS and my old determinism 
patchset, and it works perfectly.

I have two small nits, but this change looks good to me.

Acked-by: Eelco Chaudron 

> ---
>
> v3: s/0/false/ (David)
>
>  lib/vhost/vhost.c |  4 
>  lib/vhost/vhost.h | 27 +--
>  2 files changed, 25 insertions(+), 6 deletions(-)
>
> diff --git a/lib/vhost/vhost.c b/lib/vhost/vhost.c
> index c03bb9c6eb..7fde412ef3 100644
> --- a/lib/vhost/vhost.c
> +++ b/lib/vhost/vhost.c
> @@ -49,6 +49,8 @@ static const struct vhost_vq_stats_name_off 
> vhost_vq_stat_strings[] = {
>   stats.guest_notifications_offloaded)},
>   {"guest_notifications_error", offsetof(struct vhost_virtqueue,
>   stats.guest_notifications_error)},
> + {"guest_notifications_suppressed", offsetof(struct vhost_virtqueue,
> + stats.guest_notifications_suppressed)},
>   {"iotlb_hits", offsetof(struct vhost_virtqueue, 
> stats.iotlb_hits)},
>   {"iotlb_misses",   offsetof(struct vhost_virtqueue, 
> stats.iotlb_misses)},
>   {"inflight_submitted", offsetof(struct vhost_virtqueue, 
> stats.inflight_submitted)},
> @@ -1517,6 +1519,8 @@ rte_vhost_notify_guest(int vid, uint16_t queue_id)
>
>   rte_rwlock_read_lock(&vq->access_lock);
>
> + __atomic_store_n(&vq->irq_pending, false, __ATOMIC_RELEASE);
> +
>   if (dev->backend_ops->inject_irq(dev, vq)) {
>   if (dev->flags & VIRTIO_DEV_STATS_ENABLED)
>   __atomic_fetch_add(&vq->stats.guest_notifications_error,
> diff --git a/lib/vhost/vhost.h b/lib/vhost/vhost.h
> index 9723429b1c..5fc9035a1f 100644
> --- a/lib/vhost/vhost.h
> +++ b/lib/vhost/vhost.h
> @@ -156,6 +156,7 @@ struct virtqueue_stats {
>   uint64_t iotlb_misses;
>   uint64_t inflight_submitted;
>   uint64_t inflight_completed;
> + uint64_t guest_notifications_suppressed;
>   /* Counters below are atomic, and should be incremented as such. */
>   uint64_t guest_notifications;
>   uint64_t guest_notifications_offloaded;
> @@ -346,6 +347,8 @@ struct vhost_virtqueue {
>
>   struct vhost_vring_addr ring_addrs;
>   struct virtqueue_stats  stats;
> +
> + bool irq_pending;

nit: Other elements in this structure have the names aligned, not sure if this 
should be done for this item also.

>  } __rte_cache_aligned;
>
>  /* Virtio device status as per Virtio specification */
> @@ -908,12 +911,24 @@ vhost_need_event(uint16_t event_idx, uint16_t new_idx, 
> uint16_t old)
>  static __rte_always_inline void
>  vhost_vring_inject_irq(struct virtio_net *dev, struct vhost_virtqueue *vq)
>  {
> - if (dev->notify_ops->guest_notify &&
> - dev->notify_ops->guest_notify(dev->vid, vq->index)) {
> - if (dev->flags & VIRTIO_DEV_STATS_ENABLED)
> - 
> __atomic_fetch_add(&vq->stats.guest_notifications_offloaded,
> - 1, __ATOMIC_RELAXED);
> - return;
> + bool expected = false;
> +
> + if (dev->notify_ops->guest_notify) {
> + if (__atomic_compare_exchange_n(&vq->irq_pending, &expected, 
> true, 0,
> +   __ATOMIC_RELEASE, __ATOMIC_RELAXED)) {
> + if (dev->notify_ops->guest_notify(dev->vid, vq->index)) 
> {
> + if (dev->flags & VIRTIO_DEV_STATS_ENABLED)
> + 
> __atomic_fetch_add(&vq->stats.guest_notifications_offloaded,
> + 1, __ATOMIC_RELAXED);
> + return;
> + }
> +
> + /* Offloading failed, fallback to direct IRQ injection 
> */

nit: Some comments end with a dot and some do not, not sure what is the 
preference in DPDK.

> + __atomic_store_n(&vq->irq_pending, false, 
> __ATOMIC_RELEASE);
> + } else {
> + vq->stats.guest_notifications_suppressed++;
> + return;
> + }
>   }
>
>   if (dev->backend_ops->inject_irq(dev, vq)) {
> --
> 2.41.0

Re: [PATCH 0/4] support offload of simple conntrack flow rules

[Ferruh Yigit]

On 9/30/2023 11:00 AM, Chaoyong He wrote:
> This patch series add the support of simple conntrack flow rules offload
> through flower firmware by import the needed data structure and logic of
> flow merge.
> 
> Chaoyong He (4):
>   net/nfp: prepare for the flow merge
>   net/nfp: add infrastructure for ct flow merge
>

'ct' is conntrack, right? Can you prefer long version if possible?

>   net/nfp: add call to add and delete the flows to firmware
>   net/nfp: add support for merged flows and conntrack stats
> 
>  


'./devtools/check-doc-vs-code.sh' reports some errors, can you please check?

Re: [PATCH v3] vhost: add IRQ suppression

[Maxime Coquelin]

Hi Eelco,

On 10/3/23 14:36, Eelco Chaudron wrote:



On 29 Sep 2023, at 12:38, Maxime Coquelin wrote:


Guest notifications offloading, which has been introduced
in v23.07, aims at offloading syscalls out of the datapath.

This patch optimizes the offloading by not offloading the
guest notification for a given virtqueue if one is already
being offloaded by the application.

With a single VDUSE device, we can already see few
notifications being suppressed when doing throughput
testing with Iperf3. We can expect to see much more being
suppressed when the offloading thread is under pressure.

Signed-off-by: Maxime Coquelin 


Thanks for adding this Maxime. I did some tests with OVS and my old determinism 
patchset, and it works perfectly.

I have two small nits, but this change looks good to me.

Acked-by: Eelco Chaudron 


---

v3: s/0/false/ (David)

  lib/vhost/vhost.c |  4 
  lib/vhost/vhost.h | 27 +--
  2 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/lib/vhost/vhost.c b/lib/vhost/vhost.c
index c03bb9c6eb..7fde412ef3 100644
--- a/lib/vhost/vhost.c
+++ b/lib/vhost/vhost.c
@@ -49,6 +49,8 @@ static const struct vhost_vq_stats_name_off 
vhost_vq_stat_strings[] = {
stats.guest_notifications_offloaded)},
{"guest_notifications_error", offsetof(struct vhost_virtqueue,
stats.guest_notifications_error)},
+   {"guest_notifications_suppressed", offsetof(struct vhost_virtqueue,
+   stats.guest_notifications_suppressed)},
{"iotlb_hits", offsetof(struct vhost_virtqueue, 
stats.iotlb_hits)},
{"iotlb_misses",   offsetof(struct vhost_virtqueue, 
stats.iotlb_misses)},
{"inflight_submitted", offsetof(struct vhost_virtqueue, 
stats.inflight_submitted)},
@@ -1517,6 +1519,8 @@ rte_vhost_notify_guest(int vid, uint16_t queue_id)

rte_rwlock_read_lock(&vq->access_lock);

+   __atomic_store_n(&vq->irq_pending, false, __ATOMIC_RELEASE);
+
if (dev->backend_ops->inject_irq(dev, vq)) {
if (dev->flags & VIRTIO_DEV_STATS_ENABLED)
__atomic_fetch_add(&vq->stats.guest_notifications_error,
diff --git a/lib/vhost/vhost.h b/lib/vhost/vhost.h
index 9723429b1c..5fc9035a1f 100644
--- a/lib/vhost/vhost.h
+++ b/lib/vhost/vhost.h
@@ -156,6 +156,7 @@ struct virtqueue_stats {
uint64_t iotlb_misses;
uint64_t inflight_submitted;
uint64_t inflight_completed;
+   uint64_t guest_notifications_suppressed;
/* Counters below are atomic, and should be incremented as such. */
uint64_t guest_notifications;
uint64_t guest_notifications_offloaded;
@@ -346,6 +347,8 @@ struct vhost_virtqueue {

struct vhost_vring_addr ring_addrs;
struct virtqueue_stats  stats;
+
+   bool irq_pending;


nit: Other elements in this structure have the names aligned, not sure if this 
should be done for this item also.


Ha yes, you're right.
I'll fix it while applying.




  } __rte_cache_aligned;

  /* Virtio device status as per Virtio specification */
@@ -908,12 +911,24 @@ vhost_need_event(uint16_t event_idx, uint16_t new_idx, 
uint16_t old)
  static __rte_always_inline void
  vhost_vring_inject_irq(struct virtio_net *dev, struct vhost_virtqueue *vq)
  {
-   if (dev->notify_ops->guest_notify &&
-   dev->notify_ops->guest_notify(dev->vid, vq->index)) {
-   if (dev->flags & VIRTIO_DEV_STATS_ENABLED)
-   
__atomic_fetch_add(&vq->stats.guest_notifications_offloaded,
-   1, __ATOMIC_RELAXED);
-   return;
+   bool expected = false;
+
+   if (dev->notify_ops->guest_notify) {
+   if (__atomic_compare_exchange_n(&vq->irq_pending, &expected, 
true, 0,
+ __ATOMIC_RELEASE, __ATOMIC_RELAXED)) {
+   if (dev->notify_ops->guest_notify(dev->vid, vq->index)) 
{
+   if (dev->flags & VIRTIO_DEV_STATS_ENABLED)
+   
__atomic_fetch_add(&vq->stats.guest_notifications_offloaded,
+   1, __ATOMIC_RELAXED);
+   return;
+   }
+
+   /* Offloading failed, fallback to direct IRQ injection 
*/


nit: Some comments end with a dot and some do not, not sure what is the 
preference in DPDK.


I'm not sure either! I'm personally fine either way.


+   __atomic_store_n(&vq->irq_pending, false, 
__ATOMIC_RELEASE);
+   } else {
+   vq->stats.guest_notifications_suppressed++;
+   return;
+   }
}

if (dev->backend_ops->inject_irq(dev, vq)) {
--
2.41.0




Thanks,
Maxime

Re: [PATCH v3 04/12] baseband/acc: allocate FCW memory separately

[Maxime Coquelin]

On 9/29/23 18:35, Nicolas Chautru wrote:

This allows more flexibility to the FCW size for the
unified driver. No actual functional change.

Signed-off-by: Nicolas Chautru 
---
  drivers/baseband/acc/acc_common.h  |  4 +++-
  drivers/baseband/acc/rte_vrb_pmd.c | 25 -
  2 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/drivers/baseband/acc/acc_common.h 
b/drivers/baseband/acc/acc_common.h
index 7d24c644c0..2c7425e524 100644
--- a/drivers/baseband/acc/acc_common.h
+++ b/drivers/baseband/acc/acc_common.h
@@ -101,6 +101,7 @@
  #define ACC_NUM_QGRPS_PER_WORD 8
  #define ACC_MAX_NUM_QGRPS  32
  #define ACC_RING_SIZE_GRANULARITY  64
+#define ACC_MAX_FCW_SIZE  128
  
  /* Constants from K0 computation from 3GPP 38.212 Table 5.4.2.1-2 */

  #define ACC_N_ZC_1 66 /* N = 66 Zc for BG 1 */
@@ -584,13 +585,14 @@ struct __rte_cache_aligned acc_queue {
uint32_t aq_enqueued;  /* Count how many "batches" have been enqueued */
uint32_t aq_dequeued;  /* Count how many "batches" have been dequeued */
uint32_t irq_enable;  /* Enable ops dequeue interrupts if set to 1 */
-   struct rte_mempool *fcw_mempool;  /* FCW mempool */
enum rte_bbdev_op_type op_type;  /* Type of this Queue: TE or TD */
/* Internal Buffers for loopback input */
uint8_t *lb_in;
uint8_t *lb_out;
+   uint8_t *fcw_ring;
rte_iova_t lb_in_addr_iova;
rte_iova_t lb_out_addr_iova;
+   rte_iova_t fcw_ring_addr_iova;
int8_t *derm_buffer; /* interim buffer for de-rm in SDK */
struct acc_device *d;
  };
diff --git a/drivers/baseband/acc/rte_vrb_pmd.c 
b/drivers/baseband/acc/rte_vrb_pmd.c
index f11882f90e..cf0551c0c7 100644
--- a/drivers/baseband/acc/rte_vrb_pmd.c
+++ b/drivers/baseband/acc/rte_vrb_pmd.c
@@ -890,6 +890,25 @@ vrb_queue_setup(struct rte_bbdev *dev, uint16_t queue_id,
goto free_companion_ring_addr;
}
  
+	q->fcw_ring = rte_zmalloc_socket(dev->device->driver->name,

+   ACC_MAX_FCW_SIZE * d->sw_ring_max_depth,
+   RTE_CACHE_LINE_SIZE, conf->socket);
+   if (q->fcw_ring == NULL) {
+   rte_bbdev_log(ERR, "Failed to allocate fcw_ring memory");
+   ret = -ENOMEM;
+   goto free_companion_ring_addr;
+   }
+   q->fcw_ring_addr_iova = rte_malloc_virt2iova(q->fcw_ring);
+
+   /* For FFT we need to store the FCW separately */
+   if (conf->op_type == RTE_BBDEV_OP_FFT) {
+   for (desc_idx = 0; desc_idx < d->sw_ring_max_depth; desc_idx++) 
{
+   desc = q->ring_addr + desc_idx;
+   desc->req.data_ptrs[0].address = q->fcw_ring_addr_iova +
+   desc_idx * ACC_MAX_FCW_SIZE;
+   }
+   }
+
q->qgrp_id = (q_idx >> VRB1_GRP_ID_SHIFT) & 0xF;
q->vf_id = (q_idx >> VRB1_VF_ID_SHIFT)  & 0x3F;
q->aq_id = q_idx & 0xF;
@@ -1001,6 +1020,7 @@ vrb_queue_release(struct rte_bbdev *dev, uint16_t q_id)
if (q != NULL) {
/* Mark the Queue as un-assigned. */
d->q_assigned_bit_map[q->qgrp_id] &= (~0ULL - (1 << (uint64_t) 
q->aq_id));
+   rte_free(q->fcw_ring);
rte_free(q->companion_ring_addr);
rte_free(q->lb_in);
rte_free(q->lb_out);
@@ -3234,7 +3254,10 @@ vrb_enqueue_fft_one_op(struct acc_queue *q, struct 
rte_bbdev_fft_op *op,
output = op->fft.base_output.data;
in_offset = op->fft.base_input.offset;
out_offset = op->fft.base_output.offset;
-   fcw = &desc->req.fcw_fft;
+
+   fcw = (struct acc_fcw_fft *) (q->fcw_ring +
+   ((q->sw_ring_head + total_enqueued_cbs) & 
q->sw_ring_wrap_mask)
+   * ACC_MAX_FCW_SIZE);
  
  	vrb1_fcw_fft_fill(op, fcw);

vrb1_dma_desc_fft_fill(op, &desc->req, input, output, &in_offset, 
&out_offset);


Reviewed-by: Maxime Coquelin 

Thanks,
Maxime

Re: [PATCH v3 06/12] baseband/acc: refactor to allow unified driver extension

[Maxime Coquelin]

Thanks for doing the split, that will ease review.

On 9/29/23 18:35, Nicolas Chautru wrote:

Adding a few functions and common code prior to
extending the VRB driver.

Signed-off-by: Nicolas Chautru 
---
  drivers/baseband/acc/acc_common.h | 164 +++---
  drivers/baseband/acc/rte_acc100_pmd.c |   4 +-
  drivers/baseband/acc/rte_vrb_pmd.c|  62 +-
  3 files changed, 184 insertions(+), 46 deletions(-)

diff --git a/drivers/baseband/acc/acc_common.h 
b/drivers/baseband/acc/acc_common.h
index 788abf1a3c..89893eae43 100644
--- a/drivers/baseband/acc/acc_common.h
+++ b/drivers/baseband/acc/acc_common.h
@@ -18,6 +18,7 @@
  #define ACC_DMA_BLKID_OUT_HARQ  3
  #define ACC_DMA_BLKID_IN_HARQ   3
  #define ACC_DMA_BLKID_IN_MLD_R  3
+#define ACC_DMA_BLKID_DEWIN_IN  3
  
  /* Values used in filling in decode FCWs */

  #define ACC_FCW_TD_VER  1
@@ -103,6 +104,9 @@
  #define ACC_MAX_NUM_QGRPS  32
  #define ACC_RING_SIZE_GRANULARITY  64
  #define ACC_MAX_FCW_SIZE  128
+#define ACC_IQ_SIZE4
+
+#define ACC_FCW_FFT_BLEN_3 28
  
  /* Constants from K0 computation from 3GPP 38.212 Table 5.4.2.1-2 */

  #define ACC_N_ZC_1 66 /* N = 66 Zc for BG 1 */
@@ -132,6 +136,17 @@
  #define ACC_LIM_21 14 /* 0.21 */
  #define ACC_LIM_31 20 /* 0.31 */
  #define ACC_MAX_E (128 * 1024 - 2)
+#define ACC_MAX_CS 12
+
+#define ACC100_VARIANT  0
+#define VRB1_VARIANT   2
+#define VRB2_VARIANT   3
+
+/* Queue Index Hierarchy */
+#define VRB1_GRP_ID_SHIFT10
+#define VRB1_VF_ID_SHIFT 4
+#define VRB2_GRP_ID_SHIFT12
+#define VRB2_VF_ID_SHIFT 6
  
  /* Helper macro for logging */

  #define rte_acc_log(level, fmt, ...) \
@@ -332,6 +347,37 @@ struct __rte_packed acc_fcw_fft {
res:19;
  };
  
+/* FFT Frame Control Word. */

+struct __rte_packed acc_fcw_fft_3 {
+   uint32_t in_frame_size:16,
+   leading_pad_size:16;
+   uint32_t out_frame_size:16,
+   leading_depad_size:16;
+   uint32_t cs_window_sel;
+   uint32_t cs_window_sel2:16,
+   cs_enable_bmap:16;
+   uint32_t num_antennas:8,
+   idft_size:8,
+   dft_size:8,
+   cs_offset:8;
+   uint32_t idft_shift:8,
+   dft_shift:8,
+   cs_multiplier:16;
+   uint32_t bypass:2,
+   fp16_in:1,
+   fp16_out:1,
+   exp_adj:4,
+   power_shift:4,
+   power_en:1,
+   enable_dewin:1,
+   freq_resample_mode:2,
+   depad_output_size:16;
+   uint16_t cs_theta_0[ACC_MAX_CS];
+   uint32_t cs_theta_d[ACC_MAX_CS];
+   int8_t cs_time_offset[ACC_MAX_CS];
+};
+
+
  /* MLD-TS Frame Control Word */
  struct __rte_packed acc_fcw_mldts {
uint32_t fcw_version:4,
@@ -473,14 +519,14 @@ union acc_info_ring_data {
uint16_t valid: 1;
};
struct {
-   uint32_t aq_id_3: 6;
-   uint32_t qg_id_3: 5;
-   uint32_t vf_id_3: 6;
-   uint32_t int_nb_3: 6;
-   uint32_t msi_0_3: 1;
-   uint32_t vf2pf_3: 6;
-   uint32_t loop_3: 1;
-   uint32_t valid_3: 1;
+   uint32_t aq_id_vrb2: 6;
+   uint32_t qg_id_vrb2: 5;
+   uint32_t vf_id_vrb2: 6;
+   uint32_t int_nb_vrb2: 6;
+   uint32_t msi_0_vrb2: 1;
+   uint32_t vf2pf_vrb2: 6;
+   uint32_t loop_vrb2: 1;
+   uint32_t valid_vrb2: 1;
};
  } __rte_packed;
  
@@ -761,22 +807,105 @@ alloc_sw_rings_min_mem(struct rte_bbdev *dev, struct acc_device *d,

free_base_addresses(base_addrs, i);
  }
  
+/* Wrapper to provide VF index from ring data. */

+static inline uint16_t
+vf_from_ring(const union acc_info_ring_data ring_data, uint16_t 
device_variant) {


curly braces on a new line.


+   if (device_variant == VRB2_VARIANT)
+   return ring_data.vf_id_vrb2;
+   else
+   return ring_data.vf_id;
+}
+
+/* Wrapper to provide QG index from ring data. */
+static inline uint16_t
+qg_from_ring(const union acc_info_ring_data ring_data, uint16_t 
device_variant) {
+   if (device_variant == VRB2_VARIANT)
+   return ring_data.qg_id_vrb2;
+   else
+   return ring_data.qg_id;
+}
+
+/* Wrapper to provide AQ index from ring data. */
+static inline uint16_t
+aq_from_ring(const union acc_info_ring_data ring_data, uint16_t 
device_variant) {
+   if (device_variant == VRB2_VARIANT)
+   return ring_data.aq_id_vrb2;
+   else
+   return ring_data.aq_id;
+}
+
+/* Wrapper to provide int index from ring data. */
+static inline uint16_t
+int_from_ring(const union acc_info_ring_data ring_data, uint16_t 
device_variant) {
+   if (device_variant == VRB2_VARIANT)
+   return ring_data.int_nb_vrb

Re: [PATCH v3 07/12] baseband/acc: adding VRB2 device variant

[Maxime Coquelin]

On 9/29/23 18:35, Nicolas Chautru wrote:

No functionality exposed only device enumeration and
configuration.

Signed-off-by: Nicolas Chautru 
---
  doc/guides/bbdevs/features/vrb2.ini|  14 ++
  doc/guides/bbdevs/index.rst|   1 +
  doc/guides/bbdevs/vrb2.rst | 206 +
  doc/guides/rel_notes/release_23_11.rst |   3 +
  drivers/baseband/acc/rte_vrb_pmd.c | 156 +++
  drivers/baseband/acc/vrb2_pf_enum.h| 124 +++
  drivers/baseband/acc/vrb2_vf_enum.h| 121 +++
  drivers/baseband/acc/vrb_pmd.h | 161 ++-
  8 files changed, 751 insertions(+), 35 deletions(-)
  create mode 100644 doc/guides/bbdevs/features/vrb2.ini
  create mode 100644 doc/guides/bbdevs/vrb2.rst
  create mode 100644 drivers/baseband/acc/vrb2_pf_enum.h
  create mode 100644 drivers/baseband/acc/vrb2_vf_enum.h

diff --git a/doc/guides/bbdevs/features/vrb2.ini 
b/doc/guides/bbdevs/features/vrb2.ini
new file mode 100644
index 00..23ca6990b7
--- /dev/null
+++ b/doc/guides/bbdevs/features/vrb2.ini
@@ -0,0 +1,14 @@
+;
+; Supported features of the 'Intel vRAN Boost v2' baseband driver.
+;
+; Refer to default.ini for the full list of available PMD features.
+;
+[Features]
+Turbo Decoder (4G) = Y
+Turbo Encoder (4G) = Y
+LDPC Decoder (5G)  = Y
+LDPC Encoder (5G)  = Y
+LLR/HARQ Compression   = Y
+FFT/SRS= Y
+External DDR Access= N
+HW Accelerated = Y
diff --git a/doc/guides/bbdevs/index.rst b/doc/guides/bbdevs/index.rst
index 77d4c54664..269157d77f 100644
--- a/doc/guides/bbdevs/index.rst
+++ b/doc/guides/bbdevs/index.rst
@@ -15,4 +15,5 @@ Baseband Device Drivers
  fpga_5gnr_fec
  acc100
  vrb1
+vrb2
  la12xx
diff --git a/doc/guides/bbdevs/vrb2.rst b/doc/guides/bbdevs/vrb2.rst
new file mode 100644
index 00..2a30002e05
--- /dev/null
+++ b/doc/guides/bbdevs/vrb2.rst
@@ -0,0 +1,206 @@
+..  SPDX-License-Identifier: BSD-3-Clause
+Copyright(c) 2023 Intel Corporation
+
+.. include:: 
+
+Intel\ |reg| vRAN Boost v2 Poll Mode Driver (PMD)
+=
+
+The Intel\ |reg| vRAN Boost integrated accelerator enables
+cost-effective 4G and 5G next-generation virtualized Radio Access Network 
(vRAN)
+solutions.
+The Intel vRAN Boost v2.0 (VRB2 in the code) is specifically integrated on the
+Intel\ |reg| Xeon\ |reg| Granite Rapids-D Process (GNR-D).
+
+Features
+
+
+Intel vRAN Boost v2.0 includes a 5G Low Density Parity Check (LDPC) 
encoder/decoder,
+rate match/dematch, Hybrid Automatic Repeat Request (HARQ) with access to DDR
+memory for buffer management, a 4G Turbo encoder/decoder,
+a Fast Fourier Transform (FFT) block providing DFT/iDFT processing offload
+for the 5G Sounding Reference Signal (SRS), a MLD-TS accelerator, a Queue 
Manager (QMGR),
+and a DMA subsystem.
+There is no dedicated on-card memory for HARQ, the coherent memory on the CPU 
side is being used.
+
+These hardware blocks provide the following features exposed by the PMD:
+
+- LDPC Encode in the Downlink (5GNR)
+- LDPC Decode in the Uplink (5GNR)
+- Turbo Encode in the Downlink (4G)
+- Turbo Decode in the Uplink (4G)
+- FFT processing
+- MLD-TS processing
+- Single Root I/O Virtualization (SR-IOV) with 16 Virtual Functions (VFs) per 
Physical Function (PF)
+- Maximum of 2048 queues per VF
+- Message Signaled Interrupts (MSIs)
+
+The Intel vRAN Boost v2.0 PMD supports the following bbdev capabilities:
+
+* For the LDPC encode operation:
+   - ``RTE_BBDEV_LDPC_CRC_24B_ATTACH``: set to attach CRC24B to CB(s).
+   - ``RTE_BBDEV_LDPC_RATE_MATCH``: if set then do not do Rate Match bypass.
+   - ``RTE_BBDEV_LDPC_INTERLEAVER_BYPASS``: if set then bypass interleaver.
+   - ``RTE_BBDEV_LDPC_ENC_SCATTER_GATHER``: supports scatter-gather for 
input/output data.
+   - ``RTE_BBDEV_LDPC_ENC_CONCATENATION``: concatenate code blocks with bit 
granularity.
+
+* For the LDPC decode operation:
+   - ``RTE_BBDEV_LDPC_CRC_TYPE_24B_CHECK``: check CRC24B from CB(s).
+   - ``RTE_BBDEV_LDPC_CRC_TYPE_24B_DROP``: drops CRC24B bits appended while 
decoding.
+   - ``RTE_BBDEV_LDPC_CRC_TYPE_24A_CHECK``: check CRC24A from CB(s).
+   - ``RTE_BBDEV_LDPC_CRC_TYPE_16_CHECK``: check CRC16 from CB(s).
+   - ``RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE``: provides an input for HARQ 
combining.
+   - ``RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE``: provides an input for HARQ 
combining.
+   - ``RTE_BBDEV_LDPC_ITERATION_STOP_ENABLE``: disable early termination.
+   - ``RTE_BBDEV_LDPC_DEC_SCATTER_GATHER``: supports scatter-gather for 
input/output data.
+   - ``RTE_BBDEV_LDPC_HARQ_6BIT_COMPRESSION``: supports compression of the 
HARQ input/output.
+   - ``RTE_BBDEV_LDPC_LLR_COMPRESSION``: supports LLR input compression.
+   - ``RTE_BBDEV_LDPC_HARQ_4BIT_COMPRESSION``: supports compression of the 
HARQ input/output.
+   - ``RTE_BBDEV_LDPC_SOFT_OUT_ENABLE``: set the APP LLR soft output.
+   - ``RTE_BBDEV_LDP

Re: [PATCH v6 0/3] Introduce event link profiles

[Bruce Richardson]

On Tue, Oct 03, 2023 at 04:06:10PM +0530, Jerin Jacob wrote:
> On Tue, Oct 3, 2023 at 3:17 PM  wrote:
> >
> > From: Pavan Nikhilesh 
> >
> > A collection of event queues linked to an event port can be associated
> > with unique identifier called as a link profile, multiple such profiles
> > can be configured based on the event device capability using the function
> > `rte_event_port_profile_links_set` which takes arguments similar to
> > `rte_event_port_link` in addition to the profile identifier.
> >
> > The maximum link profiles that are supported by an event device is
> > advertised through the structure member
> 
> ...
> 
> >
> > v6 Changes:
> 
> Series applied to dpdk-next-net-eventdev/for-main with following changes. 
> Thanks
> 

I'm doing some investigation work on the software eventdev, using
eventdev_pipeline, and following these patches the eventdev_pipeline sample
no longer is working for me. Error message is as shown below:

Config:
ports: 2
workers: 22
packets: 33554432
Queue-prio: 0
qid0 type: ordered
Cores available: 48
Cores used: 24
Eventdev 0: event_sw
Stages:
Stage 0, Type Ordered   Priority = 128

  EVENTDEV: rte_event_port_profile_unlink() line 1092: Invalid profile_id=0
  Error setting up port 0

Parameters used when running the app:
  -l 24-47 --in-memory --vdev=event_sw0 -- \
-r 100 -t 100 -e 200 -w FC00  -c 64 -W 500

Regards,
/Bruce

Re: [PATCH v3 08/12] baseband/acc: add FEC capabilities for the VRB2 variant

[Maxime Coquelin]

On 9/29/23 18:35, Nicolas Chautru wrote:

New implementation for some of the FEC features
specific to the VRB2 variant.

Signed-off-by: Nicolas Chautru 
---
  drivers/baseband/acc/rte_vrb_pmd.c | 567 -
  1 file changed, 548 insertions(+), 19 deletions(-)

diff --git a/drivers/baseband/acc/rte_vrb_pmd.c 
b/drivers/baseband/acc/rte_vrb_pmd.c
index 48e779ce77..93add82947 100644
--- a/drivers/baseband/acc/rte_vrb_pmd.c
+++ b/drivers/baseband/acc/rte_vrb_pmd.c
@@ -1235,6 +1235,94 @@ vrb_dev_info_get(struct rte_bbdev *dev, struct 
rte_bbdev_driver_info *dev_info)
};
  
  	static const struct rte_bbdev_op_cap vrb2_bbdev_capabilities[] = {

+   {
+   .type = RTE_BBDEV_OP_TURBO_DEC,
+   .cap.turbo_dec = {
+   .capability_flags =
+   RTE_BBDEV_TURBO_SUBBLOCK_DEINTERLEAVE |
+   RTE_BBDEV_TURBO_CRC_TYPE_24B |
+   RTE_BBDEV_TURBO_DEC_CRC_24B_DROP |
+   RTE_BBDEV_TURBO_EQUALIZER |
+   RTE_BBDEV_TURBO_SOFT_OUT_SATURATE |
+   RTE_BBDEV_TURBO_HALF_ITERATION_EVEN |
+   RTE_BBDEV_TURBO_CONTINUE_CRC_MATCH |
+   RTE_BBDEV_TURBO_SOFT_OUTPUT |
+   RTE_BBDEV_TURBO_EARLY_TERMINATION |
+   RTE_BBDEV_TURBO_DEC_INTERRUPTS |
+   RTE_BBDEV_TURBO_NEG_LLR_1_BIT_IN |
+   RTE_BBDEV_TURBO_NEG_LLR_1_BIT_SOFT_OUT |
+   RTE_BBDEV_TURBO_MAP_DEC |
+   RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP |
+   RTE_BBDEV_TURBO_DEC_SCATTER_GATHER,
+   .max_llr_modulus = INT8_MAX,
+   .num_buffers_src =
+   RTE_BBDEV_TURBO_MAX_CODE_BLOCKS,
+   .num_buffers_hard_out =
+   RTE_BBDEV_TURBO_MAX_CODE_BLOCKS,
+   .num_buffers_soft_out =
+   RTE_BBDEV_TURBO_MAX_CODE_BLOCKS,
+   }
+   },
+   {
+   .type = RTE_BBDEV_OP_TURBO_ENC,
+   .cap.turbo_enc = {
+   .capability_flags =
+   RTE_BBDEV_TURBO_CRC_24B_ATTACH |
+   RTE_BBDEV_TURBO_RV_INDEX_BYPASS |
+   RTE_BBDEV_TURBO_RATE_MATCH |
+   RTE_BBDEV_TURBO_ENC_INTERRUPTS |
+   RTE_BBDEV_TURBO_ENC_SCATTER_GATHER,
+   .num_buffers_src =
+   RTE_BBDEV_TURBO_MAX_CODE_BLOCKS,
+   .num_buffers_dst =
+   RTE_BBDEV_TURBO_MAX_CODE_BLOCKS,
+   }
+   },
+   {
+   .type   = RTE_BBDEV_OP_LDPC_ENC,
+   .cap.ldpc_enc = {
+   .capability_flags =
+   RTE_BBDEV_LDPC_RATE_MATCH |
+   RTE_BBDEV_LDPC_CRC_24B_ATTACH |
+   RTE_BBDEV_LDPC_INTERLEAVER_BYPASS |
+   RTE_BBDEV_LDPC_ENC_INTERRUPTS |
+   RTE_BBDEV_LDPC_ENC_SCATTER_GATHER |
+   RTE_BBDEV_LDPC_ENC_CONCATENATION,
+   .num_buffers_src =
+   RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
+   .num_buffers_dst =
+   RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
+   }
+   },
+   {
+   .type   = RTE_BBDEV_OP_LDPC_DEC,
+   .cap.ldpc_dec = {
+   .capability_flags =
+   RTE_BBDEV_LDPC_CRC_TYPE_24B_CHECK |
+   RTE_BBDEV_LDPC_CRC_TYPE_24B_DROP |
+   RTE_BBDEV_LDPC_CRC_TYPE_24A_CHECK |
+   RTE_BBDEV_LDPC_CRC_TYPE_16_CHECK |
+   RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE |
+   RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE |
+   RTE_BBDEV_LDPC_ITERATION_STOP_ENABLE |
+   RTE_BBDEV_LDPC_DEINTERLEAVER_BYPASS |
+   RTE_BBDEV_LDPC_

Re: [PATCH v3 09/12] baseband/acc: add FFT support to VRB2 variant

[Maxime Coquelin]

On 9/29/23 18:35, Nicolas Chautru wrote:

Support for the FFT the processing specific to the
VRB2 variant.

Signed-off-by: Nicolas Chautru 
---
  drivers/baseband/acc/rte_vrb_pmd.c | 132 -
  1 file changed, 128 insertions(+), 4 deletions(-)

diff --git a/drivers/baseband/acc/rte_vrb_pmd.c 
b/drivers/baseband/acc/rte_vrb_pmd.c
index 93add82947..ce4b90d8e7 100644
--- a/drivers/baseband/acc/rte_vrb_pmd.c
+++ b/drivers/baseband/acc/rte_vrb_pmd.c
@@ -903,6 +903,9 @@ vrb_queue_setup(struct rte_bbdev *dev, uint16_t queue_id,
ACC_FCW_LD_BLEN : (conf->op_type == RTE_BBDEV_OP_FFT ?
ACC_FCW_FFT_BLEN : ACC_FCW_MLDTS_BLEN;
  
+	if ((q->d->device_variant == VRB2_VARIANT) && (conf->op_type == RTE_BBDEV_OP_FFT))

+   fcw_len = ACC_FCW_FFT_BLEN_3;
+
for (desc_idx = 0; desc_idx < d->sw_ring_max_depth; desc_idx++) {
desc = q->ring_addr + desc_idx;
desc->req.word0 = ACC_DMA_DESC_TYPE;
@@ -1323,6 +1326,24 @@ vrb_dev_info_get(struct rte_bbdev *dev, struct 
rte_bbdev_driver_info *dev_info)
.num_buffers_soft_out = 0,
}
},
+   {
+   .type   = RTE_BBDEV_OP_FFT,
+   .cap.fft = {
+   .capability_flags =
+   RTE_BBDEV_FFT_WINDOWING |
+   RTE_BBDEV_FFT_CS_ADJUSTMENT |
+   RTE_BBDEV_FFT_DFT_BYPASS |
+   RTE_BBDEV_FFT_IDFT_BYPASS |
+   RTE_BBDEV_FFT_FP16_INPUT |
+   RTE_BBDEV_FFT_FP16_OUTPUT |
+   RTE_BBDEV_FFT_POWER_MEAS |
+   RTE_BBDEV_FFT_WINDOWING_BYPASS,
+   .num_buffers_src =
+   1,
+   .num_buffers_dst =
+   1,
+   }
+   },
RTE_BBDEV_END_OF_CAPABILITIES_LIST()
};
  
@@ -3849,6 +3870,47 @@ vrb1_fcw_fft_fill(struct rte_bbdev_fft_op *op, struct acc_fcw_fft *fcw)

fcw->bypass = 0;
  }
  
+/* Fill in a frame control word for FFT processing. */

+static inline void
+vrb2_fcw_fft_fill(struct rte_bbdev_fft_op *op, struct acc_fcw_fft_3 *fcw)
+{
+   fcw->in_frame_size = op->fft.input_sequence_size;
+   fcw->leading_pad_size = op->fft.input_leading_padding;
+   fcw->out_frame_size = op->fft.output_sequence_size;
+   fcw->leading_depad_size = op->fft.output_leading_depadding;
+   fcw->cs_window_sel = op->fft.window_index[0] +
+   (op->fft.window_index[1] << 8) +
+   (op->fft.window_index[2] << 16) +
+   (op->fft.window_index[3] << 24);
+   fcw->cs_window_sel2 = op->fft.window_index[4] +
+   (op->fft.window_index[5] << 8);
+   fcw->cs_enable_bmap = op->fft.cs_bitmap;
+   fcw->num_antennas = op->fft.num_antennas_log2;
+   fcw->idft_size = op->fft.idft_log2;
+   fcw->dft_size = op->fft.dft_log2;
+   fcw->cs_offset = op->fft.cs_time_adjustment;
+   fcw->idft_shift = op->fft.idft_shift;
+   fcw->dft_shift = op->fft.dft_shift;
+   fcw->cs_multiplier = op->fft.ncs_reciprocal;
+   fcw->power_shift = op->fft.power_shift; > +fcw->exp_adj = 
op->fft.fp16_exp_adjust;
+   fcw->fp16_in = check_bit(op->fft.op_flags, RTE_BBDEV_FFT_FP16_INPUT);
+   fcw->fp16_out = check_bit(op->fft.op_flags, RTE_BBDEV_FFT_FP16_OUTPUT);
+   fcw->power_en = check_bit(op->fft.op_flags, RTE_BBDEV_FFT_POWER_MEAS);
+   if (check_bit(op->fft.op_flags,
+   RTE_BBDEV_FFT_IDFT_BYPASS)) {
+   if (check_bit(op->fft.op_flags,
+   RTE_BBDEV_FFT_WINDOWING_BYPASS))
+   fcw->bypass = 2;
+   else
+   fcw->bypass = 1;
+   } else if (check_bit(op->fft.op_flags,
+   RTE_BBDEV_FFT_DFT_BYPASS))
+   fcw->bypass = 3;
+   else
+   fcw->bypass = 0;


The only difference I see with VRB1 are backed by corresponding op_flags
(POWER & FP16), is that correct? If so, it does not make sense to me to
have a specific fucntion for VRB2.


+}
+
  static inline int
  vrb1_dma_desc_fft_fill(struct rte_bbdev_fft_op *op,
struct acc_dma_req_desc *desc,
@@ -3882,6 +3944,58 @@ vrb1_dma_desc_fft_fill(struct rte_bbdev_fft_op *op,
return 0;
  }
  
+static inline int

+vrb2_dma_desc_fft_fill(struct rte_bbdev_fft_op *op,
+   struct acc_dma_req_desc *desc,
+   struct rte_mbuf *input, struct rte_mbuf *output, struct 
rte_mbuf *win

[PATCH] eventdev: fix port link and unlink

[pbhagavatula]

From: Pavan Nikhilesh 

Port link and unlink rely on info get API to validate max
supported profiles, the default max profiles is initialized
in ``rte_dev_info_get`` API, use it instead of invoking
driver callback.

Fixes: 162aa4e1b479 ("eventdev: introduce link profiles")

Signed-off-by: Pavan Nikhilesh 
---
- Please Squash

 lib/eventdev/rte_eventdev.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/lib/eventdev/rte_eventdev.c b/lib/eventdev/rte_eventdev.c
index 5ee8bd665b..27b819d605 100644
--- a/lib/eventdev/rte_eventdev.c
+++ b/lib/eventdev/rte_eventdev.c
@@ -995,10 +995,10 @@ rte_event_port_profile_links_set(uint8_t dev_id, uint8_t 
port_id, const uint8_t
RTE_EVENTDEV_VALID_DEVID_OR_ERRNO_RET(dev_id, EINVAL, 0);
dev = &rte_eventdevs[dev_id];

-   if (*dev->dev_ops->dev_infos_get == NULL)
-   return -ENOTSUP;
+   diag = rte_event_dev_info_get(dev_id, &info);
+   if (diag < 0)
+   return diag;

-   (*dev->dev_ops->dev_infos_get)(dev, &info);
if (profile_id >= RTE_EVENT_MAX_PROFILES_PER_PORT ||
profile_id >= info.max_profiles_per_port) {
RTE_EDEV_LOG_ERR("Invalid profile_id=%" PRIu8, profile_id);
@@ -1083,10 +1083,10 @@ rte_event_port_profile_unlink(uint8_t dev_id, uint8_t 
port_id, uint8_t queues[],
RTE_EVENTDEV_VALID_DEVID_OR_ERRNO_RET(dev_id, EINVAL, 0);
dev = &rte_eventdevs[dev_id];

-   if (*dev->dev_ops->dev_infos_get == NULL)
-   return -ENOTSUP;
+   diag = rte_event_dev_info_get(dev_id, &info);
+   if (diag < 0)
+   return diag;

-   (*dev->dev_ops->dev_infos_get)(dev, &info);
if (profile_id >= RTE_EVENT_MAX_PROFILES_PER_PORT ||
profile_id >= info.max_profiles_per_port) {
RTE_EDEV_LOG_ERR("Invalid profile_id=%" PRIu8, profile_id);
@@ -1223,12 +1223,12 @@ rte_event_port_profile_links_get(uint8_t dev_id, 
uint8_t port_id, uint8_t queues
int i, count = 0;

RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, -EINVAL);
-
dev = &rte_eventdevs[dev_id];
-   if (*dev->dev_ops->dev_infos_get == NULL)
-   return -ENOTSUP;

-   (*dev->dev_ops->dev_infos_get)(dev, &info);
+   diag = rte_event_dev_info_get(dev_id, &info);
+   if (diag < 0)
+   return diag;
+
if (profile_id >= RTE_EVENT_MAX_PROFILES_PER_PORT ||
profile_id >= info.max_profiles_per_port) {
RTE_EDEV_LOG_ERR("Invalid profile_id=%" PRIu8, profile_id);
--
2.25.1

[PATCH v2] eventdev: fix port link and unlink

[pbhagavatula]

From: Pavan Nikhilesh 

Port link and unlink rely on info get API to validate max
supported profiles, the default max profiles is initialized
in ``rte_dev_info_get`` API, use it instead of invoking
driver callback.

Fixes: 162aa4e1b479 ("eventdev: introduce link profiles")

Signed-off-by: Pavan Nikhilesh 
---
 lib/eventdev/rte_eventdev.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/lib/eventdev/rte_eventdev.c b/lib/eventdev/rte_eventdev.c
index 5ee8bd665b..64fd5a70ae 100644
--- a/lib/eventdev/rte_eventdev.c
+++ b/lib/eventdev/rte_eventdev.c
@@ -995,10 +995,10 @@ rte_event_port_profile_links_set(uint8_t dev_id, uint8_t 
port_id, const uint8_t
RTE_EVENTDEV_VALID_DEVID_OR_ERRNO_RET(dev_id, EINVAL, 0);
dev = &rte_eventdevs[dev_id];
 
-   if (*dev->dev_ops->dev_infos_get == NULL)
-   return -ENOTSUP;
+   diag = rte_event_dev_info_get(dev_id, &info);
+   if (diag < 0)
+   return diag;
 
-   (*dev->dev_ops->dev_infos_get)(dev, &info);
if (profile_id >= RTE_EVENT_MAX_PROFILES_PER_PORT ||
profile_id >= info.max_profiles_per_port) {
RTE_EDEV_LOG_ERR("Invalid profile_id=%" PRIu8, profile_id);
@@ -1083,10 +1083,10 @@ rte_event_port_profile_unlink(uint8_t dev_id, uint8_t 
port_id, uint8_t queues[],
RTE_EVENTDEV_VALID_DEVID_OR_ERRNO_RET(dev_id, EINVAL, 0);
dev = &rte_eventdevs[dev_id];
 
-   if (*dev->dev_ops->dev_infos_get == NULL)
-   return -ENOTSUP;
+   diag = rte_event_dev_info_get(dev_id, &info);
+   if (diag < 0)
+   return diag;
 
-   (*dev->dev_ops->dev_infos_get)(dev, &info);
if (profile_id >= RTE_EVENT_MAX_PROFILES_PER_PORT ||
profile_id >= info.max_profiles_per_port) {
RTE_EDEV_LOG_ERR("Invalid profile_id=%" PRIu8, profile_id);
@@ -1219,16 +1219,16 @@ rte_event_port_profile_links_get(uint8_t dev_id, 
uint8_t port_id, uint8_t queues
 {
struct rte_event_dev_info info;
struct rte_eventdev *dev;
+   int i, diag, count = 0;
uint16_t *links_map;
-   int i, count = 0;
 
RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, -EINVAL);
-
dev = &rte_eventdevs[dev_id];
-   if (*dev->dev_ops->dev_infos_get == NULL)
-   return -ENOTSUP;
 
-   (*dev->dev_ops->dev_infos_get)(dev, &info);
+   diag = rte_event_dev_info_get(dev_id, &info);
+   if (diag < 0)
+   return diag;
+
if (profile_id >= RTE_EVENT_MAX_PROFILES_PER_PORT ||
profile_id >= info.max_profiles_per_port) {
RTE_EDEV_LOG_ERR("Invalid profile_id=%" PRIu8, profile_id);
-- 
2.25.1

Re: [PATCH v3 10/12] baseband/acc: add MLD support in VRB2 variant

[Maxime Coquelin]

On 9/29/23 18:35, Nicolas Chautru wrote:

Adding the capability for the MLD-TS processing specific to
the VRB2 variant.

Signed-off-by: Nicolas Chautru 
---
  drivers/baseband/acc/rte_vrb_pmd.c | 378 +
  1 file changed, 378 insertions(+)

diff --git a/drivers/baseband/acc/rte_vrb_pmd.c 
b/drivers/baseband/acc/rte_vrb_pmd.c
index ce4b90d8e7..a9d3db86e6 100644
--- a/drivers/baseband/acc/rte_vrb_pmd.c
+++ b/drivers/baseband/acc/rte_vrb_pmd.c
@@ -1344,6 +1344,17 @@ vrb_dev_info_get(struct rte_bbdev *dev, struct 
rte_bbdev_driver_info *dev_info)
1,
}
},
+   {
+   .type   = RTE_BBDEV_OP_MLDTS,
+   .cap.mld = {
+   .capability_flags =
+   RTE_BBDEV_MLDTS_REP,
+   .num_buffers_src =
+   1,
+   .num_buffers_dst =
+   1,
+   }
+   },
RTE_BBDEV_END_OF_CAPABILITIES_LIST()
};
  
@@ -4151,6 +4162,371 @@ vrb_dequeue_fft(struct rte_bbdev_queue_data *q_data,

return i;
  }
  
+/* Fill in a frame control word for MLD-TS processing. */

+static inline void
+vrb2_fcw_mldts_fill(struct rte_bbdev_mldts_op *op, struct acc_fcw_mldts *fcw)
+{
+   fcw->nrb = op->mldts.num_rbs;
+   fcw->NLayers = op->mldts.num_layers - 1;
+   fcw->Qmod0 = (op->mldts.q_m[0] >> 1) - 1;
+   fcw->Qmod1 = (op->mldts.q_m[1] >> 1) - 1;
+   fcw->Qmod2 = (op->mldts.q_m[2] >> 1) - 1;
+   fcw->Qmod3 = (op->mldts.q_m[3] >> 1) - 1;
+   /* Mark some layers as disabled */
+   if (op->mldts.num_layers == 2) {
+   fcw->Qmod2 = 3;
+   fcw->Qmod3 = 3;
+   }
+   if (op->mldts.num_layers == 3)
+   fcw->Qmod3 = 3;
+   fcw->Rrep = op->mldts.r_rep;
+   fcw->Crep = op->mldts.c_rep;
+}
+
+/* Fill in descriptor for one MLD-TS processing operation. */
+static inline int
+vrb2_dma_desc_mldts_fill(struct rte_bbdev_mldts_op *op,
+   struct acc_dma_req_desc *desc,
+   struct rte_mbuf *input_q, struct rte_mbuf *input_r,
+   struct rte_mbuf *output,
+   uint32_t *in_offset, uint32_t *out_offset)
+{
+   uint16_t qsize_per_re[VRB2_MLD_LAY_SIZE] = {8, 12, 16}; /* Layer 2 to 
4. */
+   uint16_t rsize_per_re[VRB2_MLD_LAY_SIZE] = {14, 26, 42};
+   uint16_t sc_factor_per_rrep[VRB2_MLD_RREP_SIZE] = {12, 6, 4, 3, 0, 2};
+   uint16_t i, outsize_per_re = 0;
+   uint32_t sc_num, r_num, q_size, r_size, out_size;
+
+   /* Prevent out of range access. */
+   if (op->mldts.r_rep > 5)
+   op->mldts.r_rep = 5;
+   if (op->mldts.num_layers < 2)
+   op->mldts.num_layers = 2;
+   if (op->mldts.num_layers > 4)
+   op->mldts.num_layers = 4;
+   for (i = 0; i < op->mldts.num_layers; i++)
+   outsize_per_re += op->mldts.q_m[i];
+   sc_num = op->mldts.num_rbs * RTE_BBDEV_SCPERRB * (op->mldts.c_rep + 1);
+   r_num = op->mldts.num_rbs * sc_factor_per_rrep[op->mldts.r_rep];
+   q_size = qsize_per_re[op->mldts.num_layers - 2] * sc_num;
+   r_size = rsize_per_re[op->mldts.num_layers - 2] * r_num;
+   out_size =  sc_num * outsize_per_re;
+   /* printf("Sc %d R num %d Size %d %d %d\n", sc_num, r_num, q_size, 
r_size, out_size); */


rte_bbdev_log_debug()? Otherwise just remove it.


+
+   /* FCW already done. */
+   acc_header_init(desc);
+   desc->data_ptrs[1].address = rte_pktmbuf_iova_offset(input_q, 
*in_offset);
+   desc->data_ptrs[1].blen = q_size;
+   desc->data_ptrs[1].blkid = ACC_DMA_BLKID_IN;
+   desc->data_ptrs[1].last = 0;
+   desc->data_ptrs[1].dma_ext = 0;
+   desc->data_ptrs[2].address = rte_pktmbuf_iova_offset(input_r, 
*in_offset);
+   desc->data_ptrs[2].blen = r_size;
+   desc->data_ptrs[2].blkid = ACC_DMA_BLKID_IN_MLD_R;
+   desc->data_ptrs[2].last = 1;
+   desc->data_ptrs[2].dma_ext = 0;
+   desc->data_ptrs[3].address = rte_pktmbuf_iova_offset(output, 
*out_offset);
+   desc->data_ptrs[3].blen = out_size;
+   desc->data_ptrs[3].blkid = ACC_DMA_BLKID_OUT_HARD;
+   desc->data_ptrs[3].last = 1;
+   desc->data_ptrs[3].dma_ext = 0;
+   desc->m2dlen = 3;
+   desc->d2mlen = 1;
+   desc->op_addr = op;
+   desc->cbs_in_tb = 1;
+
+   return 0;
+}
+
+/* Check whether the MLD operation can be processed as a single operation. */
+static inline bool
+vrb2_check_mld_r_constraint(struct rte_bbdev_mldts_op *op) {
+   uint8_t layer_idx, rrep_idx;
+   uint16_t max_rb[VRB2_MLD_LAY_SIZE][VRB2_MLD_RREP_SIZE] = {
+   {188, 275, 275, 275, 0, 275},
+   {101, 202, 275, 275, 0, 275},
+ 

Re: [PATCH v3 11/12] baseband/acc: add support for VRB2 engine error detection

[Maxime Coquelin]

On 9/29/23 18:35, Nicolas Chautru wrote:

Adding missing incremental functionality for the VRB2
variant. Notably detection of engine error during the
dequeue. Minor cosmetic edits.

Signed-off-by: Nicolas Chautru 
---
  drivers/baseband/acc/rte_vrb_pmd.c  | 20 
  drivers/baseband/acc/vrb1_pf_enum.h | 17 -
  2 files changed, 24 insertions(+), 13 deletions(-)

diff --git a/drivers/baseband/acc/rte_vrb_pmd.c 
b/drivers/baseband/acc/rte_vrb_pmd.c
index a9d3db86e6..3eb1a380fc 100644
--- a/drivers/baseband/acc/rte_vrb_pmd.c
+++ b/drivers/baseband/acc/rte_vrb_pmd.c
@@ -1504,6 +1504,7 @@ vrb_fcw_td_fill(const struct rte_bbdev_dec_op *op, struct 
acc_fcw_td *fcw)
fcw->ea = op->turbo_dec.cb_params.e;
fcw->eb = op->turbo_dec.cb_params.e;
}
+
if (op->turbo_dec.rv_index == 0)
fcw->k0_start_col = ACC_FCW_TD_RVIDX_0;
else if (op->turbo_dec.rv_index == 1)
@@ -2304,7 +2305,7 @@ enqueue_ldpc_enc_n_op_cb(struct acc_queue *q, struct 
rte_bbdev_enc_op **ops,
return num;
  }
  
-/* Enqueue one encode operations for device for a partial TB

+/* Enqueue one encode operations for VRB1 device for a partial TB
   * all codes blocks have same configuration multiplexed on the same 
descriptor.
   */
  static inline void
@@ -2649,7 +2650,7 @@ enqueue_dec_one_op_cb(struct acc_queue *q, struct 
rte_bbdev_dec_op *op,
return 1;
  }
  
-/** Enqueue one decode operations for device in CB mode */

+/** Enqueue one decode operations for device in CB mode. */
  static inline int
  vrb_enqueue_ldpc_dec_one_op_cb(struct acc_queue *q, struct rte_bbdev_dec_op 
*op,
uint16_t total_enqueued_cbs, bool same_op)
@@ -2801,7 +2802,6 @@ vrb_enqueue_ldpc_dec_one_op_tb(struct acc_queue *q, 
struct rte_bbdev_dec_op *op,
desc->req.data_ptrs[0].blen = ACC_FCW_LD_BLEN;
rte_memcpy(&desc->req.fcw_ld, &desc_first->req.fcw_ld, 
ACC_FCW_LD_BLEN);
desc->req.fcw_ld.tb_trailer_size = (c - r - 1) * trail_len;
-
if (q->d->device_variant == VRB1_VARIANT)
ret = vrb1_dma_desc_ld_fill(op, &desc->req, &input,
h_output, &in_offset, &h_out_offset,
@@ -3226,7 +3226,6 @@ vrb_enqueue_ldpc_dec_cb(struct rte_bbdev_queue_data 
*q_data,
break;
}
avail -= 1;
-


Is it intentionnally removed?


rte_bbdev_log(INFO, "Op %d %d %d %d %d %d %d %d %d %d %d %d\n",
i, ops[i]->ldpc_dec.op_flags, ops[i]->ldpc_dec.rv_index,
ops[i]->ldpc_dec.iter_max, ops[i]->ldpc_dec.iter_count,
@@ -3354,6 +3353,7 @@ vrb_dequeue_enc_one_op_cb(struct acc_queue *q, struct 
rte_bbdev_enc_op **ref_op,
op->status |= ((rsp.input_err) ? (1 << RTE_BBDEV_DATA_ERROR) : 0);
op->status |= ((rsp.dma_err) ? (1 << RTE_BBDEV_DRV_ERROR) : 0);
op->status |= ((rsp.fcw_err) ? (1 << RTE_BBDEV_DRV_ERROR) : 0);
+   op->status |= ((rsp.engine_hung) ? (1 << RTE_BBDEV_ENGINE_ERROR) : 0);
  
  	if (desc->req.last_desc_in_batch) {

(*aq_dequeued)++;
@@ -3470,6 +3470,7 @@ vrb_dequeue_enc_one_op_tb(struct acc_queue *q, struct 
rte_bbdev_enc_op **ref_op,
op->status |= ((rsp.input_err) ? (1 << RTE_BBDEV_DATA_ERROR) : 
0);
op->status |= ((rsp.dma_err) ? (1 << RTE_BBDEV_DRV_ERROR) : 0);
op->status |= ((rsp.fcw_err) ? (1 << RTE_BBDEV_DRV_ERROR) : 0);
+   op->status |= ((rsp.engine_hung) ? (1 << 
RTE_BBDEV_ENGINE_ERROR) : 0);
  
  		if (desc->req.last_desc_in_batch) {

(*aq_dequeued)++;
@@ -3516,6 +3517,8 @@ vrb_dequeue_dec_one_op_cb(struct rte_bbdev_queue_data 
*q_data,
op->status |= ((rsp.input_err) ? (1 << RTE_BBDEV_DATA_ERROR) : 0);
op->status |= ((rsp.dma_err) ? (1 << RTE_BBDEV_DRV_ERROR) : 0);
op->status |= ((rsp.fcw_err) ? (1 << RTE_BBDEV_DRV_ERROR) : 0);
+   op->status |= rsp.engine_hung << RTE_BBDEV_ENGINE_ERROR;
+
if (op->status != 0) {
/* These errors are not expected. */
q_data->queue_stats.dequeue_err_count++;
@@ -3569,6 +3572,7 @@ vrb_dequeue_ldpc_dec_one_op_cb(struct 
rte_bbdev_queue_data *q_data,
op->status |= rsp.input_err << RTE_BBDEV_DATA_ERROR;
op->status |= rsp.dma_err << RTE_BBDEV_DRV_ERROR;
op->status |= rsp.fcw_err << RTE_BBDEV_DRV_ERROR;
+   op->status |= rsp.engine_hung << RTE_BBDEV_ENGINE_ERROR;
if (op->status != 0)
q_data->queue_stats.dequeue_err_count++;
  
@@ -3650,6 +3654,7 @@ vrb_dequeue_dec_one_op_tb(struct acc_queue *q, struct rte_bbdev_dec_op **ref_op,

op->status |= ((rsp.input_err) ? (1 << RTE_BBDEV_DATA_ERROR) : 
0);
op->status |= ((rsp.dma_err) ? (1 << RTE_BB

Re: [PATCH v6 0/3] Introduce event link profiles

[Jerin Jacob]

On Tue, Oct 3, 2023 at 7:43 PM Bruce Richardson
 wrote:
>
> On Tue, Oct 03, 2023 at 04:06:10PM +0530, Jerin Jacob wrote:
> > On Tue, Oct 3, 2023 at 3:17 PM  wrote:
> > >
> > > From: Pavan Nikhilesh 
> > >
> > > A collection of event queues linked to an event port can be associated
> > > with unique identifier called as a link profile, multiple such profiles
> > > can be configured based on the event device capability using the function
> > > `rte_event_port_profile_links_set` which takes arguments similar to
> > > `rte_event_port_link` in addition to the profile identifier.
> > >
> > > The maximum link profiles that are supported by an event device is
> > > advertised through the structure member
> >
> > ...
> >
> > >
> > > v6 Changes:
> >
> > Series applied to dpdk-next-net-eventdev/for-main with following changes. 
> > Thanks
> >
>
> I'm doing some investigation work on the software eventdev, using
> eventdev_pipeline, and following these patches the eventdev_pipeline sample
> no longer is working for me. Error message is as shown below:
>
> Config:
> ports: 2
> workers: 22
> packets: 33554432
> Queue-prio: 0
> qid0 type: ordered
> Cores available: 48
> Cores used: 24
> Eventdev 0: event_sw
> Stages:
> Stage 0, Type Ordered   Priority = 128
>
>   EVENTDEV: rte_event_port_profile_unlink() line 1092: Invalid profile_id=0
>   Error setting up port 0
>
> Parameters used when running the app:
>   -l 24-47 --in-memory --vdev=event_sw0 -- \
> -r 100 -t 100 -e 200 -w FC00  -c 64 -W 500


Following max_profiles_per_port = 1 is getting overridden in [1]. I
was suggested to take this path to avoid driver changes.
Looks like we can not rely on common code. @Pavan Nikhilesh  Could you
change to your old version(where every driver changes to add
max_profiles_per_port = 1).
I will squash it.

diff --git a/lib/eventdev/rte_eventdev.c b/lib/eventdev/rte_eventdev.c
index 60509c6efb..5ee8bd665b 100644
--- a/lib/eventdev/rte_eventdev.c
+++ b/lib/eventdev/rte_eventdev.c
@@ -96,6 +96,7 @@  rte_event_dev_info_get(uint8_t dev_id, struct
rte_event_dev_info *dev_info)
  return -EINVAL;

  memset(dev_info, 0, sizeof(struct rte_event_dev_info));
+ dev_info->max_profiles_per_port = 1;

[1]
static void
sw_info_get(struct rte_eventdev *dev, struct rte_event_dev_info *info)
{
RTE_SET_USED(dev);

static const struct rte_event_dev_info evdev_sw_info = {
.driver_name = SW_PMD_NAME,
.max_event_queues = RTE_EVENT_MAX_QUEUES_PER_DEV,
.max_event_queue_flows = SW_QID_NUM_FIDS,
.max_event_queue_priority_levels = SW_Q_PRIORITY_MAX,
.max_event_priority_levels = SW_IQS_MAX,
.max_event_ports = SW_PORTS_MAX,
.max_event_port_dequeue_depth = MAX_SW_CONS_Q_DEPTH,
.max_event_port_enqueue_depth = MAX_SW_PROD_Q_DEPTH,
.max_num_events = SW_INFLIGHT_EVENTS_TOTAL,
.event_dev_cap = (
RTE_EVENT_DEV_CAP_QUEUE_QOS |
RTE_EVENT_DEV_CAP_BURST_MODE |
RTE_EVENT_DEV_CAP_EVENT_QOS |
RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE|
RTE_EVENT_DEV_CAP_RUNTIME_PORT_LINK |
RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT |
RTE_EVENT_DEV_CAP_NONSEQ_MODE |
RTE_EVENT_DEV_CAP_CARRY_FLOW_ID |
RTE_EVENT_DEV_CAP_MAINTENANCE_FREE),
};

*info = evdev_sw_info;
}


>
> Regards,
> /Bruce

[PATCH] eventdev: fix max link profiles info

[pbhagavatula]

From: Pavan Nikhilesh 

Since most of the drivers overwrite the info structure passed
from the common layer it is not possible to set defaults in
``rte_event_dev_info_get`` API.
Initialize default max_profiles_per_port in the driver layer.

Fixes: 162aa4e1b479 ("eventdev: introduce link profiles")

Signed-off-by: Pavan Nikhilesh 
---
Please squash to 162aa4e1b479

 drivers/event/dlb2/dlb2.c  | 1 +
 drivers/event/dpaa/dpaa_eventdev.c | 1 +
 drivers/event/dpaa2/dpaa2_eventdev.c   | 2 +-
 drivers/event/dsw/dsw_evdev.c  | 1 +
 drivers/event/octeontx/ssovf_evdev.c   | 2 +-
 drivers/event/opdl/opdl_evdev.c| 1 +
 drivers/event/skeleton/skeleton_eventdev.c | 1 +
 drivers/event/sw/sw_evdev.c| 1 +
 lib/eventdev/rte_eventdev.c| 1 -
 9 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/event/dlb2/dlb2.c b/drivers/event/dlb2/dlb2.c
index cf2764364f..e645f7595a 100644
--- a/drivers/event/dlb2/dlb2.c
+++ b/drivers/event/dlb2/dlb2.c
@@ -79,6 +79,7 @@ static struct rte_event_dev_info evdev_dlb2_default_info = {
  RTE_EVENT_DEV_CAP_RUNTIME_PORT_LINK |
  RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT |
  RTE_EVENT_DEV_CAP_MAINTENANCE_FREE),
+   .max_profiles_per_port = 1,
 };

 struct process_local_port_data
diff --git a/drivers/event/dpaa/dpaa_eventdev.c 
b/drivers/event/dpaa/dpaa_eventdev.c
index 4b3d16735b..f615da3813 100644
--- a/drivers/event/dpaa/dpaa_eventdev.c
+++ b/drivers/event/dpaa/dpaa_eventdev.c
@@ -359,6 +359,7 @@ dpaa_event_dev_info_get(struct rte_eventdev *dev,
RTE_EVENT_DEV_CAP_NONSEQ_MODE |
RTE_EVENT_DEV_CAP_CARRY_FLOW_ID |
RTE_EVENT_DEV_CAP_MAINTENANCE_FREE;
+   dev_info->max_profiles_per_port = 1;
 }

 static int
diff --git a/drivers/event/dpaa2/dpaa2_eventdev.c 
b/drivers/event/dpaa2/dpaa2_eventdev.c
index fa1a1ade80..ffc5550f85 100644
--- a/drivers/event/dpaa2/dpaa2_eventdev.c
+++ b/drivers/event/dpaa2/dpaa2_eventdev.c
@@ -411,7 +411,7 @@ dpaa2_eventdev_info_get(struct rte_eventdev *dev,
RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES |
RTE_EVENT_DEV_CAP_CARRY_FLOW_ID |
RTE_EVENT_DEV_CAP_MAINTENANCE_FREE;
-
+   dev_info->max_profiles_per_port = 1;
 }

 static int
diff --git a/drivers/event/dsw/dsw_evdev.c b/drivers/event/dsw/dsw_evdev.c
index 6c5cde2468..785c12f61f 100644
--- a/drivers/event/dsw/dsw_evdev.c
+++ b/drivers/event/dsw/dsw_evdev.c
@@ -218,6 +218,7 @@ dsw_info_get(struct rte_eventdev *dev __rte_unused,
.max_event_port_dequeue_depth = DSW_MAX_PORT_DEQUEUE_DEPTH,
.max_event_port_enqueue_depth = DSW_MAX_PORT_ENQUEUE_DEPTH,
.max_num_events = DSW_MAX_EVENTS,
+   .max_profiles_per_port = 1,
.event_dev_cap = RTE_EVENT_DEV_CAP_BURST_MODE|
RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED|
RTE_EVENT_DEV_CAP_NONSEQ_MODE|
diff --git a/drivers/event/octeontx/ssovf_evdev.c 
b/drivers/event/octeontx/ssovf_evdev.c
index 650266b996..0eb9358981 100644
--- a/drivers/event/octeontx/ssovf_evdev.c
+++ b/drivers/event/octeontx/ssovf_evdev.c
@@ -158,7 +158,7 @@ ssovf_info_get(struct rte_eventdev *dev, struct 
rte_event_dev_info *dev_info)
RTE_EVENT_DEV_CAP_NONSEQ_MODE |
RTE_EVENT_DEV_CAP_CARRY_FLOW_ID |
RTE_EVENT_DEV_CAP_MAINTENANCE_FREE;
-
+   dev_info->max_profiles_per_port = 1;
 }

 static int
diff --git a/drivers/event/opdl/opdl_evdev.c b/drivers/event/opdl/opdl_evdev.c
index 9ce8b39b60..dd25749654 100644
--- a/drivers/event/opdl/opdl_evdev.c
+++ b/drivers/event/opdl/opdl_evdev.c
@@ -378,6 +378,7 @@ opdl_info_get(struct rte_eventdev *dev, struct 
rte_event_dev_info *info)
.event_dev_cap = RTE_EVENT_DEV_CAP_BURST_MODE |
 RTE_EVENT_DEV_CAP_CARRY_FLOW_ID |
 RTE_EVENT_DEV_CAP_MAINTENANCE_FREE,
+   .max_profiles_per_port = 1,
};

*info = evdev_opdl_info;
diff --git a/drivers/event/skeleton/skeleton_eventdev.c 
b/drivers/event/skeleton/skeleton_eventdev.c
index 8513b9a013..dc9b131641 100644
--- a/drivers/event/skeleton/skeleton_eventdev.c
+++ b/drivers/event/skeleton/skeleton_eventdev.c
@@ -104,6 +104,7 @@ skeleton_eventdev_info_get(struct rte_eventdev *dev,
RTE_EVENT_DEV_CAP_EVENT_QOS |
RTE_EVENT_DEV_CAP_CARRY_FLOW_ID |
RTE_EVENT_DEV_CAP_MAINTENANCE_FREE;
+   dev_info->max_profiles_per_port = 1;
 }

 static int
diff --git a/drivers/event/sw/sw_evdev.c b/drivers/event/sw/sw_evdev.c
index cfd659d774..6d1816b76d 100644
--- a/drivers/event/sw/sw_evdev.c
+++ b/drivers/event/sw/sw_evdev.c
@@ -609,6 +609,7 @@ sw_info_get(st

Re: [PATCH v3 12/12] baseband/acc: add configure helper for VRB2

[Maxime Coquelin]

On 9/29/23 18:35, Nicolas Chautru wrote:

This allows to configure the VRB2 device using a
companion configuration function within the DPDK
bbdev-test environment.

Signed-off-by: Nicolas Chautru 
---
  drivers/baseband/acc/acc100_pmd.h |   2 +
  drivers/baseband/acc/rte_acc100_pmd.c |   6 +-
  drivers/baseband/acc/rte_vrb_pmd.c| 321 ++
  drivers/baseband/acc/vrb_cfg.h|  16 ++
  4 files changed, 344 insertions(+), 1 deletion(-)

diff --git a/drivers/baseband/acc/acc100_pmd.h 
b/drivers/baseband/acc/acc100_pmd.h
index a48298650c..5a8965fa53 100644
--- a/drivers/baseband/acc/acc100_pmd.h
+++ b/drivers/baseband/acc/acc100_pmd.h
@@ -34,6 +34,8 @@
  #define ACC100_VENDOR_ID   (0x8086)
  #define ACC100_PF_DEVICE_ID(0x0d5c)
  #define ACC100_VF_DEVICE_ID(0x0d5d)
+#define VRB1_PF_DEVICE_ID  (0x57C0)
+#define VRB2_PF_DEVICE_ID  (0x57C2)
  
  /* Values used in writing to the registers */

  #define ACC100_REG_IRQ_EN_ALL  0x1FF83FF  /* Enable all interrupts */
diff --git a/drivers/baseband/acc/rte_acc100_pmd.c 
b/drivers/baseband/acc/rte_acc100_pmd.c
index 7f8d05b5a9..699a227d13 100644
--- a/drivers/baseband/acc/rte_acc100_pmd.c
+++ b/drivers/baseband/acc/rte_acc100_pmd.c
@@ -5187,6 +5187,10 @@ rte_acc_configure(const char *dev_name, struct 
rte_acc_conf *conf)
return acc100_configure(dev_name, conf);
else if (pci_dev->id.device_id == ACC101_PF_DEVICE_ID)
return acc101_configure(dev_name, conf);
-   else
+   else if (pci_dev->id.device_id == VRB1_PF_DEVICE_ID)
return vrb1_configure(dev_name, conf);
+   else if (pci_dev->id.device_id == VRB2_PF_DEVICE_ID)
+   return vrb2_configure(dev_name, conf);
+
+   return -ENXIO;
  }
diff --git a/drivers/baseband/acc/rte_vrb_pmd.c 
b/drivers/baseband/acc/rte_vrb_pmd.c
index 3eb1a380fc..d0bc74b53f 100644
--- a/drivers/baseband/acc/rte_vrb_pmd.c
+++ b/drivers/baseband/acc/rte_vrb_pmd.c
@@ -5052,3 +5052,324 @@ vrb1_configure(const char *dev_name, struct 
rte_acc_conf *conf)
rte_bbdev_log_debug("PF Tip configuration complete for %s", dev_name);
return 0;
  }
+
+/* Initial configuration of a VRB2 device prior to running configure(). */
+int
+vrb2_configure(const char *dev_name, struct rte_acc_conf *conf)
+{
+   rte_bbdev_log(INFO, "vrb2_configure");
+   uint32_t value, address, status;
+   int qg_idx, template_idx, vf_idx, acc, i, aq_reg, static_allocation, 
numEngines;
+   int numQgs, numQqsAcc, totalQgs;
+   int qman_func_id[8] = {0, 2, 1, 3, 4, 5, 0, 0};
+   struct rte_bbdev *bbdev = rte_bbdev_get_named_dev(dev_name);
+   int rlim, alen, timestamp;
+
+   /* Compile time checks. */
+   RTE_BUILD_BUG_ON(sizeof(struct acc_dma_req_desc) != 256);
+   RTE_BUILD_BUG_ON(sizeof(union acc_dma_desc) != 256);
+   RTE_BUILD_BUG_ON(sizeof(struct acc_fcw_td) != 24);
+   RTE_BUILD_BUG_ON(sizeof(struct acc_fcw_te) != 32);
+
+   if (bbdev == NULL) {
+   rte_bbdev_log(ERR,
+   "Invalid dev_name (%s), or device is not yet initialised",
+   dev_name);
+   return -ENODEV;
+   }
+   struct acc_device *d = bbdev->data->dev_private;
+
+   /* Store configuration. */
+   rte_memcpy(&d->acc_conf, conf, sizeof(d->acc_conf));
+
+   /* Explicitly releasing AXI as this may be stopped after PF FLR/BME. */
+   address = VRB2_PfDmaAxiControl;
+   value = 1;
+   acc_reg_write(d, address, value);
+
+   /* Set the fabric mode. */
+   address = VRB2_PfFabricM2iBufferReg;
+   value = VRB2_FABRIC_MODE;
+   acc_reg_write(d, address, value);
+
+   /* Set default descriptor signature. */
+   address = VRB2_PfDmaDescriptorSignature;
+   value = 0;
+   acc_reg_write(d, address, value);
+
+   /* Enable the Error Detection in DMA. */
+   value = VRB2_CFG_DMA_ERROR;
+   address = VRB2_PfDmaErrorDetectionEn;
+   acc_reg_write(d, address, value);
+
+   /* AXI Cache configuration. */
+   value = VRB2_CFG_AXI_CACHE;
+   address = VRB2_PfDmaAxcacheReg;
+   acc_reg_write(d, address, value);
+
+   /* AXI Response configuration. */
+   acc_reg_write(d, VRB2_PfDmaCfgRrespBresp, 0x0);
+
+   /* Default DMA Configuration (Qmgr Enabled) */
+   acc_reg_write(d, VRB2_PfDmaConfig0Reg, 0);
+   acc_reg_write(d, VRB2_PfDmaQmanenSelect, 0x);
+   acc_reg_write(d, VRB2_PfDmaQmanen, 0);
+
+   /* Default RLIM/ALEN configuration. */
+   rlim = 0;
+   alen = 3;
+   timestamp = 0;
+   address = VRB2_PfDmaConfig1Reg;
+   value = (1 << 31) + (rlim << 8) + (timestamp << 6) + alen;
+   acc_reg_write(d, address, value);
+
+   /* Default FFT configuration. */
+   for (template_idx = 0; template_idx < VRB2_FFT_NUM; template_idx++) {
+   acc_reg_write(d, VRB2_PfFftConfig0 + template_idx * 0x1000, 
VRB2_FFT

RE: [EXT] Re: [PATCH v6 0/3] Introduce event link profiles

[Pavan Nikhilesh Bhagavatula]

> On Tue, Oct 3, 2023 at 7:43 PM Bruce Richardson
>  wrote:
> >
> > On Tue, Oct 03, 2023 at 04:06:10PM +0530, Jerin Jacob wrote:
> > > On Tue, Oct 3, 2023 at 3:17 PM  wrote:
> > > >
> > > > From: Pavan Nikhilesh 
> > > >
> > > > A collection of event queues linked to an event port can be associated
> > > > with unique identifier called as a link profile, multiple such profiles
> > > > can be configured based on the event device capability using the
> function
> > > > `rte_event_port_profile_links_set` which takes arguments similar to
> > > > `rte_event_port_link` in addition to the profile identifier.
> > > >
> > > > The maximum link profiles that are supported by an event device is
> > > > advertised through the structure member
> > >
> > > ...
> > >
> > > >
> > > > v6 Changes:
> > >
> > > Series applied to dpdk-next-net-eventdev/for-main with following
> changes. Thanks
> > >
> >
> > I'm doing some investigation work on the software eventdev, using
> > eventdev_pipeline, and following these patches the eventdev_pipeline
> sample
> > no longer is working for me. Error message is as shown below:
> >
> > Config:
> > ports: 2
> > workers: 22
> > packets: 33554432
> > Queue-prio: 0
> > qid0 type: ordered
> > Cores available: 48
> > Cores used: 24
> > Eventdev 0: event_sw
> > Stages:
> > Stage 0, Type Ordered   Priority = 128
> >
> >   EVENTDEV: rte_event_port_profile_unlink() line 1092: Invalid profile_id=0
> >   Error setting up port 0
> >
> > Parameters used when running the app:
> >   -l 24-47 --in-memory --vdev=event_sw0 -- \
> > -r 100 -t 100 -e 200 -w FC00  -c 64 -W 500
> 
> 
> Following max_profiles_per_port = 1 is getting overridden in [1]. I
> was suggested to take this path to avoid driver changes.
> Looks like we can not rely on common code. @Pavan Nikhilesh  Could you
> change to your old version(where every driver changes to add
> max_profiles_per_port = 1).
> I will squash it.
> 
> diff --git a/lib/eventdev/rte_eventdev.c b/lib/eventdev/rte_eventdev.c
> index 60509c6efb..5ee8bd665b 100644
> --- a/lib/eventdev/rte_eventdev.c
> +++ b/lib/eventdev/rte_eventdev.c
> @@ -96,6 +96,7 @@  rte_event_dev_info_get(uint8_t dev_id, struct
> rte_event_dev_info *dev_info)
>   return -EINVAL;
> 
>   memset(dev_info, 0, sizeof(struct rte_event_dev_info));
> + dev_info->max_profiles_per_port = 1;


Should be fixed with the following patch, @Bruce Richardson could you please 
verify 
https://patchwork.dpdk.org/project/dpdk/patch/20231003152535.10177-1-pbhagavat...@marvell.com/

> 
> [1]
> static void
> sw_info_get(struct rte_eventdev *dev, struct rte_event_dev_info *info)
> {
> RTE_SET_USED(dev);
> 
> static const struct rte_event_dev_info evdev_sw_info = {
> .driver_name = SW_PMD_NAME,
> .max_event_queues = RTE_EVENT_MAX_QUEUES_PER_DEV,
> .max_event_queue_flows = SW_QID_NUM_FIDS,
> .max_event_queue_priority_levels = SW_Q_PRIORITY_MAX,
> .max_event_priority_levels = SW_IQS_MAX,
> .max_event_ports = SW_PORTS_MAX,
> .max_event_port_dequeue_depth =
> MAX_SW_CONS_Q_DEPTH,
> .max_event_port_enqueue_depth =
> MAX_SW_PROD_Q_DEPTH,
> .max_num_events = SW_INFLIGHT_EVENTS_TOTAL,
> .event_dev_cap = (
> RTE_EVENT_DEV_CAP_QUEUE_QOS |
> RTE_EVENT_DEV_CAP_BURST_MODE |
> RTE_EVENT_DEV_CAP_EVENT_QOS |
> RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE|
> RTE_EVENT_DEV_CAP_RUNTIME_PORT_LINK |
> RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT |
> RTE_EVENT_DEV_CAP_NONSEQ_MODE |
> RTE_EVENT_DEV_CAP_CARRY_FLOW_ID |
> RTE_EVENT_DEV_CAP_MAINTENANCE_FREE),
> };
> 
> *info = evdev_sw_info;
> }
> 
> 
> >
> > Regards,
> > /Bruce

RE: [PATCH v1 1/1] app/mldev: updates to device ops test

[Anup Prabhu]

> -Original Message-
> From: Srikanth Yalavarthi 
> Sent: Wednesday, August 30, 2023 9:23 PM
> To: Srikanth Yalavarthi ; Anup Prabhu
> 
> Cc: dev@dpdk.org; Shivah Shankar Shankar Narayan Rao
> ; Prince Takkar ;
> sta...@dpdk.org
> Subject: [PATCH v1 1/1] app/mldev: updates to device ops test
> 
> Updated device_ops test to configure the device with user specific
> arguments. Fix handling unsupported values for queue_pairs and
> queue_size
> 
> Fixes: c0e871657d6a ("app/mldev: support queue pairs and size")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Srikanth Yalavarthi 
Acked-by: Anup Prabhu 
<>

Re: [PATCH v1 1/1] baseband/acc: fix ACC100 HARQ input is alignment

[Maxime Coquelin]

On 9/19/23 20:24, Hernan Vargas wrote:

Some constraints are imposed onto the ACC100 HARQ input size,
but that value is incorrectly aligned down when getting close to
max (Ncb-F) which is not required.
The wireless performance impact is negligeable but still causes a
few LLRs no to be combined at the very end of the circular buffer.

Fixes: 5802f36dd492 ("baseband/acc100: enforce additional check on FCW")
Cc: sta...@dpdk.org

Signed-off-by: Hernan Vargas 
---
  drivers/baseband/acc/rte_acc100_pmd.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/baseband/acc/rte_acc100_pmd.c 
b/drivers/baseband/acc/rte_acc100_pmd.c
index 5362d39c302f..c736f3e4201c 100644
--- a/drivers/baseband/acc/rte_acc100_pmd.c
+++ b/drivers/baseband/acc/rte_acc100_pmd.c
@@ -1218,7 +1218,7 @@ acc100_fcw_ld_fill(struct rte_bbdev_dec_op *op, struct 
acc_fcw_ld *fcw,
- op->ldpc_dec.n_filler);
  
  		/* Alignment on next 64B - Already enforced from HC output */

-   harq_in_length = RTE_ALIGN_FLOOR(harq_in_length, 
ACC_HARQ_ALIGN_64B);
+   harq_in_length = RTE_ALIGN_CEIL(harq_in_length, 
ACC_HARQ_ALIGN_64B);
  
  		/* Stronger alignment requirement when in decompression mode */

if (fcw->hcin_decomp_mode > 0)


Reviewed-by: Maxime Coquelin 

Thanks,
Maxime

Re: [PATCH v2 0/3] rte_ether_unformat_addr changes

[Stephen Hemminger]

On Tue, 3 Oct 2023 11:44:16 +0100
Ferruh Yigit  wrote:

> On 10/2/2023 7:37 PM, Stephen Hemminger wrote:
> > This patchset makes rte_ether_unformat_addr allow other formats
> > for MAC address. Need to remove some inputs from existing
> > cmdline_etheraddr test, and add a new test in test suite
> > to cover this.  There is some overlap between the two tests
> > but that is fine.
> > 
> > Stephen Hemminger (3):
> >   test: remove some strings from cmdline_etheraddr tests
> >   rte_ether_unformat: accept more inputs
> >   test: add tests for rte_ether routines
> >   
> 
> Thanks Stephen,
> 
> This enables using the API as replacement to the tap PMD's local parse
> implementation:
> https://patchwork.dpdk.org/project/dpdk/patch/20230323170145.129901-1-...@linux.vnet.ibm.com/


That looks good, but indentation is wrong and it duplicates a check for value 
== NULL
which will cause a new Coverity warning.

Re: [PATCH v2 0/3] rte_ether_unformat_addr changes

[Stephen Hemminger]

On Tue, 3 Oct 2023 11:44:16 +0100
Ferruh Yigit  wrote:

> On 10/2/2023 7:37 PM, Stephen Hemminger wrote:
> > This patchset makes rte_ether_unformat_addr allow other formats
> > for MAC address. Need to remove some inputs from existing
> > cmdline_etheraddr test, and add a new test in test suite
> > to cover this.  There is some overlap between the two tests
> > but that is fine.
> > 
> > Stephen Hemminger (3):
> >   test: remove some strings from cmdline_etheraddr tests
> >   rte_ether_unformat: accept more inputs
> >   test: add tests for rte_ether routines
> >   
> 
> Thanks Stephen,
> 
> This enables using the API as replacement to the tap PMD's local parse
> implementation:
> https://patchwork.dpdk.org/project/dpdk/patch/20230323170145.129901-1-...@linux.vnet.ibm.com/


It can be simplified to just this.
No need to check value == NULL, already checkd.
No need to check for user_mac == NULL, since only called one place and that 
place
passes pointer to stack variable.


From b478a17f13a1bedadca3b60608c585f31c9ad8f2 Mon Sep 17 00:00:00 2001
From: David Christensen 
Date: Thu, 23 Mar 2023 13:01:45 -0400
Subject: [PATCH] net/tap: resolve stringop-overflow with gcc 12 on ppc64le

Building DPDK with gcc 12 on a ppc64le system generates a
stringop-overflow warning. Replace the local MAC address
validation function parse_user_mac() with a call to
rte_ether_unformat_addr() instead.

Bugzilla ID: 1197
Cc: sta...@dpdk.org

Signed-off-by: David Christensen 
---
 drivers/net/tap/rte_eth_tap.c | 25 +
 1 file changed, 1 insertion(+), 24 deletions(-)

diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
index bf98f7555990..b25a52655fa2 100644
--- a/drivers/net/tap/rte_eth_tap.c
+++ b/drivers/net/tap/rte_eth_tap.c
@@ -2267,29 +2267,6 @@ set_remote_iface(const char *key __rte_unused,
return 0;
 }
 
-static int parse_user_mac(struct rte_ether_addr *user_mac,
-   const char *value)
-{
-   unsigned int index = 0;
-   char mac_temp[strlen(ETH_TAP_USR_MAC_FMT) + 1], *mac_byte = NULL;
-
-   if (user_mac == NULL || value == NULL)
-   return 0;
-
-   strlcpy(mac_temp, value, sizeof(mac_temp));
-   mac_byte = strtok(mac_temp, ":");
-
-   while ((mac_byte != NULL) &&
-   (strlen(mac_byte) <= 2) &&
-   (strlen(mac_byte) == strspn(mac_byte,
-   ETH_TAP_CMP_MAC_FMT))) {
-   user_mac->addr_bytes[index++] = strtoul(mac_byte, NULL, 16);
-   mac_byte = strtok(NULL, ":");
-   }
-
-   return index;
-}
-
 static int
 set_mac_type(const char *key __rte_unused,
 const char *value,
@@ -2311,7 +2288,7 @@ set_mac_type(const char *key __rte_unused,
goto success;
}
 
-   if (parse_user_mac(user_mac, value) != 6)
+   if (rte_ether_unformat_addr(value, user_mac) < 0)
goto error;
 success:
TAP_LOG(DEBUG, "TAP user MAC param (%s)", value);
-- 
2.39.2

Re: [PATCH v2 1/3] test: remove some strings from cmdline_etheraddr tests

[Stephen Hemminger]

On Tue, 3 Oct 2023 11:47:51 +0100
Ferruh Yigit  wrote:

> On 10/2/2023 7:37 PM, Stephen Hemminger wrote:
> > Some of the ethernet address formats which were invalid will
> > now become valid inputs when rte_ether_unformat_addr is modified
> > to allow leading zeros.
> > 
> > Also, make local variables static.
> > 
> > Signed-off-by: Stephen Hemminger 
> >   
> 
> <...>
> 
> > @@ -61,10 +60,8 @@ const char * ether_addr_invalid_strs[] = {
> > "INVA:LIDC:HARS",
> > /* misc */
> > "01 23 45 67 89 AB",
> > -   "01.23.45.67.89.AB",
> > "01,23,45,67,89,AB",
> > -   "01:23:45\0:67:89:AB",
> > -   "01:23:45#:67:89:AB",
> >  
> 
> Why these two are valid now?
> 
> And I guess second one is still not valid, but first one is parsed as
> [1], is this expected?
> 
> [1] 00:01:00:23:00:45

The code in cmdline converts the comment character # to a null byte.
So both test are the same.

With new unformat, it allows a 3 part mac address with leading
zeros.
01:23:45 is equivalent to 0001:0023:0045

Re: [PATCH v2 1/3] test: remove some strings from cmdline_etheraddr tests

[Stephen Hemminger]

On Tue, 3 Oct 2023 11:59:04 +0100
Ferruh Yigit  wrote:

> Ah, I guess it is taken as "::" format, but number of digit
> is not enforced, so "1:2:3" is a valid format, should we add this to API
> documentation as example format? Or is this unintended side effect?

By allowing leading zeros, it becomes allowed.
DPDK always allowed the non-standard 3 part format.
Looking around only old Cisco ACS used 3 part MAC format and it used
periods.

The API documentation should mention leading zeros are optional.

Re: [PATCH] eventdev: fix max link profiles info

[Bruce Richardson]

On Tue, Oct 03, 2023 at 08:55:35PM +0530, pbhagavat...@marvell.com wrote:
> From: Pavan Nikhilesh 
> 
> Since most of the drivers overwrite the info structure passed
> from the common layer it is not possible to set defaults in
> ``rte_event_dev_info_get`` API.
> Initialize default max_profiles_per_port in the driver layer.
> 
> Fixes: 162aa4e1b479 ("eventdev: introduce link profiles")
> 
> Signed-off-by: Pavan Nikhilesh 
> ---
> Please squash to 162aa4e1b479
> 
Just wondering, is another valid approach to check the return value from
the driver callback and set max_profiles to 1 if it's set to zero by the
driver? That would save modifying all drivers and probably still fix any
issues. [I'm assuming that max_profiles == 0 is invalid, and that every
device by default should report "1" as supported]

/Bruce

Re: [PATCH v2 1/3] test: remove some strings from cmdline_etheraddr tests

[Ferruh Yigit]

On 10/3/2023 5:36 PM, Stephen Hemminger wrote:
> On Tue, 3 Oct 2023 11:47:51 +0100
> Ferruh Yigit  wrote:
> 
>> On 10/2/2023 7:37 PM, Stephen Hemminger wrote:
>>> Some of the ethernet address formats which were invalid will
>>> now become valid inputs when rte_ether_unformat_addr is modified
>>> to allow leading zeros.
>>>
>>> Also, make local variables static.
>>>
>>> Signed-off-by: Stephen Hemminger 
>>>   
>>
>> <...>
>>
>>> @@ -61,10 +60,8 @@ const char * ether_addr_invalid_strs[] = {
>>> "INVA:LIDC:HARS",
>>> /* misc */
>>> "01 23 45 67 89 AB",
>>> -   "01.23.45.67.89.AB",
>>> "01,23,45,67,89,AB",
>>> -   "01:23:45\0:67:89:AB",
>>> -   "01:23:45#:67:89:AB",
>>>  
>>
>> Why these two are valid now?
>>
>> And I guess second one is still not valid, but first one is parsed as
>> [1], is this expected?
>>
>> [1] 00:01:00:23:00:45
> 
> The code in cmdline converts the comment character # to a null byte.
> So both test are the same.
> 
> With new unformat, it allows a 3 part mac address with leading
> zeros.
>   01:23:45 is equivalent to 0001:0023:0045
>

With 3 part MAC, omitting leading zeros looks confusing to me, because
that omitted part becomes an octet in MAC. Like:
01:23:45 being equivalent to 00:01:00:23:00:45

As 3 part MAC, and 6 part MAC has separate functions, does it makes
sense to require leading zeros in the 3 part MAC, what do you think?

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

[Medvedkin, Vladimir]

Acked-by: Vladimir Medvedkin 

On 10/07/2023 22:59, Bili Dong wrote:

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

Signed-off-by: Bili Dong 




--
Regards,
Vladimir

[PATCH] eventdev: drop custom OS defines

[Bruce Richardson]

The eventdev library doesn't need to put in place its own defines for
Linux and BSD. There are already defines for the OS environment in
rte_config.h that can be re-used, but since these are just for
identifying Linux/non-Linux, we can just check for the standard define
'__linux__' instead.

Signed-off-by: Bruce Richardson 
---
 lib/eventdev/meson.build| 6 --
 lib/eventdev/rte_event_eth_rx_adapter.c | 6 +++---
 2 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/lib/eventdev/meson.build b/lib/eventdev/meson.build
index 250abcb154..a04bb86f0f 100644
--- a/lib/eventdev/meson.build
+++ b/lib/eventdev/meson.build
@@ -7,12 +7,6 @@ if is_windows
 subdir_done()
 endif
 
-if is_linux
-cflags += '-DLINUX'
-else
-cflags += '-DBSD'
-endif
-
 sources = files(
 'eventdev_private.c',
 'eventdev_trace_points.c',
diff --git a/lib/eventdev/rte_event_eth_rx_adapter.c 
b/lib/eventdev/rte_event_eth_rx_adapter.c
index 565428a58c..9090e5fbb7 100644
--- a/lib/eventdev/rte_event_eth_rx_adapter.c
+++ b/lib/eventdev/rte_event_eth_rx_adapter.c
@@ -4,7 +4,7 @@
  */
 #include 
 #include 
-#if defined(LINUX)
+#if defined(__linux__)
 #include 
 #endif
 #include 
@@ -1565,11 +1565,11 @@ rxa_default_conf_cb(uint8_t id, uint8_t dev_id,
 static int
 rxa_epoll_create1(void)
 {
-#if defined(LINUX)
+#if defined(__linux__)
int fd;
fd = epoll_create1(EPOLL_CLOEXEC);
return fd < 0 ? -errno : fd;
-#elif defined(BSD)
+#else
return -ENOTSUP;
 #endif
 }
-- 
2.39.2

RE: [EXT] Re: [PATCH] eventdev: fix max link profiles info

[Jerin Jacob Kollanukkaran]

> -Original Message-
> From: Bruce Richardson 
> Sent: Tuesday, October 3, 2023 10:19 PM
> To: Pavan Nikhilesh Bhagavatula 
> Cc: Jerin Jacob Kollanukkaran ; Abdullah Sevincer
> ; Hemant Agrawal
> ; Sachin Saxena ;
> Mattias Rönnblom ; Liang Ma
> ; Peter Mccarthy ; Harry
> van Haaren ; dev@dpdk.org
> Subject: [EXT] Re: [PATCH] eventdev: fix max link profiles info
> 
> External Email
> 
> --
> On Tue, Oct 03, 2023 at 08:55:35PM +0530, pbhagavat...@marvell.com
> wrote:
> > From: Pavan Nikhilesh 
> >
> > Since most of the drivers overwrite the info structure passed from the
> > common layer it is not possible to set defaults in
> > ``rte_event_dev_info_get`` API.
> > Initialize default max_profiles_per_port in the driver layer.
> >
> > Fixes: 162aa4e1b479 ("eventdev: introduce link profiles")
> >
> > Signed-off-by: Pavan Nikhilesh 
> > ---
> > Please squash to 162aa4e1b479
> >
> Just wondering, is another valid approach to check the return value from the
> driver callback and set max_profiles to 1 if it's set to zero by the driver? 
> That
> would save modifying all drivers and probably still fix any issues. [I'm 
> assuming
> that max_profiles == 0 is invalid, and that every device by default should 
> report
> "1" as supported]

I can think of three options

1)Change max_profile to max_profiles_minus_one as name
2)In generic info_get, fix up max_profile as one if max_profile is zero after 
PMD callback +  
https://patches.dpdk.org/project/dpdk/patch/20231003150829.8257-1-pbhagavat...@marvell.com/
3) Or Keep as this patch.

Looks like (1) and (2) not very clean. I think, we can keep as (3) if you don't 
have strong opinion.



> 
> /Bruce

Re: [EXT] Re: [PATCH] eventdev: fix max link profiles info

[Bruce Richardson]

On Tue, Oct 03, 2023 at 05:03:28PM +, Jerin Jacob Kollanukkaran wrote:
> 
> 
> > -Original Message-
> > From: Bruce Richardson 
> > Sent: Tuesday, October 3, 2023 10:19 PM
> > To: Pavan Nikhilesh Bhagavatula 
> > Cc: Jerin Jacob Kollanukkaran ; Abdullah Sevincer
> > ; Hemant Agrawal
> > ; Sachin Saxena ;
> > Mattias Rönnblom ; Liang Ma
> > ; Peter Mccarthy ; Harry
> > van Haaren ; dev@dpdk.org
> > Subject: [EXT] Re: [PATCH] eventdev: fix max link profiles info
> > 
> > External Email
> > 
> > --
> > On Tue, Oct 03, 2023 at 08:55:35PM +0530, pbhagavat...@marvell.com
> > wrote:
> > > From: Pavan Nikhilesh 
> > >
> > > Since most of the drivers overwrite the info structure passed from the
> > > common layer it is not possible to set defaults in
> > > ``rte_event_dev_info_get`` API.
> > > Initialize default max_profiles_per_port in the driver layer.
> > >
> > > Fixes: 162aa4e1b479 ("eventdev: introduce link profiles")
> > >
> > > Signed-off-by: Pavan Nikhilesh 
> > > ---
> > > Please squash to 162aa4e1b479
> > >
> > Just wondering, is another valid approach to check the return value from the
> > driver callback and set max_profiles to 1 if it's set to zero by the 
> > driver? That
> > would save modifying all drivers and probably still fix any issues. [I'm 
> > assuming
> > that max_profiles == 0 is invalid, and that every device by default should 
> > report
> > "1" as supported]
> 
> I can think of three options
> 
> 1)Change max_profile to max_profiles_minus_one as name

Or call it "additional_profiles"?

> 2)In generic info_get, fix up max_profile as one if max_profile is zero after 
> PMD callback +  
> https://patches.dpdk.org/project/dpdk/patch/20231003150829.8257-1-pbhagavat...@marvell.com/
> 3) Or Keep as this patch.
> 
> Looks like (1) and (2) not very clean. I think, we can keep as (3) if you 
> don't have strong opinion.
> 

No, no strong opinions.

/Bruce

Re: [PATCH] eventdev: fix max link profiles info

[Bruce Richardson]

On Tue, Oct 03, 2023 at 08:55:35PM +0530, pbhagavat...@marvell.com wrote:
> From: Pavan Nikhilesh 
> 
> Since most of the drivers overwrite the info structure passed
> from the common layer it is not possible to set defaults in
> ``rte_event_dev_info_get`` API.
> Initialize default max_profiles_per_port in the driver layer.
> 
> Fixes: 162aa4e1b479 ("eventdev: introduce link profiles")
> 
> Signed-off-by: Pavan Nikhilesh 
> ---
> Please squash to 162aa4e1b479
> 
Confirm that this patch allows the eventdev_pipeline sample to once again
run with the event_sw driver.

For this solution, if it's chosen over alternatives

Acked-by: Bruce Richardson 

Re: [PATCH v2 1/3] test: remove some strings from cmdline_etheraddr tests

[Stephen Hemminger]

On Tue, 3 Oct 2023 17:50:13 +0100
Ferruh Yigit  wrote:

> On 10/3/2023 5:36 PM, Stephen Hemminger wrote:
> > On Tue, 3 Oct 2023 11:47:51 +0100
> > Ferruh Yigit  wrote:
> >   
> >> On 10/2/2023 7:37 PM, Stephen Hemminger wrote:  
> >>> Some of the ethernet address formats which were invalid will
> >>> now become valid inputs when rte_ether_unformat_addr is modified
> >>> to allow leading zeros.
> >>>
> >>> Also, make local variables static.
> >>>
> >>> Signed-off-by: Stephen Hemminger 
> >>> 
> >>
> >> <...>
> >>  
> >>> @@ -61,10 +60,8 @@ const char * ether_addr_invalid_strs[] = {
> >>>   "INVA:LIDC:HARS",
> >>>   /* misc */
> >>>   "01 23 45 67 89 AB",
> >>> - "01.23.45.67.89.AB",
> >>>   "01,23,45,67,89,AB",
> >>> - "01:23:45\0:67:89:AB",
> >>> - "01:23:45#:67:89:AB",
> >>>
> >>
> >> Why these two are valid now?
> >>
> >> And I guess second one is still not valid, but first one is parsed as
> >> [1], is this expected?
> >>
> >> [1] 00:01:00:23:00:45  
> > 
> > The code in cmdline converts the comment character # to a null byte.
> > So both test are the same.
> > 
> > With new unformat, it allows a 3 part mac address with leading
> > zeros.
> > 01:23:45 is equivalent to 0001:0023:0045
> >  
> 
> With 3 part MAC, omitting leading zeros looks confusing to me, because
> that omitted part becomes an octet in MAC. Like:
> 01:23:45 being equivalent to 00:01:00:23:00:45
> 
> As 3 part MAC, and 6 part MAC has separate functions, does it makes
> sense to require leading zeros in the 3 part MAC, what do you think?
> 

Right, 3 part MAC is only a legacy Cisco format, not used anywhere else.

RE: [PATCH v3 11/12] baseband/acc: add support for VRB2 engine error detection

[Chautru, Nicolas]

Hi Maxime, 

> -Original Message-
> From: Maxime Coquelin 
> Sent: Tuesday, October 3, 2023 8:16 AM
> To: Chautru, Nicolas ; dev@dpdk.org
> Cc: hemant.agra...@nxp.com; david.march...@redhat.com; Vargas, Hernan
> 
> Subject: Re: [PATCH v3 11/12] baseband/acc: add support for VRB2 engine
> error detection
> 
> 
> 
> On 9/29/23 18:35, Nicolas Chautru wrote:
> > Adding missing incremental functionality for the VRB2 variant. Notably
> > detection of engine error during the dequeue. Minor cosmetic edits.
> >
> > Signed-off-by: Nicolas Chautru 
> > ---
> >   drivers/baseband/acc/rte_vrb_pmd.c  | 20 
> >   drivers/baseband/acc/vrb1_pf_enum.h | 17 -
> >   2 files changed, 24 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/baseband/acc/rte_vrb_pmd.c
> > b/drivers/baseband/acc/rte_vrb_pmd.c
> > index a9d3db86e6..3eb1a380fc 100644
> > --- a/drivers/baseband/acc/rte_vrb_pmd.c
> > +++ b/drivers/baseband/acc/rte_vrb_pmd.c
> > @@ -1504,6 +1504,7 @@ vrb_fcw_td_fill(const struct rte_bbdev_dec_op
> *op, struct acc_fcw_td *fcw)
> > fcw->ea = op->turbo_dec.cb_params.e;
> > fcw->eb = op->turbo_dec.cb_params.e;
> > }
> > +
> > if (op->turbo_dec.rv_index == 0)
> > fcw->k0_start_col = ACC_FCW_TD_RVIDX_0;
> > else if (op->turbo_dec.rv_index == 1) @@ -2304,7
> +2305,7 @@
> > enqueue_ldpc_enc_n_op_cb(struct acc_queue *q, struct rte_bbdev_enc_op
> **ops,
> > return num;
> >   }
> >
> > -/* Enqueue one encode operations for device for a partial TB
> > +/* Enqueue one encode operations for VRB1 device for a partial TB
> >* all codes blocks have same configuration multiplexed on the same
> descriptor.
> >*/
> >   static inline void
> > @@ -2649,7 +2650,7 @@ enqueue_dec_one_op_cb(struct acc_queue *q,
> struct rte_bbdev_dec_op *op,
> > return 1;
> >   }
> >
> > -/** Enqueue one decode operations for device in CB mode */
> > +/** Enqueue one decode operations for device in CB mode. */
> >   static inline int
> >   vrb_enqueue_ldpc_dec_one_op_cb(struct acc_queue *q, struct
> rte_bbdev_dec_op *op,
> > uint16_t total_enqueued_cbs, bool same_op) @@ -2801,7
> +2802,6 @@
> > vrb_enqueue_ldpc_dec_one_op_tb(struct acc_queue *q, struct
> rte_bbdev_dec_op *op,
> > desc->req.data_ptrs[0].blen = ACC_FCW_LD_BLEN;
> > rte_memcpy(&desc->req.fcw_ld, &desc_first->req.fcw_ld,
> ACC_FCW_LD_BLEN);
> > desc->req.fcw_ld.tb_trailer_size = (c - r - 1) * trail_len;
> > -
> > if (q->d->device_variant == VRB1_VARIANT)
> > ret = vrb1_dma_desc_ld_fill(op, &desc->req, &input,
> > h_output, &in_offset, &h_out_offset,
> @@ -3226,7 +3226,6 @@
> > vrb_enqueue_ldpc_dec_cb(struct rte_bbdev_queue_data *q_data,
> > break;
> > }
> > avail -= 1;
> > -
> 
> Is it intentionnally removed?

Cosmetic but slightly more readable. I don’t have a strong rule for these.

> 
> > rte_bbdev_log(INFO, "Op %d %d %d %d %d %d %d %d %d %d
> %d %d\n",
> > i, ops[i]->ldpc_dec.op_flags, ops[i]-
> >ldpc_dec.rv_index,
> > ops[i]->ldpc_dec.iter_max, ops[i]-
> >ldpc_dec.iter_count, @@
> > -3354,6 +3353,7 @@ vrb_dequeue_enc_one_op_cb(struct acc_queue *q,
> struct rte_bbdev_enc_op **ref_op,
> > op->status |= ((rsp.input_err) ? (1 << RTE_BBDEV_DATA_ERROR) : 0);
> > op->status |= ((rsp.dma_err) ? (1 << RTE_BBDEV_DRV_ERROR) : 0);
> > op->status |= ((rsp.fcw_err) ? (1 << RTE_BBDEV_DRV_ERROR) : 0);
> > +   op->status |= ((rsp.engine_hung) ? (1 << RTE_BBDEV_ENGINE_ERROR)
> :
> > +0);
> >
> > if (desc->req.last_desc_in_batch) {
> > (*aq_dequeued)++;
> > @@ -3470,6 +3470,7 @@ vrb_dequeue_enc_one_op_tb(struct acc_queue
> *q, struct rte_bbdev_enc_op **ref_op,
> > op->status |= ((rsp.input_err) ? (1 <<
> RTE_BBDEV_DATA_ERROR) : 0);
> > op->status |= ((rsp.dma_err) ? (1 << RTE_BBDEV_DRV_ERROR)
> : 0);
> > op->status |= ((rsp.fcw_err) ? (1 << RTE_BBDEV_DRV_ERROR) :
> 0);
> > +   op->status |= ((rsp.engine_hung) ? (1 <<
> RTE_BBDEV_ENGINE_ERROR) :
> > +0);
> >
> > if (desc->req.last_desc_in_batch) {
> > (*aq_dequeued)++;
> > @@ -3516,6 +3517,8 @@ vrb_dequeue_dec_one_op_cb(struct
> rte_bbdev_queue_data *q_data,
> > op->status |= ((rsp.input_err) ? (1 << RTE_BBDEV_DATA_ERROR) : 0);
> > op->status |= ((rsp.dma_err) ? (1 << RTE_BBDEV_DRV_ERROR) : 0);
> > op->status |= ((rsp.fcw_err) ? (1 << RTE_BBDEV_DRV_ERROR) : 0);
> > +   op->status |= rsp.engine_hung << RTE_BBDEV_ENGINE_ERROR;
> > +
> > if (op->status != 0) {
> > /* These errors are not expected. */
> > q_data->queue_stats.dequeue_err_count++;
> > @@ -3569,6 +3572,7 @@ vrb_dequeue_ldpc_dec_one_op_cb(struct
> 

Re: [PATCH v3 11/12] baseband/acc: add support for VRB2 engine error detection

[Maxime Coquelin]

On 10/3/23 19:22, Chautru, Nicolas wrote:

Hi Maxime,


-Original Message-
From: Maxime Coquelin 
Sent: Tuesday, October 3, 2023 8:16 AM
To: Chautru, Nicolas ; dev@dpdk.org
Cc: hemant.agra...@nxp.com; david.march...@redhat.com; Vargas, Hernan

Subject: Re: [PATCH v3 11/12] baseband/acc: add support for VRB2 engine
error detection



On 9/29/23 18:35, Nicolas Chautru wrote:

Adding missing incremental functionality for the VRB2 variant. Notably
detection of engine error during the dequeue. Minor cosmetic edits.

Signed-off-by: Nicolas Chautru 
---
   drivers/baseband/acc/rte_vrb_pmd.c  | 20 
   drivers/baseband/acc/vrb1_pf_enum.h | 17 -
   2 files changed, 24 insertions(+), 13 deletions(-)

diff --git a/drivers/baseband/acc/rte_vrb_pmd.c
b/drivers/baseband/acc/rte_vrb_pmd.c
index a9d3db86e6..3eb1a380fc 100644
--- a/drivers/baseband/acc/rte_vrb_pmd.c
+++ b/drivers/baseband/acc/rte_vrb_pmd.c
@@ -1504,6 +1504,7 @@ vrb_fcw_td_fill(const struct rte_bbdev_dec_op

*op, struct acc_fcw_td *fcw)

fcw->ea = op->turbo_dec.cb_params.e;
fcw->eb = op->turbo_dec.cb_params.e;
}
+
if (op->turbo_dec.rv_index == 0)
fcw->k0_start_col = ACC_FCW_TD_RVIDX_0;
else if (op->turbo_dec.rv_index == 1) @@ -2304,7

+2305,7 @@

enqueue_ldpc_enc_n_op_cb(struct acc_queue *q, struct rte_bbdev_enc_op

**ops,

return num;
   }

-/* Enqueue one encode operations for device for a partial TB
+/* Enqueue one encode operations for VRB1 device for a partial TB
* all codes blocks have same configuration multiplexed on the same

descriptor.

*/
   static inline void
@@ -2649,7 +2650,7 @@ enqueue_dec_one_op_cb(struct acc_queue *q,

struct rte_bbdev_dec_op *op,

return 1;
   }

-/** Enqueue one decode operations for device in CB mode */
+/** Enqueue one decode operations for device in CB mode. */
   static inline int
   vrb_enqueue_ldpc_dec_one_op_cb(struct acc_queue *q, struct

rte_bbdev_dec_op *op,

uint16_t total_enqueued_cbs, bool same_op) @@ -2801,7

+2802,6 @@

vrb_enqueue_ldpc_dec_one_op_tb(struct acc_queue *q, struct

rte_bbdev_dec_op *op,

desc->req.data_ptrs[0].blen = ACC_FCW_LD_BLEN;
rte_memcpy(&desc->req.fcw_ld, &desc_first->req.fcw_ld,

ACC_FCW_LD_BLEN);

desc->req.fcw_ld.tb_trailer_size = (c - r - 1) * trail_len;
-
if (q->d->device_variant == VRB1_VARIANT)
ret = vrb1_dma_desc_ld_fill(op, &desc->req, &input,
h_output, &in_offset, &h_out_offset,

@@ -3226,7 +3226,6 @@

vrb_enqueue_ldpc_dec_cb(struct rte_bbdev_queue_data *q_data,
break;
}
avail -= 1;
-


Is it intentionnally removed?


Cosmetic but slightly more readable. I don’t have a strong rule for these.


OK, if that's intentionnal that's OK to me.




rte_bbdev_log(INFO, "Op %d %d %d %d %d %d %d %d %d %d

%d %d\n",

i, ops[i]->ldpc_dec.op_flags, ops[i]-
ldpc_dec.rv_index,
ops[i]->ldpc_dec.iter_max, ops[i]-
ldpc_dec.iter_count, @@
-3354,6 +3353,7 @@ vrb_dequeue_enc_one_op_cb(struct acc_queue *q,

struct rte_bbdev_enc_op **ref_op,

op->status |= ((rsp.input_err) ? (1 << RTE_BBDEV_DATA_ERROR) : 0);
op->status |= ((rsp.dma_err) ? (1 << RTE_BBDEV_DRV_ERROR) : 0);
op->status |= ((rsp.fcw_err) ? (1 << RTE_BBDEV_DRV_ERROR) : 0);
+   op->status |= ((rsp.engine_hung) ? (1 << RTE_BBDEV_ENGINE_ERROR)

:

+0);

if (desc->req.last_desc_in_batch) {
(*aq_dequeued)++;
@@ -3470,6 +3470,7 @@ vrb_dequeue_enc_one_op_tb(struct acc_queue

*q, struct rte_bbdev_enc_op **ref_op,

op->status |= ((rsp.input_err) ? (1 <<

RTE_BBDEV_DATA_ERROR) : 0);

op->status |= ((rsp.dma_err) ? (1 << RTE_BBDEV_DRV_ERROR)

: 0);

op->status |= ((rsp.fcw_err) ? (1 << RTE_BBDEV_DRV_ERROR) :

0);

+   op->status |= ((rsp.engine_hung) ? (1 <<

RTE_BBDEV_ENGINE_ERROR) :

+0);

if (desc->req.last_desc_in_batch) {
(*aq_dequeued)++;
@@ -3516,6 +3517,8 @@ vrb_dequeue_dec_one_op_cb(struct

rte_bbdev_queue_data *q_data,

op->status |= ((rsp.input_err) ? (1 << RTE_BBDEV_DATA_ERROR) : 0);
op->status |= ((rsp.dma_err) ? (1 << RTE_BBDEV_DRV_ERROR) : 0);
op->status |= ((rsp.fcw_err) ? (1 << RTE_BBDEV_DRV_ERROR) : 0);
+   op->status |= rsp.engine_hung << RTE_BBDEV_ENGINE_ERROR;
+
if (op->status != 0) {
/* These errors are not expected. */
q_data->queue_stats.dequeue_err_count++;
@@ -3569,6 +3572,7 @@ vrb_dequeue_ldpc_dec_one_op_cb(struct

rte_bbdev_queue_data *q_data,

op->status |= rsp.input_err << RTE_BBDEV_DATA_ERROR;
   

Re: [PATCH v4 1/3] lib: introduce dispatcher library

[Jerin Jacob]

On Wed, Sep 27, 2023 at 1:43 PM Bruce Richardson
 wrote:
>
> On Tue, Sep 26, 2023 at 11:58:37PM +0530, Jerin Jacob wrote:
> > On Mon, Sep 25, 2023 at 12:41 PM Mattias Rönnblom  
> > wrote:
> > >
> > > On 2023-09-22 09:38, Mattias Rönnblom wrote:
> > >
> > > 
> > >
> > > > +int
> > > > +rte_dispatcher_create(uint8_t id, uint8_t event_dev_id)
> > > > +{
> > >
> > >
> > > There are two changes I'm considering:
> > >
> > > 1) Removing the "id" to identify the dispatcher, replacing it with an
> > > forward-declared rte_dispatcher struct pointer.
> > >
> > > struct rte_dispatcher;
> > >
> > > struct rte_dispatcher *
> > > rte_dispatcher_create(uint8_t event_dev_id);
> > >
> > >
> > > The original reason for using an integer id to identify a dispatcher is
> > > to make it look like everything else in Eventdev. I find this pattern a
> > > little awkward to use - in particular the fact the id is
> > > application-allocated (and thus require coordination between different
> > > part of the application in case multiple instances are used).
> > >
> > > 2) Adding a flags field to the create function "for future use". But
> > > since the API is experimental, there may not be that much need to
> > > attempt to be future-proof?
> > >
> > > Any thoughts are appreciated.
> >
> > IMO, better to have rte_dispatcher_create(struct
> > rte_dispatch_create_params *params)
> > for better future proofing with specific
> > rte_dispatch_crearte_params_init() API(No need to add reserved fields
> > in rte_dispatch_create_params  now, may need only for before removing
> > experimental status)
> >
> > Just 2c.
> >
>
> I don't like using structs in those cases, I'd much rather have a flags
> parameter, as flags can be checked for explicit zeros for future proofing,
> while a struct cannot be checked for extra space on the end for future
> fields added.

For lib/dispatcher library, I have don't have specific preference. So
anything is fine for me.
However, I thought of understanding your rationale for arguments vs
structure(Looks like more of vi vs emac discussion) for _my
understanding_.

In my view,
# Use flags for setting up to express specific behavior, not as
inputting a lot of input parameters.
#  Do we need to check extra space if struct have reserved fields and
having init() functions for filling default

>
> Furthermore, if we need to add new parameters to the create function, I
> actually believe it is better to add them as explicit parameters rather
> than new fields to the struct. Struct fields can be missed by a user just
> recompiling, while new function parameters will be flagged by the compiler

I would see this as on the positive side, when

- Same code base needs to support multiple DPDK versions.
- A lot of times, API consumer may need only  _default_ values. Like
local_cache value in mempool_create API. So struct with _init() get
required values in easy way.

My views are based mostly used existing rte_mempool_create() APIs. For
some reason, I don't like this scheme.
struct rte_mempool *
rte_mempool_create(const char *name, unsigned n, unsigned elt_size,
   unsigned cache_size, unsigned private_data_size,
   rte_mempool_ctor_t *mp_init, void *mp_init_arg,
   rte_mempool_obj_cb_t *obj_init, void *obj_init_arg,
   int socket_id, unsigned flags);


> to make the user aware of the change. [There would be no change for ABI
> compatibility as function versioning would be usable in both cases]

Yes. But need to too much template code via VERSION_SYMBOL where
structure scheme does not need.




>
> /Bruce

RE: [PATCH v3 10/12] baseband/acc: add MLD support in VRB2 variant

[Chautru, Nicolas]

Hi Maxime, 

> -Original Message-
> From: Maxime Coquelin 
> Sent: Tuesday, October 3, 2023 8:13 AM
> To: Chautru, Nicolas ; dev@dpdk.org
> Cc: hemant.agra...@nxp.com; david.march...@redhat.com; Vargas, Hernan
> 
> Subject: Re: [PATCH v3 10/12] baseband/acc: add MLD support in VRB2
> variant
> 
> 
> 
> On 9/29/23 18:35, Nicolas Chautru wrote:
> > Adding the capability for the MLD-TS processing specific to the VRB2
> > variant.
> >
> > Signed-off-by: Nicolas Chautru 
> > ---
> >   drivers/baseband/acc/rte_vrb_pmd.c | 378
> +
> >   1 file changed, 378 insertions(+)
> >
> > diff --git a/drivers/baseband/acc/rte_vrb_pmd.c
> > b/drivers/baseband/acc/rte_vrb_pmd.c
> > index ce4b90d8e7..a9d3db86e6 100644
> > --- a/drivers/baseband/acc/rte_vrb_pmd.c
> > +++ b/drivers/baseband/acc/rte_vrb_pmd.c
> > @@ -1344,6 +1344,17 @@ vrb_dev_info_get(struct rte_bbdev *dev, struct
> rte_bbdev_driver_info *dev_info)
> > 1,
> > }
> > },
> > +   {
> > +   .type   = RTE_BBDEV_OP_MLDTS,
> > +   .cap.mld = {
> > +   .capability_flags =
> > +   RTE_BBDEV_MLDTS_REP,
> > +   .num_buffers_src =
> > +   1,
> > +   .num_buffers_dst =
> > +   1,
> > +   }
> > +   },
> > RTE_BBDEV_END_OF_CAPABILITIES_LIST()
> > };
> >
> > @@ -4151,6 +4162,371 @@ vrb_dequeue_fft(struct rte_bbdev_queue_data
> *q_data,
> > return i;
> >   }
> >
> > +/* Fill in a frame control word for MLD-TS processing. */ static
> > +inline void vrb2_fcw_mldts_fill(struct rte_bbdev_mldts_op *op, struct
> > +acc_fcw_mldts *fcw) {
> > +   fcw->nrb = op->mldts.num_rbs;
> > +   fcw->NLayers = op->mldts.num_layers - 1;
> > +   fcw->Qmod0 = (op->mldts.q_m[0] >> 1) - 1;
> > +   fcw->Qmod1 = (op->mldts.q_m[1] >> 1) - 1;
> > +   fcw->Qmod2 = (op->mldts.q_m[2] >> 1) - 1;
> > +   fcw->Qmod3 = (op->mldts.q_m[3] >> 1) - 1;
> > +   /* Mark some layers as disabled */
> > +   if (op->mldts.num_layers == 2) {
> > +   fcw->Qmod2 = 3;
> > +   fcw->Qmod3 = 3;
> > +   }
> > +   if (op->mldts.num_layers == 3)
> > +   fcw->Qmod3 = 3;
> > +   fcw->Rrep = op->mldts.r_rep;
> > +   fcw->Crep = op->mldts.c_rep;
> > +}
> > +
> > +/* Fill in descriptor for one MLD-TS processing operation. */ static
> > +inline int vrb2_dma_desc_mldts_fill(struct rte_bbdev_mldts_op *op,
> > +   struct acc_dma_req_desc *desc,
> > +   struct rte_mbuf *input_q, struct rte_mbuf *input_r,
> > +   struct rte_mbuf *output,
> > +   uint32_t *in_offset, uint32_t *out_offset) {
> > +   uint16_t qsize_per_re[VRB2_MLD_LAY_SIZE] = {8, 12, 16}; /* Layer 2
> to 4. */
> > +   uint16_t rsize_per_re[VRB2_MLD_LAY_SIZE] = {14, 26, 42};
> > +   uint16_t sc_factor_per_rrep[VRB2_MLD_RREP_SIZE] = {12, 6, 4, 3, 0,
> 2};
> > +   uint16_t i, outsize_per_re = 0;
> > +   uint32_t sc_num, r_num, q_size, r_size, out_size;
> > +
> > +   /* Prevent out of range access. */
> > +   if (op->mldts.r_rep > 5)
> > +   op->mldts.r_rep = 5;
> > +   if (op->mldts.num_layers < 2)
> > +   op->mldts.num_layers = 2;
> > +   if (op->mldts.num_layers > 4)
> > +   op->mldts.num_layers = 4;
> > +   for (i = 0; i < op->mldts.num_layers; i++)
> > +   outsize_per_re += op->mldts.q_m[i];
> > +   sc_num = op->mldts.num_rbs * RTE_BBDEV_SCPERRB * (op-
> >mldts.c_rep + 1);
> > +   r_num = op->mldts.num_rbs * sc_factor_per_rrep[op->mldts.r_rep];
> > +   q_size = qsize_per_re[op->mldts.num_layers - 2] * sc_num;
> > +   r_size = rsize_per_re[op->mldts.num_layers - 2] * r_num;
> > +   out_size =  sc_num * outsize_per_re;
> > +   /* printf("Sc %d R num %d Size %d %d %d\n", sc_num, r_num, q_size,
> > +r_size, out_size); */
> 
> rte_bbdev_log_debug()? Otherwise just remove it.

Thanks. Removing. 

> 
> > +
> > +   /* FCW already done. */
> > +   acc_header_init(desc);
> > +   desc->data_ptrs[1].address = rte_pktmbuf_iova_offset(input_q,
> *in_offset);
> > +   desc->data_ptrs[1].blen = q_size;
> > +   desc->data_ptrs[1].blkid = ACC_DMA_BLKID_IN;
> > +   desc->data_ptrs[1].last = 0;
> > +   desc->data_ptrs[1].dma_ext = 0;
> > +   desc->data_ptrs[2].address = rte_pktmbuf_iova_offset(input_r,
> *in_offset);
> > +   desc->data_ptrs[2].blen = r_size;
> > +   desc->data_ptrs[2].blkid = ACC_DMA_BLKID_IN_MLD_R;
> > +   desc->data_ptrs[2].last = 1;
> > +   desc->data_ptrs[2].dma_ext = 0;
> > +   desc->data_ptrs[3].address = rte_pktmbuf_iova_offset(output,
> *out_offset);
> > +   desc->data_ptrs[3].blen = out_size;
> > +   desc->data_ptrs[3].blkid = ACC_DMA_BLKID_OUT_HARD;
> > +   desc->data_ptrs[3].last = 1;
> > +   desc->data_ptrs[3].dma_ext = 0;
> > +   desc->m2dlen = 3;
> > +   desc->d2mlen = 1;
> > +   desc->op_addr = op;
> > +

RE: [PATCH v3 09/12] baseband/acc: add FFT support to VRB2 variant

[Chautru, Nicolas]

Hi Maxime, 

> -Original Message-
> From: Maxime Coquelin 
> Sent: Tuesday, October 3, 2023 7:37 AM
> To: Chautru, Nicolas ; dev@dpdk.org
> Cc: hemant.agra...@nxp.com; david.march...@redhat.com; Vargas, Hernan
> 
> Subject: Re: [PATCH v3 09/12] baseband/acc: add FFT support to VRB2 variant
> 
> 
> 
> On 9/29/23 18:35, Nicolas Chautru wrote:
> > Support for the FFT the processing specific to the
> > VRB2 variant.
> >
> > Signed-off-by: Nicolas Chautru 
> > ---
> >   drivers/baseband/acc/rte_vrb_pmd.c | 132
> -
> >   1 file changed, 128 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/baseband/acc/rte_vrb_pmd.c
> > b/drivers/baseband/acc/rte_vrb_pmd.c
> > index 93add82947..ce4b90d8e7 100644
> > --- a/drivers/baseband/acc/rte_vrb_pmd.c
> > +++ b/drivers/baseband/acc/rte_vrb_pmd.c
> > @@ -903,6 +903,9 @@ vrb_queue_setup(struct rte_bbdev *dev, uint16_t
> queue_id,
> > ACC_FCW_LD_BLEN : (conf->op_type ==
> RTE_BBDEV_OP_FFT ?
> > ACC_FCW_FFT_BLEN : ACC_FCW_MLDTS_BLEN;
> >
> > +   if ((q->d->device_variant == VRB2_VARIANT) && (conf->op_type ==
> RTE_BBDEV_OP_FFT))
> > +   fcw_len = ACC_FCW_FFT_BLEN_3;
> > +
> > for (desc_idx = 0; desc_idx < d->sw_ring_max_depth; desc_idx++) {
> > desc = q->ring_addr + desc_idx;
> > desc->req.word0 = ACC_DMA_DESC_TYPE; @@ -1323,6
> +1326,24 @@
> > vrb_dev_info_get(struct rte_bbdev *dev, struct rte_bbdev_driver_info
> *dev_info)
> > .num_buffers_soft_out = 0,
> > }
> > },
> > +   {
> > +   .type   = RTE_BBDEV_OP_FFT,
> > +   .cap.fft = {
> > +   .capability_flags =
> > +
>   RTE_BBDEV_FFT_WINDOWING |
> > +
>   RTE_BBDEV_FFT_CS_ADJUSTMENT |
> > +
>   RTE_BBDEV_FFT_DFT_BYPASS |
> > +
>   RTE_BBDEV_FFT_IDFT_BYPASS |
> > +   RTE_BBDEV_FFT_FP16_INPUT
> |
> > +
>   RTE_BBDEV_FFT_FP16_OUTPUT |
> > +
>   RTE_BBDEV_FFT_POWER_MEAS |
> > +
>   RTE_BBDEV_FFT_WINDOWING_BYPASS,
> > +   .num_buffers_src =
> > +   1,
> > +   .num_buffers_dst =
> > +   1,
> > +   }
> > +   },
> > RTE_BBDEV_END_OF_CAPABILITIES_LIST()
> > };
> >
> > @@ -3849,6 +3870,47 @@ vrb1_fcw_fft_fill(struct rte_bbdev_fft_op *op,
> struct acc_fcw_fft *fcw)
> > fcw->bypass = 0;
> >   }
> >
> > +/* Fill in a frame control word for FFT processing. */ static inline
> > +void vrb2_fcw_fft_fill(struct rte_bbdev_fft_op *op, struct
> > +acc_fcw_fft_3 *fcw) {
> > +   fcw->in_frame_size = op->fft.input_sequence_size;
> > +   fcw->leading_pad_size = op->fft.input_leading_padding;
> > +   fcw->out_frame_size = op->fft.output_sequence_size;
> > +   fcw->leading_depad_size = op->fft.output_leading_depadding;
> > +   fcw->cs_window_sel = op->fft.window_index[0] +
> > +   (op->fft.window_index[1] << 8) +
> > +   (op->fft.window_index[2] << 16) +
> > +   (op->fft.window_index[3] << 24);
> > +   fcw->cs_window_sel2 = op->fft.window_index[4] +
> > +   (op->fft.window_index[5] << 8);
> > +   fcw->cs_enable_bmap = op->fft.cs_bitmap;
> > +   fcw->num_antennas = op->fft.num_antennas_log2;
> > +   fcw->idft_size = op->fft.idft_log2;
> > +   fcw->dft_size = op->fft.dft_log2;
> > +   fcw->cs_offset = op->fft.cs_time_adjustment;
> > +   fcw->idft_shift = op->fft.idft_shift;
> > +   fcw->dft_shift = op->fft.dft_shift;
> > +   fcw->cs_multiplier = op->fft.ncs_reciprocal;
> > +   fcw->power_shift = op->fft.power_shift; > + fcw->exp_adj = op-
> >fft.fp16_exp_adjust;
> > +   fcw->fp16_in = check_bit(op->fft.op_flags,
> RTE_BBDEV_FFT_FP16_INPUT);
> > +   fcw->fp16_out = check_bit(op->fft.op_flags,
> RTE_BBDEV_FFT_FP16_OUTPUT);
> > +   fcw->power_en = check_bit(op->fft.op_flags,
> RTE_BBDEV_FFT_POWER_MEAS);
> > +   if (check_bit(op->fft.op_flags,
> > +   RTE_BBDEV_FFT_IDFT_BYPASS)) {
> > +   if (check_bit(op->fft.op_flags,
> > +   RTE_BBDEV_FFT_WINDOWING_BYPASS))
> > +   fcw->bypass = 2;
> > +   else
> > +   fcw->bypass = 1;
> > +   } else if (check_bit(op->fft.op_flags,
> > +   RTE_BBDEV_FFT_DFT_BYPASS))
> > +   fcw->bypass = 3;
> > +   else
> > +   fcw->bypass = 0;
> 
> The only difference I see with VRB1 are backed by corresponding op_flags
> (POWER & FP16), is that correct? If so, it does not make sense to me to have a
> specific function for VRB2.

There are more changes but these are only formally enabled in the next stepping 
hence some of the
related code is not included yet. More generally the FCW and IP is different 
from VRB1 implementation. 

> 
> > +}
> > +
> >   static inline int
> > 

[dpdk-dev] [PATCH] common/cnxk: fix direct rte symbol usage

[jerinj]

From: Jerin Jacob 

The common code is shared between different driver environments,
introduce missing plt_ abstractions of missing rte_ symbols and
use plt symbols to avoid changing roc_* files.

Also update the thread name for outbound soft expiry thread
in a7ba40b2b1bf7.

Fixes: 3d4e27fd7ff0 ("use abstracted bit count functions")
Fixes: a7ba40b2b1bf ("drivers: convert to internal control threads")
Fixes: c88d3638c7fc ("common/cnxk: support REE")
Cc: sta...@dpdk.org

Signed-off-by: Jerin Jacob 
---
 drivers/common/cnxk/roc_dev.c  | 2 +-
 drivers/common/cnxk/roc_dev_priv.h | 2 +-
 drivers/common/cnxk/roc_nix_inl_dev.c  | 4 ++--
 drivers/common/cnxk/roc_nix_inl_priv.h | 2 +-
 drivers/common/cnxk/roc_nix_tm.c   | 2 +-
 drivers/common/cnxk/roc_nix_tm_utils.c | 2 +-
 drivers/common/cnxk/roc_npa.c  | 2 +-
 drivers/common/cnxk/roc_npc.c  | 2 +-
 drivers/common/cnxk/roc_npc.h  | 2 +-
 drivers/common/cnxk/roc_npc_mcam.c | 8 
 drivers/common/cnxk/roc_platform.h | 8 +++-
 drivers/common/cnxk/roc_ree.c  | 4 ++--
 drivers/common/cnxk/roc_ree.h  | 2 +-
 13 files changed, 24 insertions(+), 18 deletions(-)

diff --git a/drivers/common/cnxk/roc_dev.c b/drivers/common/cnxk/roc_dev.c
index e41235ea8a..865e2f97c7 100644
--- a/drivers/common/cnxk/roc_dev.c
+++ b/drivers/common/cnxk/roc_dev.c
@@ -1166,7 +1166,7 @@ dev_active_vfs(struct dev *dev)
int i, count = 0;
 
for (i = 0; i < MAX_VFPF_DWORD_BITS; i++)
-   count += rte_popcount32(dev->active_vfs[i]);
+   count += plt_popcount32(dev->active_vfs[i]);
 
return count;
 }
diff --git a/drivers/common/cnxk/roc_dev_priv.h 
b/drivers/common/cnxk/roc_dev_priv.h
index c1a37aa4f0..5b2c5096f8 100644
--- a/drivers/common/cnxk/roc_dev_priv.h
+++ b/drivers/common/cnxk/roc_dev_priv.h
@@ -73,7 +73,7 @@ dev_is_afvf(uint16_t pf_func)
 struct mbox_sync {
bool start_thread;
uint8_t msg_avail;
-   rte_thread_t pfvf_msg_thread;
+   plt_thread_t pfvf_msg_thread;
pthread_cond_t pfvf_msg_cond;
pthread_mutex_t mutex;
 };
diff --git a/drivers/common/cnxk/roc_nix_inl_dev.c 
b/drivers/common/cnxk/roc_nix_inl_dev.c
index 6aa191410b..614d0858e5 100644
--- a/drivers/common/cnxk/roc_nix_inl_dev.c
+++ b/drivers/common/cnxk/roc_nix_inl_dev.c
@@ -826,7 +826,7 @@ nix_inl_outb_poll_thread_setup(struct nix_inl_dev *inl_dev)
soft_exp_consumer_cnt = 0;
soft_exp_poll_thread_exit = false;
rc = plt_thread_create_control(&inl_dev->soft_exp_poll_thread,
-   "outb-poll", nix_inl_outb_poll_thread, inl_dev);
+   "outb-soft-exp-poll", nix_inl_outb_poll_thread, 
inl_dev);
if (rc) {
plt_bitmap_free(inl_dev->soft_exp_ring_bmap);
plt_free(inl_dev->soft_exp_ring_bmap_mem);
@@ -1028,7 +1028,7 @@ roc_nix_inl_dev_fini(struct roc_nix_inl_dev *roc_inl_dev)
 
if (inl_dev->set_soft_exp_poll) {
soft_exp_poll_thread_exit = true;
-   rte_thread_join(inl_dev->soft_exp_poll_thread, NULL);
+   plt_thread_join(inl_dev->soft_exp_poll_thread, NULL);
plt_bitmap_free(inl_dev->soft_exp_ring_bmap);
plt_free(inl_dev->soft_exp_ring_bmap_mem);
plt_free(inl_dev->sa_soft_exp_ring);
diff --git a/drivers/common/cnxk/roc_nix_inl_priv.h 
b/drivers/common/cnxk/roc_nix_inl_priv.h
index b2b89227b1..3217f4ebc1 100644
--- a/drivers/common/cnxk/roc_nix_inl_priv.h
+++ b/drivers/common/cnxk/roc_nix_inl_priv.h
@@ -67,7 +67,7 @@ struct nix_inl_dev {
struct roc_cpt_lf cpt_lf;
 
/* OUTB soft expiry poll thread */
-   rte_thread_t soft_exp_poll_thread;
+   plt_thread_t soft_exp_poll_thread;
uint32_t soft_exp_poll_freq;
uint64_t *sa_soft_exp_ring;
bool set_soft_exp_poll;
diff --git a/drivers/common/cnxk/roc_nix_tm.c b/drivers/common/cnxk/roc_nix_tm.c
index a24bce9e70..ece88b5e99 100644
--- a/drivers/common/cnxk/roc_nix_tm.c
+++ b/drivers/common/cnxk/roc_nix_tm.c
@@ -11,7 +11,7 @@ bitmap_ctzll(uint64_t slab)
if (slab == 0)
return 0;
 
-   return rte_ctz64(slab);
+   return plt_ctz64(slab);
 }
 
 void
diff --git a/drivers/common/cnxk/roc_nix_tm_utils.c 
b/drivers/common/cnxk/roc_nix_tm_utils.c
index c14517c9ea..8e3da95a45 100644
--- a/drivers/common/cnxk/roc_nix_tm_utils.c
+++ b/drivers/common/cnxk/roc_nix_tm_utils.c
@@ -927,7 +927,7 @@ nix_tm_resource_avail(struct nix *nix, uint8_t hw_lvl, bool 
contig)
/* Count bit set */
start_pos = pos;
do {
-   count += rte_popcount64(slab);
+   count += plt_popcount64(slab);
if (!plt_bitmap_scan(bmp, &pos, &slab))
break;
} while (pos != start_pos);
diff --git a/drivers/common/cnxk/roc_npa.c b/drivers/common/cnxk/roc_npa.c
index 1943bc5420..b76b8e2342 100644
--- a/drivers/common/cnxk/roc_npa.c
+++ b/driv

RE: [PATCH v3 06/12] baseband/acc: refactor to allow unified driver extension

[Chautru, Nicolas]

Hi Maxime, 

> -Original Message-
> From: Maxime Coquelin 
> Sent: Tuesday, October 3, 2023 6:15 AM
> To: Chautru, Nicolas ; dev@dpdk.org
> Cc: hemant.agra...@nxp.com; david.march...@redhat.com; Vargas, Hernan
> 
> Subject: Re: [PATCH v3 06/12] baseband/acc: refactor to allow unified driver
> extension
> 
> Thanks for doing the split, that will ease review.
> 
> On 9/29/23 18:35, Nicolas Chautru wrote:
> > Adding a few functions and common code prior to extending the VRB
> > driver.
> >
> > Signed-off-by: Nicolas Chautru 
> > ---
> >   drivers/baseband/acc/acc_common.h | 164 +++-
> --
> >   drivers/baseband/acc/rte_acc100_pmd.c |   4 +-
> >   drivers/baseband/acc/rte_vrb_pmd.c|  62 +-
> >   3 files changed, 184 insertions(+), 46 deletions(-)
> >
> > diff --git a/drivers/baseband/acc/acc_common.h
> > b/drivers/baseband/acc/acc_common.h
> > index 788abf1a3c..89893eae43 100644
> > --- a/drivers/baseband/acc/acc_common.h
> > +++ b/drivers/baseband/acc/acc_common.h
> > @@ -18,6 +18,7 @@
> >   #define ACC_DMA_BLKID_OUT_HARQ  3
> >   #define ACC_DMA_BLKID_IN_HARQ   3
> >   #define ACC_DMA_BLKID_IN_MLD_R  3
> > +#define ACC_DMA_BLKID_DEWIN_IN  3
> >
> >   /* Values used in filling in decode FCWs */
> >   #define ACC_FCW_TD_VER  1
> > @@ -103,6 +104,9 @@
> >   #define ACC_MAX_NUM_QGRPS  32
> >   #define ACC_RING_SIZE_GRANULARITY  64
> >   #define ACC_MAX_FCW_SIZE  128
> > +#define ACC_IQ_SIZE4
> > +
> > +#define ACC_FCW_FFT_BLEN_3 28
> >
> >   /* Constants from K0 computation from 3GPP 38.212 Table 5.4.2.1-2 */
> >   #define ACC_N_ZC_1 66 /* N = 66 Zc for BG 1 */ @@ -132,6 +136,17 @@
> >   #define ACC_LIM_21 14 /* 0.21 */
> >   #define ACC_LIM_31 20 /* 0.31 */
> >   #define ACC_MAX_E (128 * 1024 - 2)
> > +#define ACC_MAX_CS 12
> > +
> > +#define ACC100_VARIANT  0
> > +#define VRB1_VARIANT   2
> > +#define VRB2_VARIANT   3
> > +
> > +/* Queue Index Hierarchy */
> > +#define VRB1_GRP_ID_SHIFT10
> > +#define VRB1_VF_ID_SHIFT 4
> > +#define VRB2_GRP_ID_SHIFT12
> > +#define VRB2_VF_ID_SHIFT 6
> >
> >   /* Helper macro for logging */
> >   #define rte_acc_log(level, fmt, ...) \ @@ -332,6 +347,37 @@ struct
> > __rte_packed acc_fcw_fft {
> > res:19;
> >   };
> >
> > +/* FFT Frame Control Word. */
> > +struct __rte_packed acc_fcw_fft_3 {
> > +   uint32_t in_frame_size:16,
> > +   leading_pad_size:16;
> > +   uint32_t out_frame_size:16,
> > +   leading_depad_size:16;
> > +   uint32_t cs_window_sel;
> > +   uint32_t cs_window_sel2:16,
> > +   cs_enable_bmap:16;
> > +   uint32_t num_antennas:8,
> > +   idft_size:8,
> > +   dft_size:8,
> > +   cs_offset:8;
> > +   uint32_t idft_shift:8,
> > +   dft_shift:8,
> > +   cs_multiplier:16;
> > +   uint32_t bypass:2,
> > +   fp16_in:1,
> > +   fp16_out:1,
> > +   exp_adj:4,
> > +   power_shift:4,
> > +   power_en:1,
> > +   enable_dewin:1,
> > +   freq_resample_mode:2,
> > +   depad_output_size:16;
> > +   uint16_t cs_theta_0[ACC_MAX_CS];
> > +   uint32_t cs_theta_d[ACC_MAX_CS];
> > +   int8_t cs_time_offset[ACC_MAX_CS];
> > +};
> > +
> > +
> >   /* MLD-TS Frame Control Word */
> >   struct __rte_packed acc_fcw_mldts {
> > uint32_t fcw_version:4,
> > @@ -473,14 +519,14 @@ union acc_info_ring_data {
> > uint16_t valid: 1;
> > };
> > struct {
> > -   uint32_t aq_id_3: 6;
> > -   uint32_t qg_id_3: 5;
> > -   uint32_t vf_id_3: 6;
> > -   uint32_t int_nb_3: 6;
> > -   uint32_t msi_0_3: 1;
> > -   uint32_t vf2pf_3: 6;
> > -   uint32_t loop_3: 1;
> > -   uint32_t valid_3: 1;
> > +   uint32_t aq_id_vrb2: 6;
> > +   uint32_t qg_id_vrb2: 5;
> > +   uint32_t vf_id_vrb2: 6;
> > +   uint32_t int_nb_vrb2: 6;
> > +   uint32_t msi_0_vrb2: 1;
> > +   uint32_t vf2pf_vrb2: 6;
> > +   uint32_t loop_vrb2: 1;
> > +   uint32_t valid_vrb2: 1;
> > };
> >   } __rte_packed;
> >
> > @@ -761,22 +807,105 @@ alloc_sw_rings_min_mem(struct rte_bbdev *dev,
> struct acc_device *d,
> > free_base_addresses(base_addrs, i);
> >   }
> >
> > +/* Wrapper to provide VF index from ring data. */ static inline
> > +uint16_t vf_from_ring(const union acc_info_ring_data ring_data,
> > +uint16_t device_variant) {
> 
> curly braces on a new line.

Thanks. 

> 
> > +   if (device_variant == VRB2_VARIANT)
> > +   return ring_data.vf_id_vrb2;
> > +   else
> > +   return ring_data.vf_id;
> > +}
> > +
> > +/* Wrapper to provide QG index from ring data. */ static inline
> > +uint16_t qg_from_ring(const union acc_info_ring_data ring_data,
> > +uint16_t device_variant) {
> > +   if (device_variant == VRB2_VARIANT)
> > +   return ring_data.qg_id_vrb2

RE: [PATCH v3 02/12] baseband/acc: add FFT window width in the VRB PMD

[Chautru, Nicolas]

Hi Maxime, 

> -Original Message-
> From: Maxime Coquelin 
> Sent: Tuesday, October 3, 2023 4:52 AM
> To: Chautru, Nicolas ; dev@dpdk.org
> Cc: hemant.agra...@nxp.com; david.march...@redhat.com; Vargas, Hernan
> 
> Subject: Re: [PATCH v3 02/12] baseband/acc: add FFT window width in the
> VRB PMD
> 
> 
> 
> On 9/29/23 18:35, Nicolas Chautru wrote:
> > This allows to expose the FFT window width being introduced in
> > previous commit based on what is configured dynamically on the device
> > platform.
> >
> > Signed-off-by: Nicolas Chautru 
> > ---
> >   drivers/baseband/acc/acc_common.h  |  3 +++
> >   drivers/baseband/acc/rte_vrb_pmd.c | 29
> +
> >   2 files changed, 32 insertions(+)
> >
> > diff --git a/drivers/baseband/acc/acc_common.h
> > b/drivers/baseband/acc/acc_common.h
> > index 5bb00746c3..7d24c644c0 100644
> > --- a/drivers/baseband/acc/acc_common.h
> > +++ b/drivers/baseband/acc/acc_common.h
> > @@ -512,6 +512,8 @@ struct acc_deq_intr_details {
> >   enum {
> > ACC_VF2PF_STATUS_REQUEST = 1,
> > ACC_VF2PF_USING_VF = 2,
> > +   ACC_VF2PF_LUT_VER_REQUEST = 3,
> > +   ACC_VF2PF_FFT_WIN_REQUEST = 4,
> >   };
> >
> >
> > @@ -558,6 +560,7 @@ struct acc_device {
> > queue_offset_fun_t queue_offset;  /* Device specific queue offset */
> > uint16_t num_qgroups;
> > uint16_t num_aqs;
> > +   uint16_t fft_window_width[RTE_BBDEV_MAX_FFT_WIN]; /* FFT
> windowing
> > +width. */
> >   };
> >
> >   /* Structure associated with each queue. */ diff --git
> > a/drivers/baseband/acc/rte_vrb_pmd.c
> > b/drivers/baseband/acc/rte_vrb_pmd.c
> > index 9e5a73c9c7..c5a74bae11 100644
> > --- a/drivers/baseband/acc/rte_vrb_pmd.c
> > +++ b/drivers/baseband/acc/rte_vrb_pmd.c
> > @@ -298,6 +298,34 @@ vrb_device_status(struct rte_bbdev *dev)
> > return reg;
> >   }
> >
> > +/* Request device FFT windowing information. */ static inline void
> > +vrb_device_fft_win(struct rte_bbdev *dev, struct
> > +rte_bbdev_driver_info *dev_info) {
> > +   struct acc_device *d = dev->data->dev_private;
> > +   uint32_t reg, time_out = 0, win;
> > +
> > +   if (d->pf_device)
> > +   return;
> > +
> > +   /* Check from the device the first time. */
> > +   if (d->fft_window_width[0] == 0) {
> 
> O is not a possible value? Might not be a big deal as it would just perform
> reading of 16 x 2 registers every time .info_get() is called, just wondering.

This is impossible for this to be null. It would mean forcing a zero output all 
the time. Cannot happen fundamentally. 

> 
> > +   for (win = 0; win < RTE_BBDEV_MAX_FFT_WIN; win++) {
> > +   vrb_vf2pf(d, ACC_VF2PF_FFT_WIN_REQUEST | win);
> 
> That looks broken, as extending RTE_BBDEV_MAX_FFT_WIN to support other
> devices may break this implementation.

I don’t believe so. 16 windows shapes is a fairly large, this already takes a 
lot of memory to store all this. 

> 
> To me, it tends to show how this fft_window_width array is more device
> specific than generic.

I don't see why you say this really. This is fundamentally what windowing is. 
This is a given section of the FFT output where you apply a point-wise 
multiplication based on a given window shape, hence the size is scaled up and 
down based on the FFT size. 
This width information is required to estimate about much noise to remove by 
applying such windowing, hence this is enumerated during device enumeration. 
Then the number of windows available is a discrete numbers as mentioned above 
based on how many of these are programmed on the device (these needs to be 
stored in HW memory). 

Would you prefer to expose an additional parameter for the number of windows in 
the capability (ie. size of that array) then a pointer for the actual array? 
That is okay with me and probably better. Please kindly confirm. 
Also Herman feel free to chime in. 

Ie. 
{
.type   = RTE_BBDEV_OP_FFT,
.cap.fft = {
.capability_flags = (...),
.num_windows = 16,
}
},

> 
> > +   reg = acc_reg_read(d, d->reg_addr->pf2vf_doorbell);
> > +   while ((time_out < ACC_STATUS_TO) && (reg ==
> RTE_BBDEV_DEV_NOSTATUS)) {
> > +   usleep(ACC_STATUS_WAIT); /*< Wait or VF-
> >PF->VF Comms */
> > +   reg = acc_reg_read(d, d->reg_addr-
> >pf2vf_doorbell);
> > +   time_out++;
> > +   }
> > +   d->fft_window_width[win] = reg;
> > +   }
> > +   }
> > +
> > +   for (win = 0; win < RTE_BBDEV_MAX_FFT_WIN; win++)
> > +   dev_info->fft_window_width[win] = d-
> >fft_window_width[win]; }
> > +
> >   /* Checks PF Info Ring to find the interrupt cause and handles it
> accordingly. */
> >   static inline void
> >   vrb_check_ir(struct acc_device *acc_dev) @@ -1100,6 +1128,7 @@
> > vrb_dev_inf

Re: [PATCH v4] app/test: add support for skipping tests

[Patrick Robb]

Thanks, this should help greatly going forward in the community lab.

As it relates to our arm64 unit testing, I will give it a few days (or
longer if needed) for next branches to rebase off of main and then
re-enable arm64 unit testing with the eal_flags_file_prefix_autotest added
to the skipped list. David explained to me on slack that this patch would
not likely be a candidate for backporting, so of course LTS will be
excluded.

[PATCH v3 0/4] rte_ether_unformat_addr related changes

[Stephen Hemminger]

This patchset makes rte_ether_unformat_addr allow other formats
for MAC address. Need to remove some inputs from existing
cmdline_etheraddr test, and add a new test in test suite
to cover this.  There is some overlap between the two tests
but that is fine.

v4 - fix spelling errors
 don't allow leading zeros in Cisco 3 part format
 incorporate tap patch to use unformat addr

David Christensen (1):
  net/tap: use rte_ether_unformat_address

Stephen Hemminger (3):
  test: remove some strings from cmdline_etheraddr tests
  rte_ether_unformat: accept more inputs
  test: add tests for rte_ether routines

 app/test/meson.build  |   1 +
 app/test/test_cmdline_etheraddr.c |   8 +-
 app/test/test_net_ether.c | 165 ++
 drivers/net/tap/rte_eth_tap.c |  25 +
 lib/net/rte_ether.c   |  85 +++
 lib/net/rte_ether.h   |  10 +-
 6 files changed, 243 insertions(+), 51 deletions(-)
 create mode 100644 app/test/test_net_ether.c

-- 
2.39.2

[PATCH v3 1/4] test: remove some strings from cmdline_etheraddr tests

[Stephen Hemminger]

Some of the ethernet address formats which were invalid will
now become valid inputs when rte_ether_unformat_addr is modified
to allow leading zeros.

Also, make local variables static.

Acked-by: Morten Brørup 
Signed-off-by: Stephen Hemminger 
---
 app/test/test_cmdline_etheraddr.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/app/test/test_cmdline_etheraddr.c 
b/app/test/test_cmdline_etheraddr.c
index 9691c32ba250..74953dea6cb9 100644
--- a/app/test/test_cmdline_etheraddr.c
+++ b/app/test/test_cmdline_etheraddr.c
@@ -20,7 +20,7 @@ struct ether_addr_str {
 };
 
 /* valid strings */
-const struct ether_addr_str ether_addr_valid_strs[] = {
+static const struct ether_addr_str ether_addr_valid_strs[] = {
{"01:23:45:67:89:AB", 0xAB8967452301ULL},
{"4567:89AB:CDEF", 0xEFCDAB896745ULL},
 };
@@ -30,7 +30,7 @@ const struct ether_addr_str ether_addr_valid_strs[] = {
  * end of token, which is either space chars, null char or
  * a hash sign.
  */
-const char * ether_addr_garbage_strs[] = {
+static const char * const ether_addr_garbage_strs[] = {
"00:11:22:33:44:55\0garbage",
"00:11:22:33:44:55#garbage",
"00:11:22:33:44:55 garbage",
@@ -46,14 +46,13 @@ const char * ether_addr_garbage_strs[] = {
 #define GARBAGE_ETHERADDR 0x554433221100ULL /* corresponding address */
 
 
-const char * ether_addr_invalid_strs[] = {
+static const char * const ether_addr_invalid_strs[] = {
/* valid chars, invalid syntax */
"0123:45:67:89:AB",
"01:23:4567:89:AB",
"01:23:45:67:89AB",
"012:345:678:9AB",
"01:23:45:67:89:ABC",
-   "01:23:45:67:89:A",
"01:23:45:67:89",
"01:23:45:67:89:AB:CD",
/* invalid chars, valid syntax */
@@ -61,7 +60,6 @@ const char * ether_addr_invalid_strs[] = {
"INVA:LIDC:HARS",
/* misc */
"01 23 45 67 89 AB",
-   "01.23.45.67.89.AB",
"01,23,45,67,89,AB",
"01:23:45\0:67:89:AB",
"01:23:45#:67:89:AB",
-- 
2.39.2

[PATCH v3 2/4] rte_ether_unformat: accept more inputs

[Stephen Hemminger]

This updates rte_ether_addr_unformat() to accept more types
formats for MAC address. It allows IEEE, IETF and Cisco
formats. Leading zeros are allowed for byte formats.

Acked-by: Morten Brørup 
Signed-off-by: Stephen Hemminger 
---
 lib/net/rte_ether.c | 85 ++---
 lib/net/rte_ether.h | 10 --
 2 files changed, 73 insertions(+), 22 deletions(-)

diff --git a/lib/net/rte_ether.c b/lib/net/rte_ether.c
index 66d9a9d0699a..f59c20289d37 100644
--- a/lib/net/rte_ether.c
+++ b/lib/net/rte_ether.c
@@ -38,7 +38,8 @@ static int8_t get_xdigit(char ch)
 }
 
 /* Convert 00:11:22:33:44:55 to ethernet address */
-static bool get_ether_addr6(const char *s0, struct rte_ether_addr *ea)
+static bool get_ether_addr6(const char *s0, struct rte_ether_addr *ea,
+   const char sep)
 {
const char *s = s0;
int i;
@@ -48,25 +49,29 @@ static bool get_ether_addr6(const char *s0, struct 
rte_ether_addr *ea)
 
x = get_xdigit(*s++);
if (x < 0)
-   return false;
+   return false;   /* not a hex digit */
 
-   ea->addr_bytes[i] = x << 4;
-   x = get_xdigit(*s++);
-   if (x < 0)
-   return false;
-   ea->addr_bytes[i] |= x;
+   ea->addr_bytes[i] = x;
+   if (*s != sep && *s != '\0') {
+   x = get_xdigit(*s++);
+   if (x < 0)
+   return false;   /* not a hex digit */
+   ea->addr_bytes[i] <<= 4;
+   ea->addr_bytes[i] |= x;
+   }
 
if (i < RTE_ETHER_ADDR_LEN - 1 &&
-   *s++ != ':')
-   return false;
+   *s++ != sep)
+   return false;   /* premature end of string */
}
 
-   /* return true if at end of string */
+   /* return true if no trailing characters */
return *s == '\0';
 }
 
 /* Convert 0011:2233:4455 to ethernet address */
-static bool get_ether_addr3(const char *s, struct rte_ether_addr *ea)
+static bool get_ether_addr3(const char *s, struct rte_ether_addr *ea,
+   const char sep)
 {
int i, j;
 
@@ -78,14 +83,15 @@ static bool get_ether_addr3(const char *s, struct 
rte_ether_addr *ea)
 
x = get_xdigit(*s++);
if (x < 0)
-   return false;
+   return false;   /* not a hex digit */
w = (w << 4) | x;
}
+
ea->addr_bytes[i] = w >> 8;
ea->addr_bytes[i + 1] = w & 0xff;
 
if (i < RTE_ETHER_ADDR_LEN - 2 &&
-   *s++ != ':')
+   *s++ != sep)
return false;
}
 
@@ -93,17 +99,56 @@ static bool get_ether_addr3(const char *s, struct 
rte_ether_addr *ea)
 }
 
 /*
- * Like ether_aton_r but can handle either
- * XX:XX:XX:XX:XX:XX or ::
- * and is more restrictive.
+ * Scan input to see if separated by dash, colon or period
+ * Returns separator and number of matches
+ * If separators are mixed will return
+ */
+static unsigned int get_ether_sep(const char *s, char *sep)
+{
+   static const char separators[] = "-:.";
+   unsigned int count = 0;
+   const char *cp;
+
+   cp = strpbrk(s, separators);
+   if (cp == NULL)
+   return 0;   /* no separator found */
+
+   *sep = *cp; /* return the separator */
+   do {
+   ++count;
+   /* find next instance of separator */
+   cp = strchr(cp + 1, *sep);
+   } while (cp != NULL);
+
+   return count;
+}
+
+/*
+ * Be liberal in accepting a wide variety of notational formats
+ * for MAC address including:
+ *  - Linux format six groups of hexadecimal digits separated by colon
+ *  - Windows format six groups separated by hyphen
+ *  - two groups hexadecimal digits
  */
 int
 rte_ether_unformat_addr(const char *s, struct rte_ether_addr *ea)
 {
-   if (get_ether_addr6(s, ea))
-   return 0;
-   if (get_ether_addr3(s, ea))
-   return 0;
+   unsigned int count;
+   char sep = '\0';
+
+   count = get_ether_sep(s, &sep);
+   switch (count) {
+   case 5: /* i.e 01:23:45:67:89:AB */
+   if (get_ether_addr6(s, ea, sep))
+   return 0;
+   break;
+   case 2: /* i.e 0123.4567.89AB */
+   if (get_ether_addr3(s, ea, sep))
+   return 0;
+   break;
+   default:
+   break;
+   }
 
rte_errno = EINVAL;
return -1;
diff --git a/lib/net/rte_ether.h b/lib/net/rte_ether.h
index b35c72c7b0e0..ce073ea818a2 100644
--- a/lib/net/rte_ether.h
+++ b/lib/net/rte_ether.h
@@ -254,9 +254,15 @@ rte_ether_format_addr

[PATCH v3 3/4] test: add tests for rte_ether routines

[Stephen Hemminger]

This add some basic tests for rte_unformat_ether_addr
and other functions in rte_ether.

Acked-by: Morten Brørup 
Signed-off-by: Stephen Hemminger 
---
 app/test/meson.build  |   1 +
 app/test/test_net_ether.c | 165 ++
 2 files changed, 166 insertions(+)
 create mode 100644 app/test/test_net_ether.c

diff --git a/app/test/meson.build b/app/test/meson.build
index bf9fc906128f..20a9333c726d 100644
--- a/app/test/meson.build
+++ b/app/test/meson.build
@@ -124,6 +124,7 @@ source_file_deps = {
 'test_meter.c': ['meter'],
 'test_metrics.c': ['metrics'],
 'test_mp_secondary.c': ['hash', 'lpm'],
+'test_net_ether.c': ['net'],
 'test_pcapng.c': ['ethdev', 'net', 'pcapng'],
 'test_pdcp.c': ['eventdev', 'pdcp', 'net', 'timer', 'security'],
 'test_pdump.c': ['pdump'] + sample_packet_forward_deps,
diff --git a/app/test/test_net_ether.c b/app/test/test_net_ether.c
new file mode 100644
index ..1cb6845a9c48
--- /dev/null
+++ b/app/test/test_net_ether.c
@@ -0,0 +1,165 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright (c) 2023 Stephen Hemminger
+ */
+
+#include 
+
+#include 
+#include "test.h"
+
+#define N 100
+
+static const struct rte_ether_addr zero_ea;
+static const struct rte_ether_addr bcast_ea = {
+   .addr_bytes = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff },
+};
+
+static int
+test_ether_addr(void)
+{
+   struct rte_ether_addr rand_ea = { };
+   unsigned int i;
+
+   RTE_TEST_ASSERT(rte_is_zero_ether_addr(&zero_ea), "Zero address is not 
zero");
+   RTE_TEST_ASSERT(!rte_is_zero_ether_addr(&bcast_ea), "Broadcast is 
zero");
+
+   for (i = 0; i < N; i++) {
+   rte_eth_random_addr(rand_ea.addr_bytes);
+   RTE_TEST_ASSERT(!rte_is_zero_ether_addr(&rand_ea),
+   "Random address is zero");
+   RTE_TEST_ASSERT(rte_is_unicast_ether_addr(&rand_ea),
+   "Random address is not unicast");
+   RTE_TEST_ASSERT(rte_is_local_admin_ether_addr(&rand_ea),
+   "Random address is not local admin");
+   }
+
+   return 0;
+}
+
+static int
+test_format_addr(void)
+{
+   struct rte_ether_addr rand_ea = { };
+   char buf[RTE_ETHER_ADDR_FMT_SIZE];
+   unsigned int i;
+
+   for (i = 0; i < N; i++) {
+   struct rte_ether_addr result = { };
+   int ret;
+
+   rte_eth_random_addr(rand_ea.addr_bytes);
+
+   rte_ether_format_addr(buf, sizeof(buf), &rand_ea);
+
+   ret = rte_ether_unformat_addr(buf, &result);
+   if (ret != 0) {
+   fprintf(stderr, "rte_ether_unformat_addr(%s) failed\n", 
buf);
+   return -1;
+   }
+   RTE_TEST_ASSERT(rte_is_same_ether_addr(&rand_ea, &result),
+   "rte_ether_format/unformat mismatch");
+   }
+   return 0;
+
+}
+
+static int
+test_unformat_addr(void)
+{
+   const struct rte_ether_addr expected = {
+   .addr_bytes = { 0x12, 0x34, 0x56, 0x78, 0x9a, 0xbc },
+   };
+   const struct rte_ether_addr nozero_ea = {
+   .addr_bytes = { 1, 2, 3, 4, 5, 6 },
+   };
+   struct rte_ether_addr result;
+   int ret;
+
+   /* Test IETF format */
+   memset(&result, 0, sizeof(result));
+   ret = rte_ether_unformat_addr("12:34:56:78:9a:bc", &result);
+   RTE_TEST_ASSERT(ret == 0, "IETF unformat failed");
+   RTE_TEST_ASSERT(rte_is_same_ether_addr(&expected, &result),
+   "IETF unformat mismatch");
+
+   /* Test IEEE format */
+   memset(&result, 0, sizeof(result));
+   ret = rte_ether_unformat_addr("12-34-56-78-9A-BC", &result);
+   RTE_TEST_ASSERT(ret == 0, "IEEE unformat failed");
+   RTE_TEST_ASSERT(rte_is_same_ether_addr(&expected, &result),
+   "IEEE unformat mismatch");
+
+   /* Test Cisco format */
+   memset(&result, 0, sizeof(result));
+   ret = rte_ether_unformat_addr("1234.5678.9ABC", &result);
+   RTE_TEST_ASSERT(ret == 0, "Cisco unformat failed");
+   RTE_TEST_ASSERT(rte_is_same_ether_addr(&expected, &result),
+   "Cisco unformat mismatch");
+
+   /* Test no leading zeros - IETF */
+   memset(&result, 0, sizeof(result));
+   ret = rte_ether_unformat_addr("1:2:3:4:5:6", &result);
+   RTE_TEST_ASSERT(ret == 0, "IETF leading zero failed");
+   RTE_TEST_ASSERT(rte_is_same_ether_addr(&nozero_ea, &result),
+   "IETF leading zero mismatch");
+
+   /* Test no-leading zero - IEEE format */
+   memset(&result, 0, sizeof(result));
+   ret = rte_ether_unformat_addr("1-2-3-4-5-6", &result);
+   RTE_TEST_ASSERT(ret == 0, "IEEE leading zero failed");
+   RTE_TEST_ASSERT(rte_is_same_ether_addr(&nozero_ea, &result),
+   "IEEE leading zero mismatch");
+
+
+   return 0;
+}
+
+static

[PATCH v3 4/4] net/tap: use rte_ether_unformat_address

[Stephen Hemminger]

From: David Christensen 

Building DPDK with gcc 12 on a ppc64le system generates a
stringop-overflow warning. Replace the local MAC address
validation function parse_user_mac() with a call to
rte_ether_unformat_addr() instead.

Bugzilla ID: 1197
Cc: sta...@dpdk.org

Signed-off-by: David Christensen 
Signed-off-by: Stephen Hemminger 
---
 drivers/net/tap/rte_eth_tap.c | 25 +
 1 file changed, 1 insertion(+), 24 deletions(-)

diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
index bf98f7555990..b25a52655fa2 100644
--- a/drivers/net/tap/rte_eth_tap.c
+++ b/drivers/net/tap/rte_eth_tap.c
@@ -2267,29 +2267,6 @@ set_remote_iface(const char *key __rte_unused,
return 0;
 }
 
-static int parse_user_mac(struct rte_ether_addr *user_mac,
-   const char *value)
-{
-   unsigned int index = 0;
-   char mac_temp[strlen(ETH_TAP_USR_MAC_FMT) + 1], *mac_byte = NULL;
-
-   if (user_mac == NULL || value == NULL)
-   return 0;
-
-   strlcpy(mac_temp, value, sizeof(mac_temp));
-   mac_byte = strtok(mac_temp, ":");
-
-   while ((mac_byte != NULL) &&
-   (strlen(mac_byte) <= 2) &&
-   (strlen(mac_byte) == strspn(mac_byte,
-   ETH_TAP_CMP_MAC_FMT))) {
-   user_mac->addr_bytes[index++] = strtoul(mac_byte, NULL, 16);
-   mac_byte = strtok(NULL, ":");
-   }
-
-   return index;
-}
-
 static int
 set_mac_type(const char *key __rte_unused,
 const char *value,
@@ -2311,7 +2288,7 @@ set_mac_type(const char *key __rte_unused,
goto success;
}
 
-   if (parse_user_mac(user_mac, value) != 6)
+   if (rte_ether_unformat_addr(value, user_mac) < 0)
goto error;
 success:
TAP_LOG(DEBUG, "TAP user MAC param (%s)", value);
-- 
2.39.2

[PATCH] raw/cnxk_bphy: support multi-process mode

[Tomasz Duszynski]

Add support for sharing BPHY PMD across multiple running processes.
In scenarios where resources need to be shared across processes
user-space need to ensure serialization.

Signed-off-by: Tomasz Duszynski 
Reviewed-by: Jerin Jacob Kollanukkaran 
Tested-by: Jerin Jacob Kollanukkaran 
---
 doc/guides/rawdevs/cnxk_bphy.rst  |  8 
 drivers/raw/cnxk_bphy/cnxk_bphy.c | 16 ++--
 2 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/doc/guides/rawdevs/cnxk_bphy.rst b/doc/guides/rawdevs/cnxk_bphy.rst
index 2490912534..b544b543a3 100644
--- a/doc/guides/rawdevs/cnxk_bphy.rst
+++ b/doc/guides/rawdevs/cnxk_bphy.rst
@@ -19,6 +19,14 @@ The BPHY CGX/RPM implements following features in the rawdev 
API:
 - Access to BPHY CGX/RPM via a set of predefined messages
 - Access to BPHY memory
 - Custom interrupt handlers
+- Multiprocess aware
+
+Limitations
+---
+
+In multiprocess mode user-space application must ensure no resources
+sharing takes place. Otherwise, user-space application should ensure
+synchronization.
 
 Device Setup
 
diff --git a/drivers/raw/cnxk_bphy/cnxk_bphy.c 
b/drivers/raw/cnxk_bphy/cnxk_bphy.c
index d42cca649c..15dbc4c1a6 100644
--- a/drivers/raw/cnxk_bphy/cnxk_bphy.c
+++ b/drivers/raw/cnxk_bphy/cnxk_bphy.c
@@ -359,10 +359,12 @@ bphy_rawdev_probe(struct rte_pci_driver *pci_drv,
bphy_dev->mem.res2 = pci_dev->mem_resource[2];
bphy_dev->bphy.pci_dev = pci_dev;
 
-   ret = roc_bphy_dev_init(&bphy_dev->bphy);
-   if (ret) {
-   rte_rawdev_pmd_release(bphy_rawdev);
-   return ret;
+   if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
+   ret = roc_bphy_dev_init(&bphy_dev->bphy);
+   if (ret) {
+   rte_rawdev_pmd_release(bphy_rawdev);
+   return ret;
+   }
}
 
return 0;
@@ -390,8 +392,10 @@ bphy_rawdev_remove(struct rte_pci_device *pci_dev)
return -EINVAL;
}
 
-   bphy_dev = (struct bphy_device *)rawdev->dev_private;
-   roc_bphy_dev_fini(&bphy_dev->bphy);
+   if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
+   bphy_dev = (struct bphy_device *)rawdev->dev_private;
+   roc_bphy_dev_fini(&bphy_dev->bphy);
+   }
 
return rte_rawdev_pmd_release(rawdev);
 }
-- 
2.34.1

[PATCH 1/2] raw/cnxk_gpio: support multi-process mode

[Tomasz Duszynski]

GPIO PMD uses a mixture of standard sysfs attributes and custom
ioctl()s to control behaviour of respective GPIOs available in
the system.

This means that each userspace application, either running as a primary
or a secondary, should be able to control a set of distinct GPIOs.

In rare cases where multiple processes need to control the same set of
GPIOs userspace application is responsible for synchronizing accesses.

Signed-off-by: Tomasz Duszynski 
Reviewed-by: Jerin Jacob Kollanukkaran 
---
 doc/guides/rawdevs/cnxk_gpio.rst  |   7 ++
 drivers/raw/cnxk_gpio/cnxk_gpio.c | 143 --
 2 files changed, 104 insertions(+), 46 deletions(-)

diff --git a/doc/guides/rawdevs/cnxk_gpio.rst b/doc/guides/rawdevs/cnxk_gpio.rst
index adff535a77..848ad329e7 100644
--- a/doc/guides/rawdevs/cnxk_gpio.rst
+++ b/doc/guides/rawdevs/cnxk_gpio.rst
@@ -21,6 +21,7 @@ Following features are available:
 - set GPIO edge that triggers interrupt
 - set GPIO active low
 - register interrupt handler for specific GPIO
+- multiprocess aware
 
 Requirements
 
@@ -30,6 +31,12 @@ for installing interrupt handlers for low latency signal 
processing.
 
 Driver is shipped with Marvell SDK.
 
+Limitations
+---
+
+In multiprocess mode user-space application must ensure no GPIO sharing across
+processes takes place.
+
 Device Setup
 
 
diff --git a/drivers/raw/cnxk_gpio/cnxk_gpio.c 
b/drivers/raw/cnxk_gpio/cnxk_gpio.c
index e2907c18b5..dcd646397e 100644
--- a/drivers/raw/cnxk_gpio/cnxk_gpio.c
+++ b/drivers/raw/cnxk_gpio/cnxk_gpio.c
@@ -19,6 +19,12 @@
 
 #define CNXK_GPIO_BUFSZ 128
 #define CNXK_GPIO_CLASS_PATH "/sys/class/gpio"
+#define CNXK_GPIO_PARAMS_MZ_NAME "cnxk_gpio_params_mz"
+
+struct cnxk_gpio_params {
+   char allowlist[CNXK_GPIO_BUFSZ];
+   int num;
+};
 
 static const char *const cnxk_gpio_args[] = {
 #define CNXK_GPIO_ARG_GPIOCHIP "gpiochip"
@@ -28,8 +34,6 @@ static const char *const cnxk_gpio_args[] = {
NULL
 };
 
-static char *allowlist;
-
 static void
 cnxk_gpio_format_name(char *name, size_t len)
 {
@@ -44,8 +48,8 @@ cnxk_gpio_filter_gpiochip(const struct dirent *dirent)
return !strncmp(dirent->d_name, pattern, strlen(pattern));
 }
 
-static void
-cnxk_gpio_set_defaults(struct cnxk_gpiochip *gpiochip)
+static int
+cnxk_gpio_set_defaults(struct cnxk_gpio_params *params)
 {
struct dirent **namelist;
int n;
@@ -53,12 +57,14 @@ cnxk_gpio_set_defaults(struct cnxk_gpiochip *gpiochip)
n = scandir(CNXK_GPIO_CLASS_PATH, &namelist, cnxk_gpio_filter_gpiochip,
alphasort);
if (n < 0 || n == 0)
-   return;
+   return -ENODEV;
 
-   sscanf(namelist[0]->d_name, "gpiochip%d", &gpiochip->num);
+   sscanf(namelist[0]->d_name, "gpiochip%d", ¶ms->num);
while (n--)
free(namelist[n]);
free(namelist);
+
+   return 0;
 }
 
 static int
@@ -78,21 +84,53 @@ cnxk_gpio_parse_arg_gpiochip(const char *key __rte_unused, 
const char *value,
 }
 
 static int
-cnxk_gpio_parse_arg_allowlist(const char *key __rte_unused, const char *value,
- void *extra_args __rte_unused)
+cnxk_gpio_parse_arg_allowlist(const char *key __rte_unused, const char *value, 
void *extra_args)
 {
-   allowlist = strdup(value);
-   if (!allowlist)
+   char *allowlist = extra_args;
+
+   rte_strlcpy(allowlist, value, sizeof(((struct cnxk_gpio_params 
*)0)->allowlist));
+
+   return 0;
+}
+
+static int
+cnxk_gpio_params_store(struct cnxk_gpio_params *params)
+{
+   const struct rte_memzone *mz;
+
+   mz = rte_memzone_reserve(CNXK_GPIO_PARAMS_MZ_NAME, sizeof(*params), 
rte_socket_id(), 0);
+   if (!mz)
return -ENOMEM;
 
+   memcpy(mz->addr, params, sizeof(*params));
+
return 0;
 }
 
+static void
+cnxk_gpio_params_restore(struct cnxk_gpio_params *params)
+{
+   const struct rte_memzone *mz;
+
+   mz = rte_memzone_lookup(CNXK_GPIO_PARAMS_MZ_NAME);
+   if (!mz)
+   return;
+
+   memcpy(params, mz->addr, sizeof(*params));
+}
+
+static void
+cnxk_gpio_params_release(void)
+{
+   if (rte_eal_process_type() == RTE_PROC_PRIMARY)
+   rte_memzone_free(rte_memzone_lookup(CNXK_GPIO_PARAMS_MZ_NAME));
+}
+
 static int
-cnxk_gpio_parse_args(struct cnxk_gpiochip *gpiochip, const char *args)
+cnxk_gpio_parse_args(struct cnxk_gpio_params *params, const char *args)
 {
struct rte_kvargs *kvlist;
-   int ret;
+   int ret, num = 0;
 
kvlist = rte_kvargs_parse(args, cnxk_gpio_args);
if (!kvlist)
@@ -101,21 +139,21 @@ cnxk_gpio_parse_args(struct cnxk_gpiochip *gpiochip, 
const char *args)
ret = rte_kvargs_count(kvlist, CNXK_GPIO_ARG_GPIOCHIP);
if (ret == 1) {
ret = rte_kvargs_process(kvlist, CNXK_GPIO_ARG_GPIOCHIP,
-cnxk_gpio_parse_arg_gpiochip,
-&gp

[PATCH 2/2] raw/cnxk_gpio: add bunch of newlines

[Tomasz Duszynski]

Improve log output by adding some newlines.

Signed-off-by: Tomasz Duszynski 
Reviewed-by: Jerin Jacob Kollanukkaran 
Tested-by: Jerin Jacob Kollanukkaran 
---
 drivers/raw/cnxk_gpio/cnxk_gpio.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/raw/cnxk_gpio/cnxk_gpio.c 
b/drivers/raw/cnxk_gpio/cnxk_gpio.c
index dcd646397e..6c4e4f5eae 100644
--- a/drivers/raw/cnxk_gpio/cnxk_gpio.c
+++ b/drivers/raw/cnxk_gpio/cnxk_gpio.c
@@ -713,7 +713,7 @@ cnxk_gpio_probe(struct rte_vdev_device *dev)
cnxk_gpio_format_name(name, sizeof(name));
rawdev = rte_rawdev_pmd_allocate(name, sizeof(*gpiochip), 
rte_socket_id());
if (!rawdev) {
-   RTE_LOG(ERR, PMD, "failed to allocate %s rawdev", name);
+   RTE_LOG(ERR, PMD, "failed to allocate %s rawdev\n", name);
return -ENOMEM;
}
 
@@ -753,7 +753,7 @@ cnxk_gpio_probe(struct rte_vdev_device *dev)
snprintf(buf, sizeof(buf), "%s/gpiochip%d/base", CNXK_GPIO_CLASS_PATH, 
gpiochip->num);
ret = cnxk_gpio_read_attr_int(buf, &gpiochip->base);
if (ret) {
-   RTE_LOG(ERR, PMD, "failed to read %s", buf);
+   RTE_LOG(ERR, PMD, "failed to read %s\n", buf);
goto out;
}
 
@@ -761,7 +761,7 @@ cnxk_gpio_probe(struct rte_vdev_device *dev)
snprintf(buf, sizeof(buf), "%s/gpiochip%d/ngpio", CNXK_GPIO_CLASS_PATH, 
gpiochip->num);
ret = cnxk_gpio_read_attr_int(buf, &gpiochip->num_gpios);
if (ret) {
-   RTE_LOG(ERR, PMD, "failed to read %s", buf);
+   RTE_LOG(ERR, PMD, "failed to read %s\n", buf);
goto out;
}
gpiochip->num_queues = gpiochip->num_gpios;
@@ -774,7 +774,7 @@ cnxk_gpio_probe(struct rte_vdev_device *dev)
 
gpiochip->gpios = rte_calloc(NULL, gpiochip->num_gpios, sizeof(struct 
cnxk_gpio *), 0);
if (!gpiochip->gpios) {
-   RTE_LOG(ERR, PMD, "failed to allocate gpios memory");
+   RTE_LOG(ERR, PMD, "failed to allocate gpios memory\n");
ret = -ENOMEM;
goto out;
}
-- 
2.34.1

Re: [PATCH 2/2] raw/cnxk_gpio: add bunch of newlines

[Stephen Hemminger]

On Tue, 3 Oct 2023 22:46:03 +0200
Tomasz Duszynski  wrote:

> Improve log output by adding some newlines.
> 
> Signed-off-by: Tomasz Duszynski 
> Reviewed-by: Jerin Jacob Kollanukkaran 
> Tested-by: Jerin Jacob Kollanukkaran 
> ---
>  drivers/raw/cnxk_gpio/cnxk_gpio.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/raw/cnxk_gpio/cnxk_gpio.c 
> b/drivers/raw/cnxk_gpio/cnxk_gpio.c
> index dcd646397e..6c4e4f5eae 100644
> --- a/drivers/raw/cnxk_gpio/cnxk_gpio.c
> +++ b/drivers/raw/cnxk_gpio/cnxk_gpio.c
> @@ -713,7 +713,7 @@ cnxk_gpio_probe(struct rte_vdev_device *dev)
>   cnxk_gpio_format_name(name, sizeof(name));
>   rawdev = rte_rawdev_pmd_allocate(name, sizeof(*gpiochip), 
> rte_socket_id());
>   if (!rawdev) {
> - RTE_LOG(ERR, PMD, "failed to allocate %s rawdev", name);
> + RTE_LOG(ERR, PMD, "failed to allocate %s rawdev\n", name);
>   return -ENOMEM;
>   }
>  
> @@ -753,7 +753,7 @@ cnxk_gpio_probe(struct rte_vdev_device *dev)
>   snprintf(buf, sizeof(buf), "%s/gpiochip%d/base", CNXK_GPIO_CLASS_PATH, 
> gpiochip->num);
>   ret = cnxk_gpio_read_attr_int(buf, &gpiochip->base);
>   if (ret) {
> - RTE_LOG(ERR, PMD, "failed to read %s", buf);
> + RTE_LOG(ERR, PMD, "failed to read %s\n", buf);
>   goto out;
>   }
>  
> @@ -761,7 +761,7 @@ cnxk_gpio_probe(struct rte_vdev_device *dev)
>   snprintf(buf, sizeof(buf), "%s/gpiochip%d/ngpio", CNXK_GPIO_CLASS_PATH, 
> gpiochip->num);
>   ret = cnxk_gpio_read_attr_int(buf, &gpiochip->num_gpios);
>   if (ret) {
> - RTE_LOG(ERR, PMD, "failed to read %s", buf);
> + RTE_LOG(ERR, PMD, "failed to read %s\n", buf);
>   goto out;
>   }
>   gpiochip->num_queues = gpiochip->num_gpios;
> @@ -774,7 +774,7 @@ cnxk_gpio_probe(struct rte_vdev_device *dev)
>  
>   gpiochip->gpios = rte_calloc(NULL, gpiochip->num_gpios, sizeof(struct 
> cnxk_gpio *), 0);
>   if (!gpiochip->gpios) {
> - RTE_LOG(ERR, PMD, "failed to allocate gpios memory");
> + RTE_LOG(ERR, PMD, "failed to allocate gpios memory\n");
>   ret = -ENOMEM;
>   goto out;
>   }


No driver should be using the PMD logtype. It should always be using a 
dynamically
allocated log type.

Re: [PATCH 1/2] raw/cnxk_gpio: support multi-process mode

[Stephen Hemminger]

On Tue, 3 Oct 2023 22:46:02 +0200
Tomasz Duszynski  wrote:

> +
> +struct cnxk_gpio_params {
> + char allowlist[CNXK_GPIO_BUFSZ];
> + int num;
> +};

Should be using unsigned for number of params since can't be negative.
You could also use a flex array to avoid any buf size issues.

Reminder - DPDK Tech Board Meeting - Tomorrow, Wed., Oct 4, 2023 - 8am Pacific/11am Eastern/1500h UTC

[Nathan Southern]

Good evening,

Tomorrow the DPDK Tech Board will hold its biweekly meeting -  8am
Pacific/11am Eastern/1500h UTC.

Here is a read-only copy of the agenda:

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

Minutes will be kept here:

*http://core.dpdk.org/techboard/minutes
*

And zoom information to follow; please use the community join link. See you
soon

Thanks,

Nathan



Ways to join meeting: 1. Join from PC, Mac, iPad, or Android
https://zoom-lfx.platform.linuxfoundation.org/meeting/96459488340?password=d808f1f6-0a28-4165-929e-5a5bcae7efeb

2. Join via audio One tap mobile: US: +12532158782,,96459488340# or
+13462487799,,96459488340 Or dial: US: +1 253 215 8782 or +1 346 248 7799
or +1 669 900 6833 or +1 301 715 8592 or +1 312 626 6799 or +1 646 374 8656
or 877 369 0926 (Toll Free) or 855 880 1246 (Toll Free) Canada: +1 647 374
4685 or +1 647 558 0588 or +1 778 907 2071 or +1 204 272 7920 or +1 438 809
7799 or +1 587 328 1099 or 855 703 8985 (Toll Free) Meeting ID: 96459488340
Meeting Passcode: 699526 International numbers: https://zoom.us/u/alwnPIaVT


   1. 10 minutes before

i...@linuxfoundation.org
Created by: Nathan Southern

RE: [PATCH v2 1/1] app/mldev: fix check for filelist and models count

[Anup Prabhu]

> -Original Message-
> From: Srikanth Yalavarthi 
> Sent: Wednesday, September 20, 2023 12:39 PM
> To: Srikanth Yalavarthi ; Anup Prabhu
> 
> Cc: dev@dpdk.org; Shivah Shankar Shankar Narayan Rao
> ; Prince Takkar ;
> sta...@dpdk.org
> Subject: [PATCH v2 1/1] app/mldev: fix check for filelist and models count
> 
> Fix incorrect check for filelist and models count.
> 
> Fixes: bbd272edcb14 ("app/mldev: add ordered inferences")
> Fixes: f6661e6d9a3a ("app/mldev: validate model operations")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Srikanth Yalavarthi 
Acked-by: Anup Prabhu 
<>

Re: [dpdk-dev] [PATCH] common/cnxk: fix direct rte symbol usage

[Nithin Dabilpuram]

Acked-by: Nithin Dabilpuram 

On Wed, Oct 4, 2023 at 2:36 AM  wrote:
>
> From: Jerin Jacob 
>
> The common code is shared between different driver environments,
> introduce missing plt_ abstractions of missing rte_ symbols and
> use plt symbols to avoid changing roc_* files.
>
> Also update the thread name for outbound soft expiry thread
> in a7ba40b2b1bf7.
>
> Fixes: 3d4e27fd7ff0 ("use abstracted bit count functions")
> Fixes: a7ba40b2b1bf ("drivers: convert to internal control threads")
> Fixes: c88d3638c7fc ("common/cnxk: support REE")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Jerin Jacob 
> ---
>  drivers/common/cnxk/roc_dev.c  | 2 +-
>  drivers/common/cnxk/roc_dev_priv.h | 2 +-
>  drivers/common/cnxk/roc_nix_inl_dev.c  | 4 ++--
>  drivers/common/cnxk/roc_nix_inl_priv.h | 2 +-
>  drivers/common/cnxk/roc_nix_tm.c   | 2 +-
>  drivers/common/cnxk/roc_nix_tm_utils.c | 2 +-
>  drivers/common/cnxk/roc_npa.c  | 2 +-
>  drivers/common/cnxk/roc_npc.c  | 2 +-
>  drivers/common/cnxk/roc_npc.h  | 2 +-
>  drivers/common/cnxk/roc_npc_mcam.c | 8 
>  drivers/common/cnxk/roc_platform.h | 8 +++-
>  drivers/common/cnxk/roc_ree.c  | 4 ++--
>  drivers/common/cnxk/roc_ree.h  | 2 +-
>  13 files changed, 24 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/common/cnxk/roc_dev.c b/drivers/common/cnxk/roc_dev.c
> index e41235ea8a..865e2f97c7 100644
> --- a/drivers/common/cnxk/roc_dev.c
> +++ b/drivers/common/cnxk/roc_dev.c
> @@ -1166,7 +1166,7 @@ dev_active_vfs(struct dev *dev)
> int i, count = 0;
>
> for (i = 0; i < MAX_VFPF_DWORD_BITS; i++)
> -   count += rte_popcount32(dev->active_vfs[i]);
> +   count += plt_popcount32(dev->active_vfs[i]);
>
> return count;
>  }
> diff --git a/drivers/common/cnxk/roc_dev_priv.h 
> b/drivers/common/cnxk/roc_dev_priv.h
> index c1a37aa4f0..5b2c5096f8 100644
> --- a/drivers/common/cnxk/roc_dev_priv.h
> +++ b/drivers/common/cnxk/roc_dev_priv.h
> @@ -73,7 +73,7 @@ dev_is_afvf(uint16_t pf_func)
>  struct mbox_sync {
> bool start_thread;
> uint8_t msg_avail;
> -   rte_thread_t pfvf_msg_thread;
> +   plt_thread_t pfvf_msg_thread;
> pthread_cond_t pfvf_msg_cond;
> pthread_mutex_t mutex;
>  };
> diff --git a/drivers/common/cnxk/roc_nix_inl_dev.c 
> b/drivers/common/cnxk/roc_nix_inl_dev.c
> index 6aa191410b..614d0858e5 100644
> --- a/drivers/common/cnxk/roc_nix_inl_dev.c
> +++ b/drivers/common/cnxk/roc_nix_inl_dev.c
> @@ -826,7 +826,7 @@ nix_inl_outb_poll_thread_setup(struct nix_inl_dev 
> *inl_dev)
> soft_exp_consumer_cnt = 0;
> soft_exp_poll_thread_exit = false;
> rc = plt_thread_create_control(&inl_dev->soft_exp_poll_thread,
> -   "outb-poll", nix_inl_outb_poll_thread, inl_dev);
> +   "outb-soft-exp-poll", nix_inl_outb_poll_thread, 
> inl_dev);
> if (rc) {
> plt_bitmap_free(inl_dev->soft_exp_ring_bmap);
> plt_free(inl_dev->soft_exp_ring_bmap_mem);
> @@ -1028,7 +1028,7 @@ roc_nix_inl_dev_fini(struct roc_nix_inl_dev 
> *roc_inl_dev)
>
> if (inl_dev->set_soft_exp_poll) {
> soft_exp_poll_thread_exit = true;
> -   rte_thread_join(inl_dev->soft_exp_poll_thread, NULL);
> +   plt_thread_join(inl_dev->soft_exp_poll_thread, NULL);
> plt_bitmap_free(inl_dev->soft_exp_ring_bmap);
> plt_free(inl_dev->soft_exp_ring_bmap_mem);
> plt_free(inl_dev->sa_soft_exp_ring);
> diff --git a/drivers/common/cnxk/roc_nix_inl_priv.h 
> b/drivers/common/cnxk/roc_nix_inl_priv.h
> index b2b89227b1..3217f4ebc1 100644
> --- a/drivers/common/cnxk/roc_nix_inl_priv.h
> +++ b/drivers/common/cnxk/roc_nix_inl_priv.h
> @@ -67,7 +67,7 @@ struct nix_inl_dev {
> struct roc_cpt_lf cpt_lf;
>
> /* OUTB soft expiry poll thread */
> -   rte_thread_t soft_exp_poll_thread;
> +   plt_thread_t soft_exp_poll_thread;
> uint32_t soft_exp_poll_freq;
> uint64_t *sa_soft_exp_ring;
> bool set_soft_exp_poll;
> diff --git a/drivers/common/cnxk/roc_nix_tm.c 
> b/drivers/common/cnxk/roc_nix_tm.c
> index a24bce9e70..ece88b5e99 100644
> --- a/drivers/common/cnxk/roc_nix_tm.c
> +++ b/drivers/common/cnxk/roc_nix_tm.c
> @@ -11,7 +11,7 @@ bitmap_ctzll(uint64_t slab)
> if (slab == 0)
> return 0;
>
> -   return rte_ctz64(slab);
> +   return plt_ctz64(slab);
>  }
>
>  void
> diff --git a/drivers/common/cnxk/roc_nix_tm_utils.c 
> b/drivers/common/cnxk/roc_nix_tm_utils.c
> index c14517c9ea..8e3da95a45 100644
> --- a/drivers/common/cnxk/roc_nix_tm_utils.c
> +++ b/drivers/common/cnxk/roc_nix_tm_utils.c
> @@ -927,7 +927,7 @@ nix_tm_resource_avail(struct nix *nix, uint8_t hw_lvl, 
> bool contig)
> /* Count bit set */
> start_pos = pos;
> do {
> -   count += rte_popcount64(slab);
> +   count 

Re: [dpdk-dev] [PATCH] common/cnxk: fix direct rte symbol usage

[David Marchand]

Hello Jerin,

On Tue, Oct 3, 2023 at 8:40 PM  wrote:
>
> From: Jerin Jacob 
>
> The common code is shared between different driver environments,
> introduce missing plt_ abstractions of missing rte_ symbols and
> use plt symbols to avoid changing roc_* files.
>
> Also update the thread name for outbound soft expiry thread
> in a7ba40b2b1bf7.
>
> Fixes: 3d4e27fd7ff0 ("use abstracted bit count functions")
> Fixes: a7ba40b2b1bf ("drivers: convert to internal control threads")
> Fixes: c88d3638c7fc ("common/cnxk: support REE")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Jerin Jacob 

- Could we add something in checkpatch for this driver?
I was aware of this s/rte_/plt_/ peculiarity but still missed it...

- If you want this backported in LTS, I suggest splitting the fix
against c88d3638c7fc ("common/cnxk: support REE") and the rest than
only affects current release.

- One comment:

> diff --git a/drivers/common/cnxk/roc_nix_inl_dev.c 
> b/drivers/common/cnxk/roc_nix_inl_dev.c
> index 6aa191410b..614d0858e5 100644
> --- a/drivers/common/cnxk/roc_nix_inl_dev.c
> +++ b/drivers/common/cnxk/roc_nix_inl_dev.c
> @@ -826,7 +826,7 @@ nix_inl_outb_poll_thread_setup(struct nix_inl_dev 
> *inl_dev)
> soft_exp_consumer_cnt = 0;
> soft_exp_poll_thread_exit = false;
> rc = plt_thread_create_control(&inl_dev->soft_exp_poll_thread,
> -   "outb-poll", nix_inl_outb_poll_thread, inl_dev);
> +   "outb-soft-exp-poll", nix_inl_outb_poll_thread, 
> inl_dev);

Such a thread name is too long.
This is reverting Thomas change.

Is this intentional?


-- 
David Marchand

Re: [dpdk-dev] [PATCH] common/cnxk: fix direct rte symbol usage

[Jerin Jacob]

On Wed, Oct 4, 2023 at 11:41 AM David Marchand
 wrote:
>
> Hello Jerin,
>
> On Tue, Oct 3, 2023 at 8:40 PM  wrote:
> >
> > From: Jerin Jacob 
> >
> > The common code is shared between different driver environments,
> > introduce missing plt_ abstractions of missing rte_ symbols and
> > use plt symbols to avoid changing roc_* files.
> >
> > Also update the thread name for outbound soft expiry thread
> > in a7ba40b2b1bf7.
> >
> > Fixes: 3d4e27fd7ff0 ("use abstracted bit count functions")
> > Fixes: a7ba40b2b1bf ("drivers: convert to internal control threads")
> > Fixes: c88d3638c7fc ("common/cnxk: support REE")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Jerin Jacob 
>
> - Could we add something in checkpatch for this driver?

I will add it.

> I was aware of this s/rte_/plt_/ peculiarity but still missed it...
>
> - If you want this backported in LTS, I suggest splitting the fix
> against c88d3638c7fc ("common/cnxk: support REE") and the rest than
> only affects current release.

I will split it the REE change.

>
> - One comment:
>
> > diff --git a/drivers/common/cnxk/roc_nix_inl_dev.c 
> > b/drivers/common/cnxk/roc_nix_inl_dev.c
> > index 6aa191410b..614d0858e5 100644
> > --- a/drivers/common/cnxk/roc_nix_inl_dev.c
> > +++ b/drivers/common/cnxk/roc_nix_inl_dev.c
> > @@ -826,7 +826,7 @@ nix_inl_outb_poll_thread_setup(struct nix_inl_dev 
> > *inl_dev)
> > soft_exp_consumer_cnt = 0;
> > soft_exp_poll_thread_exit = false;
> > rc = plt_thread_create_control(&inl_dev->soft_exp_poll_thread,
> > -   "outb-poll", nix_inl_outb_poll_thread, inl_dev);
> > +   "outb-soft-exp-poll", nix_inl_outb_poll_thread, 
> > inl_dev);
>
> Such a thread name is too long.
> This is reverting Thomas change.
>
> Is this intentional?

Yes, as mentioned in git commit log. Are 19 characters  OK, right? If
not, I will reduce it, "outb-poll" too generic.

 Also update the thread name for outbound soft expiry thread
 in a7ba40b2b1bf7

>
> --
> David Marchand
>