RE: [PATCH] examples/ipsec-secgw: fix zero address in ethernet header

[Akhil Goyal]

> Subject: [PATCH] examples/ipsec-secgw: fix zero address in ethernet header
> 
> During port init, src address stored in ethaddr_tbl is typecast
> which violates the stric-aliasing rule and not reflecting
> the updated source address in processed packets too.
> 
> Fixes: 6eb3ba0399 ("examples/ipsec-secgw: support poll mode NEON LPM
> lookup")
> 
> Signed-off-by: Rahul Bhansali 
Acked-by: Akhil Goyal 

[Bug 1231] l3fwd: perf reports affected by silently enabling "fast free"

[bugzilla]

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

Bug ID: 1231
   Summary: l3fwd: perf reports affected by silently enabling
"fast free"
   Product: DPDK
   Version: unspecified
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: normal
  Priority: Normal
 Component: examples
  Assignee: dev@dpdk.org
  Reporter: m...@smartsharesystems.com
  Target Milestone: ---

The l3fwd example application is used for benchmarking, including the official
NIC performance reports published on the DPDK web site [1].

A patch to silently enable the "fast free" (RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE)
optimization was applied to l3fwd [2][3] in January 2018.

This means that the performance reports starting from DPDK 18.02 do not reflect
generic performance, but the performance of applications that meet the
preconditions for using this optimization feature.

In order to prevent misleading performance results, such non-generic
optimizations should be not be silently enabled; they should be explicitly
enabled using a command line option in l3fwd.

The same applies to the coming "buffer recycle" optimization.

[1]: https://core.dpdk.org/perf-reports/
[2]: http://inbox.dpdk.org/dev/cover.1514280003.git.shah...@mellanox.com/
[3]:
http://git.dpdk.org/dpdk/commit/examples/l3fwd/main.c?id=1ef9600b2d20078538ca4082f9a4adf2d9bd2ab2

PS: I don't oppose to NIC vendors publishing performance results using
non-generic optimizations such as "fast free" or the coming "buffer recycle",
but it should be fully disclosed which optimizations have been used to achieve
better results.

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

Re: 21.11.4 patches review and test

[Kevin Traynor]

On 11/05/2023 08:33, Jiang, YuX wrote:

-Original Message-
From: Kevin Traynor 
Sent: Monday, May 8, 2023 11:24 PM
To: Xu, HailinX ; sta...@dpdk.org
Cc: Stokes, Ian ; Mcnamara, John
; Luca Boccassi ; Xu, Qian Q
; Thomas Monjalon ; Peng,
Yuan ; Chen, Zhaoyan ;
dev@dpdk.org
Subject: Re: 21.11.4 patches review and test

On 05/05/2023 02:42, Xu, HailinX wrote:

-Original Message-
From: Kevin Traynor 
Sent: Thursday, May 4, 2023 6:11 PM
To: Xu, HailinX ; sta...@dpdk.org
Cc: Stokes, Ian ; Mcnamara, John
; Luca Boccassi ; Xu,

Qian

Q ; Thomas Monjalon ;

Peng,

Yuan ; Chen, Zhaoyan

;

dev@dpdk.org
Subject: Re: 21.11.4 patches review and test

On 04/05/2023 03:13, Xu, HailinX wrote:

-Original Message-
From: Kevin Traynor 
Sent: Tuesday, May 2, 2023 5:35 PM
To: Xu, HailinX ; sta...@dpdk.org
Cc: Stokes, Ian ; Mcnamara, John
; Luca Boccassi ; Xu,
Qian Q ; Thomas Monjalon
;

Peng,

Yuan ; Chen, Zhaoyan

;

dev@dpdk.org
Subject: Re: 21.11.4 patches review and test

On 20/04/2023 11:32, Kevin Traynor wrote:

On 20/04/2023 03:40, Xu, HailinX wrote:

-Original Message-
From: Xu, HailinX 
Sent: Thursday, April 13, 2023 2:13 PM
To: Kevin Traynor ; sta...@dpdk.org
Cc: dev@dpdk.org; Abhishek Marathe

;

Ali Alnubani ; Walker, Benjamin
; David Christensen
; Hemant Agrawal

;

Stokes, Ian ; Jerin Jacob
; Mcnamara, John

;

Ju-Hyoung Lee ; Luca Boccassi
; Pei Zhang ; Xu, Qian

Q

; Raslan Darawsheh ;

Thomas

Monjalon ; yangh...@redhat.com; Peng,

Yuan

; Chen, Zhaoyan



Subject: RE: 21.11.4 patches review and test


-Original Message-
From: Kevin Traynor 
Sent: Thursday, April 6, 2023 7:38 PM
To: sta...@dpdk.org
Cc: dev@dpdk.org; Abhishek Marathe
; Ali Alnubani
; Walker, Benjamin
; David Christensen
; Hemant Agrawal
; Stokes, Ian

;

Jerin Jacob ; Mcnamara, John
; Ju-Hyoung Lee

;

Kevin Traynor ; Luca Boccassi
; Pei Zhang ; Xu,

Qian Q

; Raslan Darawsheh ;

Thomas

Monjalon ; yangh...@redhat.com; Peng,

Yuan

; Chen, Zhaoyan



Subject: 21.11.4 patches review and test

Hi all,

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

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

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

release notes.


A release candidate tarball can be found at:


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

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

Thanks.

Kevin


HI All,

Update the test status for Intel part. Till now dpdk21.11.4-rc1
validation test rate is 85%. No critical issue is found.
2 new bugs are found, 1 new issue is under confirming by Intel Dev.
New bugs:   --20.11.8-rc1 also has these two issues
   1.



pvp_qemu_multi_paths_port_restart:perf_pvp_qemu_vector_rx_mac:

performance drop about 23.5% when send small packets
https://bugs.dpdk.org/show_bug.cgi?id=1212-- no fix yet
   2. some of the virtio tests are failing:-- Intel dev is under

investigating

# Basic Intel(R) NIC testing
* Build & CFLAG compile: cover the build test combination with
latest GCC/Clang version and the popular OS revision such as
   Ubuntu20.04, Ubuntu22.04, Fedora35, Fedora37, RHEL8.6,
RHEL8.4, FreeBSD13.1, SUSE15, CentOS7.9, etc.
- All test done. No new dpdk issue is found.
* PF(i40e, ixgbe): test scenarios including
RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc.
- All test done. No new dpdk issue is found.
* VF(i40e, ixgbe): test scenarios including
VF-RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN,

etc.

- All test done. No new dpdk issue is found.
* PF/VF(ice): test scenarios including Switch features/Package
Management/Flow Director/Advanced Tx/Advanced

RSS/ACL/DCF/Flexible

Descriptor, etc.
- All test done. No new dpdk issue is found.
* Intel NIC single core/NIC performance: test scenarios
including PF/VF single core performance test, etc.
- All test done. No new dpdk issue is found.
* IPsec: test scenarios including ipsec/ipsec-gw/ipsec library
basic test - QAT&SW/FIB library, etc.
- On going.

# Basic cryptodev and virtio testing
* Virtio: both function and performance test are covered. Such
as PVP/Virtio_loopback/virtio-user loopback/virtio-net VM2VM
perf testing/VMAWARE ESXI 8.0, etc.
- All test done. found bug1.
* Cryptodev:
   *Function test: test scenarios including Cryptodev API
testing/CompressDev ISA-L/QAT/ZLIB PMD Testing/FIPS, etc.
 - Execution rate is 90%. found bug2.
   *Performance test: test scenarios including Thoughput
Performance/Cryptodev Latency, etc.
 - All test done. No new dpdk issue is found.

Regards,
Xu, Hailin

Update the test status for Intel part. completed dpdk21.11.4-rc1
all

validation. No critical issue is found.


Hi. Thanks for testing.


2 new bugs are found, 1 new issue is under confirming by Intel Dev.
New bugs: -

Re: [PATCH v2 3/3] vhost: add device op to offload the interrupt kick

[Eelco Chaudron]

On 10 May 2023, at 13:44, David Marchand wrote:

> On Wed, Apr 5, 2023 at 2:42 PM Eelco Chaudron  wrote:
>>
>> This patch adds an operation callback which gets called every time the
>> library wants to call eventfd_write(). This eventfd_write() call could
>> result in a system call, which could potentially block the PMD thread.
>>
>> The callback function can decide whether it's ok to handle the
>> eventfd_write() now or have the newly introduced function,
>> rte_vhost_notify_guest(), called at a later time.
>>
>> This can be used by 3rd party applications, like OVS, to avoid system
>> calls being called as part of the PMD threads.
>>
>> Signed-off-by: Eelco Chaudron 
>> ---
>>  lib/vhost/meson.build |2 +
>>  lib/vhost/rte_vhost.h |   23 +++-
>>  lib/vhost/socket.c|   72 
>> ++---
>>  lib/vhost/version.map |9 ++
>>  lib/vhost/vhost.c |   38 ++
>>  lib/vhost/vhost.h |   65 +++-
>>  6 files changed, 184 insertions(+), 25 deletions(-)
>>
>> diff --git a/lib/vhost/meson.build b/lib/vhost/meson.build
>> index 197a51d936..e93ba6b078 100644
>> --- a/lib/vhost/meson.build
>> +++ b/lib/vhost/meson.build
>> @@ -39,3 +39,5 @@ driver_sdk_headers = files(
>>  'vdpa_driver.h',
>>  )
>>  deps += ['ethdev', 'cryptodev', 'hash', 'pci', 'dmadev']
>> +
>> +use_function_versioning = true
>> diff --git a/lib/vhost/rte_vhost.h b/lib/vhost/rte_vhost.h
>> index 58a5d4be92..7a10bc36cf 100644
>> --- a/lib/vhost/rte_vhost.h
>> +++ b/lib/vhost/rte_vhost.h
>> @@ -298,7 +298,13 @@ struct rte_vhost_device_ops {
>>  */
>> void (*guest_notified)(int vid);
>>
>> -   void *reserved[1]; /**< Reserved for future extension */
>> +   /**
>> +* If this callback is registered, notification to the guest can
>> +* be handled by the front-end calling rte_vhost_notify_guest().
>> +* If it's not handled, 'false' should be returned. This can be used
>> +* to remove the "slow" eventfd_write() syscall from the datapath.
>> +*/
>> +   bool (*guest_notify)(int vid, uint16_t queue_id);
>>  };
>>
>>  /**
>> @@ -433,6 +439,21 @@ void rte_vhost_log_used_vring(int vid, uint16_t 
>> vring_idx,
>>
>>  int rte_vhost_enable_guest_notification(int vid, uint16_t queue_id, int 
>> enable);
>>
>> +/**
>> + * @warning
>> + * @b EXPERIMENTAL: this API may change, or be removed, without prior 
>> notice.
>> + *
>> + * Inject the offloaded interrupt into the vhost device's queue. For more
>> + * details see the 'guest_notify' vhost device operation.
>> + *
>> + * @param vid
>> + *  vhost device ID
>> + * @param queue_id
>> + *  virtio queue index
>> + */
>> +__rte_experimental
>> +void rte_vhost_notify_guest(int vid, uint16_t queue_id);
>> +
>>  /**
>>   * Register vhost driver. path could be different for multiple
>>   * instance support.
>> diff --git a/lib/vhost/socket.c b/lib/vhost/socket.c
>> index 669c322e12..787d6bacf8 100644
>> --- a/lib/vhost/socket.c
>> +++ b/lib/vhost/socket.c
>> @@ -15,6 +15,7 @@
>>  #include 
>>  #include 
>>
>> +#include 
>>  #include 
>>
>>  #include "fd_man.h"
>> @@ -43,6 +44,7 @@ struct vhost_user_socket {
>> bool async_copy;
>> bool net_compliant_ol_flags;
>> bool stats_enabled;
>> +   bool alloc_notify_ops;
>>
>> /*
>>  * The "supported_features" indicates the feature bits the
>> @@ -846,6 +848,14 @@ vhost_user_socket_mem_free(struct vhost_user_socket 
>> *vsocket)
>> vsocket->path = NULL;
>> }
>>
>> +   if (vsocket && vsocket->alloc_notify_ops) {
>> +#pragma GCC diagnostic push
>> +#pragma GCC diagnostic ignored "-Wcast-qual"
>> +   free((struct rte_vhost_device_ops *)vsocket->notify_ops);
>> +#pragma GCC diagnostic pop
>> +   vsocket->notify_ops = NULL;
>> +   }
>
> Rather than select the behavior based on a boolean (and here force the
> compiler to close its eyes), I would instead add a non const pointer
> to ops (let's say alloc_notify_ops) in vhost_user_socket.
> The code can then unconditionnally call free(vsocket->alloc_notify_ops);

Good idea, I will make the change in v3.

>> +
>> if (vsocket) {
>> free(vsocket);
>> vsocket = NULL;
>> @@ -1099,21 +1109,75 @@ rte_vhost_driver_unregister(const char *path)
>>  /*
>>   * Register ops so that we can add/remove device to data core.
>>   */
>> -int
>> -rte_vhost_driver_callback_register(const char *path,
>> -   struct rte_vhost_device_ops const * const ops)
>> +static int
>> +rte_vhost_driver_callback_register__(const char *path,
>
> No need for a rte_ prefix on static symbol.
> And we can simply call this internal helper vhost_driver_callback_register().

ACK.

>> +   struct rte_vhost_device_ops const * const ops, bool ops_allocated)
>>  {
>> struct vhost_user_socket *vsocket;
>>
>> pthread_mutex_lock(&vh

[PATCH 1/3] lib: add IPv6 lookup node

[Amit Prakash Shukla]

From: Sunil Kumar Kori 

Similar to IPv4 lookup node, patch adds IPv6 lookup
node.

Signed-off-by: Sunil Kumar Kori 
---
 doc/guides/prog_guide/graph_lib.rst |  13 ++
 lib/node/ip6_lookup.c   | 225 
 lib/node/meson.build|   3 +-
 lib/node/node_private.h |   3 +-
 lib/node/pkt_cls.c  |  14 ++
 lib/node/pkt_cls_priv.h |   1 +
 lib/node/rte_node_ip6_api.h |  80 ++
 lib/node/version.map|   2 +
 8 files changed, 339 insertions(+), 2 deletions(-)
 create mode 100644 lib/node/ip6_lookup.c
 create mode 100644 lib/node/rte_node_ip6_api.h

diff --git a/doc/guides/prog_guide/graph_lib.rst 
b/doc/guides/prog_guide/graph_lib.rst
index 1cfdc86433..1f70d63628 100644
--- a/doc/guides/prog_guide/graph_lib.rst
+++ b/doc/guides/prog_guide/graph_lib.rst
@@ -388,6 +388,19 @@ to determine the L2 header to be written to the packet 
before sending
 the packet out to a particular ethdev_tx node.
 ``rte_node_ip4_rewrite_add()`` is control path API to add next-hop info.
 
+ip6_lookup
+~~
+This node is an intermediate node that does LPM lookup for the received
+ipv6 packets and the result determines each packets next node.
+
+On successful LPM lookup, the result contains the ``next_node`` id and
+``next-hop`` id with which the packet needs to be further processed.
+
+On LPM lookup failure, objects are redirected to pkt_drop node.
+``rte_node_ip6_route_add()`` is control path API to add ipv6 routes.
+To achieve home run, node use ``rte_node_stream_move()`` as mentioned in above
+sections.
+
 null
 
 This node ignores the set of objects passed to it and reports that all are
diff --git a/lib/node/ip6_lookup.c b/lib/node/ip6_lookup.c
new file mode 100644
index 00..94a9c404b4
--- /dev/null
+++ b/lib/node/ip6_lookup.c
@@ -0,0 +1,225 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2023 Marvell.
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "rte_node_ip6_api.h"
+
+#include "node_private.h"
+
+#define IPV6_L3FWD_LPM_MAX_RULES 1024
+#define IPV6_L3FWD_LPM_NUMBER_TBL8S (1 << 8)
+
+/* IP6 Lookup global data struct */
+struct ip6_lookup_node_main {
+   struct rte_lpm6 *lpm_tbl[RTE_MAX_NUMA_NODES];
+};
+
+struct ip6_lookup_node_ctx {
+   /* Socket's LPM table */
+   struct rte_lpm6 *lpm6;
+   /* Dynamic offset to mbuf priv1 */
+   int mbuf_priv1_off;
+};
+
+int ip6_node_mbuf_priv1_dynfield_offset = -1;
+
+static struct ip6_lookup_node_main ip6_lookup_nm;
+
+#define IP6_LOOKUP_NODE_LPM(ctx) \
+   (((struct ip6_lookup_node_ctx *)ctx)->lpm6)
+
+#define IP6_LOOKUP_NODE_PRIV1_OFF(ctx) \
+   (((struct ip6_lookup_node_ctx *)ctx)->mbuf_priv1_off)
+
+static uint16_t
+ip6_lookup_node_process_scalar(struct rte_graph *graph, struct rte_node *node,
+   void **objs, uint16_t nb_objs)
+{
+   struct rte_lpm6 *lpm6 = IP6_LOOKUP_NODE_LPM(node->ctx);
+   const int dyn = IP6_LOOKUP_NODE_PRIV1_OFF(node->ctx);
+   struct rte_ipv6_hdr *ipv6_hdr;
+   void **to_next, **from;
+   uint16_t last_spec = 0;
+   struct rte_mbuf *mbuf;
+   rte_edge_t next_index;
+   uint16_t held = 0;
+   uint32_t drop_nh;
+   int i, rc;
+
+   /* Speculative next */
+   next_index = RTE_NODE_IP6_LOOKUP_NEXT_REWRITE;
+   /* Drop node */
+   drop_nh = ((uint32_t)RTE_NODE_IP6_LOOKUP_NEXT_PKT_DROP) << 16;
+   from = objs;
+
+   /* Get stream for the speculated next node */
+   to_next = rte_node_next_stream_get(graph, node, next_index, nb_objs);
+   for (i = 0; i < nb_objs; i++) {
+   uint32_t next_hop;
+   uint16_t next;
+
+   mbuf = (struct rte_mbuf *)objs[i];
+
+   /* Extract DIP of mbuf0 */
+   ipv6_hdr = rte_pktmbuf_mtod_offset(mbuf, struct rte_ipv6_hdr *,
+   sizeof(struct rte_ether_hdr));
+   /* Extract hop_limits as ipv6 hdr is in cache */
+   node_mbuf_priv1(mbuf, dyn)->ttl = ipv6_hdr->hop_limits;
+
+   rc = rte_lpm6_lookup(lpm6, ipv6_hdr->dst_addr, &next_hop);
+   next_hop = (rc == 0) ? next_hop : drop_nh;
+
+   node_mbuf_priv1(mbuf, dyn)->nh = (uint16_t)next_hop;
+   next_hop = next_hop >> 16;
+   next = (uint16_t)next_hop;
+
+   if (unlikely(next_index != next)) {
+   /* Copy things successfully speculated till now */
+   rte_memcpy(to_next, from, last_spec * sizeof(from[0]));
+   from += last_spec;
+   to_next += last_spec;
+   held += last_spec;
+   last_spec = 0;
+
+   rte_node_enqueue_x1(graph, node, next, from[0]);
+   from += 1;
+   } else {
+   last_spec += 1;
+

[PATCH 2/3] lib: add IPv6 rewrite node

[Amit Prakash Shukla]

Similar to IPv4 rewrite node, patch adds IPv6 rewrite node.

Signed-off-by: Amit Prakash Shukla 
---
 doc/guides/prog_guide/graph_lib.rst |   8 +
 lib/node/ethdev_ctrl.c  |  13 ++
 lib/node/ip6_rewrite.c  | 331 
 lib/node/ip6_rewrite_priv.h |  69 ++
 lib/node/meson.build|   1 +
 5 files changed, 422 insertions(+)
 create mode 100644 lib/node/ip6_rewrite.c
 create mode 100644 lib/node/ip6_rewrite_priv.h

diff --git a/doc/guides/prog_guide/graph_lib.rst 
b/doc/guides/prog_guide/graph_lib.rst
index 1f70d63628..841cabe259 100644
--- a/doc/guides/prog_guide/graph_lib.rst
+++ b/doc/guides/prog_guide/graph_lib.rst
@@ -401,6 +401,14 @@ On LPM lookup failure, objects are redirected to pkt_drop 
node.
 To achieve home run, node use ``rte_node_stream_move()`` as mentioned in above
 sections.
 
+ip6_rewrite
+~~~
+This node gets packets from ``ip6_lookup`` node with next-hop id for each
+packet is embedded in ``node_mbuf_priv1(mbuf)->nh``. This id is used
+to determine the L2 header to be written to the packet before sending
+the packet out to a particular ethdev_tx node.
+``rte_node_ip6_rewrite_add()`` is control path API to add next-hop info.
+
 null
 
 This node ignores the set of objects passed to it and reports that all are
diff --git a/lib/node/ethdev_ctrl.c b/lib/node/ethdev_ctrl.c
index 37df0431b8..ea7dc8210b 100644
--- a/lib/node/ethdev_ctrl.c
+++ b/lib/node/ethdev_ctrl.c
@@ -12,6 +12,7 @@
 #include "ethdev_rx_priv.h"
 #include "ethdev_tx_priv.h"
 #include "ip4_rewrite_priv.h"
+#include "ip6_rewrite_priv.h"
 #include "node_private.h"
 
 static struct ethdev_ctrl {
@@ -23,6 +24,7 @@ rte_node_eth_config(struct rte_node_ethdev_config *conf, 
uint16_t nb_confs,
uint16_t nb_graphs)
 {
struct rte_node_register *ip4_rewrite_node;
+   struct rte_node_register *ip6_rewrite_node;
struct ethdev_tx_node_main *tx_node_data;
uint16_t tx_q_used, rx_q_used, port_id;
struct rte_node_register *tx_node;
@@ -33,6 +35,7 @@ rte_node_eth_config(struct rte_node_ethdev_config *conf, 
uint16_t nb_confs,
uint32_t id;
 
ip4_rewrite_node = ip4_rewrite_node_get();
+   ip6_rewrite_node = ip6_rewrite_node_get();
tx_node_data = ethdev_tx_node_data_get();
tx_node = ethdev_tx_node_get();
for (i = 0; i < nb_confs; i++) {
@@ -110,6 +113,16 @@ rte_node_eth_config(struct rte_node_ethdev_config *conf, 
uint16_t nb_confs,
port_id, rte_node_edge_count(ip4_rewrite_node->id) - 1);
if (rc < 0)
return rc;
+
+   /* Add this tx port node as next to ip6_rewrite_node */
+   rte_node_edge_update(ip6_rewrite_node->id, RTE_EDGE_ID_INVALID,
+&next_nodes, 1);
+   /* Assuming edge id is the last one alloc'ed */
+   rc = ip6_rewrite_set_next(
+   port_id, rte_node_edge_count(ip6_rewrite_node->id) - 1);
+   if (rc < 0)
+   return rc;
+
}
 
ctrl.nb_graphs = nb_graphs;
diff --git a/lib/node/ip6_rewrite.c b/lib/node/ip6_rewrite.c
new file mode 100644
index 00..0e9631c86f
--- /dev/null
+++ b/lib/node/ip6_rewrite.c
@@ -0,0 +1,331 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2023 Marvell.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "rte_node_ip6_api.h"
+
+#include "ip6_rewrite_priv.h"
+#include "node_private.h"
+
+struct ip6_rewrite_node_ctx {
+   /* Dynamic offset to mbuf priv1 */
+   int mbuf_priv1_off;
+   /* Cached next index */
+   uint16_t next_index;
+};
+
+static struct ip6_rewrite_node_main *ip6_rewrite_nm;
+
+#define IP6_REWRITE_NODE_LAST_NEXT(ctx) \
+   (((struct ip6_rewrite_node_ctx *)ctx)->next_index)
+
+#define IP6_REWRITE_NODE_PRIV1_OFF(ctx) \
+   (((struct ip6_rewrite_node_ctx *)ctx)->mbuf_priv1_off)
+
+static uint16_t
+ip6_rewrite_node_process(struct rte_graph *graph, struct rte_node *node,
+void **objs, uint16_t nb_objs)
+{
+   struct rte_mbuf *mbuf0, *mbuf1, *mbuf2, *mbuf3, **pkts;
+   struct ip6_rewrite_nh_header *nh = ip6_rewrite_nm->nh;
+   const int dyn = IP6_REWRITE_NODE_PRIV1_OFF(node->ctx);
+   uint16_t next0, next1, next2, next3, next_index;
+   uint16_t n_left_from, held = 0, last_spec = 0;
+   struct rte_ipv6_hdr *ip0, *ip1, *ip2, *ip3;
+   void *d0, *d1, *d2, *d3;
+   void **to_next, **from;
+   rte_xmm_t priv01;
+   rte_xmm_t priv23;
+   int i;
+
+   /* Speculative next as last next */
+   next_index = IP6_REWRITE_NODE_LAST_NEXT(node->ctx);
+   rte_prefetch0(nh);
+
+   pkts = (struct rte_mbuf **)objs;
+   from = objs;
+   n_left_from = nb_objs;
+
+   for (i = 0; i < 4 && i < n_left_from; i++)
+   rte_prefetch0(pkts[i]);
+
+   /* Get 

[PATCH 3/3] examples/l3fwd-graph: add IPv6 lookup and rewrite support

[Amit Prakash Shukla]

From: Sunil Kumar Kori 

Similar to ipv4, to support IPv6 lookup and rewrite node
routes and rewrite data needs to be added.

Patch adds routes for ipv6 to validate ip6_lookup node
and  rewrite data to validate ip6_rewrite node.

Signed-off-by: Sunil Kumar Kori 
Signed-off-by: Amit Prakash Shukla 
---
 doc/guides/sample_app_ug/l3_forward_graph.rst | 40 ++
 examples/l3fwd-graph/main.c   | 77 ++-
 2 files changed, 98 insertions(+), 19 deletions(-)

diff --git a/doc/guides/sample_app_ug/l3_forward_graph.rst 
b/doc/guides/sample_app_ug/l3_forward_graph.rst
index 585ac8c898..23f86e4785 100644
--- a/doc/guides/sample_app_ug/l3_forward_graph.rst
+++ b/doc/guides/sample_app_ug/l3_forward_graph.rst
@@ -12,7 +12,8 @@ Overview
 
 
 The application demonstrates the use of the graph framework and graph nodes
-``ethdev_rx``, ``ip4_lookup``, ``ip4_rewrite``, ``ethdev_tx`` and ``pkt_drop`` 
in DPDK to
+``ethdev_rx``, ``pkt_cls``, ``ip4_lookup``/``ip6_lookup``,
+``ip4_rewrite``/``ip6_rewrite``, ``ethdev_tx`` and ``pkt_drop`` in DPDK to
 implement packet forwarding.
 
 The initialization is very similar to those of the :doc:`l3_forward`.
@@ -24,13 +25,15 @@ TTL update and finally Tx is implemented inside graph 
nodes. These nodes are
 interconnected in graph framework. Application main loop needs to walk over
 graph using ``rte_graph_walk()`` with graph objects created one per worker 
lcore.
 
-The lookup method is as per implementation of ``ip4_lookup`` graph node.
+The lookup method is as per implementation of ``ip4_lookup``/``ip6_lookup`` 
graph node.
 The ID of the output interface for the input packet is the next hop returned by
 the LPM lookup. The set of LPM rules used by the application is statically
-configured and provided to ``ip4_lookup`` graph node and ``ip4_rewrite`` graph 
node
-using node control API ``rte_node_ip4_route_add()`` and 
``rte_node_ip4_rewrite_add()``.
+configured and provided to ``ip4_lookup``/``ip6_lookup`` graph node and
+``ip4_rewrite``/``ip6_rewrite`` graph node using node control API
+``rte_node_ip4_route_add()``/``rte_node_ip6_route_add`` and
+``rte_node_ip4_rewrite_add()``/``rte_node_ip6_rewrite_add``.
 
-In the sample application, only IPv4 forwarding is supported as of now.
+In the sample application, IPv4 and IPv6 forwarding is supported.
 
 Compiling the Application
 -
@@ -149,8 +152,8 @@ lead to the clone of ``ethdev_rx`` and ``ethdev_tx`` nodes 
as ``ethdev_rx-X-Y``
 In case of ``ethdev_tx-X`` nodes, tx queue id assigned per instance of the node
 is same as graph id.
 
-These cloned nodes along with existing static nodes such as ``ip4_lookup`` and
-``ip4_rewrite`` will be used in graph creation to associate node's to lcore
+These cloned nodes along with existing static nodes such as 
``ip4_lookup``/``ip6_lookup``
+and ``ip4_rewrite``/``ip6_rewrite`` will be used in graph creation to 
associate node's to lcore
 specific graph object.
 
 .. literalinclude:: ../../../examples/l3fwd-graph/main.c
@@ -186,20 +189,21 @@ Forwarding data(Route, Next-Hop) addition
 ~
 
 Once graph objects are created, node specific info like routes and rewrite
-headers will be provided run-time using ``rte_node_ip4_route_add()`` and
-``rte_node_ip4_rewrite_add()`` API.
+headers will be provided run-time using ``rte_node_ip4_route_add()``/
+``rte_node_ip6_route_add`` and 
``rte_node_ip4_rewrite_add()``/``rte_node_ip6_rewrite_add``
+API.
 
 .. note::
 
-Since currently ``ip4_lookup`` and ``ip4_rewrite`` nodes don't support
-lock-less mechanisms(RCU, etc) to add run-time forwarding data like route 
and
-rewrite data, forwarding data is added before packet processing loop is
-launched on worker lcore.
+Since currently ``ip4_lookup``/``ip6_lookup`` and 
``ip4_rewrite``/``ip6_rewrite``
+nodes don't support lock-less mechanisms(RCU, etc) to add run-time 
forwarding
+data like route and rewrite data, forwarding data is added before packet
+processing loop is launched on worker lcore.
 
 .. literalinclude:: ../../../examples/l3fwd-graph/main.c
 :language: c
-:start-after: Add route to ip4 graph infra. 8<
-:end-before: >8 End of adding route to ip4 graph infa.
+:start-after: Add routes and rewrite data to graph infra. 8<
+:end-before: >8 End of adding routes and rewrite data to graph infa.
 :dedent: 1
 
 Packet Forwarding using Graph Walk
@@ -215,8 +219,10 @@ specific graph object that was already created.
 
 rte_graph_walk() will walk over all the sources nodes i.e ``ethdev_rx-X-Y``
 associated with a given graph and Rx the available packets and enqueue them
-to the following node ``ip4_lookup`` which then will enqueue them to 
``ip4_rewrite``
-node if LPM lookup succeeds. ``ip4_rewrite`` node then will update 
Ethernet header
+to the following node ``pkt_cls`` which based on the packet type will 
enqueue
+them to ``ip4_lookup``

Re: [PATCH v2] gro : ipv6 changes to support GRO for TCP/ipv6

[kumaraparameshwaran rathinavel]

On Fri, May 12, 2023 at 8:17 AM Hu, Jiayu  wrote:

> Hi Kumar,
>
> For TCP/IPv4 and TCP/IPv6, the TCP layer is the same and the difference is
> the IP layer. So the code used for TCP layer needs to be shared among
> gro_tcp6.c
> and gro_tcp4.c. But there are  too much code duplication in gro_tcp4.c and
> gro_tcp6.c
> in current implementation.
>


> Sure, will do it. I had followed the same that was similar to what was
>> done in gro_tcp4.c and gro_vxlan_tcp4.c. Eventhough the TCP could have been
>> reused for vxlan, we had code duplication. I assumed that this was better
>> in terms of performance etc.
>
>

> For example, struct tcp6_flow_key and struct tcp4_flow_key share most of
> fields, except
> the IP address type. It's better to have a common TCP flow key structure
> in gro_tcp.h. In
> gro_tcp4.h and gro_tcp6.h, we implement tcp4 and tcp6 flow key structures
> with using the
> common structure.
>
Thanks,
> Jiayu
>
> > -Original Message-
> > From: Kumara Parameshwaran 
> > Sent: Friday, October 21, 2022 2:14 AM
> > To: Hu, Jiayu 
> > Cc: dev@dpdk.org; Kumara Parameshwaran
> > 
> > Subject: [PATCH v2] gro : ipv6 changes to support GRO for TCP/ipv6
> >
> > From: Kumara Parameshwaran 
> >
> > The patch adds GRO support for TCP/ipv6 packets. This does not include
> the
> > support for vxlan, udp ipv6 packets.
> >
> > Signed-off-by: Kumara Parameshwaran 
> > ---
> > v1:
> >   * Changes to support GRO for TCP/ipv6 packets. This does not
> > include
> > vxlan changes.
> >   * The GRO is performed only for ipv6 packets that does not contain
> >extension headers.
> >   * The logic for the TCP coalescing remains the same, in ipv6 header
> > the source address, destination address, flow label, version
> fields
> > are expected to be the same.
> >   * Re-organised the code to reuse certain tcp functions for both
> ipv4
> > and
> > ipv6 flows.
> > v2:
> >   * Fix comments in gro_tcp6.h header file.
> >
> >  lib/gro/gro_tcp.h| 155 
> >  lib/gro/gro_tcp4.c   |   7 +-
> >  lib/gro/gro_tcp4.h   | 152 +--
> >  lib/gro/gro_tcp6.c   | 387
> > +++
> >  lib/gro/gro_tcp6.h   | 150 +++
> >  lib/gro/gro_vxlan_tcp4.c |   3 +-
> >  lib/gro/gro_vxlan_tcp4.h |   3 +-
> >  lib/gro/meson.build  |   1 +
> >  lib/gro/rte_gro.c|  83 +++--
> >  lib/gro/rte_gro.h|   3 +
> >  10 files changed, 774 insertions(+), 170 deletions(-)  create mode
> 100644
> > lib/gro/gro_tcp.h  create mode 100644 lib/gro/gro_tcp6.c  create mode
> > 100644 lib/gro/gro_tcp6.h
> >
> > diff --git a/lib/gro/gro_tcp.h b/lib/gro/gro_tcp.h new file mode 100644
> index
> > 00..c5d248a022
> > --- /dev/null
> > +++ b/lib/gro/gro_tcp.h
> > @@ -0,0 +1,155 @@
> > +#ifndef _GRO_TCP_H_
> > +#define _GRO_TCP_H_
> > +
> > +#include 
> > +
> > +/*
> > + * The max length of a IPv4 packet, which includes the length of the L3
> > + * header, the L4 header and the data payload.
> > + */
> > +#define MAX_IP_PKT_LENGTH UINT16_MAX
> > +
> > +/* The maximum TCP header length */
> > +#define MAX_TCP_HLEN 60
> > +#define INVALID_TCP_HDRLEN(len) \
> > + (((len) < sizeof(struct rte_tcp_hdr)) || ((len) > MAX_TCP_HLEN))
> > +
> > +struct gro_tcp_item {
> > + /*
> > +  * The first MBUF segment of the packet. If the value
> > +  * is NULL, it means the item is empty.
> > +  */
> > + struct rte_mbuf *firstseg;
> > + /* The last MBUF segment of the packet */
> > + struct rte_mbuf *lastseg;
> > + /*
> > +  * The time when the first packet is inserted into the table.
> > +  * This value won't be updated, even if the packet is merged
> > +  * with other packets.
> > +  */
> > + uint64_t start_time;
> > + /*
> > +  * next_pkt_idx is used to chain the packets that
> > +  * are in the same flow but can't be merged together
> > +  * (e.g. caused by packet reordering).
> > +  */
> > + uint32_t next_pkt_idx;
> > + /* TCP sequence number of the packet */
> > + uint32_t sent_seq;
> > + /* IPv4 ID of the packet */
> > + uint16_t ip_id;
> > + /* the number of merged packets */
> > + uint16_t nb_merged;
> > + /* Indicate if IPv4 ID can be ignored */
> > + uint8_t is_atomic;
> > +};
> > +
> > +/*
> > + * Merge two TCP packets without updating checksums.
> > + * If cmp is larger than 0, append the new packet to the
> > + * original packet. Otherwise, pre-pend the new packet to
> > + * the original packet.
> > + */
> > +static inline int
> > +merge_two_tcp_packets(struct gro_tcp_item *item,
> > + struct rte_mbuf *pkt,
> > + int cmp,
> > + uint32_t sent_seq,
> > + uint16_t ip_id,
> > + uint16_t l2_offset)
> > +{
> > + struct rte_mbuf *pkt_head, *pkt_tail, *lastseg;
> > + uint16_t hdr_len, l2_len;
> > +
> > + if (cmp > 0) {
> > +   

Re: [PATCH v2] net/tap: resolve stringop-overflow with gcc 12 on ppc64le

[Ferruh Yigit]

On 5/16/2023 2:28 AM, Stephen Hemminger wrote:
> On Tue, 16 May 2023 00:35:56 +0100
> Ferruh Yigit  wrote:
> 
>> Yes only some scripts and possible applications that hotplug tap
>> interface with hardcoded parameters may impacted, don't know how big is
>> this amount but this ends up breaking something that was working before
>> upgrading DPDK for them.
>>
>> And I believe the motivation is weak to break the behavior.
>>
>> Won't it be better to update 'rte_ether_unformat_addr()' to accept more
>> flexible syntax, and use it? Is there any disadvantage of this approach?
> 
> It is already more flexible than the standard ether_aton().

I mean to accept single chars, as 'tap' currently does, like "a:a:a:a:a:a".

Agree that impact of tap change is small, but if we can eliminate it
completely without any side affect, why not?


As accepting single char will be expanding 'rte_ether_unformat_addr()'
capability, it will be backward compatible, am I missing anything?

[Bug 1232] [regex/cn9k] Dependence to rxp-compiler.h is not checked

[bugzilla]

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

Bug ID: 1232
   Summary: [regex/cn9k] Dependence to rxp-compiler.h is not
checked
   Product: DPDK
   Version: 23.03
  Hardware: All
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: Normal
 Component: ethdev
  Assignee: dev@dpdk.org
  Reporter: barbe...@kth.se
  Target Milestone: ---

Hi all,

With Ubuntu 22.04 LTS, meson setup build && ninja && ninja build fails to
compile with :

[317/1318] Compiling C object
drivers/libtmp_rte_regex_cn9k.a.p/regex_cn9k_cn9k_regexdev_compiler.c.o
FAILED: drivers/libtmp_rte_regex_cn9k.a.p/regex_cn9k_cn9k_regexdev_compiler.c.o
cc -Idrivers/libtmp_rte_regex_cn9k.a.p -Idrivers -I../drivers
-Idrivers/regex/cn9k -I../drivers/regex/cn9k -Ilib/ethdev -I../lib/ethdev -I.
-I.. -Iconfig -I../config -Ilib/eal/include -I../lib/eal/include
-Ilib/eal/linux/include -I../lib/eal/linux/include -Ilib/eal/x86/include
-I../lib/eal/x86/include -Ilib/eal/common -I../lib/eal/common -Ilib/eal
-I../lib/eal -Ilib/kvargs -I../lib/kvargs -Ilib/metrics -I../lib/metrics
-Ilib/telemetry -I../lib/telemetry -Ilib/net -I../lib/net -Ilib/mbuf
-I../lib/mbuf -Ilib/mempool -I../lib/mempool -Ilib/ring -I../lib/ring
-Ilib/meter -I../lib/meter -Idrivers/bus/pci -I../drivers/bus/pci
-I../drivers/bus/pci/linux -Ilib/pci -I../lib/pci -Ilib/regexdev
-I../lib/regexdev -Idrivers/common/cnxk -I../drivers/common/cnxk -Ilib/security
-I../lib/security -Ilib/cryptodev -I../lib/cryptodev -Ilib/rcu -I../lib/rcu
-Idrivers/mempool/cnxk -I../drivers/mempool/cnxk -fdiagnostics-color=always
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -O3 -include rte_config.h
-Wcast-qual -Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security
-Wmissing-declarations -Wmissing-prototypes -Wnested-externs
-Wold-style-definition -Wpointer-arith -Wsign-compare -Wstrict-prototypes
-Wundef -Wwrite-strings -Wno-address-of-packed-member -Wno-packed-not-aligned
-Wno-missing-field-initializers -Wno-zero-length-bounds -D_GNU_SOURCE -fPIC
-march=native -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API
-Wno-format-truncation -DREE_COMPILER_SDK
-DRTE_LOG_DEFAULT_LOGTYPE=pmd.regex.cn9k -MD -MQ
drivers/libtmp_rte_regex_cn9k.a.p/regex_cn9k_cn9k_regexdev_compiler.c.o -MF
drivers/libtmp_rte_regex_cn9k.a.p/regex_cn9k_cn9k_regexdev_compiler.c.o.d -o
drivers/libtmp_rte_regex_cn9k.a.p/regex_cn9k_cn9k_regexdev_compiler.c.o -c
../drivers/regex/cn9k/cn9k_regexdev_compiler.c
../drivers/regex/cn9k/cn9k_regexdev_compiler.c:12:10: fatal error:
rxp-compiler.h: No such file or directory
   12 | #include 
  |  ^~~~
compilation terminated.

apt-file does not find any reference to rxp-compiler.h. Not sure what package
is installing that but it should be checked as part of meson setup, I think.


Other leads/env :
- Mellanox Ofed is installed with ./mlnxofedinstall --with-mft --with-mstflint
--dpdk --upstream-libs --with-dkms --with-kernel-mft-dkms --with-bluefield
--with-rshim --with-rshim-net --force
- NVIDIA DOCA might be partially installed
- Dual Intel(R) Xeon(R) Gold 5317 CPU @ 3.00GHz  
- lspci |grep -i eth   
   
 < ~/workspace/dpdk/build [11:59:12]
04:00.0 Ethernet controller: Broadcom Inc. and subsidiaries NetXtreme BCM5720
Gigabit Ethernet PCIe
04:00.1 Ethernet controller: Broadcom Inc. and subsidiaries NetXtreme BCM5720
Gigabit Ethernet PCIe
31:00.0 Ethernet controller: Broadcom Inc. and subsidiaries BCM57414
NetXtreme-E 10Gb/25Gb RDMA Ethernet Controller (rev 01)
31:00.1 Ethernet controller: Broadcom Inc. and subsidiaries BCM57414
NetXtreme-E 10Gb/25Gb RDMA Ethernet Controller (rev 01)
98:00.0 Ethernet controller: Mellanox Technologies MT2892 Family [ConnectX-6
Dx]
98:00.1 Ethernet controller: Mellanox Technologies MT2892 Family [ConnectX-6
Dx]


Thanks !

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

RE: [PATCH] test/crypto: remove redundant code

[Akhil Goyal]

> Subject: [PATCH] test/crypto: remove redundant code
> 
> Code for registering raw API tests for various PMDs are repeated.
> Add common routine to avoid duplication of code.
> 
> Signed-off-by: Anoob Joseph 
> ---
Acked-by: Akhil Goyal 

RE: [PATCH 1/2] test/crypto: free memory in error and skip paths

[Akhil Goyal]

> Subject: [PATCH 1/2] test/crypto: free memory in error and skip paths
> 
> In multi session tests, multiple sessions get created. So the handling
> in ut_teardown won't guard against any memory that is not freed by the
> test case. Test case should free sessions as well as local memory that
> was used to save session pointers both in case of unsupported cases as
> well as operation failures.
> 
> Signed-off-by: Anoob Joseph 
Acked-by: Akhil Goyal 

Thanks for the cleanup

Re: [PATCH v2 3/3] vhost: add device op to offload the interrupt kick

[David Marchand]

On Tue, May 16, 2023 at 10:53 AM Eelco Chaudron  wrote:
> On 10 May 2023, at 13:44, David Marchand wrote:

[snip]

> >> @@ -846,6 +848,14 @@ vhost_user_socket_mem_free(struct vhost_user_socket 
> >> *vsocket)
> >> vsocket->path = NULL;
> >> }
> >>
> >> +   if (vsocket && vsocket->alloc_notify_ops) {
> >> +#pragma GCC diagnostic push
> >> +#pragma GCC diagnostic ignored "-Wcast-qual"
> >> +   free((struct rte_vhost_device_ops *)vsocket->notify_ops);
> >> +#pragma GCC diagnostic pop
> >> +   vsocket->notify_ops = NULL;
> >> +   }
> >
> > Rather than select the behavior based on a boolean (and here force the
> > compiler to close its eyes), I would instead add a non const pointer
> > to ops (let's say alloc_notify_ops) in vhost_user_socket.
> > The code can then unconditionnally call free(vsocket->alloc_notify_ops);
>
> Good idea, I will make the change in v3.

Feel free to use a better name for this field :-).

>
> >> +
> >> if (vsocket) {
> >> free(vsocket);
> >> vsocket = NULL;

[snip]

> >> +   /*
> >> +* Although the ops structure is a const structure, we do need to
> >> +* override the guest_notify operation. This is because with the
> >> +* previous APIs it was "reserved" and if any garbage value was 
> >> passed,
> >> +* it could crash the application.
> >> +*/
> >> +   if (ops && !ops->guest_notify) {
> >
> > Hum, as described in the comment above, I don't think we should look
> > at ops->guest_notify value at all.
> > Checking ops != NULL should be enough.
>
> Not sure I get you here. If the guest_notify passed by the user is NULL, it 
> means the previously ‘reserved[1]’ field is NULL, so we do not need to use a 
> new structure.
>
> I guess your comment would be true if we would introduce a new field in the 
> data structure, not replacing a reserved one.

Hum, I don't understand my comment either o_O'.
Too many days off... or maybe my evil twin took over the keyboard.


>
> >> +   struct rte_vhost_device_ops *new_ops;
> >> +
> >> +   new_ops = malloc(sizeof(*new_ops));
> >
> > Strictly speaking, we lose the numa affinity of "ops" by calling malloc.
> > I am unclear of the impact though.
>
> Don’t think there is a portable API that we can use to determine the NUMA for 
> the ops memory and then allocate this on the same numa?
>
> Any thoughts or ideas on how to solve this? I hope most people will memset() 
> the ops structure and the reserved[1] part is zero, but it might be a problem 
> in the future if more extensions get added.

Determinining current numa is doable, via 'ops'
get_mempolicy(MPOL_F_NODE | MPOL_F_ADDR), like what is done for vq in
numa_realloc().
The problem is how to allocate on this numa with the libc allocator
for which I have no idea...
We could go with the dpdk allocator (again, like numa_realloc()).


In practice, the passed ops will be probably from a const variable in
the program .data section (for which I think fields are set to 0
unless explicitly initialised), or a memset() will be called for a
dynamic allocation from good citizens.
So we can probably live with the current proposal.
Plus, this is only for one release, since in 23.11 with the ABI bump,
we will drop this compat code.

Maxime, Chenbo, what do you think?


[snip]

> >
> > But putting indentation aside, is this change equivalent?
> > -   if ((vhost_need_event(vhost_used_event(vq), new, old) &&
> > -   (vq->callfd >= 0)) ||
> > -   unlikely(!signalled_used_valid)) {
> > +   if ((vhost_need_event(vhost_used_event(vq), new, old) ||
> > +   unlikely(!signalled_used_valid)) &&
> > +   vq->callfd >= 0) {
>
> They are not equal, but in the past eventfd_write() should also not have been 
> called with callfd < 0, guess this was an existing bug ;)

I think this should be a separate fix.

>
> >> +   vhost_vring_inject_irq(dev, vq);


-- 
David Marchand

RE: [PATCH 2/2] test/crypto: handle return code

[Akhil Goyal]

> Subject: [PATCH 2/2] test/crypto: handle return code
> 
> The sub test case, test_snow3g_decryption, may fail for non-critical
> reasons such as lack of support. Handle the return value gracefully to
> allow TEST_SKIPPED return value to be propagated correctly.
> 
> Signed-off-by: Anoob Joseph 
Acked-by: Akhil Goyal 

[PATCH v2] dts: update dependencies and mypy execution

[Juraj Linkeš]

Poetry changed the syntax of dev dependencies section in version
1.2.0. Remove the scripts section that did nothing.
Update Pylama linters:
* pep8 is the same as pycodestyle
* pylint is missing dependencies and thus not executed. It reports a
  number of warnings and may be introduced in a future patch.
* mypy doesn't work properly with Pylama. Pylama executes linting
  file-by-file and mypy works on all files at once.

Mypy has thus been moved outside Pylama and is executed separately.
Added Mypy configuration that allows fine-grained specification of
ignored issues.

Signed-off-by: Juraj Linkeš 
---
 devtools/dts-check-format.sh |  21 ++-
 doc/guides/tools/dts.rst |   1 +
 dts/poetry.lock  | 304 +++
 dts/pyproject.toml   |  26 ++-
 4 files changed, 276 insertions(+), 76 deletions(-)

diff --git a/devtools/dts-check-format.sh b/devtools/dts-check-format.sh
index c9b3702642..3f43e17e88 100755
--- a/devtools/dts-check-format.sh
+++ b/devtools/dts-check-format.sh
@@ -1,6 +1,7 @@
 #!/bin/sh
 # SPDX-License-Identifier: BSD-3-Clause
 # Copyright(c) 2022 University of New Hampshire
+# Copyright(c) 2023 PANTHEON.tech s.r.o.
 
 usage() {
echo "Usage: $(basename $0) [options] [directory]"
@@ -11,9 +12,10 @@ usage() {
 
 format=true
 lint=true
+typecheck=true
 
 # Comments after args serve as documentation; must be present
-while getopts "hfl" arg; do
+while getopts "hflt" arg; do
case $arg in
h) # Display this message
echo 'Run formatting and linting programs for DTS.'
@@ -26,6 +28,9 @@ while getopts "hfl" arg; do
l) # Don't run linter
lint=false
;;
+   t) # Don't run type checker
+   typecheck=false
+   ;;
?)
usage
exit 1
@@ -93,6 +98,20 @@ if $lint; then
fi
 fi
 
+if $typecheck; then
+   if $format || $lint; then
+   echo
+   fi
+   heading "Checking types in $directory/"
+   if command -v mypy > /dev/null; then
+   mypy .
+   errors=$((errors + $?))
+   else
+   echo "mypy not found, unable to check types"
+   errors=$((errors + 1))
+   fi
+fi
+
 echo
 heading "Summary for $directory/"
 echo "Found $errors errors"
diff --git a/doc/guides/tools/dts.rst b/doc/guides/tools/dts.rst
index ebd6dceb6a..c9f7f2027d 100644
--- a/doc/guides/tools/dts.rst
+++ b/doc/guides/tools/dts.rst
@@ -82,6 +82,7 @@ Setting up DTS environment
Another benefit is the usage of ``pyproject.toml``, which has become the 
standard config file
for python projects, improving project organization.
To install Poetry, visit their `doc pages 
`_.
+   The recommended Poetry version is at least 1.4.2.
 
 #. **Getting a Poetry shell**
 
diff --git a/dts/poetry.lock b/dts/poetry.lock
index 0b2a007d4d..64d6c18f35 100644
--- a/dts/poetry.lock
+++ b/dts/poetry.lock
@@ -1,24 +1,45 @@
+# This file is automatically @generated by Poetry and should not be changed by 
hand.
+
 [[package]]
 name = "attrs"
-version = "22.1.0"
+version = "22.2.0"
 description = "Classes Without Boilerplate"
 category = "main"
 optional = false
-python-versions = ">=3.5"
+python-versions = ">=3.6"
+files = [
+{file = "attrs-22.2.0-py3-none-any.whl", hash = 
"sha256:29e95c7f6778868dbd49170f98f8818f78f3dc5e0e37c0b1f474e3561b240836"},
+{file = "attrs-22.2.0.tar.gz", hash = 
"sha256:c9227bfc2f01993c03f68db37d1d15c9690188323c067c641f1a35ca58185f99"},
+]
 
 [package.extras]
-dev = ["coverage[toml] (>=5.0.2)", "hypothesis", "pympler", "pytest 
(>=4.3.0)", "mypy (>=0.900,!=0.940)", "pytest-mypy-plugins", "zope.interface", 
"furo", "sphinx", "sphinx-notfound-page", "pre-commit", "cloudpickle"]
-docs = ["furo", "sphinx", "zope.interface", "sphinx-notfound-page"]
-tests = ["coverage[toml] (>=5.0.2)", "hypothesis", "pympler", "pytest 
(>=4.3.0)", "mypy (>=0.900,!=0.940)", "pytest-mypy-plugins", "zope.interface", 
"cloudpickle"]
-tests_no_zope = ["coverage[toml] (>=5.0.2)", "hypothesis", "pympler", "pytest 
(>=4.3.0)", "mypy (>=0.900,!=0.940)", "pytest-mypy-plugins", "cloudpickle"]
+cov = ["attrs[tests]", "coverage-enable-subprocess", "coverage[toml] (>=5.3)"]
+dev = ["attrs[docs,tests]"]
+docs = ["furo", "myst-parser", "sphinx", "sphinx-notfound-page", 
"sphinxcontrib-towncrier", "towncrier", "zope.interface"]
+tests = ["attrs[tests-no-zope]", "zope.interface"]
+tests-no-zope = ["cloudpickle", "cloudpickle", "hypothesis", "hypothesis", 
"mypy (>=0.971,<0.990)", "mypy (>=0.971,<0.990)", "pympler", "pympler", "pytest 
(>=4.3.0)", "pytest (>=4.3.0)", "pytest-mypy-plugins", "pytest-mypy-plugins", 
"pytest-xdist[psutil]", "pytest-xdist[psutil]"]
 
 [[package]]
 name = "black"
-version = "22.10.0"
+version = "22.12.0"
 description = "The uncompromising code formatter."
 category = "dev"
 optional = false
 python-versions = ">=3.7"
+files = [
+{file = 
"b

RE: [PATCH] test/crypto: fix IPsec AES CCM test vector

[Akhil Goyal]

> Subject: [PATCH] test/crypto: fix IPsec AES CCM test vector
> 
> Fixing IPsec AES-CCM test vector IV length.

Please add appropriate description.

> 
> Fixes: d314299950de ("test/crypto: add AES-CCM vectors")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Tejasree Kondoj 
> ---
>  app/test/test_cryptodev_security_ipsec_test_vectors.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/app/test/test_cryptodev_security_ipsec_test_vectors.h
> b/app/test/test_cryptodev_security_ipsec_test_vectors.h
> index 2686bbeb62..462cef6785 100644
> --- a/app/test/test_cryptodev_security_ipsec_test_vectors.h
> +++ b/app/test/test_cryptodev_security_ipsec_test_vectors.h
> @@ -417,7 +417,7 @@ struct ipsec_test_data pkt_aes_256_ccm = {
>   .op = RTE_CRYPTO_AEAD_OP_ENCRYPT,
>   .algo = RTE_CRYPTO_AEAD_AES_CCM,
>   .key.length = 32,
> - .iv.length = 12,
> + .iv.length = 11,

Add a comment here that IV includes 3 bytes of salt and 8 bytes of IV.

>   .iv.offset = IV_OFFSET,
>   .digest_length = 16,
>   .aad_length = 12,
> --
> 2.25.1

RE: [PATCH 1/2] test/crypto: use separate keys for auth and cipher

[Akhil Goyal]

> Subject: [PATCH 1/2] test/crypto: use separate keys for auth and cipher
> 
> The mixed test cases can have keys with different key lengths. The
> routine which prepares the session parameters uses same key length for
> both cipher & auth keys. Instead allow the caller to use same keys as
> required.
> 
> Signed-off-by: Anoob Joseph 
Acked-by: Akhil Goyal 

RE: [PATCH 2/2] test/crypto: specify correct parameters with null algos

[Akhil Goyal]

> Subject: [PATCH 2/2] test/crypto: specify correct parameters with null algos
> 
> Keys are not required for NULL algorithms. Same way IV, digest lengths
> should also be set to 0. The values are invalid and any PMD which
> validates such parameters would return "-ENOTSUP" for such cases which
> would result in false skipping of tests.
> 
> Signed-off-by: Anoob Joseph 
Acked-by: Akhil Goyal 

[PATCH v3] doc: comment VF does not support multi-process

[Mingjin Ye]

Announcing that multi-process is not supported

Signed-off-by: Mingjin Ye 
---
v2: Modify issue description reason.
---
V3: Modify description.
---
 doc/guides/nics/ixgbe.rst | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/doc/guides/nics/ixgbe.rst b/doc/guides/nics/ixgbe.rst
index b1d77ab7ab..816d614c33 100644
--- a/doc/guides/nics/ixgbe.rst
+++ b/doc/guides/nics/ixgbe.rst
@@ -461,3 +461,9 @@ show bypass config
 Show the bypass configuration for a bypass enabled NIC using the lowest port 
on the NIC::
 
testpmd> show bypass config (port_id)
+
+VF driver does not support multi-process
+
+
+The VF driver does not support multi-process. And some function pointers
+in the case of multi-process are not set correctly.
-- 
2.25.1

RE: [EXT] [PATCH] examples/ipsec-secgw: Update fixed MAC address used by tap driver

[Akhil Goyal]

> Modify LOCAL_MAC value to match new locally administered MAC
> address used by TAP driver.
> 

Shouldn't this be other way round?
PMD should be able to use the MAC given by application.

> Bugzilla ID: 1198
> 
> Signed-off-by: David Christensen 
> ---
>  examples/ipsec-secgw/test/common_defs.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/examples/ipsec-secgw/test/common_defs.sh b/examples/ipsec-
> secgw/test/common_defs.sh
> index 3ef06bc761..6e04ffc1a6 100644
> --- a/examples/ipsec-secgw/test/common_defs.sh
> +++ b/examples/ipsec-secgw/test/common_defs.sh
> @@ -26,7 +26,7 @@ fi
> 
>  LOCAL_IFACE=dtap0
> 
> -LOCAL_MAC="00:64:74:61:70:30"
> +LOCAL_MAC="02:64:74:61:70:30"
> 
>  REMOTE_IPV4=192.168.31.14
>  LOCAL_IPV4=192.168.31.92
> --
> 2.31.1

[PATCH] net/ice: DCF adds default RSS

[Mingjin Ye]

When dcf and iavf ports are used together, the default configuration of
ipv4[6] rss for dcf ports is lost.

This patch adds RSS configuration to the dcf port. Any kernel PF-enabled
default RSS will be disabled at initialization.

In addition, the default RSS will be configured based on
rte_eth_rss_conf->rss_hf. Currently supported default rss_type:
ipv4[6], ipv4[6]_udp, ipv4[6]_tcp, ipv4[6]_sctp.

Fixes: 79b1f7ab462d ("net/ice: support RSS RETA configuration in DCF mode")
Fixes: 7564d5509611 ("net/ice: add DCF hardware initialization")
Fixes: 3a6bfc37eaf4 ("net/ice: support QoS config VF bandwidth in DCF")
Fixes: 3220d865382c ("net/ice: init RSS during DCF start")
Cc: sta...@dpdk.org

Signed-off-by: Mingjin Ye 
---
 drivers/net/ice/ice_dcf.c| 259 ++-
 drivers/net/ice/ice_dcf.h|   4 +
 drivers/net/ice/ice_dcf_ethdev.c |  24 ++-
 3 files changed, 285 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ice/ice_dcf.c b/drivers/net/ice/ice_dcf.c
index 1c3d22ae0f..4575d831e1 100644
--- a/drivers/net/ice/ice_dcf.c
+++ b/drivers/net/ice/ice_dcf.c
@@ -36,6 +36,130 @@
(sizeof(struct virtchnl_vf_resource) +  \
IAVF_MAX_VF_VSI * sizeof(struct virtchnl_vsi_resource))
 
+#define FIELD_SELECTOR(proto_hdr_field) \
+   (1UL << ((proto_hdr_field) & PROTO_HDR_FIELD_MASK))
+#define BUFF_NOUSED0
+
+#define proto_hdr_eth { \
+   VIRTCHNL_PROTO_HDR_ETH, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_ETH_SRC) | \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_ETH_DST), {BUFF_NOUSED} }
+
+#define proto_hdr_svlan { \
+   VIRTCHNL_PROTO_HDR_S_VLAN, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_S_VLAN_ID), {BUFF_NOUSED} }
+
+#define proto_hdr_cvlan { \
+   VIRTCHNL_PROTO_HDR_C_VLAN, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_C_VLAN_ID), {BUFF_NOUSED} }
+
+#define proto_hdr_ipv4 { \
+   VIRTCHNL_PROTO_HDR_IPV4, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV4_SRC) | \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV4_DST), {BUFF_NOUSED} }
+
+#define proto_hdr_ipv4_with_prot { \
+   VIRTCHNL_PROTO_HDR_IPV4, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV4_SRC) | \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV4_DST) | \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV4_PROT), {BUFF_NOUSED} }
+
+#define proto_hdr_ipv6 { \
+   VIRTCHNL_PROTO_HDR_IPV6, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV6_SRC) | \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV6_DST), {BUFF_NOUSED} }
+
+#define proto_hdr_ipv6_frag { \
+   VIRTCHNL_PROTO_HDR_IPV6_EH_FRAG, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV6_EH_FRAG_PKID), {BUFF_NOUSED} }
+
+#define proto_hdr_ipv6_with_prot { \
+   VIRTCHNL_PROTO_HDR_IPV6, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV6_SRC) | \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV6_DST) | \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV6_PROT), {BUFF_NOUSED} }
+
+#define proto_hdr_udp { \
+   VIRTCHNL_PROTO_HDR_UDP, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_UDP_SRC_PORT) | \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_UDP_DST_PORT), {BUFF_NOUSED} }
+
+#define proto_hdr_tcp { \
+   VIRTCHNL_PROTO_HDR_TCP, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_TCP_SRC_PORT) | \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_TCP_DST_PORT), {BUFF_NOUSED} }
+
+#define proto_hdr_sctp { \
+   VIRTCHNL_PROTO_HDR_SCTP, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_SCTP_SRC_PORT) | \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_SCTP_DST_PORT), {BUFF_NOUSED} }
+
+#define proto_hdr_esp { \
+   VIRTCHNL_PROTO_HDR_ESP, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_ESP_SPI), {BUFF_NOUSED} }
+
+#define proto_hdr_ah { \
+   VIRTCHNL_PROTO_HDR_AH, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_AH_SPI), {BUFF_NOUSED} }
+
+#define proto_hdr_l2tpv3 { \
+   VIRTCHNL_PROTO_HDR_L2TPV3, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_L2TPV3_SESS_ID), {BUFF_NOUSED} }
+
+#define proto_hdr_pfcp { \
+   VIRTCHNL_PROTO_HDR_PFCP, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_PFCP_SEID), {BUFF_NOUSED} }
+
+#define proto_hdr_gtpc { \
+   VIRTCHNL_PROTO_HDR_GTPC, 0, {BUFF_NOUSED} }
+
+#define proto_hdr_ecpri { \
+   VIRTCHNL_PROTO_HDR_ECPRI, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_ECPRI_PC_RTC_ID), {BUFF_NOUSED} }
+
+#define proto_hdr_l2tpv2 { \
+   VIRTCHNL_PROTO_HDR_L2TPV2, \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_L2TPV2_SESS_ID) | \
+   FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_L2TPV2_LEN_SESS_ID), {BUFF_NOUSED} }
+
+#define proto_hdr_ppp { \
+   VIRTCHNL_PROTO_HDR_PPP, 0, {BUFF_NOUSED} }
+
+#define TUNNEL_LEVEL_OUTER 0
+#define TUNNEL_LEVEL_INNER 1
+
+struct virtchnl_proto_hdrs ice_dcf_inner_ipv4_tmplt = {
+   TUNNEL_LEVEL_INNER, 1, {{proto_hdr_ipv4}}
+};
+
+struct virtchnl_proto_hdrs ice_dcf_inner_ipv4_udp_tmplt = {
+   TUNNEL_LEVEL_INNER, 2, {{proto_hdr_ipv4_with_prot, proto_hdr_udp}}
+};
+
+struct virtchnl_proto_hdrs ice_dcf_inner_ipv4_tcp_tmplt = {
+   TUNNEL_LEVEL_INNER, 2, {{proto

Re: [PATCH v2] dts: update dependencies and mypy execution

[Juraj Linkeš]

On Tue, May 16, 2023 at 12:16 PM Juraj Linkeš
 wrote:
>
> Poetry changed the syntax of dev dependencies section in version
> 1.2.0. Remove the scripts section that did nothing.
> Update Pylama linters:
> * pep8 is the same as pycodestyle
> * pylint is missing dependencies and thus not executed. It reports a
>   number of warnings and may be introduced in a future patch.
> * mypy doesn't work properly with Pylama. Pylama executes linting
>   file-by-file and mypy works on all files at once.
>
> Mypy has thus been moved outside Pylama and is executed separately.
> Added Mypy configuration that allows fine-grained specification of
> ignored issues.
>
> Signed-off-by: Juraj Linkeš 
> ---
>  devtools/dts-check-format.sh |  21 ++-
>  doc/guides/tools/dts.rst |   1 +
>  dts/poetry.lock  | 304 +++
>  dts/pyproject.toml   |  26 ++-
>  4 files changed, 276 insertions(+), 76 deletions(-)
>
>
> diff --git a/dts/poetry.lock b/dts/poetry.lock
> index 0b2a007d4d..64d6c18f35 100644
> --- a/dts/poetry.lock
> +++ b/dts/poetry.lock
> @@ -1,24 +1,45 @@
> +# This file is automatically @generated by Poetry and should not be changed 
> by hand.
> +

Let's continue the discussion about the generated file we started
here: 
http://patches.dpdk.org/project/dpdk/patch/20230403114608.1423020-1-juraj.lin...@pantheon.tech/



>  [[package]]
>  name = "mypy"
> @@ -116,6 +165,31 @@ description = "Optional static typing for Python"
>  category = "dev"
>  optional = false
>  python-versions = ">=3.6"
> +files = [
> +{file = "mypy-0.961-cp310-cp310-macosx_10_9_universal2.whl", hash = 
> "sha256:697540876638ce349b01b6786bc6094ccdaba88af446a9abb967293ce6eaa2b0"},
> +{file = "mypy-0.961-cp310-cp310-macosx_10_9_x86_64.whl", hash = 
> "sha256:b117650592e1782819829605a193360a08aa99f1fc23d1d71e1a75a142dc7e15"},
> +{file = "mypy-0.961-cp310-cp310-macosx_11_0_arm64.whl", hash = 
> "sha256:bdd5ca340beffb8c44cb9dc26697628d1b88c6bddf5c2f6eb308c46f269bb6f3"},
> +{file = 
> "mypy-0.961-cp310-cp310-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_12_x86_64.manylinux2010_x86_64.whl",
>  hash = 
> "sha256:3e09f1f983a71d0672bbc97ae33ee3709d10c779beb613febc36805a6e28bb4e"},
> +{file = "mypy-0.961-cp310-cp310-win_amd64.whl", hash = 
> "sha256:e999229b9f3198c0c880d5e269f9f8129c8862451ce53a011326cad38b9ccd24"},
> +{file = "mypy-0.961-cp36-cp36m-macosx_10_9_x86_64.whl", hash = 
> "sha256:b24be97351084b11582fef18d79004b3e4db572219deee0212078f7cf6352723"},
> +{file = 
> "mypy-0.961-cp36-cp36m-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_12_x86_64.manylinux2010_x86_64.whl",
>  hash = 
> "sha256:f4a21d01fc0ba4e31d82f0fff195682e29f9401a8bdb7173891070eb260aeb3b"},
> +{file = "mypy-0.961-cp36-cp36m-win_amd64.whl", hash = 
> "sha256:439c726a3b3da7ca84a0199a8ab444cd8896d95012c4a6c4a0d808e3147abf5d"},
> +{file = "mypy-0.961-cp37-cp37m-macosx_10_9_x86_64.whl", hash = 
> "sha256:5a0b53747f713f490affdceef835d8f0cb7285187a6a44c33821b6d1f46ed813"},
> +{file = 
> "mypy-0.961-cp37-cp37m-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_12_x86_64.manylinux2010_x86_64.whl",
>  hash = 
> "sha256:0e9f70df36405c25cc530a86eeda1e0867863d9471fe76d1273c783df3d35c2e"},
> +{file = "mypy-0.961-cp37-cp37m-win_amd64.whl", hash = 
> "sha256:b88f784e9e35dcaa075519096dc947a388319cb86811b6af621e3523980f1c8a"},
> +{file = "mypy-0.961-cp38-cp38-macosx_10_9_universal2.whl", hash = 
> "sha256:d5aaf1edaa7692490f72bdb9fbd941fbf2e201713523bdb3f4038be0af8846c6"},
> +{file = "mypy-0.961-cp38-cp38-macosx_10_9_x86_64.whl", hash = 
> "sha256:9f5f5a74085d9a81a1f9c78081d60a0040c3efb3f28e5c9912b900adf59a16e6"},
> +{file = "mypy-0.961-cp38-cp38-macosx_11_0_arm64.whl", hash = 
> "sha256:f4b794db44168a4fc886e3450201365c9526a522c46ba089b55e1f11c163750d"},
> +{file = 
> "mypy-0.961-cp38-cp38-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_12_x86_64.manylinux2010_x86_64.whl",
>  hash = 
> "sha256:64759a273d590040a592e0f4186539858c948302c653c2eac840c7a3cd29e51b"},
> +{file = "mypy-0.961-cp38-cp38-win_amd64.whl", hash = 
> "sha256:63e85a03770ebf403291ec50097954cc5caf2a9205c888ce3a61bd3f82e17569"},
> +{file = "mypy-0.961-cp39-cp39-macosx_10_9_universal2.whl", hash = 
> "sha256:5f1332964963d4832a94bebc10f13d3279be3ce8f6c64da563d6ee6e2eeda932"},
> +{file = "mypy-0.961-cp39-cp39-macosx_10_9_x86_64.whl", hash = 
> "sha256:006be38474216b833eca29ff6b73e143386f352e10e9c2fbe76aa8549e5554f5"},
> +{file = "mypy-0.961-cp39-cp39-macosx_11_0_arm64.whl", hash = 
> "sha256:9940e6916ed9371809b35b2154baf1f684acba935cd09928952310fbddaba648"},
> +{file = 
> "mypy-0.961-cp39-cp39-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_12_x86_64.manylinux2010_x86_64.whl",
>  hash = 
> "sha256:a5ea0875a049de1b63b972456542f04643daf320d27dc592d7c3d9cd5d9bf950"},
> +{file = "mypy-0.961-cp39-cp39-win_amd64.whl", hash = 
> "sha256:1ece702f29270ec6af25db8cf6185c04c02311c6bb21a69f423d40e527b75c56"},
> +   

RE: [PATCH] cryptodev: clarify error codes returned

[Akhil Goyal]

> Subject: [PATCH] cryptodev: clarify error codes returned
> 
> When symmetric sessions are created, it may fail due to non-critical
> errors. When PMD doesn't support the specific combination that
> application requested, it can return -ENOTSUP which can be handled so in
> application. The API is already setting rte_errno according to the
> reason of the failure. Clarifying this in the spec to list down possible
> error codes.
> 
> Fixes: bdce2564dbf7 ("cryptodev: rework session framework")
> 
> Signed-off-by: Anoob Joseph 
Acked-by: Akhil Goyal 

RE: [PATCH 2/2] test/crypto: handle return code

[Power, Ciara]

Hi Anoob,

> -Original Message-
> From: Akhil Goyal 
> Sent: Tuesday 16 May 2023 11:13
> To: Anoob Joseph ; Fan Zhang
> ; Power, Ciara 
> Cc: Hemant Agrawal ; Jerin Jacob Kollanukkaran
> ; Tejasree Kondoj ; Ji, Kai
> ; dev@dpdk.org
> Subject: RE: [PATCH 2/2] test/crypto: handle return code
> 
> > Subject: [PATCH 2/2] test/crypto: handle return code
> >
> > The sub test case, test_snow3g_decryption, may fail for non-critical
> > reasons such as lack of support. Handle the return value gracefully to
> > allow TEST_SKIPPED return value to be propagated correctly.
> >
> > Signed-off-by: Anoob Joseph 
> Acked-by: Akhil Goyal 

This looks like a duplicate of a patch recently merged: 
https://patches.dpdk.org/project/dpdk/patch/20230414135526.4271-1-saoirse.odono...@intel.com/

Thanks,
Ciara

Re: [PATCH v7] mem: telemetry support for memseg and element information

[Burakov, Anatoly]

On 10/25/2022 2:02 PM, Amit Prakash Shukla wrote:

Changes adds telemetry support to display memory occupancy
in memseg and the information of the elements allocated from
a memseg based on arguments provided by user. This patch
adds following endpoints:

1. /eal/memseg_lists
The command displays the memseg list from which the memory
has been allocated.
Example:
--> /eal/memseg_lists
{"/eal/memseg_lists": [0, 1]}

2. /eal/memseg_list_info,
The command outputs the memsegs, from which the memory is
allocated, for the memseg_list given as input.
Example:
--> /eal/memseg_list_info,0
{"/eal/memseg_list_info": [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, \
  12, 13, 14, 15]}

3. /eal/memseg_info,,
The command outputs the memseg information based on the
memseg-list and the memseg-id given as input.
Example:
--> /eal/memseg_info,0,10
{"/eal/memseg_info": {"Memseg_list_index": 0, \
"Memseg_index": 10, "Start_addr": "0x10160", \
"End_addr": "0x10180", "Size": 2097152, "Hugepage_size": 2097152, \
"Socket_id": 0, "flags": 0}}

--> /eal/memseg_info,0,15
{"/eal/memseg_info": {"Memseg_list_index": 0, "Memseg_index": 15, \
"Start_addr": "0x10200", "End_addr": "0x10220", \
"Size": 2097152, "Hugepage_size": 2097152, "Socket_id": 0, "flags": 0}}

4. /eal/mem_element_list,,,
The command outputs number of elements in a memseg based
on the heap-id, memseg-list-id and memseg-id given as input.
Example:
--> /eal/mem_element_list,0,0,10
{"/eal/mem_element_list": {"Element_count": 52}}

--> /eal/mem_element_list,0,1,15
{"/eal/mem_element_list": {"Element_count": 52}}

5. /eal/mem_element_info  \
,
The command outputs element information like element start
address, end address, to which memseg it belongs, element
state, element size. User can give a range of elements to be
printed.
Example:
--> /eal/mem_element_info,0,0,15,1,2
{"/eal/mem_element_info": {"element_1": {"msl_id": 0, "ms_id": 15, \
"memseg_start_addr": "0x10200", "memseg_end_addr": "0x10220", \
"element_start_addr": "0x102000b00", "element_end_addr": "0x102003380", \
"element_size": 10368, "element_state": "Busy"}, "element_2": \
{"msl_id": 0, "ms_id": 15, "memseg_start_addr": "0x10200", \
"memseg_end_addr": "0x10220", "element_start_addr": "0x102003380", \
"element_end_addr": "0x102005c00", "element_size": 10368, \
"element_state": "Busy"}, "Element_count": 2}}

Signed-off-by: Amit Prakash Shukla 
---





+   ms_start_addr = ms->addr_64;
+   ms_end_addr = (uint64_t)RTE_PTR_ADD(ms_start_addr, ms->len);
+   ms_size = ms->len;
+   hugepage_size = ms->hugepage_sz;
+   ms_socket_id = ms->socket_id;
+   ms_flags = ms->flags;
+
+   rte_mcfg_mem_read_unlock();
+
+   rte_tel_data_start_dict(d);
+   rte_tel_data_add_dict_int(d, "Memseg_list_index", ms_list_idx);
+   rte_tel_data_add_dict_int(d, "Memseg_index", ms_idx);
+   snprintf(addr, ADDR_STR, "0x%"PRIx64, ms_start_addr);
+   rte_tel_data_add_dict_string(d, "Start_addr", addr);
+   snprintf(addr, ADDR_STR, "0x%"PRIx64, ms_end_addr);
+   rte_tel_data_add_dict_string(d, "End_addr", addr);
+   rte_tel_data_add_dict_u64(d, "Size", ms_size);
+   rte_tel_data_add_dict_u64(d, "Hugepage_size", hugepage_size);


Seems like rte_tel_data_add_dict_u64 is deprecated now.

I would also suggest outputting IOVA address for memsegs as well (unless 
it's set to RTE_BAD_IOVA, in which case it should say something 
meaningful too).


Otherwise (and with above changes), LGTM

Acked-by: Anatoly Burakov 
--
Thanks,
Anatoly

[PATCH] lib/kni : fix memory-leak on rte_kni_rx_burst

[Yasin CANER]

Coverity issue:
Bugzilla ID: 1227
Fixes:
Cc: sta...@dpdk.org
Cc: step...@networkplumber.org

Adding new condition to check buffer is removed or not.
it prevent allocation each time when rte_kni_rx_burst function called
that cause memory-leak.

Signed-off-by: Yasin CANER 
---
 lib/kni/rte_kni.c | 25 +
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/lib/kni/rte_kni.c b/lib/kni/rte_kni.c
index bfa6a001ff..2244892aae 100644
--- a/lib/kni/rte_kni.c
+++ b/lib/kni/rte_kni.c
@@ -660,7 +660,8 @@ kni_allocate_mbufs(struct rte_kni *kni)
int i, ret;
struct rte_mbuf *pkts[MAX_MBUF_BURST_NUM];
void *phys[MAX_MBUF_BURST_NUM];
-   int allocq_free;
+   int allocq_free, allocq_count;
+   uint32_t allocq;
 
RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, pool) !=
 offsetof(struct rte_kni_mbuf, pool));
@@ -682,10 +683,26 @@ kni_allocate_mbufs(struct rte_kni *kni)
RTE_LOG(ERR, KNI, "No valid mempool for allocating mbufs\n");
return;
}
-
+   /* First, getting allocation count from alloc_q. alloc_q is allocated 
in this function 
+* and/or kni_alloc function from mempool.
+* If alloc_q is completely removed, it shall be allocated again.
+* */
+   allocq = kni_fifo_count(kni->alloc_q);
+   /* How many free allocation is possible from mempool. */
allocq_free = kni_fifo_free_count(kni->alloc_q);
-   allocq_free = (allocq_free > MAX_MBUF_BURST_NUM) ?
-   MAX_MBUF_BURST_NUM : allocq_free;
+   /* Allocated alloc_q count shall be max MAX_MBUF_BURST_NUM. */
+   allocq_count = MAX_MBUF_BURST_NUM - (int)allocq;
+   /* Try to figure out how many allocation is possible. allocq_free is 
max possible.*/
+   allocq_free = (allocq_free > MAX_MBUF_BURST_NUM )? MAX_MBUF_BURST_NUM : 
allocq_free;
+   /* Buffer is not removed so no need re-allocate*/
+
+   if(!allocq_count) {
+   /* Buffer is not removed so no need re-allocation*/
+   return;
+   } else if (allocq_free > allocq_count) {
+   allocq_free = allocq_count;
+   }
+
for (i = 0; i < allocq_free; i++) {
pkts[i] = rte_pktmbuf_alloc(kni->pktmbuf_pool);
if (unlikely(pkts[i] == NULL)) {
-- 
2.25.1

RE: [PATCH 2/2] test/crypto: handle return code

[Anoob Joseph]

Hi Ciara,

> This looks like a duplicate of a patch recently merged:
Indeed. Missed it.

@Akhil, we can abandon this patch.

Thanks,
Anoob

> -Original Message-
> From: Power, Ciara 
> Sent: Tuesday, May 16, 2023 4:16 PM
> To: Akhil Goyal ; Anoob Joseph
> ; Fan Zhang 
> Cc: Hemant Agrawal ; Jerin Jacob Kollanukkaran
> ; Tejasree Kondoj ; Ji, Kai
> ; dev@dpdk.org
> Subject: [EXT] RE: [PATCH 2/2] test/crypto: handle return code
> 
> External Email
> 
> --
> Hi Anoob,
> 
> > -Original Message-
> > From: Akhil Goyal 
> > Sent: Tuesday 16 May 2023 11:13
> > To: Anoob Joseph ; Fan Zhang
> > ; Power, Ciara 
> > Cc: Hemant Agrawal ; Jerin Jacob
> Kollanukkaran
> > ; Tejasree Kondoj ; Ji, Kai
> > ; dev@dpdk.org
> > Subject: RE: [PATCH 2/2] test/crypto: handle return code
> >
> > > Subject: [PATCH 2/2] test/crypto: handle return code
> > >
> > > The sub test case, test_snow3g_decryption, may fail for non-critical
> > > reasons such as lack of support. Handle the return value gracefully
> > > to allow TEST_SKIPPED return value to be propagated correctly.
> > >
> > > Signed-off-by: Anoob Joseph 
> > Acked-by: Akhil Goyal 
> 
> This looks like a duplicate of a patch recently merged:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__patches.dpdk.org_project_dpdk_patch_20230414135526.4271-2D1-
> 2Dsaoirse.odonovan-
> 40intel.com_&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=jPfB8rwwviRSxy
> LWs2n6B-
> WYLn1v9SyTMrT5EQqh2TU&m=O_paIbxHa0g1eO0nnvRRDxs52JIZh_Xteso9I
> wXdLnFAYQyoPk4iryD2h4_uQRdB&s=QG45QCchVqKQyfhL8vENmY-
> JXiwsRS6zrbV3XxJoPTA&e=
> 
> Thanks,
> Ciara

[PATCH v2] lib/kni : coding style is fixed

[Yasin CANER]

Coverity issue:
Bugzilla ID: 1227
Fixes:
Cc: sta...@dpdk.org
Cc: step...@networkplumber.org

Coding style is fixed
---
 lib/kni/rte_kni.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/lib/kni/rte_kni.c b/lib/kni/rte_kni.c
index 2244892aae..70c2da 100644
--- a/lib/kni/rte_kni.c
+++ b/lib/kni/rte_kni.c
@@ -683,20 +683,21 @@ kni_allocate_mbufs(struct rte_kni *kni)
RTE_LOG(ERR, KNI, "No valid mempool for allocating mbufs\n");
return;
}
-   /* First, getting allocation count from alloc_q. alloc_q is allocated 
in this function 
-* and/or kni_alloc function from mempool.
-* If alloc_q is completely removed, it shall be allocated again.
-* */
+
+   /* First, getting allocation count from alloc_q. alloc_q is allocated 
in this function*/ 
+   /* and/or kni_alloc function from mempool.*/
+   /* If alloc_q is completely removed, it shall be allocated again.*/
+
allocq = kni_fifo_count(kni->alloc_q);
/* How many free allocation is possible from mempool. */
allocq_free = kni_fifo_free_count(kni->alloc_q);
/* Allocated alloc_q count shall be max MAX_MBUF_BURST_NUM. */
allocq_count = MAX_MBUF_BURST_NUM - (int)allocq;
/* Try to figure out how many allocation is possible. allocq_free is 
max possible.*/
-   allocq_free = (allocq_free > MAX_MBUF_BURST_NUM )? MAX_MBUF_BURST_NUM : 
allocq_free;
+   allocq_free = (allocq_free > MAX_MBUF_BURST_NUM) ? MAX_MBUF_BURST_NUM : 
allocq_free;
/* Buffer is not removed so no need re-allocate*/
 
-   if(!allocq_count) {
+   if (!allocq_count) {
/* Buffer is not removed so no need re-allocation*/
return;
} else if (allocq_free > allocq_count) {
-- 
2.25.1

RE: [PATCH v1 1/1] cryptodev: support EDDSA

[Akhil Goyal]

Hi Sachin,

> Subject: [PATCH v1 1/1] cryptodev: support EDDSA
> 
> Asymmetric crypto library is extended to add EDDSA. Edwards curve
> operation params are introduced.

EDDSA -> EdDSA in patch title and description

> 
> Signed-off-by: Sachin Yaligar 
> Change-Id: I939d7646f95723113fa9f3bdbc01c0aeb4620e74

Remove change-id

> ---
>  .mailmap   |  1 +
>  doc/guides/cryptodevs/features/default.ini |  1 +
>  doc/guides/prog_guide/cryptodev_lib.rst|  2 +-
>  lib/cryptodev/rte_crypto_asym.h| 39 +-
>  4 files changed, 41 insertions(+), 2 deletions(-)
> 

Please also add release notes for adding the new algorithm.


> diff --git a/.mailmap b/.mailmap
> index cac02a6f48..6d92b56560 100644
> --- a/.mailmap
> +++ b/.mailmap
> @@ -1169,6 +1169,7 @@ Rushil Gupta 
>  Ryan E Hall 
>  Sabyasachi Sengupta 
>  Sachin Saxena  
> +Sachin Yaligar 
>  Sagar Abhang 
>  Sagi Grimberg 
>  Saikrishna Edupuganti 
> diff --git a/doc/guides/cryptodevs/features/default.ini
> b/doc/guides/cryptodevs/features/default.ini
> index 523da0cfa8..247a56be6e 100644
> --- a/doc/guides/cryptodevs/features/default.ini
> +++ b/doc/guides/cryptodevs/features/default.ini
> @@ -125,6 +125,7 @@ Diffie-hellman  =
>  ECDSA   =
>  ECPM=
>  ECDH=
> +EDDSA=
> 
>  ;
>  ; Supported Operating systems of a default crypto driver.
> diff --git a/doc/guides/prog_guide/cryptodev_lib.rst
> b/doc/guides/prog_guide/cryptodev_lib.rst
> index 2b513bbf82..358dbbc768 100644
> --- a/doc/guides/prog_guide/cryptodev_lib.rst
> +++ b/doc/guides/prog_guide/cryptodev_lib.rst
> @@ -927,7 +927,7 @@ Asymmetric Cryptography
>  The cryptodev library currently provides support for the following asymmetric
>  Crypto operations; RSA, Modular exponentiation and inversion, Diffie-Hellman
> and
>  Elliptic Curve Diffie-Hellman public and/or private key generation and shared
> -secret compute, DSA Signature generation and verification.
> +secret compute, DSA and Edward's curve DSA Signature generation and
> verification.
> 
>  Session and Session Management
>  ~~
> diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
> index 989f38323f..fc7172b070 100644
> --- a/lib/cryptodev/rte_crypto_asym.h
> +++ b/lib/cryptodev/rte_crypto_asym.h
> @@ -69,7 +69,9 @@ enum rte_crypto_curve_id {
>   RTE_CRYPTO_EC_GROUP_SECP224R1 = 21,
>   RTE_CRYPTO_EC_GROUP_SECP256R1 = 23,
>   RTE_CRYPTO_EC_GROUP_SECP384R1 = 24,
> - RTE_CRYPTO_EC_GROUP_SECP521R1 = 25
> + RTE_CRYPTO_EC_GROUP_SECP521R1 = 25,
> + RTE_CRYPTO_EC_GROUP_ED25519 = 29,
> + RTE_CRYPTO_EC_GROUP_ED448 = 30
>  };
> 
>  /**
> @@ -113,6 +115,10 @@ enum rte_crypto_asym_xform_type {
>   /**< Elliptic Curve Digital Signature Algorithm
>* Perform Signature Generation and Verification.
>*/
> + RTE_CRYPTO_ASYM_XFORM_EDDSA,
> + /**< Edwards Curve Digital Signature Algorithm
> +  * Perform Signature Generation and Verification.
> +  */
>   RTE_CRYPTO_ASYM_XFORM_ECDH,
>   /**< Elliptic Curve Diffie Hellman */
>   RTE_CRYPTO_ASYM_XFORM_ECPM,
> @@ -591,6 +597,36 @@ struct rte_crypto_ecdsa_op_param {
>*/
>  };
> 
> +/**
> + * EDDSA operation params
> + */
> +struct rte_crypto_eddsa_op_param {
> + enum rte_crypto_asym_op_type op_type;
> + /**< Signature generation or verification */

Please add '.' at end of sentences.

> +
> + rte_crypto_uint pkey;
> + /**< Private key of the signer for signature generation */
> +
> + struct rte_crypto_ec_point q;
> + /**< Public key of the signer derived from private key
> +  *  h = hash(pkey), q = (h[0-31] * B)
> +  */
> +
> + rte_crypto_param message;
> + /**< Input message digest to be signed or verified */
> +
> + rte_crypto_uint r;
> + /**< r component of edward curve signature

edward -> Edward

> +  * output : for signature generation
> +  * input  : for signature verification
> +  */
> + rte_crypto_uint s;
> + /**< s component of edward curve signature
> +  * output : for signature generation
> +  * input  : for signature verification
> +  */
> +};
> +
>  /**
>   * Structure for EC point multiplication operation param
>   */
> @@ -664,6 +700,7 @@ struct rte_crypto_asym_op {
>   struct rte_crypto_ecdh_op_param ecdh;
>   struct rte_crypto_dsa_op_param dsa;
>   struct rte_crypto_ecdsa_op_param ecdsa;
> + struct rte_crypto_eddsa_op_param eddsa;
>   struct rte_crypto_ecpm_op_param ecpm;
>   };
>   uint16_t flags;


I see that the changes in rte_crypto_asym_xform are missing for EdDSA.

Also please send the corresponding patches for the driver and test app.

Re: [PATCH 0/2] net/hns3: add some features for hns3 pmd

[Dongdong Liu]

Kindly ping.

Thanks,
Dongdong

On 2023/4/21 17:53, Dongdong Liu wrote:

This patchset is to add some features for hns3 pmd.

Chengwen Feng (1):
  net/hns3: support dump media type

Dongdong Liu (1):
  net/hns3: simplify for hardware csum offloading

 drivers/net/hns3/hns3_cmd.c|  3 ++
 drivers/net/hns3/hns3_cmd.h|  1 +
 drivers/net/hns3/hns3_dump.c   |  3 ++
 drivers/net/hns3/hns3_ethdev.c |  2 +-
 drivers/net/hns3/hns3_ethdev.h |  3 ++
 drivers/net/hns3/hns3_rxtx.c   | 52 +-
 drivers/net/hns3/hns3_rxtx.h   | 12 +++-
 7 files changed, 73 insertions(+), 3 deletions(-)

--
2.22.0

.

[PATCH v2 0/3] Windows performance enhancements

[Tal Shnaiderman]

The following series enables support of 3 hardware offloads on Windows which 
improve PMD throughput.

RX throughput improvements:
**Multi-packet RQ.
**CQE compression.

TX throughput improvement:
**Multi packet send.

---
v2: 
* Add tags
---

Tal Shnaiderman (3):
  net/mlx5: support multi-packet RQ on Windows
  net/mlx5: support CQE compression on Windows
  net/mlx5: support enhanced multi-packet write on Windows

 doc/guides/rel_notes/release_23_07.rst  | 33 +++--
 drivers/common/mlx5/mlx5_devx_cmds.c| 11 +++
 drivers/common/mlx5/mlx5_devx_cmds.h|  5 
 drivers/common/mlx5/windows/mlx5_win_defs.h |  8 -
 drivers/net/mlx5/windows/mlx5_os.c  | 46 -
 5 files changed, 72 insertions(+), 31 deletions(-)

-- 
2.16.1.windows.4

[PATCH v2 2/3] net/mlx5: support CQE compression on Windows

[Tal Shnaiderman]

CQE Compression reduces PCI overhead by coalescing and compressing
multiple CQEs into a single merged CQE.

Add supported for the CQE compression feature on Windows.
feature is enabled by default unless not supported by the HW
or if the rxq_cqe_comp_en PMD argument is explicitly disabled.

Signed-off-by: Tal Shnaiderman 
Tested-by: Pier Damouny  
Acked-by: Matan Azrad 
---
 drivers/common/mlx5/mlx5_devx_cmds.c |  2 ++
 drivers/common/mlx5/mlx5_devx_cmds.h |  1 +
 drivers/net/mlx5/windows/mlx5_os.c   | 12 
 3 files changed, 15 insertions(+)

diff --git a/drivers/common/mlx5/mlx5_devx_cmds.c 
b/drivers/common/mlx5/mlx5_devx_cmds.c
index 096bd1d520..a31e4995f5 100644
--- a/drivers/common/mlx5/mlx5_devx_cmds.c
+++ b/drivers/common/mlx5/mlx5_devx_cmds.c
@@ -1062,6 +1062,8 @@ mlx5_devx_cmd_query_hca_attr(void *ctx,
attr->cqe_compression = MLX5_GET(cmd_hca_cap, hcattr, cqe_compression);
attr->mini_cqe_resp_flow_tag = MLX5_GET(cmd_hca_cap, hcattr,
mini_cqe_resp_flow_tag);
+   attr->cqe_compression_128 = MLX5_GET(cmd_hca_cap, hcattr,
+   cqe_compression_128);
attr->mini_cqe_resp_l3_l4_tag = MLX5_GET(cmd_hca_cap, hcattr,
 mini_cqe_resp_l3_l4_tag);
attr->enhanced_cqe_compression = MLX5_GET(cmd_hca_cap, hcattr,
diff --git a/drivers/common/mlx5/mlx5_devx_cmds.h 
b/drivers/common/mlx5/mlx5_devx_cmds.h
index 9e7992b1c6..edcd867c4e 100644
--- a/drivers/common/mlx5/mlx5_devx_cmds.h
+++ b/drivers/common/mlx5/mlx5_devx_cmds.h
@@ -284,6 +284,7 @@ struct mlx5_hca_attr {
uint16_t max_wqe_sz_sq;
uint32_t striding_rq:1;
uint32_t ext_stride_num_range:1;
+   uint32_t cqe_compression_128:1;
uint32_t set_reg_c:8;
uint32_t nic_flow_table:1;
uint32_t modify_outer_ip_ecn:1;
diff --git a/drivers/net/mlx5/windows/mlx5_os.c 
b/drivers/net/mlx5/windows/mlx5_os.c
index 0caa8931e4..6527269663 100644
--- a/drivers/net/mlx5/windows/mlx5_os.c
+++ b/drivers/net/mlx5/windows/mlx5_os.c
@@ -237,6 +237,18 @@ mlx5_os_capabilities_prepare(struct mlx5_dev_ctx_shared 
*sh)
} else {
DRV_LOG(DEBUG, "Tunnel offloading is not supported.");
}
+   sh->dev_cap.cqe_comp = 0;
+#if (RTE_CACHE_LINE_SIZE == 128)
+   if (hca_attr->cqe_compression_128)
+   sh->dev_cap.cqe_comp = 1;
+   DRV_LOG(DEBUG, "Rx CQE 128B compression is %ssupported.",
+   sh->dev_cap.cqe_comp ? "" : "not ");
+#else
+   if (hca_attr->cqe_compression)
+   sh->dev_cap.cqe_comp = 1;
+   DRV_LOG(DEBUG, "Rx CQE compression is %ssupported.",
+   sh->dev_cap.cqe_comp ? "" : "not ");
+#endif
snprintf(sh->dev_cap.fw_ver, 64, "%x.%x.%04x",
 MLX5_GET(initial_seg, pv_iseg, fw_rev_major),
 MLX5_GET(initial_seg, pv_iseg, fw_rev_minor),
-- 
2.16.1.windows.4

[PATCH v2 3/3] net/mlx5: support enhanced multi-packet write on Windows

[Tal Shnaiderman]

Add support for enhanced multi-packet write on Windows.

Enhanced multi-packet write allows the Tx burst function to pack up
multiple packets in a single descriptor session to save PCI bandwidth
and improve performance.

The feature can be controlled by the txq_mpw_en PMD argument:

txq_mpw_en=1 - PMD will first attempt to use "enhanced multi packet write"
if the feature is not supported by the HW the legacy "multi packet write"
will be used.
if both are unsupported the multi packet write feature is disabled.

txq_mpw_en=0 - multi packet write is disabled.

txq_mpw_en unset(default) - enhanced multi packet write
will be activated if supported.
if unsupported the multi packet write feature is disabled.

Signed-off-by: Tal Shnaiderman 
Tested-by: Pier Damouny  
Acked-by: Matan Azrad 
---
 doc/guides/rel_notes/release_23_07.rst | 33 -
 drivers/common/mlx5/mlx5_devx_cmds.c   |  6 ++
 drivers/common/mlx5/mlx5_devx_cmds.h   |  2 ++
 drivers/net/mlx5/windows/mlx5_os.c |  8 +++-
 4 files changed, 19 insertions(+), 30 deletions(-)

diff --git a/doc/guides/rel_notes/release_23_07.rst 
b/doc/guides/rel_notes/release_23_07.rst
index a9b1293689..d74551414d 100644
--- a/doc/guides/rel_notes/release_23_07.rst
+++ b/doc/guides/rel_notes/release_23_07.rst
@@ -24,36 +24,11 @@ DPDK Release 23.07
 New Features
 
 
-.. This section should contain new features added in this release.
-   Sample format:
+* **Updated NVIDIA mlx5 driver.**
 
-   * **Add a title in the past tense with a full stop.**
-
- Add a short 1-2 sentence description in the past tense.
- The description should be enough to allow someone scanning
- the release notes to understand the new feature.
-
- If the feature adds a lot of sub-features you can use a bullet list
- like this:
-
- * Added feature foo to do something.
- * Enhanced feature bar to do something else.
-
- Refer to the previous release notes for examples.
-
- Suggested order in release notes items:
- * Core libs (EAL, mempool, ring, mbuf, buses)
- * Device abstraction libs and PMDs (ordered alphabetically by vendor name)
-   - ethdev (lib, PMDs)
-   - cryptodev (lib, PMDs)
-   - eventdev (lib, PMDs)
-   - etc
- * Other libs
- * Apps, Examples, Tools (if significant)
-
- This section is a comment. Do not overwrite or remove it.
- Also, make sure to start the actual text at the margin.
- ===
+  * Added support for multi-packet RQ on Windows.
+  * Added support for CQE compression on Windows.
+  * Added support for enhanced multi-packet write on Windows.
 
 
 Removed Items
diff --git a/drivers/common/mlx5/mlx5_devx_cmds.c 
b/drivers/common/mlx5/mlx5_devx_cmds.c
index a31e4995f5..b2abc742cf 100644
--- a/drivers/common/mlx5/mlx5_devx_cmds.c
+++ b/drivers/common/mlx5/mlx5_devx_cmds.c
@@ -1298,6 +1298,12 @@ mlx5_devx_cmd_query_hca_attr(void *ctx,
attr->rss_ind_tbl_cap = MLX5_GET
(per_protocol_networking_offload_caps,
 hcattr, rss_ind_tbl_cap);
+   attr->multi_pkt_send_wqe = MLX5_GET
+   (per_protocol_networking_offload_caps,
+hcattr, multi_pkt_send_wqe);
+   attr->enhanced_multi_pkt_send_wqe = MLX5_GET
+   (per_protocol_networking_offload_caps,
+hcattr, enhanced_multi_pkt_send_wqe);
/* Query HCA attribute for ROCE. */
if (attr->roce) {
hcattr = mlx5_devx_get_hca_cap(ctx, in, out, &rc,
diff --git a/drivers/common/mlx5/mlx5_devx_cmds.h 
b/drivers/common/mlx5/mlx5_devx_cmds.h
index edcd867c4e..c8427d2dbb 100644
--- a/drivers/common/mlx5/mlx5_devx_cmds.h
+++ b/drivers/common/mlx5/mlx5_devx_cmds.h
@@ -285,6 +285,8 @@ struct mlx5_hca_attr {
uint32_t striding_rq:1;
uint32_t ext_stride_num_range:1;
uint32_t cqe_compression_128:1;
+   uint32_t multi_pkt_send_wqe:1;
+   uint32_t enhanced_multi_pkt_send_wqe:1;
uint32_t set_reg_c:8;
uint32_t nic_flow_table:1;
uint32_t modify_outer_ip_ecn:1;
diff --git a/drivers/net/mlx5/windows/mlx5_os.c 
b/drivers/net/mlx5/windows/mlx5_os.c
index 6527269663..b731bdff06 100644
--- a/drivers/net/mlx5/windows/mlx5_os.c
+++ b/drivers/net/mlx5/windows/mlx5_os.c
@@ -173,7 +173,6 @@ mlx5_os_capabilities_prepare(struct mlx5_dev_ctx_shared *sh)
sh->dev_cap.max_qp = 1 << hca_attr->log_max_qp;
sh->dev_cap.max_qp_wr = 1 << hca_attr->log_max_qp_sz;
sh->dev_cap.dv_flow_en = 1;
-   sh->dev_cap.mps = MLX5_MPW_DISABLED;
DRV_LOG(DEBUG, "MPW isn't supported.");
DRV_LOG(DEBUG, "MPLS over GRE/UDP tunnel offloading is no supported.");
sh->dev_cap.hw_csum = hca_attr->csum_cap;
@@ -224,6 +223,13 @@ mlx5_os_capabilities_prepare(struct mlx5_d

[PATCH v2 1/3] net/mlx5: support multi-packet RQ on Windows

[Tal Shnaiderman]

Multi-Packet RQ can further save PCIe bandwidth by posting a single large
buffer for multiple packets.

Instead of posting a buffer per a packet, one large buffer is posted
to receive multiple packets on the buffer.

Add support for multi-packet RQ on Windows.
The feature is disabled by default and can by enabled
by setting mprq_en=1 in the PMD specific arguments.

Signed-off-by: Tal Shnaiderman 
Tested-by: Pier Damouny  
Acked-by: Matan Azrad 
---
 drivers/common/mlx5/mlx5_devx_cmds.c|  3 +++
 drivers/common/mlx5/mlx5_devx_cmds.h|  2 ++
 drivers/common/mlx5/windows/mlx5_win_defs.h |  8 +++-
 drivers/net/mlx5/windows/mlx5_os.c  | 26 ++
 4 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/drivers/common/mlx5/mlx5_devx_cmds.c 
b/drivers/common/mlx5/mlx5_devx_cmds.c
index d0907fcd49..096bd1d520 100644
--- a/drivers/common/mlx5/mlx5_devx_cmds.c
+++ b/drivers/common/mlx5/mlx5_devx_cmds.c
@@ -1076,6 +1076,9 @@ mlx5_devx_cmd_query_hca_attr(void *ctx,
 general_obj_types) &
  MLX5_GENERAL_OBJ_TYPES_CAP_CONN_TRACK_OFFLOAD);
attr->rq_delay_drop = MLX5_GET(cmd_hca_cap, hcattr, rq_delay_drop);
+   attr->striding_rq = MLX5_GET(cmd_hca_cap, hcattr, striding_rq);
+   attr->ext_stride_num_range =
+   MLX5_GET(cmd_hca_cap, hcattr, ext_stride_num_range);
attr->max_flow_counter_15_0 = MLX5_GET(cmd_hca_cap, hcattr,
max_flow_counter_15_0);
attr->max_flow_counter_31_16 = MLX5_GET(cmd_hca_cap, hcattr,
diff --git a/drivers/common/mlx5/mlx5_devx_cmds.h 
b/drivers/common/mlx5/mlx5_devx_cmds.h
index ce173bc36a..9e7992b1c6 100644
--- a/drivers/common/mlx5/mlx5_devx_cmds.h
+++ b/drivers/common/mlx5/mlx5_devx_cmds.h
@@ -282,6 +282,8 @@ struct mlx5_hca_attr {
uint32_t crypto_wrapped_import_method:1;
uint16_t esw_mgr_vport_id; /* E-Switch Mgr vport ID . */
uint16_t max_wqe_sz_sq;
+   uint32_t striding_rq:1;
+   uint32_t ext_stride_num_range:1;
uint32_t set_reg_c:8;
uint32_t nic_flow_table:1;
uint32_t modify_outer_ip_ecn:1;
diff --git a/drivers/common/mlx5/windows/mlx5_win_defs.h 
b/drivers/common/mlx5/windows/mlx5_win_defs.h
index 65da820c5e..885114655f 100644
--- a/drivers/common/mlx5/windows/mlx5_win_defs.h
+++ b/drivers/common/mlx5/windows/mlx5_win_defs.h
@@ -270,4 +270,10 @@ enum {
MLX5_MATCH_INNER_HEADERS= RTE_BIT32(2),
 };
 
-#endif /* MLX5_WIN_DEFS_H */
+#define MLX5_MIN_SINGLE_WQE_LOG_NUM_STRIDES 9
+#define MLX5_MAX_SINGLE_WQE_LOG_NUM_STRIDES 16
+#define MLX5_MIN_SINGLE_STRIDE_LOG_NUM_BYTES 6
+#define MLX5_MAX_SINGLE_STRIDE_LOG_NUM_BYTES 13
+#define MLX5_EXT_MIN_SINGLE_WQE_LOG_NUM_STRIDES 3
+#define IB_QPT_RAW_PACKET 8
+#endif /* __MLX5_WIN_DEFS_H__ */
diff --git a/drivers/net/mlx5/windows/mlx5_os.c 
b/drivers/net/mlx5/windows/mlx5_os.c
index f401264b61..0caa8931e4 100644
--- a/drivers/net/mlx5/windows/mlx5_os.c
+++ b/drivers/net/mlx5/windows/mlx5_os.c
@@ -187,6 +187,32 @@ mlx5_os_capabilities_prepare(struct mlx5_dev_ctx_shared 
*sh)
if (sh->dev_cap.tso)
sh->dev_cap.tso_max_payload_sz = 1 << hca_attr->max_lso_cap;
DRV_LOG(DEBUG, "Counters are not supported.");
+   if (hca_attr->striding_rq) {
+   sh->dev_cap.mprq.enabled = 1;
+   sh->dev_cap.mprq.log_min_stride_size =
+   MLX5_MIN_SINGLE_STRIDE_LOG_NUM_BYTES;
+   sh->dev_cap.mprq.log_max_stride_size =
+   MLX5_MAX_SINGLE_STRIDE_LOG_NUM_BYTES;
+   if (hca_attr->ext_stride_num_range)
+   sh->dev_cap.mprq.log_min_stride_num =
+   MLX5_EXT_MIN_SINGLE_WQE_LOG_NUM_STRIDES;
+   else
+   sh->dev_cap.mprq.log_min_stride_num =
+   MLX5_MIN_SINGLE_WQE_LOG_NUM_STRIDES;
+   sh->dev_cap.mprq.log_max_stride_num =
+   MLX5_MAX_SINGLE_WQE_LOG_NUM_STRIDES;
+   DRV_LOG(DEBUG, "\tmin_single_stride_log_num_of_bytes: %u",
+   sh->dev_cap.mprq.log_min_stride_size);
+   DRV_LOG(DEBUG, "\tmax_single_stride_log_num_of_bytes: %u",
+   sh->dev_cap.mprq.log_max_stride_size);
+   DRV_LOG(DEBUG, "\tmin_single_wqe_log_num_of_strides: %u",
+   sh->dev_cap.mprq.log_min_stride_num);
+   DRV_LOG(DEBUG, "\tmax_single_wqe_log_num_of_strides: %u",
+   sh->dev_cap.mprq.log_max_stride_num);
+   DRV_LOG(DEBUG, "\tmin_stride_wqe_log_size: %u",
+   sh->dev_cap.mprq.log_min_stride_wqe_size);
+   DRV_LOG(DEBUG, "Device supports Multi-Packet RQ.");
+   }
if (hca_attr->rss_ind_tbl_cap) {
/*
 * DPDK doesn't support larger/variable indirection tables.
-- 
2.16.1.windows.4

Re: [PATCH V5 0/5] app/testpmd: support multiple process attach and detach port

[lihuisong (C)]

Hi Ferruh and Thomas,

Can you continue to take a look at this series?
This work has been working on since August last year.

/Huisong


在 2023/1/31 11:33, Huisong Li 写道:

This patchset fix some bugs and support attaching and detaching port
in primary and secondary.

---
  -v5: move 'ALLOCATED' state to the back of 'REMOVED' to avoid abi break.
  -v4: fix a misspelling.
  -v3:
#1 merge patch 1/6 and patch 2/6 into patch 1/5, and add modification
   for other bus type.
#2 add a RTE_ETH_DEV_ALLOCATED state in rte_eth_dev_state to resolve
   the probelm in patch 2/5.
  -v2: resend due to CI unexplained failure.

Huisong Li (5):
   drivers/bus: restore driver assignment at front of probing
   ethdev: fix skip valid port in probing callback
   app/testpmd: check the validity of the port
   app/testpmd: add attach and detach port for multiple process
   app/testpmd: stop forwarding in new or destroy event

  app/test-pmd/testpmd.c   | 47 +++-
  app/test-pmd/testpmd.h   |  1 -
  drivers/bus/auxiliary/auxiliary_common.c |  9 -
  drivers/bus/dpaa/dpaa_bus.c  |  9 -
  drivers/bus/fslmc/fslmc_bus.c|  8 +++-
  drivers/bus/ifpga/ifpga_bus.c| 12 --
  drivers/bus/pci/pci_common.c |  9 -
  drivers/bus/vdev/vdev.c  | 10 -
  drivers/bus/vmbus/vmbus_common.c |  9 -
  drivers/net/bnxt/bnxt_ethdev.c   |  3 +-
  drivers/net/bonding/bonding_testpmd.c|  1 -
  drivers/net/mlx5/mlx5.c  |  2 +-
  lib/ethdev/ethdev_driver.c   | 13 +--
  lib/ethdev/ethdev_driver.h   | 12 ++
  lib/ethdev/ethdev_pci.h  |  2 +-
  lib/ethdev/rte_class_eth.c   |  2 +-
  lib/ethdev/rte_ethdev.c  |  4 +-
  lib/ethdev/rte_ethdev.h  |  4 +-
  lib/ethdev/version.map   |  1 +
  19 files changed, 114 insertions(+), 44 deletions(-)

Re: [PATCH v2 3/3] vhost: add device op to offload the interrupt kick

[Eelco Chaudron]

On 16 May 2023, at 12:12, David Marchand wrote:

> On Tue, May 16, 2023 at 10:53 AM Eelco Chaudron  wrote:
>> On 10 May 2023, at 13:44, David Marchand wrote:
>
> [snip]
>
 @@ -846,6 +848,14 @@ vhost_user_socket_mem_free(struct vhost_user_socket 
 *vsocket)
 vsocket->path = NULL;
 }

 +   if (vsocket && vsocket->alloc_notify_ops) {
 +#pragma GCC diagnostic push
 +#pragma GCC diagnostic ignored "-Wcast-qual"
 +   free((struct rte_vhost_device_ops *)vsocket->notify_ops);
 +#pragma GCC diagnostic pop
 +   vsocket->notify_ops = NULL;
 +   }
>>>
>>> Rather than select the behavior based on a boolean (and here force the
>>> compiler to close its eyes), I would instead add a non const pointer
>>> to ops (let's say alloc_notify_ops) in vhost_user_socket.
>>> The code can then unconditionnally call free(vsocket->alloc_notify_ops);
>>
>> Good idea, I will make the change in v3.
>
> Feel free to use a better name for this field :-).
>
>>
 +
 if (vsocket) {
 free(vsocket);
 vsocket = NULL;
>
> [snip]
>
 +   /*
 +* Although the ops structure is a const structure, we do need to
 +* override the guest_notify operation. This is because with the
 +* previous APIs it was "reserved" and if any garbage value was 
 passed,
 +* it could crash the application.
 +*/
 +   if (ops && !ops->guest_notify) {
>>>
>>> Hum, as described in the comment above, I don't think we should look
>>> at ops->guest_notify value at all.
>>> Checking ops != NULL should be enough.
>>
>> Not sure I get you here. If the guest_notify passed by the user is NULL, it 
>> means the previously ‘reserved[1]’ field is NULL, so we do not need to use a 
>> new structure.
>>
>> I guess your comment would be true if we would introduce a new field in the 
>> data structure, not replacing a reserved one.
>
> Hum, I don't understand my comment either o_O'.
> Too many days off... or maybe my evil twin took over the keyboard.
>
>
>>
 +   struct rte_vhost_device_ops *new_ops;
 +
 +   new_ops = malloc(sizeof(*new_ops));
>>>
>>> Strictly speaking, we lose the numa affinity of "ops" by calling malloc.
>>> I am unclear of the impact though.
>>
>> Don’t think there is a portable API that we can use to determine the NUMA 
>> for the ops memory and then allocate this on the same numa?
>>
>> Any thoughts or ideas on how to solve this? I hope most people will memset() 
>> the ops structure and the reserved[1] part is zero, but it might be a 
>> problem in the future if more extensions get added.
>
> Determinining current numa is doable, via 'ops'
> get_mempolicy(MPOL_F_NODE | MPOL_F_ADDR), like what is done for vq in
> numa_realloc().
> The problem is how to allocate on this numa with the libc allocator
> for which I have no idea...
> We could go with the dpdk allocator (again, like numa_realloc()).
>
>
> In practice, the passed ops will be probably from a const variable in
> the program .data section (for which I think fields are set to 0
> unless explicitly initialised), or a memset() will be called for a
> dynamic allocation from good citizens.
> So we can probably live with the current proposal.
> Plus, this is only for one release, since in 23.11 with the ABI bump,
> we will drop this compat code.
>
> Maxime, Chenbo, what do you think?

Wait for their response, but for now I assume we can just keep the numa unaware 
malloc().

>
> [snip]
>
>>>
>>> But putting indentation aside, is this change equivalent?
>>> -   if ((vhost_need_event(vhost_used_event(vq), new, old) &&
>>> -   (vq->callfd >= 0)) ||
>>> -   unlikely(!signalled_used_valid)) {
>>> +   if ((vhost_need_event(vhost_used_event(vq), new, old) ||
>>> +   unlikely(!signalled_used_valid)) &&
>>> +   vq->callfd >= 0) {
>>
>> They are not equal, but in the past eventfd_write() should also not have 
>> been called with callfd < 0, guess this was an existing bug ;)
>
> I think this should be a separate fix.

ACK, will add a separate patch in this series to fix it.

>
>>
 +   vhost_vring_inject_irq(dev, vq);
>
>
> -- 
> David Marchand

Re: [PATCH v2 3/3] vhost: add device op to offload the interrupt kick

[Maxime Coquelin]

On 5/16/23 13:36, Eelco Chaudron wrote:



On 16 May 2023, at 12:12, David Marchand wrote:


On Tue, May 16, 2023 at 10:53 AM Eelco Chaudron  wrote:

On 10 May 2023, at 13:44, David Marchand wrote:


[snip]


@@ -846,6 +848,14 @@ vhost_user_socket_mem_free(struct vhost_user_socket 
*vsocket)
 vsocket->path = NULL;
 }

+   if (vsocket && vsocket->alloc_notify_ops) {
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wcast-qual"
+   free((struct rte_vhost_device_ops *)vsocket->notify_ops);
+#pragma GCC diagnostic pop
+   vsocket->notify_ops = NULL;
+   }


Rather than select the behavior based on a boolean (and here force the
compiler to close its eyes), I would instead add a non const pointer
to ops (let's say alloc_notify_ops) in vhost_user_socket.
The code can then unconditionnally call free(vsocket->alloc_notify_ops);


Good idea, I will make the change in v3.


Feel free to use a better name for this field :-).




+
 if (vsocket) {
 free(vsocket);
 vsocket = NULL;


[snip]


+   /*
+* Although the ops structure is a const structure, we do need to
+* override the guest_notify operation. This is because with the
+* previous APIs it was "reserved" and if any garbage value was passed,
+* it could crash the application.
+*/
+   if (ops && !ops->guest_notify) {


Hum, as described in the comment above, I don't think we should look
at ops->guest_notify value at all.
Checking ops != NULL should be enough.


Not sure I get you here. If the guest_notify passed by the user is NULL, it 
means the previously ‘reserved[1]’ field is NULL, so we do not need to use a 
new structure.

I guess your comment would be true if we would introduce a new field in the 
data structure, not replacing a reserved one.


Hum, I don't understand my comment either o_O'.
Too many days off... or maybe my evil twin took over the keyboard.





+   struct rte_vhost_device_ops *new_ops;
+
+   new_ops = malloc(sizeof(*new_ops));


Strictly speaking, we lose the numa affinity of "ops" by calling malloc.
I am unclear of the impact though.


Don’t think there is a portable API that we can use to determine the NUMA for 
the ops memory and then allocate this on the same numa?

Any thoughts or ideas on how to solve this? I hope most people will memset() 
the ops structure and the reserved[1] part is zero, but it might be a problem 
in the future if more extensions get added.


Determinining current numa is doable, via 'ops'
get_mempolicy(MPOL_F_NODE | MPOL_F_ADDR), like what is done for vq in
numa_realloc().
The problem is how to allocate on this numa with the libc allocator
for which I have no idea...
We could go with the dpdk allocator (again, like numa_realloc()).


In practice, the passed ops will be probably from a const variable in
the program .data section (for which I think fields are set to 0
unless explicitly initialised), or a memset() will be called for a
dynamic allocation from good citizens.
So we can probably live with the current proposal.
Plus, this is only for one release, since in 23.11 with the ABI bump,
we will drop this compat code.

Maxime, Chenbo, what do you think?


Wait for their response, but for now I assume we can just keep the numa unaware 
malloc().


Let's keep it as is as we'll get rid of it in 23.11.



[snip]



But putting indentation aside, is this change equivalent?
-   if ((vhost_need_event(vhost_used_event(vq), new, old) &&
-   (vq->callfd >= 0)) ||
-   unlikely(!signalled_used_valid)) {
+   if ((vhost_need_event(vhost_used_event(vq), new, old) ||
+   unlikely(!signalled_used_valid)) &&
+   vq->callfd >= 0) {


They are not equal, but in the past eventfd_write() should also not have been 
called with callfd < 0, guess this was an existing bug ;)


I think this should be a separate fix.


ACK, will add a separate patch in this series to fix it.


I also caught & fixed it while implementing my VDUSE series [0].
You can pick it in your series, and I will rebase my series on top of
it.

Thanks,
Maxime

[0]: 
https://gitlab.com/mcoquelin/dpdk-next-virtio/-/commit/b976e1f226db5c09834148847d994045eb89be93










+   vhost_vring_inject_irq(dev, vq);



--
David Marchand

Re: [PATCH V8] ethdev: fix one address occupies two entries in MAC addrs

[lihuisong (C)]

Hi Ferruh,

There is no result on techboard.
How to deal with this problem next?

/Huisong

在 2023/2/2 20:36, Huisong Li 写道:

The dev->data->mac_addrs[0] will be changed to a new MAC address when
applications modify the default MAC address by .mac_addr_set(). However,
if the new default one has been added as a non-default MAC address by
.mac_addr_add(), the .mac_addr_set() doesn't remove it from the mac_addrs
list. As a result, one MAC address occupies two entries in the list. Like:
add(MAC1)
add(MAC2)
add(MAC3)
add(MAC4)
set_default(MAC3)
default=MAC3, the rest of the list=MAC1, MAC2, MAC3, MAC4
Note: MAC3 occupies two entries.

In addition, some PMDs, such as i40e, ice, hns3 and so on, do remove the
old default MAC when set default MAC. If user continues to do
set_default(MAC5), and the mac_addrs list is default=MAC5, filters=(MAC1,
MAC2, MAC3, MAC4). At this moment, user can still see MAC3 from the list,
but packets with MAC3 aren't actually received by the PMD.

So need to ensure that the new default address is removed from the rest of
the list if the address was already in the list.

Fixes: 854d8ad4ef68 ("ethdev: add default mac address modifier")
Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
Acked-by: Chengwen Feng 
---
v8: fix some comments.
v7: add announcement in the release notes and document this behavior.
v6: fix commit log and some code comments.
v5:
  - merge the second patch into the first patch.
  - add error log when rollback failed.
v4:
   - fix broken in the patchwork
v3:
   - first explicitly remove the non-default MAC, then set default one.
   - document default and non-default MAC address
v2:
   - fixed commit log.
---
  doc/guides/rel_notes/release_23_03.rst |  6 +
  lib/ethdev/ethdev_driver.h |  6 -
  lib/ethdev/rte_ethdev.c| 35 --
  lib/ethdev/rte_ethdev.h|  3 +++
  4 files changed, 47 insertions(+), 3 deletions(-)

diff --git a/doc/guides/rel_notes/release_23_03.rst 
b/doc/guides/rel_notes/release_23_03.rst
index 84b112a8b1..1c9b9912c2 100644
--- a/doc/guides/rel_notes/release_23_03.rst
+++ b/doc/guides/rel_notes/release_23_03.rst
@@ -105,6 +105,12 @@ API Changes
 Also, make sure to start the actual text at the margin.
 ===
  
+* ethdev: ensured all entries in MAC address list are uniques.

+  When setting a default MAC address with the function
+  ``rte_eth_dev_default_mac_addr_set``,
+  the address is now removed from the rest of the address list
+  in order to ensure it is only at index 0 of the list.
+
  
  ABI Changes

  ---
diff --git a/lib/ethdev/ethdev_driver.h b/lib/ethdev/ethdev_driver.h
index dde3ec84ef..3994c61b86 100644
--- a/lib/ethdev/ethdev_driver.h
+++ b/lib/ethdev/ethdev_driver.h
@@ -117,7 +117,11 @@ struct rte_eth_dev_data {
  
  	uint64_t rx_mbuf_alloc_failed; /**< Rx ring mbuf allocation failures */
  
-	/** Device Ethernet link address. @see rte_eth_dev_release_port() */

+   /**
+* Device Ethernet link addresses.
+* All entries are unique.
+* The first entry (index zero) is the default address.
+*/
struct rte_ether_addr *mac_addrs;
/** Bitmap associating MAC addresses to pools */
uint64_t mac_pool_sel[RTE_ETH_NUM_RECEIVE_MAC_ADDR];
diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index 86ca303ab5..de25183619 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -4498,7 +4498,10 @@ rte_eth_dev_mac_addr_remove(uint16_t port_id, struct 
rte_ether_addr *addr)
  int
  rte_eth_dev_default_mac_addr_set(uint16_t port_id, struct rte_ether_addr 
*addr)
  {
+   uint64_t mac_pool_sel_bk = 0;
struct rte_eth_dev *dev;
+   uint32_t pool;
+   int index;
int ret;
  
  	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);

@@ -4517,16 +4520,44 @@ rte_eth_dev_default_mac_addr_set(uint16_t port_id, 
struct rte_ether_addr *addr)
if (*dev->dev_ops->mac_addr_set == NULL)
return -ENOTSUP;
  
+	/* Keep address unique in dev->data->mac_addrs[]. */

+   index = eth_dev_get_mac_addr_index(port_id, addr);
+   if (index > 0) {
+   /* Remove address in dev data structure */
+   mac_pool_sel_bk = dev->data->mac_pool_sel[index];
+   ret = rte_eth_dev_mac_addr_remove(port_id, addr);
+   if (ret < 0) {
+   RTE_ETHDEV_LOG(ERR, "Cannot remove the port %u address from 
the rest of list.\n",
+  port_id);
+   return ret;
+   }
+   }
ret = (*dev->dev_ops->mac_addr_set)(dev, addr);
if (ret < 0)
-   return ret;
+   goto out;
  
  	/* Update default address in NIC data structure */

rte_ether_addr_copy(addr, &dev->data->mac_addrs[0]);
  
  	return 0;

-}
  
+out:

+   if (index > 0) {
+   pool = 0;
+

RE: [v1, 1/3] cryptodev: add SM2 asymmetric crypto algorithm

[Akhil Goyal]

> Subject: [v1, 1/3] cryptodev: add SM2 asymmetric crypto algorithm
> 
> ShangMi 2 (SM2) is a encryption and digital signatture algorithm
> used in the Chinese National Standard.

ShangMi 2 (SM2) is an encryption and digital signature algorithm
used in the Chinese National Standard.
Added support for asymmetric SM2 in cryptodev along with prime field curve.

Can you also add link for RFC in patch description here as it is mentioned in 
the
comments of the structure.

> 
> Signed-off-by: Gowrishankar Muthukrishnan 
> ---
>  doc/guides/cryptodevs/features/default.ini |  1 +
>  doc/guides/rel_notes/release_23_07.rst |  3 +
>  lib/cryptodev/rte_crypto_asym.h| 76 ++
>  lib/cryptodev/rte_cryptodev.c  |  1 +
>  4 files changed, 81 insertions(+)
> 
> diff --git a/doc/guides/cryptodevs/features/default.ini
> b/doc/guides/cryptodevs/features/default.ini
> index 523da0cfa8..a69967bb9e 100644
> --- a/doc/guides/cryptodevs/features/default.ini
> +++ b/doc/guides/cryptodevs/features/default.ini
> @@ -125,6 +125,7 @@ Diffie-hellman  =
>  ECDSA   =
>  ECPM=
>  ECDH=
> +SM2 =
> 
>  ;
>  ; Supported Operating systems of a default crypto driver.
> diff --git a/doc/guides/rel_notes/release_23_07.rst
> b/doc/guides/rel_notes/release_23_07.rst
> index a9b1293689..b920840038 100644
> --- a/doc/guides/rel_notes/release_23_07.rst
> +++ b/doc/guides/rel_notes/release_23_07.rst
> @@ -55,6 +55,9 @@ New Features
>   Also, make sure to start the actual text at the margin.
>   ===
> 
> +* **Added SM2 algorithm in cryptodev library.**
> +
> +  Added SM2 algorithm with prime field curve support.

* **Added SM2 asymmetric algorithm in cryptodev.**

Added support for ShamMi 2 (SM2) asymmetric crypto algorithm
along with prime field curve support.

> 
>  Removed Items
>  -
> diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
> index 989f38323f..c91a8dee4d 100644
> --- a/lib/cryptodev/rte_crypto_asym.h
> +++ b/lib/cryptodev/rte_crypto_asym.h
> @@ -119,6 +119,8 @@ enum rte_crypto_asym_xform_type {
>   /**< Elliptic Curve Point Multiplication */
>   RTE_CRYPTO_ASYM_XFORM_ECFPM,
>   /**< Elliptic Curve Fixed Point Multiplication */
> + RTE_CRYPTO_ASYM_XFORM_SM2,
> + /**< ShangMi 2. Performs Encrypt, Decrypt, Sign and Verify. */

/**< ShangMi 2. 
  * Performs Encrypt, Decrypt, Sign and Verify.
  * Refer to rte_crypto_asym_op_type.
  */

>   RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
>   /**< End of list */
>  };
> @@ -382,6 +384,20 @@ struct rte_crypto_ec_xform {
>   /**< Pre-defined ec groups */
>  };
> 
> +/**
> + * Asymmetric SM2 transform data
> + *
> + * Structure describing SM2 xform params
> + *
> + */
> +struct rte_crypto_sm2_xform {
> + rte_crypto_uint pkey;
> + /**< Private key of the signer for signature generation */
> +
> + struct rte_crypto_ec_point q;
> + /**< Public key of the signer for verification */

Please add dots at end of sentences.

> +};
> +
>  /**
>   * Operations params for modular operations:
>   * exponentiation and multiplicative inverse
> @@ -637,9 +653,68 @@ struct rte_crypto_asym_xform {
>   /**< EC xform parameters, used by elliptic curve based
>* operations.
>*/
> +
> + struct rte_crypto_sm2_xform sm2;
> + /**< SM2 xform parameters */
>   };
>  };
> 
> +/**
> + * SM2 operation params
> + */
> +struct rte_crypto_sm2_op_param {
> + enum rte_crypto_asym_op_type op_type;
> + /**< Signature generation or verification */
> +
> + rte_crypto_param message;
> + /**<
> +  * Pointer to input data
> +  * - to be encrypted for SM2 public encrypt.
> +  * - to be signed for SM2 sign generation.
> +  * - to be authenticated for SM2 sign verification.
> +  *
> +  * Pointer to output data
> +  * - for SM2 private decrypt.
> +  * In this case the underlying array should have been
> +  * allocated with enough memory to hold plaintext output
> +  * (atleast encrypted text length). The message.length field
> +  * will be overwritten by the PMD with the decrypted length.
> +  */
> +
> + rte_crypto_param cipher;
> + /**<
> +  * Pointer to input data
> +  * - to be decrypted for SM2 private decrypt.
> +  *
> +  * Pointer to output data
> +  * - for SM2 public encrypt.
> +  * In this case the underlying array should have been allocated
> +  * with enough memory to hold ciphertext output (atleast X bytes
> +  * for prime field curve of N bytes and for message M bytes,
> +  * where X = (C1 + C2 + C3) and computed based on SM2 RFC as
> +  * C1 (1 + N + N), C2 = M, C3 = N. The cipher.length field will
> +  * be overwritten by the PMD with the encrypted length.
> +  */
> +
> + rte_

[PATCH] app/testpmd: fix segment fault with invalid queue id

[Dengdui Huang]

When input queue id is invalid, it will lead to
Segmentation fault, like:

dpdk-testpmd -a :01:00.0 -- -i
testpmd> show port 0 txq/rxq 99 desc 0 status
Segmentation fault

dpdk-testpmd -a :01:00.0 -- -i
testpmd> show port 0 rxq 99 desc used count
Segmentation fault

This patch fixes it.

In addition, this patch add the check for the offset
of the descriptor in case of other anomalies.

Fixes: fae9aa717d6c ("app/testpmd: support checking descriptor status")
Fixes: 3f9acb5c83bb ("ethdev: avoid non-dataplane checks in Rx queue count")
Cc: sta...@dpdk.org

Signed-off-by: Dengdui Huang 
---
 app/test-pmd/cmdline.c | 50 --
 1 file changed, 43 insertions(+), 7 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 7b20bef4e9..624752c320 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -12273,14 +12273,27 @@ cmd_show_rx_tx_desc_status_parsed(void *parsed_result,
__rte_unused void *data)
 {
struct cmd_show_rx_tx_desc_status_result *res = parsed_result;
+   struct rte_eth_rxq_info rxq_info;
+   struct rte_eth_txq_info txq_info;
int rc;
 
-   if (!rte_eth_dev_is_valid_port(res->cmd_pid)) {
-   fprintf(stderr, "invalid port id %u\n", res->cmd_pid);
-   return;
-   }
-
if (!strcmp(res->cmd_keyword, "rxq")) {
+   if (rte_eth_rx_queue_info_get(res->cmd_pid, res->cmd_qid, 
&rxq_info)) {
+   fprintf(stderr, "Failed to get port %u Rx queue %u 
info\n",
+   res->cmd_pid, res->cmd_qid);
+   return;
+   }
+
+   if (rxq_info.queue_state != RTE_ETH_QUEUE_STATE_STARTED) {
+   fprintf(stderr, "Rx queue %u not started\n", 
res->cmd_qid);
+   return;
+   }
+
+   if (res->cmd_did >= rxq_info.nb_desc) {
+   fprintf(stderr, "Invalid desc id %u\n", res->cmd_did);
+   return;
+   }
+
rc = rte_eth_rx_descriptor_status(res->cmd_pid, res->cmd_qid,
 res->cmd_did);
if (rc < 0) {
@@ -12296,6 +12309,22 @@ cmd_show_rx_tx_desc_status_parsed(void *parsed_result,
else
printf("Desc status = UNAVAILABLE\n");
} else if (!strcmp(res->cmd_keyword, "txq")) {
+   if (rte_eth_tx_queue_info_get(res->cmd_pid, res->cmd_qid, 
&txq_info)) {
+   fprintf(stderr, "Failed to get port %u Tx queue %u 
info\n",
+   res->cmd_pid, res->cmd_qid);
+   return;
+   }
+
+   if (txq_info.queue_state != RTE_ETH_QUEUE_STATE_STARTED) {
+   fprintf(stderr, "Tx queue %u not started\n", 
res->cmd_qid);
+   return;
+   }
+
+   if (res->cmd_did >= txq_info.nb_desc) {
+   fprintf(stderr, "Invalid desc id %u\n", res->cmd_did);
+   return;
+   }
+
rc = rte_eth_tx_descriptor_status(res->cmd_pid, res->cmd_qid,
 res->cmd_did);
if (rc < 0) {
@@ -12373,10 +12402,17 @@ cmd_show_rx_queue_desc_used_count_parsed(void 
*parsed_result,
__rte_unused void *data)
 {
struct cmd_show_rx_queue_desc_used_count_result *res = parsed_result;
+   struct rte_eth_rxq_info rxq_info;
int rc;
 
-   if (!rte_eth_dev_is_valid_port(res->cmd_pid)) {
-   fprintf(stderr, "invalid port id %u\n", res->cmd_pid);
+   if (rte_eth_rx_queue_info_get(res->cmd_pid, res->cmd_qid, &rxq_info)) {
+   fprintf(stderr, "Failed to get port %u Rx queue %u info\n",
+   res->cmd_pid, res->cmd_qid);
+   return;
+   }
+
+   if (rxq_info.queue_state != RTE_ETH_QUEUE_STATE_STARTED) {
+   fprintf(stderr, "Rx queue %u not started\n", res->cmd_qid);
return;
}
 
-- 
2.33.0

Re: [PATCH v2 3/3] vhost: add device op to offload the interrupt kick

[Eelco Chaudron]

On 16 May 2023, at 13:45, Maxime Coquelin wrote:

> On 5/16/23 13:36, Eelco Chaudron wrote:
>>
>>
>> On 16 May 2023, at 12:12, David Marchand wrote:
>>
>>> On Tue, May 16, 2023 at 10:53 AM Eelco Chaudron  wrote:
 On 10 May 2023, at 13:44, David Marchand wrote:
>>>
>>> [snip]
>>>
>> @@ -846,6 +848,14 @@ vhost_user_socket_mem_free(struct vhost_user_socket 
>> *vsocket)
>>  vsocket->path = NULL;
>>  }
>>
>> +   if (vsocket && vsocket->alloc_notify_ops) {
>> +#pragma GCC diagnostic push
>> +#pragma GCC diagnostic ignored "-Wcast-qual"
>> +   free((struct rte_vhost_device_ops *)vsocket->notify_ops);
>> +#pragma GCC diagnostic pop
>> +   vsocket->notify_ops = NULL;
>> +   }
>
> Rather than select the behavior based on a boolean (and here force the
> compiler to close its eyes), I would instead add a non const pointer
> to ops (let's say alloc_notify_ops) in vhost_user_socket.
> The code can then unconditionnally call free(vsocket->alloc_notify_ops);

 Good idea, I will make the change in v3.
>>>
>>> Feel free to use a better name for this field :-).
>>>

>> +
>>  if (vsocket) {
>>  free(vsocket);
>>  vsocket = NULL;
>>>
>>> [snip]
>>>
>> +   /*
>> +* Although the ops structure is a const structure, we do need to
>> +* override the guest_notify operation. This is because with the
>> +* previous APIs it was "reserved" and if any garbage value was 
>> passed,
>> +* it could crash the application.
>> +*/
>> +   if (ops && !ops->guest_notify) {
>
> Hum, as described in the comment above, I don't think we should look
> at ops->guest_notify value at all.
> Checking ops != NULL should be enough.

 Not sure I get you here. If the guest_notify passed by the user is NULL, 
 it means the previously ‘reserved[1]’ field is NULL, so we do not need to 
 use a new structure.

 I guess your comment would be true if we would introduce a new field in 
 the data structure, not replacing a reserved one.
>>>
>>> Hum, I don't understand my comment either o_O'.
>>> Too many days off... or maybe my evil twin took over the keyboard.
>>>
>>>

>> +   struct rte_vhost_device_ops *new_ops;
>> +
>> +   new_ops = malloc(sizeof(*new_ops));
>
> Strictly speaking, we lose the numa affinity of "ops" by calling malloc.
> I am unclear of the impact though.

 Don’t think there is a portable API that we can use to determine the NUMA 
 for the ops memory and then allocate this on the same numa?

 Any thoughts or ideas on how to solve this? I hope most people will 
 memset() the ops structure and the reserved[1] part is zero, but it might 
 be a problem in the future if more extensions get added.
>>>
>>> Determinining current numa is doable, via 'ops'
>>> get_mempolicy(MPOL_F_NODE | MPOL_F_ADDR), like what is done for vq in
>>> numa_realloc().
>>> The problem is how to allocate on this numa with the libc allocator
>>> for which I have no idea...
>>> We could go with the dpdk allocator (again, like numa_realloc()).
>>>
>>>
>>> In practice, the passed ops will be probably from a const variable in
>>> the program .data section (for which I think fields are set to 0
>>> unless explicitly initialised), or a memset() will be called for a
>>> dynamic allocation from good citizens.
>>> So we can probably live with the current proposal.
>>> Plus, this is only for one release, since in 23.11 with the ABI bump,
>>> we will drop this compat code.
>>>
>>> Maxime, Chenbo, what do you think?
>>
>> Wait for their response, but for now I assume we can just keep the numa 
>> unaware malloc().
>
> Let's keep it as is as we'll get rid of it in 23.11.

Thanks for confirming.

>>>
>>> [snip]
>>>
>
> But putting indentation aside, is this change equivalent?
> -   if ((vhost_need_event(vhost_used_event(vq), new, old) &&
> -   (vq->callfd >= 0)) ||
> -   unlikely(!signalled_used_valid)) {
> +   if ((vhost_need_event(vhost_used_event(vq), new, old) ||
> +   unlikely(!signalled_used_valid)) &&
> +   vq->callfd >= 0) {

 They are not equal, but in the past eventfd_write() should also not have 
 been called with callfd < 0, guess this was an existing bug ;)
>>>
>>> I think this should be a separate fix.
>>
>> ACK, will add a separate patch in this series to fix it.
>
> I also caught & fixed it while implementing my VDUSE series [0].
> You can pick it in your series, and I will rebase my series on top of
> it.

Thanks for the details I’ll include your patch in my series.

I will send out a new revision s

RE: [v1, 2/3] test/test_cryptodev_asym: add SM2 tests

[Akhil Goyal]

Hi Gowri,

> Subject: [v1, 2/3] test/test_cryptodev_asym: add SM2 tests
> 

Title should be
test/crypto: add asymmetric SM2 cases

> Add SM2 tests.

Added test cases and test vectors for asymmetric SM2 crypto verification.
Cases are added for sign/verify/encrypt/decrypt.

If you have the reference from where the vectors are taken it can also be 
mentioned.

> 
> Signed-off-by: Gowrishankar Muthukrishnan 
> ---
>  app/test/test_cryptodev_asym.c | 506 +
>  app/test/test_cryptodev_sm2_test_vectors.h | 120 +
>  2 files changed, 626 insertions(+)
>  create mode 100644 app/test/test_cryptodev_sm2_test_vectors.h
> 
> diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
> index 9236817650..bfaeedee27 100644
> --- a/app/test/test_cryptodev_asym.c
> +++ b/app/test/test_cryptodev_asym.c
> @@ -21,6 +21,7 @@
>  #include "test_cryptodev_ecpm_test_vectors.h"
>  #include "test_cryptodev_mod_test_vectors.h"
>  #include "test_cryptodev_rsa_test_vectors.h"
> +#include "test_cryptodev_sm2_test_vectors.h"
>  #include "test_cryptodev_asym_util.h"
>  #include "test.h"
> 
> @@ -2196,6 +2197,507 @@ test_ecpm_all_curve(void)
>   return overall_status;
>  }
> 
> +static int
> +test_sm2_sign(void)
> +{
> + struct crypto_testsuite_params_asym *ts_params = &testsuite_params;
> + struct crypto_testsuite_sm2_params input_params =
> sm2_param_fp256;
> + struct rte_mempool *sess_mpool = ts_params->session_mpool;
> + struct rte_mempool *op_mpool = ts_params->op_mpool;
> + uint8_t dev_id = ts_params->valid_devs[0];
> + struct rte_crypto_op *result_op = NULL;
> + uint8_t output_buf_r[TEST_DATA_SIZE];
> + uint8_t output_buf_s[TEST_DATA_SIZE];
> + struct rte_crypto_asym_xform xform;
> + struct rte_crypto_asym_op *asym_op;
> + struct rte_cryptodev_info dev_info;
> + struct rte_crypto_op *op = NULL;
> + int ret, status = TEST_SUCCESS;
> + void *sess = NULL;
> +
> + rte_cryptodev_info_get(dev_id, &dev_info);

dev_info is being unused. Not checking for capabilities?
> +
> + /* Setup crypto op data structure */
> + op = rte_crypto_op_alloc(op_mpool,
> RTE_CRYPTO_OP_TYPE_ASYMMETRIC);
> + if (op == NULL) {
> + RTE_LOG(ERR, USER1,
> + "line %u FAILED: %s", __LINE__,
> + "Failed to allocate asymmetric crypto "
> + "operation struct\n");
> + status = TEST_FAILED;
> + goto exit;
> + }
> + asym_op = op->asym;
> +
> + /* Setup asym xform */
> + xform.next = NULL;
> + xform.xform_type = RTE_CRYPTO_ASYM_XFORM_SM2;
> + xform.sm2.pkey.data = input_params.pkey.data;
> + xform.sm2.pkey.length = input_params.pkey.length;
> + xform.sm2.q.x.data = input_params.pubkey_qx.data;
> + xform.sm2.q.x.length = input_params.pubkey_qx.length;
> + xform.sm2.q.y.data = input_params.pubkey_qy.data;
> + xform.sm2.q.y.length = input_params.pubkey_qy.length;
> +
> + ret = rte_cryptodev_asym_session_create(dev_id, &xform, sess_mpool,
> &sess);
> + if (ret < 0) {
> + RTE_LOG(ERR, USER1,
> + "line %u FAILED: %s", __LINE__,
> + "Session creation failed\n");
> + status = (ret == -ENOTSUP) ? TEST_SKIPPED : TEST_FAILED;
> + goto exit;
> + }
> +
> + /* Attach asymmetric crypto session to crypto operations */
> + rte_crypto_op_attach_asym_session(op, sess);
> +
> + /* Compute sign */
> +
> + /* Populate op with operational details */
> + op->asym->sm2.op_type = RTE_CRYPTO_ASYM_OP_SIGN;
> + op->asym->sm2.message.data = input_params.message.data;
> + op->asym->sm2.message.length = input_params.message.length;
> + op->asym->sm2.id.data = input_params.id.data;
> + op->asym->sm2.id.length = input_params.id.length;
> +
> + /* Init out buf */
> + op->asym->sm2.r.data = output_buf_r;
> + op->asym->sm2.s.data = output_buf_s;
> +
> + RTE_LOG(DEBUG, USER1, "Process ASYM operation\n");
> +
> + /* Process crypto operation */
> + if (rte_cryptodev_enqueue_burst(dev_id, 0, &op, 1) != 1) {
> + RTE_LOG(ERR, USER1,
> + "line %u FAILED: %s", __LINE__,
> + "Error sending packet for operation\n");
> + status = TEST_FAILED;
> + goto exit;
> + }
> +
> + while (rte_cryptodev_dequeue_burst(dev_id, 0, &result_op, 1) == 0)
> + rte_pause();

Shouldn't this be a finite loop and mark test as failed after some retries?

> +
> + if (result_op == NULL) {
> + RTE_LOG(ERR, USER1,
> + "line %u FAILED: %s", __LINE__,
> + "Failed to process asym crypto op\n");
> + status = TEST_FAILED;
> + goto exit;
> + }
> +
> + if (result_op->status != RTE_CRYPTO_OP_STATUS_S

RE: [v1, 3/3] crypto/openssl: add SM2 asymmetric crypto support

[Akhil Goyal]

Hi Kai,

Can you review this?

> Subject: [v1, 3/3] crypto/openssl: add SM2 asymmetric crypto support
> 
> Add SM2 asymmetric algorithm support in openssl PMD.
> 
> Signed-off-by: Gowrishankar Muthukrishnan 

[PATCH] eal: fix eal init may failed when too much continuous memsegs under legacy mode

[Fengnan Chang]

Under legacy mode, if the number of continuous memsegs greater
than RTE_MAX_MEMSEG_PER_LIST, eal init will failed even though
another memseg list is empty, because only one memseg list used
to check in remap_needed_hugepages.

For example:
hugepage configure:
20480
13370
7110

startup log:
EAL: Detected memory type: socket_id:0 hugepage_sz:2097152
EAL: Detected memory type: socket_id:1 hugepage_sz:2097152
EAL: Creating 4 segment lists: n_segs:8192 socket_id:0 hugepage_sz:2097152
EAL: Creating 4 segment lists: n_segs:8192 socket_id:1 hugepage_sz:2097152
EAL: Requesting 13370 pages of size 2MB from socket 0
EAL: Requesting 7110 pages of size 2MB from socket 1
EAL: Attempting to map 14220M on socket 1
EAL: Allocated 14220M on socket 1
EAL: Attempting to map 26740M on socket 0
EAL: Could not find space for memseg. Please increase 32768 and/or 65536 in
configuration.
EAL: Couldn't remap hugepage files into memseg lists
EAL: FATAL: Cannot init memory
EAL: Cannot init memory

Signed-off-by: Fengnan Chang 
Signed-off-by: Lin Li 
---
 lib/eal/linux/eal_memory.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/eal/linux/eal_memory.c b/lib/eal/linux/eal_memory.c
index 60fc8cc6ca..36b9e78f5f 100644
--- a/lib/eal/linux/eal_memory.c
+++ b/lib/eal/linux/eal_memory.c
@@ -1001,6 +1001,8 @@ remap_needed_hugepages(struct hugepage_file *hugepages, 
int n_pages)
if (cur->size == 0)
break;
 
+   if (cur_page - seg_start_page >= RTE_MAX_MEMSEG_PER_LIST)
+   new_memseg = 1;
if (cur_page == 0)
new_memseg = 1;
else if (cur->socket_id != prev->socket_id)
-- 
2.37.1 (Apple Git-137.1)

RE: [EXT] [PATCH 0/8] add AESNI_MB optimisations

[Akhil Goyal]

Hi Kai,

Can you review?

Does it need updates to documentation for intel-ipsec-mb versions?

> This patchset adds some optimisations for AESNI_MB PMD, many based on
> features that are available in intel-ipsec-mb v1.3 and future release v1.4.
> 
> Marcel Cornu (1):
>   crypto/ipsec_mb: use burst API in aesni_mb
> 
> Pablo de Lara (7):
>   crypto/ipsec_mb: use GMAC dedicated algorithms
>   crypto/ipsec_mb: use new SGL API
>   crypto/ipsec_mb: remove unneeded fields in crypto session
>   crypto/ipsec_mb: store template job
>   crypto/ipsec_mb: optimize for GCM case
>   crypto/ipsec_mb: do not free linear_sgl always
>   crypto/ipsec_mb: set and use session ID
> 
>  drivers/crypto/ipsec_mb/pmd_aesni_mb.c  | 915 
>  drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h |  32 +-
>  2 files changed, 584 insertions(+), 363 deletions(-)
> 
> --
> 2.25.1

RE: [EXT] [PATCH 0/8] add AESNI_MB optimisations

[Power, Ciara]

Hi Akhil,

> -Original Message-
> From: Akhil Goyal 
> Sent: Tuesday 16 May 2023 13:26
> To: Power, Ciara ; dev@dpdk.org
> Cc: Ji, Kai 
> Subject: RE: [EXT] [PATCH 0/8] add AESNI_MB optimisations
> 
> Hi Kai,
> 
> Can you review?
FYI I will be sending a v2 patchset later today, to address CI compilation 
error.

> 
> Does it need updates to documentation for intel-ipsec-mb versions?

Not for now.
Most of the changes are for version <= 1.3.
One change (session ID stuff) is in 1.4, which will be released soon, before 
our 23.07 release.
We plan to update the documentation to show the support once we have the link 
to the 1.4 release.

Thanks,
Ciara


> 
> > This patchset adds some optimisations for AESNI_MB PMD, many based on
> > features that are available in intel-ipsec-mb v1.3 and future release v1.4.
> >
> > Marcel Cornu (1):
> >   crypto/ipsec_mb: use burst API in aesni_mb
> >
> > Pablo de Lara (7):
> >   crypto/ipsec_mb: use GMAC dedicated algorithms
> >   crypto/ipsec_mb: use new SGL API
> >   crypto/ipsec_mb: remove unneeded fields in crypto session
> >   crypto/ipsec_mb: store template job
> >   crypto/ipsec_mb: optimize for GCM case
> >   crypto/ipsec_mb: do not free linear_sgl always
> >   crypto/ipsec_mb: set and use session ID
> >
> >  drivers/crypto/ipsec_mb/pmd_aesni_mb.c  | 915 
> >  drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h |  32 +-
> >  2 files changed, 584 insertions(+), 363 deletions(-)
> >
> > --
> > 2.25.1

Re: [PATCH v3] eventdev: avoid non-burst shortcut for variable-size bursts

[Jerin Jacob]

On Tue, May 16, 2023 at 2:22 AM Mattias Rönnblom  wrote:
>
> On 2023-05-15 14:38, Jerin Jacob wrote:
> > On Fri, May 12, 2023 at 6:45 PM Mattias Rönnblom
> >  wrote:
> >>
> >> On 2023-05-12 13:59, Jerin Jacob wrote:
> >>> On Thu, May 11, 2023 at 2:00 PM Mattias Rönnblom
> >>>  wrote:
> 
>  Use non-burst event enqueue and dequeue calls from burst enqueue and
>  dequeue only when the burst size is compile-time constant (and equal
>  to one).
> 
>  Signed-off-by: Mattias Rönnblom 
> 
>  ---
> 
>  v3: Actually include the change v2 claimed to contain.
>  v2: Wrap builtin call in __extension__, to avoid compiler warnings if
>    application is compiled with -pedantic. (Morten Brørup)
>  ---
> lib/eventdev/rte_eventdev.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
>  diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h
>  index a90e23ac8b..a471caeb6d 100644
>  --- a/lib/eventdev/rte_eventdev.h
>  +++ b/lib/eventdev/rte_eventdev.h
>  @@ -1944,7 +1944,7 @@ __rte_event_enqueue_burst(uint8_t dev_id, uint8_t 
>  port_id,
> * Allow zero cost non burst mode routine invocation if 
>  application
> * requests nb_events as const one
> */
>  -   if (nb_events == 1)
>  +   if (__extension__(__builtin_constant_p(nb_events)) && nb_events 
>  == 1)
> >>>
> >>> "Why" part is not clear from the commit message. Is this to avoid
> >>> nb_events read if it is built-in const.
> >>
> >> The __builtin_constant_p() is introduced to avoid having the compiler
> >> generate a conditional branch and two different code paths in case
> >> nb_elem is a run-time variable.
> >>
> >> In particular, this matters if nb_elems is run-time variable and varies
> >> between 1 and some larger value.
> >>
> >> I should have mention this in the commit message.
> >>
> >> A very slight performance improvement. It also makes the code better
> >> match the comment, imo. Zero cost for const one enqueues, but no impact
> >> non-compile-time-constant-length enqueues.
> >>
> >> Feel free to ignore.
> >
> >
> > I did some performance comparison of the patch.
> > A low-end ARM machines shows 0.7%  drop with single event case. No
> > regression see with high-end ARM cores with single event case.
> >
> > IMO, optimizing the check for burst mode(the new patch) may not show
> > any real improvement as the cost is divided by number of event.
> > Whereas optimizing the check for single event case(The current code)
> > shows better performance with single event case and no regression
> > with burst mode as cost is divided by number of events.
>
> I ran some tests on an AMD Zen 3 with DSW.
> In the below tests the enqueue burst size is not compile-time constant.
>
> Enqueue burst size  Performance improvement
> Run-time constant 1 ~5%
> Run-time constant 2 ~0%
> Run-time variable 1-2   ~9%
> Run-time variable 1-16  ~0%
>
> The run-time variable enqueue sizes randomly (uniformly) distributed in
> the specified range.
>
> The first result may come as a surprise. The benchmark is using
> RTE_EVENT_OP_FORWARD type events (which likely is the dominating op type
> in most apps). The single-event enqueue function only exists in a
> generic variant (i.e., no rte_event_enqueue_forward_burst() equivalent).
> I suspect that is the reason for the performance improvement.
>
> This effect is large-enough to make it somewhat beneficial (+~1%) to use
> run-time variable single-event enqueue compared to keeping the burst
> size compile-time constant.

# Interesting, Could you share your testeventdev command to test it.
# By having quick glance on DSW code, following change can be added(or
 similar cases).
Not sure such change in DSW driver is making a difference or nor?


diff --git a/drivers/event/dsw/dsw_event.c b/drivers/event/dsw/dsw_event.c
index e84b65d99f..455470997b 100644
--- a/drivers/event/dsw/dsw_event.c
+++ b/drivers/event/dsw/dsw_event.c
@@ -1251,7 +1251,7 @@ dsw_port_flush_out_buffers(struct dsw_evdev
*dsw, struct dsw_port *source_port)
 uint16_t
 dsw_event_enqueue(void *port, const struct rte_event *ev)
 {
-   return dsw_event_enqueue_burst(port, ev, unlikely(ev == NULL) ? 0 : 1);
+   return dsw_event_enqueue_burst(port, ev, 1);
 }

 static __rte_always_inline uint16_t
@@ -1340,7 +1340,7 @@ dsw_event_enqueue_burst_generic(struct dsw_port
*source_port,
return (num_non_release + num_release);
 }

-uint16_t
+inline uint16_t
 dsw_event_enqueue_burst(void *port, const struct rte_event events[],
uint16_t events_len)
 {

# I am testing with command like this "/build/app/dpdk-test-eventdev
-l 0-23 -a 0002:0e:00.0 -- --test=perf_atq --plcores 1 --wlcores 8
--stlist p --nb_pkts=100"

>
> The performance gain is counted toward both enqueue and dequeue costs
> (+benchmark app overhead), so an under-estimation if see this a

Re: [PATCH] Memory Allocation: Adding a new UT for fb_array

[Burakov, Anatoly]

Hi Vipin!

Thanks for all of the work on this bug, it is highly appreciated. Below 
are suggestions for improvements for this patch.


On 1/13/2023 1:12 PM, Vipin P R wrote:

add test case coverage to cover the ms_idx jump


This message could be expanded to be more informative. Suggested rewording:

test/fbarray: add test case for incorrect lookahead behavior



Cc: sta...@dpdk.org

Signed-off-by: Vipin P R 
Acked-by: Kumara Parameshwaran 
---
Depends-on: 0001-Memory-Allocation-Fixes-ms_idx-jump-lookahead-during.patch
Depends-on: 0002-Memory-Allocation-Fixes-ms_idx-jump-lookbehind-durin.patch


This makes no difference for commit, but for future reference: 
depends-on should reference link to actual patches, not a patch file name.



---
  app/test/test_fbarray.c | 49 +
  1 file changed, 49 insertions(+)

diff --git a/app/test/test_fbarray.c b/app/test/test_fbarray.c
index a691bf4..275449c 100644
--- a/app/test/test_fbarray.c
+++ b/app/test/test_fbarray.c
@@ -11,6 +11,7 @@
  #include 
  #include 
  #include 
+#include 


This is presumably added to get access to `struct rte_memseg`, but this 
is not needed, because the bug is in the mask behavior, which does not 
depend on specific data size.


  
  #include "test.h"
  
@@ -402,6 +403,53 @@ static int check_used_one(void)

return 0;
  }
  
+/* the following test case verifies that the jump in ms_idx for an fb-array is correct. */

+static int test_jump(void)
+{
+struct rte_fbarray test_array;
+int input[] = {1, 1070, 1, 2, 1, 2, 4, 12, 2, 2, 1, 2, 1};


I've managed to reduce this bug down to a more minimal example:

{ 63, 1, 2 }


+int ms_idx, prev_ms_idx, delta;
+int len;
+ms_idx = prev_ms_idx = 0;
+
+int ret = rte_fbarray_init(&test_array, "test", 32768, sizeof(struct 
rte_memseg));
+if (ret == 0) {
+RTE_LOG(DEBUG, EAL, "FB array init success\n");


If the code did an early exit, an additional indentation level could've 
been avoided, like so:


TEST_ASSERT(rte_fbarray_init(&test_array, "test", 256, 8) == 0,
"Failed to initialize fbarray\n");

Also, missing corresponding `rte_fbarray_destroy` call.


+int k = 0;


Seems like the only place where this is used is in find_next_n_free, and 
it never changes, so I don't think this variable is needed at all.



+for(int i=0; i < sizeof(input)/sizeof(int); i++) {


RTE_DIM? Also, array indices are `unsigned int` rather than `int`, 
compiler gives a warning.



+if (i == 0) {
+len = input[i];
+} else {
+len = input[i] + 1;
+}


All of this could be rewritten as follows:

int len, hole;

/* if this is not the first iteration, create a hole */
hole = i != 0;
len = input[i] + hole;


+prev_ms_idx = ms_idx;
+ms_idx = rte_fbarray_find_next_n_free(&test_array, k, len);


Like I said above, `k` is unneeded, we can just replace it with 0.


+
+if (i != 0) {
+ms_idx++;
+}


Given suggestion above, could use `if (hole)` instead, would be more 
readable.



+
+for (int j=0; j < input[i]; j++) {


Array indices are unsigned, and also could replace with

for (unsigned int j = hole; j < len; j++)

IMO would be more readable.


+RTE_LOG(DEBUG, EAL, "ms_idx:%d\n", ms_idx);


I don't think this log is needed.


+rte_fbarray_set_used(&test_array, ms_idx);
+ms_idx++;
+}
+
+if (prev_ms_idx) {
+/* The value of ms_idx should be monotonically increasing
+ * given the above input sequence in test_array.
+ * */
+delta = ms_idx - prev_ms_idx;
+if (!(delta > 0)) {


Given above suggestions, this can be replaced with `if (delta != len)`. 
Also, given the `TEST_ASSERT(0)` below, I think this could just be 
replaced with an assert and a message, e.g.


TEST_ASSERT(delta == len, "Incorrect fbarray index\n");

--
Thanks,
Anatoly

[PATCH] lib/mempool : rte_mempool_avail_count, fixing return bigger than mempool size

[Yasin CANER]

From: Yasin CANER 

after a while working rte_mempool_avail_count function returns bigger
than mempool size that cause miscalculation rte_mempool_in_use_count.

it helps to avoid miscalculation rte_mempool_in_use_count.

Bugzilla ID: 1229

Signed-off-by: Yasin CANER 
---
 lib/mempool/rte_mempool.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lib/mempool/rte_mempool.c b/lib/mempool/rte_mempool.c
index cf5dea2304..17ed1eb845 100644
--- a/lib/mempool/rte_mempool.c
+++ b/lib/mempool/rte_mempool.c
@@ -1009,8 +1009,11 @@ rte_mempool_avail_count(const struct rte_mempool *mp)
 
count = rte_mempool_ops_get_count(mp);
 
-   if (mp->cache_size == 0)
+   if (mp->cache_size == 0) {
+   if (count > mp->size)
+   return mp->size;
return count;
+   }
 
for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++)
count += mp->local_cache[lcore_id].len;
-- 
2.25.1

Re: [PATCH 1/2] Memory Allocation: Fixes ms_idx jump (lookahead) during find_next_n() in fb_array library

[Burakov, Anatoly]

Hi Vipin,

Fix looks good, took a while to understand what's going on, but it's a 
great find!


Reviewed-by: Anatoly Burakov 

Couple of comments below:

On 1/13/2023 1:08 PM, Vipin P R wrote:

In the legacy mem mode, when the fb_array is being populated, if there are 
holes in between, the ms_idx could go backward and there will be an overlap of 
the region starting from the ms_idx returned later. i.e. it's being mapped to 
two different physical regions in PA space to a contiguous region in VA space. 
this would result in the allocator assuming that the memory is contiguous even 
though there is a hole in between. In legacy mem, allocator assumes that PA 
contiguous are VA contiguous as well.


Technically, while this bug is indeed triggered in legacy mode, it does 
not in any way depend on it, so I would suggest avoid mentioning it 
explicitly.


Suggested commit message rewording:

fbarray: fix incorrect lookahead behavior

Currently, whenever last bit of current index mask is set (meaning, 
there is potentially a run starting at the end of the mask), lookahead 
loop is entered. In that loop, if the first bit of lookahead index is 
not set, the lookahead is stopped, and the current lookahead mask index 
is assigned to current index mask. However, because at that point we are 
inside a for-loop that increments current index mask after each 
iteration, this results in additional mask index increment.


Fix it to leave current index mask at `lookahead - 1`.

Fixes: c44d09811b40 ("eal: add shared indexed file-backed array")
Cc: anatoly.bura...@intel.com



Cc: sta...@dpdk.org

Signed-off-by: Vipin P R 
Acked-by: Kumara Parameshwaran 
---
  .mailmap| 1 +
  lib/eal/common/eal_common_fbarray.c | 2 +-
  2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/.mailmap b/.mailmap
index 75884b6..3707bf5 100644
--- a/.mailmap
+++ b/.mailmap
@@ -1391,6 +1391,7 @@ Vincent Guo 
  Vincent Jardin 
  Vincent Li 
  Vincent S. Cojot 
+Vipin P R  
  Vipin Varghese  
  Vipul Ashri 
  Vishal Kulkarni 
diff --git a/lib/eal/common/eal_common_fbarray.c 
b/lib/eal/common/eal_common_fbarray.c
index f11f879..551bd87 100644
--- a/lib/eal/common/eal_common_fbarray.c
+++ b/lib/eal/common/eal_common_fbarray.c
@@ -236,7 +236,7 @@ find_next_n(const struct rte_fbarray *arr, unsigned int 
start, unsigned int n,
 * as well, so skip that on next iteration.
 */
ignore_msk = ~((1ULL << need) - 1);
-   msk_idx = lookahead_idx;
+   msk_idx = lookahead_idx - 1;
break;
}
  


--
Thanks,
Anatoly

RE: [PATCH v2 01/22] net: add PDCP header

[Akhil Goyal]

> Subject: [PATCH v2 01/22] net: add PDCP header
> 
> From: Volodymyr Fialko 
> 
> Add PDCP protocol header to be used for supporting PDCP protocol
> processing.
> 
> Signed-off-by: Anoob Joseph 
> Signed-off-by: Kiran Kumar K 
> Signed-off-by: Volodymyr Fialko 
> ---
Acked-by: Akhil Goyal 

Re: [PATCH V8] ethdev: fix one address occupies two entries in MAC addrs

[Ferruh Yigit]

On 5/16/2023 12:47 PM, lihuisong (C) wrote:
> Hi Ferruh,
> 
> There is no result on techboard.
> How to deal with this problem next?

+techboard for comment.


Btw, what was your positioning to Bruce's suggestion,
when a MAC address is in the list, fail to set it as default and enforce
user do the corrective action (delete MAC explicitly etc...).
If you are OK with it, that is good for me too, unless techboard objects
we can proceed with that one.


> 
> /Huisong
> 
> 在 2023/2/2 20:36, Huisong Li 写道:
>> The dev->data->mac_addrs[0] will be changed to a new MAC address when
>> applications modify the default MAC address by .mac_addr_set(). However,
>> if the new default one has been added as a non-default MAC address by
>> .mac_addr_add(), the .mac_addr_set() doesn't remove it from the mac_addrs
>> list. As a result, one MAC address occupies two entries in the list.
>> Like:
>> add(MAC1)
>> add(MAC2)
>> add(MAC3)
>> add(MAC4)
>> set_default(MAC3)
>> default=MAC3, the rest of the list=MAC1, MAC2, MAC3, MAC4
>> Note: MAC3 occupies two entries.
>>
>> In addition, some PMDs, such as i40e, ice, hns3 and so on, do remove the
>> old default MAC when set default MAC. If user continues to do
>> set_default(MAC5), and the mac_addrs list is default=MAC5, filters=(MAC1,
>> MAC2, MAC3, MAC4). At this moment, user can still see MAC3 from the list,
>> but packets with MAC3 aren't actually received by the PMD.
>>
>> So need to ensure that the new default address is removed from the
>> rest of
>> the list if the address was already in the list.
>>
>> Fixes: 854d8ad4ef68 ("ethdev: add default mac address modifier")
>> Cc: sta...@dpdk.org
>>
>> Signed-off-by: Huisong Li 
>> Acked-by: Chengwen Feng 
>> ---
>> v8: fix some comments.
>> v7: add announcement in the release notes and document this behavior.
>> v6: fix commit log and some code comments.
>> v5:
>>   - merge the second patch into the first patch.
>>   - add error log when rollback failed.
>> v4:
>>    - fix broken in the patchwork
>> v3:
>>    - first explicitly remove the non-default MAC, then set default one.
>>    - document default and non-default MAC address
>> v2:
>>    - fixed commit log.
>> ---
>>   doc/guides/rel_notes/release_23_03.rst |  6 +
>>   lib/ethdev/ethdev_driver.h |  6 -
>>   lib/ethdev/rte_ethdev.c    | 35 --
>>   lib/ethdev/rte_ethdev.h    |  3 +++
>>   4 files changed, 47 insertions(+), 3 deletions(-)
>>
>> diff --git a/doc/guides/rel_notes/release_23_03.rst
>> b/doc/guides/rel_notes/release_23_03.rst
>> index 84b112a8b1..1c9b9912c2 100644
>> --- a/doc/guides/rel_notes/release_23_03.rst
>> +++ b/doc/guides/rel_notes/release_23_03.rst
>> @@ -105,6 +105,12 @@ API Changes
>>  Also, make sure to start the actual text at the margin.
>>  ===
>>   +* ethdev: ensured all entries in MAC address list are uniques.
>> +  When setting a default MAC address with the function
>> +  ``rte_eth_dev_default_mac_addr_set``,
>> +  the address is now removed from the rest of the address list
>> +  in order to ensure it is only at index 0 of the list.
>> +
>>     ABI Changes
>>   ---
>> diff --git a/lib/ethdev/ethdev_driver.h b/lib/ethdev/ethdev_driver.h
>> index dde3ec84ef..3994c61b86 100644
>> --- a/lib/ethdev/ethdev_driver.h
>> +++ b/lib/ethdev/ethdev_driver.h
>> @@ -117,7 +117,11 @@ struct rte_eth_dev_data {
>>     uint64_t rx_mbuf_alloc_failed; /**< Rx ring mbuf allocation
>> failures */
>>   -    /** Device Ethernet link address. @see
>> rte_eth_dev_release_port() */
>> +    /**
>> + * Device Ethernet link addresses.
>> + * All entries are unique.
>> + * The first entry (index zero) is the default address.
>> + */
>>   struct rte_ether_addr *mac_addrs;
>>   /** Bitmap associating MAC addresses to pools */
>>   uint64_t mac_pool_sel[RTE_ETH_NUM_RECEIVE_MAC_ADDR];
>> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
>> index 86ca303ab5..de25183619 100644
>> --- a/lib/ethdev/rte_ethdev.c
>> +++ b/lib/ethdev/rte_ethdev.c
>> @@ -4498,7 +4498,10 @@ rte_eth_dev_mac_addr_remove(uint16_t port_id,
>> struct rte_ether_addr *addr)
>>   int
>>   rte_eth_dev_default_mac_addr_set(uint16_t port_id, struct
>> rte_ether_addr *addr)
>>   {
>> +    uint64_t mac_pool_sel_bk = 0;
>>   struct rte_eth_dev *dev;
>> +    uint32_t pool;
>> +    int index;
>>   int ret;
>>     RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
>> @@ -4517,16 +4520,44 @@ rte_eth_dev_default_mac_addr_set(uint16_t
>> port_id, struct rte_ether_addr *addr)
>>   if (*dev->dev_ops->mac_addr_set == NULL)
>>   return -ENOTSUP;
>>   +    /* Keep address unique in dev->data->mac_addrs[]. */
>> +    index = eth_dev_get_mac_addr_index(port_id, addr);
>> +    if (index > 0) {
>> +    /* Remove address in dev data structure */
>> +    mac_pool_sel_bk = dev->data->mac_pool_sel[index];
>> +    ret = rte_eth_de

Re: [PATCH 2/2] Memory Allocation: Fixes ms_idx jump (lookbehind) during find_prev_n() in fb_array library

[Burakov, Anatoly]

Hi Vipin,

This commit should include a more detailed commit message, akin to one I 
suggested for the first patch.


For the patch itself:

Reviewed-by: Anatoly Burakov 


On 1/13/2023 1:08 PM, Vipin P R wrote:

Cc: sta...@dpdk.org

Signed-off-by: Vipin P R 
Acked-by: Kumara Parameshwaran 
---
  lib/eal/common/eal_common_fbarray.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/eal/common/eal_common_fbarray.c 
b/lib/eal/common/eal_common_fbarray.c
index 551bd87..90240e8 100644
--- a/lib/eal/common/eal_common_fbarray.c
+++ b/lib/eal/common/eal_common_fbarray.c
@@ -511,7 +511,7 @@ find_prev_n(const struct rte_fbarray *arr, unsigned int 
start, unsigned int n,
 * as well, so skip that on next iteration.
 */
ignore_msk = UINT64_MAX << need;
-   msk_idx = lookbehind_idx;
+   msk_idx = lookbehind_idx + 1;
break;
}
  


The unit test code you suggested does not cover this case. I've reduced 
this bug to a minimal test case:


1. Allocate fbarray with 256 entries
2. Set idx 63 as used
3. Call rte_fbarray_find_prev_n_free() starting with index 64 and length 
of 2


Returned value should be 61, but without the fix it returns -1.

--
Thanks,
Anatoly

Re: [PATCH] Memory Allocation: Adding a new UT for fb_array

[Burakov, Anatoly]

On 5/16/2023 2:39 PM, Burakov, Anatoly wrote:

Hi Vipin!

Thanks for all of the work on this bug, it is highly appreciated. Below 
are suggestions for improvements for this patch.


On 1/13/2023 1:12 PM, Vipin P R wrote:

add test case coverage to cover the ms_idx jump


This message could be expanded to be more informative. Suggested rewording:

test/fbarray: add test case for incorrect lookahead behavior



Cc: sta...@dpdk.org

Signed-off-by: Vipin P R 
Acked-by: Kumara Parameshwaran 
---
Depends-on: 
0001-Memory-Allocation-Fixes-ms_idx-jump-lookahead-during.patch
Depends-on: 
0002-Memory-Allocation-Fixes-ms_idx-jump-lookbehind-durin.patch


This makes no difference for commit, but for future reference: 
depends-on should reference link to actual patches, not a patch file name.



---
  app/test/test_fbarray.c | 49 
+

  1 file changed, 49 insertions(+)

diff --git a/app/test/test_fbarray.c b/app/test/test_fbarray.c
index a691bf4..275449c 100644
--- a/app/test/test_fbarray.c
+++ b/app/test/test_fbarray.c
@@ -11,6 +11,7 @@
  #include 
  #include 
  #include 
+#include 


This is presumably added to get access to `struct rte_memseg`, but this 
is not needed, because the bug is in the mask behavior, which does not 
depend on specific data size.



  #include "test.h"
@@ -402,6 +403,53 @@ static int check_used_one(void)
  return 0;
  }
+/* the following test case verifies that the jump in ms_idx for an 
fb-array is correct. */

+static int test_jump(void)


I think the test functions would be better named "test_lookahead" and 
"test_lookbehind" respectively.



+{
+    struct rte_fbarray test_array;
+    int input[] = {1, 1070, 1, 2, 1, 2, 4, 12, 2, 2, 1, 2, 1};


I've managed to reduce this bug down to a more minimal example:

{ 63, 1, 2 }




I've managed to reduce the test down to an even more minimal example, so 
all of the other code, loops etc. is actually not needed:


1. Allocate fbarray with 256 entries
2. Set idx 64 as used
3. Call rte_fbarray_find_next_n_free() starting with index 1 and length 
of 64


Returned value should be 65, but without the fix it returns 129.

--
Thanks,
Anatoly

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

[Ferruh Yigit]

On 2/23/2023 2:25 PM, Ferruh Yigit wrote:
> On 2/21/2023 4:30 PM, Ed Czeck wrote:
>> Support the creation of multiple ports from one ark device via
>> the use of ark pmd extension, though the assignment of queues
>> to port.
>>
>> Add unique dev_private data for each port.
>>
>> This patch repairs a latent issue uncovered during testing.
>>
>> Signed-off-by: Ed Czeck 
> 
> Can you please update patch title as fix commit, and add Fixes line?
> 
> It can be good to add information to commit log that backport is not
> desired, for LTS maintainers see and prevent backporting by mistake.


Hi Ed,

Will there be a new version of this patch or can I drop it in the patchwork?

[PATCH 1/3] event/cnxk: align TX queue buffer adjustment

[pbhagavatula]

From: Pavan Nikhilesh 

Remove recalculating SQB thresholds in Tx queue buffer adjustment.
The adjustment is already done during Tx queue setup.

Signed-off-by: Pavan Nikhilesh 
---
Depends-on: series-27660

 drivers/event/cnxk/cn10k_eventdev.c  |  9 +
 drivers/event/cnxk/cn10k_tx_worker.h |  6 +++---
 drivers/event/cnxk/cn9k_eventdev.c   |  9 +
 drivers/event/cnxk/cn9k_worker.h | 12 +---
 drivers/net/cnxk/cn10k_tx.h  | 12 ++--
 drivers/net/cnxk/cn9k_tx.h   |  5 +++--
 6 files changed, 23 insertions(+), 30 deletions(-)

diff --git a/drivers/event/cnxk/cn10k_eventdev.c 
b/drivers/event/cnxk/cn10k_eventdev.c
index 89f32c4d1e..f7c6a83ff0 100644
--- a/drivers/event/cnxk/cn10k_eventdev.c
+++ b/drivers/event/cnxk/cn10k_eventdev.c
@@ -840,16 +840,9 @@ cn10k_sso_txq_fc_update(const struct rte_eth_dev *eth_dev, 
int32_t tx_queue_id)
sq = &cnxk_eth_dev->sqs[tx_queue_id];
txq = eth_dev->data->tx_queues[tx_queue_id];
sqes_per_sqb = 1U << txq->sqes_per_sqb_log2;
-   sq->nb_sqb_bufs_adj =
-   sq->nb_sqb_bufs -
-   RTE_ALIGN_MUL_CEIL(sq->nb_sqb_bufs, sqes_per_sqb) /
-   sqes_per_sqb;
if (cnxk_eth_dev->tx_offloads & RTE_ETH_TX_OFFLOAD_SECURITY)
-   sq->nb_sqb_bufs_adj -= (cnxk_eth_dev->outb.nb_desc /
-   (sqes_per_sqb - 1));
+   sq->nb_sqb_bufs_adj -= (cnxk_eth_dev->outb.nb_desc / 
sqes_per_sqb);
txq->nb_sqb_bufs_adj = sq->nb_sqb_bufs_adj;
-   txq->nb_sqb_bufs_adj =
-   ((100 - ROC_NIX_SQB_THRESH) * txq->nb_sqb_bufs_adj) / 
100;
}
 }

diff --git a/drivers/event/cnxk/cn10k_tx_worker.h 
b/drivers/event/cnxk/cn10k_tx_worker.h
index c18786a14c..7b2798ad2e 100644
--- a/drivers/event/cnxk/cn10k_tx_worker.h
+++ b/drivers/event/cnxk/cn10k_tx_worker.h
@@ -32,9 +32,9 @@ cn10k_sso_txq_fc_wait(const struct cn10k_eth_txq *txq)
 static __rte_always_inline int32_t
 cn10k_sso_sq_depth(const struct cn10k_eth_txq *txq)
 {
-   return (txq->nb_sqb_bufs_adj -
-   __atomic_load_n((int16_t *)txq->fc_mem, __ATOMIC_RELAXED))
-  << txq->sqes_per_sqb_log2;
+   int32_t avail = (int32_t)txq->nb_sqb_bufs_adj -
+   (int32_t)__atomic_load_n(txq->fc_mem, __ATOMIC_RELAXED);
+   return (avail << txq->sqes_per_sqb_log2) - avail;
 }

 static __rte_always_inline uint16_t
diff --git a/drivers/event/cnxk/cn9k_eventdev.c 
b/drivers/event/cnxk/cn9k_eventdev.c
index df23219f14..a9d603c22f 100644
--- a/drivers/event/cnxk/cn9k_eventdev.c
+++ b/drivers/event/cnxk/cn9k_eventdev.c
@@ -893,16 +893,9 @@ cn9k_sso_txq_fc_update(const struct rte_eth_dev *eth_dev, 
int32_t tx_queue_id)
sq = &cnxk_eth_dev->sqs[tx_queue_id];
txq = eth_dev->data->tx_queues[tx_queue_id];
sqes_per_sqb = 1U << txq->sqes_per_sqb_log2;
-   sq->nb_sqb_bufs_adj =
-   sq->nb_sqb_bufs -
-   RTE_ALIGN_MUL_CEIL(sq->nb_sqb_bufs, sqes_per_sqb) /
-   sqes_per_sqb;
if (cnxk_eth_dev->tx_offloads & RTE_ETH_TX_OFFLOAD_SECURITY)
-   sq->nb_sqb_bufs_adj -= (cnxk_eth_dev->outb.nb_desc /
-   (sqes_per_sqb - 1));
+   sq->nb_sqb_bufs_adj -= (cnxk_eth_dev->outb.nb_desc / 
sqes_per_sqb);
txq->nb_sqb_bufs_adj = sq->nb_sqb_bufs_adj;
-   txq->nb_sqb_bufs_adj =
-   ((100 - ROC_NIX_SQB_THRESH) * txq->nb_sqb_bufs_adj) / 
100;
}
 }

diff --git a/drivers/event/cnxk/cn9k_worker.h b/drivers/event/cnxk/cn9k_worker.h
index 988cb3acb6..d15dd309fe 100644
--- a/drivers/event/cnxk/cn9k_worker.h
+++ b/drivers/event/cnxk/cn9k_worker.h
@@ -711,6 +711,14 @@ cn9k_sso_hws_xmit_sec_one(const struct cn9k_eth_txq *txq, 
uint64_t base,
 }
 #endif

+static __rte_always_inline int32_t
+cn9k_sso_sq_depth(const struct cn9k_eth_txq *txq)
+{
+   int32_t avail = (int32_t)txq->nb_sqb_bufs_adj -
+   (int32_t)__atomic_load_n(txq->fc_mem, __ATOMIC_RELAXED);
+   return (avail << txq->sqes_per_sqb_log2) - avail;
+}
+
 static __rte_always_inline uint16_t
 cn9k_sso_hws_event_tx(uint64_t base, struct rte_event *ev, uint64_t *cmd,
  uint64_t *txq_data, const uint32_t flags)
@@ -734,9 +742,7 @@ cn9k_sso_hws_event_tx(uint64_t base, struct rte_event *ev, 
uint64_t *cmd,
if (flags & NIX_TX_OFFLOAD_MBUF_NOFF_F && txq->tx_compl.ena)
handle_tx_completion_pkts(txq, 1, 1);

-   if (((txq->nb_sqb_bufs_adj -
- __atomic_load_n((int16_t *)txq->fc_mem, __ATOMIC_RELAXED))
-<< txq->sqes_per_sqb_log2) <= 0)
+   if (cn9k_sso_sq_depth(txq) <= 0)
return 0;
cn9k_nix_tx_skeleton(txq, cmd, flags,

[PATCH 2/3] event/cnxk: use local labels in asm intrinsic

[pbhagavatula]

From: Pavan Nikhilesh 

Using labels in asm generates them as regular function and shades
callstack in tools like gdb or perf.
Use local label instead for better visibility.

Signed-off-by: Pavan Nikhilesh 
---
 drivers/event/cnxk/cn10k_worker.h|  8 ++---
 drivers/event/cnxk/cn9k_worker.h | 25 
 drivers/event/cnxk/cnxk_tim_worker.h | 44 ++--
 drivers/event/cnxk/cnxk_worker.h |  8 ++---
 4 files changed, 43 insertions(+), 42 deletions(-)

diff --git a/drivers/event/cnxk/cn10k_worker.h 
b/drivers/event/cnxk/cn10k_worker.h
index 27d3a9bca2..6ec81a5ce5 100644
--- a/drivers/event/cnxk/cn10k_worker.h
+++ b/drivers/event/cnxk/cn10k_worker.h
@@ -268,12 +268,12 @@ cn10k_sso_hws_get_work_empty(struct cn10k_sso_hws *ws, 
struct rte_event *ev,
 #ifdef RTE_ARCH_ARM64
asm volatile(PLT_CPU_FEATURE_PREAMBLE
 "  ldp %[tag], %[wqp], [%[tag_loc]]\n"
-"  tbz %[tag], 63, done%=  \n"
+"  tbz %[tag], 63, .Ldone%=\n"
 "  sevl\n"
-"rty%=:wfe \n"
+".Lrty%=:  wfe \n"
 "  ldp %[tag], %[wqp], [%[tag_loc]]\n"
-"  tbnz %[tag], 63, rty%=  \n"
-"done%=:   dmb ld  \n"
+"  tbnz %[tag], 63, .Lrty%=\n"
+".Ldone%=: dmb ld  \n"
 : [tag] "=&r"(gw.u64[0]), [wqp] "=&r"(gw.u64[1])
 : [tag_loc] "r"(ws->base + SSOW_LF_GWS_WQE0)
 : "memory");
diff --git a/drivers/event/cnxk/cn9k_worker.h b/drivers/event/cnxk/cn9k_worker.h
index d15dd309fe..51b4db419e 100644
--- a/drivers/event/cnxk/cn9k_worker.h
+++ b/drivers/event/cnxk/cn9k_worker.h
@@ -232,18 +232,19 @@ cn9k_sso_hws_dual_get_work(uint64_t base, uint64_t 
pair_base,
rte_prefetch_non_temporal(dws->lookup_mem);
 #ifdef RTE_ARCH_ARM64
asm volatile(PLT_CPU_FEATURE_PREAMBLE
-"rty%=:\n"
+".Lrty%=:  \n"
 "  ldr %[tag], [%[tag_loc]]\n"
 "  ldr %[wqp], [%[wqp_loc]]\n"
-"  tbnz %[tag], 63, rty%=  \n"
-"done%=:   str %[gw], [%[pong]]\n"
+"  tbnz %[tag], 63, .Lrty%=\n"
+".Ldone%=: str %[gw], [%[pong]]\n"
 "  dmb ld  \n"
 "  sub %[mbuf], %[wqp], #0x80  \n"
 "  prfm pldl1keep, [%[mbuf]]   \n"
 : [tag] "=&r"(gw.u64[0]), [wqp] "=&r"(gw.u64[1]),
   [mbuf] "=&r"(mbuf)
 : [tag_loc] "r"(base + SSOW_LF_GWS_TAG),
-  [wqp_loc] "r"(base + SSOW_LF_GWS_WQP), [gw] 
"r"(dws->gw_wdata),
+  [wqp_loc] "r"(base + SSOW_LF_GWS_WQP),
+  [gw] "r"(dws->gw_wdata),
   [pong] "r"(pair_base + SSOW_LF_GWS_OP_GET_WORK0));
 #else
gw.u64[0] = plt_read64(base + SSOW_LF_GWS_TAG);
@@ -282,13 +283,13 @@ cn9k_sso_hws_get_work(struct cn9k_sso_hws *ws, struct 
rte_event *ev,
asm volatile(PLT_CPU_FEATURE_PREAMBLE
 "  ldr %[tag], [%[tag_loc]]\n"
 "  ldr %[wqp], [%[wqp_loc]]\n"
-"  tbz %[tag], 63, done%=  \n"
+"  tbz %[tag], 63, .Ldone%=\n"
 "  sevl\n"
-"rty%=:wfe \n"
+".Lrty%=:  wfe \n"
 "  ldr %[tag], [%[tag_loc]]\n"
 "  ldr %[wqp], [%[wqp_loc]]\n"
-"  tbnz %[tag], 63, rty%=  \n"
-"done%=:   dmb ld  \n"
+"  tbnz %[tag], 63, .Lrty%=\n"
+".Ldone%=: dmb ld  \n"
 "  sub %[mbuf], %[wqp], #0x80  \n"
 "  prfm pldl1keep, [%[mbuf]]   \n"
 : [tag] "=&r"(gw.u64[0]), [wqp] "=&r"(gw.u64[1]),
@@ -330,13 +331,13 @@ cn9k_sso_hws_get_work_empty(uint64_t base, struct 
rte_event *ev,
asm volatile(PLT_CPU_FEATURE_PREAMBLE
 "  ldr %[tag], [%[tag_loc]]\n"
 "  

[PATCH 3/3] event/cnxk: use WFE in Tx fc wait

[pbhagavatula]

From: Pavan Nikhilesh 

Use WFE is Tx path when waiting for space in the Tx queue.
Depending upon the Tx queue contention and size, WFE will
reduce the cache pressure and power consumption.
In multi-core scenarios we have observed up to 8W power reduction.

Signed-off-by: Pavan Nikhilesh 
---
 drivers/event/cnxk/cn10k_tx_worker.h |  18 
 drivers/net/cnxk/cn10k_tx.h  | 152 +++
 2 files changed, 147 insertions(+), 23 deletions(-)

diff --git a/drivers/event/cnxk/cn10k_tx_worker.h 
b/drivers/event/cnxk/cn10k_tx_worker.h
index 7b2798ad2e..df57a4b137 100644
--- a/drivers/event/cnxk/cn10k_tx_worker.h
+++ b/drivers/event/cnxk/cn10k_tx_worker.h
@@ -24,9 +24,27 @@ cn10k_sso_hws_xtract_meta(struct rte_mbuf *m, const uint64_t 
*txq_data)
 static __rte_always_inline void
 cn10k_sso_txq_fc_wait(const struct cn10k_eth_txq *txq)
 {
+#ifdef RTE_ARCH_ARM64
+   uint64_t space;
+
+   asm volatile(PLT_CPU_FEATURE_PREAMBLE
+"  ldxr %[space], [%[addr]]\n"
+"  cmp %[adj], %[space]\n"
+"  b.hi .Ldne%=\n"
+"  sevl\n"
+".Lrty%=:  wfe \n"
+"  ldxr %[space], [%[addr]]\n"
+"  cmp %[adj], %[space]\n"
+"  b.ls .Lrty%=\n"
+".Ldne%=:  \n"
+: [space] "=&r"(space)
+: [adj] "r"(txq->nb_sqb_bufs_adj), [addr] "r"(txq->fc_mem)
+: "memory");
+#else
while ((uint64_t)txq->nb_sqb_bufs_adj <=
   __atomic_load_n(txq->fc_mem, __ATOMIC_RELAXED))
;
+#endif
 }
 
 static __rte_always_inline int32_t
diff --git a/drivers/net/cnxk/cn10k_tx.h b/drivers/net/cnxk/cn10k_tx.h
index bab08a2d3b..9049ac6b1a 100644
--- a/drivers/net/cnxk/cn10k_tx.h
+++ b/drivers/net/cnxk/cn10k_tx.h
@@ -102,27 +102,72 @@ cn10k_nix_tx_mbuf_validate(struct rte_mbuf *m, const 
uint32_t flags)
 }
 
 static __plt_always_inline void
-cn10k_nix_vwqe_wait_fc(struct cn10k_eth_txq *txq, int64_t req)
+cn10k_nix_vwqe_wait_fc(struct cn10k_eth_txq *txq, uint16_t req)
 {
int64_t cached, refill;
+   int64_t pkts;
 
 retry:
+#ifdef RTE_ARCH_ARM64
+
+   asm volatile(PLT_CPU_FEATURE_PREAMBLE
+"  ldxr %[pkts], [%[addr]] \n"
+"  tbz %[pkts], 63, .Ldne%=\n"
+"  sevl\n"
+".Lrty%=:  wfe \n"
+"  ldxr %[pkts], [%[addr]] \n"
+"  tbnz %[pkts], 63, .Lrty%=   \n"
+".Ldne%=:  \n"
+: [pkts] "=&r"(pkts)
+: [addr] "r"(&txq->fc_cache_pkts)
+: "memory");
+#else
+   RTE_SET_USED(pkts);
while (__atomic_load_n(&txq->fc_cache_pkts, __ATOMIC_RELAXED) < 0)
;
+#endif
cached = __atomic_fetch_sub(&txq->fc_cache_pkts, req, __ATOMIC_ACQUIRE) 
- req;
/* Check if there is enough space, else update and retry. */
-   if (cached < 0) {
-   /* Check if we have space else retry. */
-   do {
-   refill = txq->nb_sqb_bufs_adj -
-__atomic_load_n(txq->fc_mem, __ATOMIC_RELAXED);
-   refill = (refill << txq->sqes_per_sqb_log2) - refill;
-   } while (refill <= 0);
-   __atomic_compare_exchange(&txq->fc_cache_pkts, &cached, &refill,
- 0, __ATOMIC_RELEASE,
- __ATOMIC_RELAXED);
+   if (cached >= 0)
+   return;
+
+   /* Check if we have space else retry. */
+#ifdef RTE_ARCH_ARM64
+   int64_t val;
+
+   asm volatile(PLT_CPU_FEATURE_PREAMBLE
+"  ldxr %[val], [%[addr]]  \n"
+"  sub %[val], %[adj], %[val]  \n"
+"  lsl %[refill], %[val], %[shft]  \n"
+"  sub %[refill], %[refill], %[val]\n"
+"  sub %[refill], %[refill], %[sub]\n"
+"  cmp %[refill], #0x0 \n"
+"  b.ge .Ldne%=\n"
+"  sevl\n"
+".Lrty%=:  wfe \n"
+"  ldxr %[val],

[PATCH] event/cnxk: add get remaining ticks routine

[pbhagavatula]

From: Pavan Nikhilesh 

Add support to get the remaining ticks to expire for a
given event timer.

Signed-off-by: Pavan Nikhilesh 
---
 drivers/event/cnxk/cn10k_worker.h|  6 +
 drivers/event/cnxk/cn9k_worker.h |  4 
 drivers/event/cnxk/cnxk_tim_evdev.c  |  1 +
 drivers/event/cnxk/cnxk_tim_evdev.h  |  3 +++
 drivers/event/cnxk/cnxk_tim_worker.c | 35 
 5 files changed, 49 insertions(+)

diff --git a/drivers/event/cnxk/cn10k_worker.h 
b/drivers/event/cnxk/cn10k_worker.h
index 06c71c6092..3907919135 100644
--- a/drivers/event/cnxk/cn10k_worker.h
+++ b/drivers/event/cnxk/cn10k_worker.h
@@ -5,7 +5,9 @@
 #ifndef __CN10K_WORKER_H__
 #define __CN10K_WORKER_H__

+#include 
 #include 
+
 #include "cn10k_cryptodev_event_dp.h"
 #include "cn10k_rx.h"
 #include "cnxk_worker.h"
@@ -213,6 +215,10 @@ cn10k_sso_hws_post_process(struct cn10k_sso_hws *ws, 
uint64_t *u64,
/* Mark vector mempool object as get */
RTE_MEMPOOL_CHECK_COOKIES(rte_mempool_from_obj((void *)u64[1]),
  (void **)&u64[1], 1, 1);
+   } else if (CNXK_EVENT_TYPE_FROM_TAG(u64[0]) == RTE_EVENT_TYPE_TIMER) {
+   struct rte_event_timer *tim = (void *)u64[1];
+
+   tim->state = RTE_EVENT_TIMER_NOT_ARMED;
}
 }

diff --git a/drivers/event/cnxk/cn9k_worker.h b/drivers/event/cnxk/cn9k_worker.h
index 1ce4b044e8..04be35de8a 100644
--- a/drivers/event/cnxk/cn9k_worker.h
+++ b/drivers/event/cnxk/cn9k_worker.h
@@ -215,6 +215,10 @@ cn9k_sso_hws_post_process(uint64_t *u64, uint64_t mbuf, 
const uint32_t flags,
if (flags & NIX_RX_OFFLOAD_TSTAMP_F)
cn9k_sso_process_tstamp(u64[1], mbuf, tstamp[port]);
u64[1] = mbuf;
+   } else if (CNXK_EVENT_TYPE_FROM_TAG(u64[0]) == RTE_EVENT_TYPE_TIMER) {
+   struct rte_event_timer *tim = (void *)u64[1];
+
+   tim->state = RTE_EVENT_TIMER_NOT_ARMED;
}
 }

diff --git a/drivers/event/cnxk/cnxk_tim_evdev.c 
b/drivers/event/cnxk/cnxk_tim_evdev.c
index 121480df15..6d59fdf909 100644
--- a/drivers/event/cnxk/cnxk_tim_evdev.c
+++ b/drivers/event/cnxk/cnxk_tim_evdev.c
@@ -392,6 +392,7 @@ cnxk_tim_caps_get(const struct rte_eventdev *evdev, 
uint64_t flags,
cnxk_tim_ops.start = cnxk_tim_ring_start;
cnxk_tim_ops.stop = cnxk_tim_ring_stop;
cnxk_tim_ops.get_info = cnxk_tim_ring_info_get;
+   cnxk_tim_ops.remaining_ticks_get = cnxk_tim_remaining_ticks_get;
sso_set_priv_mem_fn = priv_mem_fn;

if (dev->enable_stats) {
diff --git a/drivers/event/cnxk/cnxk_tim_evdev.h 
b/drivers/event/cnxk/cnxk_tim_evdev.h
index 3a0b036cb4..b91fcb3aca 100644
--- a/drivers/event/cnxk/cnxk_tim_evdev.h
+++ b/drivers/event/cnxk/cnxk_tim_evdev.h
@@ -320,6 +320,9 @@ cnxk_tim_timer_cancel_burst(const struct 
rte_event_timer_adapter *adptr,
struct rte_event_timer **tim,
const uint16_t nb_timers);

+int cnxk_tim_remaining_ticks_get(const struct rte_event_timer_adapter *adapter,
+const struct rte_event_timer *evtim, uint64_t 
*ticks_remaining);
+
 int cnxk_tim_caps_get(const struct rte_eventdev *dev, uint64_t flags,
  uint32_t *caps,
  const struct event_timer_adapter_ops **ops,
diff --git a/drivers/event/cnxk/cnxk_tim_worker.c 
b/drivers/event/cnxk/cnxk_tim_worker.c
index 923a72093b..d1dab0552f 100644
--- a/drivers/event/cnxk/cnxk_tim_worker.c
+++ b/drivers/event/cnxk/cnxk_tim_worker.c
@@ -171,3 +171,38 @@ cnxk_tim_timer_cancel_burst(const struct 
rte_event_timer_adapter *adptr,

return index;
 }
+
+int
+cnxk_tim_remaining_ticks_get(const struct rte_event_timer_adapter *adapter,
+const struct rte_event_timer *evtim, uint64_t 
*ticks_remaining)
+{
+   struct cnxk_tim_ring *tim_ring = adapter->data->adapter_priv;
+   struct cnxk_tim_bkt *bkt, *current_bkt;
+   struct cnxk_tim_ent *entry;
+   uint64_t bkt_cyc, bucket;
+   uint64_t sema;
+
+   if (evtim->impl_opaque[1] == 0 || evtim->impl_opaque[0] == 0)
+   return -ENOENT;
+
+   entry = (struct cnxk_tim_ent *)(uintptr_t)evtim->impl_opaque[0];
+   if (entry->wqe != evtim->ev.u64)
+   return -ENOENT;
+
+   if (evtim->state != RTE_EVENT_TIMER_ARMED)
+   return -ENOENT;
+
+   bkt = (struct cnxk_tim_bkt *)evtim->impl_opaque[1];
+   sema = __atomic_load_n(&bkt->w1, __ATOMIC_ACQUIRE);
+   if (cnxk_tim_bkt_get_hbt(sema) || !cnxk_tim_bkt_get_nent(sema))
+   return -ENOENT;
+
+   bkt_cyc = tim_ring->tick_fn(tim_ring->tbase) - tim_ring->ring_start_cyc;
+   bucket = rte_reciprocal_divide_u64(bkt_cyc, &tim_ring->fast_div);
+   current_bkt = &tim_ring->bkt[bucket];
+
+   *ticks_remaining = RTE_MAX(bkt, current_bkt) - RTE_MIN(bkt, 
current_bkt);
+   /* Assume that the current bucket is yet to expir

Re: [PATCH] app/testpmd: fix segment fault with invalid queue id

[Stephen Hemminger]

On Tue, 16 May 2023 19:00:21 +0800
Dengdui Huang  wrote:

> When input queue id is invalid, it will lead to
> Segmentation fault, like:
> 
> dpdk-testpmd -a :01:00.0 -- -i
> testpmd> show port 0 txq/rxq 99 desc 0 status  
> Segmentation fault
> 
> dpdk-testpmd -a :01:00.0 -- -i
> testpmd> show port 0 rxq 99 desc used count  
> Segmentation fault
> 
> This patch fixes it.
> 
> In addition, this patch add the check for the offset
> of the descriptor in case of other anomalies.
> 
> Fixes: fae9aa717d6c ("app/testpmd: support checking descriptor status")
> Fixes: 3f9acb5c83bb ("ethdev: avoid non-dataplane checks in Rx queue count")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Dengdui Huang 

What is the backtrace and device driver?  The problem is that other users
besides testpmd might hit same problem.

It would make sense to have a function to test for valid rx and tx queue id
in rte_ethdev. Similar to existing rte_eth_dev_is_valid_port() rather than
open coding it.  Maybe rte_eth_dev_is_valid_rxq(port_id, queue_id)?

here was talk that the existing rx queue descriptor status is racy, and
unused by any real application; and therefore would be good candidate for
future removal.

Re: [PATCH v2] lib/kni : coding style is fixed

[Stephen Hemminger]

On Tue, 16 May 2023 11:03:59 +
Yasin CANER  wrote:

> + /* First, getting allocation count from alloc_q. alloc_q is allocated 
> in this function*/ 
> + /* and/or kni_alloc function from mempool.*/
> + /* If alloc_q is completely removed, it shall be allocated again.*/

If you send another version of this patch. It would be good to follow the style 
of multi-line comment.
/* First, getting allocation count from alloc_q. alloc_q is allocated 
in this function
 *  and/or kni_alloc function from mempool.
 * If alloc_q is completely removed, it shall be allocated again.
 */

Re: [PATCH v3] doc: comment VF does not support multi-process

[Stephen Hemminger]

On Tue, 16 May 2023 10:22:05 +
Mingjin Ye  wrote:

> Announcing that multi-process is not supported
> 
> Signed-off-by: Mingjin Ye 
> ---
> v2: Modify issue description reason.
> ---
> V3: Modify description.
> ---
>  doc/guides/nics/ixgbe.rst | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/doc/guides/nics/ixgbe.rst b/doc/guides/nics/ixgbe.rst
> index b1d77ab7ab..816d614c33 100644
> --- a/doc/guides/nics/ixgbe.rst
> +++ b/doc/guides/nics/ixgbe.rst
> @@ -461,3 +461,9 @@ show bypass config
>  Show the bypass configuration for a bypass enabled NIC using the lowest port 
> on the NIC::
>  
> testpmd> show bypass config (port_id)  
> +
> +VF driver does not support multi-process
> +
> +
> +The VF driver does not support multi-process. And some function pointers
> +in the case of multi-process are not set correctly.

This is best done by updating doc/guides/nic/features/ixgbe_vf.ini

That is enough. Don't need to add note in ixgbe.rst.

Re: [PATCH] lib/mempool : rte_mempool_avail_count, fixing return bigger than mempool size

[Stephen Hemminger]

On Tue, 16 May 2023 13:41:46 +
Yasin CANER  wrote:

> From: Yasin CANER 
> 
> after a while working rte_mempool_avail_count function returns bigger
> than mempool size that cause miscalculation rte_mempool_in_use_count.
> 
> it helps to avoid miscalculation rte_mempool_in_use_count.
> 
> Bugzilla ID: 1229
> 
> Signed-off-by: Yasin CANER 

An alternative that avoids some code duplication.

diff --git a/lib/mempool/rte_mempool.c b/lib/mempool/rte_mempool.c
index cf5dea2304a7..2406b112e7b0 100644
--- a/lib/mempool/rte_mempool.c
+++ b/lib/mempool/rte_mempool.c
@@ -1010,7 +1010,7 @@ rte_mempool_avail_count(const struct rte_mempool *mp)
count = rte_mempool_ops_get_count(mp);
 
if (mp->cache_size == 0)
-   return count;
+   goto exit;
 
for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++)
count += mp->local_cache[lcore_id].len;
@@ -1019,6 +1019,7 @@ rte_mempool_avail_count(const struct rte_mempool *mp)
 * due to race condition (access to len is not locked), the
 * total can be greater than size... so fix the result
 */
+exit:
if (count > mp->size)
return mp->size;
return count;

[PATCH v2 0/8] add AESNI_MB optimisations

[Ciara Power]

This patchset adds some optimisations for AESNI_MB PMD, many based on
features that are available in intel-ipsec-mb v1.3 and future release v1.4.

v2: moved some functions inside ifdef as they are only used when
IPSec_MB version is 1.2 or lower.

Marcel Cornu (1):
  crypto/ipsec_mb: use burst API in aesni_mb

Pablo de Lara (7):
  crypto/ipsec_mb: use GMAC dedicated algorithms
  crypto/ipsec_mb: use new SGL API
  crypto/ipsec_mb: remove unneeded fields in crypto session
  crypto/ipsec_mb: store template job
  crypto/ipsec_mb: optimize for GCM case
  crypto/ipsec_mb: do not free linear_sgl always
  crypto/ipsec_mb: set and use session ID

 drivers/crypto/ipsec_mb/pmd_aesni_mb.c  | 984 
 drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h |  32 +-
 2 files changed, 619 insertions(+), 397 deletions(-)

-- 
2.25.1

[PATCH v2 1/8] crypto/ipsec_mb: use GMAC dedicated algorithms

[Ciara Power]

From: Pablo de Lara 

AES-GMAC can be done with auth-only enums
IMB_AES_GMAC_128/192/256, which allows another cipher
algorithm to be used, instead of being part of AES-GCM.

Signed-off-by: Pablo de Lara 
Signed-off-by: Ciara Power 
---
 drivers/crypto/ipsec_mb/pmd_aesni_mb.c | 104 +++--
 1 file changed, 47 insertions(+), 57 deletions(-)

diff --git a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c 
b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
index ac20d01937..c53548aa3b 100644
--- a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
+++ b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
@@ -57,8 +57,7 @@ is_aead_algo(IMB_HASH_ALG hash_alg, IMB_CIPHER_MODE 
cipher_mode)
 {
return (hash_alg == IMB_AUTH_CHACHA20_POLY1305 ||
hash_alg == IMB_AUTH_AES_CCM ||
-   (hash_alg == IMB_AUTH_AES_GMAC &&
-   cipher_mode == IMB_CIPHER_GCM));
+   cipher_mode == IMB_CIPHER_GCM);
 }
 
 /** Set session authentication parameters */
@@ -155,7 +154,6 @@ aesni_mb_set_session_auth_parameters(const IMB_MGR *mb_mgr,
} else
sess->cipher.direction = IMB_DIR_DECRYPT;
 
-   sess->auth.algo = IMB_AUTH_AES_GMAC;
if (sess->auth.req_digest_len >
get_digest_byte_length(IMB_AUTH_AES_GMAC)) {
IPSEC_MB_LOG(ERR, "Invalid digest size\n");
@@ -167,16 +165,19 @@ aesni_mb_set_session_auth_parameters(const IMB_MGR 
*mb_mgr,
 
switch (xform->auth.key.length) {
case IMB_KEY_128_BYTES:
+   sess->auth.algo = IMB_AUTH_AES_GMAC_128;
IMB_AES128_GCM_PRE(mb_mgr, xform->auth.key.data,
&sess->cipher.gcm_key);
sess->cipher.key_length_in_bytes = IMB_KEY_128_BYTES;
break;
case IMB_KEY_192_BYTES:
+   sess->auth.algo = IMB_AUTH_AES_GMAC_192;
IMB_AES192_GCM_PRE(mb_mgr, xform->auth.key.data,
&sess->cipher.gcm_key);
sess->cipher.key_length_in_bytes = IMB_KEY_192_BYTES;
break;
case IMB_KEY_256_BYTES:
+   sess->auth.algo = IMB_AUTH_AES_GMAC_256;
IMB_AES256_GCM_PRE(mb_mgr, xform->auth.key.data,
&sess->cipher.gcm_key);
sess->cipher.key_length_in_bytes = IMB_KEY_256_BYTES;
@@ -1039,19 +1040,20 @@ set_cpu_mb_job_params(IMB_JOB *job, struct 
aesni_mb_session *session,
break;
 
case IMB_AUTH_AES_GMAC:
-   if (session->cipher.mode == IMB_CIPHER_GCM) {
-   job->u.GCM.aad = aad->va;
-   job->u.GCM.aad_len_in_bytes = session->aead.aad_len;
-   } else {
-   /* For GMAC */
-   job->u.GCM.aad = buf;
-   job->u.GCM.aad_len_in_bytes = len;
-   job->cipher_mode = IMB_CIPHER_GCM;
-   }
+   job->u.GCM.aad = aad->va;
+   job->u.GCM.aad_len_in_bytes = session->aead.aad_len;
job->enc_keys = &session->cipher.gcm_key;
job->dec_keys = &session->cipher.gcm_key;
break;
 
+   case IMB_AUTH_AES_GMAC_128:
+   case IMB_AUTH_AES_GMAC_192:
+   case IMB_AUTH_AES_GMAC_256:
+   job->u.GMAC._key = &session->cipher.gcm_key;
+   job->u.GMAC._iv = iv->va;
+   job->u.GMAC.iv_len_in_bytes = session->iv.length;
+   break;
+
case IMB_AUTH_CHACHA20_POLY1305:
job->u.CHACHA20_POLY1305.aad = aad->va;
job->u.CHACHA20_POLY1305.aad_len_in_bytes =
@@ -1091,16 +1093,10 @@ set_cpu_mb_job_params(IMB_JOB *job, struct 
aesni_mb_session *session,
job->dst = (uint8_t *)buf + sofs.ofs.cipher.head;
job->cipher_start_src_offset_in_bytes = sofs.ofs.cipher.head;
job->hash_start_src_offset_in_bytes = sofs.ofs.auth.head;
-   if (job->hash_alg == IMB_AUTH_AES_GMAC &&
-   session->cipher.mode != IMB_CIPHER_GCM) {
-   job->msg_len_to_hash_in_bytes = 0;
-   job->msg_len_to_cipher_in_bytes = 0;
-   } else {
-   job->msg_len_to_hash_in_bytes = len - sofs.ofs.auth.head -
-   sofs.ofs.auth.tail;
-   job->msg_len_to_cipher_in_bytes = len - sofs.ofs.cipher.head -
-   sofs.ofs.cipher.tail;
-   }
+   job->msg_len_to_hash_in_bytes = len - sofs.ofs.auth.head -
+   sofs.ofs.auth.tail;
+   job->msg_len_to_cipher_in_bytes = len - sofs.ofs.cipher.head -
+   sofs.ofs.cipher.tail;
 
job->user_data = udata;
 }
@@ -1184,8 +1180,6 @@ sgl_linear_cipher_auth_len(IMB_JOB *job, uint64_t 
*auth_len)
job->hash_alg == IMB_AUTH_ZUC_EIA3_BITLEN)
   

[PATCH v2 2/8] crypto/ipsec_mb: use burst API in aesni_mb

[Ciara Power]

From: Marcel Cornu 

Use new ipsec_mb burst API in dequeue burst function,
when ipsec_mb version is v1.3 or newer.

Signed-off-by: Marcel Cornu 
Signed-off-by: Pablo de Lara 
Signed-off-by: Ciara Power 
---
v2: moved some functions inside ifdef as they are only used when
IPSec_MB version is 1.2 or lower.
---
 drivers/crypto/ipsec_mb/pmd_aesni_mb.c | 202 -
 1 file changed, 167 insertions(+), 35 deletions(-)

diff --git a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c 
b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
index c53548aa3b..b22c0183eb 100644
--- a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
+++ b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
@@ -9,6 +9,10 @@ struct aesni_mb_op_buf_data {
uint32_t offset;
 };
 
+#if IMB_VERSION(1, 2, 0) < IMB_VERSION_NUM
+static IMB_JOB *jobs[IMB_MAX_BURST_SIZE] = {NULL};
+#endif
+
 /**
  * Calculate the authentication pre-computes
  *
@@ -1884,6 +1888,168 @@ post_process_mb_sync_job(IMB_JOB *job)
st[0] = (job->status == IMB_STATUS_COMPLETED) ? 0 : EBADMSG;
 }
 
+static inline uint32_t
+handle_completed_sync_jobs(IMB_JOB *job, IMB_MGR *mb_mgr)
+{
+   uint32_t i;
+
+   for (i = 0; job != NULL; i++, job = IMB_GET_COMPLETED_JOB(mb_mgr))
+   post_process_mb_sync_job(job);
+
+   return i;
+}
+
+static inline uint32_t
+flush_mb_sync_mgr(IMB_MGR *mb_mgr)
+{
+   IMB_JOB *job;
+
+   job = IMB_FLUSH_JOB(mb_mgr);
+   return handle_completed_sync_jobs(job, mb_mgr);
+}
+
+static inline IMB_JOB *
+set_job_null_op(IMB_JOB *job, struct rte_crypto_op *op)
+{
+   job->chain_order = IMB_ORDER_HASH_CIPHER;
+   job->cipher_mode = IMB_CIPHER_NULL;
+   job->hash_alg = IMB_AUTH_NULL;
+   job->cipher_direction = IMB_DIR_DECRYPT;
+
+   /* Set user data to be crypto operation data struct */
+   job->user_data = op;
+
+   return job;
+}
+
+#if IMB_VERSION(1, 2, 0) < IMB_VERSION_NUM
+static uint16_t
+aesni_mb_dequeue_burst(void *queue_pair, struct rte_crypto_op **ops,
+   uint16_t nb_ops)
+{
+   struct ipsec_mb_qp *qp = queue_pair;
+   IMB_MGR *mb_mgr = qp->mb_mgr;
+   struct rte_crypto_op *op;
+   struct rte_crypto_op *deqd_ops[IMB_MAX_BURST_SIZE];
+   IMB_JOB *job;
+   int retval, processed_jobs = 0;
+   uint16_t i, nb_jobs;
+
+   if (unlikely(nb_ops == 0 || mb_mgr == NULL))
+   return 0;
+
+   uint8_t digest_idx = qp->digest_idx;
+   uint16_t burst_sz = (nb_ops > IMB_MAX_BURST_SIZE) ?
+   IMB_MAX_BURST_SIZE : nb_ops;
+
+   /*
+* If nb_ops is greater than the max supported
+* ipsec_mb burst size, then process in bursts of
+* IMB_MAX_BURST_SIZE until all operations are submitted
+*/
+   while (nb_ops) {
+   uint16_t nb_submit_ops;
+   uint16_t n = (nb_ops / burst_sz) ?
+   burst_sz : nb_ops;
+
+   while (unlikely((IMB_GET_NEXT_BURST(mb_mgr, n, jobs)) < n)) {
+   /*
+* Not enough free jobs in the queue
+* Flush n jobs until enough jobs available
+*/
+   nb_jobs = IMB_FLUSH_BURST(mb_mgr, n, jobs);
+   for (i = 0; i < nb_jobs; i++) {
+   job = jobs[i];
+
+   op = post_process_mb_job(qp, job);
+   if (op) {
+   ops[processed_jobs++] = op;
+   qp->stats.dequeued_count++;
+   } else {
+   qp->stats.dequeue_err_count++;
+   break;
+   }
+   }
+   }
+
+   /*
+* Get the next operations to process from ingress queue.
+* There is no need to return the job to the IMB_MGR
+* if there are no more operations to process, since
+* the IMB_MGR can use that pointer again in next
+* get_next calls.
+*/
+   nb_submit_ops = rte_ring_dequeue_burst(qp->ingress_queue,
+   (void **)deqd_ops, n, NULL);
+   for (i = 0; i < nb_submit_ops; i++) {
+   job = jobs[i];
+   op = deqd_ops[i];
+
+#ifdef AESNI_MB_DOCSIS_SEC_ENABLED
+   if (op->sess_type == RTE_CRYPTO_OP_SECURITY_SESSION)
+   retval = set_sec_mb_job_params(job, qp, op,
+  &digest_idx);
+   else
+#endif
+   retval = set_mb_job_params(job, qp, op,
+  &digest_idx, mb_mgr);
+
+   if (unlikely(retval != 0)) {
+   qp

[PATCH v2 3/8] crypto/ipsec_mb: use new SGL API

[Ciara Power]

From: Pablo de Lara 

Use new SGL API available from IPSec Multi-buffer v1.3,
where only one function call is required to submit
all segments to be processed in an SGL scenario.
Instead of having one call per segment, there is only
one call per buffer.

Signed-off-by: Pablo de Lara 
Signed-off-by: Ciara Power 
---
 drivers/crypto/ipsec_mb/pmd_aesni_mb.c  | 187 +++-
 drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h |   7 +
 2 files changed, 153 insertions(+), 41 deletions(-)

diff --git a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c 
b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
index b22c0183eb..ef1f141cad 100644
--- a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
+++ b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
@@ -1241,6 +1241,141 @@ imb_lib_support_sgl_algo(IMB_CIPHER_MODE alg)
return 0;
 }
 
+#if IMB_VERSION(1, 2, 0) < IMB_VERSION_NUM
+static inline int
+single_sgl_job(IMB_JOB *job, struct rte_crypto_op *op,
+   int oop, uint32_t offset, struct rte_mbuf *m_src,
+   struct rte_mbuf *m_dst, struct IMB_SGL_IOV *sgl_segs)
+{
+   uint32_t num_segs = 0;
+   struct aesni_mb_op_buf_data src_sgl = {0};
+   struct aesni_mb_op_buf_data dst_sgl = {0};
+   uint32_t total_len;
+
+   job->sgl_state = IMB_SGL_ALL;
+
+   src_sgl.m = m_src;
+   src_sgl.offset = offset;
+
+   while (src_sgl.offset >= src_sgl.m->data_len) {
+   src_sgl.offset -= src_sgl.m->data_len;
+   src_sgl.m = src_sgl.m->next;
+
+   RTE_ASSERT(src_sgl.m != NULL);
+   }
+
+   if (oop) {
+   dst_sgl.m = m_dst;
+   dst_sgl.offset = offset;
+
+   while (dst_sgl.offset >= dst_sgl.m->data_len) {
+   dst_sgl.offset -= dst_sgl.m->data_len;
+   dst_sgl.m = dst_sgl.m->next;
+
+   RTE_ASSERT(dst_sgl.m != NULL);
+   }
+   }
+   total_len = op->sym->aead.data.length;
+
+   while (total_len != 0) {
+   uint32_t data_len, part_len;
+
+   if (src_sgl.m == NULL) {
+   IPSEC_MB_LOG(ERR, "Invalid source buffer");
+   return -EINVAL;
+   }
+
+   data_len = src_sgl.m->data_len - src_sgl.offset;
+
+   sgl_segs[num_segs].in = rte_pktmbuf_mtod_offset(src_sgl.m, 
uint8_t *,
+   src_sgl.offset);
+
+   if (dst_sgl.m != NULL) {
+   if (dst_sgl.m->data_len - dst_sgl.offset == 0) {
+   dst_sgl.m = dst_sgl.m->next;
+   if (dst_sgl.m == NULL) {
+   IPSEC_MB_LOG(ERR, "Invalid destination 
buffer");
+   return -EINVAL;
+   }
+   dst_sgl.offset = 0;
+   }
+   part_len = RTE_MIN(data_len, (dst_sgl.m->data_len -
+   dst_sgl.offset));
+   sgl_segs[num_segs].out = 
rte_pktmbuf_mtod_offset(dst_sgl.m,
+   uint8_t *, dst_sgl.offset);
+   dst_sgl.offset += part_len;
+   } else {
+   part_len = RTE_MIN(data_len, total_len);
+   sgl_segs[num_segs].out = 
rte_pktmbuf_mtod_offset(src_sgl.m, uint8_t *,
+   src_sgl.offset);
+   }
+
+   sgl_segs[num_segs].len = part_len;
+
+   total_len -= part_len;
+
+   if (part_len != data_len) {
+   src_sgl.offset += part_len;
+   } else {
+   src_sgl.m = src_sgl.m->next;
+   src_sgl.offset = 0;
+   }
+   num_segs++;
+   }
+   job->num_sgl_io_segs = num_segs;
+   job->sgl_io_segs = sgl_segs;
+   return 0;
+}
+#endif
+
+static inline int
+multi_sgl_job(IMB_JOB *job, struct rte_crypto_op *op,
+   int oop, uint32_t offset, struct rte_mbuf *m_src,
+   struct rte_mbuf *m_dst, IMB_MGR *mb_mgr)
+{
+   int ret;
+   IMB_JOB base_job;
+   struct aesni_mb_op_buf_data src_sgl = {0};
+   struct aesni_mb_op_buf_data dst_sgl = {0};
+   uint32_t total_len;
+
+   base_job = *job;
+   job->sgl_state = IMB_SGL_INIT;
+   job = IMB_SUBMIT_JOB(mb_mgr);
+   total_len = op->sym->aead.data.length;
+
+   src_sgl.m = m_src;
+   src_sgl.offset = offset;
+
+   while (src_sgl.offset >= src_sgl.m->data_len) {
+   src_sgl.offset -= src_sgl.m->data_len;
+   src_sgl.m = src_sgl.m->next;
+
+   RTE_ASSERT(src_sgl.m != NULL);
+   }
+
+   if (oop) {
+   dst_sgl.m = m_dst;
+   dst_sgl.offset = offset;
+
+   while (dst_sgl.offset >= dst_sgl.m->data_len) {
+   dst_sgl.offset -= dst_sgl.m->data_l

[PATCH v2 4/8] crypto/ipsec_mb: remove unneeded fields in crypto session

[Ciara Power]

From: Pablo de Lara 

Cipher direction, cipher mode and hash algorithm are
duplicated in crypto session.

Signed-off-by: Pablo de Lara 
---
 drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h 
b/drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h
index e17b53e4fe..3cf44f8bc4 100644
--- a/drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h
+++ b/drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h
@@ -852,9 +852,6 @@ get_digest_byte_length(IMB_HASH_ALG algo)
 
 /** AES-NI multi-buffer private session structure */
 struct aesni_mb_session {
-   IMB_CIPHER_MODE cipher_mode;
-   IMB_CIPHER_DIRECTION cipher_direction;
-   IMB_HASH_ALG hash_alg;
IMB_CHAIN_ORDER chain_order;
/*  common job fields */
struct {
-- 
2.25.1

[PATCH v2 5/8] crypto/ipsec_mb: store template job

[Ciara Power]

From: Pablo de Lara 

Store template IMB_JOB in session that
will have filled all session-related fields.
These fields include cipher direction, chain order, cipher mode,
hash algorithm, key length, IV lengths, AAD length, digest length,
and key pointers.

Signed-off-by: Pablo de Lara 
Signed-off-by: Ciara Power 
---
 drivers/crypto/ipsec_mb/pmd_aesni_mb.c  | 403 
 drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h |  20 +-
 2 files changed, 159 insertions(+), 264 deletions(-)

diff --git a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c 
b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
index ef1f141cad..80f59e75de 100644
--- a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
+++ b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
@@ -76,7 +76,7 @@ aesni_mb_set_session_auth_parameters(const IMB_MGR *mb_mgr,
uint32_t auth_precompute = 1;
 
if (xform == NULL) {
-   sess->auth.algo = IMB_AUTH_NULL;
+   sess->template_job.hash_alg = IMB_AUTH_NULL;
return 0;
}
 
@@ -87,7 +87,6 @@ aesni_mb_set_session_auth_parameters(const IMB_MGR *mb_mgr,
 
/* Set IV parameters */
sess->auth_iv.offset = xform->auth.iv.offset;
-   sess->auth_iv.length = xform->auth.iv.length;
 
/* Set the request digest size */
sess->auth.req_digest_len = xform->auth.digest_length;
@@ -97,13 +96,13 @@ aesni_mb_set_session_auth_parameters(const IMB_MGR *mb_mgr,
 
/* Set Authentication Parameters */
if (xform->auth.algo == RTE_CRYPTO_AUTH_NULL) {
-   sess->auth.algo = IMB_AUTH_NULL;
-   sess->auth.gen_digest_len = 0;
+   sess->template_job.hash_alg = IMB_AUTH_NULL;
+   sess->template_job.auth_tag_output_len_in_bytes = 0;
return 0;
}
 
if (xform->auth.algo == RTE_CRYPTO_AUTH_AES_XCBC_MAC) {
-   sess->auth.algo = IMB_AUTH_AES_XCBC;
+   sess->template_job.hash_alg = IMB_AUTH_AES_XCBC;
 
uint16_t xcbc_mac_digest_len =
get_truncated_digest_byte_length(IMB_AUTH_AES_XCBC);
@@ -111,18 +110,21 @@ aesni_mb_set_session_auth_parameters(const IMB_MGR 
*mb_mgr,
IPSEC_MB_LOG(ERR, "Invalid digest size\n");
return -EINVAL;
}
-   sess->auth.gen_digest_len = sess->auth.req_digest_len;
+   sess->template_job.auth_tag_output_len_in_bytes = 
sess->auth.req_digest_len;
 
IMB_AES_XCBC_KEYEXP(mb_mgr, xform->auth.key.data,
sess->auth.xcbc.k1_expanded,
sess->auth.xcbc.k2, sess->auth.xcbc.k3);
+   sess->template_job.u.XCBC._k1_expanded = 
sess->auth.xcbc.k1_expanded;
+   sess->template_job.u.XCBC._k2 = sess->auth.xcbc.k2;
+   sess->template_job.u.XCBC._k3 = sess->auth.xcbc.k3;
return 0;
}
 
if (xform->auth.algo == RTE_CRYPTO_AUTH_AES_CMAC) {
uint32_t dust[4*15];
 
-   sess->auth.algo = IMB_AUTH_AES_CMAC;
+   sess->template_job.hash_alg = IMB_AUTH_AES_CMAC;
 
uint16_t cmac_digest_len =
get_digest_byte_length(IMB_AUTH_AES_CMAC);
@@ -140,70 +142,74 @@ aesni_mb_set_session_auth_parameters(const IMB_MGR 
*mb_mgr,
 * the requested number of bytes.
 */
if (sess->auth.req_digest_len < 4)
-   sess->auth.gen_digest_len = cmac_digest_len;
+   sess->template_job.auth_tag_output_len_in_bytes = 
cmac_digest_len;
else
-   sess->auth.gen_digest_len = sess->auth.req_digest_len;
+   sess->template_job.auth_tag_output_len_in_bytes = 
sess->auth.req_digest_len;
 
IMB_AES_KEYEXP_128(mb_mgr, xform->auth.key.data,
sess->auth.cmac.expkey, dust);
IMB_AES_CMAC_SUBKEY_GEN_128(mb_mgr, sess->auth.cmac.expkey,
sess->auth.cmac.skey1, sess->auth.cmac.skey2);
+   sess->template_job.u.CMAC._key_expanded = 
sess->auth.cmac.expkey;
+   sess->template_job.u.CMAC._skey1 = sess->auth.cmac.skey1;
+   sess->template_job.u.CMAC._skey2 = sess->auth.cmac.skey2;
return 0;
}
 
if (xform->auth.algo == RTE_CRYPTO_AUTH_AES_GMAC) {
if (xform->auth.op == RTE_CRYPTO_AUTH_OP_GENERATE) {
-   sess->cipher.direction = IMB_DIR_ENCRYPT;
-   sess->chain_order = IMB_ORDER_CIPHER_HASH;
+   sess->template_job.cipher_direction = IMB_DIR_ENCRYPT;
+   sess->template_job.chain_order = IMB_ORDER_CIPHER_HASH;
} else
-   sess->cipher.direction = IMB_DIR_DECRYPT;
+   sess->template_job.cipher_direction = IMB_DIR_DECRYPT;
 
i

[PATCH v2 6/8] crypto/ipsec_mb: optimize for GCM case

[Ciara Power]

From: Pablo de Lara 

Use a separate code path when dealing with AES-GCM.

Signed-off-by: Pablo de Lara 
Signed-off-by: Ciara Power 
---
 drivers/crypto/ipsec_mb/pmd_aesni_mb.c | 88 +++---
 1 file changed, 79 insertions(+), 9 deletions(-)

diff --git a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c 
b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
index 80f59e75de..58faf3502c 100644
--- a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
+++ b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
@@ -1366,6 +1366,70 @@ multi_sgl_job(IMB_JOB *job, struct rte_crypto_op *op,
}
return 0;
 }
+
+static inline int
+set_gcm_job(IMB_MGR *mb_mgr, IMB_JOB *job, const uint8_t sgl,
+   struct aesni_mb_qp_data *qp_data,
+   struct rte_crypto_op *op, uint8_t *digest_idx,
+   const struct aesni_mb_session *session,
+   struct rte_mbuf *m_src, struct rte_mbuf *m_dst,
+   const int oop)
+{
+   const uint32_t m_offset = op->sym->aead.data.offset;
+
+   job->u.GCM.aad = op->sym->aead.aad.data;
+   if (sgl) {
+   job->u.GCM.ctx = &qp_data->gcm_sgl_ctx;
+   job->cipher_mode = IMB_CIPHER_GCM_SGL;
+   job->hash_alg = IMB_AUTH_GCM_SGL;
+   job->hash_start_src_offset_in_bytes = 0;
+   job->msg_len_to_hash_in_bytes = 0;
+   job->msg_len_to_cipher_in_bytes = 0;
+   job->cipher_start_src_offset_in_bytes = 0;
+   } else {
+   job->hash_start_src_offset_in_bytes =
+   op->sym->aead.data.offset;
+   job->msg_len_to_hash_in_bytes =
+   op->sym->aead.data.length;
+   job->cipher_start_src_offset_in_bytes =
+   op->sym->aead.data.offset;
+   job->msg_len_to_cipher_in_bytes = op->sym->aead.data.length;
+   }
+
+   if (session->auth.operation == RTE_CRYPTO_AUTH_OP_VERIFY) {
+   job->auth_tag_output = qp_data->temp_digests[*digest_idx];
+   *digest_idx = (*digest_idx + 1) % IMB_MAX_JOBS;
+   } else {
+   job->auth_tag_output = op->sym->aead.digest.data;
+   }
+
+   job->iv = rte_crypto_op_ctod_offset(op, uint8_t *,
+   session->iv.offset);
+
+   /* Set user data to be crypto operation data struct */
+   job->user_data = op;
+
+   if (sgl) {
+   job->src = NULL;
+   job->dst = NULL;
+
+#if IMB_VERSION(1, 2, 0) < IMB_VERSION_NUM
+   if (m_src->nb_segs <= MAX_NUM_SEGS)
+   return single_sgl_job(job, op, oop,
+   m_offset, m_src, m_dst,
+   qp_data->sgl_segs);
+   else
+#endif
+   return multi_sgl_job(job, op, oop,
+   m_offset, m_src, m_dst, mb_mgr);
+   } else {
+   job->src = rte_pktmbuf_mtod(m_src, uint8_t *);
+   job->dst = rte_pktmbuf_mtod_offset(m_dst, uint8_t *, m_offset);
+   }
+
+   return 0;
+}
+
 /**
  * Process a crypto operation and complete a IMB_JOB job structure for
  * submission to the multi buffer library for processing.
@@ -1403,10 +1467,10 @@ set_mb_job_params(IMB_JOB *job, struct ipsec_mb_qp *qp,
return -1;
}
 
-   memcpy(job, &session->template_job, sizeof(IMB_JOB));
+   const IMB_CIPHER_MODE cipher_mode =
+   session->template_job.cipher_mode;
 
-   /* Set authentication parameters */
-   const int aead = is_aead_algo(job->hash_alg, job->cipher_mode);
+   memcpy(job, &session->template_job, sizeof(IMB_JOB));
 
if (!op->sym->m_dst) {
/* in-place operation */
@@ -1424,10 +1488,17 @@ set_mb_job_params(IMB_JOB *job, struct ipsec_mb_qp *qp,
 
if (m_src->nb_segs > 1 || m_dst->nb_segs > 1) {
sgl = 1;
-   if (!imb_lib_support_sgl_algo(job->cipher_mode))
+   if (!imb_lib_support_sgl_algo(cipher_mode))
lb_sgl = 1;
}
 
+   if (cipher_mode == IMB_CIPHER_GCM)
+   return set_gcm_job(mb_mgr, job, sgl, qp_data,
+   op, digest_idx, session, m_src, m_dst, oop);
+
+   /* Set authentication parameters */
+   const int aead = is_aead_algo(job->hash_alg, cipher_mode);
+
switch (job->hash_alg) {
case IMB_AUTH_AES_CCM:
job->u.CCM.aad = op->sym->aead.aad.data + 18;
@@ -1474,13 +1545,12 @@ set_mb_job_params(IMB_JOB *job, struct ipsec_mb_qp *qp,
else
m_offset = op->sym->cipher.data.offset;
 
-   if (job->cipher_mode == IMB_CIPHER_ZUC_EEA3) {
+   if (cipher_mode == IMB_CIPHER_ZUC_EEA3)
m_offset >>= 3;
-   } else if (job->cipher_mode == IMB_CIPHER_SNOW3G_UEA2_BITLEN) {
+   else if (cipher_mode == IMB_CIPHER_SNOW3G_UEA2_BITLEN)
m_offset = 0;
-   } else if (job->cipher_mode == IMB_CIP

[PATCH v2 7/8] crypto/ipsec_mb: do not free linear_sgl always

[Ciara Power]

From: Pablo de Lara 

linear_sgl buffer only needs to be freed
if it was allocated previously.

Signed-off-by: Pablo de Lara 
---
 drivers/crypto/ipsec_mb/pmd_aesni_mb.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c 
b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
index 58faf3502c..f83738a5eb 100644
--- a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
+++ b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
@@ -1898,6 +1898,7 @@ post_process_mb_job(struct ipsec_mb_qp *qp, IMB_JOB *job)
struct rte_crypto_op *op = (struct rte_crypto_op *)job->user_data;
struct aesni_mb_session *sess = NULL;
uint8_t *linear_buf = NULL;
+   int sgl = 0;
 
 #ifdef AESNI_MB_DOCSIS_SEC_ENABLED
uint8_t is_docsis_sec = 0;
@@ -1923,6 +1924,8 @@ post_process_mb_job(struct ipsec_mb_qp *qp, IMB_JOB *job)
op->sym->m_dst->nb_segs > 1)) &&

!imb_lib_support_sgl_algo(job->cipher_mode)) {
linear_buf = (uint8_t *) job->user_data2;
+   sgl = 1;
+
post_process_sgl_linear(op, job, sess, 
linear_buf);
}
 
@@ -1952,7 +1955,8 @@ post_process_mb_job(struct ipsec_mb_qp *qp, IMB_JOB *job)
default:
op->status = RTE_CRYPTO_OP_STATUS_ERROR;
}
-   rte_free(linear_buf);
+   if (sgl)
+   rte_free(linear_buf);
}
 
/* Free session if a session-less crypto op */
-- 
2.25.1

[PATCH v2 8/8] crypto/ipsec_mb: set and use session ID

[Ciara Power]

From: Pablo de Lara 

When creating a session, get the session ID that
defines the fixed session parameters and store it in the private data.
When retrieving IMB_JOB's, if their internal session ID matches
the one in the private session data, these fixed session parameters
do not need to be filled again.

Signed-off-by: Pablo de Lara 
Signed-off-by: Ciara Power 
---
 drivers/crypto/ipsec_mb/pmd_aesni_mb.c  | 22 -
 drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h |  2 ++
 2 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c 
b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
index f83738a5eb..f4322d9af4 100644
--- a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
+++ b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
@@ -845,6 +845,10 @@ aesni_mb_session_configure(IMB_MGR *mb_mgr,
}
}
 
+#if IMB_VERSION(1, 3, 0) < IMB_VERSION_NUM
+   sess->session_id = imb_set_session(mb_mgr, &sess->template_job);
+#endif
+
return 0;
 }
 
@@ -977,6 +981,10 @@ aesni_mb_set_docsis_sec_session_parameters(
goto error_exit;
}
 
+#if IMB_VERSION(1, 3, 0) < IMB_VERSION_NUM
+   ipsec_sess->session_id = imb_set_session(mb_mgr, 
&ipsec_sess->template_job);
+#endif
+
 error_exit:
free_mb_mgr(mb_mgr);
return ret;
@@ -1386,6 +1394,9 @@ set_gcm_job(IMB_MGR *mb_mgr, IMB_JOB *job, const uint8_t 
sgl,
job->msg_len_to_hash_in_bytes = 0;
job->msg_len_to_cipher_in_bytes = 0;
job->cipher_start_src_offset_in_bytes = 0;
+#if IMB_VERSION(1, 3, 0) < IMB_VERSION_NUM
+   imb_set_session(mb_mgr, job);
+#endif
} else {
job->hash_start_src_offset_in_bytes =
op->sym->aead.data.offset;
@@ -1470,7 +1481,10 @@ set_mb_job_params(IMB_JOB *job, struct ipsec_mb_qp *qp,
const IMB_CIPHER_MODE cipher_mode =
session->template_job.cipher_mode;
 
-   memcpy(job, &session->template_job, sizeof(IMB_JOB));
+#if IMB_VERSION(1, 3, 0) < IMB_VERSION_NUM
+   if (job->session_id != session->session_id)
+#endif
+   memcpy(job, &session->template_job, sizeof(IMB_JOB));
 
if (!op->sym->m_dst) {
/* in-place operation */
@@ -1510,6 +1524,9 @@ set_mb_job_params(IMB_JOB *job, struct ipsec_mb_qp *qp,
job->u.GCM.ctx = &qp_data->gcm_sgl_ctx;
job->cipher_mode = IMB_CIPHER_GCM_SGL;
job->hash_alg = IMB_AUTH_GCM_SGL;
+#if IMB_VERSION(1, 3, 0) < IMB_VERSION_NUM
+   imb_set_session(mb_mgr, job);
+#endif
}
break;
case IMB_AUTH_AES_GMAC_128:
@@ -1534,6 +1551,9 @@ set_mb_job_params(IMB_JOB *job, struct ipsec_mb_qp *qp,
job->u.CHACHA20_POLY1305.ctx = &qp_data->chacha_sgl_ctx;
job->cipher_mode = IMB_CIPHER_CHACHA20_POLY1305_SGL;
job->hash_alg = IMB_AUTH_CHACHA20_POLY1305_SGL;
+#if IMB_VERSION(1, 3, 0) < IMB_VERSION_NUM
+   imb_set_session(mb_mgr, job);
+#endif
}
break;
default:
diff --git a/drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h 
b/drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h
index ce9a6e4886..9b7c9edb6d 100644
--- a/drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h
+++ b/drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h
@@ -854,6 +854,8 @@ get_digest_byte_length(IMB_HASH_ALG algo)
 struct aesni_mb_session {
IMB_JOB template_job;
/*< Template job structure */
+   uint32_t session_id;
+   /*< IPSec MB session ID */
struct {
uint16_t offset;
} iv;
-- 
2.25.1

RE: [PATCH v2 02/22] lib: add pdcp protocol

[Akhil Goyal]

Hi Anoob,

Fix check patch issues and please see some inline comments.

> Subject: [PATCH v2 02/22] lib: add pdcp protocol
> 
> Add Packet Data Convergence Protocol (PDCP) processing library.
> 
> The library is similar to lib_ipsec which provides IPsec processing
> capabilities in DPDK.
> 
> PDCP would involve roughly the following options,
> 1. Transfer of user plane data
> 2. Transfer of control plane data
> 3. Header compression
> 4. Uplink data compression
> 5. Ciphering and integrity protection
> 
> PDCP library provides following control path APIs that is used to
> configure various PDCP entities,
> 1. rte_pdcp_entity_establish()
> 2. rte_pdcp_entity_suspend()
> 3. rte_pdcp_entity_release()
> 
> Signed-off-by: Anoob Joseph 
> Signed-off-by: Kiran Kumar K 
> Signed-off-by: Volodymyr Fialko 
> ---
>  doc/api/doxy-api-index.md |   3 +-
>  doc/api/doxy-api.conf.in  |   1 +
>  lib/meson.build   |   1 +
>  lib/pdcp/meson.build  |  17 +
>  lib/pdcp/pdcp_crypto.c|  21 +
>  lib/pdcp/pdcp_crypto.h|  15 
>  lib/pdcp/pdcp_entity.h|  95 +++
>  lib/pdcp/pdcp_process.c   | 138 +
>  lib/pdcp/pdcp_process.h   |  13 
>  lib/pdcp/rte_pdcp.c   | 138 +
>  lib/pdcp/rte_pdcp.h   | 157 ++
>  lib/pdcp/version.map  |  10 +++
>  12 files changed, 608 insertions(+), 1 deletion(-)
>  create mode 100644 lib/pdcp/meson.build
>  create mode 100644 lib/pdcp/pdcp_crypto.c
>  create mode 100644 lib/pdcp/pdcp_crypto.h
>  create mode 100644 lib/pdcp/pdcp_entity.h
>  create mode 100644 lib/pdcp/pdcp_process.c
>  create mode 100644 lib/pdcp/pdcp_process.h
>  create mode 100644 lib/pdcp/rte_pdcp.c
>  create mode 100644 lib/pdcp/rte_pdcp.h
>  create mode 100644 lib/pdcp/version.map
> 
> diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
> index debbe4134f..cd7a6cae44 100644
> --- a/doc/api/doxy-api-index.md
> +++ b/doc/api/doxy-api-index.md
> @@ -128,7 +128,8 @@ The public API headers are grouped by topics:
>[eCPRI](@ref rte_ecpri.h),
>[L2TPv2](@ref rte_l2tpv2.h),
>[PPP](@ref rte_ppp.h),
> -  [PDCP hdr](@ref rte_pdcp_hdr.h)
> +  [PDCP hdr](@ref rte_pdcp_hdr.h),
> +  [PDCP](@ref rte_pdcp.h)
> 
>  - **QoS**:
>[metering](@ref rte_meter.h),
> diff --git a/doc/api/doxy-api.conf.in b/doc/api/doxy-api.conf.in
> index d230a19e1f..58789308a9 100644
> --- a/doc/api/doxy-api.conf.in
> +++ b/doc/api/doxy-api.conf.in
> @@ -62,6 +62,7 @@ INPUT   = @TOPDIR@/doc/api/doxy-api-
> index.md \
>@TOPDIR@/lib/net \
>@TOPDIR@/lib/pcapng \
>@TOPDIR@/lib/pci \
> +  @TOPDIR@/lib/pdcp \
>@TOPDIR@/lib/pdump \
>@TOPDIR@/lib/pipeline \
>@TOPDIR@/lib/port \
> diff --git a/lib/meson.build b/lib/meson.build
> index 0812ce6026..d217c04ea9 100644
> --- a/lib/meson.build
> +++ b/lib/meson.build
> @@ -64,6 +64,7 @@ libraries = [
>  'flow_classify', # flow_classify lib depends on pkt framework table 
> lib
>  'graph',
>  'node',
> +'pdcp', # pdcp lib depends on crypto and security
>  ]
> 
>  optional_libs = [
> diff --git a/lib/pdcp/meson.build b/lib/pdcp/meson.build
> new file mode 100644
> index 00..ccaf426240
> --- /dev/null
> +++ b/lib/pdcp/meson.build
> @@ -0,0 +1,17 @@
> +# SPDX-License-Identifier: BSD-3-Clause
> +# Copyright(C) 2023 Marvell.
> +
> +if is_windows
> +build = false
> +reason = 'not supported on Windows'
> +subdir_done()
> +endif
> +
> +sources = files(
> +'pdcp_crypto.c',
> +'pdcp_process.c',
> +'rte_pdcp.c',
> +)
> +headers = files('rte_pdcp.h')
> +
> +deps += ['mbuf', 'net', 'cryptodev', 'security']
> diff --git a/lib/pdcp/pdcp_crypto.c b/lib/pdcp/pdcp_crypto.c
> new file mode 100644
> index 00..755e27ec9e
> --- /dev/null
> +++ b/lib/pdcp/pdcp_crypto.c
> @@ -0,0 +1,21 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(C) 2023 Marvell.
> + */
> +
> +#include 
> +
> +#include "pdcp_crypto.h"
> +
> +int
> +pdcp_crypto_sess_create(struct rte_pdcp_entity *entity, const struct
> rte_pdcp_entity_conf *conf)
> +{
> + RTE_SET_USED(entity);
> + RTE_SET_USED(conf);
> + return 0;
> +}
> +
> +void
> +pdcp_crypto_sess_destroy(struct rte_pdcp_entity *entity)
> +{
> + RTE_SET_USED(entity);
> +}
> diff --git a/lib/pdcp/pdcp_crypto.h b/lib/pdcp/pdcp_crypto.h
> new file mode 100644
> index 00..6563331d37
> --- /dev/null
> +++ b/lib/pdcp/pdcp_crypto.h
> @@ -0,0 +1,15 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(C) 2023 Marvell.
> + */
> +
> +#ifndef PDCP_CRYPTO_H
> +#define PDCP_CRYPTO_H
> +
> +#include 
> +
> +int pdcp_crypto_sess_create(struct rte_pdcp_entity *entity,
> + const struct rte_pdcp_entity_c

Re: [PATCH 1/3] net/ark: support secondary process

[Burakov, Anatoly]

On 2/17/2023 4:00 PM, Ed Czeck wrote:

From: John Miller 

disable device configuration for secondary processes

Signed-off-by: John Miller 
---
  drivers/net/ark/ark_ethdev.c | 11 ---
  1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ark/ark_ethdev.c b/drivers/net/ark/ark_ethdev.c
index b2995427c8..f96722551e 100644
--- a/drivers/net/ark/ark_ethdev.c
+++ b/drivers/net/ark/ark_ethdev.c
@@ -147,6 +147,9 @@ eth_ark_pci_probe(struct rte_pci_driver *pci_drv 
__rte_unused,
struct rte_eth_dev *eth_dev;
int ret;
  
+	if (rte_eal_process_type() == RTE_PROC_SECONDARY)

+   fprintf(stderr, "ARK probed by secondary process\n");


Why is this printing directly to stderr? IMO this should be RTE_LOG(ERR, 
...)


--
Thanks,
Anatoly

RE: [PATCH v2 03/22] pdcp: add pre and post-process

[Akhil Goyal]

> Subject: [PATCH v2 03/22] pdcp: add pre and post-process
> 
> PDCP process is split into 2 parts. One before crypto processing
> (rte_pdcp_pkt_pre_process()) and one after crypto processing
> (rte_pdcp_pkt_post_process()). Functionality of pre-process &
> post-process varies based on the type of entity. Registration of entity
> specific function pointer allows skipping multiple checks that would
> come in datapath otherwise.
> 
> Signed-off-by: Anoob Joseph 
> Signed-off-by: Kiran Kumar K 
> Signed-off-by: Volodymyr Fialko 
Acked-by: Akhil Goyal 

Haven't compiled it yet. Check for doxygen build issues if any.

RE: [PATCH v2 04/22] pdcp: add packet group

[Akhil Goyal]

> Subject: [PATCH v2 04/22] pdcp: add packet group
> 
> Crypto processing in PDCP is performed asynchronously by
> rte_cryptodev_enqueue_burst() and rte_cryptodev_dequeue_burst(). Since
> cryptodev dequeue can return crypto operations belonging to multiple
> entities, rte_pdcp_pkt_crypto_group() is added to help grouping crypto
> operations belonging to same entity.
> 
> Signed-off-by: Anoob Joseph 
> Signed-off-by: Kiran Kumar K 
> Signed-off-by: Volodymyr Fialko 
> ---
>  lib/pdcp/meson.build  |   1 +
>  lib/pdcp/rte_pdcp.h   |   2 +
>  lib/pdcp/rte_pdcp_group.h | 125
> ++
>  3 files changed, 128 insertions(+)
>  create mode 100644 lib/pdcp/rte_pdcp_group.h
> 
> diff --git a/lib/pdcp/meson.build b/lib/pdcp/meson.build
> index ccaf426240..08679b743a 100644
> --- a/lib/pdcp/meson.build
> +++ b/lib/pdcp/meson.build
> @@ -13,5 +13,6 @@ sources = files(
>  'rte_pdcp.c',
>  )
>  headers = files('rte_pdcp.h')
> +indirect_headers += files('rte_pdcp_group.h')
> 
>  deps += ['mbuf', 'net', 'cryptodev', 'security']
> diff --git a/lib/pdcp/rte_pdcp.h b/lib/pdcp/rte_pdcp.h
> index 75dc569f66..54f88e3fd3 100644
> --- a/lib/pdcp/rte_pdcp.h
> +++ b/lib/pdcp/rte_pdcp.h
> @@ -247,6 +247,8 @@ rte_pdcp_pkt_post_process(const struct
> rte_pdcp_entity *entity,
>   return entity->post_process(entity, in_mb, out_mb, num, nb_err);
>  }
> 
> +#include 
> +
>  #ifdef __cplusplus
>  }
>  #endif
> diff --git a/lib/pdcp/rte_pdcp_group.h b/lib/pdcp/rte_pdcp_group.h
> new file mode 100644
> index 00..cb322f55c7
> --- /dev/null
> +++ b/lib/pdcp/rte_pdcp_group.h
> @@ -0,0 +1,125 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(C) 2023 Marvell.
> + */
> +
> +#ifndef RTE_PDCP_GROUP_H
> +#define RTE_PDCP_GROUP_H
> +
> +/**
> + * @file rte_pdcp_group.h
> + *
> + * RTE PDCP grouping support.
> + * It is not recommended to include this file directly, include 
> + * instead.
> + * Provides helper functions to process completed crypto-ops and group
> related
> + * packets by sessions they belong to.
> + */

Why do we need to have a separate public header file which we do not wish user 
to use directly
for just a single API?

Can it not be added into rte_pdcp.h?

> +
> +#include 
> +#include 
> +#include 
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +/**
> + * Group packets belonging to same PDCP entity.
> + */
> +struct rte_pdcp_group {
> + union {
> + uint64_t val;
> + void *ptr;
> + } id; /**< Grouped by value */
> + struct rte_mbuf **m;  /**< Start of the group */
> + uint32_t cnt; /**< Number of entries in the group */
> + int32_t rc;   /**< Status code associated with the group */
> +};
> +
> +/**
> + * Take crypto-op as an input and extract pointer to related PDCP entity.
> + * @param cop
> + *   The address of an input *rte_crypto_op* structure.
> + * @return
> + *   The pointer to the related *rte_pdcp_entity* structure.
> + */
> +static inline struct rte_pdcp_entity *
> +rte_pdcp_en_from_cop(const struct rte_crypto_op *cop)
> +{
> + void *sess = cop->sym[0].session;
> +
> + return (struct rte_pdcp_entity *)
> + rte_cryptodev_sym_session_opaque_data_get(sess);
> +}
> +
> +/**
> + * Take as input completed crypto ops, extract related mbufs and group them
> by
> + * *rte_pdcp_entity* they belong to. Mbuf for which the crypto operation has
> + * failed would be flagged using *RTE_MBUF_F_RX_SEC_OFFLOAD_FAILED*
> flag
> + * in rte_mbuf.ol_flags. The crypto_ops would be freed after the grouping.
> + *
> + * Note that application must ensure only crypto-ops prepared by lib_pdcp is
> + * provided back to @see rte_pdcp_pkt_crypto_group().
> + *
> + * @param cop
> + *   The address of an array of *num* pointers to the input *rte_crypto_op*
> + *   structures.
> + * @param[out] mb
> + *   The address of an array of *num* pointers to output *rte_mbuf* 
> structures.
> + * @param[out] grp
> + *   The address of an array of *num* to output *rte_pdcp_group* structures.
> + * @param num
> + *   The maximum number of crypto-ops to process.
> + * @return
> + *   Number of filled elements in *grp* array.
> + *
> + */
> +static inline uint16_t
> +rte_pdcp_pkt_crypto_group(struct rte_crypto_op *cop[], struct rte_mbuf
> *mb[],
> +   struct rte_pdcp_group grp[], uint16_t num)
> +{
> + uint32_t i, j = 0, n = 0;
> + void *ns, *ps = NULL;
> + struct rte_mbuf *m;
> +
> + for (i = 0; i != num; i++) {
> + m = cop[i]->sym[0].m_src;
> + ns = cop[i]->sym[0].session;
> +
> + m->ol_flags |= RTE_MBUF_F_RX_SEC_OFFLOAD;
> + if (cop[i]->status != RTE_CRYPTO_OP_STATUS_SUCCESS)
> + m->ol_flags |=
> RTE_MBUF_F_RX_SEC_OFFLOAD_FAILED;
> +
> + /* Different entity */
> + if (ps != ns) {
> +
> + /* Finalize open group and start a new one */
> +  

RE: [PATCH] lib/mempool : rte_mempool_avail_count, fixing return bigger than mempool size

[Morten Brørup]

> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Tuesday, 16 May 2023 17.24
> 
> On Tue, 16 May 2023 13:41:46 +
> Yasin CANER  wrote:
> 
> > From: Yasin CANER 
> >
> > after a while working rte_mempool_avail_count function returns bigger
> > than mempool size that cause miscalculation rte_mempool_in_use_count.
> >
> > it helps to avoid miscalculation rte_mempool_in_use_count.
> >
> > Bugzilla ID: 1229
> >
> > Signed-off-by: Yasin CANER 
> 
> An alternative that avoids some code duplication.
> 
> diff --git a/lib/mempool/rte_mempool.c b/lib/mempool/rte_mempool.c
> index cf5dea2304a7..2406b112e7b0 100644
> --- a/lib/mempool/rte_mempool.c
> +++ b/lib/mempool/rte_mempool.c
> @@ -1010,7 +1010,7 @@ rte_mempool_avail_count(const struct rte_mempool
> *mp)
> count = rte_mempool_ops_get_count(mp);
> 
> if (mp->cache_size == 0)
> -   return count;
> +   goto exit;

This bug can only occur here (i.e. with cache_size==0) if 
rte_mempool_ops_get_count() returns an incorrect value. The bug should be fixed 
there instead.

> 
> for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++)
> count += mp->local_cache[lcore_id].len;
> @@ -1019,6 +1019,7 @@ rte_mempool_avail_count(const struct rte_mempool
> *mp)
>  * due to race condition (access to len is not locked), the
>  * total can be greater than size... so fix the result
>  */
> +exit:
> if (count > mp->size)
> return mp->size;
> return count;

RE: [PATCH v2 05/22] pdcp: add crypto session create and destroy

[Akhil Goyal]

> Subject: [PATCH v2 05/22] pdcp: add crypto session create and destroy
> 
> Add routines to create & destroy sessions. PDCP lib would take
> crypto transforms as input and creates the session on the corresponding
> device after verifying capabilities.
> 
> Signed-off-by: Anoob Joseph 
> Signed-off-by: Volodymyr Fialko 

Acked-by: Akhil Goyal 

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

[Joshua Washington]

Hello,

I believe my original solution was something closer to what you are
suggesting for backward compatibility. I originally had a flag that enabled
changing source port instead of source IP addresses, but I received
feedback that adding an extra flag was complicating things too much from
Stephen.

On a VM, the purpose of using multi-flow is similar to that of bare metal:
to test RSS in the RX side. However, generating traffic by changing source
IP address can cause inconsistencies in performance due to protections in
cloud infrastructure from sending packets from a different source IP
address than is provisioned for the VM. Changing source UDP port to test
RSS should be functionally equivalent while allowing VMs to send traffic
from a single source IP address.

If everyone agrees that adding --txonly-multi-flow as an option as well as
keeping the flag is an acceptable way of moving forward, I can do that.

Thanks,
Josh

[Bug 1233] GCC 13 build errors in drivers/bus/dpaa in DRTE_ENABLE_ASSERT mode

[bugzilla]

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

Bug ID: 1233
   Summary: GCC 13 build errors  in drivers/bus/dpaa in
DRTE_ENABLE_ASSERT mode
   Product: DPDK
   Version: 23.07
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: normal
  Priority: Normal
 Component: other
  Assignee: dev@dpdk.org
  Reporter: jerinjac...@gmail.com
  Target Milestone: ---

steps to reproduce:

meson --werror -Dc_args='-DRTE_ENABLE_ASSERT'  -Denable_docs=true build
ninja -C build


[dpdk-next-net-mrvl] $ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/cc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/13.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=ada,c,c++,d,fortran,go,lto,objc,obj-c++ --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugur
l=https://bugs.archlinux.org/ --with-build-config=bootstrap-lto
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp
 --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-l
ibssp --disable-libstdcxx-pch --disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.1.1 20230429 (GCC)


log:

ccache cc -Idrivers/libtmp_rte_bus_dpaa.a.p -Idrivers -I../drivers
-Idrivers/bus/dpaa -I../drivers/bus/dpaa -I../drivers/bus/dpaa/include
-I../drivers/bus/dpaa/base/qbman -I. -I.. -Iconfig -I../config
-Ilib/eal/include -I../lib/eal/include
-Ilib/eal/linux/include -I../lib/eal/linux/include -Ilib/eal/x86/include
-I../lib/eal/x86/include -Ilib/eal/common -I../lib/eal/common -Ilib/eal
-I../lib/eal -Ilib/kvargs -I../lib/kvargs -Ilib/metrics -I../lib/metrics
-Ilib/telemetry -I../l
ib/telemetry -Idrivers/common/dpaax -I../drivers/common/dpaax
-I../drivers/common/dpaax/caamflib -Ilib/eventdev -I../lib/eventdev -Ilib/ring
-I../lib/ring -Ilib/ethdev -I../lib/ethdev -Ilib/net -I../lib/net -Ilib/mbuf
-I../lib/mbuf -Ilib/me
mpool -I../lib/mempool -Ilib/meter -I../lib/meter -Ilib/hash -I../lib/hash
-Ilib/rcu -I../lib/rcu -Ilib/timer -I../lib/timer -Ilib/cryptodev
-I../lib/cryptodev -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall
-Winvalid-pch -Wextra -W
error -O3 -include rte_config.h -Wcast-qual -Wdeprecated -Wformat
-Wformat-nonliteral -Wformat-security -Wmissing-declarations
-Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wpointer-arith
-Wsign-compare -Wstrict-prototypes -
Wundef -Wwrite-strings -Wno-address-of-packed-member -Wno-packed-not-aligned
-Wno-missing-field-initializers -Wno-zero-length-bounds -D_GNU_SOURCE
-DRTE_ENABLE_ASSERT -fPIC -march=native -DALLOW_EXPERIMENTAL_API
-DALLOW_INTERNAL_API -Wno-fo
rmat-truncation -Wno-cast-qual -Wno-pointer-arith
-DRTE_LOG_DEFAULT_LOGTYPE=bus.dpaa -MD -MQ
drivers/libtmp_rte_bus_dpaa.a.p/bus_dpaa_base_qbman_qman.c.o -MF
drivers/libtmp_rte_bus_dpaa.a.p/bus_dpaa_base_qbman_qman.c.o.d -o
drivers/libtmp_r
te_bus_dpaa.a.p/bus_dpaa_base_qbman_qman.c.o -c
../drivers/bus/dpaa/base/qbman/qman.c
In file included from ../lib/eal/x86/include/rte_byteorder.h:13,
 from ../drivers/common/dpaax/compat.h:33,
 from ../drivers/bus/dpaa/base/qbman/dpaa_sys.h:11,
 from ../drivers/bus/dpaa/base/qbman/qman_priv.h:11,
 from ../drivers/bus/dpaa/base/qbman/qman.h:8,
 from ../drivers/bus/dpaa/base/qbman/qman.c:8:
In function ‘rte_spinlock_lock’,
inlined from ‘fq_state_change’ at
../drivers/bus/dpaa/base/qbman/qman.c:767:2,
inlined from ‘__poll_portal_slow’ at
../drivers/bus/dpaa/base/qbman/qman.c:901:5:
../lib/eal/include/rte_common.h:33:13: error: array subscript 0 is outside
array bounds of ‘rte_spinlock_t[0]’ [-Werror=array-bounds=]
   33 | #define asm __asm__
  | ^~~
../lib/eal/x86/include/rte_spinlock.h:29:9: note: in expansion of macro ‘asm’
   29 | asm volatile (
  | ^~~
In function ‘__poll_portal_slow’:
cc1: note: source object is likely at address zero
In file included from ../drivers/bus/dpaa/include/fsl_qman.h:15,
 from ../drivers/bus/dpaa/base/qbman/qman_priv.h:12:
In function ‘fqtree_del’,
inlined from ‘table_del_fq’ at ../drivers/bus/dpaa/base/qbman/qman.c:145:2,
inlined from ‘fq_state_change’ at
../drivers/bus/dpaa/base/qbman/qman.c:772:3,
inlined from ‘__poll_portal_slow’ at
../drivers/bus/dpaa/base/qbman/qman.c:901:5:
../drivers/bus/dpaa/include/dpaa_rbtree.h:94:48: error: array subscript 0 is
outside array bounds of ‘struct rb_node[0]’ [-Werror=array-bounds=]
   94 |  

Re: [PATCH] event/dsw: free rings on close

[Jerin Jacob]

On Thu, May 11, 2023 at 12:17 PM Mattias Rönnblom
 wrote:
>
> The per-port data and control rings were not freed when the event
> device was closed.
>
> Fixes: 1c8e3caa3bfb ("event/dsw: add event scheduling and device start/stop")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Mattias Rönnblom 


Updated the git commit as follows and applied to
dpdk-next-net-eventdev/for-main. Thanks


> ---
>  drivers/event/dsw/dsw_evdev.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/event/dsw/dsw_evdev.c b/drivers/event/dsw/dsw_evdev.c
> index ffabf0d23d..6c5cde2468 100644
> --- a/drivers/event/dsw/dsw_evdev.c
> +++ b/drivers/event/dsw/dsw_evdev.c
> @@ -363,6 +363,10 @@ static int
>  dsw_close(struct rte_eventdev *dev)
>  {
> struct dsw_evdev *dsw = dsw_pmd_priv(dev);
> +   uint16_t port_id;
> +
> +   for (port_id = 0; port_id < dsw->num_ports; port_id++)
> +   dsw_port_release(&dsw->ports[port_id]);
>
> dsw->num_ports = 0;
> dsw->num_queues = 0;
> --
> 2.34.1
>

RE: Photon OS + MLX not coming up

[Asaf Penso]

Hello Chetan,

Can you please mention the OFED version you use?
In case it’s inbox, please share the rdma-core version.

Have you tried installing OFED?
DPDK 21.02 is tested with MLNX_OFED 5.2-2.2.0.0

Regards,
Asaf Penso

From: chetan bhasin 
Sent: Friday, 12 May 2023 10:54
To: dev@dpdk.org
Subject: Photon OS + MLX not coming up


Hi,

We are using DPDK version “21.02” and facing issue while doing port start of 
MLX (ConnectX-4 Lx Virtual Function)

:0b:00.0 'MT27710 Family [ConnectX-4 Lx Virtual Function] 1016' if=eth2 
drv=mlx5_core unused=

Photon kernel version - 4.19.277-3.ph3

Firmware version –
]# ethtool -i eth2
driver: mlx5_core
version: 5.0-0
firmware-version: 14.26.1040 (HP_2690110034)
expansion-rom-version:
bus-info: :0b:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: yes

modinfo mlx5_core
filename:   
/lib/modules/4.19.277-3.ph3/kernel/drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.ko.xz
version:5.0-0
license:Dual BSD/GPL
description:Mellanox 5th generation network adapters (ConnectX series) core 
driver
author: Eli Cohen e...@mellanox.com
srcversion: 981FA6D58D2B017B197F177

We are seeing following errors in dpdk when we start the port

2023/05/12 06:00:57:497 notice dpdk   EAL: Couldn't map new region 
for DMA
2023/05/12 06:01:29:966 error  dpdk   Interface 
TwentyFiveGigabitEthernetb/0/0 error -12: Unknown error -12
2023/05/12 06:01:29:966 error  interface  sw_set_flags_helper: 
dpdk_interface_admin_up_down: Interface start failed
2023/05/12 06:01:29:966 notice dpdk   common_mlx5: Unable to find 
virtually contiguous chunk for address (0x10). rte_memseg_contig_walk() 
failed.
2023/05/12 06:01:29:966 notice dpdk   mlx5_pci: Failed to init 
cache list NIC_ingress_0_matcher_cache entry (nil).
2023/05/12 06:01:29:966 notice dpdk   mlx5_pci: port 0 failed to 
set defaults flows

DPDK packaging and OpenWrt

[Philip Prindeville]

Hi,

I'm a packaging maintainer for some of the OpenWrt ancillary packages, and I'm 
looking at upstreaming DPDK support into OpenWrt.  Apologies in advance if this 
is a bit dense (a brain dump) or hops between too many topics.

I was looking at what's been done to date, and it seems there are a few 
shortcomings which I hope to address.

Amongst them are:

* getting DPDK support into OpenWrt's main repo for the kmod's and into the 
packages repo for the user-space support;

* making DPDK supported on all available architectures (i.e. agnostic, not just 
x86_64 specific);

* integrating into the OpenWrt "make menuconfig" system, so that editing 
packages directly isn't required;

* supporting cross-building and avoiding the [flawed] assumption that the 
micro-architecture of the build server is in any way related to the processor 
type of the target machine(s);

* integration into the OpenWrt CI/CD tests;

* making the kernel support as secure/robust as possible (i.e. avoiding an 
ill-behaved application taking down the kernel, since this is a firewall after 
all);

* avoiding conflict with other existing module or package functionality;

* avoiding, to the extent possible, introducing one-off toolchain dependencies 
that unnecessarily complicate the build ecosystem;

To this end, I'm asking the mailing list for guidance on the best packaging 
practices that satisfy these goals.  I'm willing to do whatever heavy lifting 
that's within my ability.

I have some related questions.

1. OpenWrt already bakes "vfio.ko" and "vfio-pci.ko" here:

https://github.com/openwrt/openwrt/blob/master/package/kernel/linux/modules/virt.mk#L77-L117

   but does so with "CONFIG_VFIO_PCI_IGD=y", which seems to be specifically for 
VGA acceleration of guests in a virtualized environment.  That seems to be an 
odd corner case, and unlikely given that OpenWrt almost always runs on headless 
hardware.  Should this be reverted?

2. "vfio.ko" is built with "CONFIG_VFIO_NOIOMMU=y", which seems insecure.  Can 
this be reverted?

3. Is "uio_pci_generic.ko" worth the potential insecurity/instability of a 
misbehaving application?  My understanding is that it's only needed on SR-IOV 
hardware where MSI/MSI-X interrupts aren't supported: is there even any current 
hardware that doesn't support MSI/MSI-X?  Or am I misunderstanding the use case?

4. Can most functionality be achieved with VFIO + IOMMU support?

5. I've seen packaging for the "iommu_v2.ko" module done here:

https://github.com/k13132/openwrt-dpdk/blob/main/packages/kmod-iommu_v2/Makefile#L22-L42

   Is this potentially useful?  What platforms/architectures use this driver?

6. Hand editing a wrapper for dpdk.tar.gz is a non-starter.  I'd rather add 
Kconfig adornments to OpenWrt packaging for the wrapper so that options for 
"-Denable_drivers=" and "-Dcpu_instruction_set=" can be passed in once global 
build options for OpenWrt have been selected.  Defaulting the instruction set 
to the build host is going to be wrong at least some of the time, if not most 
of the time.  For x86_64, what is a decent compromise for a micro-architecture 
that will build and run on most AMD and Intel hardware?  What's a decent 
baseline for an ARM64 micro-architecture that will build and run on most ARM 
hardware?

7. Many embedded systems don't build with glibc because it's too bloated (and 
because critical fixes sometimes take too long to roll out), and instead use 
MUSL, eglibc, or uClibc (although the last one seems to be waning).  Only glibc 
supports  from what I can tell.  Can broader support for other C 
runtimes be added?  Can RTE_BACKTRACE be made a parameter or conditionally 
defined based on the runtime headers?  (autotools would be and HAVE_EXECINFO_H 
would be really handy here, but I'm not sure how to make this play well with 
meson/ninja, and truth be told I'm an old school Makefile + autotools 
knuckle-dragger).

8. How do I validate that DPDK is properly being built with the cross-tools and 
not native tools?  Even when building x86_64 targets on an x86_64 build host, 
we end up using a custom toolchain and not the "native" compiler that comes 
with the distro.

9. What is the parity between AMD64 and ARM64?  Do both platforms offer equal 
functionality and security, if not performance?

10. Who else is using DPDK with OpenWrt that is open to collaboration?

11. What is the user-space TCP/IP stack of choice (or reference) for use with 
DPDK?

Thanks,

-Philip

Re: DPDK packaging and OpenWrt

[Stephen Hemminger]

On Tue, 16 May 2023 13:18:40 -0600
Philip Prindeville  wrote:

> Hi,
> 
> I'm a packaging maintainer for some of the OpenWrt ancillary packages, and 
> I'm looking at upstreaming DPDK support into OpenWrt.  Apologies in advance 
> if this is a bit dense (a brain dump) or hops between too many topics.
> 
> I was looking at what's been done to date, and it seems there are a few 
> shortcomings which I hope to address.
> 
> Amongst them are:
> 
> * getting DPDK support into OpenWrt's main repo for the kmod's and into the 
> packages repo for the user-space support;

DPDK kernel modules are deprecated, creating more usage of them is problematic.

> 
> * making DPDK supported on all available architectures (i.e. agnostic, not 
> just x86_64 specific);
> 
> * integrating into the OpenWrt "make menuconfig" system, so that editing 
> packages directly isn't required;

Does openwrt build system support meson?

> * supporting cross-building and avoiding the [flawed] assumption that the 
> micro-architecture of the build server is in any way related to the processor 
> type of the target machine(s);
> 
> * integration into the OpenWrt CI/CD tests;
> 
> * making the kernel support as secure/robust as possible (i.e. avoiding an 
> ill-behaved application taking down the kernel, since this is a firewall 
> after all);

Not a problem with vfio

> 
> * avoiding conflict with other existing module or package functionality;
> 
> * avoiding, to the extent possible, introducing one-off toolchain 
> dependencies that unnecessarily complicate the build ecosystem;
> 
> To this end, I'm asking the mailing list for guidance on the best packaging 
> practices that satisfy these goals.  I'm willing to do whatever heavy lifting 
> that's within my ability.
> 
> I have some related questions.
> 
> 1. OpenWrt already bakes "vfio.ko" and "vfio-pci.ko" here:
> 
> https://github.com/openwrt/openwrt/blob/master/package/kernel/linux/modules/virt.mk#L77-L117
> 
>but does so with "CONFIG_VFIO_PCI_IGD=y", which seems to be specifically 
> for VGA acceleration of guests in a virtualized environment.  That seems to 
> be an odd corner case, and unlikely given that OpenWrt almost always runs on 
> headless hardware.  Should this be reverted?

Yes.

> 
> 2. "vfio.ko" is built with "CONFIG_VFIO_NOIOMMU=y", which seems insecure.  
> Can this be reverted?

No. Most of OpenWrt's systems do not have an IOMMU.

> 3. Is "uio_pci_generic.ko" worth the potential insecurity/instability of a 
> misbehaving application?  My understanding is that it's only needed on SR-IOV 
> hardware where MSI/MSI-X interrupts aren't supported: is there even any 
> current hardware that doesn't support MSI/MSI-X?  Or am I misunderstanding 
> the use case?

Use VFIO noiommu, it is more supported and tested upstream.  With PCI generic, 
no interrupts work.


> 4. Can most functionality be achieved with VFIO + IOMMU support?

Yes.

> 5. I've seen packaging for the "iommu_v2.ko" module done here:
> 
> https://github.com/k13132/openwrt-dpdk/blob/main/packages/kmod-iommu_v2/Makefile#L22-L42
> 
>Is this potentially useful?  What platforms/architectures use this driver?
> 
> 6. Hand editing a wrapper for dpdk.tar.gz is a non-starter.  I'd rather add 
> Kconfig adornments to OpenWrt packaging for the wrapper so that options for 
> "-Denable_drivers=" and "-Dcpu_instruction_set=" can be passed in once global 
> build options for OpenWrt have been selected.  Defaulting the instruction set 
> to the build host is going to be wrong at least some of the time, if not most 
> of the time.  For x86_64, what is a decent compromise for a 
> micro-architecture that will build and run on most AMD and Intel hardware?  
> What's a decent baseline for an ARM64 micro-architecture that will build and 
> run on most ARM hardware?
> 
> 7. Many embedded systems don't build with glibc because it's too bloated (and 
> because critical fixes sometimes take too long to roll out), and instead use 
> MUSL, eglibc, or uClibc (although the last one seems to be waning).  Only 
> glibc supports  from what I can tell.  Can broader support for 
> other C runtimes be added?  Can RTE_BACKTRACE be made a parameter or 
> conditionally defined based on the runtime headers?  (autotools would be and 
> HAVE_EXECINFO_H would be really handy here, but I'm not sure how to make this 
> play well with meson/ninja, and truth be told I'm an old school Makefile + 
> autotools knuckle-dragger).

You could do without backtrace, but then if DPDK applications you are flying 
blind.


> 8. How do I validate that DPDK is properly being built with the cross-tools 
> and not native tools?  Even when building x86_64 targets on an x86_64 build 
> host, we end up using a custom toolchain and not the "native" compiler that 
> comes with the distro.
> 
> 9. What is the parity between AMD64 and ARM64?  Do both platforms offer equal 
> functionality and security, if not performance?

Apples/Oranges.

> 10. Who else is using DPDK with Ope

Re: DPDK packaging and OpenWrt

[Garrett D'Amore]

On May 16, 2023 at 12:19 PM -0700, Philip Prindeville 
, wrote:
> Hi,
>
> I'm a packaging maintainer for some of the OpenWrt ancillary packages, and 
> I'm looking at upstreaming DPDK support into OpenWrt. Apologies in advance if 
> this is a bit dense (a brain dump) or hops between too many topics.
>
> I was looking at what's been done to date, and it seems there are a few 
> shortcomings which I hope to address.
>
> Amongst them are:
>
>
> I have some related questions.
>
> 1. OpenWrt already bakes "vfio.ko" and "vfio-pci.ko" here:
>
> https://github.com/openwrt/openwrt/blob/master/package/kernel/linux/modules/virt.mk#L77-L117
>
> but does so with "CONFIG_VFIO_PCI_IGD=y", which seems to be specifically for 
> VGA acceleration of guests in a virtualized environment. That seems to be an 
> odd corner case, and unlikely given that OpenWrt almost always runs on 
> headless hardware. Should this be reverted?
>
> 2. "vfio.ko" is built with "CONFIG_VFIO_NOIOMMU=y", which seems insecure. Can 
> this be reverted?
>
> 3. Is "uio_pci_generic.ko" worth the potential insecurity/instability of a 
> misbehaving application? My understanding is that it's only needed on SR-IOV 
> hardware where MSI/MSI-X interrupts aren't supported: is there even any 
> current hardware that doesn't support MSI/MSI-X? Or am I misunderstanding the 
> use case?

*Either* uio_pci_generic *or* vfio with NOIOMMU are required for the vary large 
number of systems that either lack an IOMMU (btw, that will be nearly all 
OpenWRT platforms!), or elect to run with the iommu unconfigured (one 
justification for doing that - apart from numerous software bugs and 
limitations — is that the IOMMU can slow down I/O. We actually recommend most 
of our customers that run dedicated systems run with the IOMMU disabled for 
this reason.)

vfio with  noiommu is preferable.
>
> 4. Can most functionality be achieved with VFIO + IOMMU support?

*If* you have an IOMMU, and you aren’t trying to eke the very last bits of 
performance, yes.  But as many systems don’t have an IOMMU, and as one of the 
main points of DPDK are extremely performance sensitive applications, I think 
the answer is more broadly, “no”.
> 11. What is the user-space TCP/IP stack of choice (or reference) for use with 
> DPDK?

IMO, if you’re using DPDK to run *TCP* applications then you’re probably 
misusing it — there isn’t a user land TCP stack that I would trust.  IP/UDP is 
something we do, and it works well, but I can tell you already it’s a pain to 
do *just* IP, because e.g. routing tables, ARP, etc. all have to be handled.

• Garrett

Re: DPDK packaging and OpenWrt

[Philip Prindeville]

Hey Stephen, it's been a while...


> On May 16, 2023, at 2:43 PM, Stephen Hemminger  
> wrote:
> 
> On Tue, 16 May 2023 13:18:40 -0600
> Philip Prindeville  wrote:
> 
>> Hi,
>> 
>> I'm a packaging maintainer for some of the OpenWrt ancillary packages, and 
>> I'm looking at upstreaming DPDK support into OpenWrt.  Apologies in advance 
>> if this is a bit dense (a brain dump) or hops between too many topics.
>> 
>> I was looking at what's been done to date, and it seems there are a few 
>> shortcomings which I hope to address.
>> 
>> Amongst them are:
>> 
>> * getting DPDK support into OpenWrt's main repo for the kmod's and into the 
>> packages repo for the user-space support;
> 
> DPDK kernel modules are deprecated, creating more usage of them is 
> problematic.


Well, some kernel modules are still required, aren't they?  What's been 
deprecated?


> 
>> 
>> * making DPDK supported on all available architectures (i.e. agnostic, not 
>> just x86_64 specific);
>> 
>> * integrating into the OpenWrt "make menuconfig" system, so that editing 
>> packages directly isn't required;
> 
> Does openwrt build system support meson?
> 
>> * supporting cross-building and avoiding the [flawed] assumption that the 
>> micro-architecture of the build server is in any way related to the 
>> processor type of the target machine(s);
>> 
>> * integration into the OpenWrt CI/CD tests;
>> 
>> * making the kernel support as secure/robust as possible (i.e. avoiding an 
>> ill-behaved application taking down the kernel, since this is a firewall 
>> after all);
> 
> Not a problem with vfio
> 
>> 
>> * avoiding conflict with other existing module or package functionality;
>> 
>> * avoiding, to the extent possible, introducing one-off toolchain 
>> dependencies that unnecessarily complicate the build ecosystem;
>> 
>> To this end, I'm asking the mailing list for guidance on the best packaging 
>> practices that satisfy these goals.  I'm willing to do whatever heavy 
>> lifting that's within my ability.
>> 
>> I have some related questions.
>> 
>> 1. OpenWrt already bakes "vfio.ko" and "vfio-pci.ko" here:
>> 
>> https://github.com/openwrt/openwrt/blob/master/package/kernel/linux/modules/virt.mk#L77-L117
>> 
>>   but does so with "CONFIG_VFIO_PCI_IGD=y", which seems to be specifically 
>> for VGA acceleration of guests in a virtualized environment.  That seems to 
>> be an odd corner case, and unlikely given that OpenWrt almost always runs on 
>> headless hardware.  Should this be reverted?
> 
> Yes.


Okay, thanks.


> 
>> 
>> 2. "vfio.ko" is built with "CONFIG_VFIO_NOIOMMU=y", which seems insecure.  
>> Can this be reverted?
> 
> No. Most of OpenWrt's systems do not have an IOMMU.


And most of OpenWrt isn't going to need DPDK, either.  We're thinking of Xeon, 
Xeon-D, and Atom64 (C26xx) based Intel hardware, or high-end multicore ARM64 
designs like the Traverse Technologies ten64.

In other words, Enterprise-class firewalls and data center appliances.


> 
>> 3. Is "uio_pci_generic.ko" worth the potential insecurity/instability of a 
>> misbehaving application?  My understanding is that it's only needed on 
>> SR-IOV hardware where MSI/MSI-X interrupts aren't supported: is there even 
>> any current hardware that doesn't support MSI/MSI-X?  Or am I 
>> misunderstanding the use case?
> 
> Use VFIO noiommu, it is more supported and tested upstream.  With PCI 
> generic, no interrupts work.


What is the risk/reward of using CONFIG_NOIOMMU=n?  It's a non-trivial bit of 
logic to include in a processor design: it must have had some scenario where it 
would be useful otherwise that's a lot of wasted gates...


> 
>> 4. Can most functionality be achieved with VFIO + IOMMU support?
> 
> Yes.
> 
>> 5. I've seen packaging for the "iommu_v2.ko" module done here:
>> 
>> https://github.com/k13132/openwrt-dpdk/blob/main/packages/kmod-iommu_v2/Makefile#L22-L42
>> 
>>   Is this potentially useful?  What platforms/architectures use this driver?
>> 
>> 6. Hand editing a wrapper for dpdk.tar.gz is a non-starter.  I'd rather add 
>> Kconfig adornments to OpenWrt packaging for the wrapper so that options for 
>> "-Denable_drivers=" and "-Dcpu_instruction_set=" can be passed in once 
>> global build options for OpenWrt have been selected.  Defaulting the 
>> instruction set to the build host is going to be wrong at least some of the 
>> time, if not most of the time.  For x86_64, what is a decent compromise for 
>> a micro-architecture that will build and run on most AMD and Intel hardware? 
>>  What's a decent baseline for an ARM64 micro-architecture that will build 
>> and run on most ARM hardware?
>> 
>> 7. Many embedded systems don't build with glibc because it's too bloated 
>> (and because critical fixes sometimes take too long to roll out), and 
>> instead use MUSL, eglibc, or uClibc (although the last one seems to be 
>> waning).  Only glibc supports  from what I can tell.  Can 
>> broader support for other C runtimes be added?  Can RTE_BACKTR

Re: DPDK packaging and OpenWrt

[Philip Prindeville]

> On May 16, 2023, at 5:06 PM, Garrett D'Amore  wrote:
> 
> On May 16, 2023 at 12:19 PM -0700, Philip Prindeville 
> , wrote:
> [snip]
> 
> 3. Is "uio_pci_generic.ko" worth the potential insecurity/instability of a 
> misbehaving application? My understanding is that it's only needed on SR-IOV 
> hardware where MSI/MSI-X interrupts aren't supported: is there even any 
> current hardware that doesn't support MSI/MSI-X? Or am I misunderstanding the 
> use case? 
> *Either* uio_pci_generic *or* vfio with NOIOMMU are required for the vary 
> large number of systems that either lack an IOMMU (btw, that will be nearly 
> all OpenWRT platforms!), or elect to run with the iommu unconfigured (one 
> justification for doing that - apart from numerous software bugs and 
> limitations — is that the IOMMU can slow down I/O. We actually recommend most 
> of our customers that run dedicated systems run with the IOMMU disabled for 
> this reason.)
> 
> vfio with  noiommu is preferable.


I could build with CONFIG_NOIOMMU=n and then package the modprobe .conf file 
(or the grub command-line, etc) to have enable_unsafe_noiommu_mode=1, right?

This would accomplish the same thing at run-time, but allow the module to be 
built to be used either with or without an IOMMU?

That's per:

https://dpdk-guide.gitlab.io/dpdk-guide/setup/binding.html

But I don't know how recent that advice is...


> 
> 4. Can most functionality be achieved with VFIO + IOMMU support? 
> *If* you have an IOMMU, and you aren’t trying to eke the very last bits of 
> performance, yes.  But as many systems don’t have an IOMMU, and as one of the 
> main points of DPDK are extremely performance sensitive applications, I think 
> the answer is more broadly, “no”.
> 11. What is the user-space TCP/IP stack of choice (or reference) for use with 
> DPDK? 
> IMO, if you’re using DPDK to run *TCP* applications then you’re probably 
> misusing it — there isn’t a user land TCP stack that I would trust.  IP/UDP 
> is something we do, and it works well, but I can tell you already it’s a pain 
> to do *just* IP, because e.g. routing tables, ARP, etc. all have to be 
> handled. 
> • Garrett


Yeah, good point.  Are there shims to use with FRR, lldpd, et al for example?

Re: DPDK packaging and OpenWrt

[Stephen Hemminger]

On Tue, 16 May 2023 17:24:21 -0600
Philip Prindeville  wrote:

> >> * getting DPDK support into OpenWrt's main repo for the kmod's and into 
> >> the packages repo for the user-space support;  
> > 
> > DPDK kernel modules are deprecated, creating more usage of them is 
> > problematic.  
> 
> 
> Well, some kernel modules are still required, aren't they?  What's been 
> deprecated?

igb_uio and kni are on the chopping block

Re: DPDK packaging and OpenWrt

[Stephen Hemminger]

On Tue, 16 May 2023 17:24:21 -0600
Philip Prindeville  wrote:

> >> 11. What is the user-space TCP/IP stack of choice (or reference) for use 
> >> with DPDK?  
> > 
> > No user-space TCP/IP stack is really robust and that great.
> > VPP has one but it is likely to be specific to using VPP and not sure if 
> > you want to go there.
> > I don't think Fedora/Suse/Debian/Ubuntu have packaged any userspace TCP 
> > yet.  
> 
> 
> Not robust how?  In terms of performance, security, handling error 
> conditions, having complete feature handlings... ?

TCP with all the features is very complex, heck Linux is still fixing corner 
cases.
Sure if you want one socket to send an email or print job, then sure. But doing 
something
at DPDK kind of performance is quite complex.

RE: [PATCH v4] net/iavf: add devargs to control watchdog

[Zhang, Qi Z]

> -Original Message-
> From: Zeng, ZhichaoX 
> Sent: Monday, May 15, 2023 2:54 PM
> To: dev@dpdk.org
> Cc: Zhang, Qi Z ; Zeng, ZhichaoX
> ; Yang, Qiming ; Wu,
> Wenjun1 ; Su, Simei ; Zhang,
> Yuying ; Xing, Beilei ; Wu,
> Jingjing 
> Subject: [PATCH v4] net/iavf: add devargs to control watchdog
> 
> This patch enables the watchdog to detect VF FLR when the link state
> changes to down, and the default period is 2000us as defined by
> IAVF_DEV_WATCHDOG_PERIOD.
> 
> In addition, the 'watchdog_period' devargs was added to adjust the
> watchdog period(microseconds), or set to 0 to disable the watchdog.
> 
> Signed-off-by: Zhichao Zeng 

Acked-by: Qi Zhang 

Applied to dpdk-next-net-intel.

Thanks
Qi

RE: [PATCH v2] net/i40e: remove redundant judgment

[Zhang, Qi Z]

> -Original Message-
> From: Feifei Wang 
> Sent: Tuesday, May 16, 2023 9:54 AM
> To: Zhang, Qi Z ; Richardson, Bruce
> ; Konstantin Ananyev
> ; Zhang, Yuying
> ; Xing, Beilei ; David
> Christensen ; Ruifeng Wang
> 
> Cc: dev@dpdk.org; nd ; Honnappa Nagarahalli
> ; nd 
> Subject: RE: [PATCH v2] net/i40e: remove redundant judgment
> 
> > -Original Message-
> > From: Zhang, Qi Z 
> > Sent: Monday, May 15, 2023 9:59 AM
> > To: Zhang, Qi Z ; Feifei Wang
> > ; Richardson, Bruce
> > ; Konstantin Ananyev
> > ; Zhang, Yuying
> > ; Xing, Beilei ; David
> > Christensen ; Ruifeng Wang
> > 
> > Cc: dev@dpdk.org; nd ; Honnappa Nagarahalli
> > 
> > Subject: RE: [PATCH v2] net/i40e: remove redundant judgment
> >
> >
> >
> > > -Original Message-
> > > From: Zhang, Qi Z 
> > > Sent: Thursday, April 27, 2023 3:38 PM
> > > To: Feifei Wang ; Richardson, Bruce
> > > ; Konstantin Ananyev
> > > ; Zhang, Yuying
> > > ; Xing, Beilei ;
> > > David Christensen ; Ruifeng Wang
> > > 
> > > Cc: dev@dpdk.org; n...@arm.com; Honnappa Nagarahalli
> > > 
> > > Subject: RE: [PATCH v2] net/i40e: remove redundant judgment
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Feifei Wang 
> > > > Sent: Tuesday, March 28, 2023 3:28 PM
> > > > To: Richardson, Bruce ; Konstantin
> > > > Ananyev ; Zhang, Yuying
> > > > ; Xing, Beilei ;
> > > > David Christensen ; Ruifeng Wang
> > > > 
> > > > Cc: dev@dpdk.org; n...@arm.com; Feifei Wang
> ;
> > > > Honnappa Nagarahalli 
> > > > Subject: [PATCH v2] net/i40e: remove redundant judgment
> > > >
> > > > Merged variable updates under the same condition. It reduces branch.
> > > >
> > > > In ampere-altra, there is no performance improvement with this patch.
> > > > In x86 sse and avx2 path, there is also no performance improvement.
> > >
> > > Thanks for sharing the results. While the code implements some best
> > > practices, such as reducing branching and adding compiler hints,
> > > which should generally improve performance, it's not necessary to
> > > highlight that it didn't provide benefits on certain specific platforms.
> > >
> > > Would it be ok to remove the last two lines when merging the patch?
> >
> > Ping
> >
> Sorry for I did not reply this. I agree with this when  merging the patch.
> Thanks for the comments~.
> > >
> > > Otherwise
> > > Acked-by: Qi Zhang 

Applied to dpdk-next-net-intel.

Thanks
Qi

RE: [PATCH v3] doc: comment VF does not support multi-process

[Ye, MingjinX]

> -Original Message-
> From: Stephen Hemminger 
> Sent: 2023年5月16日 23:18
> To: Ye, MingjinX 
> Cc: dev@dpdk.org; Yang, Qiming ;
> sta...@dpdk.org; Zhou, YidingX ; Wu, Wenjun1
> 
> Subject: Re: [PATCH v3] doc: comment VF does not support multi-process
> 
> On Tue, 16 May 2023 10:22:05 +
> Mingjin Ye  wrote:
> 
> > Announcing that multi-process is not supported
> >
> > Signed-off-by: Mingjin Ye 
> > ---
> > v2: Modify issue description reason.
> > ---
> > V3: Modify description.
> > ---
> >  doc/guides/nics/ixgbe.rst | 6 ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/doc/guides/nics/ixgbe.rst b/doc/guides/nics/ixgbe.rst
> > index b1d77ab7ab..816d614c33 100644
> > --- a/doc/guides/nics/ixgbe.rst
> > +++ b/doc/guides/nics/ixgbe.rst
> > @@ -461,3 +461,9 @@ show bypass config  Show the bypass configuration
> > for a bypass enabled NIC using the lowest port on the NIC::
> >
> > testpmd> show bypass config (port_id)
> > +
> > +VF driver does not support multi-process
> > +
> > +
> > +The VF driver does not support multi-process. And some function
> > +pointers in the case of multi-process are not set correctly.
> 
> This is best done by updating doc/guides/nic/features/ixgbe_vf.ini
> 
> That is enough. Don't need to add note in ixgbe.rst.

I will send the v4 version as soon as possible with a better solution.

RE: [PATCH] net/e1000: report VLAN extend capability for 82576

[Zhang, Qi Z]

> -Original Message-
> From: Akihiko Odaki 
> Sent: Friday, April 14, 2023 7:47 PM
> To: Su, Simei ; Wu, Wenjun1 
> Cc: dev@dpdk.org; Akihiko Odaki 
> Subject: [PATCH] net/e1000: report VLAN extend capability for 82576
> 
> 82576 also has exended VLAN support.
> 
> Signed-off-by: Akihiko Odaki 
> ---
>  drivers/net/e1000/igb_rxtx.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/e1000/igb_rxtx.c b/drivers/net/e1000/igb_rxtx.c index
> f32dee46df..25ad9eb4e5 100644
> --- a/drivers/net/e1000/igb_rxtx.c
> +++ b/drivers/net/e1000/igb_rxtx.c
> @@ -1648,7 +1648,8 @@ igb_get_rx_port_offloads_capa(struct rte_eth_dev
> *dev)
> RTE_ETH_RX_OFFLOAD_SCATTER |
> RTE_ETH_RX_OFFLOAD_RSS_HASH;
> 
> - if (hw->mac.type == e1000_i350 ||
> + if (hw->mac.type == e1000_82576 ||
> + hw->mac.type == e1000_i350 ||
>   hw->mac.type == e1000_i210 ||
>   hw->mac.type == e1000_i211)
>   rx_offload_capa |= RTE_ETH_RX_OFFLOAD_VLAN_EXTEND;
> --
> 2.40.0

Acked-by: Qi Zhang 

Applied to dpdk-next-net-intel.

Thanks
Qi

Reminder - DPDK Techboard Meeting - Tomorrow 5/17, 8am PDT/11am EDT/1500h UTC

[Nathan Southern]

Good evening,

This is a reminder that tomorrow 5/17 at 8am PDT/11am EDT/1500h UTC DPDK
has its bi-weekly tech board call.  Here is a read-only copy of the agenda:

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

And you may log in at:

http://jit.si/dpdk

Thanks and we look forward to seeing you soon,

Nathan

Nathan C. Southern, Project Coordinator

Data Plane Development Kit

The Linux Foundation

248.835.4812 (mobile)

nsouth...@linuxfoundation.org

[PATCH] net/e1000/base: add new devices

[Qiming Yang]

Added new device ids for I219 NIC.

Signed-off-by: Nir Efrati 
Signed-off-by: Qiming Yang 
---
 drivers/net/e1000/base/e1000_api.c | 5 +
 drivers/net/e1000/base/e1000_hw.h  | 4 
 2 files changed, 9 insertions(+)

diff --git a/drivers/net/e1000/base/e1000_api.c 
b/drivers/net/e1000/base/e1000_api.c
index 6a2376f40f..5e0603d80e 100644
--- a/drivers/net/e1000/base/e1000_api.c
+++ b/drivers/net/e1000/base/e1000_api.c
@@ -292,8 +292,13 @@ s32 e1000_set_mac_type(struct e1000_hw *hw)
break;
case E1000_DEV_ID_PCH_ADL_I219_LM16:
case E1000_DEV_ID_PCH_ADL_I219_V16:
+   case E1000_DEV_ID_PCH_RPL_I219_LM23:
+   case E1000_DEV_ID_PCH_RPL_I219_V23:
+   mac->type = e1000_pch_tgp;
case E1000_DEV_ID_PCH_ADL_I219_LM17:
case E1000_DEV_ID_PCH_ADL_I219_V17:
+   case E1000_DEV_ID_PCH_RPL_I219_LM22:
+   case E1000_DEV_ID_PCH_RPL_I219_V22:
mac->type = e1000_pch_adp;
break;
case E1000_DEV_ID_82575EB_COPPER:
diff --git a/drivers/net/e1000/base/e1000_hw.h 
b/drivers/net/e1000/base/e1000_hw.h
index 4e93855e7a..601f0a1889 100644
--- a/drivers/net/e1000/base/e1000_hw.h
+++ b/drivers/net/e1000/base/e1000_hw.h
@@ -128,6 +128,10 @@ struct e1000_hw;
 #define E1000_DEV_ID_PCH_ADL_I219_V16  0x1A1F
 #define E1000_DEV_ID_PCH_ADL_I219_LM17 0x1A1C
 #define E1000_DEV_ID_PCH_ADL_I219_V17  0x1A1D
+#define E1000_DEV_ID_PCH_RPL_I219_LM23  0x0DC5
+#define E1000_DEV_ID_PCH_RPL_I219_V23   0x0DC6
+#define E1000_DEV_ID_PCH_RPL_I219_LM22  0x0DC7
+#define E1000_DEV_ID_PCH_RPL_I219_V22   0x0DC8
 #define E1000_DEV_ID_82576 0x10C9
 #define E1000_DEV_ID_82576_FIBER   0x10E6
 #define E1000_DEV_ID_82576_SERDES  0x10E7
-- 
2.25.1

RE: [PATCH v1] eventdev/crypto: refactor circular buffer size

[Gujjar, Abhinandan S]

> -Original Message-
> From: Kundapura, Ganapati 
> Sent: Tuesday, April 18, 2023 2:46 PM
> To: jer...@marvell.com; Gujjar, Abhinandan S
> ; dev@dpdk.org
> Cc: Naga Harish K, S V ; Jayatheerthan, Jay
> 
> Subject: [PATCH v1] eventdev/crypto: refactor circular buffer size
> 
> In case of CRYPTO_ADAPTER_OPS_BUFFER_SZ is modified,
> eca_circular_buffer_space_for_batch() also needs to be updated to check
> maximum number of crypto ops can be accommodated in circular buffer
> when CPM becomes busy.
> 
> Defined MAX_OPS_IN_BUFFER which contains size for batch of dequeued
> events and redefined CRYPTO_ADAPTER_OPS_BUFFER_SZ in terms of
> MAX_OPS_IN_BUFFER.
> 
> This patch makes eca_circular_buffer_space_for_batch() independent of
> circular buffer changes.
> 
> Signed-off-by: Ganapati Kundapura 

Acked-by: Abhinandan Gujjar 

> 
> diff --git a/lib/eventdev/rte_event_crypto_adapter.c
> b/lib/eventdev/rte_event_crypto_adapter.c
> index f6c1e53..52a28e5 100644
> --- a/lib/eventdev/rte_event_crypto_adapter.c
> +++ b/lib/eventdev/rte_event_crypto_adapter.c
> @@ -25,7 +25,14 @@
>  #define CRYPTO_ADAPTER_MEM_NAME_LEN 32
>  #define CRYPTO_ADAPTER_MAX_EV_ENQ_RETRIES 100
> 
> -#define CRYPTO_ADAPTER_OPS_BUFFER_SZ (BATCH_SIZE + BATCH_SIZE)
> +/* MAX_OPS_IN_BUFFER contains size for  batch of dequeued events */
> +#define MAX_OPS_IN_BUFFER BATCH_SIZE
> +
> +/* CRYPTO_ADAPTER_OPS_BUFFER_SZ to accommodate
> MAX_OPS_IN_BUFFER +
> + * additional space for one batch
> + */
> +#define CRYPTO_ADAPTER_OPS_BUFFER_SZ (MAX_OPS_IN_BUFFER +
> BATCH_SIZE)
> +
>  #define CRYPTO_ADAPTER_BUFFER_SZ 1024
> 
>  /* Flush an instance's enqueue buffers every
> CRYPTO_ENQ_FLUSH_THRESHOLD @@ -188,7 +195,8 @@
> eca_circular_buffer_batch_ready(struct crypto_ops_circular_buffer *bufp)
> static inline bool  eca_circular_buffer_space_for_batch(struct
> crypto_ops_circular_buffer *bufp)  {
> - return (bufp->size - bufp->count) >= BATCH_SIZE;
> + /* circular buffer can have atmost MAX_OPS_IN_BUFFER */
> + return (bufp->size - bufp->count) >= MAX_OPS_IN_BUFFER;
>  }
> 
>  static inline void
> --
> 2.6.4

Re: [PATCH v2] eventdev/eth_tx: fix runtime parameter test

[Jerin Jacob]

On Tue, May 2, 2023 at 11:27 AM Naga Harish K S V
 wrote:
>
> TX adapter capability check logic is simplified.
> The UT has been updated to skip the test, if the API
> to set runtime parameters is not supported.
>
> Fixes: 1d176c7add08581 ("eventdev/eth_tx: support runtime set/get parameters")
>
> Signed-off-by: Naga Harish K S V 
> ---
>  app/test/test_event_eth_tx_adapter.c| 11 ++---
>  lib/eventdev/rte_event_eth_tx_adapter.c | 33 +
>  2 files changed, 14 insertions(+), 30 deletions(-)


Please fix
Is it candidate for Cc: sta...@dpdk.org backport?
eventdev/eth_tx: fix runtime parameter test

Invalid patch(es) found - checked 1 patch
check-git-log failed

### [PATCH] eventdev/eth_tx: fix runtime parameter test

WARNING:BAD_FIXES_TAG: Please use correct Fixes: style 'Fixes: <12
chars of sha1> ("")' - ie: 'Fixes: 1d176c7add08
("eventdev/eth_tx: support runtime set/get parameters")'
#10:
Fixes: 1d176c7add08581 ("eventdev/eth_tx: support runtime set/get parameters")

total: 0 errors, 1 warnings, 90 lines checked

0/1 valid patch
checkpatch failed

>
> diff --git a/app/test/test_event_eth_tx_adapter.c 
> b/app/test/test_event_eth_tx_adapter.c
> index 4e1d821bf9..616c972ac0 100644
> --- a/app/test/test_event_eth_tx_adapter.c
> +++ b/app/test/test_event_eth_tx_adapter.c
> @@ -800,13 +800,17 @@ tx_adapter_queue_start_stop(void)
>  static int
>  tx_adapter_set_get_params(void)
>  {
> -   int err;
> +   int err, rc;
> struct rte_event_eth_tx_adapter_runtime_params in_params;
> struct rte_event_eth_tx_adapter_runtime_params out_params;
>
> err = rte_event_eth_tx_adapter_queue_add(TEST_INST_ID,
>  TEST_ETHDEV_ID,
>  0);
> +   if (err == -ENOTSUP) {
> +   rc = TEST_SKIPPED;
> +   goto skip;
> +   }
> TEST_ASSERT(err == 0, "Expected 0 got %d", err);
>
> err = rte_event_eth_tx_adapter_runtime_params_init(&in_params);
> @@ -916,13 +920,14 @@ tx_adapter_set_get_params(void)
> TEST_ASSERT(in_params.flush_threshold == out_params.flush_threshold,
> "Expected %u got %u",
> in_params.flush_threshold, out_params.flush_threshold);
> -
> +   rc = TEST_SUCCESS;
> +skip:
> err = rte_event_eth_tx_adapter_queue_del(TEST_INST_ID,
>  TEST_ETHDEV_ID,
>  0);
> TEST_ASSERT(err == 0, "Expected 0 got %d", err);
>
> -   return TEST_SUCCESS;
> +   return rc;
>  }
>
>  static int
> diff --git a/lib/eventdev/rte_event_eth_tx_adapter.c 
> b/lib/eventdev/rte_event_eth_tx_adapter.c
> index 131e11e01d..360d5caf6a 100644
> --- a/lib/eventdev/rte_event_eth_tx_adapter.c
> +++ b/lib/eventdev/rte_event_eth_tx_adapter.c
> @@ -1310,36 +1310,15 @@ rte_event_eth_tx_adapter_runtime_params_init(
>  }
>
>  static int
> -txa_caps_check(uint8_t id, struct txa_service_data *txa)
> +txa_caps_check(struct txa_service_data *txa)
>  {
> -   uint32_t caps = 0;
> -   struct rte_eth_dev *eth_dev = NULL;
> -   struct txa_service_ethdev *tdi;
> -   int i;
> -
> if (!txa->dev_count)
> return -EINVAL;
>
> -   /* The eth_dev used is always the same type.
> -* Hence first valid eth_dev is taken.
> -*/
> -   for (i = 0; i < txa->dev_count; i++) {
> -   tdi = &txa->txa_ethdev[i];
> -   if (tdi->nb_queues) {
> -   eth_dev = tdi->dev;
> -   break;
> -   }
> -   }
> -   if (eth_dev == NULL)
> -   return -EINVAL;
> -
> -   if (txa_dev_caps_get(id))
> -   txa_dev_caps_get(id)(txa_evdev(id), eth_dev, &caps);
> -
> -   if (caps & RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT)
> -   return -ENOTSUP;
> +   if (txa->service_id != TXA_INVALID_SERVICE_ID)
> +   return 0;
>
> -   return 0;
> +   return -ENOTSUP;
>  }
>
>  int
> @@ -1361,7 +1340,7 @@ rte_event_eth_tx_adapter_runtime_params_set(uint8_t id,
> if (txa == NULL)
> return -EINVAL;
>
> -   ret = txa_caps_check(id, txa);
> +   ret = txa_caps_check(txa);
> if (ret)
> return ret;
>
> @@ -1392,7 +1371,7 @@ rte_event_eth_tx_adapter_runtime_params_get(uint8_t id,
> if (txa == NULL)
> return -EINVAL;
>
> -   ret = txa_caps_check(id, txa);
> +   ret = txa_caps_check(txa);
> if (ret)
> return ret;
>
> --
> 2.23.0
>

RE: [PATCH v2] eventdev/eth_tx: fix runtime parameter test

[Naga Harish K, S V]

> -Original Message-
> From: Jerin Jacob 
> Sent: Wednesday, May 17, 2023 10:49 AM
> To: Naga Harish K, S V 
> Cc: jer...@marvell.com; dev@dpdk.org; Jayatheerthan, Jay
> 
> Subject: Re: [PATCH v2] eventdev/eth_tx: fix runtime parameter test
> 
> On Tue, May 2, 2023 at 11:27 AM Naga Harish K S V
>  wrote:
> >
> > TX adapter capability check logic is simplified.
> > The UT has been updated to skip the test, if the API to set runtime
> > parameters is not supported.
> >
> > Fixes: 1d176c7add08581 ("eventdev/eth_tx: support runtime set/get
> > parameters")
> >
> > Signed-off-by: Naga Harish K S V 
> > ---
> >  app/test/test_event_eth_tx_adapter.c| 11 ++---
> >  lib/eventdev/rte_event_eth_tx_adapter.c | 33
> > +
> >  2 files changed, 14 insertions(+), 30 deletions(-)
> 
> 
> Please fix
> Is it candidate for Cc: sta...@dpdk.org backport?
> eventdev/eth_tx: fix runtime parameter test
> 

This patch (feature) is added in DPDK 23.03 release.
So, thinking this fix may need not be backported.
Please let me know if it still needs to be backported.

> Invalid patch(es) found - checked 1 patch check-git-log failed
> 
> ### [PATCH] eventdev/eth_tx: fix runtime parameter test
> 
> WARNING:BAD_FIXES_TAG: Please use correct Fixes: style 'Fixes: <12 chars
> of sha1> ("")' - ie: 'Fixes: 1d176c7add08
> ("eventdev/eth_tx: support runtime set/get parameters")'
> #10:
> Fixes: 1d176c7add08581 ("eventdev/eth_tx: support runtime set/get
> parameters")
> 
> total: 0 errors, 1 warnings, 90 lines checked
> 
> 0/1 valid patch
> checkpatch failed
> 
> >
> > diff --git a/app/test/test_event_eth_tx_adapter.c
> > b/app/test/test_event_eth_tx_adapter.c
> > index 4e1d821bf9..616c972ac0 100644
> > --- a/app/test/test_event_eth_tx_adapter.c
> > +++ b/app/test/test_event_eth_tx_adapter.c
> > @@ -800,13 +800,17 @@ tx_adapter_queue_start_stop(void)  static int
> >  tx_adapter_set_get_params(void)
> >  {
> > -   int err;
> > +   int err, rc;
> > struct rte_event_eth_tx_adapter_runtime_params in_params;
> > struct rte_event_eth_tx_adapter_runtime_params out_params;
> >
> > err = rte_event_eth_tx_adapter_queue_add(TEST_INST_ID,
> >  TEST_ETHDEV_ID,
> >  0);
> > +   if (err == -ENOTSUP) {
> > +   rc = TEST_SKIPPED;
> > +   goto skip;
> > +   }
> > TEST_ASSERT(err == 0, "Expected 0 got %d", err);
> >
> > err =
> > rte_event_eth_tx_adapter_runtime_params_init(&in_params);
> > @@ -916,13 +920,14 @@ tx_adapter_set_get_params(void)
> > TEST_ASSERT(in_params.flush_threshold ==
> out_params.flush_threshold,
> > "Expected %u got %u",
> > in_params.flush_threshold,
> > out_params.flush_threshold);
> > -
> > +   rc = TEST_SUCCESS;
> > +skip:
> > err = rte_event_eth_tx_adapter_queue_del(TEST_INST_ID,
> >  TEST_ETHDEV_ID,
> >  0);
> > TEST_ASSERT(err == 0, "Expected 0 got %d", err);
> >
> > -   return TEST_SUCCESS;
> > +   return rc;
> >  }
> >
> >  static int
> > diff --git a/lib/eventdev/rte_event_eth_tx_adapter.c
> > b/lib/eventdev/rte_event_eth_tx_adapter.c
> > index 131e11e01d..360d5caf6a 100644
> > --- a/lib/eventdev/rte_event_eth_tx_adapter.c
> > +++ b/lib/eventdev/rte_event_eth_tx_adapter.c
> > @@ -1310,36 +1310,15 @@
> rte_event_eth_tx_adapter_runtime_params_init(
> >  }
> >
> >  static int
> > -txa_caps_check(uint8_t id, struct txa_service_data *txa)
> > +txa_caps_check(struct txa_service_data *txa)
> >  {
> > -   uint32_t caps = 0;
> > -   struct rte_eth_dev *eth_dev = NULL;
> > -   struct txa_service_ethdev *tdi;
> > -   int i;
> > -
> > if (!txa->dev_count)
> > return -EINVAL;
> >
> > -   /* The eth_dev used is always the same type.
> > -* Hence first valid eth_dev is taken.
> > -*/
> > -   for (i = 0; i < txa->dev_count; i++) {
> > -   tdi = &txa->txa_ethdev[i];
> > -   if (tdi->nb_queues) {
> > -   eth_dev = tdi->dev;
> > -   break;
> > -   }
> > -   }
> > -   if (eth_dev == NULL)
> > -   return -EINVAL;
> > -
> > -   if (txa_dev_caps_get(id))
> > -   txa_dev_caps_get(id)(txa_evdev(id), eth_dev, &caps);
> > -
> > -   if (caps & RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT)
> > -   return -ENOTSUP;
> > +   if (txa->service_id != TXA_INVALID_SERVICE_ID)
> > +   return 0;
> >
> > -   return 0;
> > +   return -ENOTSUP;
> >  }
> >
> >  int
> > @@ -1361,7 +1340,7 @@
> rte_event_eth_tx_adapter_runtime_params_set(uint8_t id,
> > if (txa == NULL)
> > return -EINVAL;
> >
> > -   ret = txa_caps_check(id, txa);
> > +   ret = tx

[PATCH v2] app/dma-perf: introduce dma-perf application

[Cheng Jiang]

There are many high-performance DMA devices supported in DPDK now, and
these DMA devices can also be integrated into other modules of DPDK as
accelerators, such as Vhost. Before integrating DMA into applications,
developers need to know the performance of these DMA devices in various
scenarios and the performance of CPUs in the same scenario, such as
different buffer lengths. Only in this way can we know the target
performance of the application accelerated by using them. This patch
introduces a high-performance testing tool, which supports comparing the
performance of CPU and DMA in different scenarios automatically with a
pre-set config file. Memory Copy performance test are supported for now.

Signed-off-by: Cheng Jiang 
Signed-off-by: Jiayu Hu 
Signed-off-by: Yuan Wang 
Acked-by: Morten Brørup 
---
v2:
  added lcore/dmadev designation;
  added error case process;
  removed worker_threads parameter from config.ini;
  improved the logs;
  improved config file;

 app/meson.build   |   1 +
 app/test-dma-perf/benchmark.c | 471 
 app/test-dma-perf/config.ini  |  59 
 app/test-dma-perf/main.c  | 567 ++
 app/test-dma-perf/main.h  |  69 +
 app/test-dma-perf/meson.build |  17 +
 6 files changed, 1184 insertions(+)
 create mode 100644 app/test-dma-perf/benchmark.c
 create mode 100644 app/test-dma-perf/config.ini
 create mode 100644 app/test-dma-perf/main.c
 create mode 100644 app/test-dma-perf/main.h
 create mode 100644 app/test-dma-perf/meson.build

diff --git a/app/meson.build b/app/meson.build
index e32ea4bd5c..514cb2f7b2 100644
--- a/app/meson.build
+++ b/app/meson.build
@@ -19,6 +19,7 @@ apps = [
 'test-cmdline',
 'test-compress-perf',
 'test-crypto-perf',
+'test-dma-perf',
 'test-eventdev',
 'test-fib',
 'test-flow-perf',
diff --git a/app/test-dma-perf/benchmark.c b/app/test-dma-perf/benchmark.c
new file mode 100644
index 00..4e99ab9736
--- /dev/null
+++ b/app/test-dma-perf/benchmark.c
@@ -0,0 +1,471 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2023 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "main.h"
+
+#define MAX_DMA_CPL_NB 255
+
+#define TEST_WAIT_U_SECOND 1
+
+#define CSV_LINE_DMA_FMT "Scenario %u,%u,%s,%u,%u,%u,%" PRIu64 ",%.3lf,%.3lf\n"
+#define CSV_LINE_CPU_FMT "Scenario %u,%u,NA,%u,%u,%u,%" PRIu64 ",%.3lf,%.3lf\n"
+
+struct worker_info {
+   bool ready_flag;
+   bool start_flag;
+   bool stop_flag;
+   uint32_t total_cpl;
+   uint32_t test_cpl;
+};
+
+struct lcore_params {
+   uint8_t scenario_id;
+   unsigned int lcore_id;
+   char *dma_name;
+   uint16_t worker_id;
+   uint16_t dev_id;
+   uint32_t nr_buf;
+   uint16_t kick_batch;
+   uint32_t buf_size;
+   uint16_t test_secs;
+   struct rte_mbuf **srcs;
+   struct rte_mbuf **dsts;
+   struct worker_info worker_info;
+};
+
+static struct rte_mempool *src_pool;
+static struct rte_mempool *dst_pool;
+
+static volatile struct lcore_params *worker_params[MAX_WORKER_NB];
+
+#define PRINT_ERR(...) print_err(__func__, __LINE__, __VA_ARGS__)
+
+static inline int
+__rte_format_printf(3, 4)
+print_err(const char *func, int lineno, const char *format, ...)
+{
+   va_list ap;
+   int ret;
+
+   ret = fprintf(stderr, "In %s:%d - ", func, lineno);
+   va_start(ap, format);
+   ret += vfprintf(stderr, format, ap);
+   va_end(ap);
+
+   return ret;
+}
+
+static inline void
+calc_result(uint32_t buf_size, uint32_t nr_buf, uint16_t nb_workers, uint16_t 
test_secs,
+   uint32_t total_cnt, uint32_t *memory, uint32_t 
*ave_cycle,
+   float *bandwidth, float *mops)
+{
+   *memory = (buf_size * (nr_buf / nb_workers) * 2) / (1024 * 1024);
+   *ave_cycle = test_secs * rte_get_timer_hz() / total_cnt;
+   *bandwidth = (buf_size * 8 * (rte_get_timer_hz() / (float)*ave_cycle)) 
/ 10;
+   *mops = (float)rte_get_timer_hz() / *ave_cycle / 100;
+}
+
+static void
+output_result(uint8_t scenario_id, uint32_t lcore_id, char *dma_name, uint64_t 
ave_cycle,
+   uint32_t buf_size, uint32_t nr_buf, uint32_t memory,
+   float bandwidth, float mops, bool is_dma)
+{
+   if (is_dma)
+   printf("lcore %u, DMA %s:\n", lcore_id, dma_name);
+   else
+   printf("lcore %u\n", lcore_id);
+
+   printf("average cycles/op: %" PRIu64 ", buffer size: %u, nr_buf: %u, 
memory: %uMB, frequency: %" PRIu64 ".\n",
+   ave_cycle, buf_size, nr_buf, memory, 
rte_get_timer_hz());
+   printf("Average bandwidth: %.3lfGbps, MOps: %.3lf\n", bandwidth, mops);
+
+   if (is_dma)
+   snprintf(output_str[lcore_id], MAX_OUTPUT_STR_LEN, 
CSV_LINE_DMA_FMT,
+