Re: [dpdk-dev] [PATCH 3/3 v3] app/testpmd: support hardware offload to drop error packets

[Asaf Penso]

Regards,
Asaf Penso

>-Original Message-
>From: nipun.gu...@nxp.com 
>Sent: Friday, October 9, 2020 4:14 PM
>To: dev@dpdk.org
>Cc: NBU-Contact-Thomas Monjalon ;
>ferruh.yi...@intel.com; arybche...@solarflare.com;
>hemant.agra...@nxp.com; sachin.sax...@nxp.com; rohit@nxp.com;
>jerinjac...@gmail.com; step...@networkplumber.org; Asaf Penso
>; Nipun Gupta 
>Subject: [PATCH 3/3 v3] app/testpmd: support hardware offload to drop error
>packets
>
>From: Nipun Gupta 
>
>With DEV_RX_OFFLOAD_ERR_PKT_DROP now defined as an offload
>capability, and separate DEV_RX_ERR_PKT_DROP_OFFLOAD_ALL capability to
>drop all error packets in hardware, testpmd showcases this with a new added
>configuration option 'enable-hw-drop-err-all'.
>
>Signed-off-by: Nipun Gupta 
Reviewed-By: Asaf Penso 
>---
> app/test-pmd/parameters.c | 7 +++
> app/test-pmd/testpmd.c| 8 
> app/test-pmd/testpmd.h| 1 +
> doc/guides/testpmd_app_ug/run_app.rst | 4 
> 4 files changed, 20 insertions(+)
>
>diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c index
>1ead59579..508612426 100644
>--- a/app/test-pmd/parameters.c
>+++ b/app/test-pmd/parameters.c
>@@ -142,6 +142,7 @@ usage(char* progname)
>   printf("  --enable-hw-vlan-strip: enable hardware vlan strip.\n");
>   printf("  --enable-hw-vlan-extend: enable hardware vlan extend.\n");
>   printf("  --enable-hw-qinq-strip: enable hardware qinq strip.\n");
>+  printf("  --enable-hw-drop-err-all: enable hardware packet drop for
>+all error packets.\n");
>   printf("  --enable-drop-en: enable per queue packet drop.\n");
>   printf("  --disable-rss: disable rss.\n");
>   printf("  --port-topology=: set port topology
>(paired "
>@@ -631,6 +632,7 @@ launch_args_parse(int argc, char** argv)
>   { "enable-hw-vlan-strip",   0, 0, 0 },
>   { "enable-hw-vlan-extend",  0, 0, 0 },
>   { "enable-hw-qinq-strip",   0, 0, 0 },
>+  { "enable-hw-drop-err-all", 0, 0, 0 },
>   { "enable-drop-en",0, 0, 0 },
>   { "disable-rss",0, 0, 0 },
>   { "port-topology",  1, 0, 0 },
>@@ -1283,6 +1285,11 @@ launch_args_parse(int argc, char** argv)
>   rmv_interrupt = 0;
>   if (!strcmp(lgopts[opt_idx].name, "flow-isolate-all"))
>   flow_isolate_all = 1;
>+  if (!strcmp(lgopts[opt_idx].name,
>+  "enable-hw-drop-err-all")) {
>+  rx_err_pkt_drop_all = 1;
>+  }
>+
>   if (!strcmp(lgopts[opt_idx].name, "tx-offloads")) {
>   char *end = NULL;
>   n = strtoull(optarg, &end, 16);
>diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
>ccba71c07..c9e7397e6 100644
>--- a/app/test-pmd/testpmd.c
>+++ b/app/test-pmd/testpmd.c
>@@ -359,6 +359,11 @@ uint8_t lsc_interrupt = 1; /* enabled by default */
>  */
> uint8_t rmv_interrupt = 1; /* enabled by default */
>
>+/*
>+ * Drop all RX error packets on HW itself.
>+ */
>+uint8_t rx_err_pkt_drop_all = 0; /* disabled by default */
>+
> uint8_t hot_plug = 0; /**< hotplug disabled by default. */
>
> /* After attach, port setup is called on event or by iterator */ @@ -3359,6
>+3364,9 @@ init_port_config(void)
>   (rte_eth_devices[pid].data->dev_flags &
>RTE_ETH_DEV_INTR_RMV))
>   port->dev_conf.intr_conf.rmv = 1;
>+
>+  if (rx_err_pkt_drop_all)
>+  port->dev_conf.err_pkt_drop_conf.all = 1;
>   }
> }
>
>diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h index
>c7e7e41a9..eab154ed4 100644
>--- a/app/test-pmd/testpmd.h
>+++ b/app/test-pmd/testpmd.h
>@@ -314,6 +314,7 @@ extern uint8_t no_device_start; /**device-start" parameter */  extern volatile int test_done; /* stop packet
>forwarding when set to 1. */  extern uint8_t lsc_interrupt; /**< disabled by "-
>-no-lsc-interrupt" parameter */  extern uint8_t rmv_interrupt; /**< disabled
>by "--no-rmv-interrupt" parameter */
>+extern uint8_t rx_err_pkt_drop_all; /**< enabled by
>+"--enable-hw-drop-err-all" parameter */
> extern uint32_t event_print_mask;
> /**< set by "--print-event " and "--mask-event  parameters */
>extern bool setup_on_probe_event; /**< disabled by port setup-on iterator
>*/ diff --git a/doc/guides/testpmd_app_ug/run_app.rst
>b/doc/guides/testpmd_app_ug/run_app.rst
>index e2539f693..20f2f8083 100644
>--- a/doc/guides/testpmd_app_ug/run_app.rst
>+++ b/doc/guides/testpmd_app_ug/run_app.rst
>@@ -213,6 +213,10 @@ The command line options are:
>
> Enable hardware QINQ strip.
>
>+*  ``--enable-hw-drop-err-all``
>+
>+Enable hardware packet drop for any error packets
>+
> *   ``--enable-drop-en``
>
> Enable per-queue packet dro

Re: [dpdk-dev] [PATCH 1/4] common/octeontx2: add REE definitions and logging support

[Liron Himi]

Reviewed-by: Liron Himi 

-Original Message-
From: dev  On Behalf Of g...@marvell.com
Sent: Tuesday, 1 September 2020 15:25
To: Jerin Jacob Kollanukkaran ; Nithin Kumar Dabilpuram 
; tho...@monjalon.net; m...@ashroe.eu; 
nhor...@tuxdriver.com; bruce.richard...@intel.com; anatoly.bura...@intel.com; 
john.mcnam...@intel.com; marko.kovace...@intel.com
Cc: dev@dpdk.org; Smadar Fuks ; Dovrat Zifroni 
; Guy Kaneti ; or...@mellanox.com
Subject: [dpdk-dev] [PATCH 1/4] common/octeontx2: add REE definitions and 
logging support

From: Guy Kaneti 

Add REE mbox msg definitions, RVU and REE HW definitions

Signed-off-by: Guy Kaneti 
---
 drivers/common/octeontx2/hw/otx2_ree.h|  27 +
 drivers/common/octeontx2/hw/otx2_rvu.h|   5 +
 drivers/common/octeontx2/otx2_common.c|   1 +
 drivers/common/octeontx2/otx2_common.h|   5 +
 drivers/common/octeontx2/otx2_mbox.h  | 103 ++
 .../rte_common_octeontx2_version.map  |   1 +
 6 files changed, 142 insertions(+)
 create mode 100644 drivers/common/octeontx2/hw/otx2_ree.h

diff --git a/drivers/common/octeontx2/hw/otx2_ree.h 
b/drivers/common/octeontx2/hw/otx2_ree.h
new file mode 100644
index 0..b7481f125
--- /dev/null
+++ b/drivers/common/octeontx2/hw/otx2_ree.h
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright (C) 2020 Marvell International Ltd.
+ */
+
+#ifndef __OTX2_REE_HW_H__
+#define __OTX2_REE_HW_H__
+
+/* REE BAR0*/
+#define REE_AF_REEXM_MAX_MATCH (0x80c8)
+
+/* REE BAR02 */
+#define REE_LF_MISC_INT (0x300)
+#define REE_LF_DONE_INT (0x120)
+
+#define REE_AF_QUEX_GMCTL(a)(0x800 | (a) << 3)
+
+#define REE_AF_INT_VEC_RAS  (0x0ull)
+#define REE_AF_INT_VEC_RVU  (0x1ull)
+#define REE_AF_INT_VEC_QUE_DONE (0x2ull)
+#define REE_AF_INT_VEC_AQ   (0x3ull)
+
+/* ENUMS */
+
+#define REE_LF_INT_VEC_QUE_DONE(0x0ull)
+#define REE_LF_INT_VEC_MISC(0x1ull)
+
+#endif /* __OTX2_REE_HW_H__*/
diff --git a/drivers/common/octeontx2/hw/otx2_rvu.h 
b/drivers/common/octeontx2/hw/otx2_rvu.h
index 330bfb37f..072515207 100644
--- a/drivers/common/octeontx2/hw/otx2_rvu.h
+++ b/drivers/common/octeontx2/hw/otx2_rvu.h
@@ -130,6 +130,7 @@
 #define RVU_BLOCK_TYPE_RAD  (0xdull)
 #define RVU_BLOCK_TYPE_DFA  (0xeull)
 #define RVU_BLOCK_TYPE_HNA  (0xfull)
+#define RVU_BLOCK_TYPE_REE  (0xeull)
 
 #define RVU_BLOCK_ADDR_RVUM (0x0ull)
 #define RVU_BLOCK_ADDR_LMT  (0x1ull)
@@ -146,6 +147,8 @@
 #define RVU_BLOCK_ADDR_NDC2 (0xeull)
 #define RVU_BLOCK_ADDR_R_END(0x1full)
 #define RVU_BLOCK_ADDR_R_START  (0x14ull)
+#define RVU_BLOCK_ADDR_REE0 (0x14ull)
+#define RVU_BLOCK_ADDR_REE1 (0x15ull)
 
 #define RVU_VF_INT_VEC_MBOX (0x0ull)
 
@@ -167,6 +170,7 @@
 #define NPA_AF_BAR2_SEL(0x900ull)
 #define CPT_AF_BAR2_SEL(0x900ull)
 #define RVU_AF_BAR2_SEL(0x900ull)
+#define REE_AF_BAR2_SEL(0x900ull)
 
 #define AF_BAR2_ALIASX(a, b) \
(0x910ull | (uint64_t)(a) << 12 | (uint64_t)(b)) @@ -177,6 +181,7 @@
 #define NPA_AF_BAR2_ALIASX(a, b)   AF_BAR2_ALIASX(0, b)
 #define CPT_AF_BAR2_ALIASX(a, b)   AF_BAR2_ALIASX(a, b)
 #define RVU_AF_BAR2_ALIASX(a, b)   AF_BAR2_ALIASX(a, b)
+#define REE_AF_BAR2_ALIASX(a, b)   AF_BAR2_ALIASX(a, b)
 
 /* Structures definitions */
 
diff --git a/drivers/common/octeontx2/otx2_common.c 
b/drivers/common/octeontx2/otx2_common.c
index b292e999a..d23c50242 100644
--- a/drivers/common/octeontx2/otx2_common.c
+++ b/drivers/common/octeontx2/otx2_common.c
@@ -213,3 +213,4 @@ RTE_LOG_REGISTER(otx2_logtype_sso, pmd.event.octeontx2, 
NOTICE);  RTE_LOG_REGISTER(otx2_logtype_tim, pmd.event.octeontx2.timer, 
NOTICE);  RTE_LOG_REGISTER(otx2_logtype_dpi, pmd.raw.octeontx2.dpi, NOTICE);  
RTE_LOG_REGISTER(otx2_logtype_ep, pmd.raw.octeontx2.ep, NOTICE);
+RTE_LOG_REGISTER(otx2_logtype_ree, pmd.regex.octeontx2, NOTICE);
diff --git a/drivers/common/octeontx2/otx2_common.h 
b/drivers/common/octeontx2/otx2_common.h
index 2168cde4d..b6779f710 100644
--- a/drivers/common/octeontx2/otx2_common.h
+++ b/drivers/common/octeontx2/otx2_common.h
@@ -21,6 +21,7 @@
 #include "hw/otx2_sso.h"
 #include "hw/otx2_ssow.h"
 #include "hw/otx2_tim.h"
+#include "hw/otx2_ree.h"
 
 /* Alignment */
 #define OTX2_ALIGN  128
@@ -96,6 +97,7 @@ extern int otx2_logtype_tm;  extern int otx2_logtype_tim;  
extern int otx2_logtype_dpi;  extern int otx2_logtype_ep;
+extern int otx2_logtype_ree;
 
 #define otx2_err(fmt, args...) \
RTE_LOG(ERR, PMD, "%s():%u " fmt "\n",  \
@@ -119,6 +121,7 @@ extern int otx2_logtype_ep;  #define otx2_tim_dbg(fmt, ...) 
otx2_dbg(tim, fmt, ##__VA_ARGS__)  #

Re: [dpdk-dev] [PATCH 3/4] usertools: add octeontx2 REE device binding

[Liron Himi]

Reviewed-by: Liron Himi 

-Original Message-
From: dev  On Behalf Of g...@marvell.com
Sent: Tuesday, 1 September 2020 15:25
To: Jerin Jacob Kollanukkaran ; Nithin Kumar Dabilpuram 
; tho...@monjalon.net; m...@ashroe.eu; 
nhor...@tuxdriver.com; bruce.richard...@intel.com; anatoly.bura...@intel.com; 
john.mcnam...@intel.com; marko.kovace...@intel.com
Cc: dev@dpdk.org; Smadar Fuks ; Dovrat Zifroni 
; Guy Kaneti ; or...@mellanox.com
Subject: [dpdk-dev] [PATCH 3/4] usertools: add octeontx2 REE device binding

From: Guy Kaneti 

Update the devbind script with new section of regex devices, also added 
OCTEONTX2 REE device ID to regex device list

Signed-off-by: Guy Kaneti 
---
 usertools/dpdk-devbind.py | 8 
 1 file changed, 8 insertions(+)

diff --git a/usertools/dpdk-devbind.py b/usertools/dpdk-devbind.py index 
86b6b53c4..51ee990db 100755
--- a/usertools/dpdk-devbind.py
+++ b/usertools/dpdk-devbind.py
@@ -44,6 +44,8 @@
   'SVendor': None, 'SDevice': None}  octeontx2_dma = {'Class': 
'08', 'Vendor': '177d', 'Device': 'a081',
   'SVendor': None, 'SDevice': None}
+octeontx2_ree = {'Class': '08', 'Vendor': '177d', 'Device': 'a0f4',
+  'SVendor': None, 'SDevice': None}
 
 intel_ioat_bdw = {'Class': '08', 'Vendor': '8086', 'Device': 
'6f20,6f21,6f22,6f23,6f24,6f25,6f26,6f27,6f2e,6f2f',
   'SVendor': None, 'SDevice': None} @@ -61,6 +63,7 @@  
mempool_devices = [cavium_fpa, octeontx2_npa]  compress_devices = [cavium_zip]  
misc_devices = [intel_ioat_bdw, intel_ioat_skx, intel_ioat_icx, intel_ntb_skx, 
octeontx2_dma]
+regex_devices = [octeontx2_ree]
 
 # global dict ethernet devices present. Dictionary indexed by PCI address.
 # Each device within this is itself a dictionary of device properties @@ 
-648,6 +651,9 @@ def show_status():
 if status_dev == "misc" or status_dev == "all":
 show_device_status(misc_devices, "Misc (rawdev)")
 
+if status_dev == "regex" or status_dev == "all":
+show_device_status(regex_devices, "Regex")
+
 def parse_args():
 '''Parses the command-line arguments given by the user and takes the
 appropriate action for each'''
@@ -723,6 +729,7 @@ def do_arg_actions():
 get_device_details(mempool_devices)
 get_device_details(compress_devices)
 get_device_details(misc_devices)
+get_device_details(regex_devices)
 show_status()
 
 
@@ -744,6 +751,7 @@ def main():
 get_device_details(mempool_devices)
 get_device_details(compress_devices)
 get_device_details(misc_devices)
+get_device_details(regex_devices)
 do_arg_actions()
 
 if __name__ == "__main__":
--
2.28.0

Re: [dpdk-dev] [PATCH 2/4] regex/octeontx2: add build infra and device support

[Liron Himi]

Reviewed-by: Liron Himi 

-Original Message-
From: dev  On Behalf Of g...@marvell.com
Sent: Tuesday, 1 September 2020 15:25
To: Jerin Jacob Kollanukkaran ; Nithin Kumar Dabilpuram 
; tho...@monjalon.net; m...@ashroe.eu; 
nhor...@tuxdriver.com; bruce.richard...@intel.com; anatoly.bura...@intel.com; 
john.mcnam...@intel.com; marko.kovace...@intel.com
Cc: dev@dpdk.org; Smadar Fuks ; Dovrat Zifroni 
; Guy Kaneti ; or...@mellanox.com
Subject: [dpdk-dev] [PATCH 2/4] regex/octeontx2: add build infra and device 
support

From: Guy Kaneti 

Add meson based build infrastructure along with the
OTX2 regexdev (REE) device functions.

For regex rule compiler support build:
meson configure -Dree_compiler_sdk=

Signed-off-by: Guy Kaneti 
---
 MAINTAINERS   |3 +
 config/common_base|6 +
 drivers/regex/meson.build |2 +-
 drivers/regex/octeontx2/meson.build   |   53 +
 drivers/regex/octeontx2/otx2_regexdev.c   | 1001 +
 drivers/regex/octeontx2/otx2_regexdev.h   |  109 ++
 .../regex/octeontx2/otx2_regexdev_compiler.c  |  229 
 .../regex/octeontx2/otx2_regexdev_compiler.h  |   11 +
 .../regex/octeontx2/otx2_regexdev_hw_access.c |  167 +++
 .../regex/octeontx2/otx2_regexdev_hw_access.h |  202 
 drivers/regex/octeontx2/otx2_regexdev_mbox.c  |  401 +++
 drivers/regex/octeontx2/otx2_regexdev_mbox.h  |   38 +
 .../rte_pmd_octeontx2_regex_version.map   |3 +
 meson_options.txt |2 +
 14 files changed, 2226 insertions(+), 1 deletion(-)
 create mode 100644 drivers/regex/octeontx2/meson.build
 create mode 100644 drivers/regex/octeontx2/otx2_regexdev.c
 create mode 100644 drivers/regex/octeontx2/otx2_regexdev.h
 create mode 100644 drivers/regex/octeontx2/otx2_regexdev_compiler.c
 create mode 100644 drivers/regex/octeontx2/otx2_regexdev_compiler.h
 create mode 100644 drivers/regex/octeontx2/otx2_regexdev_hw_access.c
 create mode 100644 drivers/regex/octeontx2/otx2_regexdev_hw_access.h
 create mode 100644 drivers/regex/octeontx2/otx2_regexdev_mbox.c
 create mode 100644 drivers/regex/octeontx2/otx2_regexdev_mbox.h
 create mode 100644 drivers/regex/octeontx2/rte_pmd_octeontx2_regex_version.map

diff --git a/MAINTAINERS b/MAINTAINERS
index ed163f5d5..ab8a9313c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1137,6 +1137,9 @@ F: drivers/regex/mlx5/
 F: doc/guides/regexdevs/mlx5.rst
 F: doc/guides/regexdevs/features/mlx5.ini
 
+Marvell OCTEON TX2 regex
+M: Guy Kaneti 
+F: drivers/regex/octeontx2/
 
 vDPA Drivers
 
diff --git a/config/common_base b/config/common_base
index fbf0ee70c..2cd687bf6 100644
--- a/config/common_base
+++ b/config/common_base
@@ -842,6 +842,12 @@ CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_EP_RAWDEV=y
 #
 CONFIG_RTE_LIBRTE_PMD_NTB_RAWDEV=y
 
+#
+# Compile PMD for Octeontx2 REE regex device
+#
+CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_REGEX=y
+CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_REGEX_COMPILER=n
+
 #
 # Compile librte_ring
 #
diff --git a/drivers/regex/meson.build b/drivers/regex/meson.build
index 8edeba3a0..79bb5d5df 100644
--- a/drivers/regex/meson.build
+++ b/drivers/regex/meson.build
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: BSD-3-Clause
 # Copyright 2020 Mellanox Technologies, Ltd
 
-drivers = ['mlx5']
+drivers = ['mlx5', 'octeontx2']
 std_deps = ['ethdev', 'kvargs'] # 'ethdev' also pulls in mbuf, net, eal etc
 config_flag_fmt = 'RTE_LIBRTE_@0@_PMD'
 driver_name_fmt = 'rte_pmd_@0@'
diff --git a/drivers/regex/octeontx2/meson.build 
b/drivers/regex/octeontx2/meson.build
new file mode 100644
index 0..c212e3d43
--- /dev/null
+++ b/drivers/regex/octeontx2/meson.build
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(C) 2020 Marvell International Ltd.
+#
+
+if not is_linux
+   build = false
+   reason = 'only supported on Linux'
+endif
+
+path = get_option('ree_compiler_sdk')
+lib_dir = path + '/lib'
+inc_dir = path + '/include'
+
+if dpdk_conf.has('RTE_LIBRTE_PMD_OCTEONTX2_REGEX_COMPILER')
+   lib = cc.find_library('librxp_compiler', dirs : [lib_dir], required: 
false)
+   if not lib.found()
+   build = false
+   reason = 'missing dependency, "librxp_compiler"'
+   else
+   ext_deps += lib
+   ext_deps += cc.find_library('libstdc++', required: true)
+   includes += include_directories(inc_dir)
+   cflags += ['-DREE_COMPILER_SDK']
+   endif
+endif
+
+sources = files('otx2_regexdev.c',
+   'otx2_regexdev_hw_access.c',
+   'otx2_regexdev_mbox.c',
+   'otx2_regexdev_compiler.c'
+   )
+
+extra_flags = []
+# This integrated controller runs only on a arm64 machine, remove 32bit 
warnings
+if not dpdk_conf.get('RTE_ARCH_64')
+   extra_flags += ['-Wno-int-to-pointer-cast', '-Wno-pointer-to-int-cast']
+endif
+
+# for clang 32-bit compiles we need libatomic for 64-bit atomic ops
+if cc.get_id(

Re: [dpdk-dev] [PATCH 4/4] doc: add Marvell OCTEON TX2 regex guide

[Liron Himi]

Reviewed-by: Liron Himi 

-Original Message-
From: dev  On Behalf Of g...@marvell.com
Sent: Tuesday, 1 September 2020 15:25
To: Jerin Jacob Kollanukkaran ; Nithin Kumar Dabilpuram 
; tho...@monjalon.net; m...@ashroe.eu; 
nhor...@tuxdriver.com; bruce.richard...@intel.com; anatoly.bura...@intel.com; 
john.mcnam...@intel.com; marko.kovace...@intel.com
Cc: dev@dpdk.org; Smadar Fuks ; Dovrat Zifroni 
; Guy Kaneti ; or...@mellanox.com
Subject: [dpdk-dev] [PATCH 4/4] doc: add Marvell OCTEON TX2 regex guide

From: Guy Kaneti 

Signed-off-by: Guy Kaneti 
---
 doc/guides/platform/octeontx2.rst   |  5 +++
 doc/guides/regexdevs/features/octeontx2.ini | 10 +
 doc/guides/regexdevs/index.rst  |  1 +
 doc/guides/regexdevs/octeontx2.rst  | 49 +
 doc/guides/rel_notes/release_20_11.rst  |  5 +++
 5 files changed, 70 insertions(+)
 create mode 100644 doc/guides/regexdevs/features/octeontx2.ini
 create mode 100644 doc/guides/regexdevs/octeontx2.rst

diff --git a/doc/guides/platform/octeontx2.rst 
b/doc/guides/platform/octeontx2.rst
index 13255eec5..c4d64ab4b 100644
--- a/doc/guides/platform/octeontx2.rst
+++ b/doc/guides/platform/octeontx2.rst
@@ -67,6 +67,8 @@ DPDK subsystem.
+---+-+--+
| 9 | SDP | rte_ethdev   |
+---+-+--+
+   | 10| REE | rte_regexdev |
+   
+ +---+-+---
+ ---+
 
 PF0 is called the administrative / admin function (AF) and has exclusive  
privileges to provision RVU functional block's LFs to each of the PF/VF.
@@ -156,6 +158,9 @@ This section lists dataplane H/W block(s) available in 
OCTEON TX2 SoC.
 #. **Crypto Device Driver**
See :doc:`../cryptodevs/octeontx2` for CPT crypto device driver information.
 
+#. **Regex Device Driver**
+   See :doc:`../regexdevs/octeontx2` for REE regex device driver information.
+
 Procedure to Setup Platform
 ---
 
diff --git a/doc/guides/regexdevs/features/octeontx2.ini 
b/doc/guides/regexdevs/features/octeontx2.ini
new file mode 100644
index 0..c9b421a16
--- /dev/null
+++ b/doc/guides/regexdevs/features/octeontx2.ini
@@ -0,0 +1,10 @@
+;
+; Supported features of the 'octeontx2' regex driver.
+;
+; Refer to default.ini for the full list of available driver features.
+;
+[Features]
+PCRE back reference = Y
+PCRE word boundary  = Y
+Run time compilation= Y
+Armv8   = Y
diff --git a/doc/guides/regexdevs/index.rst b/doc/guides/regexdevs/index.rst 
index 49216a932..b1abc826b 100644
--- a/doc/guides/regexdevs/index.rst
+++ b/doc/guides/regexdevs/index.rst
@@ -13,3 +13,4 @@ which can be used from an application through RegEx API.
 
features_overview
mlx5
+   octeontx2
diff --git a/doc/guides/regexdevs/octeontx2.rst 
b/doc/guides/regexdevs/octeontx2.rst
new file mode 100644
index 0..859780da1
--- /dev/null
+++ b/doc/guides/regexdevs/octeontx2.rst
@@ -0,0 +1,49 @@
+..  SPDX-License-Identifier: BSD-3-Clause
+Copyright(c) 2020 Marvell International Ltd.
+
+OCTEON TX2 REE Regexdev Driver
+===
+
+The OCTEON TX2 REE PMD (**librte_pmd_octeontx2_regex**) provides poll 
+mode regexdev driver support for the inbuilt regex device found in the 
+**Marvell OCTEON TX2** SoC family.
+
+More information about OCTEON TX2 SoC can be found at `Marvell Official 
+Website 
`_.
+
+Features
+
+
+Features of the OCTEON TX2 REE PMD are:
+
+- 36 queues
+- Up to 254 matches for each regex operation
+
+Prerequisites and Compilation procedure
+---
+
+   See :doc:`../platform/octeontx2` for setup information.
+
+Device Setup
+
+
+The OCTEON TX2 REE devices will need to be bound to a user-space IO 
+driver for use. The script ``dpdk-devbind.py`` script included with 
+DPDK can be used to view the state of the devices and to bind them to a 
+suitable DPDK-supported kernel driver. When querying the status of the 
+devices, they will appear under the category of "REGEX devices", i.e. 
+the command ``dpdk-devbind.py --status-dev regex`` can be used to see 
+the state of those devices alone.
+
+Debugging Options
+-
+
+.. _table_octeontx2_regex_debug_options:
+
+.. table:: OCTEON TX2 regex device debug options
+
+   +---++---+
+   | # | Component  | EAL log command   |
+   +===++===+
+   | 1 | REE| --log-level='pmd\.regex\.octeontx2,8' |
+   
+ +---++
+

Re: [dpdk-dev] [PATCH v4 5/5] eal/windows: added support for rte_bus_close API

[Tal Shnaiderman]

> Subject: [dpdk-dev] [PATCH v4 5/5] eal/windows: added support for
> rte_bus_close API
> 
> External email: Use caution opening links or attachments
> 
> 
> From: Rohit Raj 
> 
> Added support for rte_bus_close API on windows to reset the devices on
> the bus to default state.
> 
> Signed-off-by: Rohit Raj 
> ---
>  lib/librte_eal/windows/eal.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/librte_eal/windows/eal.c b/lib/librte_eal/windows/eal.c index
> bc48f27ab..9eb32077b 100644
> --- a/lib/librte_eal/windows/eal.c
> +++ b/lib/librte_eal/windows/eal.c
> @@ -251,7 +251,7 @@ rte_eal_cleanup(void)  {
> struct internal_config *internal_conf =
> eal_get_internal_configuration();
> -
> +   rte_bus_close();
> eal_cleanup_config(internal_conf);
> return 0;
>  }
> --
> 2.17.1

Hi Rohit,

You need to add rte_bus_close to lib/librte_eal/rte_eal_exports.def as it is 
currently the way to export functions from eal in Windows clang build.

Thanks,

Tal.

Re: [dpdk-dev] [PATCH] net/octeontx2: fix rss flow create

[Jerin Jacob]

On Sat, Oct 10, 2020 at 12:03 PM  wrote:
>
> From: Kiran Kumar K 
>
> While creating flow with action type RSS, action type is not being
> set to RSS, and action type is being set to unicast. Therefore it breaks
> RSS functionality. This patch add changes to program the RSS action
> properly.
>
> Fixes: 4092e4845d ("net/octeontx2: add flow operations")

Cc: sta...@dpdk.org

Applied to dpdk-next-net-mrvl/for-main. Thanks.

>
> Signed-off-by: Kiran Kumar K 
> ---
>  drivers/net/octeontx2/otx2_flow.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/octeontx2/otx2_flow.c 
> b/drivers/net/octeontx2/otx2_flow.c
> index 13a76e441..90540ffbd 100644
> --- a/drivers/net/octeontx2/otx2_flow.c
> +++ b/drivers/net/octeontx2/otx2_flow.c
> @@ -270,6 +270,8 @@ flow_program_rss_action(struct rte_eth_dev *eth_dev,
> if (rc)
> return rc;
>
> +   flow->npc_action &= (~(0xfULL));
> +   flow->npc_action |= NIX_RX_ACTIONOP_RSS;
> flow->npc_action |=
> ((uint64_t)(alg_idx & NIX_RSS_ACT_ALG_MASK) <<
>  NIX_RSS_ACT_ALG_OFFSET) |
> --
> 2.25.1
>

Re: [dpdk-dev] [PATCH v2] net/octeontx2: remove logically dead code

[Jerin Jacob]

On Fri, Oct 9, 2020 at 6:09 PM wangyunjian  wrote:
>
> From: Yunjian Wang 
>
> The glibc free allows free(NULL) as null operation,
> so remove this useless null checks.
>
> Coverity issue: 357719
> Fixes: da138cd47e06 ("net/octeontx2: handle port reconfigure")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Yunjian Wang 

Acked-by: Jerin Jacob 
Applied to dpdk-next-net-mrvl/for-main. Thanks

> ---
> v2:
>fix code styles suggested by Stephen Hemminger
> ---
>  drivers/net/octeontx2/otx2_ethdev.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/octeontx2/otx2_ethdev.c 
> b/drivers/net/octeontx2/otx2_ethdev.c
> index 03d81faef..b69b92bf5 100644
> --- a/drivers/net/octeontx2/otx2_ethdev.c
> +++ b/drivers/net/octeontx2/otx2_ethdev.c
> @@ -1383,10 +1383,8 @@ nix_store_queue_cfg_and_then_release(struct 
> rte_eth_dev *eth_dev)
> return 0;
>
>  fail:
> -   if (tx_qconf)
> -   free(tx_qconf);
> -   if (rx_qconf)
> -   free(rx_qconf);
> +   free(tx_qconf);
> +   free(rx_qconf);
>
> return -ENOMEM;
>  }
> --
> 2.23.0
>

Re: [dpdk-dev] [PATCH v2 1/1] eventdev: add PCI probe named convenience function

[Jerin Jacob]

On Thu, Oct 8, 2020 at 9:56 PM Jerin Jacob  wrote:
>
> On Tue, Oct 6, 2020 at 1:41 AM Timothy McDaniel
>  wrote:
> >
> > Add new internal wrapper function for use by pci drivers as a
> > .probe function to attach to an event interface.  Same as
> > rte_event_pmd_pci_probe, except the caller can specify the name.
> >
> > Updated rte_event_pmd_pci_probe so as to not duplicate
> > code.
> >
> > Signed-off-by: Timothy McDaniel 
> > ---
> >  lib/librte_eventdev/rte_eventdev_pmd_pci.h | 44 
> > ++
> >  1 file changed, 32 insertions(+), 12 deletions(-)
> >
>
> >   * @internal
> > + * Wrapper for use by pci drivers as a .probe function to attach to a event
> > + * interface.
> > + */
> > +static inline int
> > +rte_event_pmd_pci_probe(struct rte_pci_driver *pci_drv,
> > +   struct rte_pci_device *pci_dev,
> > +   size_t private_data_size,
> > +   eventdev_pmd_pci_callback_t devinit)
>
>
> rte_event_pmd_pci_probe() added in
> lib/librte_eventdev/rte_eventdev_version.map file.
> Please add the new function in the map file. With above change:
>
> Acked-by: Jerin Jacob 


@McDaniel, Timothy
Could you send the updated version, I would like to merge this for RC1.


>
>
>
> > +{
> > +   char eventdev_name[RTE_EVENTDEV_NAME_MAX_LEN];
> > +
> > +   rte_pci_device_name(&pci_dev->addr, eventdev_name,
> > +   sizeof(eventdev_name));
> > +
> > +   return rte_event_pmd_pci_probe_named(pci_drv,
> > +pci_dev,
> > +private_data_size,
> > +devinit,
> > +eventdev_name);
> > +}
> > +
> > +/**
> > + * @internal
> >   * Wrapper for use by pci drivers as a .remove function to detach a event
> >   * interface.
> >   */
> > --
> > 2.6.4
> >

[dpdk-dev] [PATCH] app/flow-perf: configurable rule batches

[Georgios Katsikas]

Currently, flow-perf measures the performance of
rule installation/deletion operations by breaking
down the entire number of operations into windows
of fixed size (i.e., 10 operations per window).
Then, flow-perf measures the total time per window
and computes an average time across all windows.

This commit allows flow-perf users to configure
the number of rules per window instead of using
a fixed pre-compiled value. To do so, users must
pass --rules-batch=N, where N is the number of
rules per window (or batch).
For consistency reasons, flow_count variable is
now renamed to rules_count. This variable is the
total number of rules to be installed/deleted.

For example, if a user wants to measure how much
time it takes to install 1M rules in a certain NIC,
he/she can input:
--rules-count=100
This way flow-perf will break down 1M flow rules into
10 batches of 100k flow rules each (this is the default
batch size) and compute an average across the 10
measurements.
Now, if the user modifies the number of rules per
batch as follows:
--rules-count=100 --rules-batch=50
then flow-perf will break down 1M flow rules into
2 batches of 500k flow rules each and compute the
average across the 2 measurements.

Finally, this commit also adds default variables
to the usage function instead of hardcoded values.

Signed-off-by: Georgios Katsikas 
---
 app/test-flow-perf/main.c  | 86 --
 doc/guides/tools/flow-perf.rst | 42 -
 2 files changed, 79 insertions(+), 49 deletions(-)

diff --git a/app/test-flow-perf/main.c b/app/test-flow-perf/main.c
index c420da6a5..4cdab2c93 100644
--- a/app/test-flow-perf/main.c
+++ b/app/test-flow-perf/main.c
@@ -40,7 +40,8 @@
 
 #define MAX_ITERATIONS 100
 #define DEFAULT_RULES_COUNT400
-#define DEFAULT_ITERATION   10
+#define DEFAULT_RULES_BATCH 10
+#define DEFAULT_GROUP0
 
 struct rte_flow *flow;
 static uint8_t flow_group;
@@ -62,8 +63,8 @@ static bool enable_fwd;
 
 static struct rte_mempool *mbuf_mp;
 static uint32_t nb_lcores;
-static uint32_t flows_count;
-static uint32_t iterations_number;
+static uint32_t rules_count;
+static uint32_t rules_batch;
 static uint32_t hairpin_queues_num; /* total hairpin q number - default: 0 */
 static uint32_t nb_lcores;
 
@@ -98,8 +99,10 @@ usage(char *progname)
 {
printf("\nusage: %s\n", progname);
printf("\nControl configurations:\n");
-   printf("  --flows-count=N: to set the number of needed"
-   " flows to insert, default is 4,000,000\n");
+   printf("  --rules-count=N: to set the number of needed"
+   " rules to insert, default is %d\n", DEFAULT_RULES_COUNT);
+   printf("  --rules-batch=N: set number of batched rules,"
+   " default is %d\n", DEFAULT_RULES_BATCH);
printf("  --dump-iterations: To print rates for each"
" iteration\n");
printf("  --deletion-rate: Enable deletion rate"
@@ -114,7 +117,7 @@ usage(char *progname)
printf("  --egress: set egress attribute in flows\n");
printf("  --transfer: set transfer attribute in flows\n");
printf("  --group=N: set group for all flows,"
-   " default is 0\n");
+   " default is %d\n", DEFAULT_GROUP);
 
printf("To set flow items:\n");
printf("  --ether: add ether layer in flow items\n");
@@ -527,7 +530,8 @@ args_parse(int argc, char **argv)
static const struct option lgopts[] = {
/* Control */
{ "help",   0, 0, 0 },
-   { "flows-count",1, 0, 0 },
+   { "rules-count",1, 0, 0 },
+   { "rules-batch",1, 0, 0 },
{ "dump-iterations",0, 0, 0 },
{ "deletion-rate",  0, 0, 0 },
{ "dump-socket-mem",0, 0, 0 },
@@ -705,16 +709,26 @@ args_parse(int argc, char **argv)
}
/* Control */
if (strcmp(lgopts[opt_idx].name,
-   "flows-count") == 0) {
+   "rules-batch") == 0) {
n = atoi(optarg);
-   if (n > (int) iterations_number)
-   flows_count = n;
+   if (n >= DEFAULT_RULES_BATCH)
+   rules_batch = n;
else {
-   printf("\n\nflows_count should be > 
%d\n",
-   iterations_number);
+   printf("\n\nrules_batch should be >= 
%d\n",
+   DEFAULT_RULES_BATCH);
rte_exit(EXIT_SUCCESS, " ");
  

Re: [dpdk-dev] [PATCH v5 03/10] eal: add intrinsics support check infrastructure

[Jerin Jacob]

On Fri, Oct 9, 2020 at 9:32 PM Anatoly Burakov
 wrote:
>
> Currently, it is not possible to check support for intrinsics that
> are platform-specific, cannot be abstracted in a generic way, or do not
> have support on all architectures. The CPUID flags can be used to some
> extent, but they are only defined for their platform, while intrinsics
> will be available to all code as they are in generic headers.
>
> This patch introduces infrastructure to check support for certain
> platform-specific intrinsics, and adds support for checking support for
> IA power management-related intrinsics for UMWAIT/UMONITOR and TPAUSE.
>
> Signed-off-by: Anatoly Burakov 
> ---
>  .../arm/include/rte_power_intrinsics.h|  8 ++
>  lib/librte_eal/arm/rte_cpuflags.c |  6 +
>  lib/librte_eal/include/generic/rte_cpuflags.h | 26 +++
>  .../include/generic/rte_power_intrinsics.h|  8 ++
>  .../ppc/include/rte_power_intrinsics.h|  8 ++
>  lib/librte_eal/ppc/rte_cpuflags.c |  6 +
>  lib/librte_eal/rte_eal_version.map|  1 +
>  .../x86/include/rte_power_intrinsics.h|  8 ++
>  lib/librte_eal/x86/rte_cpuflags.c | 12 +
>  9 files changed, 83 insertions(+)
>
> diff --git a/lib/librte_eal/arm/include/rte_power_intrinsics.h 
> b/lib/librte_eal/arm/include/rte_power_intrinsics.h
> index 4aad44a0b9..055ec5877a 100644
> --- a/lib/librte_eal/arm/include/rte_power_intrinsics.h
> +++ b/lib/librte_eal/arm/include/rte_power_intrinsics.h
> @@ -17,6 +17,10 @@ extern "C" {
>  /**
>   * This function is not supported on ARM.
>   *
> + * @warning It is responsibility of the user to check if this function is
> + *   supported at runtime using `rte_cpu_get_features()` API call. Failing 
> to do
> + *   so may result in an illegal CPU instruction error.

See below

> + *
>   * @param p
>   *   Address to monitor for changes. Must be aligned on an 64-byte boundary.
>   * @param expected_value
> @@ -43,6 +47,10 @@ static inline void rte_power_monitor(const volatile void 
> *p,
>  /**
>   * This function is not supported on ARM.
>   *
> + * @warning It is responsibility of the user to check if this function is
> + *   supported at runtime using `rte_cpu_get_features()` API call. Failing 
> to do
> + *   so may result in an illegal CPU instruction error.
> + *
See below

This patch looks to me.

Since rte_power_monitor() API is public API, I think, only in the
generic header file, you need to have
these warnings and API documentation rather than repeating everywhere.



>   * @param tsc_timestamp
>   *   Maximum TSC timestamp to wait for.
>   *
> diff --git a/lib/librte_eal/arm/rte_cpuflags.c 
> b/lib/librte_eal/arm/rte_cpuflags.c
> index caf3dc83a5..7eef11fa02 100644
> --- a/lib/librte_eal/arm/rte_cpuflags.c
> +++ b/lib/librte_eal/arm/rte_cpuflags.c
> @@ -138,3 +138,9 @@ rte_cpu_get_flag_name(enum rte_cpu_flag_t feature)
> return NULL;
> return rte_cpu_feature_table[feature].name;
>  }
> +
> +void
> +rte_cpu_get_intrinsics_support(struct rte_cpu_intrinsics *intrinsics)
> +{
> +   memset(intrinsics, 0, sizeof(*intrinsics));
> +}
> diff --git a/lib/librte_eal/include/generic/rte_cpuflags.h 
> b/lib/librte_eal/include/generic/rte_cpuflags.h
> index 872f0ebe3e..28a5aecde8 100644
> --- a/lib/librte_eal/include/generic/rte_cpuflags.h
> +++ b/lib/librte_eal/include/generic/rte_cpuflags.h
> @@ -13,6 +13,32 @@
>  #include "rte_common.h"
>  #include 
>
> +#include 
> +
> +/**
> + * Structure used to describe platform-specific intrinsics that may or may 
> not
> + * be supported at runtime.
> + */
> +struct rte_cpu_intrinsics {
> +   uint32_t power_monitor : 1;
> +   /**< indicates support for rte_power_monitor function */
> +   uint32_t power_pause : 1;
> +   /**< indicates support for rte_power_pause function */
> +};
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice
> + *
> + * Check CPU support for various intrinsics at runtime.
> + *
> + * @param intrinsics
> + * Pointer to a structure to be filled.
> + */
> +__rte_experimental
> +void
> +rte_cpu_get_intrinsics_support(struct rte_cpu_intrinsics *intrinsics);
> +
>  /**
>   * Enumeration of all CPU features supported
>   */
> diff --git a/lib/librte_eal/include/generic/rte_power_intrinsics.h 
> b/lib/librte_eal/include/generic/rte_power_intrinsics.h
> index e36c1f8976..218eda7e86 100644
> --- a/lib/librte_eal/include/generic/rte_power_intrinsics.h
> +++ b/lib/librte_eal/include/generic/rte_power_intrinsics.h
> @@ -26,6 +26,10 @@
>   * checked against the expected value, and if they match, the entering of
>   * optimized power state may be aborted.
>   *
> + * @warning It is responsibility of the user to check if this function is
> + *   supported at runtime using `rte_cpu_get_features()` API call. Failing 
> to do
> + *   so may result in an illegal CPU instruction error.

See above

> + *
>   * @param p
>   *

Re: [dpdk-dev] [PATCH 1/3 v3] ethdev: add rx offload to drop error packets

[Jerin Jacob]

On Fri, Oct 9, 2020 at 6:43 PM  wrote:
>
> From: Nipun Gupta 
>
> This change adds a RX offload capability and configuration to
> enable hardware to drop the packets in case of any error in the
> packets such as L3 checksum error or L4 checksum.
>
> Signed-off-by: Nipun Gupta 
> Signed-off-by: Rohit Raj 
> Reviewed-by: Asaf Penso 
> ---
>
> v3:
>  - Add additional rx_err_drop_offload_capa, which is specific
>capability flag for RX packets error drop offload. Currently
>only 'all' error packet drops are enabled, but can be extended
>to provide capability to drop any specific errors like L1 FCS,
>L3 Checksum etc.
>  - Added separate config structure to enable the drop configuration.
>  - Updated doc with the new updated option in testbbdev (patch 3/3)
>
> v2:
>  - Add support in DPAA1 driver (patch 2/3)
>  - Add support and config parameter in testpmd (patch 3/3)
>
>  lib/librte_ethdev/rte_ethdev.c |  1 +
>  lib/librte_ethdev/rte_ethdev.h | 22 ++
>  2 files changed, 23 insertions(+)


The patch looks good to me.

1) Missed to update port_offload_cap_display() for new oflload in
/app/test-pmd/config.c
2) Please update doc/guides/nics/features.rst for this new offload

See [1] as a reference.
[1]
commit 28f6a3b88d23a348eeffd2bac79b2e0819d3b4e9
Author: Jerin Jacob 
Date:   Tue Oct 2 16:21:41 2018 +0530

ethdev: support SCTP Rx checksum offload

Added SCTP Rx checksum offload support

Signed-off-by: Jerin Jacob 
Reviewed-by: Ferruh Yigit 



>
> diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
> index 48d1333b1..be25e947e 100644
> --- a/lib/librte_ethdev/rte_ethdev.c
> +++ b/lib/librte_ethdev/rte_ethdev.c
> @@ -128,6 +128,7 @@ static const struct {
> RTE_RX_OFFLOAD_BIT2STR(SCTP_CKSUM),
> RTE_RX_OFFLOAD_BIT2STR(OUTER_UDP_CKSUM),
> RTE_RX_OFFLOAD_BIT2STR(RSS_HASH),
> +   RTE_RX_OFFLOAD_BIT2STR(ERR_PKT_DROP),
>  };
>
>  #undef RTE_RX_OFFLOAD_BIT2STR
> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
> index d2bf74f12..cb968d38a 100644
> --- a/lib/librte_ethdev/rte_ethdev.h
> +++ b/lib/librte_ethdev/rte_ethdev.h
> @@ -1194,6 +1194,16 @@ struct rte_intr_conf {
> uint32_t rmv:1;
>  };
>
> +/**
> + * A structure used to enable/disable error packet drop on RX.
> + */
> +struct rte_rx_err_pkt_drop_conf {
> +   /** enable/disable all RX error packet drop.
> +* 0 (default) - disable, 1 enable
> +*/
> +   uint32_t all:1;
> +};
> +
>  /**
>   * A structure used to configure an Ethernet port.
>   * Depending upon the RX multi-queue mode, extra advanced
> @@ -1236,6 +1246,8 @@ struct rte_eth_conf {
> uint32_t dcb_capability_en;
> struct rte_fdir_conf fdir_conf; /**< FDIR configuration. DEPRECATED */
> struct rte_intr_conf intr_conf; /**< Interrupt mode configuration. */
> +   struct rte_rx_err_pkt_drop_conf err_pkt_drop_conf;
> +   /**< RX error packet drop configuration. */
>  };
>
>  /**
> @@ -1260,6 +1272,7 @@ struct rte_eth_conf {
>  #define DEV_RX_OFFLOAD_SCTP_CKSUM  0x0002
>  #define DEV_RX_OFFLOAD_OUTER_UDP_CKSUM  0x0004
>  #define DEV_RX_OFFLOAD_RSS_HASH0x0008
> +#define DEV_RX_OFFLOAD_ERR_PKT_DROP0x0010
>
>  #define DEV_RX_OFFLOAD_CHECKSUM (DEV_RX_OFFLOAD_IPV4_CKSUM | \
>  DEV_RX_OFFLOAD_UDP_CKSUM | \
> @@ -1274,6 +1287,13 @@ struct rte_eth_conf {
>   * mentioned in rte_rx_offload_names in rte_ethdev.c file.
>   */
>
> +/**
> + * RX Error Drop offload config/capabilities of a device. These
> + * are valid only when RX capability DEV_RX_OFFLOAD_ERR_PKT_DROP
> + * is supported by the device.
> + */
> +#define DEV_RX_ERR_PKT_DROP_OFFLOAD_ALL0x0001
> +
>  /**
>   * TX offload capabilities of a device.
>   */
> @@ -1411,6 +1431,8 @@ struct rte_eth_dev_info {
> /**< Device per-queue RX offload capabilities. */
> uint64_t tx_queue_offload_capa;
> /**< Device per-queue TX offload capabilities. */
> +   uint64_t rx_err_drop_offload_capa;
> +   /**< RX error packet drop offload capabilities. */
> uint16_t reta_size;
> /**< Device redirection table size, the total number of entries. */
> uint8_t hash_key_size; /**< Hash key size in bytes */
> --
> 2.17.1
>

Re: [dpdk-dev] [PATCH v9 1/1] net/mlx5: support match ICMP identifier fields

[Raslan Darawsheh]

Hi,

> -Original Message-
> From: Li Zhang 
> Sent: Friday, October 9, 2020 9:12 AM
> To: Dekel Peled ; Ori Kam ; Slava
> Ovsiienko ; Matan Azrad 
> Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon
> ; Raslan Darawsheh 
> Subject: [PATCH v9 1/1] net/mlx5: support match ICMP identifier fields
> 
> PRM expose fields "Icmp_header_data" in IPv4 ICMP.
> Update ICMP mask parameter with ICMP identifier and sequence number
> fields.
> ICMP sequence number spec with mask, Icmp_header_data low 16 bits are
> set.
> ICMP identifier spec with mask, Icmp_header_data high 16 bits are set.
> 
> Signed-off-by: Li Zhang 
> Acked-by: Ori Kam 
> ---
>  doc/guides/nics/mlx5.rst   |  4 ++--
>  doc/guides/rel_notes/release_20_11.rst |  2 +-
>  drivers/net/mlx5/mlx5_flow.c   | 10 --
>  drivers/net/mlx5/mlx5_flow_dv.c| 13 +
>  4 files changed, 24 insertions(+), 5 deletions(-)
> 
> diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
> index b0614ae335..a174cdd5f5 100644
> --- a/doc/guides/nics/mlx5.rst
> +++ b/doc/guides/nics/mlx5.rst
> @@ -288,7 +288,7 @@ Limitations
>- The input buffer, providing the removal size, is not validated.
>- The buffer size must match the length of the headers to be removed.
> 
> -- ICMP/ICMP6 code/type matching, IP-in-IP and MPLS flow matching are all
> +- ICMP(code/type/identifier/sequence number) / ICMP6(code/type)
> matching, IP-in-IP and MPLS flow matching are all
>mutually exclusive features which cannot be supported together
>(see :ref:`mlx5_firmware_config`).
> 
> @@ -1009,7 +1009,7 @@ Below are some firmware configurations listed.
> 
>  FLEX_PARSER_PROFILE_ENABLE=1
> 
> -- enable ICMP/ICMP6 code/type fields matching::
> +- enable ICMP(code/type/identifier/sequence number) /
> ICMP6(code/type) fields matching::
> 
>  FLEX_PARSER_PROFILE_ENABLE=2
> 
> diff --git a/doc/guides/rel_notes/release_20_11.rst
> b/doc/guides/rel_notes/release_20_11.rst
> index b0637640d1..e22e0c3981 100644
> --- a/doc/guides/rel_notes/release_20_11.rst
> +++ b/doc/guides/rel_notes/release_20_11.rst
> @@ -102,7 +102,7 @@ New Features
>* Added flag action.
>* Added raw encap/decap actions.
>* Added VXLAN encap/decap actions.
> -  * Added ICMP and ICMP6 matching items.
> +  * Added ICMP(code/type/identifier/sequence number) and
> ICMP6(code/type) matching items.
>* Added option to set port mask for insertion/deletion:
>  ``--portmask=N``
>  where N represents the hexadecimal bitmask of ports used.
> diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
> index 691eb9a3cd..0a54818c0c 100644
> --- a/drivers/net/mlx5/mlx5_flow.c
> +++ b/drivers/net/mlx5/mlx5_flow.c
> @@ -1629,6 +1629,12 @@ mlx5_flow_validate_item_icmp(const struct
> rte_flow_item *item,
>struct rte_flow_error *error)
>  {
>   const struct rte_flow_item_icmp *mask = item->mask;
> + const struct rte_flow_item_icmp nic_mask = {
> + .hdr.icmp_type = 0xff,
> + .hdr.icmp_code = 0xff,
> + .hdr.icmp_ident = RTE_BE16(0x),
> + .hdr.icmp_seq_nb = RTE_BE16(0x),
> + };
>   const int tunnel = !!(item_flags & MLX5_FLOW_LAYER_TUNNEL);
>   const uint64_t l3m = tunnel ? MLX5_FLOW_LAYER_INNER_L3_IPV4 :
> MLX5_FLOW_LAYER_OUTER_L3_IPV4;
> @@ -1651,10 +1657,10 @@ mlx5_flow_validate_item_icmp(const struct
> rte_flow_item *item,
> RTE_FLOW_ERROR_TYPE_ITEM,
> item,
> "multiple L4 layers not supported");
>   if (!mask)
> - mask = &rte_flow_item_icmp_mask;
> + mask = &nic_mask;
>   ret = mlx5_flow_item_acceptable
>   (item, (const uint8_t *)mask,
> -  (const uint8_t *)&rte_flow_item_icmp_mask,
> +  (const uint8_t *)&nic_mask,
>sizeof(struct rte_flow_item_icmp), error);
>   if (ret < 0)
>   return ret;
> diff --git a/drivers/net/mlx5/mlx5_flow_dv.c
> b/drivers/net/mlx5/mlx5_flow_dv.c
> index 79fdf34c0e..2bbfcea1ed 100644
> --- a/drivers/net/mlx5/mlx5_flow_dv.c
> +++ b/drivers/net/mlx5/mlx5_flow_dv.c
> @@ -7378,6 +7378,8 @@ flow_dv_translate_item_icmp(void *matcher, void
> *key,
>  {
>   const struct rte_flow_item_icmp *icmp_m = item->mask;
>   const struct rte_flow_item_icmp *icmp_v = item->spec;
> + uint32_t icmp_header_data_m = 0;
> + uint32_t icmp_header_data_v = 0;
>   void *headers_m;
>   void *headers_v;
>   void *misc3_m = MLX5_ADDR_OF(fte_match_param, matcher,
> @@ -7412,6 +7414,17 @@ flow_dv_translate_item_icmp(void *matcher,
> void *key,
>icmp_m->hdr.icmp_code);
>   MLX5_SET(fte_match_set_misc3, misc3_v, icmp_code,
>icmp_v->hdr.icmp_code & icmp_m->hdr.icmp_code);
> + icmp_header_data_m = rte_be_to_cpu_16(icmp_m-
> >hdr.icmp_seq_nb);
> + icmp_header_data_m |= rte_

Re: [dpdk-dev] [PATCH v2 4/4] app/eventdev: enable fast free offload

[Jerin Jacob]

On Fri, Oct 9, 2020 at 12:20 AM Harman Kalra  wrote:
>
> Since we are not holding the mbufs or creating any references
> in the app, hence mbuf fast free offload can be enabled.
>
> Signed-off-by: Harman Kalra 
> ---
>  app/test-eventdev/test_pipeline_common.c | 5 +

++ eventdev maintainers

Since testeventdev is not creating more than one pool and not using
any mbuf reference feature.
This change looks to me. Let me know if you have any different opinion if nay.

Acked-by: Jerin Jacob 


>  1 file changed, 5 insertions(+)
>
> diff --git a/app/test-eventdev/test_pipeline_common.c 
> b/app/test-eventdev/test_pipeline_common.c
> index 17088b1b4..f0c0ffea7 100644
> --- a/app/test-eventdev/test_pipeline_common.c
> +++ b/app/test-eventdev/test_pipeline_common.c
> @@ -219,6 +219,11 @@ pipeline_ethdev_setup(struct evt_test *test, struct 
> evt_options *opt)
> return ret;
> }
>
> +   /* Enable mbuf fast free if PMD has the capability. */
> +   if (dev_info.tx_offload_capa & DEV_TX_OFFLOAD_MBUF_FAST_FREE)
> +   local_port_conf.txmode.offloads |=
> +   DEV_TX_OFFLOAD_MBUF_FAST_FREE;
> +
> rx_conf = dev_info.default_rxconf;
> rx_conf.offloads = port_conf.rxmode.offloads;
>
> --
> 2.18.0
>

Re: [dpdk-dev] [PATCH] app/flow-perf: configurable rule batches

[Georgios Katsikas]

Hi,

Thanks for the feedback Thomas.
Please see my updated patch, I hope it better explains the scope of this
work.

Best regards,
Georgios

On Tue, Oct 6, 2020 at 1:25 AM Thomas Monjalon  wrote:

> 05/10/2020 19:16, Georgios Katsikas:
> > Hi,
> >
> > What is the conclusion?
> > I haven't seen this patch being committed yet.
>
> You missed updating the file doc/guides/tools/flow-perf.rst
>
>
> > On Thu, Sep 24, 2020 at 3:01 PM Wisam Monther  wrote:
> > >From: Georgios Katsikas
> > > >
> > > >* One can now configure the number of rules per batch
>
> Please develop a bit more what was the previous behaviour
> and what you mean by "batch" in this context.
>
> > > >* Refactored flow_count variable to rules_count as it is related to
> the
> > > newly
> > > >added rules_batch variable
> > > >* Added default values to usage function
> > > >
> > > >Signed-off-by: Georgios Katsikas 
> > >
> > > Acked-by: Wisam Jaddo 
>
> Wisam, you should not ack if the doc is not updated.
> Otherwise you will have to complete the doc update yourself ;)
>
>
>

Re: [dpdk-dev] [PATCH v2 1/4] event/octeontx2: add switch tag flush op

[Jerin Jacob]

On Fri, Oct 9, 2020 at 12:19 AM Harman Kalra  wrote:
>
> From: Pavan Nikhilesh 
>
> Add SWTAG flush operation at the end of transmit sequence to
> immediately release the tag held by the core.
> Reuse Tag address to check SWTAG completion status.
>
> Signed-off-by: Pavan Nikhilesh 

Applied to driver-specific patches(1 to 3)to
dpdk-next-net-evntdev/for-main. Thanks.
Waiting for feedback on the non-driver-specific 4/4 patch[1]

[1]
http://patches.dpdk.org/patch/80076/

Re: [dpdk-dev] [PATCH] net/mlx5: add flow sync API

[Ori Kam]

Hi Bing,

> -Original Message-
> From: dev  On Behalf Of Bing Zhao
> Sent: Friday, October 9, 2020 6:01 PM
> Subject: [dpdk-dev] [PATCH] net/mlx5: add flow sync API
> 
> When creating a flow, the rule itself might not take effort
> immediately once the function call returns with success. It would
> take some time to let the steering synchronize with the hardware.
> 
> If the application wants the packet to be sent to hit the flow after
> it it created, this flow sync API can be used to clear the steering
> HW cache to enforce next packet hits the latest rules.
> 
> For TX, usually the NIC TX domain and/or the FDB domain should be
> synchronized depends in which domain the flow is created.
> 
> The application could also try to synchronize the NIC RX and/or the
> FDB domain for the ingress packets. But in the real life, it is hard
> to determine when a packet will come into the NIC.
> 
> Signed-off-by: Bing Zhao 
> ---
>  drivers/common/mlx5/linux/mlx5_glue.c | 14 ++
>  drivers/common/mlx5/linux/mlx5_glue.h |  1 +
>  drivers/net/mlx5/mlx5_flow.c  | 22 ++
>  drivers/net/mlx5/mlx5_flow.h  |  5 +
>  drivers/net/mlx5/mlx5_flow_dv.c   | 25 +
>  drivers/net/mlx5/rte_pmd_mlx5.h   | 19 +++
>  drivers/net/mlx5/rte_pmd_mlx5_version.map |  2 ++
>  7 files changed, 88 insertions(+)
> 
Missing release notes and mlx5.rst.

> diff --git a/drivers/common/mlx5/linux/mlx5_glue.c
> b/drivers/common/mlx5/linux/mlx5_glue.c
> index fcf03e8..86047b1 100644
> --- a/drivers/common/mlx5/linux/mlx5_glue.c
> +++ b/drivers/common/mlx5/linux/mlx5_glue.c
> @@ -494,6 +494,19 @@
>  #endif
>  }
> 
> +static int
> +mlx5_glue_dr_sync_domain(void *domain, uint32_t flags)
> +{
> +#ifdef HAVE_MLX5DV_DR
> + return mlx5dv_dr_domain_sync(domain, flags);
> +#else
> + (void)domain;
> + (void)flags;
> + errno = ENOTSUP;
> + return errno;
> +#endif
> +}
> +
>  static struct ibv_cq_ex *
>  mlx5_glue_dv_create_cq(struct ibv_context *context,
>  struct ibv_cq_init_attr_ex *cq_attr,
> @@ -1298,6 +1311,7 @@
>   .dr_destroy_flow_tbl = mlx5_glue_dr_destroy_flow_tbl,
>   .dr_create_domain = mlx5_glue_dr_create_domain,
>   .dr_destroy_domain = mlx5_glue_dr_destroy_domain,
> + .dr_sync_domain = mlx5_glue_dr_sync_domain,
>   .dv_create_cq = mlx5_glue_dv_create_cq,
>   .dv_create_wq = mlx5_glue_dv_create_wq,
>   .dv_query_device = mlx5_glue_dv_query_device,
> diff --git a/drivers/common/mlx5/linux/mlx5_glue.h
> b/drivers/common/mlx5/linux/mlx5_glue.h
> index 734ace2..d24a16e 100644
> --- a/drivers/common/mlx5/linux/mlx5_glue.h
> +++ b/drivers/common/mlx5/linux/mlx5_glue.h
> @@ -195,6 +195,7 @@ struct mlx5_glue {
>   void *(*dr_create_domain)(struct ibv_context *ctx,
> enum mlx5dv_dr_domain_type domain);
>   int (*dr_destroy_domain)(void *domain);
> + int (*dr_sync_domain)(void *domain, uint32_t flags);
>   struct ibv_cq_ex *(*dv_create_cq)
>   (struct ibv_context *context,
>struct ibv_cq_init_attr_ex *cq_attr,
> diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
> index a94f630..e25ec0c 100644
> --- a/drivers/net/mlx5/mlx5_flow.c
> +++ b/drivers/net/mlx5/mlx5_flow.c
> @@ -29,6 +29,7 @@
>  #include "mlx5_flow.h"
>  #include "mlx5_flow_os.h"
>  #include "mlx5_rxtx.h"
> +#include "rte_pmd_mlx5.h"
> 
>  /** Device flow drivers. */
>  extern const struct mlx5_flow_driver_ops mlx5_flow_verbs_drv_ops;
> @@ -6310,3 +6311,24 @@ struct mlx5_meter_domains_infos *
>dev->data->port_id);
>   return -ENOTSUP;
>  }
> +
> +static int
> +mlx5_flow_sync_memory(struct rte_eth_dev *dev, uint32_t domains, uint32_t
> flags)
> +{
> + const struct mlx5_flow_driver_ops *fops;
> + struct rte_flow_attr attr = { .transfer = 0 };
> +
> + if (flow_get_drv_type(dev, &attr) == MLX5_FLOW_TYPE_DV) {
> + fops = flow_get_drv_ops(MLX5_FLOW_TYPE_DV);
> + return fops->sync_memory(dev, domains, flags);
> + }
> + return -ENOTSUP;
> +}
> +
> +int rte_pmd_mlx5_sync_flow(uint16_t port_id, uint32_t domains)
> +{
> + struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> +
> + return mlx5_flow_sync_memory(dev, domains,
> +  MLX5DV_DR_DOMAIN_SYNC_FLAGS_HW);
> +}
> diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
> index 279daf2..ae0a508 100644
> --- a/drivers/net/mlx5/mlx5_flow.h
> +++ b/drivers/net/mlx5/mlx5_flow.h
> @@ -910,6 +910,10 @@ typedef int (*mlx5_flow_get_aged_flows_t)
>void **context,
>uint32_t nb_contexts,
>struct rte_flow_error *error);
> +typedef int (*mlx5_flow_sync_memory_t)
> + (struct rte_eth_dev *dev,
> +

Re: [dpdk-dev] [PATCH RESEND 1/2] raw/octeontx2_dma: Assign pem_id as lport for non-internal DMA

[Thomas Monjalon]

> DPI needs to know the PEM number for all external transfers.
> 
> Signed-off-by: Radha Mohan Chintakuntla 
> Reviewed-by: Satha Koteswara Rao Kottidi 
> Reviewed-by: Satananda Burla 
> 
> Acked-by: Satha Rao 

Series applied, thanks

Re: [dpdk-dev] [dpdk-stable] [PATCH v2] raw/dpaa2_qdma: fix missing parentheses

[Thomas Monjalon]

> > This issue detected by coverity, CID#279443(Structurally dead code).
> > 
> > Coverity issue: 279443
> > Fixes: c22fab9a6c34 ("raw/dpaa2_qdma: support configuration APIs")
> > Cc: sta...@dpdk.org
> > 
> > Signed-off-by: Yunjian Wang 
> > ---
> > --- a/drivers/raw/dpaa2_qdma/dpaa2_qdma.c
> > +++ b/drivers/raw/dpaa2_qdma/dpaa2_qdma.c
> > @@ -452,9 +452,10 @@ rte_qdma_reset(void)
> > /* In case there are pending jobs on any VQ, return -EBUSY */
> > for (i = 0; i < qdma_dev.max_vqs; i++) {
> > if (qdma_vqs[i].in_use && (qdma_vqs[i].num_enqueues !=
> > -   qdma_vqs[i].num_dequeues))
> > +   qdma_vqs[i].num_dequeues)) {
> > DPAA2_QDMA_ERR("Jobs are still pending on VQ: %d",
> > i);
> > return -EBUSY;
> > +   }
> > }

Acked by: Nipun Gupta 

I don't understand how it could work before in simplest case.
Changed title to "fix reset".

Applied, thanks

Re: [dpdk-dev] [PATCH v9 0/8] Enable dynamic config of subport bandwidth

[Thomas Monjalon]

09/10/2020 14:39, Savinay Dharmappa:
> DPDK sched library allows runtime configuration of the pipe profiles to the
> pipes of the subport once scheduler hierarchy is constructed. However, to
> change the subport level bandwidth, existing hierarchy needs to be
> dismantled and whole process of building hierarchy under subport nodes
> needs to be repeated which might result in router downtime. Furthermore,
> due to lack of dynamic configuration of the subport bandwidth profile
> configuration (shaper and Traffic class rates), the user application
> is unable to dynamically re-distribute the excess-bandwidth of one subport
> among other subports in the scheduler hierarchy. Therefore, it is also not
> possible to adjust the subport bandwidth profile in sync with dynamic
> changes in pipe profiles of subscribers who want to consume higher
> bandwidth opportunistically.
> 
> This patch series implements dynamic configuration of the subport bandwidth
> profile to overcome the runtime situation when group of subscribers are not
> using the allotted bandwidth and dynamic bandwidth re-distribution is
> needed the without making any structural changes in the hierarchy.
> 
> The implementation work includes refactoring the existing api and
> data structures defined for port and subport level, new APIs for
> adding subport level bandwidth profiles that can be used in runtime.
> 
> ---
> v8 -> v9
>- updated ABI section in release notes.
>- Addressed review comments from patch 8
>  of v8.

I was asking a question in my reply to v8 but you didn't hit the "reply" button.

One more question: why don't you keep the ack given by Cristian in v7?

Re: [dpdk-dev] [PATCH v6 08/14] doc: remove references to make from eventdevs guides

[Thomas Monjalon]

09/10/2020 12:21, Ciara Power:
> Make is no longer supported for compiling DPDK, references are now
> removed in the documentation.
> 
> Signed-off-by: Ciara Power 
> Reviewed-by: Kevin Laatz 
> ---
>  doc/guides/eventdevs/dpaa.rst  | 20 
>  doc/guides/eventdevs/dpaa2.rst | 20 
>  doc/guides/eventdevs/octeontx.rst  | 24 
>  doc/guides/eventdevs/octeontx2.rst |  8 
>  4 files changed, 72 deletions(-)
> 
> diff --git a/doc/guides/eventdevs/dpaa.rst b/doc/guides/eventdevs/dpaa.rst
> index be68c6da6f..6fbee91d9e 100644
> --- a/doc/guides/eventdevs/dpaa.rst
> +++ b/doc/guides/eventdevs/dpaa.rst
> @@ -43,26 +43,6 @@ Currently supported by DPDK:
>  Pre-Installation Configuration
>  --

This section becomes empty and can be removed.

>  
> -Config File Options
> -~~~
> -
> -The following options can be modified in the ``config`` file.
> -Please note that enabling debugging options may affect system performance.
> -
> -- ``CONFIG_RTE_LIBRTE_PMD_DPAA_EVENTDEV`` (default ``y``)
> -
> -  Toggle compilation of the ``librte_pmd_dpaa_event`` driver.
> -
> -Driver Compilation
> -~~
> -
> -To compile the DPAA EVENTDEV PMD for Linux arm64 gcc target, run the
> -following ``make`` command:
> -
> -.. code-block:: console
> -
> -   cd 
> -   make config T=arm64-dpaa-linux-gcc install
>  
>  Initialization
>  --
> diff --git a/doc/guides/eventdevs/dpaa2.rst b/doc/guides/eventdevs/dpaa2.rst
> index 835767f98d..b992ae649e 100644
> --- a/doc/guides/eventdevs/dpaa2.rst
> +++ b/doc/guides/eventdevs/dpaa2.rst
> @@ -52,26 +52,6 @@ Currently supported by DPDK:
>  Pre-Installation Configuration
>  --

This section becomes empty and can be removed.

> -Config File Options
> -~~~
> -
> -The following options can be modified in the ``config`` file.
> -Please note that enabling debugging options may affect system performance.
> -
> -- ``CONFIG_RTE_LIBRTE_PMD_DPAA2_EVENTDEV`` (default ``y``)
> -
> -  Toggle compilation of the ``lrte_pmd_dpaa2_event`` driver.
> -
> -Driver Compilation
> -~~
> -
> -To compile the DPAA2 EVENTDEV PMD for Linux arm64 gcc target, run the
> -following ``make`` command:
> -
> -.. code-block:: console
> -
> -   cd 
> -   make config T=arm64-dpaa-linux-gcc install
>  
>  Initialization
>  --
> diff --git a/doc/guides/eventdevs/octeontx.rst 
> b/doc/guides/eventdevs/octeontx.rst
> index 9a3646db0d..f7a4cdd586 100644
> --- a/doc/guides/eventdevs/octeontx.rst
> +++ b/doc/guides/eventdevs/octeontx.rst
> @@ -41,30 +41,6 @@ Prerequisites
>  
>  See :doc:`../platform/octeontx` for setup information.
>  
> -Pre-Installation Configuration
> ---
> -
> -Config File Options
> -~~~
> -
> -The following options can be modified in the ``config`` file.
> -Please note that enabling debugging options may affect system performance.
> -
> -- ``CONFIG_RTE_LIBRTE_PMD_OCTEONTX_SSOVF`` (default ``y``)
> -
> -  Toggle compilation of the ``librte_pmd_octeontx_ssovf`` driver.
> -
> -Driver Compilation
> -~~
> -
> -To compile the OCTEON TX SSOVF PMD for Linux arm64 gcc target, run the
> -following ``make`` command:
> -
> -.. code-block:: console
> -
> -   cd 
> -   make config T=arm64-thunderx-linux-gcc install
> -
>  
>  Initialization
>  --
> diff --git a/doc/guides/eventdevs/octeontx2.rst 
> b/doc/guides/eventdevs/octeontx2.rst
> index 6502f6415f..7f9eceb01f 100644
> --- a/doc/guides/eventdevs/octeontx2.rst
> +++ b/doc/guides/eventdevs/octeontx2.rst
> @@ -47,14 +47,6 @@ Prerequisites and Compilation procedure
>  Pre-Installation Configuration
>  --

This title doesn't really make any sense now.
If think sub-titles could be promoted to an highel level.

>  
> -Compile time Config Options
> -~~~
> -
> -The following option can be modified in the ``config`` file.
> -
> -- ``CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_EVENTDEV`` (default ``y``)
> -
> -  Toggle compilation of the ``librte_pmd_octeontx2_event`` driver.
>  
>  Runtime Config Options
>  ~~
> 

Re: [dpdk-dev] [PATCH v6 11/14] doc: remove reference to make from tools guides

[Thomas Monjalon]

09/10/2020 12:21, Ciara Power:
> Make is no longer supported for compiling DPDK, references are now
> removed in the documentation.
> 
> Signed-off-by: Ciara Power 
> Reviewed-by: Kevin Laatz 
> Acked-by: Nicolas Chautru 
> 
> ---
> v6:
>   - Fixed indentation for testbbdev list entry.
> v5:
>   - Reworded sentence in pdump doc.
>   - Replaced references to testbbdev binary with dpdk-test-bbdev.
>   - Fixed links to linux_gsg doc.
> ---
>  doc/guides/tools/comp_perf.rst| 10 ++--
>  doc/guides/tools/cryptoperf.rst   | 20 +++-
>  doc/guides/tools/pdump.rst| 15 +---
>  doc/guides/tools/proc_info.rst|  2 +-
>  doc/guides/tools/testbbdev.rst| 38 +--
>  doc/guides/tools/testeventdev.rst | 21 -
>  6 files changed, 32 insertions(+), 74 deletions(-)
> 
> diff --git a/doc/guides/tools/comp_perf.rst b/doc/guides/tools/comp_perf.rst
> index ee585d1024..269d7bdc9d 100644
> --- a/doc/guides/tools/comp_perf.rst
> +++ b/doc/guides/tools/comp_perf.rst
> @@ -100,13 +100,7 @@ Application Options
>  Compiling the Tool
>  --
>  
> -**Step 1: PMD setting**
> -
> -The ``dpdk-test-compress-perf`` tool depends on compression device drivers 
> PMD which
> -can be disabled by default in the build configuration file ``common_base``.
> -The compression device drivers PMD which should be tested can be enabled by 
> setting e.g.::
> -
> -   CONFIG_RTE_LIBRTE_PMD_ISAL=y
> +See :doc:`../linux_gsg/build_dpdk` for compilation steps.

Funnily there was only one step in this section.
I don't see any benefit of referencing how to compile on Linux everywhere.
I think it would be better to just drop the whole section about compilation.


>  Running the Tool
[...]
> --- a/doc/guides/tools/cryptoperf.rst
> +++ b/doc/guides/tools/cryptoperf.rst
> @@ -33,19 +33,8 @@ the hardware accelerator fully loaded and so measure 
> maximum throughput.
>  Compiling the Application
>  -
>  
> -**Step 1: PMD setting**
>  
> -The ``dpdk-test-crypto-perf`` tool depends on crypto device drivers PMD which
> -are disabled by default in the build configuration file ``common_base``.
> -The crypto device drivers PMD which should be tested can be enabled by 
> setting::
> -
> -   CONFIG_RTE_LIBRTE_PMD_=y
> -
> -Setting example for open ssl PMD::
> -
> -   CONFIG_RTE_LIBRTE_PMD_OPENSSL=y
> -
> -**Step 2: Linearization setting**
> +**Step 1: Linearization setting**
>  
>  It is possible linearized input segmented packets just before crypto 
> operation
>  for devices which doesn't support scatter-gather, and allows to measure
> @@ -56,13 +45,10 @@ To set on the linearization options add below definition 
> to the
>  
> #define CPERF_LINEARIZATION_ENABLE
>  
> -**Step 3: Build the application**
> +**Step 2: Build the application**
>  
> -Execute the ``dpdk-setup.sh`` script to build the DPDK library together with 
> the
> -``dpdk-test-crypto-perf`` application.
> +See :doc:`../linux_gsg/build_dpdk` for compilation steps.
>  
> -Initially, the user must select a DPDK target to choose the correct target 
> type
> -and compiler options to use when building the libraries.
>  The user must have all libraries, modules, updates and compilers installed
>  in the system prior to this,
>  as described in the earlier chapters in this Getting Started Guide.

Same here, I would keep only the "Linearization setting".


> --- a/doc/guides/tools/testbbdev.rst
> +++ b/doc/guides/tools/testbbdev.rst
> @@ -13,25 +13,10 @@ parameters passed to a python running script.
>  Compiling the Application
>  -
>  
> -**Step 1: PMD setting**
> +**Build the application**
>  
> -The ``dpdk-test-bbdev`` tool depends on crypto device drivers PMD which
> -are disabled by default in the build configuration file ``common_base``.
> -The bbdevice drivers PMD which should be tested can be enabled by setting
> +See :doc:`../linux_gsg/build_dpdk` for compilation steps.
>  
> -   ``CONFIG_RTE_LIBRTE_PMD_=y``
> -
> -Setting example for (*baseband_turbo_sw*) PMD
> -
> -   ``CONFIG_RTE_LIBRTE_PMD_BBDEV_TURBO_SW=y``
> -
> -**Step 2: Build the application**
> -
> -Execute the ``dpdk-setup.sh`` script to build the DPDK library together with 
> the
> -``dpdk-test-bbdev`` application.
> -
> -Initially, the user must select a DPDK target to choose the correct target 
> type
> -and compiler options to use when building the libraries.
>  The user must have all libraries, modules, updates and compilers installed
>  in the system prior to this, as described in the earlier chapters in this
>  Getting Started Guide.

Same here, there is no value in repeating these obvious considerations
about compilation.

[...]
> --- a/doc/guides/tools/testeventdev.rst
> +++ b/doc/guides/tools/testeventdev.rst
> @@ -15,11 +15,8 @@ Compiling the Application
>  
>  **Build the application**
>  
> -Execute the ``dpdk-setup.sh`` script to build the DPDK library together with 
> the
> -``dpdk-test-e

Re: [dpdk-dev] [PATCH v6 12/14] doc: remove references to make from contributing guide

[Thomas Monjalon]

09/10/2020 12:21, Ciara Power:
> -   As in the linux kernel, the ``CONFIG_`` prefix is not used in C code.
> -   This is only needed in Makefiles or shell scripts.
> +* Use build definition macros and conditions in the Meson build file. This 
> is done when the differences
> +  are more significant. In this case, the code is split into two separate 
> files that are architecture
> +  or environment specific. This should only apply inside the EAL library.

When writing new sentences, it's better splitting lines after a punctuation,
preferably the end of a sentence.


>  Per Architecture Sources
>  
>  
> -The following config options can be used:
> +The following macro options can be used:
>  
> -* ``CONFIG_RTE_ARCH`` is a string that contains the name of the architecture.
> -* ``CONFIG_RTE_ARCH_I686``, ``CONFIG_RTE_ARCH_X86_64``, 
> ``CONFIG_RTE_ARCH_X86_64_32`` or ``CONFIG_RTE_ARCH_PPC_64`` are defined only 
> if we are building for those architectures.
> +* ``RTE_ARCH`` is a string that contains the name of the architecture.
> +* ``RTE_ARCH_I686``, ``RTE_ARCH_X86_64``, ``RTE_ARCH_X86_64_32`` or 
> ``RTE_ARCH_PPC_64`` are defined only if we are building for those 
> architectures.

This is out of date. Arm is notably missing.

>  Per Execution Environment Sources
>  ~
>  
> -The following config options can be used:
> +The following macro options can be used:
>  
> -* ``CONFIG_RTE_EXEC_ENV`` is a string that contains the name of the 
> executive environment.
> -* ``CONFIG_RTE_EXEC_ENV_FREEBSD`` or ``CONFIG_RTE_EXEC_ENV_LINUX`` are 
> defined only if we are building for this execution environment.
> +* ``RTE_EXEC_ENV`` is a string that contains the name of the executive 
> environment.
> +* ``RTE_EXEC_ENV_FREEBSD`` or ``RTE_EXEC_ENV_LINUX`` are defined only if we 
> are building for this execution environment.

This is out of date. Windows is missing.

[...]
> -* Generate all the documentation targets::
> +To enable doc building::
>  
> - make doc
> +   meson configure -Denable_docs=true

No need of this option.
"ninja -C build doc" works even without it.

Re: [dpdk-dev] [PATCH v6 04/14] doc: remove references to make from vdpadevs guides

[Thomas Monjalon]

09/10/2020 12:21, Ciara Power:
> Make is no longer supported for compiling DPDK, references are now
> removed in the documentation.
> 
> Signed-off-by: Ciara Power 
> ---
>  Compilation options
>  ~~~
>  
> -These options can be modified in the ``.config`` file.
> -
> -- ``CONFIG_RTE_LIBRTE_MLX5_VDPA_PMD`` (default **n**)
> -
> -  Toggle compilation of librte_pmd_mlx5 itself.
> -
> -- ``CONFIG_RTE_IBVERBS_LINK_DLOPEN`` (default **n**)
> -
> -  Build PMD with additional code to make it loadable without hard
> -  dependencies on **libibverbs** nor **libmlx5**, which may not be installed
> -  on the target system.
> -
> -  In this mode, their presence is still required for it to run properly,
> -  however their absence won't prevent a DPDK application from starting (with
> -  ``CONFIG_RTE_BUILD_SHARED_LIB`` disabled) and they won't show up as
> -  missing with ``ldd(1)``.
> -
> -  It works by moving these dependencies to a purpose-built rdma-core "glue"
> -  plug-in which must either be installed in a directory whose name is based
> -  on ``CONFIG_RTE_EAL_PMD_PATH`` suffixed with ``-glue`` if set, or in a
> -  standard location for the dynamic linker (e.g. ``/lib``) if left to the
> -  default empty string (``""``).
> -
> -  This option has no performance impact.
> -
> -- ``CONFIG_RTE_IBVERBS_LINK_STATIC`` (default **n**)
> -
> -  Embed static flavor of the dependencies **libibverbs** and **libmlx5**
> -  in the PMD shared library or the executable static binary.

It is completely removing some information
which could be kept if mentioning the meson option "ibverbs_link".

Re: [dpdk-dev] [EXT] [PATCH v6 03/14] doc: remove references to make from NICs guides

[Thomas Monjalon]

09/10/2020 14:00, Igor Russkikh:
> > --- a/doc/guides/nics/qede.rst
> > +++ b/doc/guides/nics/qede.rst
> > @@ -106,22 +106,9 @@ Performance note
> >  Config File Options
> >  ~~~
> > 
> > -The following options can be modified in the ``.config`` file. Please note 
> > that
> > -enabling debugging options may affect system performance.
> > +The following option can be modified in the ``config/rte_config.h`` file.
> > 
> > -- ``CONFIG_RTE_LIBRTE_QEDE_PMD`` (default **y**)
> > -
> > -  Toggle compilation of QEDE PMD driver.
> 
> This one is correctly removed, but the below defines,
> 
> > -- ``CONFIG_RTE_LIBRTE_QEDE_DEBUG_TX`` (default **n**)
> > -
> > -  Toggle display of transmit fast path run-time messages.
> > -
> > -- ``CONFIG_RTE_LIBRTE_QEDE_DEBUG_RX`` (default **n**)
> > -
> > -  Toggle display of receive fast path run-time messages.
> > -
> > -- ``CONFIG_RTE_LIBRTE_QEDE_FW`` (default **""**)
> > +- ``RTE_LIBRTE_QEDE_FW`` (default **""**)
> > 
> >Gives absolute path of firmware file.
> >``Eg: "/lib/firmware/qed/qed_init_values-8.40.33.0.bin"``
> 
> These all still exist. I believe "CONFIG_" prefix should be removed here, but
> the defines and code behind them should stay.

I believe the same comment applies to multiple drivers which have
compilation options and probably should keep this information.

That's the main reason why I didn't apply these patches so far,
waiting for feedbacks.
It has been decided in a maintainers meeting to apply the patches anyway,
but given we have a request for qede, I think it blocks applying this v6.

Re: [dpdk-dev] [PATCH 0/4] Add Marvell OCTEON TX2 regex driver

[Thomas Monjalon]

08/10/2020 08:31, Guy Kaneti:
> Kind reminder to all maintainers, please review and ack/comment.

Please could you rebase?

The 2 rebase issues I see are:
- make is removed
- rte_cio_wmb is removed

Re: [dpdk-dev] [PATCH v6 1/3] ethdev: support device reset and recovery events

[Thomas Monjalon]

09/10/2020 05:48, Kalesh A P:
> From: Kalesh AP 
> 
> Adding support for device reset and recovery events in the
> rte_eth_event framework. FW error and FW reset conditions would be
> managed internally by PMD without needing application intervention.
> In such cases, PMD would need reset/recovery events to notify application
> that PMD is undergoing a reset.
> 
> Signed-off-by: Somnath Kotur 
> Signed-off-by: Kalesh AP 
> Reviewed-by: Ajit Khaparde 
> Reviewed-by: Asaf Penso 

The ethdev maintainers are not Cc'ed.
Please use the option --cc-cmd devtools/get-maintainer.sh


> +Error recovery support
> +~~
> +
> +When the PMD detects a FW reset or error condition, it will try to recover
> +from the error without needing the application intervention. In such cases,
> +PMD would need events to notify the application that it is undergoing
> +an error recovery.
> +
> +The PMD will trigger RTE_ETH_EVENT_ERR_RECOVERING event to notify the
> +application that PMD detected a FW reset or FW error condition. PMD will
> +try to recover from the error by itself. Data path will be halted and
> +control path operations would fail during the recovery period.
> +
> +The PMD will trigger RTE_ETH_EVENT_RECOVERED event to notify the application
> +that the it has recovered from the error condition. Control path and data 
> path
> +are up now. Since the device undergone a reset, flow rules offloaded prior to
> +the reset will be lost and the application has to recreate the rules again.
> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
> index 9759f13..9b4b015 100644
> --- a/lib/librte_ethdev/rte_ethdev.h
> +++ b/lib/librte_ethdev/rte_ethdev.h
> @@ -3207,6 +3207,23 @@ enum rte_eth_event_type {
>   RTE_ETH_EVENT_DESTROY,  /**< port is released */
>   RTE_ETH_EVENT_IPSEC,/**< IPsec offload related event */
>   RTE_ETH_EVENT_FLOW_AGED,/**< New aged-out flows is detected */
> + RTE_ETH_EVENT_ERR_RECOVERING,
> + /**< port recovering from an error
> +  *
> +  * PMD detected a FW reset or error condition.
> +  * PMD will try to recover from the error.
> +  * Data path will be halted and Control path operations
> +  * would fail at this time.
> +  */

Does it mean the application has nothing to do when receiving this event?
I think the app should stop polling at least.

> + RTE_ETH_EVENT_RECOVERED,
> + /**< port recovered from an error
> +  *
> +  * PMD has recovered from the error condition.
> +  * Control path and Data path are up now.
> +  * Since the device undergone a reset, flow rules
> +  * offloaded prior to the reset will be lost and
> +  * the application has to recreate the rules again.
> +  */

Please be more precise.
Should the app re-configure the port, setup the queues, start the port?

[dpdk-dev] [PATCH v2 0/8] support PDCP-SDAP for dpaa2_sec

[Akhil Goyal]

The SDAP is a protocol in the LTE stack on top of PDCP. It is
dedicated to QoS.

The difficulty of implementing this protocol is because the
PDCP change behavior regarding encryption and authentication
of the SDU it receives. In effect PDCP shall not encrypt the
SDAP SDU but must authenticate it (when encryption and
authentication is enabled).

A new field is added in the PDCP xform to specify SDAP is enabled.
The overall size of the xform is not changed, as hfn_ovrd is just
a flag and does not need uint32. Hence, it is converted to uint8_t
and a 16 bit reserved field is added for future.

The corresponding test cases and test vectors are added in the test
application.

This patch need Techboard approval as there is a change in API
without a deprecation notice from last release.
This patch is required to support the upcoming development of
5GNR protocol - SDAP in near future. If the patch is not approved
in the current release, we may not be able to support SDAP for next
1 year which is not accceptable for the customers.

Changes in v2:
- removed unnecessary API documentation from security guide.
- fix clang build
- updated release notes


Akhil Goyal (4):
  security: modify PDCP xform to support SDAP
  doc: remove unnecessary API code from security guide
  crypto/dpaa2_sec: enable PDCP-SDAP sessions
  crypto/dpaa_sec: enable PDCP-SDAP sessions

Franck LENORMAND (4):
  common/dpaax/caamflib: Support PDCP-SDAP
  test/crypto: Add test vectors for PDCP-SDAP
  test/crypto: Modify test_pdcp_proto to take parameters
  test/crypto: Add PDCP-SDAP cases

 app/test/test_cryptodev.c |  278 +-
 ...ryptodev_security_pdcp_sdap_test_vectors.h | 3619 +
 doc/guides/prog_guide/rte_security.rst|   55 +-
 doc/guides/rel_notes/release_20_11.rst|9 +
 drivers/common/dpaax/caamflib/desc/pdcp.h |8 +
 drivers/common/dpaax/caamflib/desc/sdap.h | 1063 +
 drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c   |   30 +-
 drivers/crypto/dpaa_sec/dpaa_sec.c|   63 +-
 drivers/crypto/dpaa_sec/dpaa_sec.h|3 +-
 lib/librte_security/rte_security.h|   12 +-
 10 files changed, 4982 insertions(+), 158 deletions(-)
 create mode 100644 app/test/test_cryptodev_security_pdcp_sdap_test_vectors.h
 create mode 100644 drivers/common/dpaax/caamflib/desc/sdap.h

-- 
2.17.1

[dpdk-dev] [PATCH v2 2/8] security: modify PDCP xform to support SDAP

[Akhil Goyal]

The SDAP is a protocol in the LTE stack on top of PDCP for
QOS. A particular PDCP session may or may not have
SDAP enabled. But if it is enabled, SDAP header should be
authenticated but not encrypted if both confidentiality and
integrity is enabled. Hence, the driver should be intimated
from the xform so that it skip the SDAP header while encryption.

A new field is added in the PDCP xform to specify SDAP is enabled.
The overall size of the xform is not changed, as hfn_ovrd is just
a flag and does not need uint32. Hence, it is converted to uint8_t
and a 16 bit reserved field is added for future.

Signed-off-by: Akhil Goyal 
---
 doc/guides/rel_notes/release_20_11.rst |  9 +
 lib/librte_security/rte_security.h | 12 ++--
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/doc/guides/rel_notes/release_20_11.rst 
b/doc/guides/rel_notes/release_20_11.rst
index c34ab5493..fad91487a 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -103,6 +103,11 @@ New Features
   also known as Mount Bryce.  See the
   :doc:`../bbdevs/acc100` BBDEV guide for more details on this new driver.
 
+* **Updated rte_security library to support SDAP.**
+
+  ``rte_security_pdcp_xform`` in ``rte_security`` lib is updated to enable
+  5G NR processing of SDAP header in PMDs.
+
 * **Updated Virtio driver.**
 
   * Added support for Vhost-vDPA backend to Virtio-user PMD.
@@ -307,6 +312,10 @@ API Changes
   ``rte_fpga_lte_fec_configure`` and structure ``fpga_lte_fec_conf`` to
   ``rte_fpga_lte_fec_conf``.
 
+* security: ``hfn_ovrd`` field in ``rte_security_pdcp_xform`` is changed from
+  ``uint32_t`` to ``uint8_t`` so that a new field ``sdap_enabled`` can be added
+  to support SDAP.
+
 
 ABI Changes
 ---
diff --git a/lib/librte_security/rte_security.h 
b/lib/librte_security/rte_security.h
index 16839e539..c259b35e0 100644
--- a/lib/librte_security/rte_security.h
+++ b/lib/librte_security/rte_security.h
@@ -1,5 +1,5 @@
 /* SPDX-License-Identifier: BSD-3-Clause
- * Copyright 2017,2019 NXP
+ * Copyright 2017,2019-2020 NXP
  * Copyright(c) 2017-2020 Intel Corporation.
  */
 
@@ -290,7 +290,15 @@ struct rte_security_pdcp_xform {
 * per packet HFN in place of IV. PMDs will extract the HFN
 * and perform operations accordingly.
 */
-   uint32_t hfn_ovrd;
+   uint8_t hfn_ovrd;
+   /** In case of 5G NR, a new protocol (SDAP) header may be set
+* inside PDCP payload which should be authenticated but not
+* encrypted. Hence, driver should be notified if SDAP is
+* enabled or not, so that SDAP header is not encrypted.
+*/
+   uint8_t sdap_enabled;
+   /** Reserved for future */
+   uint16_t reserved;
 };
 
 /** DOCSIS direction */
-- 
2.17.1

[dpdk-dev] [PATCH v2 3/8] doc: remove unnecessary API code from security guide

[Akhil Goyal]

Various xform structures are being copied in
rte_security guide which can be referred from the
API documentation generated by Doxygen. The security guide
does not talk about specific details of these xforms and
thus are removed from the security guide.

Signed-off-by: Akhil Goyal 
---
 doc/guides/prog_guide/rte_security.rst | 55 +-
 1 file changed, 1 insertion(+), 54 deletions(-)

diff --git a/doc/guides/prog_guide/rte_security.rst 
b/doc/guides/prog_guide/rte_security.rst
index 127da2e4f..41c95aa52 100644
--- a/doc/guides/prog_guide/rte_security.rst
+++ b/doc/guides/prog_guide/rte_security.rst
@@ -1,5 +1,5 @@
 ..  SPDX-License-Identifier: BSD-3-Clause
-Copyright 2017 NXP
+Copyright 2017,2020 NXP
 
 
 
@@ -647,63 +647,10 @@ which will be updated in the future.
 
 IPsec related configuration parameters are defined in 
``rte_security_ipsec_xform``
 
-.. code-block:: c
-
-struct rte_security_ipsec_xform {
-uint32_t spi;
-/**< SA security parameter index */
-uint32_t salt;
-/**< SA salt */
-struct rte_security_ipsec_sa_options options;
-/**< various SA options */
-enum rte_security_ipsec_sa_direction direction;
-/**< IPsec SA Direction - Egress/Ingress */
-enum rte_security_ipsec_sa_protocol proto;
-/**< IPsec SA Protocol - AH/ESP */
-enum rte_security_ipsec_sa_mode mode;
-/**< IPsec SA Mode - transport/tunnel */
-struct rte_security_ipsec_tunnel_param tunnel;
-/**< Tunnel parameters, NULL for transport mode */
-};
-
 PDCP related configuration parameters are defined in 
``rte_security_pdcp_xform``
 
-.. code-block:: c
-
-struct rte_security_pdcp_xform {
-int8_t bearer; /**< PDCP bearer ID */
-/** Enable in order delivery, this field shall be set only if
- * driver/HW is capable. See RTE_SECURITY_PDCP_ORDERING_CAP.
- */
-uint8_t en_ordering;
-/** Notify driver/HW to detect and remove duplicate packets.
- * This field should be set only when driver/hw is capable.
- * See RTE_SECURITY_PDCP_DUP_DETECT_CAP.
- */
-uint8_t remove_duplicates;
-/** PDCP mode of operation: Control or data */
-enum rte_security_pdcp_domain domain;
-/** PDCP Frame Direction 0:UL 1:DL */
-enum rte_security_pdcp_direction pkt_dir;
-/** Sequence number size, 5/7/12/15/18 */
-enum rte_security_pdcp_sn_size sn_size;
-/** Starting Hyper Frame Number to be used together with the SN
- * from the PDCP frames
- */
-uint32_t hfn;
-/** HFN Threshold for key renegotiation */
-uint32_t hfn_threshold;
-};
-
 DOCSIS related configuration parameters are defined in 
``rte_security_docsis_xform``
 
-.. code-block:: c
-
-struct rte_security_docsis_xform {
-enum rte_security_docsis_direction direction;
-/**< DOCSIS direction */
-};
-
 
 Security API
 
-- 
2.17.1

[dpdk-dev] [PATCH v2 4/8] crypto/dpaa2_sec: enable PDCP-SDAP sessions

[Akhil Goyal]

Based on the new field in PDCP xform, a decision is made
to create a PDCP session with or without SDAP enabled.

Signed-off-by: Akhil Goyal 
---
 drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c | 30 ++---
 1 file changed, 26 insertions(+), 4 deletions(-)

diff --git a/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c 
b/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
index c11d02420..f8e8750e4 100644
--- a/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
+++ b/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
@@ -36,6 +36,7 @@
 /* RTA header files */
 #include 
 #include 
+#include 
 #include 
 
 /* Minimum job descriptor consists of a oneword job descriptor HEADER and
@@ -3264,8 +3265,9 @@ dpaa2_sec_set_pdcp_session(struct rte_cryptodev *dev,
&cipherdata, &authdata,
0);
} else {
-   if (session->dir == DIR_ENC)
-   bufsize = cnstr_shdsc_pdcp_u_plane_encap(
+   if (session->dir == DIR_ENC) {
+   if (pdcp_xform->sdap_enabled)
+   bufsize = cnstr_shdsc_pdcp_sdap_u_plane_encap(
priv->flc_desc[0].desc, 1, swap,
session->pdcp.sn_size,
pdcp_xform->hfn,
@@ -3273,8 +3275,18 @@ dpaa2_sec_set_pdcp_session(struct rte_cryptodev *dev,
pdcp_xform->pkt_dir,
pdcp_xform->hfn_threshold,
&cipherdata, p_authdata, 0);
-   else if (session->dir == DIR_DEC)
-   bufsize = cnstr_shdsc_pdcp_u_plane_decap(
+   else
+   bufsize = cnstr_shdsc_pdcp_u_plane_encap(
+   priv->flc_desc[0].desc, 1, swap,
+   session->pdcp.sn_size,
+   pdcp_xform->hfn,
+   pdcp_xform->bearer,
+   pdcp_xform->pkt_dir,
+   pdcp_xform->hfn_threshold,
+   &cipherdata, p_authdata, 0);
+   } else if (session->dir == DIR_DEC) {
+   if (pdcp_xform->sdap_enabled)
+   bufsize = cnstr_shdsc_pdcp_sdap_u_plane_decap(
priv->flc_desc[0].desc, 1, swap,
session->pdcp.sn_size,
pdcp_xform->hfn,
@@ -3282,6 +3294,16 @@ dpaa2_sec_set_pdcp_session(struct rte_cryptodev *dev,
pdcp_xform->pkt_dir,
pdcp_xform->hfn_threshold,
&cipherdata, p_authdata, 0);
+   else
+   bufsize = cnstr_shdsc_pdcp_u_plane_decap(
+   priv->flc_desc[0].desc, 1, swap,
+   session->pdcp.sn_size,
+   pdcp_xform->hfn,
+   pdcp_xform->bearer,
+   pdcp_xform->pkt_dir,
+   pdcp_xform->hfn_threshold,
+   &cipherdata, p_authdata, 0);
+   }
}
 
if (bufsize < 0) {
-- 
2.17.1

[dpdk-dev] [PATCH v2 5/8] crypto/dpaa_sec: enable PDCP-SDAP sessions

[Akhil Goyal]

Based on the new field in PDCP xform, a decision is made
to create a PDCP session with or without SDAP enabled.

Signed-off-by: Akhil Goyal 
---
 drivers/crypto/dpaa_sec/dpaa_sec.c | 63 +-
 drivers/crypto/dpaa_sec/dpaa_sec.h |  3 +-
 2 files changed, 47 insertions(+), 19 deletions(-)

diff --git a/drivers/crypto/dpaa_sec/dpaa_sec.c 
b/drivers/crypto/dpaa_sec/dpaa_sec.c
index 0495422a4..f69cb5719 100644
--- a/drivers/crypto/dpaa_sec/dpaa_sec.c
+++ b/drivers/crypto/dpaa_sec/dpaa_sec.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -293,24 +294,49 @@ dpaa_sec_prep_pdcp_cdb(dpaa_sec_session *ses)
&cipherdata, &authdata,
0);
} else {
-   if (ses->dir == DIR_ENC)
-   shared_desc_len = cnstr_shdsc_pdcp_u_plane_encap(
-   cdb->sh_desc, 1, swap,
-   ses->pdcp.sn_size,
-   ses->pdcp.hfn,
-   ses->pdcp.bearer,
-   ses->pdcp.pkt_dir,
-   ses->pdcp.hfn_threshold,
-   &cipherdata, p_authdata, 0);
-   else if (ses->dir == DIR_DEC)
-   shared_desc_len = cnstr_shdsc_pdcp_u_plane_decap(
-   cdb->sh_desc, 1, swap,
-   ses->pdcp.sn_size,
-   ses->pdcp.hfn,
-   ses->pdcp.bearer,
-   ses->pdcp.pkt_dir,
-   ses->pdcp.hfn_threshold,
-   &cipherdata, p_authdata, 0);
+   if (ses->dir == DIR_ENC) {
+   if (ses->pdcp.sdap_enabled)
+   shared_desc_len =
+   cnstr_shdsc_pdcp_sdap_u_plane_encap(
+   cdb->sh_desc, 1, swap,
+   ses->pdcp.sn_size,
+   ses->pdcp.hfn,
+   ses->pdcp.bearer,
+   ses->pdcp.pkt_dir,
+   ses->pdcp.hfn_threshold,
+   &cipherdata, p_authdata, 0);
+   else
+   shared_desc_len =
+   cnstr_shdsc_pdcp_u_plane_encap(
+   cdb->sh_desc, 1, swap,
+   ses->pdcp.sn_size,
+   ses->pdcp.hfn,
+   ses->pdcp.bearer,
+   ses->pdcp.pkt_dir,
+   ses->pdcp.hfn_threshold,
+   &cipherdata, p_authdata, 0);
+   } else if (ses->dir == DIR_DEC) {
+   if (ses->pdcp.sdap_enabled)
+   shared_desc_len =
+   cnstr_shdsc_pdcp_sdap_u_plane_decap(
+   cdb->sh_desc, 1, swap,
+   ses->pdcp.sn_size,
+   ses->pdcp.hfn,
+   ses->pdcp.bearer,
+   ses->pdcp.pkt_dir,
+   ses->pdcp.hfn_threshold,
+   &cipherdata, p_authdata, 0);
+   else
+   shared_desc_len =
+   cnstr_shdsc_pdcp_u_plane_decap(
+   cdb->sh_desc, 1, swap,
+   ses->pdcp.sn_size,
+   ses->pdcp.hfn,
+   ses->pdcp.bearer,
+   ses->pdcp.pkt_dir,
+   ses->pdcp.hfn_threshold,
+   &cipherdata, p_authdata, 0);
+   }
}
return shared_desc_len;
 }
@@ -2949,6 +2975,7 @@ dpaa_sec_set_pdcp_session(struct rte_cryptodev *dev,
session->pdcp.hfn = pdcp_xform->hfn;
session->pdcp.hfn_threshold = pdcp_xform->hfn_threshold;
session->pdcp.hfn_ovd = pdcp_xform->hfn_ovrd;
+   session->pdcp.sdap_enabled = pdcp_xform->sdap_enabled;
if (cipher_xform)
session->pdcp.hfn

[dpdk-dev] [PATCH v2 1/8] common/dpaax/caamflib: Support PDCP-SDAP

[Akhil Goyal]

From: Franck LENORMAND 

The SDAP is a protocol in the LTE stack on top of PDCP. It is
dedicated to QoS.

The difficulty of implementing this protocol is because the
PDCP change behavior regarding encryption and authentication
of the SDU it receives. In effect PDCP shall not encrypt the
SDAP SDU but must authenticate it (when encryption and
authentication is enabled).

The current version of SEC does not support the SDAP and the
change of behavior of PDCP prevent the use of the PDCP
protocol command available.

The way to do it is to reuse the PDCP implementation but to
not use the PDCP protocol and to have descriptors which
performs the PDCP protocol.

It is configured by:

It is implemented done doing small changes of code:
#ifdef SDAP_SUPPORT
length += SDAP_BYTE_SIZE;
offset -= SDAP_BYTE_SIZE;
#endif
after having computed the size of the SN to read from the
input data, then
#ifdef SDAP_SUPPORT
MATHI(p, MATH0, LSHIFT, 8, MATH1, 8, 0);
MATHB(p, MATH1, AND, sn_mask, MATH1, 8, IFB | IMMED2);
#else
MATHB(p, MATH0, AND, sn_mask, MATH1, 8, IFB | IMMED2);
#endif
It will keep the SN and the SDAP header in MATH0, then shift
it to remove the SDAP header and store the result in MATH1.

Signed-off-by: Franck LENORMAND 
Signed-off-by: Akhil Goyal 
---
 drivers/common/dpaax/caamflib/desc/pdcp.h |8 +
 drivers/common/dpaax/caamflib/desc/sdap.h | 1063 +
 2 files changed, 1071 insertions(+)
 create mode 100644 drivers/common/dpaax/caamflib/desc/sdap.h

diff --git a/drivers/common/dpaax/caamflib/desc/pdcp.h 
b/drivers/common/dpaax/caamflib/desc/pdcp.h
index 95d1416c2..f084cf1de 100644
--- a/drivers/common/dpaax/caamflib/desc/pdcp.h
+++ b/drivers/common/dpaax/caamflib/desc/pdcp.h
@@ -43,6 +43,14 @@
 #define PDCP_C_PLANE_SN_MASK   0x1F00
 #define PDCP_C_PLANE_SN_MASK_BE0x001F
 
+/**
+ * PDCP_7BIT_SN_MASK - This mask is used in the PDCP descriptors for
+ *  extracting the sequence number (SN) from the
+ *  PDCP User Plane header.
+ */
+#define PDCP_7BIT_SN_MASK  0x7F00
+#define PDCP_7BIT_SN_MASK_BE   0x007F
+
 /**
  * PDCP_12BIT_SN_MASK - This mask is used in the PDCP descriptors for
  *  extracting the sequence number (SN) from the
diff --git a/drivers/common/dpaax/caamflib/desc/sdap.h 
b/drivers/common/dpaax/caamflib/desc/sdap.h
new file mode 100644
index 0..e4ed3e159
--- /dev/null
+++ b/drivers/common/dpaax/caamflib/desc/sdap.h
@@ -0,0 +1,1063 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2020 NXP
+ */
+
+#ifndef __DESC_SDAP_H__
+#define __DESC_SDAP_H__
+
+#include "rta.h"
+#include "common.h"
+#include "pdcp.h"
+
+/* The file defines all the functions to do PDCP without protocol support in
+ * SEC
+ */
+
+/* Enable SDAP support */
+#define SDAP_SUPPORT
+#ifdef SDAP_SUPPORT
+#define SDAP_BYTE_SIZE 1
+#define SDAP_BITS_SIZE (SDAP_BYTE_SIZE * 8)
+#endif
+
+static inline void key_loading_opti(struct program *p,
+   struct alginfo *cipherdata,
+   struct alginfo *authdata)
+{
+   LABEL(lbl_skip_key_loading_jump);
+   REFERENCE(ref_skip_key_loading_jump);
+
+   /* Optimisation to bypass key loading (and decryption of the keys):
+* Jump command testing:
+* - SHRD: Descriptor is shared
+* - SELF: The shared descriptor is in the same DECO
+* - BOTH: The Class 1 and 2 CHA have finished
+* -> If this is true, we jump and skip loading of the keys as they are
+*already loaded
+*/
+   ref_skip_key_loading_jump =
+   JUMP(p, lbl_skip_key_loading_jump, LOCAL_JUMP, ALL_TRUE,
+SHRD | SELF | BOTH);
+
+   /* Load the keys */
+   if (cipherdata) {
+   KEY(p, KEY1, cipherdata->key_enc_flags, cipherdata->key,
+   cipherdata->keylen, INLINE_KEY(cipherdata));
+   }
+
+   if (authdata) {
+   KEY(p, KEY2, authdata->key_enc_flags, authdata->key,
+   authdata->keylen, INLINE_KEY(authdata));
+   }
+
+   /* Save the place where we want the jump to go */
+   SET_LABEL(p, lbl_skip_key_loading_jump);
+   /* Update the jump command with the position where to jump */
+   PATCH_JUMP(p, ref_skip_key_loading_jump, lbl_skip_key_loading_jump);
+}
+
+static inline int pdcp_sdap_get_sn_parameters(enum pdcp_sn_size sn_size,
+ bool swap, uint32_t *offset,
+ uint32_t *length,
+ uint32_t *sn_mask)
+{
+   switch (sn_size) {
+   case PDCP_SN_SIZE_5:
+   *offset = 7;
+   *length = 1;
+   *sn_mask = (swap == false) ? PDCP_C_PLANE_SN_MASK

[dpdk-dev] [PATCH v2 6/8] test/crypto: Add test vectors for PDCP-SDAP

[Akhil Goyal]

From: Franck LENORMAND 

The test vectors are structured in a more readable way compared
to test vector for PDCP. This structure allows to have all the
information about a test vector at the same place.

Signed-off-by: Franck LENORMAND 
Signed-off-by: Akhil Goyal 
---
 ...ryptodev_security_pdcp_sdap_test_vectors.h | 3619 +
 1 file changed, 3619 insertions(+)
 create mode 100644 app/test/test_cryptodev_security_pdcp_sdap_test_vectors.h

diff --git a/app/test/test_cryptodev_security_pdcp_sdap_test_vectors.h 
b/app/test/test_cryptodev_security_pdcp_sdap_test_vectors.h
new file mode 100644
index 0..f43f693ed
--- /dev/null
+++ b/app/test/test_cryptodev_security_pdcp_sdap_test_vectors.h
@@ -0,0 +1,3619 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ *
+ * Copyright 2020 NXP
+ */
+
+#ifndef SECURITY_PDCP_SDAP_TEST_VECTOR_H_
+#define SECURITY_PDCP_SDAP_TEST_VECTOR_H_
+
+#include 
+
+struct pdcp_sdap_test {
+   uint32_t test_idx;
+   struct pdcp_sdap_test_param {
+   uint8_t type;
+   enum rte_security_pdcp_domain domain;
+   enum rte_crypto_cipher_algorithm cipher_alg;
+   uint8_t cipher_key_len;
+   enum rte_crypto_auth_algorithm auth_alg;
+   uint8_t auth_key_len;
+   const char *name;
+   } param;
+   const uint8_t *cipher_key;
+   const uint8_t *auth_key;
+   const uint8_t *data_in;
+   uint32_t in_len;
+   const uint8_t *data_out;
+   uint8_t sn_size;
+   uint32_t hfn;
+   uint32_t hfn_threshold;
+   uint8_t bearer;
+   uint8_t packet_direction;
+};
+
+static const struct pdcp_sdap_test list_pdcp_sdap_tests[] = {
+   / 7bit /
+
+   / null + null /
+
+   {
+   .test_idx = 1,
+   .param = {.name = "PDCP-SDAP Uplane: 7b SN, NULL_ENC Uplink",
+   .cipher_alg = RTE_CRYPTO_CIPHER_NULL,
+   .auth_alg = 0,
+   .domain = RTE_SECURITY_PDCP_MODE_DATA,
+   .cipher_key_len = 16,
+   .auth_key_len = 16,
+   },
+   .cipher_key = (uint8_t[]){ 0x5a, 0xcb, 0x1d, 0x64, 0x4c, 0x0d,
+  0x51, 0x20, 0x4e, 0xa5, 0xf1, 0x45,
+  0x10, 0x10, 0xd8, 0x52 },
+   .auth_key = NULL,
+   .data_in = (uint8_t[]){ 0x8b, 0xad, 0x9c, 0x44, 0x1f, 0x89,
+   0x0b, 0x38, 0xc4, 0x57, 0xa4, 0x9d,
+   0x42, 0x14, 0x07, 0xe8 },
+   .in_len = 16,
+   .data_out = (uint8_t[]){ 0x8b, 0xad, 0x9c, 0x44, 0x1f, 0x89,
+0x0b, 0x38, 0xc4, 0x57, 0xa4, 0x9d,
+0x42, 0x14, 0x07, 0xe8 },
+   .sn_size = 7,
+   .hfn = 0xfa557,
+   .hfn_threshold = 0xfa558,
+   .bearer = 0x3,
+   .packet_direction = 0,
+   },
+
+   / null + null /
+
+   {
+   .test_idx = 2,
+   .param = {.name = "PDCP-SDAP Uplane: 7b SN, NULL_ENC Downlink",
+   .cipher_alg = RTE_CRYPTO_CIPHER_NULL,
+   .auth_alg = 0,
+   .domain = RTE_SECURITY_PDCP_MODE_DATA,
+   .cipher_key_len = 16,
+   .auth_key_len = 16,
+   },
+   .cipher_key = (uint8_t[]){ 0x5a, 0xcb, 0x1d, 0x64, 0x4c, 0x0d,
+  0x51, 0x20, 0x4e, 0xa5, 0xf1, 0x45,
+  0x10, 0x10, 0xd8, 0x52 },
+   .auth_key = NULL,
+   .data_in = (uint8_t[]){ 0x8b, 0xad, 0x9c, 0x44, 0x1f, 0x89,
+   0x0b, 0x38, 0xc4, 0x57, 0xa4, 0x9d,
+   0x42, 0x14, 0x07, 0xe8 },
+   .in_len = 16,
+   .data_out = (uint8_t[]){ 0x8b, 0xad, 0x9c, 0x44, 0x1f, 0x89,
+0x0b, 0x38, 0xc4, 0x57, 0xa4, 0x9d,
+0x42, 0x14, 0x07, 0xe8 },
+   .sn_size = 7,
+   .hfn = 0xfa557,
+   .hfn_threshold = 0xfa558,
+   .bearer = 0x3,
+   .packet_direction = 1,
+   },
+
+   / aes-ctr + null /
+
+   {
+   .test_idx = 3,
+   .param = {.name = "PDCP-SDAP Uplane: 7b SN, AES-CTR_ENC Uplink",
+   .cipher_alg = RTE_CRYPTO_CIPHER_AES_CTR,
+   .auth_alg = 0,
+   .domain = RTE_SECURITY_PDCP_MODE_DATA,
+   .cipher_key_len = 16,
+   .

[dpdk-dev] [PATCH v2 8/8] test/crypto: Add PDCP-SDAP cases

[Akhil Goyal]

From: Franck LENORMAND 

A new functions which uses the structure of the test vectors for SDAP
is added and call a functions responsible to call the test_pdcp_proto
with the test vector both for encapsulation and decapsulation.

Signed-off-by: Franck LENORMAND 
Signed-off-by: Akhil Goyal 
---
 app/test/test_cryptodev.c | 95 +++
 1 file changed, 95 insertions(+)

diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
index 7cea914f9..590691521 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -1,5 +1,6 @@
 /* SPDX-License-Identifier: BSD-3-Clause
  * Copyright(c) 2015-2020 Intel Corporation
+ * Copyright 2020 NXP
  */
 
 #include 
@@ -42,8 +43,12 @@
 #include "test_cryptodev_mixed_test_vectors.h"
 #ifdef RTE_LIBRTE_SECURITY
 #include "test_cryptodev_security_pdcp_test_vectors.h"
+#include "test_cryptodev_security_pdcp_sdap_test_vectors.h"
 #include "test_cryptodev_security_pdcp_test_func.h"
 #include "test_cryptodev_security_docsis_test_vectors.h"
+
+#define SDAP_DISABLED  0
+#define SDAP_ENABLED   1
 #endif
 
 #define VDEV_ARGS_SIZE 100
@@ -52,6 +57,10 @@
 #define IN_PLACE 0
 #define OUT_OF_PLACE 1
 
+#ifndef ARRAY_SIZE
+#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
+#endif
+
 static int gbl_driver_id;
 
 static enum rte_security_session_action_type gbl_action_type =
@@ -7743,6 +7752,90 @@ test_PDCP_PROTO_SGL_oop_128B_32B(void)
128, 32);
 }
 
+static int
+test_PDCP_SDAP_PROTO_encap_all(void)
+{
+   int i = 0, size = 0;
+   int err, all_err = TEST_SUCCESS;
+   const struct pdcp_sdap_test *cur_test;
+
+   size = ARRAY_SIZE(list_pdcp_sdap_tests);
+
+   for (i = 0; i < size; i++) {
+   cur_test = &list_pdcp_sdap_tests[i];
+   err = test_pdcp_proto(
+   i, 0, RTE_CRYPTO_CIPHER_OP_ENCRYPT,
+   RTE_CRYPTO_AUTH_OP_GENERATE, cur_test->data_in,
+   cur_test->in_len, cur_test->data_out,
+   cur_test->in_len + ((cur_test->auth_key) ? 4 : 0),
+   cur_test->param.cipher_alg, cur_test->cipher_key,
+   cur_test->param.cipher_key_len,
+   cur_test->param.auth_alg,
+   cur_test->auth_key, cur_test->param.auth_key_len,
+   cur_test->bearer, cur_test->param.domain,
+   cur_test->packet_direction, cur_test->sn_size,
+   cur_test->hfn,
+   cur_test->hfn_threshold, SDAP_ENABLED);
+   if (err) {
+   printf("\t%d) %s: Encapsulation failed\n",
+   cur_test->test_idx,
+   cur_test->param.name);
+   err = TEST_FAILED;
+   } else {
+   printf("\t%d) %s: Encap PASS\n", cur_test->test_idx,
+   cur_test->param.name);
+   err = TEST_SUCCESS;
+   }
+   all_err += err;
+   }
+
+   printf("Success: %d, Failure: %d\n", size + all_err, -all_err);
+
+   return (all_err == TEST_SUCCESS) ? TEST_SUCCESS : TEST_FAILED;
+}
+
+static int
+test_PDCP_SDAP_PROTO_decap_all(void)
+{
+   int i = 0, size = 0;
+   int err, all_err = TEST_SUCCESS;
+   const struct pdcp_sdap_test *cur_test;
+
+   size = ARRAY_SIZE(list_pdcp_sdap_tests);
+
+   for (i = 0; i < size; i++) {
+   cur_test = &list_pdcp_sdap_tests[i];
+   err = test_pdcp_proto(
+   i, 0, RTE_CRYPTO_CIPHER_OP_DECRYPT,
+   RTE_CRYPTO_AUTH_OP_VERIFY,
+   cur_test->data_out,
+   cur_test->in_len + ((cur_test->auth_key) ? 4 : 0),
+   cur_test->data_in, cur_test->in_len,
+   cur_test->param.cipher_alg,
+   cur_test->cipher_key, cur_test->param.cipher_key_len,
+   cur_test->param.auth_alg, cur_test->auth_key,
+   cur_test->param.auth_key_len, cur_test->bearer,
+   cur_test->param.domain, cur_test->packet_direction,
+   cur_test->sn_size, cur_test->hfn,
+   cur_test->hfn_threshold, SDAP_ENABLED);
+   if (err) {
+   printf("\t%d) %s: Decapsulation failed\n",
+   cur_test->test_idx,
+   cur_test->param.name);
+   err = TEST_FAILED;
+   } else {
+   printf("\t%d) %s: Decap PASS\n", cur_test->test_idx,
+   cur_test->param.name);
+   err = TEST_SUCCESS;
+   }
+   all_err += err;
+   }
+
+   printf("Success: %d, Failure: %d\n", size + all_err, -all_err);
+
+   return (all

[dpdk-dev] [PATCH v2 7/8] test/crypto: Modify test_pdcp_proto to take parameters

[Akhil Goyal]

From: Franck LENORMAND 

The function test_pdcp_proto was relying to heavily on the structure
of test vectors for PDCP making it difficult to be reusable.

The function is changed to take all the test parameters as input and
does not need access to the tests vectors anymore.

Signed-off-by: Franck LENORMAND 
---
 app/test/test_cryptodev.c | 183 ++
 1 file changed, 104 insertions(+), 79 deletions(-)

diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
index ac2a36bc2..7cea914f9 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -7121,14 +7121,18 @@ security_proto_supported(enum 
rte_security_session_action_type action,
  * on input_vec. Checks the output of the crypto operation against
  * output_vec.
  */
-static int
-test_pdcp_proto(int i, int oop,
-   enum rte_crypto_cipher_operation opc,
-   enum rte_crypto_auth_operation opa,
-   uint8_t *input_vec,
-   unsigned int input_vec_len,
-   uint8_t *output_vec,
-   unsigned int output_vec_len)
+static int test_pdcp_proto(int i, int oop, enum rte_crypto_cipher_operation 
opc,
+  enum rte_crypto_auth_operation opa,
+  const uint8_t *input_vec, unsigned int input_vec_len,
+  const uint8_t *output_vec,
+  unsigned int output_vec_len,
+  enum rte_crypto_cipher_algorithm cipher_alg,
+  const uint8_t *cipher_key, uint32_t cipher_key_len,
+  enum rte_crypto_auth_algorithm auth_alg,
+  const uint8_t *auth_key, uint32_t auth_key_len,
+  uint8_t bearer, enum rte_security_pdcp_domain domain,
+  uint8_t packet_direction, uint8_t sn_size,
+  uint32_t hfn, uint32_t hfn_threshold, uint8_t sdap)
 {
struct crypto_testsuite_params *ts_params = &testsuite_params;
struct crypto_unittest_params *ut_params = &unittest_params;
@@ -7143,7 +7147,7 @@ test_pdcp_proto(int i, int oop,
 
sec_cap_idx.action = ut_params->type;
sec_cap_idx.protocol = RTE_SECURITY_PROTOCOL_PDCP;
-   sec_cap_idx.pdcp.domain = pdcp_test_params[i].domain;
+   sec_cap_idx.pdcp.domain = domain;
if (rte_security_capability_get(ctx, &sec_cap_idx) == NULL)
return -ENOTSUP;
 
@@ -7169,24 +7173,22 @@ test_pdcp_proto(int i, int oop,
 
/* Setup Cipher Parameters */
ut_params->cipher_xform.type = RTE_CRYPTO_SYM_XFORM_CIPHER;
-   ut_params->cipher_xform.cipher.algo = pdcp_test_params[i].cipher_alg;
+   ut_params->cipher_xform.cipher.algo = cipher_alg;
ut_params->cipher_xform.cipher.op = opc;
-   ut_params->cipher_xform.cipher.key.data = pdcp_test_crypto_key[i];
-   ut_params->cipher_xform.cipher.key.length =
-   pdcp_test_params[i].cipher_key_len;
+   ut_params->cipher_xform.cipher.key.data = cipher_key;
+   ut_params->cipher_xform.cipher.key.length = cipher_key_len;
ut_params->cipher_xform.cipher.iv.length =
-   pdcp_test_packet_direction[i] ? 4 : 0;
+   packet_direction ? 4 : 0;
ut_params->cipher_xform.cipher.iv.offset = IV_OFFSET;
 
/* Setup HMAC Parameters if ICV header is required */
-   if (pdcp_test_params[i].auth_alg != 0) {
+   if (auth_alg != 0) {
ut_params->auth_xform.type = RTE_CRYPTO_SYM_XFORM_AUTH;
ut_params->auth_xform.next = NULL;
-   ut_params->auth_xform.auth.algo = pdcp_test_params[i].auth_alg;
+   ut_params->auth_xform.auth.algo = auth_alg;
ut_params->auth_xform.auth.op = opa;
-   ut_params->auth_xform.auth.key.data = pdcp_test_auth_key[i];
-   ut_params->auth_xform.auth.key.length =
-   pdcp_test_params[i].auth_key_len;
+   ut_params->auth_xform.auth.key.data = auth_key;
+   ut_params->auth_xform.auth.key.length = auth_key_len;
 
ut_params->cipher_xform.next = &ut_params->auth_xform;
} else {
@@ -7197,22 +7199,22 @@ test_pdcp_proto(int i, int oop,
.action_type = ut_params->type,
.protocol = RTE_SECURITY_PROTOCOL_PDCP,
{.pdcp = {
-   .bearer = pdcp_test_bearer[i],
-   .domain = pdcp_test_params[i].domain,
-   .pkt_dir = pdcp_test_packet_direction[i],
-   .sn_size = pdcp_test_data_sn_size[i],
-   .hfn = pdcp_test_packet_direction[i] ?
-   0 : pdcp_test_hfn[i],
-   /**
-* hfn can be set as pdcp_test_hfn[i]
-* if hfn_ovrd is not set. Here, PDCP
-* 

Re: [dpdk-dev] [PATCH 1/3 v3] ethdev: add rx offload to drop error packets

[Thomas Monjalon]

Hi,

The configuration of this feature is not clear to me.
Please see the comments below.

09/10/2020 15:13, nipun.gu...@nxp.com:
> From: Nipun Gupta 
> 
> This change adds a RX offload capability and configuration to
> enable hardware to drop the packets in case of any error in the
> packets such as L3 checksum error or L4 checksum.
> 
> Signed-off-by: Nipun Gupta 
> Signed-off-by: Rohit Raj 
> Reviewed-by: Asaf Penso 
> ---
[...]
> +/**
> + * A structure used to enable/disable error packet drop on RX.

RX -> Rx
same for other occurences below

> + */
> +struct rte_rx_err_pkt_drop_conf {

The name should start with rte_eth_

> + /** enable/disable all RX error packet drop.
> +  * 0 (default) - disable, 1 enable
> +  */
> + uint32_t all:1;
> +};

I don't understand the meaning of this struct.
Is it just one bit to drop packets having an error?
How do you determine what is an error?

[...]
> @@ -1236,6 +1246,8 @@ struct rte_eth_conf {
>   uint32_t dcb_capability_en;
>   struct rte_fdir_conf fdir_conf; /**< FDIR configuration. DEPRECATED */
>   struct rte_intr_conf intr_conf; /**< Interrupt mode configuration. */
> + struct rte_rx_err_pkt_drop_conf err_pkt_drop_conf;
> + /**< RX error packet drop configuration. */

Why a per-port configuration is needed in addition of the per-queue offload?

[...]
> @@ -1260,6 +1272,7 @@ struct rte_eth_conf {
>  #define DEV_RX_OFFLOAD_SCTP_CKSUM0x0002
>  #define DEV_RX_OFFLOAD_OUTER_UDP_CKSUM  0x0004
>  #define DEV_RX_OFFLOAD_RSS_HASH  0x0008
> +#define DEV_RX_OFFLOAD_ERR_PKT_DROP  0x0010

New offload names should starte with RTE_ prefix.


> +/**
> + * RX Error Drop offload config/capabilities of a device. These
> + * are valid only when RX capability DEV_RX_OFFLOAD_ERR_PKT_DROP
> + * is supported by the device.
> + */
> +#define DEV_RX_ERR_PKT_DROP_OFFLOAD_ALL  0x0001

I don't understand the meaning.

> @@ -1411,6 +1431,8 @@ struct rte_eth_dev_info {
>   /**< Device per-queue RX offload capabilities. */
>   uint64_t tx_queue_offload_capa;
>   /**< Device per-queue TX offload capabilities. */
> + uint64_t rx_err_drop_offload_capa;
> + /**< RX error packet drop offload capabilities. */

Why adding a new field here instead of reporting in rx_offload_capa?

Re: [dpdk-dev] [PATCH v2 6/8] test/crypto: Add test vectors for PDCP-SDAP

[Thomas Monjalon]

11/10/2020 23:34, Akhil Goyal:
> Signed-off-by: Franck LENORMAND 

Please follow the same scheme as everybody for names:
only the first letter is capital.

> Signed-off-by: Akhil Goyal 

Re: [dpdk-dev] [PATCH v2 1/9] ethdev: introduce Rx buffer split

[Thomas Monjalon]

07/10/2020 17:06, Viacheslav Ovsiienko:
> The DPDK datapath in the transmit direction is very flexible.
> An application can build the multi-segment packet and manages
> almost all data aspects - the memory pools where segments
> are allocated from, the segment lengths, the memory attributes
> like external buffers, registered for DMA, etc.
> 
> In the receiving direction, the datapath is much less flexible,
> an application can only specify the memory pool to configure the
> receiving queue and nothing more. In order to extend receiving
> datapath capabilities it is proposed to add the way to provide
> extended information how to split the packets being received.
> 
> The following structure is introduced to specify the Rx packet
> segment:
> 
> struct rte_eth_rxseg {
> struct rte_mempool *mp; /* memory pools to allocate segment from */
> uint16_t length; /* segment maximal data length */

The "length" parameter is configuring a split point.
Worth to note in the comment I think.

> uint16_t offset; /* data offset from beginning of mbuf data buffer */

Is it replacing RTE_PKTMBUF_HEADROOM?

> uint32_t reserved; /* reserved field */
> };
> 
> The new routine rte_eth_rx_queue_setup_ex() is introduced to
> setup the given Rx queue using the new extended Rx packet segment
> description:
> 
> int
> rte_eth_rx_queue_setup_ex(uint16_t port_id, uint16_t rx_queue_id,
>   uint16_t nb_rx_desc, unsigned int socket_id,
>   const struct rte_eth_rxconf *rx_conf,
> const struct rte_eth_rxseg *rx_seg,
>   uint16_t n_seg)

An alternative name for this function:
rte_eth_rxseg_queue_setup

> This routine presents the two new parameters:
> rx_seg - pointer the array of segment descriptions, each element
>  describes the memory pool, maximal data length, initial
>  data offset from the beginning of data buffer in mbuf
> n_seg - number of elements in the array

Not clear why we need an array.
I suggest writing here that each segment of the same packet
can have different properties, the array representing the full packet.

> The new offload flag DEV_RX_OFFLOAD_BUFFER_SPLIT in device

The name should start with RTE_ prefix.

> capabilities is introduced to present the way for PMD to report to
> application about supporting Rx packet split to configurable
> segments. Prior invoking the rte_eth_rx_queue_setup_ex() routine
> application should check DEV_RX_OFFLOAD_BUFFER_SPLIT flag.
> 
> If the Rx queue is configured with new routine the packets being
> received will be split into multiple segments pushed to the mbufs
> with specified attributes. The PMD will allocate the first mbuf
> from the pool specified in the first segment descriptor and puts
> the data staring at specified offset in the allocated mbuf data
> buffer. If packet length exceeds the specified segment length
> the next mbuf will be allocated according to the next segment
> descriptor (if any) and data will be put in its data buffer at
> specified offset and not exceeding specified length. If there is
> no next descriptor the next mbuf will be allocated and filled in the
> same way (from the same pool and with the same buffer offset/length)
> as the current one.
> 
> For example, let's suppose we configured the Rx queue with the
> following segments:
> seg0 - pool0, len0=14B, off0=RTE_PKTMBUF_HEADROOM
> seg1 - pool1, len1=20B, off1=0B
> seg2 - pool2, len2=20B, off2=0B
> seg3 - pool3, len3=512B, off3=0B
> 
> The packet 46 bytes long will look like the following:
> seg0 - 14B long @ RTE_PKTMBUF_HEADROOM in mbuf from pool0
> seg1 - 20B long @ 0 in mbuf from pool1
> seg2 - 12B long @ 0 in mbuf from pool2
> 
> The packet 1500 bytes long will look like the following:
> seg0 - 14B @ RTE_PKTMBUF_HEADROOM in mbuf from pool0
> seg1 - 20B @ 0 in mbuf from pool1
> seg2 - 20B @ 0 in mbuf from pool2
> seg3 - 512B @ 0 in mbuf from pool3
> seg4 - 512B @ 0 in mbuf from pool3
> seg5 - 422B @ 0 in mbuf from pool3
> 
> The offload DEV_RX_OFFLOAD_SCATTER must be present and
> configured to support new buffer split feature (if n_seg
> is greater than one).
> 
> The new approach would allow splitting the ingress packets into
> multiple parts pushed to the memory with different attributes.
> For example, the packet headers can be pushed to the embedded
> data buffers within mbufs and the application data into
> the external buffers attached to mbufs allocated from the
> different memory pools. The memory attributes for the split
> parts may differ either - for example the application data
> may be pushed into the external memory located on the dedicated
> physical device, say GPU or NVMe. This would improve the DPDK
> receiving datapath flexibility with preserving compatibility
> with existing API.
> 
> Also, the proposed segment description might be used to specify
> Rx packet split for so

Re: [dpdk-dev] [PATCH v3 11/18] net/ixgbe: add checks for max SIMD bitwidth

[Ananyev, Konstantin]

> > From: Power, Ciara 
> > Sent: Wednesday, September 30, 2020 21:04
> > To: dev@dpdk.org
> > Cc: Power, Ciara ; Zhao1, Wei ; 
> > Guo, Jia
> > ; Wang, Haiyue 
> > Subject: [PATCH v3 11/18] net/ixgbe: add checks for max SIMD bitwidth
> >
> > When choosing a vector path to take, an extra condition must be
> > satisfied to ensure the max SIMD bitwidth allows for the CPU enabled
> > path.
> >
> > Cc: Wei Zhao 
> > Cc: Jeff Guo 
> >
> > Signed-off-by: Ciara Power 
> > ---
> >  drivers/net/ixgbe/ixgbe_rxtx.c | 7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
> > index 977ecf5137..eadc7183f2 100644
> > --- a/drivers/net/ixgbe/ixgbe_rxtx.c
> > +++ b/drivers/net/ixgbe/ixgbe_rxtx.c
> > @@ -2503,7 +2503,9 @@ ixgbe_set_tx_function(struct rte_eth_dev *dev, struct 
> > ixgbe_tx_queue *txq)
> > dev->tx_pkt_prepare = NULL;
> > if (txq->tx_rs_thresh <= RTE_IXGBE_TX_MAX_FREE_BUF_SZ &&
> > (rte_eal_process_type() != RTE_PROC_PRIMARY ||
> > -   ixgbe_txq_vec_setup(txq) == 0)) {
> > +   ixgbe_txq_vec_setup(txq) == 0) &&
> > +   rte_get_max_simd_bitwidth()
> 
> As Konstantin mentioned: " I think it is a bit safer to do all checks first 
> before
>  doing txq_vec_setup()."
> 
> Fox x86 & arm platforms, the setup is always 0, since 'sw_ring_v' is union 
> with
> 'sw_ring' which is initialize at 'ixgbe_dev_tx_queue_setup'.
> 
>   union {
>   struct ixgbe_tx_entry *sw_ring; /**< address of SW ring for 
> scalar PMD. */
>   struct ixgbe_tx_entry_v *sw_ring_v; /**< address of SW ring for 
> vector PMD */
>   };
> 
> static inline int
> ixgbe_txq_vec_setup_default(struct ixgbe_tx_queue *txq,
>   const struct ixgbe_txq_ops *txq_ops)
> {
>   if (txq->sw_ring_v == NULL)
>   return -1;
> 
>   /* leave the first one for overflow */
>   txq->sw_ring_v = txq->sw_ring_v + 1;
>   txq->ops = txq_ops;
> 
>   return 0;
> }
> 
> So we need check the SIMD bitwidth firstly to avoid changing the sw_ring* 
> pointer address.
> 
> 
> Also, looks like we need to add check on:
> 
> int
> ixgbe_dev_tx_done_cleanup(void *tx_queue, uint32_t free_cnt)
> {
>   struct ixgbe_tx_queue *txq = (struct ixgbe_tx_queue *)tx_queue;
>   if (txq->offloads == 0 &&
> #ifdef RTE_LIBRTE_SECURITY
>   !(txq->using_ipsec) &&
> #endif
>   txq->tx_rs_thresh >= RTE_PMD_IXGBE_TX_MAX_BURST) {
>   if (txq->tx_rs_thresh <= RTE_IXGBE_TX_MAX_FREE_BUF_SZ &&
>  <--- Add 
> the same check
>   (rte_eal_process_type() != RTE_PROC_PRIMARY ||
>   txq->sw_ring_v != NULL)) {
>   return ixgbe_tx_done_cleanup_vec(txq, free_cnt);

Could you probably explain a bit more why it is needed?

>   } else {
>   return ixgbe_tx_done_cleanup_simple(txq, free_cnt);
>   }
>   }
> 
> > +   >= RTE_MAX_128_SIMD) {
> > PMD_INIT_LOG(DEBUG, "Vector tx enabled.");
> > dev->tx_pkt_burst = ixgbe_xmit_pkts_vec;
> > } else
> > @@ -4743,7 +4745,8 @@ ixgbe_set_rx_function(struct rte_eth_dev *dev)
> >  * conditions to be met and Rx Bulk Allocation should be allowed.
> >  */
> > if (ixgbe_rx_vec_dev_conf_condition_check(dev) ||
> > -   !adapter->rx_bulk_alloc_allowed) {
> > +   !adapter->rx_bulk_alloc_allowed ||
> > +   rte_get_max_simd_bitwidth() < RTE_MAX_128_SIMD) {
> > PMD_INIT_LOG(DEBUG, "Port[%d] doesn't meet Vector Rx "
> > "preconditions",
> >  dev->data->port_id);
> > --
> > 2.17.1

Re: [dpdk-dev] [PATCH v3 18/18] lpm: choose vector path at runtime

[Ananyev, Konstantin]

Hi Ciara,

> Hi Konstantin,
> 
> 
> >-Original Message-
> >From: Ananyev, Konstantin 
> >Sent: Thursday 8 October 2020 15:40
> >To: Medvedkin, Vladimir ; Power, Ciara
> >; dev@dpdk.org
> >Cc: Richardson, Bruce ; Jerin Jacob
> >; Ruifeng Wang 
> >Subject: RE: [dpdk-dev] [PATCH v3 18/18] lpm: choose vector path at runtime
> >
> >>
> >> Hi Ciara,
> >>
> >>
> >> On 30/09/2020 14:04, Ciara Power wrote:
> >> > When choosing the vector path, max SIMD bitwidth is now checked to
> >> > ensure a vector path is allowable. To do this, rather than the
> >> > vector lookup functions being called directly from apps, a generic
> >> > lookup function is called which will call the vector functions if 
> >> > suitable.
> >> >
> >> > Signed-off-by: Ciara Power 
> >> > ---
> >> >   lib/librte_lpm/rte_lpm.h | 57 ++--
> >> >   lib/librte_lpm/rte_lpm_altivec.h |  2 +-
> >> >   lib/librte_lpm/rte_lpm_neon.h|  2 +-
> >> >   lib/librte_lpm/rte_lpm_sse.h |  2 +-
> >> >   4 files changed, 50 insertions(+), 13 deletions(-)
> >> >
> >> > diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
> >> > index 03da2d37e0..edba7cafd5 100644
> >> > --- a/lib/librte_lpm/rte_lpm.h
> >> > +++ b/lib/librte_lpm/rte_lpm.h
> >> > @@ -397,8 +397,18 @@ rte_lpm_lookup_bulk_func(const struct rte_lpm
> >*lpm, const uint32_t *ips,
> >> >   /* Mask four results. */
> >> >   #define RTE_LPM_MASKX4_RES UINT64_C(0x00ff00ff)
> >> >
> >> > +#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64) #include
> >> > +"rte_lpm_neon.h"
> >> > +#elif defined(RTE_ARCH_PPC_64)
> >> > +#include "rte_lpm_altivec.h"
> >> > +#else
> >> > +#include "rte_lpm_sse.h"
> >> > +#endif
> >> > +
> >> >   /**
> >> > - * Lookup four IP addresses in an LPM table.
> >> > + * Lookup four IP addresses in an LPM table individually by calling
> >> > + the
> >> > + * lookup function for each ip. This is used when lookupx4 is
> >> > + called but
> >> > + * the vector path is not suitable.
> >> >*
> >> >* @param lpm
> >> >*   LPM object handle
> >> > @@ -417,16 +427,43 @@ rte_lpm_lookup_bulk_func(const struct
> >rte_lpm *lpm, const uint32_t *ips,
> >> >*   if lookup would fail.
> >> >*/
> >> >   static inline void
> >> > -rte_lpm_lookupx4(const struct rte_lpm *lpm, xmm_t ip, uint32_t hop[4],
> >> > -uint32_t defv);
> >> > +rte_lpm_lookupx4_scalar(struct rte_lpm *lpm, xmm_t ip, uint32_t
> >hop[4],
> >> > +uint32_t defv)
> >> > +{
> >> > +int i;
> >> > +for (i = 0; i < 4; i++)
> >> > +if (rte_lpm_lookup(lpm, ((uint32_t *) &ip)[i], &hop[i]) 
> >> > < 0)
> >> > +hop[i] = defv; /* lookupx4 expected to set on 
> >> > failure
> >*/ }
> >> >
> >> > -#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64) -#include
> >> > "rte_lpm_neon.h"
> >> > -#elif defined(RTE_ARCH_PPC_64)
> >> > -#include "rte_lpm_altivec.h"
> >> > -#else
> >> > -#include "rte_lpm_sse.h"
> >> > -#endif
> >> > +/**
> >> > + * Lookup four IP addresses in an LPM table.
> >> > + *
> >> > + * @param lpm
> >> > + *   LPM object handle
> >> > + * @param ip
> >> > + *   Four IPs to be looked up in the LPM table
> >> > + * @param hop
> >> > + *   Next hop of the most specific rule found for IP (valid on lookup 
> >> > hit
> >only).
> >> > + *   This is an 4 elements array of two byte values.
> >> > + *   If the lookup was successful for the given IP, then least 
> >> > significant
> >byte
> >> > + *   of the corresponding element is the  actual next hop and the most
> >> > + *   significant byte is zero.
> >> > + *   If the lookup for the given IP failed, then corresponding element
> >would
> >> > + *   contain default value, see description of then next parameter.
> >> > + * @param defv
> >> > + *   Default value to populate into corresponding element of hop[] 
> >> > array,
> >> > + *   if lookup would fail.
> >> > + */
> >> > +static inline void
> >> > +rte_lpm_lookupx4(struct rte_lpm *lpm, xmm_t ip, uint32_t hop[4],
> >> > +uint32_t defv)
> >> > +{
> >> > +if (rte_get_max_simd_bitwidth() >= RTE_MAX_128_SIMD)
> >> > +rte_lpm_lookupx4_vec(lpm, ip, hop, defv);
> >> > +else
> >> > +rte_lpm_lookupx4_scalar(lpm, ip, hop, defv); }
> >>
> >> I'm afraid this will lead to a drop in performance. rte_lpm_lookupx4
> >> is used in the hot path, and a bulk size is too small to amortize the
> >> cost of adding this extra logic.
> >
> >I do share Vladimir's concern regarding performance here.
> >As I said in other mail - it seems not much point to insert these checks into
> >inline SSE specific function, as SSE is enabled by default for all x86 
> >builds.
> >
> 
> The performance impact is quite small, thanks Vladimir for providing these 
> results:
> 
> before patches:
>   LPM LookupX4: 25.1 cycles (fails = 12.5%)
>   LPM LookupX4: 25.2 cycles (fails = 12.5%)
>   LPM LookupX4: 25.2 cycles (fails = 12.5%)
> 
> v3:
>   

Re: [dpdk-dev] [v2 1/2] cryptodev: support enqueue callback functions

[Ananyev, Konstantin]

Hi Abhinandan,

> 
> Hi Konstantin,
> 
> 
> > -Original Message-
> > From: Ananyev, Konstantin 
> > Sent: Friday, October 9, 2020 8:10 PM
> > To: Gujjar, Abhinandan S ; Honnappa
> > Nagarahalli ; dev@dpdk.org; Doherty,
> > Declan 
> > Cc: jer...@marvell.com; akhil.go...@nxp.com; Vangati, Narender
> > ; nd ; nd 
> > Subject: RE: [dpdk-dev] [v2 1/2] cryptodev: support enqueue callback 
> > functions
> >
> > Hi Abhinandan,
> >
> > >
> > > Hi Konstantin & Honnappa,
> > >
> > > Thanks for all the inputs and feedback.
> > >
> > > @Ananyev, Konstantin,
> > > I have measured the perf with and without callback on xeon. Here are the
> > numbers:
> > >
> > > ./app/dpdk-test-crypto-perf -l 6-7
> > > --vdev="crypto_openssl0,socket_id=0,max_nb_sessions=128" -- --ptest
> > > throughput --devtype crypto_openssl --optype cipher-then-auth
> > > --cipher-algo aes-cbc --cipher-op encrypt --cipher-key-sz 16
> > > --auth-algo sha1-hmac --auth-op generate --auth-key-sz 64 --digest-sz
> > > 12 --total-ops 1000 --burst-sz 32 --buffer-sz 64
> > >
> > > With callback(+ RCU - totally opaque to data-plane threads)
> > > lcore idBuf Size  Burst SizeEnqueuedDequeued  Failed Enq  
> > > Failed
> > DeqMOpsGbps  Cycles/Buf
> > >7  64  3210001000  
> > >  0   0
> > 0.8129  0.4162 2694.09
> > >7  64  3210001000  
> > >  0   0
> > 0.8152  0.4174 2686.31
> > >7  64  3210001000  
> > >  0   0
> > 0.8198  0.4197 2671.48
> > >
> > > Without callback:
> > > lcore idBuf Size  Burst SizeEnqueuedDequeued  Failed Enq  
> > > Failed
> > DeqMOpsGbps  Cycles/Buf
> > >
> > >7  64  32   10001000   
> > > 0   0
> > 0.8234  0.4216 2659.81
> > >7  64  32   10001000   
> > > 0   0
> > 0.8247  0.4222 2655.63
> > >7  64  32   10001000   
> > > 0   0
> > 0.8123  0.4159 2695.90
> >
> >
> > Just to cofirm:
> > You implemented crypto enqueue callbacks using RCU QSBR online /offline (as
> > suggested below) and numbers above are for:
> > 1) callback code in place and some dummy callback installed
> That's right. (+ RCU calling online + offline APIs inside 
> rte_cryptodev_enqueue_burst())
> > 2) callback code in place but no callbacks installed
> No callback code. i.e. Original code.

Ok, and if I get things right - difference between mean values is ~15 cycles?
That's seems like very good result to me.
Can I suggest to run one more test for your new callback code in place,
but no actual callbacks installed?
Thanks
Konstantin

> >
> > Is my understanding correct here?
> > Thanks
> > Konstantin
> >
> >
> > >
> > > Regards
> > > Abhinandan
> > >
> > > > -Original Message-
> > > > From: Ananyev, Konstantin 
> > > > Sent: Tuesday, September 29, 2020 2:33 PM
> > > > To: Honnappa Nagarahalli ; Gujjar,
> > > > Abhinandan S ; dev@dpdk.org; Doherty,
> > > > Declan 
> > > > Cc: jer...@marvell.com; akhil.go...@nxp.com; Vangati, Narender
> > > > ; nd ; nd 
> > > > Subject: RE: [dpdk-dev] [v2 1/2] cryptodev: support enqueue callback
> > > > functions
> > > >
> > > >
> > > > >
> > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > +#ifdef RTE_CRYPTODEV_CALLBACKS int
> > > > > > > > > > > > > > > +rte_cryptodev_rcu_qsbr_add(uint8_t dev_id,
> > > > > > > > > > > > > > > +struct rte_rcu_qsbr
> > > > > > > > > > > > > > > +*qsbr) {
> > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > + struct rte_cryptodev *dev;
> > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > + if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
> > > > > > > > > > > > > > > + CDEV_LOG_ERR("Invalid dev_id=%"
> > PRIu8,
> > > > > > dev_id);
> > > > > > > > > > > > > > > + return -EINVAL;
> > > > > > > > > > > > > > > + }
> > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > + dev = &rte_crypto_devices[dev_id];
> > > > > > > > > > > > > > > + dev->qsbr = qsbr;
> > > > > > > > > > > > > > > + return 0;
> > > > > > > > > > > > > > > +}
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > So if I understand your patch correctly you
> > > > > > > > > > > > > > propose a new working model for
> > > > > > > > > > > > > > crypto-devs:
> > > > > > > > > > > > > > 1. Control-plane has to allocate/setup rcu_qsbr
> > > > > > > > > > > > > > and do rte_cryptodev_rcu_qsbr_add().
> > > > > > > > > > > > > > 2. Data-plane has somehow to obtain pointer to
> > > > > > > > > > > > > > that rcu_qsbr and wrap
> > > > > > > > > > > > > > cryptodev_enqueue()
> > > > > > > > > > > > > >with rcu_qsbr_quiescent()  or
> > > > > > > > r

Re: [dpdk-dev] [PATCH v3 11/18] net/ixgbe: add checks for max SIMD bitwidth

[Wang, Haiyue]

> -Original Message-
> From: Ananyev, Konstantin 
> Sent: Monday, October 12, 2020 06:31
> To: Wang, Haiyue ; Power, Ciara 
> ; dev@dpdk.org
> Cc: Zhao1, Wei ; Guo, Jia 
> Subject: RE: [PATCH v3 11/18] net/ixgbe: add checks for max SIMD bitwidth
> 
> 
> 
> > > From: Power, Ciara 
> > > Sent: Wednesday, September 30, 2020 21:04
> > > To: dev@dpdk.org
> > > Cc: Power, Ciara ; Zhao1, Wei 
> > > ; Guo, Jia
> > > ; Wang, Haiyue 
> > > Subject: [PATCH v3 11/18] net/ixgbe: add checks for max SIMD bitwidth
> > >
> > > When choosing a vector path to take, an extra condition must be
> > > satisfied to ensure the max SIMD bitwidth allows for the CPU enabled
> > > path.
> > >
> > > Cc: Wei Zhao 
> > > Cc: Jeff Guo 
> > >
> > > Signed-off-by: Ciara Power 
> > > ---
> > >  drivers/net/ixgbe/ixgbe_rxtx.c | 7 +--
> > >  1 file changed, 5 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c 
> > > b/drivers/net/ixgbe/ixgbe_rxtx.c
> > > index 977ecf5137..eadc7183f2 100644
> > > --- a/drivers/net/ixgbe/ixgbe_rxtx.c
> > > +++ b/drivers/net/ixgbe/ixgbe_rxtx.c
> > > @@ -2503,7 +2503,9 @@ ixgbe_set_tx_function(struct rte_eth_dev *dev, 
> > > struct ixgbe_tx_queue *txq)
> > >   dev->tx_pkt_prepare = NULL;
> > >   if (txq->tx_rs_thresh <= RTE_IXGBE_TX_MAX_FREE_BUF_SZ &&
> > >   (rte_eal_process_type() != RTE_PROC_PRIMARY ||
> > > - ixgbe_txq_vec_setup(txq) == 0)) {
> > > + ixgbe_txq_vec_setup(txq) == 0) &&
> > > + rte_get_max_simd_bitwidth()
> >
> > As Konstantin mentioned: " I think it is a bit safer to do all checks first 
> > before
> >  doing txq_vec_setup()."
> >
> > Fox x86 & arm platforms, the setup is always 0, since 'sw_ring_v' is union 
> > with
> > 'sw_ring' which is initialize at 'ixgbe_dev_tx_queue_setup'.
> >
> > union {
> > struct ixgbe_tx_entry *sw_ring; /**< address of SW ring for 
> > scalar PMD. */
> > struct ixgbe_tx_entry_v *sw_ring_v; /**< address of SW ring for 
> > vector PMD */
> > };
> >
> > static inline int
> > ixgbe_txq_vec_setup_default(struct ixgbe_tx_queue *txq,
> > const struct ixgbe_txq_ops *txq_ops)
> > {
> > if (txq->sw_ring_v == NULL)
> > return -1;
> >
> > /* leave the first one for overflow */
> > txq->sw_ring_v = txq->sw_ring_v + 1;
> > txq->ops = txq_ops;
> >
> > return 0;
> > }
> >
> > So we need check the SIMD bitwidth firstly to avoid changing the sw_ring* 
> > pointer address.
> >
> >
> > Also, looks like we need to add check on:
> >
> > int
> > ixgbe_dev_tx_done_cleanup(void *tx_queue, uint32_t free_cnt)
> > {
> > struct ixgbe_tx_queue *txq = (struct ixgbe_tx_queue *)tx_queue;
> > if (txq->offloads == 0 &&
> > #ifdef RTE_LIBRTE_SECURITY
> > !(txq->using_ipsec) &&
> > #endif
> > txq->tx_rs_thresh >= RTE_PMD_IXGBE_TX_MAX_BURST) {
> > if (txq->tx_rs_thresh <= RTE_IXGBE_TX_MAX_FREE_BUF_SZ &&
> >  <--- 
> > Add the same check
> > (rte_eal_process_type() != RTE_PROC_PRIMARY ||
> > txq->sw_ring_v != NULL)) {
> > return ixgbe_tx_done_cleanup_vec(txq, free_cnt);
> 
> Could you probably explain a bit more why it is needed?

To align with the vector selection path:

if (txq->tx_rs_thresh <= RTE_IXGBE_TX_MAX_FREE_BUF_SZ &&
(rte_eal_process_type() != RTE_PROC_PRIMARY ||
ixgbe_txq_vec_setup(txq) == 0))


> 
> > } else {
> > return ixgbe_tx_done_cleanup_simple(txq, free_cnt);
> > }


> > > 2.17.1

Re: [dpdk-dev] [PATCH v6 03/14] doc: remove references to make from NICs guides

[Hyong Youb Kim (hyonkim)]

> -Original Message-
> From: Ciara Power 
> Sent: Friday, October 9, 2020 7:21 PM
> To: dev@dpdk.org
[...]
> Subject: [PATCH v6 03/14] doc: remove references to make from NICs guides
> 
> Make is no longer supported for compiling DPDK, references are now
> removed in the documentation.
[...]
>  doc/guides/nics/enic.rst   |  9 -
[...]
> diff --git a/doc/guides/nics/enetc.rst b/doc/guides/nics/enetc.rst
> index 3c896eeffa..6203f4d799 100644
> --- a/doc/guides/nics/enetc.rst
> +++ b/doc/guides/nics/enetc.rst
> @@ -113,5 +113,3 @@ Driver compilation and testing
>  Follow instructions available in the document
>  :ref:`compiling and testing a PMD for a NIC `
>  to launch **testpmd**
> -
> -To compile in performance mode, please set
> ``CONFIG_RTE_CACHE_LINE_SIZE=64``
> diff --git a/doc/guides/nics/enic.rst b/doc/guides/nics/enic.rst
> index a28a7f4e47..be6a034279 100644
> --- a/doc/guides/nics/enic.rst
> +++ b/doc/guides/nics/enic.rst
> @@ -20,13 +20,6 @@ should be downloaded from
> https://core.dpdk.org/download/
>  Configuration information
>  -
> 
> -- **DPDK Configuration Parameters**
> -
> -  The following configuration options are available for the ENIC PMD:
> -
> -  - **CONFIG_RTE_LIBRTE_ENIC_PMD** (default y): Enables or disables
> inclusion
> -of the ENIC PMD driver in the DPDK compilation.
> -
>  - **vNIC Configuration Parameters**
> 
>- **Number of Queues**
> @@ -583,8 +576,6 @@ The value depends on the memory configuration of
> the application, DPDK and
>  PMD.  Typically, the limit has to be raised to higher than 2GB.
>  e.g., 2621440
> 
> -The compilation of any unused drivers can be disabled using the
> -configuration file in config/ directory (e.g., config/common_linux).
>  This would help in bringing down the time taken for building the
>  libraries and the initialization time of the application.
> 

Hi,

Could you remove the remaining two lines as well ("This would ... 
application.")?

For enic,
Acked-by: Hyong Youb Kim 

Thanks.
-Hyong

[dpdk-dev] [PATCH v2] ethdev: check if queue setupped in queue-related APIs

[Wei Hu (Xavier)]

From: Chengchang Tang 

This patch adds checking whether the related Tx or Rx queue has been
setupped in the queue-related API functions to avoid illegal address
access. And validity check of the queue_id is also added in the API
functions rte_eth_dev_rx_intr_enable and rte_eth_dev_rx_intr_disable.

Signed-off-by: Chengchang Tang 
Signed-off-by: Wei Hu (Xavier) 
Signed-off-by: Chengwen Feng 
---
v1 -> v2:
 1. replace %"PRIu16" with %u.
 2. extact two common functions which validate RXQ/TXQ ids and
whether it has been set up or not.
---
 lib/librte_ethdev/rte_ethdev.c | 92 ++
 lib/librte_ethdev/rte_ethdev.h |  3 +-
 2 files changed, 78 insertions(+), 17 deletions(-)

diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 892c246..cb55863 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -877,10 +877,59 @@ rte_eth_dev_rx_queue_config(struct rte_eth_dev *dev, 
uint16_t nb_queues)
return 0;
 }
 
+static inline int
+rte_eth_dev_validate_rx_queue(uint16_t port_id, uint16_t rx_queue_id)
+{
+   struct rte_eth_dev *dev;
+
+   RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);
+
+   dev = &rte_eth_devices[port_id];
+
+   if (rx_queue_id >= dev->data->nb_rx_queues) {
+   RTE_ETHDEV_LOG(ERR, "Invalid RX queue_id=%u\n", rx_queue_id);
+   return -EINVAL;
+   }
+
+   if (dev->data->rx_queues[rx_queue_id] == NULL) {
+   RTE_ETHDEV_LOG(ERR,
+  "Queue %u of device with port_id=%u has not been"
+  " setup\n", rx_queue_id, port_id);
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static inline int
+rte_eth_dev_validate_tx_queue(uint16_t port_id, uint16_t tx_queue_id)
+{
+   struct rte_eth_dev *dev;
+
+   RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);
+
+   dev = &rte_eth_devices[port_id];
+
+   if (tx_queue_id >= dev->data->nb_tx_queues) {
+   RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u\n", tx_queue_id);
+   return -EINVAL;
+   }
+
+   if (dev->data->tx_queues[tx_queue_id] == NULL) {
+   RTE_ETHDEV_LOG(ERR,
+  "Queue %u of device with port_id=%u has not been"
+  " setup\n", tx_queue_id, port_id);
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 int
 rte_eth_dev_rx_queue_start(uint16_t port_id, uint16_t rx_queue_id)
 {
struct rte_eth_dev *dev;
+   int ret;
 
RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);
 
@@ -892,10 +941,9 @@ rte_eth_dev_rx_queue_start(uint16_t port_id, uint16_t 
rx_queue_id)
return -EINVAL;
}
 
-   if (rx_queue_id >= dev->data->nb_rx_queues) {
-   RTE_ETHDEV_LOG(ERR, "Invalid RX queue_id=%u\n", rx_queue_id);
-   return -EINVAL;
-   }
+   ret = rte_eth_dev_validate_rx_queue(port_id, rx_queue_id);
+   if (ret)
+   return ret;
 
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->rx_queue_start, -ENOTSUP);
 
@@ -922,14 +970,15 @@ int
 rte_eth_dev_rx_queue_stop(uint16_t port_id, uint16_t rx_queue_id)
 {
struct rte_eth_dev *dev;
+   int ret;
 
RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);
 
dev = &rte_eth_devices[port_id];
-   if (rx_queue_id >= dev->data->nb_rx_queues) {
-   RTE_ETHDEV_LOG(ERR, "Invalid RX queue_id=%u\n", rx_queue_id);
-   return -EINVAL;
-   }
+
+   ret = rte_eth_dev_validate_rx_queue(port_id, rx_queue_id);
+   if (ret)
+   return ret;
 
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->rx_queue_stop, -ENOTSUP);
 
@@ -955,6 +1004,7 @@ int
 rte_eth_dev_tx_queue_start(uint16_t port_id, uint16_t tx_queue_id)
 {
struct rte_eth_dev *dev;
+   int ret;
 
RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);
 
@@ -966,10 +1016,9 @@ rte_eth_dev_tx_queue_start(uint16_t port_id, uint16_t 
tx_queue_id)
return -EINVAL;
}
 
-   if (tx_queue_id >= dev->data->nb_tx_queues) {
-   RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u\n", tx_queue_id);
-   return -EINVAL;
-   }
+   ret = rte_eth_dev_validate_tx_queue(port_id, tx_queue_id);
+   if (ret)
+   return ret;
 
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->tx_queue_start, -ENOTSUP);
 
@@ -994,14 +1043,15 @@ int
 rte_eth_dev_tx_queue_stop(uint16_t port_id, uint16_t tx_queue_id)
 {
struct rte_eth_dev *dev;
+   int ret;
 
RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);
 
dev = &rte_eth_devices[port_id];
-   if (tx_queue_id >= dev->data->nb_tx_queues) {
-   RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u\n", tx_queue_id);
-   return -EINVAL;
-   }
+
+   ret = rte_eth_dev_validate_tx_queue(port_id, tx_queue_id);
+   if (ret)
+  

Re: [dpdk-dev] [PATCH] ethdev: check if queue setupped in queue-related APIs

[Wei Hu (Xavier)]

Hi, Stephen Hemminger

On 2020/10/10 23:24, Stephen Hemminger wrote:

On Sat, 10 Oct 2020 15:12:12 +0800
"Wei Hu (Xavier)"  wrote:


+   if (dev->data->rx_queues[rx_queue_id] == NULL) {
+   RTE_ETHDEV_LOG(ERR, "Rx queue %"PRIu16" of device with 
port_id=%"
+   PRIu16" has not been setupped\n",
+   rx_queue_id, port_id);
+   return -EINVAL;
+

Please use correct spelling.

Your change follows the existing style in rte_eth_dev_rx_queue_start() but
my preference is that message strings are not split across
lines. That makes it easier to use tools like grep to find messages in the 
source.

Use of PRIu16 is not required. And recent compiler standards would require space
around its use.

Suggest:
RTE_ETHDEV_LOG(ERR,
   "Queue %u of device with port_id=%u has not been 
setup\n",
rx_queue_id, port_id);


I fixed it in V2.

Thanks, xavier

Re: [dpdk-dev] [PATCH] ethdev: check if queue setupped in queue-related APIs

[Wei Hu (Xavier)]

Hi, Kalesh Anakkur Purayil

On 2020/10/11 0:38, Kalesh Anakkur Purayil wrote:



On Sat, Oct 10, 2020 at 12:42 PM Wei Hu (Xavier) 
mailto:huwei...@chinasoftinc.com>> wrote:


From: Chengchang Tang mailto:tangchengch...@huawei.com>>

This patch adds checking whether the related Tx or Rx queue has been
setupped in the queue-related API functions to avoid illegal address
access. And validity check of the queue_id is also added in the API
functions rte_eth_dev_rx_intr_enable and rte_eth_dev_rx_intr_disable.

Signed-off-by: Chengchang Tang mailto:tangchengch...@huawei.com>>
Signed-off-by: Wei Hu (Xavier) mailto:xavier.hu...@huawei.com>>
Signed-off-by: Chengwen Feng mailto:fengcheng...@huawei.com>>
---
 lib/librte_ethdev/rte_ethdev.c | 56
++
 lib/librte_ethdev/rte_ethdev.h |  3 ++-
 2 files changed, 58 insertions(+), 1 deletion(-)

diff --git a/lib/librte_ethdev/rte_ethdev.c
b/lib/librte_ethdev/rte_ethdev.c
index 892c246..31a8eb3 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -897,6 +897,13 @@ rte_eth_dev_rx_queue_start(uint16_t port_id,
uint16_t rx_queue_id)
                return -EINVAL;
        }

+       if (dev->data->rx_queues[rx_queue_id] == NULL) {
+               RTE_ETHDEV_LOG(ERR, "Rx queue %"PRIu16" of device
with port_id=%"
+                                   PRIu16" has not been setupped\n",
+                                   rx_queue_id, port_id);
+               return -EINVAL;
+       }
+


Hi Xavier,

How about having two common functions which validate RXQ/TXQ ids and 
whether it has been set up or not like below. This helps avoiding lot 
of duplicate code:


static inline int
rte_eth_dev_validate_rx_queue(uint16_t port_id, uint16_t rx_queue_id)
{
        struct rte_eth_dev *dev;

        RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);

        dev = &rte_eth_devices[port_id];

        if (rx_queue_id >= dev->data->nb_rx_queues) {
                RTE_ETHDEV_LOG(ERR, "Invalid RX queue_id=%u\n", 
rx_queue_id);

                return -EINVAL;
        }

       if (dev->data->rx_queues[rx_queue_id] == NULL) {
               RTE_ETHDEV_LOG(ERR,
                              "Queue %u of device with port_id=%u has 
not been setup\n",

                              rx_queue_id, port_id);
               return -EINVAL;
       }

       return 0;
}


I fixed it in V2.

Thanks, xavier


Regards,
Kalesh

-- 
2.9.5




--
Regards,
Kalesh A P

Re: [dpdk-dev] [PATCH v6 1/2] eal/arm64: update CPU flags

[Wei Hu (Xavier)]

Hi, Thomas Monjalon

For this series, ARM engineer has already given them backed by. If you 
have no other opinion, can we merge them? so we can continue to promote 
other patch sets accelerated by using SVE instructions.

Hope for your reply, thanks.

  Regards
Xavier

On 2020/8/19 18:56, Wei Hu (Xavier) wrote:

From: "Wei Hu (Xavier)" 

ARM64 Linux kernel updated the CPU flags using the HWCAP scheme.
The related marco definition can be found in linux kernel:
   arch/arm64/include/uapi/asm/hwcap.h

This patch incorporates those changes to the eal library.

Signed-off-by: Chengwen Feng 
Signed-off-by: Wei Hu (Xavier) 
Reviewed-by: Ruifeng Wang 
---
v4 -> v5:
No change.
v3 -> v4:
Update commit log.
v2 -> v3:
1. Change commit log.
2. Add HWCAP2_FLAGM2 and HWCAP2_FRINT to rte_cpu_feature_table[].
3. Add the flags for newly added items into enum rte_cpu_flag_t.
v1 -> v2:
Adds more sve-related definition to rte_cpu_feature_table,
sunch as SVE2, etc.
---
  lib/librte_eal/arm/include/rte_cpuflags_64.h | 13 +
  lib/librte_eal/arm/rte_cpuflags.c| 13 +
  2 files changed, 26 insertions(+)

diff --git a/lib/librte_eal/arm/include/rte_cpuflags_64.h 
b/lib/librte_eal/arm/include/rte_cpuflags_64.h
index 95cc01474..aa7a56d49 100644
--- a/lib/librte_eal/arm/include/rte_cpuflags_64.h
+++ b/lib/librte_eal/arm/include/rte_cpuflags_64.h
@@ -22,6 +22,19 @@ enum rte_cpu_flag_t {
RTE_CPUFLAG_SHA2,
RTE_CPUFLAG_CRC32,
RTE_CPUFLAG_ATOMICS,
+   RTE_CPUFLAG_SVE,
+   RTE_CPUFLAG_SVE2,
+   RTE_CPUFLAG_SVEAES,
+   RTE_CPUFLAG_SVEPMULL,
+   RTE_CPUFLAG_SVEBITPERM,
+   RTE_CPUFLAG_SVESHA3,
+   RTE_CPUFLAG_SVESM4,
+   RTE_CPUFLAG_FLAGM2,
+   RTE_CPUFLAG_FRINT,
+   RTE_CPUFLAG_SVEI8MM,
+   RTE_CPUFLAG_SVEF32MM,
+   RTE_CPUFLAG_SVEF64MM,
+   RTE_CPUFLAG_SVEBF16,
RTE_CPUFLAG_AARCH64,
/* The last item */
RTE_CPUFLAG_NUMFLAGS,/**< This should always be the last! */
diff --git a/lib/librte_eal/arm/rte_cpuflags.c 
b/lib/librte_eal/arm/rte_cpuflags.c
index caf3dc83a..7b257b787 100644
--- a/lib/librte_eal/arm/rte_cpuflags.c
+++ b/lib/librte_eal/arm/rte_cpuflags.c
@@ -95,6 +95,19 @@ const struct feature_entry rte_cpu_feature_table[] = {
FEAT_DEF(SHA2,  REG_HWCAP,6)
FEAT_DEF(CRC32, REG_HWCAP,7)
FEAT_DEF(ATOMICS,   REG_HWCAP,8)
+   FEAT_DEF(SVE,   REG_HWCAP,22)
+   FEAT_DEF(SVE2,  REG_HWCAP2,   1)
+   FEAT_DEF(SVEAES,REG_HWCAP2,   2)
+   FEAT_DEF(SVEPMULL,  REG_HWCAP2,   3)
+   FEAT_DEF(SVEBITPERM,REG_HWCAP2,   4)
+   FEAT_DEF(SVESHA3,   REG_HWCAP2,   5)
+   FEAT_DEF(SVESM4,REG_HWCAP2,   6)
+   FEAT_DEF(FLAGM2,REG_HWCAP2,   7)
+   FEAT_DEF(FRINT, REG_HWCAP2,   8)
+   FEAT_DEF(SVEI8MM,   REG_HWCAP2,   9)
+   FEAT_DEF(SVEF32MM,  REG_HWCAP2,   10)
+   FEAT_DEF(SVEF64MM,  REG_HWCAP2,   11)
+   FEAT_DEF(SVEBF16,   REG_HWCAP2,   12)
FEAT_DEF(AARCH64,   REG_PLATFORM, 1)
  };
  #endif /* RTE_ARCH */

Re: [dpdk-dev] [PATCH v6 03/14] doc: remove references to make from NICs guides

[Ajit Khaparde]

On Fri, Oct 9, 2020 at 5:16 AM Ferruh Yigit  wrote:
>
> On 10/9/2020 11:21 AM, Ciara Power wrote:
> > Make is no longer supported for compiling DPDK, references are now
> > removed in the documentation.
> >
> > Signed-off-by: Ciara Power 
> > Reviewed-by: Bruce Richardson 
> >
> > ---
> > v6: Fixed indentation of testbbdev list entry.
>
> for kni, pcap & null,
> Reviewed-by: Ferruh Yigit 
For bnxt
Acked-by: Ajit Khaparde 

>
>

[dpdk-dev] [PATCH v4 0/4] add async data path in vhost sample

[Cheng Jiang]

This patch set makes vhost-vswitch be able to use vhost async APIs
for enqueue operations. Demonstrated how the application
leverage IOAT DMA channel with vhost async APIs.

We introduce two parameters to enable DMA acceleration for Tx
operations of queues:
-dma_type This parameter is used to specify DMA type for async
vhost-user net driver.
-dmas This parameter is used to specify the assigned DMA device of a
vhost device and enable async vhost data path.

---
v4:
 * Code rebased for latest IOAT driver

v3:
 * Fixed a coding style problem

v2:
 * Changed meson build file to fix dependency problem
 * Added parameter description in usage function
 * Optimized parameter settings and parsing function
 * Optimized abstraction, moved some code to ioat.c

Cheng Jiang (4):
  example/vhost: add async vhost args parsing function
  example/vhost: add support for vhost async data path
  doc: update vhost sample doc for vhost async data path
  doc: update release notes for vhost sample

 doc/guides/rel_notes/release_20_11.rst |   6 +
 doc/guides/sample_app_ug/vhost.rst |  11 ++
 examples/vhost/ioat.c  | 209 +
 examples/vhost/main.c  |  98 +++-
 examples/vhost/main.h  |  14 ++
 examples/vhost/meson.build |   4 +-
 6 files changed, 338 insertions(+), 4 deletions(-)
 create mode 100644 examples/vhost/ioat.c

--
2.27.0

[dpdk-dev] [PATCH v4 1/4] example/vhost: add async vhost args parsing function

[Cheng Jiang]

This patch is to add async vhost driver arguments parsing function
for CBDMA channel, DMA initiation function and args description.
The meson build file is changed to fix dependency problem. With
these arguments vhost device can be set to use CBDMA or CPU for
enqueue operation and bind vhost device with specific CBDMA channel
to accelerate data copy.

Signed-off-by: Cheng Jiang 
---
 examples/vhost/ioat.c  | 117 +
 examples/vhost/main.c  |  37 +++-
 examples/vhost/main.h  |   2 +
 examples/vhost/meson.build |   4 +-
 4 files changed, 157 insertions(+), 3 deletions(-)
 create mode 100644 examples/vhost/ioat.c

diff --git a/examples/vhost/ioat.c b/examples/vhost/ioat.c
new file mode 100644
index 0..c3158d3c3
--- /dev/null
+++ b/examples/vhost/ioat.c
@@ -0,0 +1,117 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2010-2017 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "main.h"
+
+#define MAX_VHOST_DEVICE 1024
+#define IOAT_RING_SIZE 4096
+
+struct dma_info {
+   struct rte_pci_addr addr;
+   uint16_t dev_id;
+   bool is_valid;
+};
+
+struct dma_for_vhost {
+   struct dma_info dmas[RTE_MAX_QUEUES_PER_PORT * 2];
+   uint16_t nr;
+};
+
+struct dma_for_vhost dma_bind[MAX_VHOST_DEVICE];
+
+int
+open_ioat(const char *value)
+{
+   struct dma_for_vhost *dma_info = dma_bind;
+   char *input = strndup(value, strlen(value) + 1);
+   char *addrs = input;
+   char *ptrs[2];
+   char *start, *end, *substr;
+   int64_t vid, vring_id;
+   struct rte_ioat_rawdev_config config;
+   struct rte_rawdev_info info = { .dev_private = &config };
+   char name[32];
+   int dev_id;
+   int ret = 0;
+   uint16_t i = 0;
+   char *dma_arg[MAX_VHOST_DEVICE];
+   uint8_t args_nr;
+
+   while (isblank(*addrs))
+   addrs++;
+   if (*addrs == '\0') {
+   ret = -1;
+   goto out;
+   }
+
+   /* process DMA devices within bracket. */
+   addrs++;
+   substr = strtok(addrs, ";]");
+   if (!substr) {
+   ret = -1;
+   goto out;
+   }
+   args_nr = rte_strsplit(substr, strlen(substr),
+   dma_arg, MAX_VHOST_DEVICE, ',');
+   do {
+   char *arg_temp = dma_arg[i];
+   rte_strsplit(arg_temp, strlen(arg_temp), ptrs, 2, '@');
+
+   start = strstr(ptrs[0], "txd");
+   if (start == NULL) {
+   ret = -1;
+   goto out;
+   }
+
+   start += 3;
+   vid = strtol(start, &end, 0);
+   if (end == start) {
+   ret = -1;
+   goto out;
+   }
+
+   vring_id = 0 + VIRTIO_RXQ;
+   if (rte_pci_addr_parse(ptrs[1],
+   &(dma_info + vid)->dmas[vring_id].addr) < 0) {
+   ret = -1;
+   goto out;
+   }
+
+   rte_pci_device_name(&(dma_info + vid)->dmas[vring_id].addr,
+   name, sizeof(name));
+   dev_id = rte_rawdev_get_dev_id(name);
+   if (dev_id == (uint16_t)(-ENODEV) ||
+   dev_id == (uint16_t)(-EINVAL)) {
+   ret = -1;
+   goto out;
+   }
+
+   if (rte_rawdev_info_get(dev_id, &info, sizeof(config)) < 0 ||
+   strstr(info.driver_name, "ioat") == NULL) {
+   ret = -1;
+   goto out;
+   }
+
+   (dma_info + vid)->dmas[vring_id].dev_id = dev_id;
+   (dma_info + vid)->dmas[vring_id].is_valid = true;
+   config.ring_size = IOAT_RING_SIZE;
+   config.hdls_disable = true;
+   if (rte_rawdev_configure(dev_id, &info, sizeof(config)) < 0) {
+   ret = -1;
+   goto out;
+   }
+   rte_rawdev_start(dev_id);
+
+   dma_info->nr++;
+   i++;
+   } while (i < args_nr);
+out:
+   free(input);
+   return ret;
+}
diff --git a/examples/vhost/main.c b/examples/vhost/main.c
index 959c0c283..4806419d6 100644
--- a/examples/vhost/main.c
+++ b/examples/vhost/main.c
@@ -95,6 +95,10 @@ static int client_mode;
 
 static int builtin_net_driver;
 
+static int async_vhost_driver;
+
+static char dma_type[MAX_LONG_OPT_SZ];
+
 /* Specify timeout (in useconds) between retries on RX. */
 static uint32_t burst_rx_delay_time = BURST_RX_WAIT_US;
 /* Specify the number of retries on RX. */
@@ -181,6 +185,15 @@ struct mbuf_table lcore_tx_queue[RTE_MAX_LCORE];
 / US_PER_S * BURST_TX_DRAIN_US)
 #define VLAN_HLEN   4
 
+static inline int
+open_dma(const char *value)
+{
+   if (strncmp(dma_type, "IOAT", 4) == 0)
+   return o

[dpdk-dev] [PATCH v4 4/4] doc: update release notes for vhost sample

[Cheng Jiang]

Add release notes for vhost async data path support in vhost sample.

Signed-off-by: Cheng Jiang 
---
 doc/guides/rel_notes/release_20_11.rst | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/doc/guides/rel_notes/release_20_11.rst 
b/doc/guides/rel_notes/release_20_11.rst
index 26cc0949a..aa69d6dca 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -148,6 +148,12 @@ New Features
   * Extern objects and functions can be plugged into the pipeline.
   * Transaction-oriented table updates.
 
+* **Updated vhost sample application.**
+
+  Added vhost asynchronous APIs support, which demonstrated how the application
+  leverage IOAT DMA channel with vhost asynchronous APIs.
+  See the :doc:`../sample_app_ug/vhost` for more details.
+
 
 Removed Items
 -
-- 
2.27.0

[dpdk-dev] [PATCH v4 3/4] doc: update vhost sample doc for vhost async data path

[Cheng Jiang]

Add vhost async driver arguments information for vhost async data
path in vhost sample application.

Signed-off-by: Cheng Jiang 
---
 doc/guides/sample_app_ug/vhost.rst | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/doc/guides/sample_app_ug/vhost.rst 
b/doc/guides/sample_app_ug/vhost.rst
index b7ed4f8bd..0f4f70945 100644
--- a/doc/guides/sample_app_ug/vhost.rst
+++ b/doc/guides/sample_app_ug/vhost.rst
@@ -162,6 +162,17 @@ enabled and cannot be disabled.
 A very simple vhost-user net driver which demonstrates how to use the generic
 vhost APIs will be used when this option is given. It is disabled by default.
 
+**--dma-type**
+This parameter is used to specify DMA type for async vhost-user net driver 
which
+demonstrates how to use the async vhost APIs. It's used in combination with 
dmas.
+
+**--dmas**
+This parameter is used to specify the assigned DMA device of a vhost device.
+Async vhost-user net driver will be used if --dmas is set. For example
+--dmas [txd0@00:04.0,txd1@00:04.1] means use DMA channel 00:04.0 for vhost
+device 0 enqueue operation and use DMA channel 00:04.1 for vhost device 1
+enqueue operation.
+
 Common Issues
 -
 
-- 
2.27.0

[dpdk-dev] [PATCH v4 2/4] example/vhost: add support for vhost async data path

[Cheng Jiang]

This patch is to implement vhost DMA operation callbacks for CBDMA
PMD and add vhost async data-path in vhost sample. With providing
callback implementation for CBDMA, vswitch can leverage IOAT to
accelerate vhost async data-path.

Signed-off-by: Cheng Jiang 
---
 examples/vhost/ioat.c | 92 +++
 examples/vhost/main.c | 61 +++-
 examples/vhost/main.h | 12 ++
 3 files changed, 164 insertions(+), 1 deletion(-)

diff --git a/examples/vhost/ioat.c b/examples/vhost/ioat.c
index c3158d3c3..d7b7c59c1 100644
--- a/examples/vhost/ioat.c
+++ b/examples/vhost/ioat.c
@@ -6,11 +6,13 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "main.h"
 
 #define MAX_VHOST_DEVICE 1024
 #define IOAT_RING_SIZE 4096
+#define MAX_ENQUEUED_SIZE 256
 
 struct dma_info {
struct rte_pci_addr addr;
@@ -25,6 +27,15 @@ struct dma_for_vhost {
 
 struct dma_for_vhost dma_bind[MAX_VHOST_DEVICE];
 
+struct packet_tracker {
+   unsigned short size_track[MAX_ENQUEUED_SIZE];
+   unsigned short next_read;
+   unsigned short next_write;
+   unsigned short last_remain;
+};
+
+struct packet_tracker cb_tracker[MAX_VHOST_DEVICE];
+
 int
 open_ioat(const char *value)
 {
@@ -115,3 +126,84 @@ open_ioat(const char *value)
free(input);
return ret;
 }
+
+uint32_t
+ioat_transfer_data_cb(int vid, uint16_t queue_id,
+   struct rte_vhost_async_desc *descs,
+   struct rte_vhost_async_status *opaque_data, uint16_t count)
+{
+   int ret;
+   uint32_t i_desc;
+   int dev_id = dma_bind[vid].dmas[queue_id * 2 + VIRTIO_RXQ].dev_id;
+   struct rte_vhost_iov_iter *src = NULL;
+   struct rte_vhost_iov_iter *dst = NULL;
+   unsigned long i_seg;
+   unsigned short mask = MAX_ENQUEUED_SIZE - 1;
+   unsigned short write = cb_tracker[dev_id].next_write;
+
+   if (likely(!opaque_data)) {
+   for (i_desc = 0; i_desc < count; i_desc++) {
+   src = descs[i_desc].src;
+   dst = descs[i_desc].dst;
+   i_seg = 0;
+   while (i_seg < src->nr_segs) {
+   ret = rte_ioat_enqueue_copy(dev_id,
+   (uintptr_t)(src->iov[i_seg].iov_base)
+   + src->offset,
+   (uintptr_t)(dst->iov[i_seg].iov_base)
+   + dst->offset,
+   src->iov[i_seg].iov_len,
+   0,
+   0);
+   if (ret != 1)
+   break;
+   i_seg++;
+   }
+   write &= mask;
+   cb_tracker[dev_id].size_track[write] = i_seg;
+   write++;
+   }
+   } else {
+   /* Opaque data is not supported */
+   return -1;
+   }
+   /* ring the doorbell */
+   rte_ioat_perform_ops(dev_id);
+   cb_tracker[dev_id].next_write = write;
+   return i_desc;
+}
+
+uint32_t
+ioat_check_completed_copies_cb(int vid, uint16_t queue_id,
+   struct rte_vhost_async_status *opaque_data,
+   uint16_t max_packets)
+{
+   if (!opaque_data) {
+   uintptr_t dump[255];
+   unsigned short n_seg;
+   unsigned short read;
+   unsigned short nb_packet = 0;
+   unsigned short mask = MAX_ENQUEUED_SIZE - 1;
+   unsigned short i;
+   int dev_id = dma_bind[vid].dmas[queue_id * 2
+   + VIRTIO_RXQ].dev_id;
+   n_seg = rte_ioat_completed_ops(dev_id, 255, dump, dump);
+   n_seg = n_seg + cb_tracker[dev_id].last_remain;
+   read = cb_tracker[dev_id].next_read;
+   for (i = 0; i < max_packets; i++) {
+   read &= mask;
+   if (n_seg >= cb_tracker[dev_id].size_track[read]) {
+   n_seg -= cb_tracker[dev_id].size_track[read];
+   read++;
+   nb_packet++;
+   } else {
+   break;
+   }
+   }
+   cb_tracker[dev_id].next_read = read;
+   cb_tracker[dev_id].last_remain = n_seg;
+   return nb_packet;
+   }
+   /* Opaque data is not supported */
+   return -1;
+}
diff --git a/examples/vhost/main.c b/examples/vhost/main.c
index 4806419d6..f37d1f691 100644
--- a/examples/vhost/main.c
+++ b/examples/vhost/main.c
@@ -804,9 +804,26 @@ virtio_xmit(struct vhost_dev *dst_vdev, struct vhost_dev 
*src_vdev,
struct rte_mbuf *m)
 {
uint16_t ret;
+   struct rte_mbuf *m_cpl[1];
 
 

Re: [dpdk-dev] [PATCH v2 3/5] cryptodev: remove crypto list end enumerators

[Kusztal, ArkadiuszX]

Hi Akhil,

> -Original Message-
> From: Akhil Goyal 
> Sent: czwartek, 8 października 2020 21:58
> To: Kusztal, ArkadiuszX ; dev@dpdk.org
> Cc: Trahe, Fiona ; ruifeng.w...@arm.com;
> michae...@marvell.com
> Subject: RE: [PATCH v2 3/5] cryptodev: remove crypto list end enumerators
> 
> > diff --git a/lib/librte_cryptodev/rte_crypto_sym.h
> > b/lib/librte_cryptodev/rte_crypto_sym.h
> > index f29c98051..7a2556a9e 100644
> > --- a/lib/librte_cryptodev/rte_crypto_sym.h
> > +++ b/lib/librte_cryptodev/rte_crypto_sym.h
> > @@ -132,15 +132,12 @@ enum rte_crypto_cipher_algorithm {
> >  * for m_src and m_dst in the rte_crypto_sym_op must be NULL.
> >  */
> >
> > -   RTE_CRYPTO_CIPHER_DES_DOCSISBPI,
> > +   RTE_CRYPTO_CIPHER_DES_DOCSISBPI
> > /**< DES algorithm using modes required by
> >  * DOCSIS Baseline Privacy Plus Spec.
> >  * Chained mbufs are not supported in this mode, i.e. rte_mbuf.next
> >  * for m_src and m_dst in the rte_crypto_sym_op must be NULL.
> >  */
> > -
> > -   RTE_CRYPTO_CIPHER_LIST_END
> > -
> >  };
> 
> Probably we should add a comment for each of the enums that we change, that
> the user can define its own LIST_END = last item in the enum +1.
> LIST_END is not added to avoid ABI breakage across releases when new algos
> are added.
[Arek] - I do not now if necessary, should it be some kind of guarantee that 
order and number of enumerators will not change across the releases?
> 
> >
> >  /** Cipher algorithm name strings */
> > @@ -312,10 +309,8 @@ enum rte_crypto_auth_algorithm {
> > /**< HMAC using 384 bit SHA3 algorithm. */
> > RTE_CRYPTO_AUTH_SHA3_512,
> > /**< 512 bit SHA3 algorithm. */
> > -   RTE_CRYPTO_AUTH_SHA3_512_HMAC,
> > +   RTE_CRYPTO_AUTH_SHA3_512_HMAC
> > /**< HMAC using 512 bit SHA3 algorithm. */
> > -
> > -   RTE_CRYPTO_AUTH_LIST_END
> >  };
> >
> >  /** Authentication algorithm name strings */ @@ -412,9 +407,8 @@ enum
> > rte_crypto_aead_algorithm {
> > /**< AES algorithm in CCM mode. */
> > RTE_CRYPTO_AEAD_AES_GCM,
> > /**< AES algorithm in GCM mode. */
> > -   RTE_CRYPTO_AEAD_CHACHA20_POLY1305,
> > +   RTE_CRYPTO_AEAD_CHACHA20_POLY1305
> > /**< Chacha20 cipher with poly1305 authenticator */
> > -   RTE_CRYPTO_AEAD_LIST_END
> >  };
> >
> >  /** AEAD algorithm name strings */
> > --
> > 2.17.1

Re: [dpdk-dev] [PATCH v9 0/8] Enable dynamic config of subport bandwidth

[Dharmappa, Savinay]

09/10/2020 14:39, Savinay Dharmappa:
> DPDK sched library allows runtime configuration of the pipe profiles 
> to the pipes of the subport once scheduler hierarchy is constructed. 
> However, to change the subport level bandwidth, existing hierarchy 
> needs to be dismantled and whole process of building hierarchy under 
> subport nodes needs to be repeated which might result in router 
> downtime. Furthermore, due to lack of dynamic configuration of the 
> subport bandwidth profile configuration (shaper and Traffic class 
> rates), the user application is unable to dynamically re-distribute 
> the excess-bandwidth of one subport among other subports in the 
> scheduler hierarchy. Therefore, it is also not possible to adjust the 
> subport bandwidth profile in sync with dynamic changes in pipe 
> profiles of subscribers who want to consume higher bandwidth 
> opportunistically.
> 
> This patch series implements dynamic configuration of the subport 
> bandwidth profile to overcome the runtime situation when group of 
> subscribers are not using the allotted bandwidth and dynamic bandwidth 
> re-distribution is needed the without making any structural changes in the 
> hierarchy.
> 
> The implementation work includes refactoring the existing api and data 
> structures defined for port and subport level, new APIs for adding 
> subport level bandwidth profiles that can be used in runtime.
> 
> ---
> v8 -> v9
>- updated ABI section in release notes.
>- Addressed review comments from patch 8
>  of v8.

I was asking a question in my reply to v8 but you didn't hit the "reply" button.
>> sorry for that. All the question raised by you were relevant so I addressed 
>> them and sent out v9. 

One more question: why don't you keep the ack given by Cristian in v7?
>> I am carrying ack given Cristian in v9, but It is at the bottom of cover 
>> letter.

Re: [dpdk-dev] [PATCH 1/3 v3] ethdev: add rx offload to drop error packets

[Nipun Gupta]

> -Original Message-
> From: Thomas Monjalon 
> Sent: Monday, October 12, 2020 3:12 AM
> To: Nipun Gupta 
> Cc: dev@dpdk.org; ferruh.yi...@intel.com; arybche...@solarflare.com;
> Hemant Agrawal ; Sachin Saxena
> ; Rohit Raj ;
> jerinjac...@gmail.com; step...@networkplumber.org; as...@nvidia.com
> Subject: Re: [dpdk-dev] [PATCH 1/3 v3] ethdev: add rx offload to drop error
> packets
> 
> Hi,
> 
> The configuration of this feature is not clear to me.
> Please see the comments below.
> 
> 09/10/2020 15:13, nipun.gu...@nxp.com:
> > From: Nipun Gupta 
> >
> > This change adds a RX offload capability and configuration to
> > enable hardware to drop the packets in case of any error in the
> > packets such as L3 checksum error or L4 checksum.
> >
> > Signed-off-by: Nipun Gupta 
> > Signed-off-by: Rohit Raj 
> > Reviewed-by: Asaf Penso 
> > ---
> [...]
> > +/**
> > + * A structure used to enable/disable error packet drop on RX.
> 
> RX -> Rx
> same for other occurences below

Okay.

> 
> > + */
> > +struct rte_rx_err_pkt_drop_conf {
> 
> The name should start with rte_eth_
> 
> > +   /** enable/disable all RX error packet drop.
> > +* 0 (default) - disable, 1 enable
> > +*/
> > +   uint32_t all:1;
> > +};
> 
> I don't understand the meaning of this struct.
> Is it just one bit to drop packets having an error?
> How do you determine what is an error?

The error packets which are dropped on the hardware can be from
various reasons, like L1 FCS, L3 CSUM, L4 CSUM or HW can be configured
to drop ALL (or any) of the error packets received on the interface.

Currently DPAA drivers support drop of ALL the error packets, but does
not support configuration of packet drops on basis of separate error types
like dropping only L2 CSUM, L3 CSUM. So this patch is supporting only drop
of 'ALL' the errors packets received on HW.

Marvell supports drop on separate error types, thus Jerin suggested to have
this structure so that it opens the room for adding separate configuration
to drop packets on basis of separate error types.

Jerin,
maybe you can add more on this.

> 
> [...]
> > @@ -1236,6 +1246,8 @@ struct rte_eth_conf {
> > uint32_t dcb_capability_en;
> > struct rte_fdir_conf fdir_conf; /**< FDIR configuration. DEPRECATED */
> > struct rte_intr_conf intr_conf; /**< Interrupt mode configuration. */
> > +   struct rte_rx_err_pkt_drop_conf err_pkt_drop_conf;
> > +   /**< RX error packet drop configuration. */
> 
> Why a per-port configuration is needed in addition of the per-queue offload?
> 
> [...]
> > @@ -1260,6 +1272,7 @@ struct rte_eth_conf {
> >  #define DEV_RX_OFFLOAD_SCTP_CKSUM  0x0002
> >  #define DEV_RX_OFFLOAD_OUTER_UDP_CKSUM  0x0004
> >  #define DEV_RX_OFFLOAD_RSS_HASH0x0008
> > +#define DEV_RX_OFFLOAD_ERR_PKT_DROP0x0010
> 
> New offload names should starte with RTE_ prefix.

Okay

> 
> 
> > +/**
> > + * RX Error Drop offload config/capabilities of a device. These
> > + * are valid only when RX capability DEV_RX_OFFLOAD_ERR_PKT_DROP
> > + * is supported by the device.
> > + */
> > +#define DEV_RX_ERR_PKT_DROP_OFFLOAD_ALL0x0001
> 
> I don't understand the meaning.

For DPAA drivers there is only one offload required, but once separate offloads
are added to drop packets on basis of separate errors, then it can bloat up the
offload capabilities. So we added new flags ' rte_rx_err_pkt_drop_conf ' instead
of adding this onto 'rx_offload_capa'.

There is only one flag ' DEV_RX_OFFLOAD_ERR_PKT_DROP' added in 'rx_offload_capa'
and if this flag is enabled, one or more of the flag in ' 
DEV_RX_ERR_PKT_DROP_OFFLOAD...'
can be enabled (currently only DEV_RX_ERR_PKT_DROP_OFFLOAD_ALL) being supported
Others like:
- DEV_RX_ERR_PKT_DROP_OFFLOAD_L1_FCS
- DEV_RX_ERR_PKT_DROP_OFFLOAD_L3_CSUM
- DEV_RX_ERR_PKT_DROP_OFFLOAD_L4_CSUM etc.
Can be added once any reference driver is supporting this.

P.S. I can add these flags in this patch but without any ref driver support.

> 
> > @@ -1411,6 +1431,8 @@ struct rte_eth_dev_info {
> > /**< Device per-queue RX offload capabilities. */
> > uint64_t tx_queue_offload_capa;
> > /**< Device per-queue TX offload capabilities. */
> > +   uint64_t rx_err_drop_offload_capa;
> > +   /**< RX error packet drop offload capabilities. */
> 
> Why adding a new field here instead of reporting in rx_offload_capa?

This was part of v2 where flag was added in rx_offload_capa.

Both ways (v2 and v3 versions) seems to have pros and cons:
- Adding only in the rx_offload_capa' seems simpler to implement and use
- But it shall lead to increase in the offload capability types when packet
  drop configuration is added on individual error types.

Regards,
Nipun

> 
> 

[dpdk-dev] [PATCH v3 0/2] remove list end enumerators

[Arek Kusztal]

This patchset removes enumerators RTE_CRYPTO_CIPHER_LIST_END,
RTE_CRYPTO_AUTH_LIST_END, RTE_CRYPTO_AEAD_LIST_END from symmetric
crypto API to prevent some problems that may arise when adding
new crypto algorithms.

v2:
- combined patches into one series
- added removal of deprecation notice
v3:
- removed asymmetric crypto patches

Arek Kusztal (2):
  cryptodev: remove crypto list end enumerators
  doc: remove crypto list end deprecation notice

 doc/guides/rel_notes/deprecation.rst  |  5 -
 lib/librte_cryptodev/rte_crypto_sym.h | 12 +++-
 2 files changed, 3 insertions(+), 14 deletions(-)

-- 
2.17.1

[dpdk-dev] [PATCH v3 1/2] cryptodev: remove crypto list end enumerators

[Arek Kusztal]

This patch removes enumerators RTE_CRYPTO_CIPHER_LIST_END,
RTE_CRYPTO_AUTH_LIST_END, RTE_CRYPTO_AEAD_LIST_END to prevent
some problems that may arise when adding new crypto algorithms.

Signed-off-by: Arek Kusztal 
---
 lib/librte_cryptodev/rte_crypto_sym.h | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/lib/librte_cryptodev/rte_crypto_sym.h 
b/lib/librte_cryptodev/rte_crypto_sym.h
index f29c98051..7a2556a9e 100644
--- a/lib/librte_cryptodev/rte_crypto_sym.h
+++ b/lib/librte_cryptodev/rte_crypto_sym.h
@@ -132,15 +132,12 @@ enum rte_crypto_cipher_algorithm {
 * for m_src and m_dst in the rte_crypto_sym_op must be NULL.
 */
 
-   RTE_CRYPTO_CIPHER_DES_DOCSISBPI,
+   RTE_CRYPTO_CIPHER_DES_DOCSISBPI
/**< DES algorithm using modes required by
 * DOCSIS Baseline Privacy Plus Spec.
 * Chained mbufs are not supported in this mode, i.e. rte_mbuf.next
 * for m_src and m_dst in the rte_crypto_sym_op must be NULL.
 */
-
-   RTE_CRYPTO_CIPHER_LIST_END
-
 };
 
 /** Cipher algorithm name strings */
@@ -312,10 +309,8 @@ enum rte_crypto_auth_algorithm {
/**< HMAC using 384 bit SHA3 algorithm. */
RTE_CRYPTO_AUTH_SHA3_512,
/**< 512 bit SHA3 algorithm. */
-   RTE_CRYPTO_AUTH_SHA3_512_HMAC,
+   RTE_CRYPTO_AUTH_SHA3_512_HMAC
/**< HMAC using 512 bit SHA3 algorithm. */
-
-   RTE_CRYPTO_AUTH_LIST_END
 };
 
 /** Authentication algorithm name strings */
@@ -412,9 +407,8 @@ enum rte_crypto_aead_algorithm {
/**< AES algorithm in CCM mode. */
RTE_CRYPTO_AEAD_AES_GCM,
/**< AES algorithm in GCM mode. */
-   RTE_CRYPTO_AEAD_CHACHA20_POLY1305,
+   RTE_CRYPTO_AEAD_CHACHA20_POLY1305
/**< Chacha20 cipher with poly1305 authenticator */
-   RTE_CRYPTO_AEAD_LIST_END
 };
 
 /** AEAD algorithm name strings */
-- 
2.17.1

[dpdk-dev] [PATCH v3 2/2] doc: remove crypto list end deprecation notice

[Arek Kusztal]

This patch removes deprecation notice about removing
LIST_END enumerators from Cryptodev.

Signed-off-by: Arek Kusztal 
---
 doc/guides/rel_notes/deprecation.rst | 5 -
 1 file changed, 5 deletions(-)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index f9b72acb8..7f203fd7e 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -230,11 +230,6 @@ Deprecation Notices
   Hence the API will be modified to take two mempool pointers - one for session
   and one for private data.
 
-* cryptodev: ``RTE_CRYPTO_AEAD_LIST_END`` from ``enum 
rte_crypto_aead_algorithm``,
-  ``RTE_CRYPTO_CIPHER_LIST_END`` from ``enum rte_crypto_cipher_algorithm`` and
-  ``RTE_CRYPTO_AUTH_LIST_END`` from ``enum rte_crypto_auth_algorithm``
-  will be removed.
-
 * cryptodev: support for using IV with all sizes is added, J0 still can
   be used but only when IV length in following structs 
``rte_crypto_auth_xform``,
   ``rte_crypto_aead_xform`` is set to zero. When IV length is greater or equal
-- 
2.17.1

Re: [dpdk-dev] [PATCH] test/event_crypto_adapter: fix conf issue

[Gujjar, Abhinandan S]

Hi Akhil,

This was introduced in patch (24054e3640a2).

Fixes: 24054e3640a2 ("test/crypto: use separate session mempools")

Thanks
Abhinandan

> -Original Message-
> From: Akhil Goyal 
> Sent: Saturday, October 10, 2020 12:32 AM
> To: Gujjar, Abhinandan S ; dev@dpdk.org;
> jer...@marvell.com
> Cc: Vangati, Narender 
> Subject: RE: [dpdk-dev] [PATCH] test/event_crypto_adapter: fix conf issue
> 
> Hi Abhinandan,
> 
> > Hi Akhil,
> >
> > If the patch is ok, could you please ack it?
> >
> Could you please send the Fixes tag for the original patch which introduced 
> this
> Issue? I will add it while applying the patch.
> 
> Acked-by: Akhil Goyal 
> 
> 
> > >
> > > Hi Akhil,
> > >
> > > Recently, I observed that test was failing with sw adapter.
> > > I noticed that, it was because of some changes went in related to
> > > crypto in the past releases.
> > > One of the tests, configures a session in turn calls
> > > null_crypto_set_session_parameters()
> > > which checks for params was failing. As part of fixing & updating
> > > the xforms to address this issue, thought of getting rid of algo as
> > > well, to make the test simpler. The test continues to use null
> > > cryptodev and does not deal with any encryption or auth.
> > >
> > > Regards
> > > Abhinandan
> > >
> > > > -Original Message-
> > > > From: Akhil Goyal 
> > > > Sent: Wednesday, September 23, 2020 12:59 AM
> > > > To: Gujjar, Abhinandan S ;
> > > > dev@dpdk.org; jer...@marvell.com
> > > > Cc: Vangati, Narender 
> > > > Subject: RE: [dpdk-dev] [PATCH] test/event_crypto_adapter: fix
> > > > conf issue
> > > >
> > > > Hi Abhinandan,
> > > >
> > > > > This patch updates the xform with right configuration.
> > > > > For session based ops, sym session pool is created with valid
> > > > > userdata size.
> > > > >
> > > > > Signed-off-by: Abhinandan Gujjar 
> > > > > ---
> > > > The patch description do not match with the patch.
> > > > I can see that you are changing the cipher algo from AES-CBC to
> > > > NULL Without explaining the reason.
> > > > Could you please clarify the need of this patch.
> > > >
> > > > Regards,
> > > > Akhil

Re: [dpdk-dev] [PATCH v2] ethdev: check if queue setupped in queue-related APIs

[Stephen Hemminger]

On Mon, 12 Oct 2020 11:19:07 +0800
"Wei Hu (Xavier)"  wrote:

> + RTE_ETHDEV_LOG(ERR,
> +"Queue %u of device with port_id=%u has not been"
> +" setup\n", rx_queue_id, port_id);

Please do not break lines in format strings.
If checkpatch complains (which it shouldn't) ignore the warning.

Re: [dpdk-dev] [v2 1/2] cryptodev: support enqueue callback functions

[Gujjar, Abhinandan S]

Hi Konstantin,

> -Original Message-
> From: Ananyev, Konstantin 
> Sent: Monday, October 12, 2020 4:33 AM
> To: Gujjar, Abhinandan S ; Honnappa
> Nagarahalli ; dev@dpdk.org; Doherty,
> Declan 
> Cc: jer...@marvell.com; akhil.go...@nxp.com; Vangati, Narender
> ; nd ; nd 
> Subject: RE: [dpdk-dev] [v2 1/2] cryptodev: support enqueue callback functions
> 
> 
> 
> Hi Abhinandan,
> 
> >
> > Hi Konstantin,
> >
> >
> > > -Original Message-
> > > From: Ananyev, Konstantin 
> > > Sent: Friday, October 9, 2020 8:10 PM
> > > To: Gujjar, Abhinandan S ; Honnappa
> > > Nagarahalli ; dev@dpdk.org; Doherty,
> > > Declan 
> > > Cc: jer...@marvell.com; akhil.go...@nxp.com; Vangati, Narender
> > > ; nd ; nd 
> > > Subject: RE: [dpdk-dev] [v2 1/2] cryptodev: support enqueue callback
> > > functions
> > >
> > > Hi Abhinandan,
> > >
> > > >
> > > > Hi Konstantin & Honnappa,
> > > >
> > > > Thanks for all the inputs and feedback.
> > > >
> > > > @Ananyev, Konstantin,
> > > > I have measured the perf with and without callback on xeon. Here
> > > > are the
> > > numbers:
> > > >
> > > > ./app/dpdk-test-crypto-perf -l 6-7
> > > > --vdev="crypto_openssl0,socket_id=0,max_nb_sessions=128" --
> > > > --ptest throughput --devtype crypto_openssl --optype
> > > > cipher-then-auth --cipher-algo aes-cbc --cipher-op encrypt
> > > > --cipher-key-sz 16 --auth-algo sha1-hmac --auth-op generate
> > > > --auth-key-sz 64 --digest-sz
> > > > 12 --total-ops 1000 --burst-sz 32 --buffer-sz 64
> > > >
> > > > With callback(+ RCU - totally opaque to data-plane threads)
> > > > lcore idBuf Size  Burst SizeEnqueuedDequeued  Failed Enq
> Failed
> > > DeqMOpsGbps  Cycles/Buf
> > > >7  64  321000
> > > > 1000   0   0
> > > 0.8129  0.4162 2694.09
> > > >7  64  321000
> > > > 1000   0   0
> > > 0.8152  0.4174 2686.31
> > > >7  64  321000
> > > > 1000   0   0
> > > 0.8198  0.4197 2671.48
> > > >
> > > > Without callback:
> > > > lcore idBuf Size  Burst SizeEnqueuedDequeued  Failed Enq
> Failed
> > > DeqMOpsGbps  Cycles/Buf
> > > >
> > > >7  64  32   10001000 
> > > >   0   0
> > > 0.8234  0.4216 2659.81
> > > >7  64  32   10001000 
> > > >   0   0
> > > 0.8247  0.4222 2655.63
> > > >7  64  32   10001000 
> > > >   0   0
> > > 0.8123  0.4159 2695.90
> > >
> > >
> > > Just to cofirm:
> > > You implemented crypto enqueue callbacks using RCU QSBR online
> > > /offline (as suggested below) and numbers above are for:
> > > 1) callback code in place and some dummy callback installed
> > That's right. (+ RCU calling online + offline APIs inside
> > rte_cryptodev_enqueue_burst())
> > > 2) callback code in place but no callbacks installed
> > No callback code. i.e. Original code.
> 
> Ok, and if I get things right - difference between mean values is ~15 cycles?
Yes. May be, number are more stable on isolated core. Let's consider worst case 
too.
> That's seems like very good result to me.
> Can I suggest to run one more test for your new callback code in place, but no
> actual callbacks installed?
lcore idBuf Size  Burst SizeEnqueuedDequeued  Failed Enq  
Failed DeqMOpsGbps  Cycles/Buf

   7  64  3210001000   0
   0  0.8220  0.4209 2664.12
   7  64  3210001000   0
   0  0.8245  0.4221 2656.14
   7  64  3210001000   0
   0  0.8261  0.4229 2651.15

> Thanks
> Konstantin
> 
> > >
> > > Is my understanding correct here?
> > > Thanks
> > > Konstantin
> > >
> > >
> > > >
> > > > Regards
> > > > Abhinandan
> > > >
> > > > > -Original Message-
> > > > > From: Ananyev, Konstantin 
> > > > > Sent: Tuesday, September 29, 2020 2:33 PM
> > > > > To: Honnappa Nagarahalli ; Gujjar,
> > > > > Abhinandan S ; dev@dpdk.org;
> > > > > Doherty, Declan 
> > > > > Cc: jer...@marvell.com; akhil.go...@nxp.com; Vangati, Narender
> > > > > ; nd ; nd 
> > > > > Subject: RE: [dpdk-dev] [v2 1/2] cryptodev: support enqueue
> > > > > callback functions
> > > > >
> > > > >
> > > > > >
> > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > +#ifdef RTE_CRYPTODEV_CALLBACKS int
> > > > > > > > > > > > > > > > +rte_cryptodev_rcu_qsbr_add(uint8_t
> > > > > > > > > > > > > > > > +dev_id, struct rte_rcu_qsbr
> > > > > > > > > > > > > > > > +*qsbr) {
> > > > > > > > > > > > > > > > +
> > > > > > > > > > > 

Re: [dpdk-dev] [EXT] [PATCH v6 03/14] doc: remove references to make from NICs guides

[Rasesh Mody]

>From: Thomas Monjalon 
>Sent: Sunday, October 11, 2020 2:02 PM
>
>09/10/2020 14:00, Igor Russkikh:
>> > --- a/doc/guides/nics/qede.rst
>> > +++ b/doc/guides/nics/qede.rst
>> > @@ -106,22 +106,9 @@ Performance note  Config File Options
>> > ~~~
>> >
>> > -The following options can be modified in the ``.config`` file.
>> > Please note that -enabling debugging options may affect system
>> > performance.
>> > +The following option can be modified in the ``config/rte_config.h`` file.
>> >
>> > -- ``CONFIG_RTE_LIBRTE_QEDE_PMD`` (default **y**)
>> > -
>> > -  Toggle compilation of QEDE PMD driver.
>>
>> This one is correctly removed, but the below defines,
>>
>> > -- ``CONFIG_RTE_LIBRTE_QEDE_DEBUG_TX`` (default **n**)
>> > -
>> > -  Toggle display of transmit fast path run-time messages.
>> > -
>> > -- ``CONFIG_RTE_LIBRTE_QEDE_DEBUG_RX`` (default **n**)
>> > -
>> > -  Toggle display of receive fast path run-time messages.
>> > -
>> > -- ``CONFIG_RTE_LIBRTE_QEDE_FW`` (default **""**)
>> > +- ``RTE_LIBRTE_QEDE_FW`` (default **""**)
>> >
>> >Gives absolute path of firmware file.
>> >``Eg: "/lib/firmware/qed/qed_init_values-8.40.33.0.bin"``
>>
>> These all still exist. I believe "CONFIG_" prefix should be removed
>> here, but the defines and code behind them should stay.
>
>I believe the same comment applies to multiple drivers which have
>compilation options and probably should keep this information.
>
>That's the main reason why I didn't apply these patches so far, waiting for
>feedbacks.
>It has been decided in a maintainers meeting to apply the patches anyway,
>but given we have a request for qede, I think it blocks applying this v6.
>

Thanks for the patch Ciara, besides 'qede' PMD we also need similar config 
preserved for 'bnx2x' PMD.

Remove "CONFIG_" prefix and retain following:
RTE_LIBRTE_BNX2X_DEBUG_RX
RTE_LIBRTE_BNX2X_DEBUG_TX
RTE_LIBRTE_BNX2X_DEBUG_PERIODIC