date:20231009

RE: [EXT] Re: [PATCH v3 1/2] dmadev: offload to free source buffer

2023-10-09 Thread Amit Prakash Shukla

Hi Chengwen,

Thanks for the review and feedback. Please find my reply in-line.

Thanks,
Amit Shukla

> -Original Message-
> From: fengchengwen 
> Sent: Saturday, October 7, 2023 2:31 PM
> To: Amit Prakash Shukla ; Kevin Laatz
> ; Bruce Richardson 
> Cc: dev@dpdk.org; Jerin Jacob Kollanukkaran ;
> m...@smartsharesystems.com; conor.wa...@intel.com; Vamsi Krishna
> Attunuru ; g.si...@nxp.com;
> sachin.sax...@oss.nxp.com; hemant.agra...@nxp.com;
> cheng1.ji...@intel.com; Nithin Kumar Dabilpuram
> ; Anoob Joseph 
> Subject: [EXT] Re: [PATCH v3 1/2] dmadev: offload to free source buffer
> 
> External Email
> 
> --
> Hi Amit,
> 
> On 2023/9/28 19:50, Amit Prakash Shukla wrote:
> > This changeset adds support in DMA library to free source DMA buffer
> > by hardware. On a supported hardware, application can pass on the
> > mempool information as part of vchan config when the DMA transfer
> > direction is configured as RTE_DMA_DIR_MEM_TO_DEV.
> >
> > Signed-off-by: Amit Prakash Shukla 
> > Acked-by: Morten Brørup 
> > Acked-by: Anoob Joseph 
> > ---
> >  lib/dmadev/rte_dmadev.h | 27 +++
> >  1 file changed, 27 insertions(+)
> >
> > diff --git a/lib/dmadev/rte_dmadev.h b/lib/dmadev/rte_dmadev.h index
> > b157ab7600..f7a6af2528 100644
> > --- a/lib/dmadev/rte_dmadev.h
> > +++ b/lib/dmadev/rte_dmadev.h
> > @@ -278,6 +278,13 @@ int16_t rte_dma_next_dev(int16_t start_dev_id);
> >  #define RTE_DMA_CAPA_OPS_COPY_SG   RTE_BIT64(33)
> >  /** Support fill operation. */
> >  #define RTE_DMA_CAPA_OPS_FILL  RTE_BIT64(34)
> > +/** Support for source buffer free for mem to dev transfer.
> 
> Support auto free source buffer once the M2D (memory-to-device) transfer
> completed.

Ack

> 
> > + *
> > + * @note Even though the DMA driver has this capability, it may not
> > + support all
> > + * mempool drivers. If the mempool is not supported by the DMA
> > + driver,
> > + * rte_dma_vchan_setup() will fail.
> 
> In addition to hardware support, there are requirements for buffer attribute
> (e.g. only specific mempool support it).
> 
> > + **/
> > +#define RTE_DMA_CAPA_MEM_TO_DEV_SOURCE_BUFFER_FREE
>   RTE_BIT64(35)
> 
> 1) this should follow RTE_DMA_CAPA_HANDLES_ERRORS, because it not
> new OPS.
> 2) the name is too long. how abort
> RTE_DMA_CAPA_AUTO_FREE_M2D_SBUF? I am not sure, suggest get better
> name.

Ack.

> 
> >  /**@}*/
> >
> >  /**
> > @@ -581,6 +588,19 @@ struct rte_dma_vchan_conf {
> >  * @see struct rte_dma_port_param
> >  */
> > struct rte_dma_port_param dst_port;
> > +   /** Mempool from which source buffer is allocated. Mempool info is
> used
> > +* for freeing source buffer by hardware when configured direction is
> > +* RTE_DMA_DIR_MEM_TO_DEV. To free the source buffer by
> hardware,
> > +* RTE_DMA_OP_FLAG_FREE_SBUF must be set while calling
> rte_dma_copy and
> > +* rte_dma_copy_sg().
> > +*
> > +* @note If the mempool is not supported by the DMA device,
> > +* rte_dma_vchan_setup() will fail.
> > +*
> > +* @see RTE_DMA_OP_FLAG_FREE_SBUF
> > +*/
> > +   struct rte_mempool *mem_to_dev_src_buf_pool;
> > +
> >  };
> 
> Suggest add one extra struct e.g.
> struct rte_dma_auto_free_param {
> union {
> struct rte_mempool *pool;
> }
> uint64_t reserved[2]; /**< Reserved for future fields. */ };
> 
> In the above conf, we could add a new field: struct
> rte_dma_auto_free_param  m2d_buf

Ack, will add new struct.
struct rte_dma_auto_free_buf_param {
struct rte_mempool *pool;
uint64_t reserved[2]; /**< Reserved for future fields. */ };
};

struct rte_dma_auto_free_buf_param  m2d_sbuf;

> 
> >
> >  /**
> > @@ -818,6 +838,13 @@ struct rte_dma_sge {
> >   * capability bit for this, driver should not return error if this flag 
> > was set.
> >   */
> >  #define RTE_DMA_OP_FLAG_LLC RTE_BIT64(2)
> > +/** Mem to dev source buffer free flag.
> > + * Used for freeing source DMA buffer by hardware when the transfer
> > +direction is
> > + * configured as RTE_DMA_DIR_MEM_TO_DEV.
> > + *
> > + * @see struct rte_dma_vchan_conf::mem_to_dev_src_buf_pool
> > + */
> > +#define RTE_DMA_OP_FLAG_FREE_SBUF  RTE_BIT64(3)
> 
> Suggest RTE_DMA_OP_FLAG_AUTO_FREE_SBUF

Ack

> 
> >  /**@}*/
> >
> >  /**
> >
> 
> The S in SBUF seem useless, because it should not auto free dstbuf in
> logically.
> 
> Maybe we should direct use auto-free (just like silent)

RE: [EXT] Re: [PATCH v3 2/2] test/dma: add source buffer offload free test

2023-10-09 Thread Amit Prakash Shukla



> -Original Message-
> From: fengchengwen 
> Sent: Saturday, October 7, 2023 3:03 PM
> To: Amit Prakash Shukla ; Kevin Laatz
> ; Bruce Richardson 
> Cc: dev@dpdk.org; Jerin Jacob Kollanukkaran ;
> m...@smartsharesystems.com; conor.wa...@intel.com; Vamsi Krishna
> Attunuru ; g.si...@nxp.com;
> sachin.sax...@oss.nxp.com; hemant.agra...@nxp.com;
> cheng1.ji...@intel.com; Nithin Kumar Dabilpuram
> ; Anoob Joseph 
> Subject: [EXT] Re: [PATCH v3 2/2] test/dma: add source buffer offload free
> test
> 
> External Email
> 
> --
> Hi Amit,
> 
> On 2023/9/28 19:50, Amit Prakash Shukla wrote:
> > Add a test case to validate the functionality of drivers' dma source
> > buffer offload free. As part of dmadev_autotest, test case will be
> > executed only if the driver supports source buffer offload free and if
> > the test is exported by env variable DPDK_ADD_DMA_TEST.
> 
> Why should under control by the env variable?

Added env variable for the setups that do not have PCIe endpoint and do not 
want to run the test for DMA source buffer free even though the driver supports 
the feature.

> 
> >
> > Signed-off-by: Amit Prakash Shukla 
> > ---
> >  app/test/test_dmadev.c | 166
> > -
> >  1 file changed, 165 insertions(+), 1 deletion(-)
> >
> 
> ...

[Bug 1281] Build failure with Meson 1.2.1 on Windows

2023-10-09 Thread bugzilla

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

Thomas Monjalon (tho...@monjalon.net) changed:

   What|Removed |Added

 CC||tho...@monjalon.net
 Ever confirmed|0   |1
 Resolution|WONTFIX |---
 Status|RESOLVED|CONFIRMED

--- Comment #2 from Thomas Monjalon (tho...@monjalon.net) ---
We should not close a bug just because we don't find time to fix it.
Reopening

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

RE: [PATCH] net/mlx5: fix jump ipool entry size

2023-10-09 Thread Raslan Darawsheh

Hi,

> -Original Message-
> From: Dariusz Sosnowski 
> Sent: Friday, August 25, 2023 9:44 PM
> To: Matan Azrad ; Slava Ovsiienko
> ; Ori Kam ; Suanming Mou
> 
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: [PATCH] net/mlx5: fix jump ipool entry size
> 
> In mlx5 PMD, MLX5_IPOOL_JUMP ipool configuration is used to initialize the
> ipool containing either:
> 
> - flow table entry when DV flow engine is chosen or,
> - group table entry when HW steering flow engine is chosen.
> 
> Default configuration for MLX5_IPOOL_JUMP ipool specified entry size as size
> of mlx5_flow_tbl_data_entry struct, used with DV flow engine.
> This could lead to memory corruption when mlx5_flow_group struct (used
> with HW steering flow engine) would have bigger size than
> mlx5_flow_tbl_data_entry.
> 
> This patch fixes that. Entry size for MLX5_IPOOL_JUMP ipool is chosen
> dynamically based on device configuration.
> 
> Fixes: d1559d66ed2d ("net/mlx5: add table management")
> Cc: suanmi...@nvidia.com
> Cc: sta...@dpdk.org

Patch applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh

RE: [PATCH 1/5] net/mlx5/hws: add support for matching on bth_a bit

2023-10-09 Thread Matan Azrad



> RTE_FLOW_ITEM_TYPE_IB_BTH matches an InfiniBand base transport header.
> We extend the match on the acknowledgment bit (BTH_A).
> 
> Signed-off-by: Itamar Gozlan 

Series-acked-by: Matan Azrad 

> ---
>  drivers/net/mlx5/hws/mlx5dr_definer.c | 12 ++--
> drivers/net/mlx5/hws/mlx5dr_definer.h |  1 +
>  2 files changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/mlx5/hws/mlx5dr_definer.c
> b/drivers/net/mlx5/hws/mlx5dr_definer.c
> index 33d0f2d18e..b82af9d102 100644
> --- a/drivers/net/mlx5/hws/mlx5dr_definer.c
> +++ b/drivers/net/mlx5/hws/mlx5dr_definer.c
> @@ -177,7 +177,8 @@ struct mlx5dr_definer_conv_data {
>   X(SET_BE32, ipsec_spi,  v->hdr.spi, 
> rte_flow_item_esp) \
>   X(SET_BE32, ipsec_sequence_number,  v->hdr.seq,
> rte_flow_item_esp) \
>   X(SET,  ib_l4_udp_port, UDP_ROCEV2_PORT,
>   rte_flow_item_ib_bth) \
> - X(SET,  ib_l4_opcode,   v->hdr.opcode,
>   rte_flow_item_ib_bth)
> + X(SET,  ib_l4_opcode,   v->hdr.opcode,
>   rte_flow_item_ib_bth) \
> + X(SET,  ib_l4_bth_a,v->hdr.a,
>   rte_flow_item_ib_bth) \
> 
>  /* Item set function format */
>  #define X(set_type, func_name, value, item_type) \ @@ -2148,7 +2149,7 @@
> mlx5dr_definer_conv_item_ib_l4(struct mlx5dr_definer_conv_data *cd,
> 
>   if (m->hdr.se || m->hdr.m || m->hdr.padcnt || m->hdr.tver ||
>   m->hdr.pkey || m->hdr.f || m->hdr.b || m->hdr.rsvd0 ||
> - m->hdr.a || m->hdr.rsvd1 || !is_mem_zero(m->hdr.psn, 3)) {
> + m->hdr.rsvd1 || !is_mem_zero(m->hdr.psn, 3)) {
>   rte_errno = ENOTSUP;
>   return rte_errno;
>   }
> @@ -2167,6 +2168,13 @@ mlx5dr_definer_conv_item_ib_l4(struct
> mlx5dr_definer_conv_data *cd,
>   DR_CALC_SET_HDR(fc, ib_l4, qp);
>   }
> 
> + if (m->hdr.a) {
> + fc = &cd->fc[MLX5DR_DEFINER_FNAME_IB_L4_A];
> + fc->item_idx = item_idx;
> + fc->tag_set = &mlx5dr_definer_ib_l4_bth_a_set;
> + DR_CALC_SET_HDR(fc, ib_l4, ackreq);
> + }
> +
>   return 0;
>  }
> 
> diff --git a/drivers/net/mlx5/hws/mlx5dr_definer.h
> b/drivers/net/mlx5/hws/mlx5dr_definer.h
> index 6b645f4cf0..bf026fa6bb 100644
> --- a/drivers/net/mlx5/hws/mlx5dr_definer.h
> +++ b/drivers/net/mlx5/hws/mlx5dr_definer.h
> @@ -136,6 +136,7 @@ enum mlx5dr_definer_fname {
>   MLX5DR_DEFINER_FNAME_OKS2_MPLS4_I,
>   MLX5DR_DEFINER_FNAME_IB_L4_OPCODE,
>   MLX5DR_DEFINER_FNAME_IB_L4_QPN,
> + MLX5DR_DEFINER_FNAME_IB_L4_A,
>   MLX5DR_DEFINER_FNAME_MAX,
>  };
> 
> --
> 2.38.1

[PATCH v10 0/9] add rte flow support for cpfl

2023-10-09 Thread Zhang, Yuying

From: Yuying Zhang 

This patchset add rte flow support for cpfl driver.
It depends on the following patch set:
http://patchwork.dpdk.org/project/dpdk/cover/20230912173039.1612287-1-beilei.x...@intel.com/

Wenjing Qiao (2):
  net/cpfl: parse flow offloading hint from JSON
  net/cpfl: build action mapping rules from JSON

Yuying Zhang (7):
  net/cpfl: set up flow offloading skeleton
  net/cpfl: set up control path
  net/cpfl: add FXP low level implementation
  net/cpfl: implement FXP rule creation and destroying
  net/cpfl: adapt FXP to flow engine
  net/cpfl: support flow ops on representor
  net/cpfl: support represented port action
---
v10:
* fix ci build issue

v9:
* refine rx queue message process function

v8:
* fix compile issues
* refine document and separate patch with different features

v7:
* refine commit log
* fix compile issues

v6:
* use existed jansson instead of json-c library
* refine "add FXP low level implementation"

V5:
* Add input validation for some functions

 doc/guides/nics/cpfl.rst|   52 +
 doc/guides/rel_notes/release_23_11.rst  |1 +
 drivers/net/cpfl/cpfl_actions.h |  858 +++
 drivers/net/cpfl/cpfl_controlq.c|  801 ++
 drivers/net/cpfl/cpfl_controlq.h|   75 +
 drivers/net/cpfl/cpfl_ethdev.c  |  392 -
 drivers/net/cpfl/cpfl_ethdev.h  |  128 ++
 drivers/net/cpfl/cpfl_flow.c|  339 +
 drivers/net/cpfl/cpfl_flow.h|   85 ++
 drivers/net/cpfl/cpfl_flow_engine_fxp.c |  666 
 drivers/net/cpfl/cpfl_flow_parser.c | 1835 +++
 drivers/net/cpfl/cpfl_flow_parser.h |  268 
 drivers/net/cpfl/cpfl_fxp_rule.c|  263 
 drivers/net/cpfl/cpfl_fxp_rule.h|   68 +
 drivers/net/cpfl/cpfl_representor.c |   29 +
 drivers/net/cpfl/cpfl_rules.c   |  127 ++
 drivers/net/cpfl/cpfl_rules.h   |  306 
 drivers/net/cpfl/cpfl_vchnl.c   |  144 ++
 drivers/net/cpfl/meson.build|   12 +
 19 files changed, 6448 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/cpfl/cpfl_actions.h
 create mode 100644 drivers/net/cpfl/cpfl_controlq.c
 create mode 100644 drivers/net/cpfl/cpfl_controlq.h
 create mode 100644 drivers/net/cpfl/cpfl_flow.c
 create mode 100644 drivers/net/cpfl/cpfl_flow.h
 create mode 100644 drivers/net/cpfl/cpfl_flow_engine_fxp.c
 create mode 100644 drivers/net/cpfl/cpfl_flow_parser.c
 create mode 100644 drivers/net/cpfl/cpfl_flow_parser.h
 create mode 100644 drivers/net/cpfl/cpfl_fxp_rule.c
 create mode 100644 drivers/net/cpfl/cpfl_fxp_rule.h
 create mode 100644 drivers/net/cpfl/cpfl_rules.c
 create mode 100644 drivers/net/cpfl/cpfl_rules.h

-- 
2.34.1

[PATCH v10 1/9] net/cpfl: parse flow offloading hint from JSON

2023-10-09 Thread Zhang, Yuying

From: Wenjing Qiao 

Add devargs "flow_parser" to specify the path of a JSON
configure file. The cpfl PMD use the JSON configuration file
to translate rte_flow tokens into low level hardware
representation.

Example:
-a ca:00.0,flow_parser="refpkg.json"

jansson library is used to parse JSON syntax.

In this patch, The parser only builds rules which maps from
a set of rte_flow items to hardware representations. The rules
that maps from rte_flow actions will be enabled in a separate
patch to avoid a big size patch.

Note, the JSON configuration file is provided by the hardware vendor
and is intended to work exclusively with a specific P4 pipeline
configuration, which must be compiled and programmed into the hardware.

The format of the JSON file strictly follows the internal specifications
of the hardware vendor and is not meant to be modified directly by
users.

Signed-off-by: Wenjing Qiao 
Acked-by: Qi Zhang 
---
 doc/guides/nics/cpfl.rst|   38 +
 drivers/net/cpfl/cpfl_ethdev.c  |   38 +-
 drivers/net/cpfl/cpfl_ethdev.h  |   76 ++
 drivers/net/cpfl/cpfl_flow_parser.c | 1299 +++
 drivers/net/cpfl/cpfl_flow_parser.h |  168 
 drivers/net/cpfl/meson.build|7 +
 6 files changed, 1625 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/cpfl/cpfl_flow_parser.c
 create mode 100644 drivers/net/cpfl/cpfl_flow_parser.h

diff --git a/doc/guides/nics/cpfl.rst b/doc/guides/nics/cpfl.rst
index 83a18c3f2e..e17347d15c 100644
--- a/doc/guides/nics/cpfl.rst
+++ b/doc/guides/nics/cpfl.rst
@@ -128,12 +128,32 @@ Runtime Configuration
 
 -a BDF,representor=vf[0-3],representor=c1pf1
 
+- ``flow_parser`` (default ``not enabled``)
+
+  The cpfl PMD supports utilizing a JSON config file to translate rte_flow 
tokens into
+  low-level hardware resources.
+
+  The JSON configuration file is provided by the hardware vendor and is 
intended to work
+  exclusively with a specific P4 pipeline configuration, which must be 
compiled and programmed
+  into the hardware.
+
+  The format of the JSON file strictly follows the internal specifications of 
the hardware
+  vendor and is not meant to be modified directly by users.
+
+  Using the ``devargs`` option ``flow_parser`` the user can specify the path
+  of a json file, for example::
+
+-a ca:00.0,flow_parser="refpkg.json"
+
+  Then the PMD will load json file for device ``ca:00.0``.
+  The parameter is optional.
 
 Driver compilation and testing
 --
 
 Refer to the document :doc:`build_and_test` for details.
 
+The jansson library must be installed to use rte_flow.
 
 Features
 
@@ -164,3 +184,21 @@ Hairpin queue
 E2100 Series can loopback packets from RX port to TX port.
 This feature is called port-to-port or hairpin.
 Currently, the PMD only supports single port hairpin.
+
+Rte_flow
+~
+
+PMD uses a json file to direct CPF PMD to parse rte_flow tokens into
+low level hardware resources.
+
+- Required Libraries
+
+  * jansson
+
+* For Ubuntu, it can be installed using `apt install libjansson-dev`
+
+- run testpmd with the json file
+
+   .. code-block:: console
+
+   dpdk-testpmd -c 0x3 -n 4 -a 
:af:00.6,vport=[0],flow_parser="refpkg.json" -- -i
diff --git a/drivers/net/cpfl/cpfl_ethdev.c b/drivers/net/cpfl/cpfl_ethdev.c
index 189072ab33..1745f703c8 100644
--- a/drivers/net/cpfl/cpfl_ethdev.c
+++ b/drivers/net/cpfl/cpfl_ethdev.c
@@ -21,6 +21,10 @@
 #define CPFL_RX_SINGLE_Q   "rx_single"
 #define CPFL_VPORT "vport"
 
+#ifdef RTE_HAS_JANSSON
+#define CPFL_FLOW_PARSER   "flow_parser"
+#endif
+
 rte_spinlock_t cpfl_adapter_lock;
 /* A list for all adapters, one adapter matches one PCI device */
 struct cpfl_adapter_list cpfl_adapter_list;
@@ -31,6 +35,9 @@ static const char * const cpfl_valid_args_first[] = {
CPFL_TX_SINGLE_Q,
CPFL_RX_SINGLE_Q,
CPFL_VPORT,
+#ifdef RTE_HAS_JANSSON
+   CPFL_FLOW_PARSER,
+#endif
NULL
 };
 
@@ -1537,6 +1544,24 @@ parse_repr(const char *key __rte_unused, const char 
*value, void *args)
return 0;
 }
 
+#ifdef RTE_HAS_JANSSON
+static int
+parse_file(const char *key, const char *value, void *args)
+{
+   char *name = args;
+
+   if (strlen(value) > CPFL_FLOW_FILE_LEN - 1) {
+   PMD_DRV_LOG(ERR, "file path(%s) is too long.", value);
+   return -1;
+   }
+
+   PMD_DRV_LOG(DEBUG, "value:\"%s\" for key:\"%s\"", value, key);
+   strlcpy(name, value, CPFL_FLOW_FILE_LEN);
+
+   return 0;
+}
+#endif
+
 static int
 cpfl_parse_devargs(struct rte_pci_device *pci_dev, struct cpfl_adapter_ext 
*adapter, bool first)
 {
@@ -1585,7 +1610,18 @@ cpfl_parse_devargs(struct rte_pci_device *pci_dev, 
struct cpfl_adapter_ext *adap
 &adapter->base.is_rx_singleq);
if (ret != 0)
goto fail;
-
+#ifdef RTE_HAS_JANSSON
+   if (rte_kvargs_get(kvlist, CPFL_FLOW_PARSER)) {
+   ret = r

[PATCH v10 2/9] net/cpfl: build action mapping rules from JSON

2023-10-09 Thread Zhang, Yuying

From: Wenjing Qiao 

Build rules that maps from an rte_flow action vxlan_encap or
vxlan_decap to hardware representations.

Signed-off-by: Wenjing Qiao 
Acked-by: Qi Zhang 
---
 drivers/net/cpfl/cpfl_flow_parser.c | 538 +++-
 drivers/net/cpfl/cpfl_flow_parser.h | 100 ++
 2 files changed, 637 insertions(+), 1 deletion(-)

diff --git a/drivers/net/cpfl/cpfl_flow_parser.c 
b/drivers/net/cpfl/cpfl_flow_parser.c
index a5fff5a857..0e623494a2 100644
--- a/drivers/net/cpfl/cpfl_flow_parser.c
+++ b/drivers/net/cpfl/cpfl_flow_parser.c
@@ -28,6 +28,18 @@ cpfl_get_item_type_by_str(const char *type)
return RTE_FLOW_ITEM_TYPE_VOID;
 }
 
+static enum rte_flow_action_type
+cpfl_get_action_type_by_str(const char *type)
+{
+   if (strcmp(type, "vxlan_encap") == 0)
+   return RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP;
+   else if (strcmp(type, "vxlan_decap") == 0)
+   return RTE_FLOW_ACTION_TYPE_VXLAN_DECAP;
+
+   PMD_DRV_LOG(ERR, "Not support this type: %s.", type);
+   return RTE_FLOW_ACTION_TYPE_VOID;
+}
+
 static const char *
 cpfl_json_t_to_string(json_t *object, const char *name)
 {
@@ -46,6 +58,29 @@ cpfl_json_t_to_string(json_t *object, const char *name)
return json_string_value(subobject);
 }
 
+static int
+cpfl_json_t_to_int(json_t *object, const char *name, int *value)
+{
+   json_t *subobject;
+
+   if (!object) {
+   PMD_DRV_LOG(ERR, "object doesn't exist.");
+   return -EINVAL;
+   }
+   subobject = json_object_get(object, name);
+   if (!subobject) {
+   PMD_DRV_LOG(ERR, "%s doesn't exist.", name);
+   return -EINVAL;
+   }
+   if (!json_is_integer(subobject)) {
+   PMD_DRV_LOG(ERR, "%s is not an integer.", name);
+   return -EINVAL;
+   }
+   *value = (int)json_integer_value(subobject);
+
+   return 0;
+}
+
 static int
 cpfl_json_t_to_uint16(json_t *object, const char *name, uint16_t *value)
 {
@@ -518,6 +553,228 @@ cpfl_flow_js_pattern_rule(json_t *ob_root, struct 
cpfl_flow_js_parser *parser)
return -EINVAL;
 }
 
+static int
+cpfl_flow_js_mr_key(json_t *ob_mr_keys, struct cpfl_flow_js_mr_key *js_mr_key)
+{
+   int len, i;
+
+   len = json_array_size(ob_mr_keys);
+   if (len == 0)
+   return 0;
+   js_mr_key->actions = rte_malloc(NULL, sizeof(struct 
cpfl_flow_js_mr_key_action) * len, 0);
+   if (!js_mr_key->actions) {
+   PMD_DRV_LOG(ERR, "Failed to alloc memory.");
+   return -ENOMEM;
+   }
+   js_mr_key->actions_size = len;
+   for (i = 0; i < len; i++) {
+   json_t *object, *ob_data;
+   const char *type;
+   enum rte_flow_action_type act_type;
+
+   object = json_array_get(ob_mr_keys, i);
+   /* mr->key->actions->type */
+   type = cpfl_json_t_to_string(object, "type");
+   if (!type) {
+   PMD_DRV_LOG(ERR, "Can not parse string 'type'.");
+   goto err;
+   }
+   act_type = cpfl_get_action_type_by_str(type);
+   if (act_type == RTE_FLOW_ACTION_TYPE_VOID)
+   goto err;
+   js_mr_key->actions[i].type = act_type;
+   /* mr->key->actions->data */
+   ob_data = json_object_get(object, "data");
+   if (js_mr_key->actions[i].type == 
RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP) {
+   json_t *ob_protos;
+   int proto_size, j;
+   struct cpfl_flow_js_mr_key_action_vxlan_encap *encap;
+
+   ob_protos = json_object_get(ob_data, "protocols");
+   encap = &js_mr_key->actions[i].encap;
+   if (!ob_protos) {
+   encap->proto_size = 0;
+   continue;
+   }
+   proto_size = json_array_size(ob_protos);
+   encap->proto_size = proto_size;
+   for (j = 0; j < proto_size; j++) {
+   const char *s;
+   json_t *subobject;
+   enum rte_flow_item_type proto_type;
+
+   subobject = json_array_get(ob_protos, j);
+   s = json_string_value(subobject);
+   proto_type = cpfl_get_item_type_by_str(s);
+   if (proto_type == RTE_FLOW_ITEM_TYPE_VOID) {
+   PMD_DRV_LOG(ERR, "parse VXLAN_ENCAP 
failed.");
+   goto err;
+   }
+   encap->protocols[j] = proto_type;
+   }
+   } else if (js_mr_key->actions[i].type != 
RTE_FLOW_ACTION_TYPE_VXLAN_DECAP) {
+

[PATCH v10 3/9] net/cpfl: set up flow offloading skeleton

2023-10-09 Thread Zhang, Yuying

From: Yuying Zhang 

Set up the rte_flow backend skeleton. Introduce the framework
to support different engines as rte_flow backend. Bridge rte_flow
driver API to flow engines.

Signed-off-by: Yuying Zhang 
Acked-by: Qi Zhang 
---
 drivers/net/cpfl/cpfl_ethdev.c |  53 ++
 drivers/net/cpfl/cpfl_ethdev.h |   5 +
 drivers/net/cpfl/cpfl_flow.c   | 339 +
 drivers/net/cpfl/cpfl_flow.h   |  85 +
 drivers/net/cpfl/meson.build   |   1 +
 5 files changed, 483 insertions(+)
 create mode 100644 drivers/net/cpfl/cpfl_flow.c
 create mode 100644 drivers/net/cpfl/cpfl_flow.h

diff --git a/drivers/net/cpfl/cpfl_ethdev.c b/drivers/net/cpfl/cpfl_ethdev.c
index 1745f703c8..c350728861 100644
--- a/drivers/net/cpfl/cpfl_ethdev.c
+++ b/drivers/net/cpfl/cpfl_ethdev.c
@@ -15,6 +15,7 @@
 #include "cpfl_ethdev.h"
 #include 
 #include "cpfl_rxtx.h"
+#include "cpfl_flow.h"
 
 #define CPFL_REPRESENTOR   "representor"
 #define CPFL_TX_SINGLE_Q   "tx_single"
@@ -1074,6 +1075,19 @@ cpfl_dev_stop(struct rte_eth_dev *dev)
return 0;
 }
 
+static void
+cpfl_flow_free(struct cpfl_vport *vport)
+{
+   struct rte_flow *p_flow;
+
+   while ((p_flow = TAILQ_FIRST(&vport->itf.flow_list))) {
+   TAILQ_REMOVE(&vport->itf.flow_list, p_flow, next);
+   if (p_flow->engine->free)
+   p_flow->engine->free(p_flow);
+   rte_free(p_flow);
+   }
+}
+
 static int
 cpfl_p2p_queue_grps_del(struct idpf_vport *vport)
 {
@@ -1105,6 +1119,7 @@ cpfl_dev_close(struct rte_eth_dev *dev)
if (!adapter->base.is_rx_singleq && !adapter->base.is_tx_singleq)
cpfl_p2p_queue_grps_del(vport);
 
+   cpfl_flow_free(cpfl_vport);
idpf_vport_deinit(vport);
rte_free(cpfl_vport->p2p_q_chunks_info);
 
@@ -1117,6 +1132,29 @@ cpfl_dev_close(struct rte_eth_dev *dev)
return 0;
 }
 
+static int
+cpfl_dev_flow_ops_get(struct rte_eth_dev *dev,
+ const struct rte_flow_ops **ops)
+{
+   struct cpfl_itf *itf;
+
+   if (!dev)
+   return -EINVAL;
+
+   itf = CPFL_DEV_TO_ITF(dev);
+
+   /* only vport support rte_flow */
+   if (itf->type != CPFL_ITF_TYPE_VPORT)
+   return -ENOTSUP;
+#ifdef RTE_HAS_JANSSON
+   *ops = &cpfl_flow_ops;
+#else
+   *ops = NULL;
+   PMD_DRV_LOG(NOTICE, "not support rte_flow, please install json-c 
library.");
+#endif
+   return 0;
+}
+
 static int
 cpfl_hairpin_get_peer_ports(struct rte_eth_dev *dev, uint16_t *peer_ports,
size_t len, uint32_t tx)
@@ -1318,6 +1356,7 @@ static const struct eth_dev_ops cpfl_eth_dev_ops = {
.xstats_get = cpfl_dev_xstats_get,
.xstats_get_names   = cpfl_dev_xstats_get_names,
.xstats_reset   = cpfl_dev_xstats_reset,
+   .flow_ops_get   = cpfl_dev_flow_ops_get,
.hairpin_cap_get= cpfl_hairpin_cap_get,
.rx_hairpin_queue_setup = cpfl_rx_hairpin_queue_setup,
.tx_hairpin_queue_setup = cpfl_tx_hairpin_queue_setup,
@@ -2021,6 +2060,13 @@ cpfl_adapter_ext_init(struct rte_pci_device *pci_dev, 
struct cpfl_adapter_ext *a
goto err_vports_alloc;
}
 
+#ifdef RTE_HAS_JANSSON
+   ret = cpfl_flow_init(adapter);
+   if (ret) {
+   PMD_INIT_LOG(ERR, "Failed to init flow module");
+   goto err_flow_init;
+   }
+#endif
adapter->cur_vports = 0;
adapter->cur_vport_nb = 0;
 
@@ -2028,6 +2074,9 @@ cpfl_adapter_ext_init(struct rte_pci_device *pci_dev, 
struct cpfl_adapter_ext *a
 
return ret;
 
+#ifdef RTE_HAS_JANSSON
+err_flow_init:
+#endif
 err_vports_alloc:
rte_eal_alarm_cancel(cpfl_dev_alarm_handler, adapter);
cpfl_repr_allowlist_uninit(adapter);
@@ -2182,6 +2231,7 @@ cpfl_dev_vport_init(struct rte_eth_dev *dev, void 
*init_params)
cpfl_vport->itf.type = CPFL_ITF_TYPE_VPORT;
cpfl_vport->itf.adapter = adapter;
cpfl_vport->itf.data = dev->data;
+   TAILQ_INIT(&cpfl_vport->itf.flow_list);
adapter->vports[param->idx] = cpfl_vport;
adapter->cur_vports |= RTE_BIT32(param->devarg_id);
adapter->cur_vport_nb++;
@@ -2262,6 +2312,9 @@ cpfl_find_adapter_ext(struct rte_pci_device *pci_dev)
 static void
 cpfl_adapter_ext_deinit(struct cpfl_adapter_ext *adapter)
 {
+#ifdef RTE_HAS_JANSSON
+   cpfl_flow_uninit(adapter);
+#endif
rte_eal_alarm_cancel(cpfl_dev_alarm_handler, adapter);
cpfl_vport_map_uninit(adapter);
idpf_adapter_deinit(&adapter->base);
diff --git a/drivers/net/cpfl/cpfl_ethdev.h b/drivers/net/cpfl/cpfl_ethdev.h
index 383dbd14c6..69bf32cfbd 100644
--- a/drivers/net/cpfl/cpfl_ethdev.h
+++ b/drivers/net/cpfl/cpfl_ethdev.h
@@ -140,9 +140,12 @@ enum cpfl_itf_type {
CPFL_ITF_TYPE_REPRESENTOR,
 };
 
+TAILQ_HEAD(cpfl_flow_list, rte_flow);
+
 struct cpfl_itf {

[PATCH v10 4/9] net/cpfl: set up control path

2023-10-09 Thread Zhang, Yuying

From: Yuying Zhang 

Set up a dedicate vport with 4 pairs of control queues for flow offloading.

Signed-off-by: Yuying Zhang 
Acked-by: Qi Zhang 
---
 drivers/net/cpfl/cpfl_controlq.c | 801 +++
 drivers/net/cpfl/cpfl_controlq.h |  75 +++
 drivers/net/cpfl/cpfl_ethdev.c   | 270 +++
 drivers/net/cpfl/cpfl_ethdev.h   |  14 +
 drivers/net/cpfl/cpfl_vchnl.c| 144 ++
 drivers/net/cpfl/meson.build |   1 +
 6 files changed, 1305 insertions(+)
 create mode 100644 drivers/net/cpfl/cpfl_controlq.c
 create mode 100644 drivers/net/cpfl/cpfl_controlq.h

diff --git a/drivers/net/cpfl/cpfl_controlq.c b/drivers/net/cpfl/cpfl_controlq.c
new file mode 100644
index 00..4a925bc338
--- /dev/null
+++ b/drivers/net/cpfl/cpfl_controlq.c
@@ -0,0 +1,801 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2001-2023 Intel Corporation
+ */
+
+#include "cpfl_controlq.h"
+#include "base/idpf_controlq.h"
+#include "rte_common.h"
+
+/**
+ * cpfl_check_dma_mem_parameters - verify DMA memory params from CP
+ * @qinfo: pointer to create control queue info struct
+ *
+ * Verify that DMA parameter of each DMA memory struct is present and
+ * consistent with control queue parameters
+ */
+static inline int
+cpfl_check_dma_mem_parameters(struct cpfl_ctlq_create_info *qinfo)
+{
+   struct idpf_dma_mem *ring = &qinfo->ring_mem;
+   struct idpf_dma_mem *buf = &qinfo->buf_mem;
+
+   if (!ring->va || !ring->size)
+   return -EINVAL;
+
+   if (ring->size != qinfo->len * sizeof(struct idpf_ctlq_desc))
+   return -EINVAL;
+
+   /* no need for buffer checks for TX queues */
+   if (qinfo->type == IDPF_CTLQ_TYPE_MAILBOX_TX ||
+   qinfo->type == IDPF_CTLQ_TYPE_CONFIG_TX ||
+   qinfo->type == IDPF_CTLQ_TYPE_RDMA_TX)
+   return 0;
+
+   if (!buf->va || !buf->size)
+   return -EINVAL;
+
+   /* accommodate different types of rx ring buffer sizes */
+   if ((qinfo->type == IDPF_CTLQ_TYPE_MAILBOX_RX &&
+buf->size != CPFL_CTLQ_MAILBOX_BUFFER_SIZE * qinfo->len) ||
+   (qinfo->type == IDPF_CTLQ_TYPE_CONFIG_RX &&
+buf->size != CPFL_CFGQ_RING_LEN * CPFL_CTLQ_CFGQ_BUFFER_SIZE))
+   return -EINVAL;
+
+   return 0;
+}
+
+/**
+ * cpfl_ctlq_alloc_ring_res - store memory for descriptor ring and bufs
+ * @hw: pointer to hw struct
+ * @cq: pointer to control queue struct
+ * @qinfo: pointer to create queue info struct
+ *
+ * The CP takes care of all DMA memory allocations. Store the allocated memory
+ * information for the descriptor ring and buffers. If the memory for either 
the
+ * descriptor ring or the buffers is not allocated properly and/or inconsistent
+ * with the control queue parameters, this routine will free the memory for
+ * both the descriptors and the buffers
+ */
+int
+cpfl_ctlq_alloc_ring_res(struct idpf_hw *hw __rte_unused, struct 
idpf_ctlq_info *cq,
+struct cpfl_ctlq_create_info *qinfo)
+{
+   int ret_code = 0;
+   unsigned int elem_size;
+   int i = 0;
+
+   ret_code = cpfl_check_dma_mem_parameters(qinfo);
+   if (ret_code)
+   /* TODO: Log an error message per CP */
+   goto err;
+
+   cq->desc_ring.va = qinfo->ring_mem.va;
+   cq->desc_ring.pa = qinfo->ring_mem.pa;
+   cq->desc_ring.size = qinfo->ring_mem.size;
+
+   switch (cq->cq_type) {
+   case IDPF_CTLQ_TYPE_MAILBOX_RX:
+   case IDPF_CTLQ_TYPE_CONFIG_RX:
+   case IDPF_CTLQ_TYPE_EVENT_RX:
+   case IDPF_CTLQ_TYPE_RDMA_RX:
+   /* Only receive queues will have allocated buffers
+* during init.  CP allocates one big chunk of DMA
+* region who size is equal to ring_len * buff_size.
+* In CPFLib, the block gets broken down to multiple
+* smaller blocks that actually gets programmed in the hardware.
+*/
+
+   cq->bi.rx_buff = (struct idpf_dma_mem **)
+   idpf_calloc(hw, cq->ring_size,
+   sizeof(struct idpf_dma_mem *));
+   if (!cq->bi.rx_buff) {
+   ret_code = -ENOMEM;
+   /* TODO: Log an error message per CP */
+   goto err;
+   }
+
+   elem_size = qinfo->buf_size;
+   for (i = 0; i < cq->ring_size; i++) {
+   cq->bi.rx_buff[i] = (struct idpf_dma_mem *)idpf_calloc
+   (hw, 1,
+sizeof(struct idpf_dma_mem));
+   if (!cq->bi.rx_buff[i]) {
+   ret_code = -ENOMEM;
+   goto free_rx_buffs;
+   }
+   cq->bi.rx_buff[i]->va =
+   (uint64_t *)((char *)qinfo->buf_mem.va + (i * 
elem_size));
+

[PATCH v10 5/9] net/cpfl: add FXP low level implementation

2023-10-09 Thread Zhang, Yuying

From: Yuying Zhang 

Add low level helper functions for CPFL PMD to create / delete
rules on IPU's Flexible Packet Processor(FXP).

Signed-off-by: Yuying Zhang 
Acked-by: Qi Zhang 
---
 drivers/net/cpfl/cpfl_actions.h | 858 
 drivers/net/cpfl/cpfl_rules.c   | 127 +
 drivers/net/cpfl/cpfl_rules.h   | 306 
 drivers/net/cpfl/meson.build|   1 +
 4 files changed, 1292 insertions(+)
 create mode 100644 drivers/net/cpfl/cpfl_actions.h
 create mode 100644 drivers/net/cpfl/cpfl_rules.c
 create mode 100644 drivers/net/cpfl/cpfl_rules.h

diff --git a/drivers/net/cpfl/cpfl_actions.h b/drivers/net/cpfl/cpfl_actions.h
new file mode 100644
index 00..7b82119e39
--- /dev/null
+++ b/drivers/net/cpfl/cpfl_actions.h
@@ -0,0 +1,858 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2001-2023 Intel Corporation
+ */
+
+#ifndef _CPFL_ACTIONS_H_
+#define _CPFL_ACTIONS_H_
+
+#include "base/idpf_osdep.h"
+
+#pragma pack(1)
+
+union cpfl_action_set {
+   uint32_t data;
+
+   struct {
+   uint32_t val : 24;
+   uint32_t idx : 4;
+   uint32_t tag : 1;
+   uint32_t prec : 3;
+   } set_24b_a;
+
+   struct {
+   uint32_t val : 24;
+   uint32_t idx : 3;
+   uint32_t tag : 2;
+   uint32_t prec : 3;
+   } set_24b_b;
+
+   struct {
+   uint32_t val : 16;
+   uint32_t idx : 4;
+   uint32_t unused : 6;
+   uint32_t tag : 3;
+   uint32_t prec : 3;
+   } set_16b;
+
+   struct {
+   uint32_t val_a : 8;
+   uint32_t val_b : 8;
+   uint32_t idx_a : 4;
+   uint32_t idx_b : 4;
+   uint32_t tag : 5;
+   uint32_t prec : 3;
+   } set_8b;
+
+   struct {
+   uint32_t val : 10;
+   uint32_t ena : 10;
+   uint32_t idx : 4;
+   uint32_t tag : 5;
+   uint32_t prec : 3;
+   } set_1b;
+
+   struct {
+   uint32_t val : 24;
+   uint32_t tag : 5;
+   uint32_t prec : 3;
+   } nop;
+
+   struct {
+   uint32_t val : 24;
+   uint32_t tag : 5;
+   uint32_t prec : 3;
+   } chained_24b;
+
+   struct {
+   uint32_t val : 24;
+   uint32_t tag : 5;
+   uint32_t prec : 3;
+   } aux_flags;
+};
+
+struct cpfl_action_set_ext {
+#define CPFL_ACTION_SET_EXT_CNT 2
+   union cpfl_action_set acts[CPFL_ACTION_SET_EXT_CNT];
+};
+
+#pragma pack()
+
+/**
+ * cpfl_act_nop - Encode a NOP action
+ */
+static inline union cpfl_action_set
+cpfl_act_nop(void)
+{
+   union cpfl_action_set act;
+
+   act.data = 0;
+   return act;
+}
+
+/**
+ * cpfl_is_nop_action - Indicate if an action set is a NOP
+ */
+static inline bool
+cpfl_is_nop_action(union cpfl_action_set *act)
+{
+   return act->data == cpfl_act_nop().data;
+}
+
+#define CPFL_MAKE_MASK32(b, s) uint32_t)1 << (b)) - 1) << (s))
+
+#define CPFL_ACT_PREC_MAX  7
+#define CPFL_ACT_PREC_S29
+#define CPFL_ACT_PREC_MCPFL_MAKE_MASK32(3, CPFL_ACT_PREC_S)
+#define CPFL_ACT_PREC_SET(p)   \
+   (((uint32_t)(p) << CPFL_ACT_PREC_S) & CPFL_ACT_PREC_M)
+#define CPFL_ACT_PREC_CHECK(p) ((p) > 0 && (p) <= CPFL_ACT_PREC_MAX)
+
+#define CPFL_METADATA_ID_CNT   32  /* Max number of metadata IDs */
+#define CPFL_METADATA_STRUCT_MAX_SZ128 /* Max metadata size per ID */
+
+/***
+ * 1-Bit Actions
+ 
**/
+#define CPFL_ACT_1B_OP_S   24
+#define CPFL_ACT_1B_OP_M   CPFL_MAKE_MASK32(5, CPFL_ACT_1B_OP_S)
+#define CPFL_ACT_1B_OP ((uint32_t)(0x01) << CPFL_ACT_1B_OP_S)
+
+#define CPFL_ACT_1B_VAL_S  0
+#define CPFL_ACT_1B_VAL_M  CPFL_MAKE_MASK32(10, CPFL_ACT_1B_VAL_S)
+#define CPFL_ACT_1B_EN_S   10
+#define CPFL_ACT_1B_EN_M   CPFL_MAKE_MASK32(10, CPFL_ACT_1B_EN_S)
+#define CPFL_ACT_1B_INDEX_S20
+#define CPFL_ACT_1B_INDEX_MCPFL_MAKE_MASK32(4, CPFL_ACT_1B_INDEX_S)
+
+/* 1-bit actions currently uses only INDEX of 0 */
+#define CPFL_ACT_MAKE_1B(prec, en, val) \
+   ((CPFL_ACT_PREC_SET(prec)) | CPFL_ACT_1B_OP | \
+uint32_t)0) << CPFL_ACT_1B_INDEX_S) & CPFL_ACT_1B_INDEX_M) | \
+(((uint32_t)(en) << CPFL_ACT_1B_EN_S) & CPFL_ACT_1B_EN_M) | \
+(((uint32_t)(val) << CPFL_ACT_1B_VAL_S) & CPFL_ACT_1B_VAL_M))
+
+enum cpfl_act_1b_op {
+   CPFL_ACT_1B_OP_DROP = 0x01,
+   CPFL_ACT_1B_OP_HDR_SPLIT= 0x02,
+   CPFL_ACT_1B_OP_DIR_CHANGE   = 0x04,
+   CPFL_ACT_1B_OP_DEFER_DROP   = 0x08,
+   CPFL_ACT_1B_OP_ORIG_MIR_MD  = 0x80
+};
+
+#define CPFL_ACT_1B_COMMIT_MODE_S  4
+#define CPFL_ACT_1B_COMMIT_MODE_M  \
+

[PATCH v10 6/9] net/cpfl: implement FXP rule creation and destroying

2023-10-09 Thread Zhang, Yuying

From: Yuying Zhang 

Add a new module that implements FXP rule creation / destroying.

Signed-off-by: Yuying Zhang 
Acked-by: Qi Zhang 
---
 drivers/net/cpfl/cpfl_ethdev.c   |  31 
 drivers/net/cpfl/cpfl_ethdev.h   |   6 +
 drivers/net/cpfl/cpfl_fxp_rule.c | 263 +++
 drivers/net/cpfl/cpfl_fxp_rule.h |  68 
 drivers/net/cpfl/meson.build |   1 +
 5 files changed, 369 insertions(+)
 create mode 100644 drivers/net/cpfl/cpfl_fxp_rule.c
 create mode 100644 drivers/net/cpfl/cpfl_fxp_rule.h

diff --git a/drivers/net/cpfl/cpfl_ethdev.c b/drivers/net/cpfl/cpfl_ethdev.c
index a2bc6784d0..762fbddfe6 100644
--- a/drivers/net/cpfl/cpfl_ethdev.c
+++ b/drivers/net/cpfl/cpfl_ethdev.c
@@ -16,6 +16,7 @@
 #include 
 #include "cpfl_rxtx.h"
 #include "cpfl_flow.h"
+#include "cpfl_rules.h"
 
 #define CPFL_REPRESENTOR   "representor"
 #define CPFL_TX_SINGLE_Q   "tx_single"
@@ -1127,6 +1128,7 @@ cpfl_dev_close(struct rte_eth_dev *dev)
adapter->cur_vport_nb--;
dev->data->dev_private = NULL;
adapter->vports[vport->sw_idx] = NULL;
+   idpf_free_dma_mem(NULL, &cpfl_vport->itf.flow_dma);
rte_free(cpfl_vport);
 
return 0;
@@ -2466,6 +2468,26 @@ cpfl_p2p_queue_info_init(struct cpfl_vport *cpfl_vport,
return 0;
 }
 
+int
+cpfl_alloc_dma_mem_batch(struct idpf_dma_mem *orig_dma, struct idpf_dma_mem 
*dma, uint32_t size,
+int batch_size)
+{
+   int i;
+
+   if (!idpf_alloc_dma_mem(NULL, orig_dma, size * (1 + batch_size))) {
+   PMD_INIT_LOG(ERR, "Could not alloc dma memory");
+   return -ENOMEM;
+   }
+
+   for (i = 0; i < batch_size; i++) {
+   dma[i].va = (void *)((char *)orig_dma->va + size * (i + 1));
+   dma[i].pa = orig_dma->pa + size * (i + 1);
+   dma[i].size = size;
+   dma[i].zone = NULL;
+   }
+   return 0;
+}
+
 static int
 cpfl_dev_vport_init(struct rte_eth_dev *dev, void *init_params)
 {
@@ -2515,6 +2537,15 @@ cpfl_dev_vport_init(struct rte_eth_dev *dev, void 
*init_params)
rte_ether_addr_copy((struct rte_ether_addr *)vport->default_mac_addr,
&dev->data->mac_addrs[0]);
 
+   memset(cpfl_vport->itf.dma, 0, sizeof(cpfl_vport->itf.dma));
+   memset(cpfl_vport->itf.msg, 0, sizeof(cpfl_vport->itf.msg));
+   ret = cpfl_alloc_dma_mem_batch(&cpfl_vport->itf.flow_dma,
+  cpfl_vport->itf.dma,
+  sizeof(union cpfl_rule_cfg_pkt_record),
+  CPFL_FLOW_BATCH_SIZE);
+   if (ret < 0)
+   goto err_mac_addrs;
+
if (!adapter->base.is_rx_singleq && !adapter->base.is_tx_singleq) {
memset(&p2p_queue_grps_info, 0, sizeof(p2p_queue_grps_info));
ret = cpfl_p2p_q_grps_add(vport, &p2p_queue_grps_info, 
p2p_q_vc_out_info);
diff --git a/drivers/net/cpfl/cpfl_ethdev.h b/drivers/net/cpfl/cpfl_ethdev.h
index 7f83d170d7..8eeeac9910 100644
--- a/drivers/net/cpfl/cpfl_ethdev.h
+++ b/drivers/net/cpfl/cpfl_ethdev.h
@@ -147,10 +147,14 @@ enum cpfl_itf_type {
 
 TAILQ_HEAD(cpfl_flow_list, rte_flow);
 
+#define CPFL_FLOW_BATCH_SIZE  490
 struct cpfl_itf {
enum cpfl_itf_type type;
struct cpfl_adapter_ext *adapter;
struct cpfl_flow_list flow_list;
+   struct idpf_dma_mem flow_dma;
+   struct idpf_dma_mem dma[CPFL_FLOW_BATCH_SIZE];
+   struct idpf_ctlq_msg msg[CPFL_FLOW_BATCH_SIZE];
void *data;
 };
 
@@ -240,6 +244,8 @@ int cpfl_cc_vport_info_get(struct cpfl_adapter_ext *adapter,
 int cpfl_vc_create_ctrl_vport(struct cpfl_adapter_ext *adapter);
 int cpfl_config_ctlq_rx(struct cpfl_adapter_ext *adapter);
 int cpfl_config_ctlq_tx(struct cpfl_adapter_ext *adapter);
+int cpfl_alloc_dma_mem_batch(struct idpf_dma_mem *orig_dma, struct 
idpf_dma_mem *dma,
+uint32_t size, int batch_size);
 
 #define CPFL_DEV_TO_PCI(eth_dev)   \
RTE_DEV_TO_PCI((eth_dev)->device)
diff --git a/drivers/net/cpfl/cpfl_fxp_rule.c b/drivers/net/cpfl/cpfl_fxp_rule.c
new file mode 100644
index 00..ea65e20507
--- /dev/null
+++ b/drivers/net/cpfl/cpfl_fxp_rule.c
@@ -0,0 +1,263 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2023 Intel Corporation
+ */
+#include "cpfl_ethdev.h"
+
+#include "cpfl_fxp_rule.h"
+#include "cpfl_logs.h"
+
+#define CTLQ_SEND_RETRIES 100
+#define CTLQ_RECEIVE_RETRIES 100
+
+int
+cpfl_send_ctlq_msg(struct idpf_hw *hw, struct idpf_ctlq_info *cq, u16 
num_q_msg,
+  struct idpf_ctlq_msg q_msg[])
+{
+   struct idpf_ctlq_msg **msg_ptr_list;
+   u16 clean_count = 0;
+   int num_cleaned = 0;
+   int retries = 0;
+   int ret = 0;
+
+   msg_ptr_list = calloc(num_q_msg, sizeof(struct idpf_ctlq_msg *));
+   if (!msg_ptr_list) {
+   PMD_INIT_LOG(ERR, "no memory for cleaning ctlq");
+   ret

RE: [PATCH v5 3/3] power: amd power monitor support

2023-10-09 Thread Tummala, Sivaprasad

[AMD Official Use Only - General]

> -Original Message-
> From: David Marchand 
> Sent: Friday, October 6, 2023 1:57 PM
> To: Tummala, Sivaprasad 
> Cc: david.h...@intel.com; anatoly.bura...@intel.com; Yigit, Ferruh
> ; tho...@monjalon.net; dev@dpdk.org; Tyler Retzlaff
> 
> Subject: Re: [PATCH v5 3/3] power: amd power monitor support
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Wed, Aug 16, 2023 at 9:00 PM Sivaprasad Tummala
>  wrote:
> >
> > mwaitx allows EPYC processors to enter a implementation dependent
> > power/performance optimized state (C1 state) for a specific period or
> > until a store to the monitored address range.
> >
> > Signed-off-by: Sivaprasad Tummala 
> > Acked-by: Anatoly Burakov 
>
> This series won't apply cleanly (following MSVC related series merge) and it 
> breaks
> x86 32bits compilation.
> http://mails.dpdk.org/archives/test-report/2023-August/442809.html
Hi David,

I will send a new version of the patch on the new mainline along with the fix 
for 32bit compilation.

>
>
> --
> David Marchand

[PATCH v10 7/9] net/cpfl: adapt FXP to flow engine

2023-10-09 Thread Zhang, Yuying

From: Yuying Zhang 

Adapt FXP implementation to a flow engine

Signed-off-by: Yuying Zhang 
Acked-by: Qi Zhang 
---
 doc/guides/nics/cpfl.rst|  18 +-
 doc/guides/rel_notes/release_23_11.rst  |   1 +
 drivers/net/cpfl/cpfl_ethdev.h  |  27 ++
 drivers/net/cpfl/cpfl_flow_engine_fxp.c | 582 
 drivers/net/cpfl/meson.build|   1 +
 5 files changed, 627 insertions(+), 2 deletions(-)
 create mode 100644 drivers/net/cpfl/cpfl_flow_engine_fxp.c

diff --git a/doc/guides/nics/cpfl.rst b/doc/guides/nics/cpfl.rst
index e17347d15c..ae5487f2f6 100644
--- a/doc/guides/nics/cpfl.rst
+++ b/doc/guides/nics/cpfl.rst
@@ -197,8 +197,22 @@ low level hardware resources.
 
 * For Ubuntu, it can be installed using `apt install libjansson-dev`
 
-- run testpmd with the json file
+- run testpmd with the json file, create two vports
 
.. code-block:: console
 
-   dpdk-testpmd -c 0x3 -n 4 -a 
:af:00.6,vport=[0],flow_parser="refpkg.json" -- -i
+   dpdk-testpmd -c 0x3 -n 4 -a 
:af:00.6,vport=[0-1],flow_parser="refpkg.json" -- -i
+
+#. Create one flow to forward ETH-IPV4-TCP from I/O port to a local(CPF's) 
vport. Flow should be created on
+   vport X. Group M should match fxp module. Action port_representor Y means 
forward packet to local vport Y::
+
+   .. code-block:: console
+
+   flow create X ingress group M pattern eth dst is 00:01:00:00:03:14 / ipv4 
src is 192.168.0.1 \
+   dst is 192.168.0.2 / tcp / end actions port_representor port_id Y / end
+
+#. Send a matched packet, and it should be displayed on PMD::
+
+   .. code-block:: console
+
+   
sendp(Ether(dst='00:01:00:00:03:14')/IP(src='192.168.0.1',dst='192.168.0.2')/TCP(),iface="ens25f0")
diff --git a/doc/guides/rel_notes/release_23_11.rst 
b/doc/guides/rel_notes/release_23_11.rst
index 8536ce88f4..16cdd674d3 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -85,6 +85,7 @@ New Features
 * **Updated Intel cpfl driver.**
 
   * Added support for port representor.
+  * Added support for rte_flow.
 
 * **Updated Intel iavf driver.**
   * Added support for iavf auto-reset.
diff --git a/drivers/net/cpfl/cpfl_ethdev.h b/drivers/net/cpfl/cpfl_ethdev.h
index 8eeeac9910..efb0eb5251 100644
--- a/drivers/net/cpfl/cpfl_ethdev.h
+++ b/drivers/net/cpfl/cpfl_ethdev.h
@@ -85,6 +85,8 @@
 
 #define CPFL_RX_CFGQ_NUM   4
 #define CPFL_TX_CFGQ_NUM   4
+#define CPFL_FPCP_CFGQ_TX  0
+#define CPFL_FPCP_CFGQ_RX  1
 #define CPFL_CFGQ_NUM  8
 
 /* bit[15:14] type
@@ -219,6 +221,8 @@ struct cpfl_adapter_ext {
struct rte_hash *repr_allowlist_hash;
 
struct cpfl_flow_js_parser *flow_parser;
+   struct rte_bitmap *mod_bm;
+   void *mod_bm_mem;
 
struct cpfl_metadata meta;
 
@@ -312,4 +316,27 @@ cpfl_get_vsi_id(struct cpfl_itf *itf)
return CPFL_INVALID_HW_ID;
 }
 
+static inline struct cpfl_itf *
+cpfl_get_itf_by_port_id(uint16_t port_id)
+{
+   struct rte_eth_dev *dev;
+
+   if (port_id >= RTE_MAX_ETHPORTS) {
+   PMD_DRV_LOG(ERR, "port_id should be < %d.", RTE_MAX_ETHPORTS);
+   return NULL;
+   }
+
+   dev = &rte_eth_devices[port_id];
+   if (dev->state == RTE_ETH_DEV_UNUSED) {
+   PMD_DRV_LOG(ERR, "eth_dev[%d] is unused.", port_id);
+   return NULL;
+   }
+
+   if (!dev->data) {
+   PMD_DRV_LOG(ERR, "eth_dev[%d] data not be allocated.", port_id);
+   return NULL;
+   }
+
+   return CPFL_DEV_TO_ITF(dev);
+}
 #endif /* _CPFL_ETHDEV_H_ */
diff --git a/drivers/net/cpfl/cpfl_flow_engine_fxp.c 
b/drivers/net/cpfl/cpfl_flow_engine_fxp.c
new file mode 100644
index 00..4c7b4deb7a
--- /dev/null
+++ b/drivers/net/cpfl/cpfl_flow_engine_fxp.c
@@ -0,0 +1,582 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2022 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "cpfl_rules.h"
+#include "cpfl_logs.h"
+#include "cpfl_ethdev.h"
+#include "cpfl_flow.h"
+#include "cpfl_fxp_rule.h"
+#include "cpfl_flow_parser.h"
+
+#define CPFL_COOKIE_DEF0x1000
+#define CPFL_MOD_COOKIE_DEF0x1237561
+#define CPFL_PREC_DEF  1
+#define CPFL_PREC_SET  5
+#define CPFL_TYPE_ID   3
+#define CPFL_OFFSET0x0a
+#define CPFL_HOST_ID_DEF   0
+#define CPFL_PF_NUM_DEF0
+#define CPFL_PORT_NUM_DEF  0
+#define CPFL_RESP_REQ_DEF  2
+#define CPFL_PIN_TO_CACHE_DEF  0
+#define CPFL_CLEAR_MIRROR_1ST_STATE_DEF0
+#define CPFL_FIXED_FETCH_DEF   0
+#define CPFL_PTI_DEF   0
+#define CPFL_MOD_OBJ_SIZE_DEF  0
+#define CPFL_PIN_MOD_CONTENT_DEF   0
+
+#define CPFL_MAX_MOD_CONTENT_INDEX 256
+#define CPFL_MAX_MR_ACTION_NUM 8
+
+/* Struct used when parse detailed rule informati

[PATCH v10 8/9] net/cpfl: support flow ops on representor

2023-10-09 Thread Zhang, Yuying

From: Yuying Zhang 

Add flow ops support for representor, so representor can
create, destroy, validate and flush rules.

Signed-off-by: Yuying Zhang 
Acked-by: Qi Zhang 
---
 drivers/net/cpfl/cpfl_flow_engine_fxp.c | 74 +
 drivers/net/cpfl/cpfl_representor.c | 29 ++
 2 files changed, 103 insertions(+)

diff --git a/drivers/net/cpfl/cpfl_flow_engine_fxp.c 
b/drivers/net/cpfl/cpfl_flow_engine_fxp.c
index 4c7b4deb7a..7a3376f9f6 100644
--- a/drivers/net/cpfl/cpfl_flow_engine_fxp.c
+++ b/drivers/net/cpfl/cpfl_flow_engine_fxp.c
@@ -72,6 +72,7 @@ cpfl_fxp_create(struct rte_eth_dev *dev,
struct cpfl_adapter_ext *ad = itf->adapter;
struct cpfl_rule_info_meta *rim = meta;
struct cpfl_vport *vport;
+   struct cpfl_repr *repr;
 
if (!rim)
return ret;
@@ -82,6 +83,10 @@ cpfl_fxp_create(struct rte_eth_dev *dev,
 * Even index is tx queue and odd index is rx queue.
 */
cpq_id = vport->base.devarg_id * 2;
+   } else if (itf->type == CPFL_ITF_TYPE_REPRESENTOR) {
+   repr = (struct cpfl_repr *)itf;
+   cpq_id = ((repr->repr_id.pf_id  + repr->repr_id.vf_id) &
+ (CPFL_TX_CFGQ_NUM - 1)) * 2;
} else {
rte_flow_error_set(error, EINVAL, RTE_FLOW_ERROR_TYPE_HANDLE, 
NULL,
   "fail to find correct control queue");
@@ -121,6 +126,7 @@ cpfl_fxp_destroy(struct rte_eth_dev *dev,
struct cpfl_rule_info_meta *rim;
uint32_t i;
struct cpfl_vport *vport;
+   struct cpfl_repr *repr;
 
rim = flow->rule;
if (!rim) {
@@ -134,6 +140,10 @@ cpfl_fxp_destroy(struct rte_eth_dev *dev,
if (itf->type == CPFL_ITF_TYPE_VPORT) {
vport = (struct cpfl_vport *)itf;
cpq_id = vport->base.devarg_id * 2;
+   } else if (itf->type == CPFL_ITF_TYPE_REPRESENTOR) {
+   repr = (struct cpfl_repr *)itf;
+   cpq_id = ((repr->repr_id.pf_id  + repr->repr_id.vf_id) &
+ (CPFL_TX_CFGQ_NUM - 1)) * 2;
} else {
rte_flow_error_set(error, EINVAL, RTE_FLOW_ERROR_TYPE_HANDLE, 
NULL,
   "fail to find correct control queue");
@@ -413,6 +423,64 @@ cpfl_is_mod_action(const struct rte_flow_action actions[])
return false;
 }
 
+static bool
+cpfl_fxp_get_metadata_port(struct cpfl_itf *itf,
+  const struct rte_flow_action actions[])
+{
+   const struct rte_flow_action *action;
+   enum rte_flow_action_type action_type;
+   const struct rte_flow_action_ethdev *ethdev;
+   struct cpfl_itf *target_itf;
+   bool ret;
+
+   if (itf->type == CPFL_ITF_TYPE_VPORT) {
+   ret = cpfl_metadata_write_port_id(itf);
+   if (!ret) {
+   PMD_DRV_LOG(ERR, "fail to write port id");
+   return false;
+   }
+   }
+
+   ret = cpfl_metadata_write_sourcevsi(itf);
+   if (!ret) {
+   PMD_DRV_LOG(ERR, "fail to write source vsi id");
+   return false;
+   }
+
+   ret = cpfl_metadata_write_vsi(itf);
+   if (!ret) {
+   PMD_DRV_LOG(ERR, "fail to write vsi id");
+   return false;
+   }
+
+   if (!actions || actions->type == RTE_FLOW_ACTION_TYPE_END)
+   return false;
+
+   for (action = actions; action->type != RTE_FLOW_ACTION_TYPE_END; 
action++) {
+   action_type = action->type;
+   switch (action_type) {
+   case RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT:
+   case RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR:
+   ethdev = (const struct rte_flow_action_ethdev 
*)action->conf;
+   target_itf = cpfl_get_itf_by_port_id(ethdev->port_id);
+   if (!target_itf) {
+   PMD_DRV_LOG(ERR, "fail to get target_itf by 
port id");
+   return false;
+   }
+   ret = cpfl_metadata_write_targetvsi(target_itf);
+   if (!ret) {
+   PMD_DRV_LOG(ERR, "fail to write target vsi id");
+   return false;
+   }
+   break;
+   default:
+   continue;
+   }
+   }
+
+   return true;
+}
+
 static int
 cpfl_fxp_parse_pattern_action(struct rte_eth_dev *dev,
  const struct rte_flow_attr *attr,
@@ -429,6 +497,12 @@ cpfl_fxp_parse_pattern_action(struct rte_eth_dev *dev,
struct cpfl_rule_info_meta *rim;
int ret;
 
+   ret = cpfl_fxp_get_metadata_port(itf, actions);
+   if (!ret) {
+   PMD_DRV_LOG(ERR, "Fail to save metadata.");
+   return -EINVAL;
+   }
+
ret = cpfl_f

[PATCH v10 9/9] net/cpfl: support represented port action

2023-10-09 Thread Zhang, Yuying

From: Yuying Zhang 

Support RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT action for forwarding
packet to APF/CPF/VF representors.

Signed-off-by: Yuying Zhang 
Acked-by: Qi Zhang 
---
 drivers/net/cpfl/cpfl_flow_engine_fxp.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/net/cpfl/cpfl_flow_engine_fxp.c 
b/drivers/net/cpfl/cpfl_flow_engine_fxp.c
index 7a3376f9f6..ddede2f553 100644
--- a/drivers/net/cpfl/cpfl_flow_engine_fxp.c
+++ b/drivers/net/cpfl/cpfl_flow_engine_fxp.c
@@ -266,6 +266,7 @@ cpfl_fxp_parse_action(struct cpfl_itf *itf,
int queue_id = -1;
bool fwd_vsi = false;
bool fwd_q = false;
+   bool is_vsi;
uint32_t i;
struct cpfl_rule_info *rinfo = &rim->rules[index];
union cpfl_action_set *act_set = (void *)rinfo->act_bytes;
@@ -276,6 +277,7 @@ cpfl_fxp_parse_action(struct cpfl_itf *itf,
action_type = action->type;
switch (action_type) {
case RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR:
+   case RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT:
if (!fwd_vsi)
fwd_vsi = true;
else
@@ -294,12 +296,20 @@ cpfl_fxp_parse_action(struct cpfl_itf *itf,
queue_id = CPFL_INVALID_QUEUE_ID;
}
 
-   dev_id = cpfl_get_vsi_id(dst_itf);
+   is_vsi = (action_type == 
RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR ||
+ dst_itf->type == CPFL_ITF_TYPE_REPRESENTOR);
+   if (is_vsi)
+   dev_id = cpfl_get_vsi_id(dst_itf);
+   else
+   dev_id = cpfl_get_port_id(dst_itf);
 
if (dev_id == CPFL_INVALID_HW_ID)
goto err;
 
-   *act_set = cpfl_act_fwd_vsi(0, priority, 0, dev_id);
+   if (is_vsi)
+   *act_set = cpfl_act_fwd_vsi(0, priority, 0, 
dev_id);
+   else
+   *act_set = cpfl_act_fwd_port(0, priority, 0, 
dev_id);
act_set++;
rinfo->act_byte_len += sizeof(union cpfl_action_set);
break;
-- 
2.34.1

RE: [PATCH v16 1/8] net/ntnic: initial commit which adds register defines

2023-10-09 Thread Christian Koue Muf

On 9/29/2023 12:24 PM, Thomas Monjalon wrote:
>29/09/2023 11:46, Ferruh Yigit:
>> On 9/29/2023 10:21 AM, Christian Koue Muf wrote:
>> > On 9/21/2023 4:05 PM, Ferruh Yigit wrote:
>> >> On 9/20/2023 2:17 PM, Thomas Monjalon wrote:
>> >>> Hello,
>> >>>
>> >>> 19/09/2023 11:06, Christian Koue Muf:
>>  On 9/18/23 10:34 AM, Ferruh Yigit wrote:
>> > On 9/15/2023 7:37 PM, Morten Brørup wrote:
>> >>> From: Ferruh Yigit [mailto:ferruh.yi...@amd.com]
>> >>> Sent: Friday, 15 September 2023 17.55
>> >>>
>> >>> On 9/8/2023 5:07 PM, Mykola Kostenok wrote:
>>  From: Christian Koue Muf 
>> 
>>  The NTNIC PMD does not rely on a kernel space Napatech 
>>  driver, thus all defines related to the register layout is 
>>  part of the PMD code, which will be added in later commits.
>> 
>>  Signed-off-by: Christian Koue Muf 
>>  Reviewed-by: Mykola Kostenok 
>> 
>> >>>
>> >>> Hi Mykola, Christiam,
>> >>>
>> >>> This PMD scares me, overall it is a big drop:
>> >>> "249 files changed, 87128 insertions(+)"
>> >>>
>> >>> I think it is not possible to review all in one release cycle, 
>> >>> and it is not even possible to say if all code used or not.
>> >>>
>> >>> I can see code is already developed, and it is difficult to 
>> >>> restructure developed code, but restructure it into small 
>> >>> pieces really helps for reviews.
>> >>>
>> >>>
>> >>> Driver supports good list of features, can it be possible to 
>> >>> distribute upstream effort into multiple release.
>> >>> Starting from basic functionality and add features gradually.
>> >>> Target for this release can be providing datapath, and add 
>> >>> more if we have time in the release, what do you think?
>> >>>
>> >>> I was expecting to get only Rx/Tx in this release, not really more.
>> >>>
>> >>> I agree it may be interesting to discuss some design and check 
>> >>> whether we need more features in ethdev as part of the driver 
>> >>> upstreaming process.
>> >>>
>> >>>
>> >>> Also there are large amount of base code (HAL / FPGA code), 
>> >>> instead of adding them as a bulk, relevant ones with a feature 
>> >>> can be added with the feature patch, this eliminates dead code 
>> >>> in the base code layer, also helps user/review to understand 
>> >>> the link between driver code and base code.
>> >>>
>> >>> Yes it would be interesting to see what is really needed for the 
>> >>> basic initialization and what is linked to a specific offload or 
>> >>> configuration feature.
>> >>>
>> >>> As a maintainer, I have to do some changes across all drivers 
>> >>> sometimes, and I use git blame a lot to understand why something was 
>> >>> added.
>> >>>
>> >>>
>> >> Jumping in here with an opinion about welcoming new NIC vendors to 
>> >> the community:
>> >>
>> >> Generally, if a NIC vendor supplies a PMD for their NIC, I expect the 
>> >> vendor to take responsibility for the quality of the PMD, including 
>> >> providing a maintainer and support backporting of fixes to the PMD in 
>> >> LTS releases. This should align with the vendor's business case for 
>> >> upstreaming their driver.
>> >>
>> >> If the vendor provides one big patch series, which may be difficult 
>> >> to understand/review, the fallout mainly hits the vendor's customers 
>> >> (and thus the vendor's support organization), not the community as a 
>> >> whole.
>> >>
>> >
>> > Hi Morten,
>> >
>> > I was thinking same before making my above comment, what happens if 
>> > vendors submit as one big patch and when a problem occurs we can ask 
>> > owner to fix. Probably this makes vendor happy and makes my life (or 
>> > any other maintainer's life) easier, it is always easier to say yes.
>> >
>> >
>> > But I come up with two main reasons to ask for a rework:
>> >
>> > 1- Technically any vendor can deliver their software to their 
>> > customers via a public git repository, they don't have to 
>> > upstream to 
>> > https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fdpdk.org&c=E
>> > ,1,N 
>> > poJejuuvPdOPfcFJYtsmkQF6PVrDjGsZ8x_gi5xDrTyZokK_nM11u4ZpzHgM10J9
>> > bOLl nhoR6fFAzWtCzOhRCzVruYj520zZORv6-MjJeSC5TrGnIFL&typo=1,
>> > but upstreaming has many benefits.
>> >
>> > One of those benefits is upstreaming provides a quality assurance for 
>> > vendor's customers (that is why customer can be asking for this, as we 
>> > are having in many cases), and this quality assurance comes from 
>> > additional eyes reviewing the code and guiding vendors for the DPDK 
>> > quality standards (some vendors already doing pretty good, but new 
>> > ones sometimes requires hand-holding).
>> >
>> > If driver is one big patch series, it is practically not possible to 
>> > review

[PATCH v10 0/9] add rte flow support for cpfl

2023-10-09 Thread Zhang, Yuying

From: Yuying Zhang 

This patchset add rte flow support for cpfl driver.
It depends on the following patch set:
http://patchwork.dpdk.org/project/dpdk/cover/20230912173039.1612287-1-beilei.x...@intel.com/

Wenjing Qiao (2):
  net/cpfl: parse flow offloading hint from JSON
  net/cpfl: build action mapping rules from JSON

Yuying Zhang (7):
  net/cpfl: set up flow offloading skeleton
  net/cpfl: set up control path
  net/cpfl: add FXP low level implementation
  net/cpfl: implement FXP rule creation and destroying
  net/cpfl: adapt FXP to flow engine
  net/cpfl: support flow ops on representor
  net/cpfl: support represented port action
---
v10:
* fix ci build issue

v9:
* refine rx queue message process function

v8:
* fix compile issues
* refine document and separate patch with different features

v7:
* refine commit log
* fix compile issues

v6:
* use existed jansson instead of json-c library
* refine "add FXP low level implementation"

V5:
* Add input validation for some functions

 doc/guides/nics/cpfl.rst|   52 +
 doc/guides/rel_notes/release_23_11.rst  |1 +
 drivers/net/cpfl/cpfl_actions.h |  858 +++
 drivers/net/cpfl/cpfl_controlq.c|  801 ++
 drivers/net/cpfl/cpfl_controlq.h|   75 +
 drivers/net/cpfl/cpfl_ethdev.c  |  392 -
 drivers/net/cpfl/cpfl_ethdev.h  |  128 ++
 drivers/net/cpfl/cpfl_flow.c|  339 +
 drivers/net/cpfl/cpfl_flow.h|   85 ++
 drivers/net/cpfl/cpfl_flow_engine_fxp.c |  666 
 drivers/net/cpfl/cpfl_flow_parser.c | 1835 +++
 drivers/net/cpfl/cpfl_flow_parser.h |  268 
 drivers/net/cpfl/cpfl_fxp_rule.c|  263 
 drivers/net/cpfl/cpfl_fxp_rule.h|   68 +
 drivers/net/cpfl/cpfl_representor.c |   29 +
 drivers/net/cpfl/cpfl_rules.c   |  127 ++
 drivers/net/cpfl/cpfl_rules.h   |  306 
 drivers/net/cpfl/cpfl_vchnl.c   |  144 ++
 drivers/net/cpfl/meson.build|   12 +
 19 files changed, 6448 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/cpfl/cpfl_actions.h
 create mode 100644 drivers/net/cpfl/cpfl_controlq.c
 create mode 100644 drivers/net/cpfl/cpfl_controlq.h
 create mode 100644 drivers/net/cpfl/cpfl_flow.c
 create mode 100644 drivers/net/cpfl/cpfl_flow.h
 create mode 100644 drivers/net/cpfl/cpfl_flow_engine_fxp.c
 create mode 100644 drivers/net/cpfl/cpfl_flow_parser.c
 create mode 100644 drivers/net/cpfl/cpfl_flow_parser.h
 create mode 100644 drivers/net/cpfl/cpfl_fxp_rule.c
 create mode 100644 drivers/net/cpfl/cpfl_fxp_rule.h
 create mode 100644 drivers/net/cpfl/cpfl_rules.c
 create mode 100644 drivers/net/cpfl/cpfl_rules.h

-- 
2.34.1

[PATCH v10 1/9] net/cpfl: parse flow offloading hint from JSON

2023-10-09 Thread Zhang, Yuying

From: Wenjing Qiao 

Add devargs "flow_parser" to specify the path of a JSON
configure file. The cpfl PMD use the JSON configuration file
to translate rte_flow tokens into low level hardware
representation.

Example:
-a ca:00.0,flow_parser="refpkg.json"

jansson library is used to parse JSON syntax.

In this patch, The parser only builds rules which maps from
a set of rte_flow items to hardware representations. The rules
that maps from rte_flow actions will be enabled in a separate
patch to avoid a big size patch.

Note, the JSON configuration file is provided by the hardware vendor
and is intended to work exclusively with a specific P4 pipeline
configuration, which must be compiled and programmed into the hardware.

The format of the JSON file strictly follows the internal specifications
of the hardware vendor and is not meant to be modified directly by
users.

Signed-off-by: Wenjing Qiao 
Acked-by: Qi Zhang 
---
 doc/guides/nics/cpfl.rst|   38 +
 drivers/net/cpfl/cpfl_ethdev.c  |   38 +-
 drivers/net/cpfl/cpfl_ethdev.h  |   76 ++
 drivers/net/cpfl/cpfl_flow_parser.c | 1299 +++
 drivers/net/cpfl/cpfl_flow_parser.h |  168 
 drivers/net/cpfl/meson.build|7 +
 6 files changed, 1625 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/cpfl/cpfl_flow_parser.c
 create mode 100644 drivers/net/cpfl/cpfl_flow_parser.h

diff --git a/doc/guides/nics/cpfl.rst b/doc/guides/nics/cpfl.rst
index 83a18c3f2e..e17347d15c 100644
--- a/doc/guides/nics/cpfl.rst
+++ b/doc/guides/nics/cpfl.rst
@@ -128,12 +128,32 @@ Runtime Configuration
 
 -a BDF,representor=vf[0-3],representor=c1pf1
 
+- ``flow_parser`` (default ``not enabled``)
+
+  The cpfl PMD supports utilizing a JSON config file to translate rte_flow 
tokens into
+  low-level hardware resources.
+
+  The JSON configuration file is provided by the hardware vendor and is 
intended to work
+  exclusively with a specific P4 pipeline configuration, which must be 
compiled and programmed
+  into the hardware.
+
+  The format of the JSON file strictly follows the internal specifications of 
the hardware
+  vendor and is not meant to be modified directly by users.
+
+  Using the ``devargs`` option ``flow_parser`` the user can specify the path
+  of a json file, for example::
+
+-a ca:00.0,flow_parser="refpkg.json"
+
+  Then the PMD will load json file for device ``ca:00.0``.
+  The parameter is optional.
 
 Driver compilation and testing
 --
 
 Refer to the document :doc:`build_and_test` for details.
 
+The jansson library must be installed to use rte_flow.
 
 Features
 
@@ -164,3 +184,21 @@ Hairpin queue
 E2100 Series can loopback packets from RX port to TX port.
 This feature is called port-to-port or hairpin.
 Currently, the PMD only supports single port hairpin.
+
+Rte_flow
+~
+
+PMD uses a json file to direct CPF PMD to parse rte_flow tokens into
+low level hardware resources.
+
+- Required Libraries
+
+  * jansson
+
+* For Ubuntu, it can be installed using `apt install libjansson-dev`
+
+- run testpmd with the json file
+
+   .. code-block:: console
+
+   dpdk-testpmd -c 0x3 -n 4 -a 
:af:00.6,vport=[0],flow_parser="refpkg.json" -- -i
diff --git a/drivers/net/cpfl/cpfl_ethdev.c b/drivers/net/cpfl/cpfl_ethdev.c
index 189072ab33..1745f703c8 100644
--- a/drivers/net/cpfl/cpfl_ethdev.c
+++ b/drivers/net/cpfl/cpfl_ethdev.c
@@ -21,6 +21,10 @@
 #define CPFL_RX_SINGLE_Q   "rx_single"
 #define CPFL_VPORT "vport"
 
+#ifdef RTE_HAS_JANSSON
+#define CPFL_FLOW_PARSER   "flow_parser"
+#endif
+
 rte_spinlock_t cpfl_adapter_lock;
 /* A list for all adapters, one adapter matches one PCI device */
 struct cpfl_adapter_list cpfl_adapter_list;
@@ -31,6 +35,9 @@ static const char * const cpfl_valid_args_first[] = {
CPFL_TX_SINGLE_Q,
CPFL_RX_SINGLE_Q,
CPFL_VPORT,
+#ifdef RTE_HAS_JANSSON
+   CPFL_FLOW_PARSER,
+#endif
NULL
 };
 
@@ -1537,6 +1544,24 @@ parse_repr(const char *key __rte_unused, const char 
*value, void *args)
return 0;
 }
 
+#ifdef RTE_HAS_JANSSON
+static int
+parse_file(const char *key, const char *value, void *args)
+{
+   char *name = args;
+
+   if (strlen(value) > CPFL_FLOW_FILE_LEN - 1) {
+   PMD_DRV_LOG(ERR, "file path(%s) is too long.", value);
+   return -1;
+   }
+
+   PMD_DRV_LOG(DEBUG, "value:\"%s\" for key:\"%s\"", value, key);
+   strlcpy(name, value, CPFL_FLOW_FILE_LEN);
+
+   return 0;
+}
+#endif
+
 static int
 cpfl_parse_devargs(struct rte_pci_device *pci_dev, struct cpfl_adapter_ext 
*adapter, bool first)
 {
@@ -1585,7 +1610,18 @@ cpfl_parse_devargs(struct rte_pci_device *pci_dev, 
struct cpfl_adapter_ext *adap
 &adapter->base.is_rx_singleq);
if (ret != 0)
goto fail;
-
+#ifdef RTE_HAS_JANSSON
+   if (rte_kvargs_get(kvlist, CPFL_FLOW_PARSER)) {
+   ret = r

[PATCH v10 2/9] net/cpfl: build action mapping rules from JSON

2023-10-09 Thread Zhang, Yuying

From: Wenjing Qiao 

Build rules that maps from an rte_flow action vxlan_encap or
vxlan_decap to hardware representations.

Signed-off-by: Wenjing Qiao 
Acked-by: Qi Zhang 
---
 drivers/net/cpfl/cpfl_flow_parser.c | 538 +++-
 drivers/net/cpfl/cpfl_flow_parser.h | 100 ++
 2 files changed, 637 insertions(+), 1 deletion(-)

diff --git a/drivers/net/cpfl/cpfl_flow_parser.c 
b/drivers/net/cpfl/cpfl_flow_parser.c
index a5fff5a857..0e623494a2 100644
--- a/drivers/net/cpfl/cpfl_flow_parser.c
+++ b/drivers/net/cpfl/cpfl_flow_parser.c
@@ -28,6 +28,18 @@ cpfl_get_item_type_by_str(const char *type)
return RTE_FLOW_ITEM_TYPE_VOID;
 }
 
+static enum rte_flow_action_type
+cpfl_get_action_type_by_str(const char *type)
+{
+   if (strcmp(type, "vxlan_encap") == 0)
+   return RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP;
+   else if (strcmp(type, "vxlan_decap") == 0)
+   return RTE_FLOW_ACTION_TYPE_VXLAN_DECAP;
+
+   PMD_DRV_LOG(ERR, "Not support this type: %s.", type);
+   return RTE_FLOW_ACTION_TYPE_VOID;
+}
+
 static const char *
 cpfl_json_t_to_string(json_t *object, const char *name)
 {
@@ -46,6 +58,29 @@ cpfl_json_t_to_string(json_t *object, const char *name)
return json_string_value(subobject);
 }
 
+static int
+cpfl_json_t_to_int(json_t *object, const char *name, int *value)
+{
+   json_t *subobject;
+
+   if (!object) {
+   PMD_DRV_LOG(ERR, "object doesn't exist.");
+   return -EINVAL;
+   }
+   subobject = json_object_get(object, name);
+   if (!subobject) {
+   PMD_DRV_LOG(ERR, "%s doesn't exist.", name);
+   return -EINVAL;
+   }
+   if (!json_is_integer(subobject)) {
+   PMD_DRV_LOG(ERR, "%s is not an integer.", name);
+   return -EINVAL;
+   }
+   *value = (int)json_integer_value(subobject);
+
+   return 0;
+}
+
 static int
 cpfl_json_t_to_uint16(json_t *object, const char *name, uint16_t *value)
 {
@@ -518,6 +553,228 @@ cpfl_flow_js_pattern_rule(json_t *ob_root, struct 
cpfl_flow_js_parser *parser)
return -EINVAL;
 }
 
+static int
+cpfl_flow_js_mr_key(json_t *ob_mr_keys, struct cpfl_flow_js_mr_key *js_mr_key)
+{
+   int len, i;
+
+   len = json_array_size(ob_mr_keys);
+   if (len == 0)
+   return 0;
+   js_mr_key->actions = rte_malloc(NULL, sizeof(struct 
cpfl_flow_js_mr_key_action) * len, 0);
+   if (!js_mr_key->actions) {
+   PMD_DRV_LOG(ERR, "Failed to alloc memory.");
+   return -ENOMEM;
+   }
+   js_mr_key->actions_size = len;
+   for (i = 0; i < len; i++) {
+   json_t *object, *ob_data;
+   const char *type;
+   enum rte_flow_action_type act_type;
+
+   object = json_array_get(ob_mr_keys, i);
+   /* mr->key->actions->type */
+   type = cpfl_json_t_to_string(object, "type");
+   if (!type) {
+   PMD_DRV_LOG(ERR, "Can not parse string 'type'.");
+   goto err;
+   }
+   act_type = cpfl_get_action_type_by_str(type);
+   if (act_type == RTE_FLOW_ACTION_TYPE_VOID)
+   goto err;
+   js_mr_key->actions[i].type = act_type;
+   /* mr->key->actions->data */
+   ob_data = json_object_get(object, "data");
+   if (js_mr_key->actions[i].type == 
RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP) {
+   json_t *ob_protos;
+   int proto_size, j;
+   struct cpfl_flow_js_mr_key_action_vxlan_encap *encap;
+
+   ob_protos = json_object_get(ob_data, "protocols");
+   encap = &js_mr_key->actions[i].encap;
+   if (!ob_protos) {
+   encap->proto_size = 0;
+   continue;
+   }
+   proto_size = json_array_size(ob_protos);
+   encap->proto_size = proto_size;
+   for (j = 0; j < proto_size; j++) {
+   const char *s;
+   json_t *subobject;
+   enum rte_flow_item_type proto_type;
+
+   subobject = json_array_get(ob_protos, j);
+   s = json_string_value(subobject);
+   proto_type = cpfl_get_item_type_by_str(s);
+   if (proto_type == RTE_FLOW_ITEM_TYPE_VOID) {
+   PMD_DRV_LOG(ERR, "parse VXLAN_ENCAP 
failed.");
+   goto err;
+   }
+   encap->protocols[j] = proto_type;
+   }
+   } else if (js_mr_key->actions[i].type != 
RTE_FLOW_ACTION_TYPE_VXLAN_DECAP) {
+

[PATCH v10 3/9] net/cpfl: set up flow offloading skeleton

2023-10-09 Thread Zhang, Yuying

From: Yuying Zhang 

Set up the rte_flow backend skeleton. Introduce the framework
to support different engines as rte_flow backend. Bridge rte_flow
driver API to flow engines.

Signed-off-by: Yuying Zhang 
Acked-by: Qi Zhang 
---
 drivers/net/cpfl/cpfl_ethdev.c |  53 ++
 drivers/net/cpfl/cpfl_ethdev.h |   5 +
 drivers/net/cpfl/cpfl_flow.c   | 339 +
 drivers/net/cpfl/cpfl_flow.h   |  85 +
 drivers/net/cpfl/meson.build   |   1 +
 5 files changed, 483 insertions(+)
 create mode 100644 drivers/net/cpfl/cpfl_flow.c
 create mode 100644 drivers/net/cpfl/cpfl_flow.h

diff --git a/drivers/net/cpfl/cpfl_ethdev.c b/drivers/net/cpfl/cpfl_ethdev.c
index 1745f703c8..c350728861 100644
--- a/drivers/net/cpfl/cpfl_ethdev.c
+++ b/drivers/net/cpfl/cpfl_ethdev.c
@@ -15,6 +15,7 @@
 #include "cpfl_ethdev.h"
 #include 
 #include "cpfl_rxtx.h"
+#include "cpfl_flow.h"
 
 #define CPFL_REPRESENTOR   "representor"
 #define CPFL_TX_SINGLE_Q   "tx_single"
@@ -1074,6 +1075,19 @@ cpfl_dev_stop(struct rte_eth_dev *dev)
return 0;
 }
 
+static void
+cpfl_flow_free(struct cpfl_vport *vport)
+{
+   struct rte_flow *p_flow;
+
+   while ((p_flow = TAILQ_FIRST(&vport->itf.flow_list))) {
+   TAILQ_REMOVE(&vport->itf.flow_list, p_flow, next);
+   if (p_flow->engine->free)
+   p_flow->engine->free(p_flow);
+   rte_free(p_flow);
+   }
+}
+
 static int
 cpfl_p2p_queue_grps_del(struct idpf_vport *vport)
 {
@@ -1105,6 +1119,7 @@ cpfl_dev_close(struct rte_eth_dev *dev)
if (!adapter->base.is_rx_singleq && !adapter->base.is_tx_singleq)
cpfl_p2p_queue_grps_del(vport);
 
+   cpfl_flow_free(cpfl_vport);
idpf_vport_deinit(vport);
rte_free(cpfl_vport->p2p_q_chunks_info);
 
@@ -1117,6 +1132,29 @@ cpfl_dev_close(struct rte_eth_dev *dev)
return 0;
 }
 
+static int
+cpfl_dev_flow_ops_get(struct rte_eth_dev *dev,
+ const struct rte_flow_ops **ops)
+{
+   struct cpfl_itf *itf;
+
+   if (!dev)
+   return -EINVAL;
+
+   itf = CPFL_DEV_TO_ITF(dev);
+
+   /* only vport support rte_flow */
+   if (itf->type != CPFL_ITF_TYPE_VPORT)
+   return -ENOTSUP;
+#ifdef RTE_HAS_JANSSON
+   *ops = &cpfl_flow_ops;
+#else
+   *ops = NULL;
+   PMD_DRV_LOG(NOTICE, "not support rte_flow, please install json-c 
library.");
+#endif
+   return 0;
+}
+
 static int
 cpfl_hairpin_get_peer_ports(struct rte_eth_dev *dev, uint16_t *peer_ports,
size_t len, uint32_t tx)
@@ -1318,6 +1356,7 @@ static const struct eth_dev_ops cpfl_eth_dev_ops = {
.xstats_get = cpfl_dev_xstats_get,
.xstats_get_names   = cpfl_dev_xstats_get_names,
.xstats_reset   = cpfl_dev_xstats_reset,
+   .flow_ops_get   = cpfl_dev_flow_ops_get,
.hairpin_cap_get= cpfl_hairpin_cap_get,
.rx_hairpin_queue_setup = cpfl_rx_hairpin_queue_setup,
.tx_hairpin_queue_setup = cpfl_tx_hairpin_queue_setup,
@@ -2021,6 +2060,13 @@ cpfl_adapter_ext_init(struct rte_pci_device *pci_dev, 
struct cpfl_adapter_ext *a
goto err_vports_alloc;
}
 
+#ifdef RTE_HAS_JANSSON
+   ret = cpfl_flow_init(adapter);
+   if (ret) {
+   PMD_INIT_LOG(ERR, "Failed to init flow module");
+   goto err_flow_init;
+   }
+#endif
adapter->cur_vports = 0;
adapter->cur_vport_nb = 0;
 
@@ -2028,6 +2074,9 @@ cpfl_adapter_ext_init(struct rte_pci_device *pci_dev, 
struct cpfl_adapter_ext *a
 
return ret;
 
+#ifdef RTE_HAS_JANSSON
+err_flow_init:
+#endif
 err_vports_alloc:
rte_eal_alarm_cancel(cpfl_dev_alarm_handler, adapter);
cpfl_repr_allowlist_uninit(adapter);
@@ -2182,6 +2231,7 @@ cpfl_dev_vport_init(struct rte_eth_dev *dev, void 
*init_params)
cpfl_vport->itf.type = CPFL_ITF_TYPE_VPORT;
cpfl_vport->itf.adapter = adapter;
cpfl_vport->itf.data = dev->data;
+   TAILQ_INIT(&cpfl_vport->itf.flow_list);
adapter->vports[param->idx] = cpfl_vport;
adapter->cur_vports |= RTE_BIT32(param->devarg_id);
adapter->cur_vport_nb++;
@@ -2262,6 +2312,9 @@ cpfl_find_adapter_ext(struct rte_pci_device *pci_dev)
 static void
 cpfl_adapter_ext_deinit(struct cpfl_adapter_ext *adapter)
 {
+#ifdef RTE_HAS_JANSSON
+   cpfl_flow_uninit(adapter);
+#endif
rte_eal_alarm_cancel(cpfl_dev_alarm_handler, adapter);
cpfl_vport_map_uninit(adapter);
idpf_adapter_deinit(&adapter->base);
diff --git a/drivers/net/cpfl/cpfl_ethdev.h b/drivers/net/cpfl/cpfl_ethdev.h
index 383dbd14c6..69bf32cfbd 100644
--- a/drivers/net/cpfl/cpfl_ethdev.h
+++ b/drivers/net/cpfl/cpfl_ethdev.h
@@ -140,9 +140,12 @@ enum cpfl_itf_type {
CPFL_ITF_TYPE_REPRESENTOR,
 };
 
+TAILQ_HEAD(cpfl_flow_list, rte_flow);
+
 struct cpfl_itf {

[PATCH v10 4/9] net/cpfl: set up control path

2023-10-09 Thread Zhang, Yuying

From: Yuying Zhang 

Set up a dedicate vport with 4 pairs of control queues for flow offloading.

Signed-off-by: Yuying Zhang 
Acked-by: Qi Zhang 
---
 drivers/net/cpfl/cpfl_controlq.c | 801 +++
 drivers/net/cpfl/cpfl_controlq.h |  75 +++
 drivers/net/cpfl/cpfl_ethdev.c   | 270 +++
 drivers/net/cpfl/cpfl_ethdev.h   |  14 +
 drivers/net/cpfl/cpfl_vchnl.c| 144 ++
 drivers/net/cpfl/meson.build |   1 +
 6 files changed, 1305 insertions(+)
 create mode 100644 drivers/net/cpfl/cpfl_controlq.c
 create mode 100644 drivers/net/cpfl/cpfl_controlq.h

diff --git a/drivers/net/cpfl/cpfl_controlq.c b/drivers/net/cpfl/cpfl_controlq.c
new file mode 100644
index 00..4a925bc338
--- /dev/null
+++ b/drivers/net/cpfl/cpfl_controlq.c
@@ -0,0 +1,801 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2001-2023 Intel Corporation
+ */
+
+#include "cpfl_controlq.h"
+#include "base/idpf_controlq.h"
+#include "rte_common.h"
+
+/**
+ * cpfl_check_dma_mem_parameters - verify DMA memory params from CP
+ * @qinfo: pointer to create control queue info struct
+ *
+ * Verify that DMA parameter of each DMA memory struct is present and
+ * consistent with control queue parameters
+ */
+static inline int
+cpfl_check_dma_mem_parameters(struct cpfl_ctlq_create_info *qinfo)
+{
+   struct idpf_dma_mem *ring = &qinfo->ring_mem;
+   struct idpf_dma_mem *buf = &qinfo->buf_mem;
+
+   if (!ring->va || !ring->size)
+   return -EINVAL;
+
+   if (ring->size != qinfo->len * sizeof(struct idpf_ctlq_desc))
+   return -EINVAL;
+
+   /* no need for buffer checks for TX queues */
+   if (qinfo->type == IDPF_CTLQ_TYPE_MAILBOX_TX ||
+   qinfo->type == IDPF_CTLQ_TYPE_CONFIG_TX ||
+   qinfo->type == IDPF_CTLQ_TYPE_RDMA_TX)
+   return 0;
+
+   if (!buf->va || !buf->size)
+   return -EINVAL;
+
+   /* accommodate different types of rx ring buffer sizes */
+   if ((qinfo->type == IDPF_CTLQ_TYPE_MAILBOX_RX &&
+buf->size != CPFL_CTLQ_MAILBOX_BUFFER_SIZE * qinfo->len) ||
+   (qinfo->type == IDPF_CTLQ_TYPE_CONFIG_RX &&
+buf->size != CPFL_CFGQ_RING_LEN * CPFL_CTLQ_CFGQ_BUFFER_SIZE))
+   return -EINVAL;
+
+   return 0;
+}
+
+/**
+ * cpfl_ctlq_alloc_ring_res - store memory for descriptor ring and bufs
+ * @hw: pointer to hw struct
+ * @cq: pointer to control queue struct
+ * @qinfo: pointer to create queue info struct
+ *
+ * The CP takes care of all DMA memory allocations. Store the allocated memory
+ * information for the descriptor ring and buffers. If the memory for either 
the
+ * descriptor ring or the buffers is not allocated properly and/or inconsistent
+ * with the control queue parameters, this routine will free the memory for
+ * both the descriptors and the buffers
+ */
+int
+cpfl_ctlq_alloc_ring_res(struct idpf_hw *hw __rte_unused, struct 
idpf_ctlq_info *cq,
+struct cpfl_ctlq_create_info *qinfo)
+{
+   int ret_code = 0;
+   unsigned int elem_size;
+   int i = 0;
+
+   ret_code = cpfl_check_dma_mem_parameters(qinfo);
+   if (ret_code)
+   /* TODO: Log an error message per CP */
+   goto err;
+
+   cq->desc_ring.va = qinfo->ring_mem.va;
+   cq->desc_ring.pa = qinfo->ring_mem.pa;
+   cq->desc_ring.size = qinfo->ring_mem.size;
+
+   switch (cq->cq_type) {
+   case IDPF_CTLQ_TYPE_MAILBOX_RX:
+   case IDPF_CTLQ_TYPE_CONFIG_RX:
+   case IDPF_CTLQ_TYPE_EVENT_RX:
+   case IDPF_CTLQ_TYPE_RDMA_RX:
+   /* Only receive queues will have allocated buffers
+* during init.  CP allocates one big chunk of DMA
+* region who size is equal to ring_len * buff_size.
+* In CPFLib, the block gets broken down to multiple
+* smaller blocks that actually gets programmed in the hardware.
+*/
+
+   cq->bi.rx_buff = (struct idpf_dma_mem **)
+   idpf_calloc(hw, cq->ring_size,
+   sizeof(struct idpf_dma_mem *));
+   if (!cq->bi.rx_buff) {
+   ret_code = -ENOMEM;
+   /* TODO: Log an error message per CP */
+   goto err;
+   }
+
+   elem_size = qinfo->buf_size;
+   for (i = 0; i < cq->ring_size; i++) {
+   cq->bi.rx_buff[i] = (struct idpf_dma_mem *)idpf_calloc
+   (hw, 1,
+sizeof(struct idpf_dma_mem));
+   if (!cq->bi.rx_buff[i]) {
+   ret_code = -ENOMEM;
+   goto free_rx_buffs;
+   }
+   cq->bi.rx_buff[i]->va =
+   (uint64_t *)((char *)qinfo->buf_mem.va + (i * 
elem_size));
+

[PATCH v10 5/9] net/cpfl: add FXP low level implementation

2023-10-09 Thread Zhang, Yuying

From: Yuying Zhang 

Add low level helper functions for CPFL PMD to create / delete
rules on IPU's Flexible Packet Processor(FXP).

Signed-off-by: Yuying Zhang 
Acked-by: Qi Zhang 
---
 drivers/net/cpfl/cpfl_actions.h | 858 
 drivers/net/cpfl/cpfl_rules.c   | 127 +
 drivers/net/cpfl/cpfl_rules.h   | 306 
 drivers/net/cpfl/meson.build|   1 +
 4 files changed, 1292 insertions(+)
 create mode 100644 drivers/net/cpfl/cpfl_actions.h
 create mode 100644 drivers/net/cpfl/cpfl_rules.c
 create mode 100644 drivers/net/cpfl/cpfl_rules.h

diff --git a/drivers/net/cpfl/cpfl_actions.h b/drivers/net/cpfl/cpfl_actions.h
new file mode 100644
index 00..7b82119e39
--- /dev/null
+++ b/drivers/net/cpfl/cpfl_actions.h
@@ -0,0 +1,858 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2001-2023 Intel Corporation
+ */
+
+#ifndef _CPFL_ACTIONS_H_
+#define _CPFL_ACTIONS_H_
+
+#include "base/idpf_osdep.h"
+
+#pragma pack(1)
+
+union cpfl_action_set {
+   uint32_t data;
+
+   struct {
+   uint32_t val : 24;
+   uint32_t idx : 4;
+   uint32_t tag : 1;
+   uint32_t prec : 3;
+   } set_24b_a;
+
+   struct {
+   uint32_t val : 24;
+   uint32_t idx : 3;
+   uint32_t tag : 2;
+   uint32_t prec : 3;
+   } set_24b_b;
+
+   struct {
+   uint32_t val : 16;
+   uint32_t idx : 4;
+   uint32_t unused : 6;
+   uint32_t tag : 3;
+   uint32_t prec : 3;
+   } set_16b;
+
+   struct {
+   uint32_t val_a : 8;
+   uint32_t val_b : 8;
+   uint32_t idx_a : 4;
+   uint32_t idx_b : 4;
+   uint32_t tag : 5;
+   uint32_t prec : 3;
+   } set_8b;
+
+   struct {
+   uint32_t val : 10;
+   uint32_t ena : 10;
+   uint32_t idx : 4;
+   uint32_t tag : 5;
+   uint32_t prec : 3;
+   } set_1b;
+
+   struct {
+   uint32_t val : 24;
+   uint32_t tag : 5;
+   uint32_t prec : 3;
+   } nop;
+
+   struct {
+   uint32_t val : 24;
+   uint32_t tag : 5;
+   uint32_t prec : 3;
+   } chained_24b;
+
+   struct {
+   uint32_t val : 24;
+   uint32_t tag : 5;
+   uint32_t prec : 3;
+   } aux_flags;
+};
+
+struct cpfl_action_set_ext {
+#define CPFL_ACTION_SET_EXT_CNT 2
+   union cpfl_action_set acts[CPFL_ACTION_SET_EXT_CNT];
+};
+
+#pragma pack()
+
+/**
+ * cpfl_act_nop - Encode a NOP action
+ */
+static inline union cpfl_action_set
+cpfl_act_nop(void)
+{
+   union cpfl_action_set act;
+
+   act.data = 0;
+   return act;
+}
+
+/**
+ * cpfl_is_nop_action - Indicate if an action set is a NOP
+ */
+static inline bool
+cpfl_is_nop_action(union cpfl_action_set *act)
+{
+   return act->data == cpfl_act_nop().data;
+}
+
+#define CPFL_MAKE_MASK32(b, s) uint32_t)1 << (b)) - 1) << (s))
+
+#define CPFL_ACT_PREC_MAX  7
+#define CPFL_ACT_PREC_S29
+#define CPFL_ACT_PREC_MCPFL_MAKE_MASK32(3, CPFL_ACT_PREC_S)
+#define CPFL_ACT_PREC_SET(p)   \
+   (((uint32_t)(p) << CPFL_ACT_PREC_S) & CPFL_ACT_PREC_M)
+#define CPFL_ACT_PREC_CHECK(p) ((p) > 0 && (p) <= CPFL_ACT_PREC_MAX)
+
+#define CPFL_METADATA_ID_CNT   32  /* Max number of metadata IDs */
+#define CPFL_METADATA_STRUCT_MAX_SZ128 /* Max metadata size per ID */
+
+/***
+ * 1-Bit Actions
+ 
**/
+#define CPFL_ACT_1B_OP_S   24
+#define CPFL_ACT_1B_OP_M   CPFL_MAKE_MASK32(5, CPFL_ACT_1B_OP_S)
+#define CPFL_ACT_1B_OP ((uint32_t)(0x01) << CPFL_ACT_1B_OP_S)
+
+#define CPFL_ACT_1B_VAL_S  0
+#define CPFL_ACT_1B_VAL_M  CPFL_MAKE_MASK32(10, CPFL_ACT_1B_VAL_S)
+#define CPFL_ACT_1B_EN_S   10
+#define CPFL_ACT_1B_EN_M   CPFL_MAKE_MASK32(10, CPFL_ACT_1B_EN_S)
+#define CPFL_ACT_1B_INDEX_S20
+#define CPFL_ACT_1B_INDEX_MCPFL_MAKE_MASK32(4, CPFL_ACT_1B_INDEX_S)
+
+/* 1-bit actions currently uses only INDEX of 0 */
+#define CPFL_ACT_MAKE_1B(prec, en, val) \
+   ((CPFL_ACT_PREC_SET(prec)) | CPFL_ACT_1B_OP | \
+uint32_t)0) << CPFL_ACT_1B_INDEX_S) & CPFL_ACT_1B_INDEX_M) | \
+(((uint32_t)(en) << CPFL_ACT_1B_EN_S) & CPFL_ACT_1B_EN_M) | \
+(((uint32_t)(val) << CPFL_ACT_1B_VAL_S) & CPFL_ACT_1B_VAL_M))
+
+enum cpfl_act_1b_op {
+   CPFL_ACT_1B_OP_DROP = 0x01,
+   CPFL_ACT_1B_OP_HDR_SPLIT= 0x02,
+   CPFL_ACT_1B_OP_DIR_CHANGE   = 0x04,
+   CPFL_ACT_1B_OP_DEFER_DROP   = 0x08,
+   CPFL_ACT_1B_OP_ORIG_MIR_MD  = 0x80
+};
+
+#define CPFL_ACT_1B_COMMIT_MODE_S  4
+#define CPFL_ACT_1B_COMMIT_MODE_M  \
+

[PATCH v10 6/9] net/cpfl: implement FXP rule creation and destroying

2023-10-09 Thread Zhang, Yuying

From: Yuying Zhang 

Add a new module that implements FXP rule creation / destroying.

Signed-off-by: Yuying Zhang 
Acked-by: Qi Zhang 
---
 drivers/net/cpfl/cpfl_ethdev.c   |  31 
 drivers/net/cpfl/cpfl_ethdev.h   |   6 +
 drivers/net/cpfl/cpfl_fxp_rule.c | 263 +++
 drivers/net/cpfl/cpfl_fxp_rule.h |  68 
 drivers/net/cpfl/meson.build |   1 +
 5 files changed, 369 insertions(+)
 create mode 100644 drivers/net/cpfl/cpfl_fxp_rule.c
 create mode 100644 drivers/net/cpfl/cpfl_fxp_rule.h

diff --git a/drivers/net/cpfl/cpfl_ethdev.c b/drivers/net/cpfl/cpfl_ethdev.c
index a2bc6784d0..762fbddfe6 100644
--- a/drivers/net/cpfl/cpfl_ethdev.c
+++ b/drivers/net/cpfl/cpfl_ethdev.c
@@ -16,6 +16,7 @@
 #include 
 #include "cpfl_rxtx.h"
 #include "cpfl_flow.h"
+#include "cpfl_rules.h"
 
 #define CPFL_REPRESENTOR   "representor"
 #define CPFL_TX_SINGLE_Q   "tx_single"
@@ -1127,6 +1128,7 @@ cpfl_dev_close(struct rte_eth_dev *dev)
adapter->cur_vport_nb--;
dev->data->dev_private = NULL;
adapter->vports[vport->sw_idx] = NULL;
+   idpf_free_dma_mem(NULL, &cpfl_vport->itf.flow_dma);
rte_free(cpfl_vport);
 
return 0;
@@ -2466,6 +2468,26 @@ cpfl_p2p_queue_info_init(struct cpfl_vport *cpfl_vport,
return 0;
 }
 
+int
+cpfl_alloc_dma_mem_batch(struct idpf_dma_mem *orig_dma, struct idpf_dma_mem 
*dma, uint32_t size,
+int batch_size)
+{
+   int i;
+
+   if (!idpf_alloc_dma_mem(NULL, orig_dma, size * (1 + batch_size))) {
+   PMD_INIT_LOG(ERR, "Could not alloc dma memory");
+   return -ENOMEM;
+   }
+
+   for (i = 0; i < batch_size; i++) {
+   dma[i].va = (void *)((char *)orig_dma->va + size * (i + 1));
+   dma[i].pa = orig_dma->pa + size * (i + 1);
+   dma[i].size = size;
+   dma[i].zone = NULL;
+   }
+   return 0;
+}
+
 static int
 cpfl_dev_vport_init(struct rte_eth_dev *dev, void *init_params)
 {
@@ -2515,6 +2537,15 @@ cpfl_dev_vport_init(struct rte_eth_dev *dev, void 
*init_params)
rte_ether_addr_copy((struct rte_ether_addr *)vport->default_mac_addr,
&dev->data->mac_addrs[0]);
 
+   memset(cpfl_vport->itf.dma, 0, sizeof(cpfl_vport->itf.dma));
+   memset(cpfl_vport->itf.msg, 0, sizeof(cpfl_vport->itf.msg));
+   ret = cpfl_alloc_dma_mem_batch(&cpfl_vport->itf.flow_dma,
+  cpfl_vport->itf.dma,
+  sizeof(union cpfl_rule_cfg_pkt_record),
+  CPFL_FLOW_BATCH_SIZE);
+   if (ret < 0)
+   goto err_mac_addrs;
+
if (!adapter->base.is_rx_singleq && !adapter->base.is_tx_singleq) {
memset(&p2p_queue_grps_info, 0, sizeof(p2p_queue_grps_info));
ret = cpfl_p2p_q_grps_add(vport, &p2p_queue_grps_info, 
p2p_q_vc_out_info);
diff --git a/drivers/net/cpfl/cpfl_ethdev.h b/drivers/net/cpfl/cpfl_ethdev.h
index 7f83d170d7..8eeeac9910 100644
--- a/drivers/net/cpfl/cpfl_ethdev.h
+++ b/drivers/net/cpfl/cpfl_ethdev.h
@@ -147,10 +147,14 @@ enum cpfl_itf_type {
 
 TAILQ_HEAD(cpfl_flow_list, rte_flow);
 
+#define CPFL_FLOW_BATCH_SIZE  490
 struct cpfl_itf {
enum cpfl_itf_type type;
struct cpfl_adapter_ext *adapter;
struct cpfl_flow_list flow_list;
+   struct idpf_dma_mem flow_dma;
+   struct idpf_dma_mem dma[CPFL_FLOW_BATCH_SIZE];
+   struct idpf_ctlq_msg msg[CPFL_FLOW_BATCH_SIZE];
void *data;
 };
 
@@ -240,6 +244,8 @@ int cpfl_cc_vport_info_get(struct cpfl_adapter_ext *adapter,
 int cpfl_vc_create_ctrl_vport(struct cpfl_adapter_ext *adapter);
 int cpfl_config_ctlq_rx(struct cpfl_adapter_ext *adapter);
 int cpfl_config_ctlq_tx(struct cpfl_adapter_ext *adapter);
+int cpfl_alloc_dma_mem_batch(struct idpf_dma_mem *orig_dma, struct 
idpf_dma_mem *dma,
+uint32_t size, int batch_size);
 
 #define CPFL_DEV_TO_PCI(eth_dev)   \
RTE_DEV_TO_PCI((eth_dev)->device)
diff --git a/drivers/net/cpfl/cpfl_fxp_rule.c b/drivers/net/cpfl/cpfl_fxp_rule.c
new file mode 100644
index 00..ea65e20507
--- /dev/null
+++ b/drivers/net/cpfl/cpfl_fxp_rule.c
@@ -0,0 +1,263 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2023 Intel Corporation
+ */
+#include "cpfl_ethdev.h"
+
+#include "cpfl_fxp_rule.h"
+#include "cpfl_logs.h"
+
+#define CTLQ_SEND_RETRIES 100
+#define CTLQ_RECEIVE_RETRIES 100
+
+int
+cpfl_send_ctlq_msg(struct idpf_hw *hw, struct idpf_ctlq_info *cq, u16 
num_q_msg,
+  struct idpf_ctlq_msg q_msg[])
+{
+   struct idpf_ctlq_msg **msg_ptr_list;
+   u16 clean_count = 0;
+   int num_cleaned = 0;
+   int retries = 0;
+   int ret = 0;
+
+   msg_ptr_list = calloc(num_q_msg, sizeof(struct idpf_ctlq_msg *));
+   if (!msg_ptr_list) {
+   PMD_INIT_LOG(ERR, "no memory for cleaning ctlq");
+   ret

[PATCH v10 7/9] net/cpfl: adapt FXP to flow engine

2023-10-09 Thread Zhang, Yuying

From: Yuying Zhang 

Adapt FXP implementation to a flow engine

Signed-off-by: Yuying Zhang 
Acked-by: Qi Zhang 
---
 doc/guides/nics/cpfl.rst|  18 +-
 doc/guides/rel_notes/release_23_11.rst  |   1 +
 drivers/net/cpfl/cpfl_ethdev.h  |  27 ++
 drivers/net/cpfl/cpfl_flow_engine_fxp.c | 582 
 drivers/net/cpfl/meson.build|   1 +
 5 files changed, 627 insertions(+), 2 deletions(-)
 create mode 100644 drivers/net/cpfl/cpfl_flow_engine_fxp.c

diff --git a/doc/guides/nics/cpfl.rst b/doc/guides/nics/cpfl.rst
index e17347d15c..ae5487f2f6 100644
--- a/doc/guides/nics/cpfl.rst
+++ b/doc/guides/nics/cpfl.rst
@@ -197,8 +197,22 @@ low level hardware resources.
 
 * For Ubuntu, it can be installed using `apt install libjansson-dev`
 
-- run testpmd with the json file
+- run testpmd with the json file, create two vports
 
.. code-block:: console
 
-   dpdk-testpmd -c 0x3 -n 4 -a 
:af:00.6,vport=[0],flow_parser="refpkg.json" -- -i
+   dpdk-testpmd -c 0x3 -n 4 -a 
:af:00.6,vport=[0-1],flow_parser="refpkg.json" -- -i
+
+#. Create one flow to forward ETH-IPV4-TCP from I/O port to a local(CPF's) 
vport. Flow should be created on
+   vport X. Group M should match fxp module. Action port_representor Y means 
forward packet to local vport Y::
+
+   .. code-block:: console
+
+   flow create X ingress group M pattern eth dst is 00:01:00:00:03:14 / ipv4 
src is 192.168.0.1 \
+   dst is 192.168.0.2 / tcp / end actions port_representor port_id Y / end
+
+#. Send a matched packet, and it should be displayed on PMD::
+
+   .. code-block:: console
+
+   
sendp(Ether(dst='00:01:00:00:03:14')/IP(src='192.168.0.1',dst='192.168.0.2')/TCP(),iface="ens25f0")
diff --git a/doc/guides/rel_notes/release_23_11.rst 
b/doc/guides/rel_notes/release_23_11.rst
index 8536ce88f4..16cdd674d3 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -85,6 +85,7 @@ New Features
 * **Updated Intel cpfl driver.**
 
   * Added support for port representor.
+  * Added support for rte_flow.
 
 * **Updated Intel iavf driver.**
   * Added support for iavf auto-reset.
diff --git a/drivers/net/cpfl/cpfl_ethdev.h b/drivers/net/cpfl/cpfl_ethdev.h
index 8eeeac9910..efb0eb5251 100644
--- a/drivers/net/cpfl/cpfl_ethdev.h
+++ b/drivers/net/cpfl/cpfl_ethdev.h
@@ -85,6 +85,8 @@
 
 #define CPFL_RX_CFGQ_NUM   4
 #define CPFL_TX_CFGQ_NUM   4
+#define CPFL_FPCP_CFGQ_TX  0
+#define CPFL_FPCP_CFGQ_RX  1
 #define CPFL_CFGQ_NUM  8
 
 /* bit[15:14] type
@@ -219,6 +221,8 @@ struct cpfl_adapter_ext {
struct rte_hash *repr_allowlist_hash;
 
struct cpfl_flow_js_parser *flow_parser;
+   struct rte_bitmap *mod_bm;
+   void *mod_bm_mem;
 
struct cpfl_metadata meta;
 
@@ -312,4 +316,27 @@ cpfl_get_vsi_id(struct cpfl_itf *itf)
return CPFL_INVALID_HW_ID;
 }
 
+static inline struct cpfl_itf *
+cpfl_get_itf_by_port_id(uint16_t port_id)
+{
+   struct rte_eth_dev *dev;
+
+   if (port_id >= RTE_MAX_ETHPORTS) {
+   PMD_DRV_LOG(ERR, "port_id should be < %d.", RTE_MAX_ETHPORTS);
+   return NULL;
+   }
+
+   dev = &rte_eth_devices[port_id];
+   if (dev->state == RTE_ETH_DEV_UNUSED) {
+   PMD_DRV_LOG(ERR, "eth_dev[%d] is unused.", port_id);
+   return NULL;
+   }
+
+   if (!dev->data) {
+   PMD_DRV_LOG(ERR, "eth_dev[%d] data not be allocated.", port_id);
+   return NULL;
+   }
+
+   return CPFL_DEV_TO_ITF(dev);
+}
 #endif /* _CPFL_ETHDEV_H_ */
diff --git a/drivers/net/cpfl/cpfl_flow_engine_fxp.c 
b/drivers/net/cpfl/cpfl_flow_engine_fxp.c
new file mode 100644
index 00..4c7b4deb7a
--- /dev/null
+++ b/drivers/net/cpfl/cpfl_flow_engine_fxp.c
@@ -0,0 +1,582 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2022 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "cpfl_rules.h"
+#include "cpfl_logs.h"
+#include "cpfl_ethdev.h"
+#include "cpfl_flow.h"
+#include "cpfl_fxp_rule.h"
+#include "cpfl_flow_parser.h"
+
+#define CPFL_COOKIE_DEF0x1000
+#define CPFL_MOD_COOKIE_DEF0x1237561
+#define CPFL_PREC_DEF  1
+#define CPFL_PREC_SET  5
+#define CPFL_TYPE_ID   3
+#define CPFL_OFFSET0x0a
+#define CPFL_HOST_ID_DEF   0
+#define CPFL_PF_NUM_DEF0
+#define CPFL_PORT_NUM_DEF  0
+#define CPFL_RESP_REQ_DEF  2
+#define CPFL_PIN_TO_CACHE_DEF  0
+#define CPFL_CLEAR_MIRROR_1ST_STATE_DEF0
+#define CPFL_FIXED_FETCH_DEF   0
+#define CPFL_PTI_DEF   0
+#define CPFL_MOD_OBJ_SIZE_DEF  0
+#define CPFL_PIN_MOD_CONTENT_DEF   0
+
+#define CPFL_MAX_MOD_CONTENT_INDEX 256
+#define CPFL_MAX_MR_ACTION_NUM 8
+
+/* Struct used when parse detailed rule informati

[PATCH v10 8/9] net/cpfl: support flow ops on representor

2023-10-09 Thread Zhang, Yuying

From: Yuying Zhang 

Add flow ops support for representor, so representor can
create, destroy, validate and flush rules.

Signed-off-by: Yuying Zhang 
Acked-by: Qi Zhang 
---
 drivers/net/cpfl/cpfl_flow_engine_fxp.c | 74 +
 drivers/net/cpfl/cpfl_representor.c | 29 ++
 2 files changed, 103 insertions(+)

diff --git a/drivers/net/cpfl/cpfl_flow_engine_fxp.c 
b/drivers/net/cpfl/cpfl_flow_engine_fxp.c
index 4c7b4deb7a..7a3376f9f6 100644
--- a/drivers/net/cpfl/cpfl_flow_engine_fxp.c
+++ b/drivers/net/cpfl/cpfl_flow_engine_fxp.c
@@ -72,6 +72,7 @@ cpfl_fxp_create(struct rte_eth_dev *dev,
struct cpfl_adapter_ext *ad = itf->adapter;
struct cpfl_rule_info_meta *rim = meta;
struct cpfl_vport *vport;
+   struct cpfl_repr *repr;
 
if (!rim)
return ret;
@@ -82,6 +83,10 @@ cpfl_fxp_create(struct rte_eth_dev *dev,
 * Even index is tx queue and odd index is rx queue.
 */
cpq_id = vport->base.devarg_id * 2;
+   } else if (itf->type == CPFL_ITF_TYPE_REPRESENTOR) {
+   repr = (struct cpfl_repr *)itf;
+   cpq_id = ((repr->repr_id.pf_id  + repr->repr_id.vf_id) &
+ (CPFL_TX_CFGQ_NUM - 1)) * 2;
} else {
rte_flow_error_set(error, EINVAL, RTE_FLOW_ERROR_TYPE_HANDLE, 
NULL,
   "fail to find correct control queue");
@@ -121,6 +126,7 @@ cpfl_fxp_destroy(struct rte_eth_dev *dev,
struct cpfl_rule_info_meta *rim;
uint32_t i;
struct cpfl_vport *vport;
+   struct cpfl_repr *repr;
 
rim = flow->rule;
if (!rim) {
@@ -134,6 +140,10 @@ cpfl_fxp_destroy(struct rte_eth_dev *dev,
if (itf->type == CPFL_ITF_TYPE_VPORT) {
vport = (struct cpfl_vport *)itf;
cpq_id = vport->base.devarg_id * 2;
+   } else if (itf->type == CPFL_ITF_TYPE_REPRESENTOR) {
+   repr = (struct cpfl_repr *)itf;
+   cpq_id = ((repr->repr_id.pf_id  + repr->repr_id.vf_id) &
+ (CPFL_TX_CFGQ_NUM - 1)) * 2;
} else {
rte_flow_error_set(error, EINVAL, RTE_FLOW_ERROR_TYPE_HANDLE, 
NULL,
   "fail to find correct control queue");
@@ -413,6 +423,64 @@ cpfl_is_mod_action(const struct rte_flow_action actions[])
return false;
 }
 
+static bool
+cpfl_fxp_get_metadata_port(struct cpfl_itf *itf,
+  const struct rte_flow_action actions[])
+{
+   const struct rte_flow_action *action;
+   enum rte_flow_action_type action_type;
+   const struct rte_flow_action_ethdev *ethdev;
+   struct cpfl_itf *target_itf;
+   bool ret;
+
+   if (itf->type == CPFL_ITF_TYPE_VPORT) {
+   ret = cpfl_metadata_write_port_id(itf);
+   if (!ret) {
+   PMD_DRV_LOG(ERR, "fail to write port id");
+   return false;
+   }
+   }
+
+   ret = cpfl_metadata_write_sourcevsi(itf);
+   if (!ret) {
+   PMD_DRV_LOG(ERR, "fail to write source vsi id");
+   return false;
+   }
+
+   ret = cpfl_metadata_write_vsi(itf);
+   if (!ret) {
+   PMD_DRV_LOG(ERR, "fail to write vsi id");
+   return false;
+   }
+
+   if (!actions || actions->type == RTE_FLOW_ACTION_TYPE_END)
+   return false;
+
+   for (action = actions; action->type != RTE_FLOW_ACTION_TYPE_END; 
action++) {
+   action_type = action->type;
+   switch (action_type) {
+   case RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT:
+   case RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR:
+   ethdev = (const struct rte_flow_action_ethdev 
*)action->conf;
+   target_itf = cpfl_get_itf_by_port_id(ethdev->port_id);
+   if (!target_itf) {
+   PMD_DRV_LOG(ERR, "fail to get target_itf by 
port id");
+   return false;
+   }
+   ret = cpfl_metadata_write_targetvsi(target_itf);
+   if (!ret) {
+   PMD_DRV_LOG(ERR, "fail to write target vsi id");
+   return false;
+   }
+   break;
+   default:
+   continue;
+   }
+   }
+
+   return true;
+}
+
 static int
 cpfl_fxp_parse_pattern_action(struct rte_eth_dev *dev,
  const struct rte_flow_attr *attr,
@@ -429,6 +497,12 @@ cpfl_fxp_parse_pattern_action(struct rte_eth_dev *dev,
struct cpfl_rule_info_meta *rim;
int ret;
 
+   ret = cpfl_fxp_get_metadata_port(itf, actions);
+   if (!ret) {
+   PMD_DRV_LOG(ERR, "Fail to save metadata.");
+   return -EINVAL;
+   }
+
ret = cpfl_f

[PATCH v10 9/9] net/cpfl: support represented port action

2023-10-09 Thread Zhang, Yuying

From: Yuying Zhang 

Support RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT action for forwarding
packet to APF/CPF/VF representors.

Signed-off-by: Yuying Zhang 
Acked-by: Qi Zhang 
---
 drivers/net/cpfl/cpfl_flow_engine_fxp.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/net/cpfl/cpfl_flow_engine_fxp.c 
b/drivers/net/cpfl/cpfl_flow_engine_fxp.c
index 7a3376f9f6..ddede2f553 100644
--- a/drivers/net/cpfl/cpfl_flow_engine_fxp.c
+++ b/drivers/net/cpfl/cpfl_flow_engine_fxp.c
@@ -266,6 +266,7 @@ cpfl_fxp_parse_action(struct cpfl_itf *itf,
int queue_id = -1;
bool fwd_vsi = false;
bool fwd_q = false;
+   bool is_vsi;
uint32_t i;
struct cpfl_rule_info *rinfo = &rim->rules[index];
union cpfl_action_set *act_set = (void *)rinfo->act_bytes;
@@ -276,6 +277,7 @@ cpfl_fxp_parse_action(struct cpfl_itf *itf,
action_type = action->type;
switch (action_type) {
case RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR:
+   case RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT:
if (!fwd_vsi)
fwd_vsi = true;
else
@@ -294,12 +296,20 @@ cpfl_fxp_parse_action(struct cpfl_itf *itf,
queue_id = CPFL_INVALID_QUEUE_ID;
}
 
-   dev_id = cpfl_get_vsi_id(dst_itf);
+   is_vsi = (action_type == 
RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR ||
+ dst_itf->type == CPFL_ITF_TYPE_REPRESENTOR);
+   if (is_vsi)
+   dev_id = cpfl_get_vsi_id(dst_itf);
+   else
+   dev_id = cpfl_get_port_id(dst_itf);
 
if (dev_id == CPFL_INVALID_HW_ID)
goto err;
 
-   *act_set = cpfl_act_fwd_vsi(0, priority, 0, dev_id);
+   if (is_vsi)
+   *act_set = cpfl_act_fwd_vsi(0, priority, 0, 
dev_id);
+   else
+   *act_set = cpfl_act_fwd_port(0, priority, 0, 
dev_id);
act_set++;
rinfo->act_byte_len += sizeof(union cpfl_action_set);
break;
-- 
2.34.1

RE: [PATCH] ethdev: add calculate hash function

2023-10-09 Thread Dariusz Sosnowski

Hi,

> -Original Message-
> From: Ori Kam 
> Sent: Tuesday, September 26, 2023 13:38
> To: cristian.dumitre...@intel.com; Aman Singh
> ; Yuying Zhang ;
> NBU-Contact-Thomas Monjalon (EXTERNAL) ;
> Ferruh Yigit ; Andrew Rybchenko
> 
> Cc: dev@dpdk.org; Ori Kam ; Raslan Darawsheh
> 
> Subject: [PATCH] ethdev: add calculate hash function
> 
> External email: Use caution opening links or attachments
> 
> 
> rte_flow supports insert by index table[1].
> 
> Using the above table, the application can create rules that are based on 
> hash.
> For example application can create the following logic in order to create load
> balancing:
> 1. Create insert by index table with 2 rules, that hashes based on dmac 2.
> Insert to index 0 a rule that sends the traffic to port A.
> 3. Insert to index 1 a rule that sends the traffic to port B.
> 
> Let's also assume that before this table, there is a 5 tuple match table that
> jumps to the above table.
> 
> So each packet that matches one of the 5 tuple rules is RSSed to port A or B,
> based on dmac hash.
> 
> The issue arises when there is a miss on the 5 tuple table, which resulted due
> to the packet being the first packet of this flow, or fragmented packet or any
> other reason.
> In this case, the application must calculate what would be the hash calculated
> by the HW so it can send the packet to the correct port.
> 
> This new API allows applications to calculate the hash value of a given packet
> for a given table.
> 
> [1] -
> http://patches.dpdk.org/project/dpdk/patch/20230208030624.78465-2-
> akozy...@nvidia.com/
> 
> Signed-off-by: Ori Kam 
Acked-by: Dariusz Sosnowski 

Thanks,
Dariusz Sosnowski

Re: [PATCH v1 1/3] examples/l3fwd: relax RSS requirement with option

2023-10-09 Thread Konstantin Ananyev


Hi Trevor,


Now the port Rx mq_mode had been set to RTE_ETH_MQ_RX_RSS
by default, but some hw and/or virtual interface does not
support the RSS and offload mode presupposed, e.g., some
virtio interfaces in the cloud don't support
RSS and the error msg may like:

virtio_dev_configure(): RSS support requested but not supported by
the device
Port0 dev_configure = -95

So to enable the l3fwd running in that environment, the Rx mode requirement
can be relaxed to reflect the hardware feature reality here, and the l3fwd
can run smoothly then.

An option named "relax-rx-mode" is added to enable the relax action
here, and it's disabled by default.

Signed-off-by: Trevor Tao 
---
  examples/l3fwd/main.c | 19 +--
  1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c
index 6063eb1399..2c8f528d00 100644
--- a/examples/l3fwd/main.c
+++ b/examples/l3fwd/main.c
@@ -73,6 +73,7 @@ static enum L3FWD_LOOKUP_MODE lookup_mode;
  static int numa_on = 1; /**< NUMA is enabled by default. */
  static int parse_ptype; /**< Parse packet type using rx callback, and */
/**< disabled by default */
+static int relax_rx_mode; /**< Relax RX mode is disabled by default */
  static int per_port_pool; /**< Use separate buffer pools per port; disabled */
  /**< by default */
  
@@ -678,6 +679,7 @@ static const char short_options[] =

  #define CMD_LINE_OPT_MAX_PKT_LEN "max-pkt-len"
  #define CMD_LINE_OPT_HASH_ENTRY_NUM "hash-entry-num"
  #define CMD_LINE_OPT_PARSE_PTYPE "parse-ptype"
+#define CMD_LINE_OPT_RELAX_RX_MODE "relax-rx-mode"
  #define CMD_LINE_OPT_PER_PORT_POOL "per-port-pool"
  #define CMD_LINE_OPT_MODE "mode"
  #define CMD_LINE_OPT_EVENTQ_SYNC "eventq-sched"
@@ -705,6 +707,7 @@ enum {
CMD_LINE_OPT_MAX_PKT_LEN_NUM,
CMD_LINE_OPT_HASH_ENTRY_NUM_NUM,
CMD_LINE_OPT_PARSE_PTYPE_NUM,
+   CMD_LINE_OPT_RELAX_RX_MODE_NUM,
CMD_LINE_OPT_RULE_IPV4_NUM,
CMD_LINE_OPT_RULE_IPV6_NUM,
CMD_LINE_OPT_ALG_NUM,
@@ -728,6 +731,7 @@ static const struct option lgopts[] = {
{CMD_LINE_OPT_MAX_PKT_LEN, 1, 0, CMD_LINE_OPT_MAX_PKT_LEN_NUM},
{CMD_LINE_OPT_HASH_ENTRY_NUM, 1, 0, CMD_LINE_OPT_HASH_ENTRY_NUM_NUM},
{CMD_LINE_OPT_PARSE_PTYPE, 0, 0, CMD_LINE_OPT_PARSE_PTYPE_NUM},
+   {CMD_LINE_OPT_RELAX_RX_MODE, 0, 0, CMD_LINE_OPT_RELAX_RX_MODE_NUM},
{CMD_LINE_OPT_PER_PORT_POOL, 0, 0, CMD_LINE_OPT_PARSE_PER_PORT_POOL},
{CMD_LINE_OPT_MODE, 1, 0, CMD_LINE_OPT_MODE_NUM},
{CMD_LINE_OPT_EVENTQ_SYNC, 1, 0, CMD_LINE_OPT_EVENTQ_SYNC_NUM},
@@ -853,6 +857,11 @@ parse_args(int argc, char **argv)
parse_ptype = 1;
break;
  
+		case CMD_LINE_OPT_RELAX_RX_MODE_NUM:

+   printf("Relax rx mode is enabled\n");
+   relax_rx_mode = 1;
+   break;
+
case CMD_LINE_OPT_PARSE_PER_PORT_POOL:
printf("per port buffer pool is enabled\n");
per_port_pool = 1;
@@ -1257,8 +1266,14 @@ l3fwd_poll_resource_setup(void)
local_port_conf.rx_adv_conf.rss_conf.rss_hf &=
dev_info.flow_type_rss_offloads;
  
-		if (dev_info.max_rx_queues == 1)

-   local_port_conf.rxmode.mq_mode = RTE_ETH_MQ_RX_NONE;
+   /* relax the rx rss requirement */
+   if (dev_info.max_rx_queues == 1 || 
!local_port_conf.rx_adv_conf.rss_conf.rss_hf) {
+   if (relax_rx_mode) {
+   printf("warning: modified the rx mq_mode to 
RTE_ETH_MQ_RX_NONE base on"
+   " device capability\n");
+   local_port_conf.rxmode.mq_mode = 
RTE_ETH_MQ_RX_NONE;
+   }
+   }


But that way we change current behavior - always use MQ_RX_NONE
for devices with just one RX queue.
Was it intended?
Might be it should be:
if (dev_info.max_rx_queues == 1)
local_port_conf.rxmode.mq_mode = RTE_ETH_MQ_RX_NONE;

+   /* relax the rx rss requirement */
+   if (relax_rx_mode &&
+   !local_port_conf.rx_adv_conf.rss_conf.rss_hf) {
+   printf("...");
+   local_port_conf.rxmode.mq_mode = RTE_ETH_MQ_RX_NONE;
+   }

?


  
  		if (local_port_conf.rx_adv_conf.rss_conf.rss_hf !=

port_conf.rx_adv_conf.rss_conf.rss_hf) {

Re: [EXT] Re: [PATCH v3 1/2] dmadev: offload to free source buffer

2023-10-09 Thread fengchengwen

Hi Amit,

  Rethink again, I suggest use auto-free to denote this feature.

So we could re-define as:
  RTE_DMA_CAPA_M2D_AUTO_FREE
  RTE_DMA_OP_FLAG_AUTO_FREE

struct rte_dma_auto_free_param {
  union {
  struct {
  struct rte_mempool *pool;
  } m2d;
  };
  uint64_t reserved[2]; /**< Reserved for future fields. */ };
};
note: because one vchan only support one DMA direction, so we could use union.

struct rte_dma_vchan_conf {
enum rte_dma_direction direction;
struct rte_dma_port_param src_port;
struct rte_dma_port_param dst_port;
struct rte_dma_auto_free_param auto_free;
};


As for later extension, if support other type auto-free, so could:
1. add one capa: RTE_DMA_CAPA_XXX_AUTO_FREE
2. modify rte_dma_auto_free_param:
   struct rte_dma_auto_free_param {
  union {
  struct {
  struct rte_mempool *pool;
  } m2d;
  struct {
  // params;
  } xxx;
  };
  uint64_t reserved[2]; /**< Reserved for future fields. */ };
};


Thanks.

On 2023/10/9 15:00, Amit Prakash Shukla wrote:
> Hi Chengwen,
> 
> Thanks for the review and feedback. Please find my reply in-line.
> 
> Thanks,
> Amit Shukla
> 
>> -Original Message-
>> From: fengchengwen 
>> Sent: Saturday, October 7, 2023 2:31 PM
>> To: Amit Prakash Shukla ; Kevin Laatz
>> ; Bruce Richardson 
>> Cc: dev@dpdk.org; Jerin Jacob Kollanukkaran ;
>> m...@smartsharesystems.com; conor.wa...@intel.com; Vamsi Krishna
>> Attunuru ; g.si...@nxp.com;
>> sachin.sax...@oss.nxp.com; hemant.agra...@nxp.com;
>> cheng1.ji...@intel.com; Nithin Kumar Dabilpuram
>> ; Anoob Joseph 
>> Subject: [EXT] Re: [PATCH v3 1/2] dmadev: offload to free source buffer
>>
>> External Email
>>
>> --
>> Hi Amit,
>>
>> On 2023/9/28 19:50, Amit Prakash Shukla wrote:
>>> This changeset adds support in DMA library to free source DMA buffer
>>> by hardware. On a supported hardware, application can pass on the
>>> mempool information as part of vchan config when the DMA transfer
>>> direction is configured as RTE_DMA_DIR_MEM_TO_DEV.
>>>
>>> Signed-off-by: Amit Prakash Shukla 
>>> Acked-by: Morten Brørup 
>>> Acked-by: Anoob Joseph 
>>> ---
>>>  lib/dmadev/rte_dmadev.h | 27 +++
>>>  1 file changed, 27 insertions(+)
>>>
>>> diff --git a/lib/dmadev/rte_dmadev.h b/lib/dmadev/rte_dmadev.h index
>>> b157ab7600..f7a6af2528 100644
>>> --- a/lib/dmadev/rte_dmadev.h
>>> +++ b/lib/dmadev/rte_dmadev.h
>>> @@ -278,6 +278,13 @@ int16_t rte_dma_next_dev(int16_t start_dev_id);
>>>  #define RTE_DMA_CAPA_OPS_COPY_SG   RTE_BIT64(33)
>>>  /** Support fill operation. */
>>>  #define RTE_DMA_CAPA_OPS_FILL  RTE_BIT64(34)
>>> +/** Support for source buffer free for mem to dev transfer.
>>
>> Support auto free source buffer once the M2D (memory-to-device) transfer
>> completed.
> 
> Ack
> 
>>
>>> + *
>>> + * @note Even though the DMA driver has this capability, it may not
>>> + support all
>>> + * mempool drivers. If the mempool is not supported by the DMA
>>> + driver,
>>> + * rte_dma_vchan_setup() will fail.
>>
>> In addition to hardware support, there are requirements for buffer attribute
>> (e.g. only specific mempool support it).
>>
>>> + **/
>>> +#define RTE_DMA_CAPA_MEM_TO_DEV_SOURCE_BUFFER_FREE
>>  RTE_BIT64(35)
>>
>> 1) this should follow RTE_DMA_CAPA_HANDLES_ERRORS, because it not
>> new OPS.
>> 2) the name is too long. how abort
>> RTE_DMA_CAPA_AUTO_FREE_M2D_SBUF? I am not sure, suggest get better
>> name.
> 
> Ack.
> 
>>
>>>  /**@}*/
>>>
>>>  /**
>>> @@ -581,6 +588,19 @@ struct rte_dma_vchan_conf {
>>>  * @see struct rte_dma_port_param
>>>  */
>>> struct rte_dma_port_param dst_port;
>>> +   /** Mempool from which source buffer is allocated. Mempool info is
>> used
>>> +* for freeing source buffer by hardware when configured direction is
>>> +* RTE_DMA_DIR_MEM_TO_DEV. To free the source buffer by
>> hardware,
>>> +* RTE_DMA_OP_FLAG_FREE_SBUF must be set while calling
>> rte_dma_copy and
>>> +* rte_dma_copy_sg().
>>> +*
>>> +* @note If the mempool is not supported by the DMA device,
>>> +* rte_dma_vchan_setup() will fail.
>>> +*
>>> +* @see RTE_DMA_OP_FLAG_FREE_SBUF
>>> +*/
>>> +   struct rte_mempool *mem_to_dev_src_buf_pool;
>>> +
>>>  };
>>
>> Suggest add one extra struct e.g.
>> struct rte_dma_auto_free_param {
>> union {
>> struct rte_mempool *pool;
>> }
>> uint64_t reserved[2]; /**< Reserved for future fields. */ };
>>
>> In the above conf, we could add a new field: struct
>> rte_dma_auto_free_param  m2d_buf
> 
> Ack, will add new struct.
> struct rte_dma_auto_free_buf_param {
> struct rte_mempool *pool;
> uint64_t reserved[2]; /**< Reserved for future fields. */ };
> };
> 
> struct rte_dma_auto_free_buf_param  m2d_sbuf;
> 
>>
>>>
>>>  /**
>>> @@ -818,6 +838,13 @@ struct rte_dma

RE: [PATCH] net/mlx5: adds the checking for Tx queue affinity

2023-10-09 Thread Raslan Darawsheh

Hi,

> -Original Message-
> From: Jiawei(Jonny) Wang 
> Sent: Friday, September 22, 2023 9:50 AM
> To: Slava Ovsiienko 
> Cc: dev@dpdk.org; Raslan Darawsheh 
> Subject: [PATCH] net/mlx5: adds the checking for Tx queue affinity
> 
> MLX5 PMD updates the TIS index based on the tx queue affinity, and creates
> the DevX SQ object with updated the TIS index.
> 
> This patch adds the checking that set the affinity per Tx Queue if HW objects
> can be created by DevX.
> 
> Signed-off-by: Jiawei Wang 
> Acked-by: Viacheslav Ovsiienko 

Patch applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh

Re: [PATCH v1 2/3] examples/l3fwd: relax the Offload requirement

2023-10-09 Thread Konstantin Ananyev


02.10.2023 09:53, Trevor Tao пишет:

Now the port Rx offload mode is set to RTE_ETH_RX_OFFLOAD_CHECKSUM
by default, but some hw and/or virtual interface does not support
the offload mode presupposed, e.g., some virtio interfaces in
the cloud may only partly support RTE_ETH_RX_OFFLOAD_UDP_CKSUM/
RTE_ETH_RX_OFFLOAD_TCP_CKSUM,
but not RTE_ETH_RX_OFFLOAD_IPV4_CKSUM, and the error msg here:

Ethdev port_id=0 requested Rx offloads 0xe does not match Rx offloads
capabilities 0x201d in rte_eth_dev_configure()

So to enable the l3fwd running in that environment, the Rx mode requirement
can be relaxed to reflect the hardware feature reality here, and the l3fwd
can run smoothly then.
A warning msg would be provided to user in case it happens here.

On the other side, enabling the software cksum check in case missing the
hw support.

The relax action for rx cksum offload is just enabled when relax_rx_mode is
true which is false by default.

Signed-off-by: Trevor Tao 
---
  examples/l3fwd/l3fwd.h | 12 ++--
  examples/l3fwd/l3fwd_em.h  |  2 +-
  examples/l3fwd/l3fwd_lpm.h |  2 +-
  examples/l3fwd/main.c  | 14 ++
  4 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/examples/l3fwd/l3fwd.h b/examples/l3fwd/l3fwd.h
index b55855c932..fd98ad3373 100644
--- a/examples/l3fwd/l3fwd.h
+++ b/examples/l3fwd/l3fwd.h
@@ -159,7 +159,7 @@ send_single_packet(struct lcore_conf *qconf,
  
  #ifdef DO_RFC_1812_CHECKS

  static inline int
-is_valid_ipv4_pkt(struct rte_ipv4_hdr *pkt, uint32_t link_len)
+is_valid_ipv4_pkt(struct rte_ipv4_hdr *pkt, uint32_t link_len, uint64_t 
ol_flags)
  {
/* From http://www.rfc-editor.org/rfc/rfc1812.txt section 5.2.2 */
/*
@@ -170,7 +170,15 @@ is_valid_ipv4_pkt(struct rte_ipv4_hdr *pkt, uint32_t 
link_len)
return -1;
  
  	/* 2. The IP checksum must be correct. */

-   /* this is checked in H/W */
+   /* if this is not checked in H/W, check it. */
+   if ((ol_flags & RTE_ETH_RX_OFFLOAD_IPV4_CKSUM) == 0) {
+   uint16_t actual_cksum, expected_cksum;
+   actual_cksum = pkt->hdr_checksum;
+   pkt->hdr_checksum = 0;
+   expected_cksum = rte_ipv4_cksum(pkt);
+   if (actual_cksum != expected_cksum)
+   return -2;
+   }
  
  	/*

 * 3. The IP version number must be 4. If the version number is not 4
diff --git a/examples/l3fwd/l3fwd_em.h b/examples/l3fwd/l3fwd_em.h
index 7d051fc076..1fee2e2e6c 100644
--- a/examples/l3fwd/l3fwd_em.h
+++ b/examples/l3fwd/l3fwd_em.h
@@ -20,7 +20,7 @@ l3fwd_em_handle_ipv4(struct rte_mbuf *m, uint16_t portid,
  
  #ifdef DO_RFC_1812_CHECKS

/* Check to make sure the packet is valid (RFC1812) */
-   if (is_valid_ipv4_pkt(ipv4_hdr, m->pkt_len) < 0) {
+   if (is_valid_ipv4_pkt(ipv4_hdr, m->pkt_len, m->ol_flags) < 0) {
rte_pktmbuf_free(m);
return BAD_PORT;
}
diff --git a/examples/l3fwd/l3fwd_lpm.h b/examples/l3fwd/l3fwd_lpm.h
index c61b969584..5ddae7da0f 100644
--- a/examples/l3fwd/l3fwd_lpm.h
+++ b/examples/l3fwd/l3fwd_lpm.h
@@ -22,7 +22,7 @@ l3fwd_lpm_simple_forward(struct rte_mbuf *m, uint16_t portid,
  
  #ifdef DO_RFC_1812_CHECKS

/* Check to make sure the packet is valid (RFC1812) */
-   if (is_valid_ipv4_pkt(ipv4_hdr, m->pkt_len) < 0) {
+   if (is_valid_ipv4_pkt(ipv4_hdr, m->pkt_len) < 0, m->ol_flags) {


Typo, pls fix.


rte_pktmbuf_free(m);
return;
}
diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c
index 2c8f528d00..a48ae7f62b 100644
--- a/examples/l3fwd/main.c
+++ b/examples/l3fwd/main.c
@@ -1284,6 +1284,20 @@ l3fwd_poll_resource_setup(void)
local_port_conf.rx_adv_conf.rss_conf.rss_hf);
}
  
+		/* relax the rx offload requirement */

+   if ((local_port_conf.rxmode.offloads & 
dev_info.rx_offload_capa) !=
+   local_port_conf.rxmode.offloads) {



Ok, but we relax only IP cksum.
Though l3fwd tries to enable IP/TCP/UDP cksum.
What if TCP/UDP is not supported, should we allow it or fail?



+   printf("Port %u requested Rx offloads 0x%"PRIx64" does 
not"
+   " match Rx offloads capabilities 0x%"PRIx64"\n",
+   portid, local_port_conf.rxmode.offloads,
+   dev_info.rx_offload_capa);
+   if (relax_rx_mode) {
+   local_port_conf.rxmode.offloads &= 
dev_info.rx_offload_capa;
+   printf("warning: modified the rx offload to 
0x%"PRIx64" based on device"
+   " capability\n", 
local_port_conf.rxmode.offloads);
+   }
+   }
+
ret = rte_eth_dev_configure(portid, nb_rx_queue,
(uint16_t)n

Re: [PATCH] net/nfp: fix one memory access problem

2023-10-09 Thread Ferruh Yigit

On 10/8/2023 8:08 AM, Chaoyong He wrote:
> The initial logic do not give a value to the out parameter in the
> abnormal logic, which cause an local variable uninitialized problem.
> 
> Fixes: 3d6811281392 ("net/nfp: add infrastructure for conntrack flow merge")
> Cc: chaoyong...@corigine.com
> 
> Signed-off-by: Chaoyong He 
> 

   Tested-by: Daxue Gao 


Acked-by: Ferruh Yigit 


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

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

2023-10-09 Thread Ferruh Yigit

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

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

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


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

>>>
>>> Hi David,
>>>
>>> If API update is not planned, what do you think to just solve the build
>>> error without changing functionality with a change something like below:
>>>
>>> ```
>>>   -   (strlen(mac_byte) == strspn(mac_byte,
>>>   -   ETH_TAP_CMP_MAC_FMT))) {
>>>   +   (strlen(mac_byte) == strspn(mac_byte, ETH_TAP_CMP_MAC_FMT)) &&
>>>   +   index < RTE_ETHER_ADDR_LEN) {
>>>
>>> ```
>>
>> Hi David,
>>
>> If you can confirm above fixes the issue, I can send a patch for it.
> 
> Confirmed that your proposed change resolves the build issue on ppc64le.
>  Appreciate if you can submit the patch.
> 
> 

Thanks for checking, but Stephen updated the 'rte_ether_unformat_addr()'
API [1] and sent a new version of this patch [2], which is merged in
next-net [3] now.
Build error for PPC should be fixed now.


[1]
https://patchwork.dpdk.org/project/dpdk/patch/20231003202909.391330-3-step...@networkplumber.org/

[2]
https://patchwork.dpdk.org/project/dpdk/patch/20231003202909.391330-5-step...@networkplumber.org/

[3]
https://git.dpdk.org/next/dpdk-next-net/log/

Re: [PATCH v3 0/2] fix help string and add a new command

2023-10-09 Thread Ferruh Yigit

On 10/8/2023 7:46 AM, Dengdui Huang wrote:
> This series fix help string and add a new command.
> 
> v3->v4
> help string add '\n' at last.
> 
> v2->v3
> add 'mcast_addr add|remove' to help string and
> update the new command description.
> 
> v1->v2
> update order on help string.
> 
> Dengdui Huang (2):
>   app/testpmd: fix help string
>   app/testpmd: add flush all multicast MAC address command
> 
>  

For series,
Acked-by: Ferruh Yigit 


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

Re: [PATCH v16 1/8] net/ntnic: initial commit which adds register defines

2023-10-09 Thread Ferruh Yigit

On 10/9/2023 8:57 AM, Christian Koue Muf wrote:
> On 9/29/2023 12:24 PM, Thomas Monjalon wrote:
>> 29/09/2023 11:46, Ferruh Yigit:
>>> On 9/29/2023 10:21 AM, Christian Koue Muf wrote:
 On 9/21/2023 4:05 PM, Ferruh Yigit wrote:
> On 9/20/2023 2:17 PM, Thomas Monjalon wrote:
>> Hello,
>>
>> 19/09/2023 11:06, Christian Koue Muf:
>>> On 9/18/23 10:34 AM, Ferruh Yigit wrote:
 On 9/15/2023 7:37 PM, Morten Brørup wrote:
>> From: Ferruh Yigit [mailto:ferruh.yi...@amd.com]
>> Sent: Friday, 15 September 2023 17.55
>>
>> On 9/8/2023 5:07 PM, Mykola Kostenok wrote:
>>> From: Christian Koue Muf 
>>>
>>> The NTNIC PMD does not rely on a kernel space Napatech
>>> driver, thus all defines related to the register layout is
>>> part of the PMD code, which will be added in later commits.
>>>
>>> Signed-off-by: Christian Koue Muf 
>>> Reviewed-by: Mykola Kostenok 
>>>
>>
>> Hi Mykola, Christiam,
>>
>> This PMD scares me, overall it is a big drop:
>> "249 files changed, 87128 insertions(+)"
>>
>> I think it is not possible to review all in one release cycle,
>> and it is not even possible to say if all code used or not.
>>
>> I can see code is already developed, and it is difficult to
>> restructure developed code, but restructure it into small
>> pieces really helps for reviews.
>>
>>
>> Driver supports good list of features, can it be possible to
>> distribute upstream effort into multiple release.
>> Starting from basic functionality and add features gradually.
>> Target for this release can be providing datapath, and add
>> more if we have time in the release, what do you think?
>>
>> I was expecting to get only Rx/Tx in this release, not really more.
>>
>> I agree it may be interesting to discuss some design and check
>> whether we need more features in ethdev as part of the driver
>> upstreaming process.
>>
>>
>> Also there are large amount of base code (HAL / FPGA code),
>> instead of adding them as a bulk, relevant ones with a feature
>> can be added with the feature patch, this eliminates dead code
>> in the base code layer, also helps user/review to understand
>> the link between driver code and base code.
>>
>> Yes it would be interesting to see what is really needed for the
>> basic initialization and what is linked to a specific offload or 
>> configuration feature.
>>
>> As a maintainer, I have to do some changes across all drivers
>> sometimes, and I use git blame a lot to understand why something was 
>> added.
>>
>>
> Jumping in here with an opinion about welcoming new NIC vendors to 
> the community:
>
> Generally, if a NIC vendor supplies a PMD for their NIC, I expect the 
> vendor to take responsibility for the quality of the PMD, including 
> providing a maintainer and support backporting of fixes to the PMD in 
> LTS releases. This should align with the vendor's business case for 
> upstreaming their driver.
>
> If the vendor provides one big patch series, which may be difficult 
> to understand/review, the fallout mainly hits the vendor's customers 
> (and thus the vendor's support organization), not the community as a 
> whole.
>

 Hi Morten,

 I was thinking same before making my above comment, what happens if 
 vendors submit as one big patch and when a problem occurs we can ask 
 owner to fix. Probably this makes vendor happy and makes my life (or 
 any other maintainer's life) easier, it is always easier to say yes.


 But I come up with two main reasons to ask for a rework:

 1- Technically any vendor can deliver their software to their
 customers via a public git repository, they don't have to
 upstream to
 https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fdpdk.org&c=E
 ,1,N
 poJejuuvPdOPfcFJYtsmkQF6PVrDjGsZ8x_gi5xDrTyZokK_nM11u4ZpzHgM10J9
 bOLl nhoR6fFAzWtCzOhRCzVruYj520zZORv6-MjJeSC5TrGnIFL&typo=1,
 but upstreaming has many benefits.

 One of those benefits is upstreaming provides a quality assurance for 
 vendor's customers (that is why customer can be asking for this, as we 
 are having in many cases), and this quality assurance comes from 
 additional eyes reviewing the code and guiding vendors for the DPDK 
 quality standards (some vendors already doing pretty good, but new 
 ones sometimes requires hand-holding).

 If driver is one big patch series, it is practically

[PATCH v2] config/arm: update aarch32 build with gcc13

2023-10-09 Thread Juraj Linkeš

The aarch32 with gcc13 fails with:

Compiler for C supports arguments -march=armv8-a: NO

../config/arm/meson.build:714:12: ERROR: Problem encountered: No
suitable armv8 march version found.

This is because we test -march=armv8-a alone (without the -mpfu option),
which is no longer supported in gcc13 aarch32 builds.

The most recent recommendation from the compiler team is to build with
-march=armv8-a+simd -mfpu=auto, which should work for compilers old and
new. The suggestion is to first check -march=armv8-a+simd and only then
check -mfpu=auto.

To address this, add a way to force the architecture (the value of
the -march option).

Signed-off-by: Juraj Linkeš 
---
 config/arm/meson.build | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/config/arm/meson.build b/config/arm/meson.build
index 3f22d8a2fc..5303d0e969 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -43,7 +43,9 @@ implementer_generic = {
 },
 'generic_aarch32': {
 'march': 'armv8-a',
-'compiler_options': ['-mfpu=neon'],
+'force_march': true,
+'march_features': ['simd'],
+'compiler_options': ['-mfpu=auto'],
 'flags': [
 ['RTE_ARCH_ARM_NEON_MEMCPY', false],
 ['RTE_ARCH_STRICT_ALIGN', true],
@@ -711,7 +713,11 @@ if update_flags
 endif
 endforeach
 if candidate_march == ''
-error('No suitable armv8 march version found.')
+if part_number_config.get('force_march', false)
+candidate_march = part_number_config['march']
+else
+error('No suitable armv8 march version found.')
+endif
 endif
 if candidate_march != part_number_config['march']
 warning('Configuration march version is ' +
@@ -741,7 +747,7 @@ if update_flags
 # apply supported compiler options
 if part_number_config.has_key('compiler_options')
 foreach flag: part_number_config['compiler_options']
-if cc.has_argument(flag)
+if cc.has_multi_arguments(machine_args + [flag])
 machine_args += flag
 else
 warning('Configuration compiler option ' +
-- 
2.34.1

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

2023-10-09 Thread lihuisong (C)


Hi Ferruh and Thomas,

Can you take a look at this series? They've been over a year on 
disscussion.



在 2023/8/2 11:15, Huisong Li 写道:

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

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

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

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

[PATCH v2] mem: allow using ASan in multi-process mode

2023-10-09 Thread Artur Paszkiewicz

Multi-process applications operate on shared hugepage memory but each
process has its own ASan shadow region which is not synchronized with
the other processes. This causes issues when different processes try to
use the same memory because they have their own view of which addresses
are valid.

Fix it by mapping the shadow regions for memseg lists as shared memory.
The primary process is responsible for creating and removing the shared
memory objects.

Disable ASan instrumentation for triggering the page fault in
alloc_seg() because if the segment is already allocated by another
process and is marked as free in the shadow, accessing this address will
cause an ASan error.

Signed-off-by: Artur Paszkiewicz 
---
v2:
- Added checks for config options disabling multi-process support.
- Fixed missing unmap in legacy mode.

 lib/eal/common/eal_common_memory.c |  9 +++
 lib/eal/common/eal_private.h   | 22 +++
 lib/eal/linux/eal_memalloc.c   |  9 ++-
 lib/eal/linux/eal_memory.c | 97 ++
 lib/eal/linux/meson.build  |  4 ++
 5 files changed, 140 insertions(+), 1 deletion(-)

diff --git a/lib/eal/common/eal_common_memory.c 
b/lib/eal/common/eal_common_memory.c
index d9433db623..15f950810b 100644
--- a/lib/eal/common/eal_common_memory.c
+++ b/lib/eal/common/eal_common_memory.c
@@ -263,6 +263,12 @@ eal_memseg_list_alloc(struct rte_memseg_list *msl, int 
reserve_flags)
RTE_LOG(DEBUG, EAL, "VA reserved for memseg list at %p, size %zx\n",
addr, mem_sz);
 
+#ifdef RTE_MALLOC_ASAN
+   if (eal_memseg_list_map_asan_shadow(msl) != 0) {
+   RTE_LOG(ERR, EAL, "Failed to map ASan shadow region for memseg 
list");
+   return -1;
+   }
+#endif
return 0;
 }
 
@@ -1050,6 +1056,9 @@ rte_eal_memory_detach(void)
RTE_LOG(ERR, EAL, "Could not unmap memory: 
%s\n",
rte_strerror(rte_errno));
 
+#ifdef RTE_MALLOC_ASAN
+   eal_memseg_list_unmap_asan_shadow(msl);
+#endif
/*
 * we are detaching the fbarray rather than destroying because
 * other processes might still reference this fbarray, and we
diff --git a/lib/eal/common/eal_private.h b/lib/eal/common/eal_private.h
index 5eadba4902..48df338cf9 100644
--- a/lib/eal/common/eal_private.h
+++ b/lib/eal/common/eal_private.h
@@ -300,6 +300,28 @@ eal_memseg_list_alloc(struct rte_memseg_list *msl, int 
reserve_flags);
 void
 eal_memseg_list_populate(struct rte_memseg_list *msl, void *addr, int n_segs);
 
+#ifdef RTE_MALLOC_ASAN
+/**
+ * Map shared memory for MSL ASan shadow region.
+ *
+ * @param msl
+ *  Memory segment list.
+ * @return
+ *  0 on success, (-1) on failure.
+ */
+int
+eal_memseg_list_map_asan_shadow(struct rte_memseg_list *msl);
+
+/**
+ * Unmap the MSL ASan shadow region.
+ *
+ * @param msl
+ *  Memory segment list.
+ */
+void
+eal_memseg_list_unmap_asan_shadow(struct rte_memseg_list *msl);
+#endif
+
 /**
  * Distribute available memory between MSLs.
  *
diff --git a/lib/eal/linux/eal_memalloc.c b/lib/eal/linux/eal_memalloc.c
index f8b1588cae..5212ae6b56 100644
--- a/lib/eal/linux/eal_memalloc.c
+++ b/lib/eal/linux/eal_memalloc.c
@@ -511,6 +511,13 @@ resize_hugefile(int fd, uint64_t fa_offset, uint64_t 
page_sz, bool grow,
grow, dirty);
 }
 
+__rte_no_asan
+static inline void
+page_fault(void *addr)
+{
+   *(volatile int *)addr = *(volatile int *)addr;
+}
+
 static int
 alloc_seg(struct rte_memseg *ms, void *addr, int socket_id,
struct hugepage_info *hi, unsigned int list_idx,
@@ -641,7 +648,7 @@ alloc_seg(struct rte_memseg *ms, void *addr, int socket_id,
 * that is already there, so read the old value, and write itback.
 * kernel populates the page with zeroes initially.
 */
-   *(volatile int *)addr = *(volatile int *)addr;
+   page_fault(addr);
 
iova = rte_mem_virt2iova(addr);
if (iova == RTE_BAD_PHYS_ADDR) {
diff --git a/lib/eal/linux/eal_memory.c b/lib/eal/linux/eal_memory.c
index 9b6f08fba8..3dca532874 100644
--- a/lib/eal/linux/eal_memory.c
+++ b/lib/eal/linux/eal_memory.c
@@ -41,6 +41,7 @@
 #include "eal_filesystem.h"
 #include "eal_hugepages.h"
 #include "eal_options.h"
+#include "malloc_elem.h"
 
 #define PFN_MASK_SIZE  8
 
@@ -1469,6 +1470,9 @@ eal_legacy_hugepage_init(void)
if (msl->memseg_arr.count > 0)
continue;
/* this is an unused list, deallocate it */
+#ifdef RTE_MALLOC_ASAN
+   eal_memseg_list_unmap_asan_shadow(msl);
+#endif
mem_sz = msl->len;
munmap(msl->base_va, mem_sz);
msl->base_va = NULL;
@@ -1956,3 +1960,96 @@ rte_eal_memseg_init(void)
 #endif
memseg_secondary_init();
 }
+
+#ifdef RTE_MALLOC_ASAN
+int
+eal_memseg_list_map_asan_shadow(struct rte_memseg_list *msl)
+{
+

Re: [PATCH] mem: allow using ASan in multi-process mode

2023-10-09 Thread Artur Paszkiewicz


On 10/4/23 16:51, David Marchand wrote:

- did you test with --in-memory mode? with --no-huge?


Please see v2 of the patch. I added checks for these options. They imply
no multi-process support so mapping is skipped for those cases.


- I did not look at the patch, but I wonder if there is a risk some
"local" ASan region (for the process heap, for example) can overlap
with some "shared" ASan region (for shared DPDK hugepages).


I don't think it's possible unless the actual memory regions overlap.
The ASan shadow region is always at a fixed offset from the memory it
shadows. Also, this patch only makes the shadow regions shared, ASan
instrumentation already uses these regions.


- with this work, would unit tests (that were marked failing with
ASan) be ok now? See REGISTER_FAST_TEST macro in app/test.


I tried enabling these tests and some of them started passing with this
patch, namely:
- multiprocess_autotest
- eal_flags_c_opt_autotest
- eal_flags_main_opt_autotest
- eal_flags_a_opt_autotest

eal_flags_file_prefix_autotest still fails. The rest seem to be passing
even without the patch.

Regards,
Artur

RE: [PATCH v4 0/5] support item NSH matching

2023-10-09 Thread Raslan Darawsheh

Hi,

> -Original Message-
> From: Haifei Luo 
> Sent: Sunday, October 8, 2023 6:10 AM
> To: dev@dpdk.org
> Cc: Ori Kam ; Slava Ovsiienko ;
> Raslan Darawsheh ; Xueming(Steven) Li
> ; Haifei Luo 
> Subject: [PATCH v4 0/5] support item NSH matching
> 
> NSH can be matched using the existed item: RTE_FLOW_ITEM_TYPE_NSH.
> NSH fields matching is not supported.
> 
> Add support for configuring VXLAN-GPE's next protocol.
> The CLI is: vxlan-gpe protocol is .
> 
> Add support for matching item NSH. The CLI is: nsh Add support for HCA
> attribute query of NSH.
> 
> Enhance the validation for the case matching item NSH is supported.
> Add NSH support in net/mlx5.
> 
> V2: Add Ack info in commit message.
> V3: Add more Ack in commi message.
> V4: Add nsh in feature ini file.
> 
> Haifei Luo (5):
>   app/testpmd: support for VXLAN-GPE's next protocol
>   common/mlx5: extend HCA attribute query for NSH
>   net/mlx5: enhance the validation for item VXLAN-GPE
>   app/testpmd: support for NSH flow item
>   net/mlx5: add support for item NSH
> 
>  app/test-pmd/cmdline_flow.c  | 26 ++
>  doc/guides/nics/features/mlx5.ini|  1 +
>  drivers/common/mlx5/mlx5_devx_cmds.c |  3 ++
> drivers/common/mlx5/mlx5_devx_cmds.h |  1 +
>  drivers/common/mlx5/mlx5_prm.h   |  4 ++-
>  drivers/net/mlx5/mlx5_flow.c | 52 
>  drivers/net/mlx5/mlx5_flow.h |  6 
>  drivers/net/mlx5/mlx5_flow_dv.c  | 13 ++-
>  8 files changed, 97 insertions(+), 9 deletions(-)
> 
> --
> 2.27.0

Series applied to next-net-mlx,
Replied originally to V2
Now to the correct version !

Kindest regards,
Raslan Darawsheh

RE: [EXT] Re: [PATCH v3 1/2] dmadev: offload to free source buffer

2023-10-09 Thread Amit Prakash Shukla

Hi Chengwen,

Ack, I will make the changes in next version of the patch.

Thanks,
Amit Shukla

> -Original Message-
> From: fengchengwen 
> Sent: Monday, October 9, 2023 2:29 PM
> To: Amit Prakash Shukla ; Kevin Laatz
> ; Bruce Richardson 
> Cc: dev@dpdk.org; Jerin Jacob Kollanukkaran ;
> m...@smartsharesystems.com; conor.wa...@intel.com; Vamsi Krishna
> Attunuru ; g.si...@nxp.com;
> sachin.sax...@oss.nxp.com; hemant.agra...@nxp.com;
> cheng1.ji...@intel.com; Nithin Kumar Dabilpuram
> ; Anoob Joseph 
> Subject: Re: [EXT] Re: [PATCH v3 1/2] dmadev: offload to free source buffer
> 
> Hi Amit,
> 
>   Rethink again, I suggest use auto-free to denote this feature.
> 
> So we could re-define as:
>   RTE_DMA_CAPA_M2D_AUTO_FREE
>   RTE_DMA_OP_FLAG_AUTO_FREE
> 
> struct rte_dma_auto_free_param {
>   union {
>   struct {
>   struct rte_mempool *pool;
>   } m2d;
>   };
>   uint64_t reserved[2]; /**< Reserved for future fields. */ }; };
> note: because one vchan only support one DMA direction, so we could use
> union.
> 
> struct rte_dma_vchan_conf {
>   enum rte_dma_direction direction;
>   struct rte_dma_port_param src_port;
>   struct rte_dma_port_param dst_port;
>   struct rte_dma_auto_free_param auto_free; };
> 
> 
> As for later extension, if support other type auto-free, so could:
> 1. add one capa: RTE_DMA_CAPA_XXX_AUTO_FREE 2. modify
> rte_dma_auto_free_param:
>struct rte_dma_auto_free_param {
>   union {
>   struct {
>   struct rte_mempool *pool;
>   } m2d;
>   struct {
>   // params;
>   } xxx;
>   };
>   uint64_t reserved[2]; /**< Reserved for future fields. */ };
> };
> 
> 
> Thanks.
>

[PATCH v4 0/2] offload support to auto free dma buffer

2023-10-09 Thread Amit Prakash Shukla

This series adds offload support to auto free buffer in dma library
and adds a test support in dmadev_autotest to validate the functionality.

v4:
- Resolved review comments.

v3:
- Removed unwanted comment from code.

v2:
- Resolved review comments.
- Fixed compilation issue.

v1:
- Implementation from RFC.
- Add test support to validate functionality.

Amit Prakash Shukla (2):
  dmadev: offload to auto free DMA buffer
  test/dma: auto free offload test to free DMA buffer

 app/test/test_dmadev.c  | 167 +++-
 lib/dmadev/rte_dmadev.h |  43 +++
 2 files changed, 209 insertions(+), 1 deletion(-)

-- 
2.25.1

[PATCH v4 1/2] dmadev: offload to auto free DMA buffer

2023-10-09 Thread Amit Prakash Shukla

This changeset adds support in DMA library to auto free DMA buffer by
hardware. On a supported hardware, application can pass on the mempool
information as part of vchan config.

Signed-off-by: Amit Prakash Shukla 
Acked-by: Morten Brørup 
Acked-by: Anoob Joseph 
---
 lib/dmadev/rte_dmadev.h | 43 +
 1 file changed, 43 insertions(+)

diff --git a/lib/dmadev/rte_dmadev.h b/lib/dmadev/rte_dmadev.h
index b157ab7600..493263a5d6 100644
--- a/lib/dmadev/rte_dmadev.h
+++ b/lib/dmadev/rte_dmadev.h
@@ -269,6 +269,14 @@ int16_t rte_dma_next_dev(int16_t start_dev_id);
  * must ensure that all memory addresses are valid and accessible by HW.
  */
 #define RTE_DMA_CAPA_HANDLES_ERRORSRTE_BIT64(6)
+/** Support auto free for source buffer once mem to dev transfer is completed.
+ *
+ * @note Even though the DMA driver has this capability, it may not support all
+ * mempool drivers. If the mempool is not supported by the DMA driver,
+ * rte_dma_vchan_setup() will fail.
+ */
+#define RTE_DMA_CAPA_M2D_AUTO_FREE  RTE_BIT64(7)
+
 /** Support copy operation.
  * This capability start with index of 32, so that it could leave gap between
  * normal capability and ops capability.
@@ -552,6 +560,26 @@ struct rte_dma_port_param {
uint64_t reserved[2]; /**< Reserved for future fields. */
 };
 
+/**
+ * A structure used for offload auto free params.
+ */
+struct rte_dma_auto_free_param {
+   union {
+   struct {
+   /**
+* Mempool from which buffer is allocated. Mempool info
+* is used for freeing buffer by hardware.
+*
+* @note If the mempool is not supported by the DMA 
device,
+* rte_dma_vchan_setup() will fail.
+*/
+   struct rte_mempool *pool;
+   } m2d;
+   };
+   /** Reserved for future fields. */
+   uint64_t reserved[2];
+};
+
 /**
  * A structure used to configure a virtual DMA channel.
  *
@@ -581,6 +609,14 @@ struct rte_dma_vchan_conf {
 * @see struct rte_dma_port_param
 */
struct rte_dma_port_param dst_port;
+   /** Buffer params to auto free buffer by hardware. To free the buffer
+* by hardware, RTE_DMA_OP_FLAG_AUTO_FREE must be set while calling
+* rte_dma_copy and rte_dma_copy_sg().
+*
+* @see RTE_DMA_OP_FLAG_AUTO_FREE
+* @see struct rte_dma_auto_free_param
+*/
+   struct rte_dma_auto_free_param auto_free;
 };
 
 /**
@@ -818,6 +854,13 @@ struct rte_dma_sge {
  * capability bit for this, driver should not return error if this flag was 
set.
  */
 #define RTE_DMA_OP_FLAG_LLC RTE_BIT64(2)
+/** Auto free buffer flag.
+ * Operation with this flag must issue command to hardware to free the DMA
+ * buffer after DMA transfer is completed.
+ *
+ * @see struct rte_dma_vchan_conf::auto_free
+ */
+#define RTE_DMA_OP_FLAG_AUTO_FREE  RTE_BIT64(3)
 /**@}*/
 
 /**
-- 
2.25.1

[PATCH v4 2/2] test/dma: auto free offload test to free DMA buffer

2023-10-09 Thread Amit Prakash Shukla

Add a test case to validate the functionality of drivers' dma
buffer offload auto free. As part of dmadev_autotest, test case
will be executed only if the driver supports buffer offload auto
free and if the test is exported by env variable DPDK_ADD_DMA_TEST.

Signed-off-by: Amit Prakash Shukla 
Acked-by: Anoob Joseph 
---
 app/test/test_dmadev.c | 167 -
 1 file changed, 166 insertions(+), 1 deletion(-)

diff --git a/app/test/test_dmadev.c b/app/test/test_dmadev.c
index 6ef875e545..216f84b6bb 100644
--- a/app/test/test_dmadev.c
+++ b/app/test/test_dmadev.c
@@ -18,11 +18,37 @@
 
 #define ERR_RETURN(...) do { print_err(__func__, __LINE__, __VA_ARGS__); 
return -1; } while (0)
 
+#define TEST_RINGSIZE 512
 #define COPY_LEN 1024
 
 static struct rte_mempool *pool;
 static uint16_t id_count;
 
+enum {
+   TEST_PARAM_REMOTE_ADDR = 0,
+   TEST_PARAM_MAX,
+};
+
+static const char * const dma_test_param[] = {
+   [TEST_PARAM_REMOTE_ADDR] = "remote_addr",
+};
+
+static uint64_t env_test_param[TEST_PARAM_MAX];
+
+enum {
+   TEST_M2D_AUTO_FREE = 0,
+   TEST_MAX,
+};
+
+struct dma_add_test {
+   const char *name;
+   bool enabled;
+};
+
+struct dma_add_test dma_add_test[] = {
+   [TEST_M2D_AUTO_FREE] = {.name = "m2d_auto_free", .enabled = false},
+};
+
 static void
 __rte_format_printf(3, 4)
 print_err(const char *func, int lineno, const char *format, ...)
@@ -797,10 +823,103 @@ test_burst_capacity(int16_t dev_id, uint16_t vchan)
return 0;
 }
 
+static int
+test_m2d_auto_free(int16_t dev_id, uint16_t vchan)
+{
+#define NR_MBUF 256
+   struct rte_mbuf *src[NR_MBUF], *dst[NR_MBUF];
+   const struct rte_dma_vchan_conf qconf = {
+   .direction = RTE_DMA_DIR_MEM_TO_DEV,
+   .nb_desc = TEST_RINGSIZE,
+   .auto_free.m2d.pool = pool,
+   .dst_port.port_type = RTE_DMA_PORT_PCIE,
+   .dst_port.pcie.coreid = 0,
+   };
+   uint32_t buf_cnt1, buf_cnt2;
+   struct rte_mempool_ops *ops;
+   static bool dev_init;
+   uint16_t nb_done = 0;
+   bool dma_err = false;
+   int retry = 100;
+   int i, ret = 0;
+
+   if (!dev_init) {
+   /* Stop the device to reconfigure vchan. */
+   if (rte_dma_stop(dev_id) < 0)
+   ERR_RETURN("Error stopping device %u\n", dev_id);
+
+   if (rte_dma_vchan_setup(dev_id, vchan, &qconf) < 0)
+   ERR_RETURN("Error with queue configuration\n");
+
+   if (rte_dma_start(dev_id) != 0)
+   ERR_RETURN("Error with rte_dma_start()\n");
+
+   dev_init = true;
+   }
+
+   if (rte_pktmbuf_alloc_bulk(pool, dst, NR_MBUF) != 0)
+   ERR_RETURN("alloc dst mbufs failed.\n");
+
+   for (i = 0; i < NR_MBUF; i++) {
+   /* Using mbuf structure to hold remote iova address. */
+   rte_mbuf_iova_set(dst[i], 
(rte_iova_t)env_test_param[TEST_PARAM_REMOTE_ADDR]);
+   dst[i]->data_off = 0;
+   }
+
+   /* Capture buffer count before allocating source buffer. */
+   ops = rte_mempool_get_ops(pool->ops_index);
+   buf_cnt1 = ops->get_count(pool);
+
+   if (rte_pktmbuf_alloc_bulk(pool, src, NR_MBUF) != 0) {
+   printf("alloc src mbufs failed.\n");
+   ret = -1;
+   goto done;
+   }
+
+   if ((buf_cnt1 - NR_MBUF) != ops->get_count(pool)) {
+   printf("Buffer count check failed.\n");
+   ret = -1;
+   goto done;
+   }
+
+   for (i = 0; i < NR_MBUF; i++) {
+   ret = rte_dma_copy(dev_id, vchan, rte_mbuf_data_iova(src[i]),
+  rte_mbuf_data_iova(dst[i]), COPY_LEN,
+  RTE_DMA_OP_FLAG_AUTO_FREE);
+
+   if (ret < 0) {
+   printf("rte_dma_copy returned error.\n");
+   goto done;
+   }
+   }
+
+   rte_dma_submit(dev_id, vchan);
+   do {
+   nb_done += rte_dma_completed(dev_id, vchan, (NR_MBUF - 
nb_done), NULL, &dma_err);
+   if (dma_err)
+   break;
+   /* Sleep for 1 millisecond */
+   rte_delay_us_sleep(1000);
+   } while (retry-- && (nb_done < NR_MBUF));
+
+   buf_cnt2 = ops->get_count(pool);
+   if ((buf_cnt1 != buf_cnt2) || dma_err) {
+   printf("Free mem to dev buffer test failed.\n");
+   ret = -1;
+   }
+
+done:
+   rte_pktmbuf_free_bulk(dst, NR_MBUF);
+   /* If the test passes source buffer will be freed in hardware. */
+   if (ret < 0)
+   rte_pktmbuf_free_bulk(&src[nb_done], (NR_MBUF - nb_done));
+
+   return ret;
+}
+
 static int
 test_dmadev_instance(int16_t dev_id)
 {
-#define TEST_RINGSIZE 512
 #define CHECK_ERRStrue
struct rte_dma_stats stats;
struct rte_dma_info info;
@@

[PATCH] net/virtio: fixed missing next flag when sending packets in packed mode

2023-10-09 Thread liufengjiang.0426

When the packets is sent in packed mode, and the packets data and
virtio-header are divided into two desc, set the next flag of virtio-header desc

Bugzilla ID: 1295
Fixes: 892dc798fa9c ("net/virtio: implement Tx path for packed queues")

Signed-off-by: liufengjiang.0426 
---
 drivers/net/virtio/virtqueue.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/virtio/virtqueue.h b/drivers/net/virtio/virtqueue.h
index 9d4aba11a3..4e9f2d0358 100644
--- a/drivers/net/virtio/virtqueue.h
+++ b/drivers/net/virtio/virtqueue.h
@@ -672,6 +672,7 @@ virtqueue_enqueue_xmit_packed(struct virtnet_tx *txvq, 
struct rte_mbuf *cookie,
 */
start_dp[idx].addr = txvq->hdr_mem + 
RTE_PTR_DIFF(&txr[idx].tx_hdr, txr);
start_dp[idx].len = vq->hw->vtnet_hdr_size;
+   head_flags |= VRING_DESC_F_NEXT;
hdr = (struct virtio_net_hdr *)&txr[idx].tx_hdr;
idx++;
if (idx >= vq->vq_nentries) {
-- 
2.37.0.windows.1

Re: DPDK Release Status Meeting 2023-10-05

2023-10-09 Thread Ferruh Yigit

On 10/5/2023 10:04 AM, Mcnamara, John wrote:
> Release status meeting minutes 2023-10-05
> =
>  
> Agenda:
> * Release Dates
> * Subtrees
> * Roadmaps
> * LTS
> * Defects
> * Opens
>  
> Participants:
> * AMD
> * Intel
> * Marvell
> * Nvidia
> * Red Hat
>  
> Release Dates
> -
>  
> The following are the current working dates for 23.11:
>  
> * V1:  12 August 2023
> * RC1: 11 October 2023
> * RC2: 27 October 2023
> * RC3:  3 November 2023
> * Release: 15 November 2023
>  
>  
> Subtrees
> 
>  
> * next-net
>   * Initial pull done.
>   * Working on the rest of the tree.
>   * There are still a number of rte_flow patches pending merge but not having 
> reviews
>

I created two public bundles for rte flow patches waiting for review,

1) rte_flow patches:
https://patchwork.dpdk.org/bundle/fyigit/rte_flow_v23.11/

2) rte_flow related testpmd patches:
https://patchwork.dpdk.org/bundle/fyigit/rte_flow_testpmd_v23.11/


Can you please help/support reviewing these patches?

Thanks in advance,
ferruh

[PATCH v3] power: support amd-pstate cpufreq driver

2023-10-09 Thread Sivaprasad Tummala

amd-pstate introduces a new CPU frequency control mechanism for AMD
EPYC processors using the ACPI Collaborative Performance Power Control
feature for a finer grained frequency management.

Patch to add support for amd-pstate driver.

Signed-off-by: Sivaprasad Tummala 
Acked-by: Anatoly Burakov 
---
v3:
1. replaced __atomic_xxx built-ins with rte_atomic_xxx
2. fixed typo

v2:
1. error logged when scaling min freq exceeds max freq
2. workaound in test app to allow frequency deviation of up to 50Mhz
2. fixed indentation in release notes
---
 app/test/test_power.c  |   1 +
 app/test/test_power_cpufreq.c  |  13 +-
 doc/guides/rel_notes/release_23_11.rst |   4 +
 examples/l3fwd-power/main.c|   3 +
 lib/power/meson.build  |   1 +
 lib/power/power_amd_pstate_cpufreq.c   | 701 +
 lib/power/power_amd_pstate_cpufreq.h   | 219 
 lib/power/rte_power.c  |  26 +
 lib/power/rte_power.h  |   3 +-
 lib/power/rte_power_pmd_mgmt.c |   6 +-
 10 files changed, 973 insertions(+), 4 deletions(-)
 create mode 100644 lib/power/power_amd_pstate_cpufreq.c
 create mode 100644 lib/power/power_amd_pstate_cpufreq.h

diff --git a/app/test/test_power.c b/app/test/test_power.c
index 02ebc54d19..f1e80299d3 100644
--- a/app/test/test_power.c
+++ b/app/test/test_power.c
@@ -134,6 +134,7 @@ test_power(void)
const enum power_management_env envs[] = {PM_ENV_ACPI_CPUFREQ,
PM_ENV_KVM_VM,
PM_ENV_PSTATE_CPUFREQ,
+   PM_ENV_AMD_PSTATE_CPUFREQ,
PM_ENV_CPPC_CPUFREQ};
 
unsigned int i;
diff --git a/app/test/test_power_cpufreq.c b/app/test/test_power_cpufreq.c
index 10755a0d41..b050c47864 100644
--- a/app/test/test_power_cpufreq.c
+++ b/app/test/test_power_cpufreq.c
@@ -93,6 +93,17 @@ check_cur_freq(unsigned int lcore_id, uint32_t idx, bool 
turbo)
freq_conv = (cur_freq + TEST_FREQ_ROUNDING_DELTA)
/ TEST_ROUND_FREQ_TO_N_10;
freq_conv = freq_conv * TEST_ROUND_FREQ_TO_N_10;
+   } else if (env == PM_ENV_AMD_PSTATE_CPUFREQ) {
+   freq_conv = cur_freq > freqs[idx] ? (cur_freq - 
freqs[idx]) :
+   (freqs[idx] - cur_freq);
+   if (freq_conv <= TEST_FREQ_ROUNDING_DELTA) {
+   /* workaround: current frequency may deviate 
from
+* nominal freq. Allow deviation of up to 50Mhz.
+*/
+   printf("current frequency deviated from nominal 
"
+   "frequency by %d Khz!\n", freq_conv);
+   freq_conv = freqs[idx];
+   }
}
 
if (turbo)
@@ -502,7 +513,7 @@ test_power_cpufreq(void)
/* Test environment configuration */
env = rte_power_get_env();
if ((env != PM_ENV_ACPI_CPUFREQ) && (env != PM_ENV_PSTATE_CPUFREQ) &&
-   (env != PM_ENV_CPPC_CPUFREQ)) {
+   (env != PM_ENV_CPPC_CPUFREQ) && (env != 
PM_ENV_AMD_PSTATE_CPUFREQ)) {
printf("Unexpectedly got an environment other than 
ACPI/PSTATE\n");
goto fail_all;
}
diff --git a/doc/guides/rel_notes/release_23_11.rst 
b/doc/guides/rel_notes/release_23_11.rst
index eaa1d58f32..63c3d5bbaf 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -80,6 +80,10 @@ New Features
   device is different from the Tx Ethernet device with respective driver
   callback functions in ``rte_eth_recycle_mbufs``.
 
+* **Added amd-pstate driver support to power management library.**
+
+  Added support for amd-pstate driver which works on AMD EPYC processors.
+
 * **Updated Solarflare net driver.**
 
   * Added support for transfer flow action ``INDIRECT`` with subtype 
``VXLAN_ENCAP``.
diff --git a/examples/l3fwd-power/main.c b/examples/l3fwd-power/main.c
index 3f01cbd9e2..b9bec79cb2 100644
--- a/examples/l3fwd-power/main.c
+++ b/examples/l3fwd-power/main.c
@@ -2245,6 +2245,7 @@ init_power_library(void)
env = rte_power_get_env();
if (env != PM_ENV_ACPI_CPUFREQ &&
env != PM_ENV_PSTATE_CPUFREQ &&
+   env != PM_ENV_AMD_PSTATE_CPUFREQ &&
env != PM_ENV_CPPC_CPUFREQ) {
RTE_LOG(ERR, POWER,
"Only ACPI, PSTATE and CPPC mode are 
supported\n");
@@ -2417,6 +2418,8 @@ autodetect_mode(void)
return APP_MODE_LEGACY;
if (rte_power_check_env_supported(PM_ENV_PSTATE_CPUFREQ))
return APP_MODE_LEGACY;
+   if (rte_power_check_env_supported(PM_ENV_AMD_PSTATE_CP

[PATCH v4 0/7] cryptodev: support digest message in SM2

2023-10-09 Thread Gowrishankar Muthukrishnan

This patch series fixes SM2 algorithm implementation to
support digest message as input along with plain message
as today.

v4:
 - code rebase on next-crypto

Gowrishankar Muthukrishnan (7):
  crypto/openssl: include SM2 in asymmetric capabilities
  cryptodev: add hash algorithms in asymmetric capability
  cryptodev: use generic EC xform params for SM2
  cryptodev: set private and public keys in EC session
  cryptodev: add RNG capability in EC based xform
  crypto/cnxk: add SM2 support
  app/test: check asymmetric capabilities in SM2 test

 app/test/test_cryptodev_asym.c| 197 -
 app/test/test_cryptodev_sm2_test_vectors.h|  32 ++-
 doc/guides/cryptodevs/features/cn10k.ini  |   1 +
 doc/guides/rel_notes/release_23_11.rst|   6 +
 drivers/common/cnxk/hw/cpt.h  |   2 +-
 drivers/common/cnxk/roc_ae.c  |  32 ++-
 drivers/common/cnxk/roc_ae.h  |  21 +-
 drivers/common/cnxk/roc_ae_fpm_tables.c   | 190 +
 drivers/common/cpt/cpt_mcode_defines.h|  18 ++
 drivers/common/cpt/cpt_ucode_asym.h   |  22 +-
 drivers/crypto/cnxk/cnxk_ae.h | 269 +-
 drivers/crypto/cnxk/cnxk_cryptodev.h  |   2 +-
 .../crypto/cnxk/cnxk_cryptodev_capabilities.c |  17 ++
 drivers/crypto/openssl/rte_openssl_pmd.c  |  53 +---
 drivers/crypto/openssl/rte_openssl_pmd_ops.c  |  55 +++-
 drivers/crypto/qat/qat_asym.c |   6 +-
 examples/fips_validation/main.c   |  14 +-
 lib/cryptodev/cryptodev_trace.h   |   9 +
 lib/cryptodev/cryptodev_trace_points.c|   3 +
 lib/cryptodev/rte_crypto_asym.h   |  33 +--
 lib/cryptodev/rte_cryptodev.c |  16 ++
 lib/cryptodev/rte_cryptodev.h |  25 ++
 lib/cryptodev/version.map |   1 +
 23 files changed, 828 insertions(+), 196 deletions(-)

-- 
2.25.1

[PATCH v4 1/7] crypto/openssl: include SM2 in asymmetric capabilities

2023-10-09 Thread Gowrishankar Muthukrishnan

Include SM2 algorithm in the asymmetric capabilities supported
by OpenSSL PMD.

Fixes: 3b7d638fb11f ("crypto/openssl: support asymmetric SM2")

Signed-off-by: Gowrishankar Muthukrishnan 
Acked-by: Arkadiusz Kusztal 
---
 drivers/crypto/openssl/rte_openssl_pmd_ops.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/crypto/openssl/rte_openssl_pmd_ops.c 
b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
index 85a4fa3e55..2eb450fcfd 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd_ops.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
@@ -593,6 +593,20 @@ static const struct rte_cryptodev_capabilities 
openssl_pmd_capabilities[] = {
},
}
},
+   {   /* SM2 */
+   .op = RTE_CRYPTO_OP_TYPE_ASYMMETRIC,
+   {.asym = {
+   .xform_capa = {
+   .xform_type = RTE_CRYPTO_ASYM_XFORM_SM2,
+   .op_types =
+   ((1<

[PATCH v4 2/7] cryptodev: add hash algorithms in asymmetric capability

2023-10-09 Thread Gowrishankar Muthukrishnan

Most of the asymmetric operations start with hash of the input.
But a PMD might also support only plain input (eg openssl).
Add a new field in asymmetric capability to declare support
for hash operations that PMD can support for the asymmetric
operations. Application can skip computing hash if PMD already
supports it.

Signed-off-by: Gowrishankar Muthukrishnan 
---
 app/test/test_cryptodev_asym.c   | 52 ++--
 drivers/crypto/openssl/rte_openssl_pmd_ops.c |  1 +
 lib/cryptodev/cryptodev_trace.h  |  9 
 lib/cryptodev/cryptodev_trace_points.c   |  3 ++
 lib/cryptodev/rte_cryptodev.c| 16 ++
 lib/cryptodev/rte_cryptodev.h| 19 +++
 lib/cryptodev/version.map|  1 +
 7 files changed, 97 insertions(+), 4 deletions(-)

diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index 39de0bdac5..af323e02d9 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -1810,8 +1810,10 @@ _test_sm2_sign(bool rnd_secret)
 {
struct crypto_testsuite_params_asym *ts_params = &testsuite_params;
struct crypto_testsuite_sm2_params input_params = sm2_param_fp256;
+   const struct rte_cryptodev_asymmetric_xform_capability *capa;
struct rte_mempool *sess_mpool = ts_params->session_mpool;
struct rte_mempool *op_mpool = ts_params->op_mpool;
+   struct rte_cryptodev_asym_capability_idx idx;
uint8_t dev_id = ts_params->valid_devs[0];
struct rte_crypto_op *result_op = NULL;
uint8_t output_buf_r[TEST_DATA_SIZE];
@@ -1822,6 +1824,12 @@ _test_sm2_sign(bool rnd_secret)
int ret, status = TEST_SUCCESS;
void *sess = NULL;
 
+   /* Check SM2 capability */
+   idx.type = RTE_CRYPTO_ASYM_XFORM_SM2;
+   capa = rte_cryptodev_asym_capability_get(dev_id, &idx);
+   if (capa == NULL)
+   return -ENOTSUP;
+
/* Setup crypto op data structure */
op = rte_crypto_op_alloc(op_mpool, RTE_CRYPTO_OP_TYPE_ASYMMETRIC);
if (op == NULL) {
@@ -1838,7 +1846,10 @@ _test_sm2_sign(bool rnd_secret)
/* Setup asym xform */
xform.next = NULL;
xform.xform_type = RTE_CRYPTO_ASYM_XFORM_SM2;
-   xform.sm2.hash = RTE_CRYPTO_AUTH_SM3;
+   if (rte_cryptodev_asym_xform_capability_check_hash(capa, 
RTE_CRYPTO_AUTH_SM3))
+   xform.sm2.hash = RTE_CRYPTO_AUTH_SM3;
+   else
+   xform.sm2.hash = RTE_CRYPTO_AUTH_NULL;
 
ret = rte_cryptodev_asym_session_create(dev_id, &xform, sess_mpool, 
&sess);
if (ret < 0) {
@@ -1993,8 +2004,10 @@ test_sm2_verify(void)
 {
struct crypto_testsuite_params_asym *ts_params = &testsuite_params;
struct crypto_testsuite_sm2_params input_params = sm2_param_fp256;
+   const struct rte_cryptodev_asymmetric_xform_capability *capa;
struct rte_mempool *sess_mpool = ts_params->session_mpool;
struct rte_mempool *op_mpool = ts_params->op_mpool;
+   struct rte_cryptodev_asym_capability_idx idx;
uint8_t dev_id = ts_params->valid_devs[0];
struct rte_crypto_op *result_op = NULL;
struct rte_crypto_asym_xform xform;
@@ -2003,6 +2016,12 @@ test_sm2_verify(void)
int ret, status = TEST_SUCCESS;
void *sess = NULL;
 
+   /* Check SM2 capability */
+   idx.type = RTE_CRYPTO_ASYM_XFORM_SM2;
+   capa = rte_cryptodev_asym_capability_get(dev_id, &idx);
+   if (capa == NULL)
+   return -ENOTSUP;
+
/* Setup crypto op data structure */
op = rte_crypto_op_alloc(op_mpool, RTE_CRYPTO_OP_TYPE_ASYMMETRIC);
if (op == NULL) {
@@ -2019,7 +2038,10 @@ test_sm2_verify(void)
/* Setup asym xform */
xform.next = NULL;
xform.xform_type = RTE_CRYPTO_ASYM_XFORM_SM2;
-   xform.sm2.hash = RTE_CRYPTO_AUTH_SM3;
+   if (rte_cryptodev_asym_xform_capability_check_hash(capa, 
RTE_CRYPTO_AUTH_SM3))
+   xform.sm2.hash = RTE_CRYPTO_AUTH_SM3;
+   else
+   xform.sm2.hash = RTE_CRYPTO_AUTH_NULL;
 
ret = rte_cryptodev_asym_session_create(dev_id, &xform, sess_mpool, 
&sess);
if (ret < 0) {
@@ -2094,9 +2116,11 @@ _test_sm2_enc(bool rnd_secret)
 {
struct crypto_testsuite_params_asym *ts_params = &testsuite_params;
struct crypto_testsuite_sm2_params input_params = sm2_param_fp256;
+   const struct rte_cryptodev_asymmetric_xform_capability *capa;
struct rte_mempool *sess_mpool = ts_params->session_mpool;
struct rte_mempool *op_mpool = ts_params->op_mpool;
uint8_t output_buf[TEST_DATA_SIZE], *pbuf = NULL;
+   struct rte_cryptodev_asym_capability_idx idx;
uint8_t dev_id = ts_params->valid_devs[0];
struct rte_crypto_op *result_op = NULL;
struct rte_crypto_asym_xform xform;
@@ -2105,6 +2129,12 @@ _test_sm2_enc(bool rnd_secret)
int ret, status = TEST_SUCCESS;
void *sess = NULL;
 
+

[PATCH v4 3/7] cryptodev: use generic EC xform params for SM2

2023-10-09 Thread Gowrishankar Muthukrishnan

SM2 curve could use generic EC xform as it is yet another EC.
This would also require SM2 curve ID enumerated
along with other curves, as listed in:
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml

Signed-off-by: Gowrishankar Muthukrishnan 
Acked-by: Arkadiusz Kusztal 
---
 app/test/test_cryptodev_asym.c   | 40 
 app/test/test_cryptodev_sm2_test_vectors.h   |  4 +-
 doc/guides/rel_notes/release_23_11.rst   |  2 +
 drivers/crypto/openssl/rte_openssl_pmd_ops.c |  3 --
 lib/cryptodev/rte_crypto_asym.h  | 19 +++---
 5 files changed, 34 insertions(+), 34 deletions(-)

diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index af323e02d9..514ea96b8b 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -1846,10 +1846,7 @@ _test_sm2_sign(bool rnd_secret)
/* Setup asym xform */
xform.next = NULL;
xform.xform_type = RTE_CRYPTO_ASYM_XFORM_SM2;
-   if (rte_cryptodev_asym_xform_capability_check_hash(capa, 
RTE_CRYPTO_AUTH_SM3))
-   xform.sm2.hash = RTE_CRYPTO_AUTH_SM3;
-   else
-   xform.sm2.hash = RTE_CRYPTO_AUTH_NULL;
+   xform.ec.curve_id = input_params.curve;
 
ret = rte_cryptodev_asym_session_create(dev_id, &xform, sess_mpool, 
&sess);
if (ret < 0) {
@@ -1867,6 +1864,11 @@ _test_sm2_sign(bool rnd_secret)
 
/* Populate op with operational details */
asym_op->sm2.op_type = RTE_CRYPTO_ASYM_OP_SIGN;
+   if (rte_cryptodev_asym_xform_capability_check_hash(capa, 
RTE_CRYPTO_AUTH_SM3))
+   asym_op->sm2.hash = RTE_CRYPTO_AUTH_SM3;
+   else
+   asym_op->sm2.hash = RTE_CRYPTO_AUTH_NULL;
+
asym_op->sm2.message.data = input_params.message.data;
asym_op->sm2.message.length = input_params.message.length;
asym_op->sm2.pkey.data = input_params.pkey.data;
@@ -2038,10 +2040,7 @@ test_sm2_verify(void)
/* Setup asym xform */
xform.next = NULL;
xform.xform_type = RTE_CRYPTO_ASYM_XFORM_SM2;
-   if (rte_cryptodev_asym_xform_capability_check_hash(capa, 
RTE_CRYPTO_AUTH_SM3))
-   xform.sm2.hash = RTE_CRYPTO_AUTH_SM3;
-   else
-   xform.sm2.hash = RTE_CRYPTO_AUTH_NULL;
+   xform.ec.curve_id = input_params.curve;
 
ret = rte_cryptodev_asym_session_create(dev_id, &xform, sess_mpool, 
&sess);
if (ret < 0) {
@@ -2059,6 +2058,11 @@ test_sm2_verify(void)
 
/* Populate op with operational details */
asym_op->sm2.op_type = RTE_CRYPTO_ASYM_OP_VERIFY;
+   if (rte_cryptodev_asym_xform_capability_check_hash(capa, 
RTE_CRYPTO_AUTH_SM3))
+   asym_op->sm2.hash = RTE_CRYPTO_AUTH_SM3;
+   else
+   asym_op->sm2.hash = RTE_CRYPTO_AUTH_NULL;
+
asym_op->sm2.message.data = input_params.message.data;
asym_op->sm2.message.length = input_params.message.length;
asym_op->sm2.pkey.data = input_params.pkey.data;
@@ -2150,10 +2154,7 @@ _test_sm2_enc(bool rnd_secret)
/* Setup asym xform */
xform.next = NULL;
xform.xform_type = RTE_CRYPTO_ASYM_XFORM_SM2;
-   if (rte_cryptodev_asym_xform_capability_check_hash(capa, 
RTE_CRYPTO_AUTH_SM3))
-   xform.sm2.hash = RTE_CRYPTO_AUTH_SM3;
-   else
-   xform.sm2.hash = RTE_CRYPTO_AUTH_NULL;
+   xform.ec.curve_id = input_params.curve;
 
ret = rte_cryptodev_asym_session_create(dev_id, &xform, sess_mpool, 
&sess);
if (ret < 0) {
@@ -2171,6 +2172,11 @@ _test_sm2_enc(bool rnd_secret)
 
/* Populate op with operational details */
asym_op->sm2.op_type = RTE_CRYPTO_ASYM_OP_ENCRYPT;
+   if (rte_cryptodev_asym_xform_capability_check_hash(capa, 
RTE_CRYPTO_AUTH_SM3))
+   asym_op->sm2.hash = RTE_CRYPTO_AUTH_SM3;
+   else
+   asym_op->sm2.hash = RTE_CRYPTO_AUTH_NULL;
+
asym_op->sm2.message.data = input_params.message.data;
asym_op->sm2.message.length = input_params.message.length;
asym_op->sm2.pkey.data = input_params.pkey.data;
@@ -2340,10 +2346,7 @@ test_sm2_dec(void)
/* Setup asym xform */
xform.next = NULL;
xform.xform_type = RTE_CRYPTO_ASYM_XFORM_SM2;
-   if (rte_cryptodev_asym_xform_capability_check_hash(capa, 
RTE_CRYPTO_AUTH_SM3))
-   xform.sm2.hash = RTE_CRYPTO_AUTH_SM3;
-   else
-   xform.sm2.hash = RTE_CRYPTO_AUTH_NULL;
+   xform.ec.curve_id = input_params.curve;
 
ret = rte_cryptodev_asym_session_create(dev_id, &xform, sess_mpool, 
&sess);
if (ret < 0) {
@@ -2361,6 +2364,11 @@ test_sm2_dec(void)
 
/* Populate op with operational details */
asym_op->sm2.op_type = RTE_CRYPTO_ASYM_OP_DECRYPT;
+   if (rte_cryptodev_asym_xform_capability_check_hash(capa, 
RTE_CRYPTO_AUTH_SM3))
+   asym_op->sm2.hash = RTE_CRYPTO_AUTH_SM3;
+   else
+   asym_op->sm2.hash = RTE_

[PATCH v4 4/7] cryptodev: set private and public keys in EC session

2023-10-09 Thread Gowrishankar Muthukrishnan

Set EC private and public keys into xform so that, it can be
maintained per session.

Signed-off-by: Gowrishankar Muthukrishnan 
Acked-by: Ciara Power 
---
 app/test/test_cryptodev_asym.c   | 60 ++--
 drivers/common/cnxk/roc_ae.h | 18 ++
 drivers/common/cpt/cpt_mcode_defines.h   | 18 ++
 drivers/common/cpt/cpt_ucode_asym.h  | 22 +++
 drivers/crypto/cnxk/cnxk_ae.h| 37 
 drivers/crypto/openssl/rte_openssl_pmd.c | 53 +
 drivers/crypto/openssl/rte_openssl_pmd_ops.c | 35 
 drivers/crypto/qat/qat_asym.c|  6 +-
 examples/fips_validation/main.c  | 14 +++--
 lib/cryptodev/rte_crypto_asym.h  | 18 ++
 10 files changed, 158 insertions(+), 123 deletions(-)

diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index 514ea96b8b..a2bb1f9336 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -1503,6 +1503,12 @@ test_ecdsa_sign_verify(enum curve curve_id)
xform.next = NULL;
xform.xform_type = RTE_CRYPTO_ASYM_XFORM_ECDSA;
xform.ec.curve_id = input_params.curve;
+   xform.ec.pkey.data = input_params.pkey.data;
+   xform.ec.pkey.length = input_params.pkey.length;
+   xform.ec.q.x.data = input_params.pubkey_qx.data;
+   xform.ec.q.x.length = input_params.pubkey_qx.length;
+   xform.ec.q.y.data = input_params.pubkey_qy.data;
+   xform.ec.q.y.length = input_params.pubkey_qy.length;
 
ret = rte_cryptodev_asym_session_create(dev_id, &xform, sess_mpool, 
&sess);
if (ret < 0) {
@@ -1524,8 +1530,6 @@ test_ecdsa_sign_verify(enum curve curve_id)
op->asym->ecdsa.message.length = input_params.digest.length;
op->asym->ecdsa.k.data = input_params.scalar.data;
op->asym->ecdsa.k.length = input_params.scalar.length;
-   op->asym->ecdsa.pkey.data = input_params.pkey.data;
-   op->asym->ecdsa.pkey.length = input_params.pkey.length;
 
/* Init out buf */
op->asym->ecdsa.r.data = output_buf_r;
@@ -1582,10 +1586,6 @@ test_ecdsa_sign_verify(enum curve curve_id)
 
/* Populate op with operational details */
op->asym->ecdsa.op_type = RTE_CRYPTO_ASYM_OP_VERIFY;
-   op->asym->ecdsa.q.x.data = input_params.pubkey_qx.data;
-   op->asym->ecdsa.q.x.length = input_params.pubkey_qx.length;
-   op->asym->ecdsa.q.y.data = input_params.pubkey_qy.data;
-   op->asym->ecdsa.q.y.length = input_params.pubkey_qx.length;
op->asym->ecdsa.r.data = asym_op->ecdsa.r.data;
op->asym->ecdsa.r.length = asym_op->ecdsa.r.length;
op->asym->ecdsa.s.data = asym_op->ecdsa.s.data;
@@ -1847,6 +1847,12 @@ _test_sm2_sign(bool rnd_secret)
xform.next = NULL;
xform.xform_type = RTE_CRYPTO_ASYM_XFORM_SM2;
xform.ec.curve_id = input_params.curve;
+   xform.ec.pkey.data = input_params.pkey.data;
+   xform.ec.pkey.length = input_params.pkey.length;
+   xform.ec.q.x.data = input_params.pubkey_qx.data;
+   xform.ec.q.x.length = input_params.pubkey_qx.length;
+   xform.ec.q.y.data = input_params.pubkey_qy.data;
+   xform.ec.q.y.length = input_params.pubkey_qy.length;
 
ret = rte_cryptodev_asym_session_create(dev_id, &xform, sess_mpool, 
&sess);
if (ret < 0) {
@@ -1871,12 +1877,6 @@ _test_sm2_sign(bool rnd_secret)
 
asym_op->sm2.message.data = input_params.message.data;
asym_op->sm2.message.length = input_params.message.length;
-   asym_op->sm2.pkey.data = input_params.pkey.data;
-   asym_op->sm2.pkey.length = input_params.pkey.length;
-   asym_op->sm2.q.x.data = input_params.pubkey_qx.data;
-   asym_op->sm2.q.x.length = input_params.pubkey_qx.length;
-   asym_op->sm2.q.y.data = input_params.pubkey_qy.data;
-   asym_op->sm2.q.y.length = input_params.pubkey_qy.length;
asym_op->sm2.id.data = input_params.id.data;
asym_op->sm2.id.length = input_params.id.length;
if (rnd_secret) {
@@ -2041,6 +2041,12 @@ test_sm2_verify(void)
xform.next = NULL;
xform.xform_type = RTE_CRYPTO_ASYM_XFORM_SM2;
xform.ec.curve_id = input_params.curve;
+   xform.ec.pkey.data = input_params.pkey.data;
+   xform.ec.pkey.length = input_params.pkey.length;
+   xform.ec.q.x.data = input_params.pubkey_qx.data;
+   xform.ec.q.x.length = input_params.pubkey_qx.length;
+   xform.ec.q.y.data = input_params.pubkey_qy.data;
+   xform.ec.q.y.length = input_params.pubkey_qy.length;
 
ret = rte_cryptodev_asym_session_create(dev_id, &xform, sess_mpool, 
&sess);
if (ret < 0) {
@@ -2065,12 +2071,6 @@ test_sm2_verify(void)
 
asym_op->sm2.message.data = input_params.message.data;
asym_op->sm2.message.length = input_params.message.length;
-   asym_op->sm2.pkey.data = input_params.pkey.data;
-   asym_op->sm2.pkey.length = input_params.pkey.length;
-

[PATCH v4 5/7] cryptodev: add RNG capability in EC based xform

2023-10-09 Thread Gowrishankar Muthukrishnan

Elliptic curve based asymmetric operations use cryptographically
secure random number in its computation. If PMD supports RNG
for such ops, the application could skip computing on its own.
This patch adds new field in asymmetric capability to declare
this capability.

Signed-off-by: Gowrishankar Muthukrishnan 
Acked-by: Arkadiusz Kusztal 
---
 drivers/crypto/openssl/rte_openssl_pmd_ops.c | 2 ++
 lib/cryptodev/rte_cryptodev.h| 6 ++
 2 files changed, 8 insertions(+)

diff --git a/drivers/crypto/openssl/rte_openssl_pmd_ops.c 
b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
index 083ad63360..2862c294a9 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd_ops.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
@@ -604,6 +604,8 @@ static const struct rte_cryptodev_capabilities 
openssl_pmd_capabilities[] = {
 (1 << RTE_CRYPTO_ASYM_OP_VERIFY) |
 (1 << RTE_CRYPTO_ASYM_OP_ENCRYPT) |
 (1 << RTE_CRYPTO_ASYM_OP_DECRYPT)),
+   {.internal_rng = 1
+   }
}
}
}
diff --git a/lib/cryptodev/rte_cryptodev.h b/lib/cryptodev/rte_cryptodev.h
index 3a1b4dc501..6c8f532797 100644
--- a/lib/cryptodev/rte_cryptodev.h
+++ b/lib/cryptodev/rte_cryptodev.h
@@ -181,6 +181,12 @@ struct rte_cryptodev_asymmetric_xform_capability {
/**< Range of modulus length supported by modulus based xform.
 * Value 0 mean implementation default
 */
+
+   uint8_t internal_rng;
+   /**< Availability of random number generator for Elliptic curve 
based xform.
+* Value 0 means unavailable, and application should pass the 
required
+* random value. Otherwise, PMD would internally compute the 
random number.
+*/
};
 
uint64_t hash_algos;
-- 
2.25.1

[PATCH v4 6/7] crypto/cnxk: add SM2 support

2023-10-09 Thread Gowrishankar Muthukrishnan

Add SM2 asymmetric algorithm support in cnxk PMD.

Signed-off-by: Gowrishankar Muthukrishnan 
---
 doc/guides/cryptodevs/features/cn10k.ini  |   1 +
 doc/guides/rel_notes/release_23_11.rst|   4 +
 drivers/common/cnxk/hw/cpt.h  |   2 +-
 drivers/common/cnxk/roc_ae.c  |  32 ++-
 drivers/common/cnxk/roc_ae.h  |   3 +-
 drivers/common/cnxk/roc_ae_fpm_tables.c   | 190 ++
 drivers/crypto/cnxk/cnxk_ae.h | 232 +-
 drivers/crypto/cnxk/cnxk_cryptodev.h  |   2 +-
 .../crypto/cnxk/cnxk_cryptodev_capabilities.c |  17 ++
 9 files changed, 478 insertions(+), 5 deletions(-)

diff --git a/doc/guides/cryptodevs/features/cn10k.ini 
b/doc/guides/cryptodevs/features/cn10k.ini
index 53ee2a720e..4f542c6038 100644
--- a/doc/guides/cryptodevs/features/cn10k.ini
+++ b/doc/guides/cryptodevs/features/cn10k.ini
@@ -104,6 +104,7 @@ Modular Inversion   =
 Diffie-hellman  =
 ECDSA   = Y
 ECPM= Y
+SM2 = Y
 
 ;
 ; Supported Operating systems of the 'cn10k' crypto driver.
diff --git a/doc/guides/rel_notes/release_23_11.rst 
b/doc/guides/rel_notes/release_23_11.rst
index 53639543a6..401230a1c0 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -96,6 +96,10 @@ New Features
   Added support for DOCSIS security protocol through the ``rte_security`` API
   callbacks.
 
+* **Updated CNXK crypto driver.**
+
+  Added SM2 algorithm support in asymmetric crypto operations.
+
 
 Removed Items
 -
diff --git a/drivers/common/cnxk/hw/cpt.h b/drivers/common/cnxk/hw/cpt.h
index cad4ed7e79..cf9046bbfb 100644
--- a/drivers/common/cnxk/hw/cpt.h
+++ b/drivers/common/cnxk/hw/cpt.h
@@ -78,7 +78,7 @@ union cpt_eng_caps {
uint64_t __io sm4 : 1;
uint64_t __io reserved_23_34 : 12;
uint64_t __io sg_ver2 : 1;
-   uint64_t __io reserved36 : 1;
+   uint64_t __io sm2 : 1;
uint64_t __io pdcp_chain_zuc256 : 1;
uint64_t __io reserved_38_63 : 26;
};
diff --git a/drivers/common/cnxk/roc_ae.c b/drivers/common/cnxk/roc_ae.c
index 336b927641..e6a013d7c4 100644
--- a/drivers/common/cnxk/roc_ae.c
+++ b/drivers/common/cnxk/roc_ae.c
@@ -149,7 +149,37 @@ const struct roc_ae_ec_group ae_ec_grp[ROC_AE_EC_ID_PMAX] 
= {
 0xBF, 0x07, 0x35, 0x73, 0xDF, 0x88, 0x3D, 0x2C,
 0x34, 0xF1, 0xEF, 0x45, 0x1F, 0xD4, 0x6B, 0x50,
 0x3F, 0x00},
-   .length = 66}}};
+   .length = 66},
+   },
+   {},
+   {},
+   {},
+   {
+   .prime = {.data = {0xFF, 0xFF, 0xFF, 0xFE, 0xFF, 0xFF, 0xFF,
+  0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+  0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00,
+  0x00, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF,
+  0xFF, 0xFF, 0xFF, 0xFF},
+ .length = 32},
+   .order = {.data = {0xFF, 0xFF, 0xFF, 0xFE, 0xFF, 0xFF, 0xFF,
+  0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+  0xFF, 0xFF, 0x72, 0x03, 0xDF, 0x6B, 0x21,
+  0xC6, 0x05, 0x2B, 0x53, 0xBB, 0xF4, 0x09,
+  0x39, 0xD5, 0x41, 0x23},
+ .length = 32},
+   .consta = {.data = {0xFF, 0xFF, 0xFF, 0xFE, 0xFF, 0xFF, 0xFF,
+   0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+   0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00,
+   0x00, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF,
+   0xFF, 0xFF, 0xFF, 0xFC},
+  .length = 32},
+   .constb = {.data = {0x28, 0xE9, 0xFA, 0x9E, 0x9D, 0x9F, 0x5E,
+   0x34, 0x4D, 0x5A, 0x9E, 0x4B, 0xCF, 0x65,
+   0x09, 0xA7, 0xF3, 0x97, 0x89, 0xF5, 0x15,
+   0xAB, 0x8F, 0x92, 0xDD, 0xBC, 0xBD, 0x41,
+   0x4D, 0x94, 0x0E, 0x93},
+  .length = 32},
+   }};
 
 int
 roc_ae_ec_grp_get(struct roc_ae_ec_group **tbl)
diff --git a/drivers/common/cnxk/roc_ae.h b/drivers/common/cnxk/roc_ae.h
index d8ad0129b1..d459c5e680 100644
--- a/drivers/common/cnxk/roc_ae.h
+++ b/drivers/common/cnxk/roc_ae.h
@@ -34,7 +34,8 @@ typedef enum {
ROC_AE_EC_ID_P160 = 5,
ROC_AE_EC_ID_P320 = 6,
ROC_AE_EC_ID_P512 = 7,
-   ROC_AE_EC_ID_PMAX = 8
+   ROC_AE_EC_ID_SM2  = 8,
+   ROC_AE_EC_ID_PMAX
 } roc_ae_ec_id;
 
 /* Prime and order fields of built-in elliptic curves */
diff --git a/drivers/common/cnxk/roc_ae_fpm_tables.c 
b/d

[PATCH v4 7/7] app/test: check asymmetric capabilities in SM2 test

2023-10-09 Thread Gowrishankar Muthukrishnan

Check asymmetric capabilities such as SM3 hash support and
internal RNG and accordingly choose op params for SM2 test.

Signed-off-by: Gowrishankar Muthukrishnan 
Acked-by: Arkadiusz Kusztal 
---
 app/test/test_cryptodev_asym.c | 77 +++---
 app/test/test_cryptodev_sm2_test_vectors.h | 28 +---
 2 files changed, 57 insertions(+), 48 deletions(-)

diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index a2bb1f9336..94bb091df3 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -608,6 +608,7 @@ static inline void print_asym_capa(
break;
case RTE_CRYPTO_ASYM_XFORM_ECDSA:
case RTE_CRYPTO_ASYM_XFORM_ECPM:
+   case RTE_CRYPTO_ASYM_XFORM_SM2:
default:
break;
}
@@ -1806,7 +1807,7 @@ test_ecpm_all_curve(void)
 }
 
 static int
-_test_sm2_sign(bool rnd_secret)
+test_sm2_sign(void)
 {
struct crypto_testsuite_params_asym *ts_params = &testsuite_params;
struct crypto_testsuite_sm2_params input_params = sm2_param_fp256;
@@ -1875,11 +1876,19 @@ _test_sm2_sign(bool rnd_secret)
else
asym_op->sm2.hash = RTE_CRYPTO_AUTH_NULL;
 
-   asym_op->sm2.message.data = input_params.message.data;
-   asym_op->sm2.message.length = input_params.message.length;
-   asym_op->sm2.id.data = input_params.id.data;
-   asym_op->sm2.id.length = input_params.id.length;
-   if (rnd_secret) {
+   if (asym_op->sm2.hash == RTE_CRYPTO_AUTH_SM3) {
+   asym_op->sm2.message.data = input_params.message.data;
+   asym_op->sm2.message.length = input_params.message.length;
+   asym_op->sm2.id.data = input_params.id.data;
+   asym_op->sm2.id.length = input_params.id.length;
+   } else {
+   asym_op->sm2.message.data = input_params.digest.data;
+   asym_op->sm2.message.length = input_params.digest.length;
+   asym_op->sm2.id.data = NULL;
+   asym_op->sm2.id.length = 0;
+   }
+
+   if (capa->internal_rng != 0) {
asym_op->sm2.k.data = NULL;
asym_op->sm2.k.length = 0;
} else {
@@ -1928,7 +1937,7 @@ _test_sm2_sign(bool rnd_secret)
debug_hexdump(stdout, "s:",
asym_op->sm2.s.data, asym_op->sm2.s.length);
 
-   if (!rnd_secret) {
+   if (capa->internal_rng == 0) {
/* Verify sign (by comparison). */
if (memcmp(input_params.sign_r.data, asym_op->sm2.r.data,
   asym_op->sm2.r.length) != 0) {
@@ -1989,18 +1998,6 @@ _test_sm2_sign(bool rnd_secret)
return status;
 };
 
-static int
-test_sm2_sign_rnd_secret(void)
-{
-   return _test_sm2_sign(true);
-}
-
-__rte_used static int
-test_sm2_sign_plain_secret(void)
-{
-   return _test_sm2_sign(false);
-}
-
 static int
 test_sm2_verify(void)
 {
@@ -2064,19 +2061,28 @@ test_sm2_verify(void)
 
/* Populate op with operational details */
asym_op->sm2.op_type = RTE_CRYPTO_ASYM_OP_VERIFY;
+
if (rte_cryptodev_asym_xform_capability_check_hash(capa, 
RTE_CRYPTO_AUTH_SM3))
asym_op->sm2.hash = RTE_CRYPTO_AUTH_SM3;
else
asym_op->sm2.hash = RTE_CRYPTO_AUTH_NULL;
 
-   asym_op->sm2.message.data = input_params.message.data;
-   asym_op->sm2.message.length = input_params.message.length;
+   if (asym_op->sm2.hash == RTE_CRYPTO_AUTH_SM3) {
+   asym_op->sm2.message.data = input_params.message.data;
+   asym_op->sm2.message.length = input_params.message.length;
+   asym_op->sm2.id.data = input_params.id.data;
+   asym_op->sm2.id.length = input_params.id.length;
+   } else {
+   asym_op->sm2.message.data = input_params.digest.data;
+   asym_op->sm2.message.length = input_params.digest.length;
+   asym_op->sm2.id.data = NULL;
+   asym_op->sm2.id.length = 0;
+   }
+
asym_op->sm2.r.data = input_params.sign_r.data;
asym_op->sm2.r.length = input_params.sign_r.length;
asym_op->sm2.s.data = input_params.sign_s.data;
asym_op->sm2.s.length = input_params.sign_s.length;
-   asym_op->sm2.id.data = input_params.id.data;
-   asym_op->sm2.id.length = input_params.id.length;
 
RTE_LOG(DEBUG, USER1, "Process ASYM operation\n");
 
@@ -2116,7 +2122,7 @@ test_sm2_verify(void)
 };
 
 static int
-_test_sm2_enc(bool rnd_secret)
+test_sm2_enc(void)
 {
struct crypto_testsuite_params_asym *ts_params = &testsuite_params;
struct crypto_testsuite_sm2_params input_params = sm2_param_fp256;
@@ -2185,7 +2191,8 @@ _test_sm2_enc(bool rnd_secret)
 
asym_op->sm2.message.data = input_params.message.data;
asym_op->sm2.message.length = input_params.message.length;
-   if (rnd_secret) {
+
+   if (capa->internal_rng != 0) {
asym_op->sm2.k.dat

RE: [PATCH v2 1/2] power: refactor uncore power management interfaces

2023-10-09 Thread Tummala, Sivaprasad

[AMD Official Use Only - General]

> -Original Message-
> From: David Marchand 
> Sent: Friday, October 6, 2023 2:33 PM
> To: david.h...@intel.com; anatoly.bura...@intel.com
> Cc: Yigit, Ferruh ; dev@dpdk.org; Tummala, Sivaprasad
> 
> Subject: Re: [PATCH v2 1/2] power: refactor uncore power management interfaces
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Wed, Aug 16, 2023 at 12:10 PM Sivaprasad Tummala
>  wrote:
> >
> > currently the uncore power management implementation is vendor specific.
> > Added new vendor agnostic uncore power interface similar to rte_power
> > and rename specific implementations ("rte_power_intel_uncore") to
> > "power_intel_uncore" along with functions.
> >
> > Signed-off-by: Sivaprasad Tummala 
>
> Review please.
>
Hi Anatoly,
Based on your earlier review comments on RFC patch, it appears you are fine 
with the refactor.
Can I use that as an ACK to this patch. Please let me know otherwise.

> --
> David Marchand

[PATCH v6 1/3] eal: add x86 cpuid support for monitorx

2023-10-09 Thread Sivaprasad Tummala

Add a new CPUID flag to indicate support for monitorx instruction
on AMD EPYC processors.

Signed-off-by: Sivaprasad Tummala 
Acked-by: Anatoly Burakov 
---
 lib/eal/x86/include/rte_cpuflags.h | 1 +
 lib/eal/x86/rte_cpuflags.c | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/lib/eal/x86/include/rte_cpuflags.h 
b/lib/eal/x86/include/rte_cpuflags.h
index d95bf33a16..1ee00e70fe 100644
--- a/lib/eal/x86/include/rte_cpuflags.h
+++ b/lib/eal/x86/include/rte_cpuflags.h
@@ -133,6 +133,7 @@ enum rte_cpu_flag_t {
RTE_CPUFLAG_AVX512VP2INTERSECT, /**< AVX512 Two Register 
Intersection */
 
RTE_CPUFLAG_WAITPKG,/**< UMONITOR/UMWAIT/TPAUSE */
+   RTE_CPUFLAG_MONITORX,   /**< MONITORX */
 };
 
 #include "generic/rte_cpuflags.h"
diff --git a/lib/eal/x86/rte_cpuflags.c b/lib/eal/x86/rte_cpuflags.c
index 3fb1cb9bab..26163ab746 100644
--- a/lib/eal/x86/rte_cpuflags.c
+++ b/lib/eal/x86/rte_cpuflags.c
@@ -133,6 +133,7 @@ const struct feature_entry rte_cpu_feature_table[] = {
 
FEAT_DEF(LAHF_SAHF, 0x8001, 0, RTE_REG_ECX,  0)
FEAT_DEF(LZCNT, 0x8001, 0, RTE_REG_ECX,  4)
+   FEAT_DEF(MONITORX, 0x8001, 0, RTE_REG_ECX,  29)
 
FEAT_DEF(SYSCALL, 0x8001, 0, RTE_REG_EDX, 11)
FEAT_DEF(XD, 0x8001, 0, RTE_REG_EDX, 20)
@@ -195,5 +196,7 @@ rte_cpu_get_intrinsics_support(struct rte_cpu_intrinsics 
*intrinsics)
intrinsics->power_pause = 1;
if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_RTM))
intrinsics->power_monitor_multi = 1;
+   } else if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_MONITORX)) {
+   intrinsics->power_monitor = 1;
}
 }
-- 
2.34.1

[PATCH v6 2/3] eal: removed unnecessary checks in x86 power monitor APIs

2023-10-09 Thread Sivaprasad Tummala

current x86 power monitor implementation fails on platforms
with only monitor supported and not power_pause.

Signed-off-by: Sivaprasad Tummala 
Acked-by: Anatoly Burakov 
---
 lib/eal/x86/rte_power_intrinsics.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/lib/eal/x86/rte_power_intrinsics.c 
b/lib/eal/x86/rte_power_intrinsics.c
index 1467a32cb3..664cde01e9 100644
--- a/lib/eal/x86/rte_power_intrinsics.c
+++ b/lib/eal/x86/rte_power_intrinsics.c
@@ -31,6 +31,7 @@ __umwait_wakeup(volatile void *addr)
 
 static bool wait_supported;
 static bool wait_multi_supported;
+static bool monitor_supported;
 
 static inline uint64_t
 __get_umwait_val(const volatile void *p, const uint8_t sz)
@@ -82,7 +83,7 @@ rte_power_monitor(const struct rte_power_monitor_cond *pmc,
uint64_t cur_value;
 
/* prevent user from running this instruction if it's not supported */
-   if (!wait_supported)
+   if (!monitor_supported)
return -ENOTSUP;
 
/* prevent non-EAL thread from using this API */
@@ -183,6 +184,8 @@ RTE_INIT(rte_power_intrinsics_init) {
wait_supported = 1;
if (i.power_monitor_multi)
wait_multi_supported = 1;
+   if (i.power_monitor)
+   monitor_supported = 1;
 }
 
 int
@@ -191,7 +194,7 @@ rte_power_monitor_wakeup(const unsigned int lcore_id)
struct power_wait_status *s;
 
/* prevent user from running this instruction if it's not supported */
-   if (!wait_supported)
+   if (!monitor_supported)
return -ENOTSUP;
 
/* prevent buffer overrun */
-- 
2.34.1

[PATCH v6 3/3] power: amd power monitor support

2023-10-09 Thread Sivaprasad Tummala

mwaitx allows EPYC processors to enter a implementation dependent
power/performance optimized state (C1 state) for a specific period
or until a store to the monitored address range.

Signed-off-by: Sivaprasad Tummala 
Acked-by: Anatoly Burakov 
---
 lib/eal/x86/rte_power_intrinsics.c | 108 ++---
 1 file changed, 84 insertions(+), 24 deletions(-)

diff --git a/lib/eal/x86/rte_power_intrinsics.c 
b/lib/eal/x86/rte_power_intrinsics.c
index 664cde01e9..0d2953f570 100644
--- a/lib/eal/x86/rte_power_intrinsics.c
+++ b/lib/eal/x86/rte_power_intrinsics.c
@@ -17,6 +17,78 @@ static struct power_wait_status {
volatile void *monitor_addr; /**< NULL if not currently sleeping */
 } __rte_cache_aligned wait_status[RTE_MAX_LCORE];
 
+/**
+ * This functions uses UMONITOR/UMWAIT instructions and will enter C0.2 state.
+ * For more information about usage of these instructions, please refer to
+ * Intel(R) 64 and IA-32 Architectures Software Developer's Manual.
+ */
+static void intel_umonitor(volatile void *addr)
+{
+#if defined(RTE_TOOLCHAIN_MSVC) || defined(__WAITPKG__)
+   /* cast away "volatile" when using the intrinsic */
+   _umonitor((void *)(uintptr_t)addr);
+#else
+   /*
+* we're using raw byte codes for compiler versions which
+* don't support this instruction natively.
+*/
+   asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
+   :
+   : "D"(addr));
+#endif
+}
+
+static void intel_umwait(const uint64_t timeout)
+{
+   const uint32_t tsc_l = (uint32_t)timeout;
+   const uint32_t tsc_h = (uint32_t)(timeout >> 32);
+#if defined(RTE_TOOLCHAIN_MSVC) || defined(__WAITPKG__)
+   _umwait(tsc_l, tsc_h);
+#else
+   asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
+   : /* ignore rflags */
+   : "D"(0), /* enter C0.2 */
+ "a"(tsc_l), "d"(tsc_h));
+#endif
+}
+
+/**
+ * This functions uses MONITORX/MWAITX instructions and will enter C1 state.
+ * For more information about usage of these instructions, please refer to
+ * AMD64 Architecture Programmer’s Manual.
+ */
+static void amd_monitorx(volatile void *addr)
+{
+#if defined(__MWAITX__)
+   /* cast away "volatile" when using the intrinsic */
+   _mm_monitorx((void *)(uintptr_t)addr, 0, 0);
+#else
+   asm volatile(".byte 0x0f, 0x01, 0xfa;"
+   :
+   : "a"(addr),
+   "c"(0),  /* no extensions */
+   "d"(0)); /* no hints */
+#endif
+}
+
+static void amd_mwaitx(const uint64_t timeout)
+{
+   RTE_SET_USED(timeout);
+#if defined(__MWAITX__)
+   _mm_mwaitx(0, 0, 0);
+#else
+   asm volatile(".byte 0x0f, 0x01, 0xfb;"
+   : /* ignore rflags */
+   : "a"(0), /* enter C1 */
+   "c"(0)); /* no time-out */
+#endif
+}
+
+static struct {
+   void (*mmonitor)(volatile void *addr);
+   void (*mwait)(const uint64_t timeout);
+} __rte_cache_aligned power_monitor_ops;
+
 static inline void
 __umwait_wakeup(volatile void *addr)
 {
@@ -76,8 +148,6 @@ int
 rte_power_monitor(const struct rte_power_monitor_cond *pmc,
const uint64_t tsc_timestamp)
 {
-   const uint32_t tsc_l = (uint32_t)tsc_timestamp;
-   const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
const unsigned int lcore_id = rte_lcore_id();
struct power_wait_status *s;
uint64_t cur_value;
@@ -105,19 +175,8 @@ rte_power_monitor(const struct rte_power_monitor_cond *pmc,
rte_spinlock_lock(&s->lock);
s->monitor_addr = pmc->addr;
 
-   /* set address for UMONITOR */
-#if defined(RTE_TOOLCHAIN_MSVC) || defined(__WAITPKG__)
-   /* cast away "volatile" when using the intrinsic */
-   _umonitor((void *)(uintptr_t)pmc->addr);
-#else
-   /*
-* we're using raw byte codes for compiler versions which
-* don't support this instruction natively.
-*/
-   asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
-   :
-   : "D"(pmc->addr));
-#endif
+   /* set address for memory monitor */
+   power_monitor_ops.mmonitor(pmc->addr);
 
/* now that we've put this address into monitor, we can unlock */
rte_spinlock_unlock(&s->lock);
@@ -128,15 +187,8 @@ rte_power_monitor(const struct rte_power_monitor_cond *pmc,
if (pmc->fn(cur_value, pmc->opaque) != 0)
goto end;
 
-   /* execute UMWAIT */
-#if defined(RTE_TOOLCHAIN_MSVC) || defined(__WAITPKG__)
-   _umwait(tsc_l, tsc_h);
-#else
-   asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
-   : /* ignore rflags */
-   : "D"(0), /* enter C0.2 */
- "a"(tsc_l), "d"(tsc_h));
-#endif
+   /* execute mwait */
+   power_monitor_ops.mwait(tsc_timestamp);
 
 end:
/* erase sleep address */
@@ -186,6 +238,14 @@ RT

Re: [PATCH v3] hash: fix SSE comparison

2023-10-09 Thread Bruce Richardson

On Sat, Oct 07, 2023 at 03:36:34PM +0800, Jieqiang Wang wrote:
> __mm_cmpeq_epi16 returns 0x if the corresponding 16-bit elements are
> equal. In original SSE2 implementation for function compare_signatures,
> it utilizes _mm_movemask_epi8 to create mask from the MSB of each 8-bit
> element, while we should only care about the MSB of lower 8-bit in each
> 16-bit element.
> For example, if the comparison result is all equal, SSE2 path returns
> 0x while NEON and default scalar path return 0x.
> Although this bug is not causing any negative effects since the caller
> function solely examines the trailing zeros of each match mask, we
> recommend this fix to ensure consistency with NEON and default scalar
> code behaviors.
> 
> Fixes: c7d93df552c2 ("hash: use partial-key hashing")
> Cc: sta...@dpdk.org
> 
> v2:
> 1. Utilize scalar mask instead of vector mask to save extra loads (Bruce)
> 
> v3:
> 1. Fix coding style warnings
> 
> Signed-off-by: Feifei Wang 
> Signed-off-by: Jieqiang Wang 
> Reviewed-by: Ruifeng Wang 

Acked-by: Bruce Richardson

[PATCH v3] power: support amd-pstate cpufreq driver

2023-10-09 Thread Sivaprasad Tummala

amd-pstate introduces a new CPU frequency control mechanism for AMD
EPYC processors using the ACPI Collaborative Performance Power Control
feature for a finer grained frequency management.

Patch to add support for amd-pstate driver.

Signed-off-by: Sivaprasad Tummala 
Acked-by: Anatoly Burakov 
---
v3:
1. replaced __atomic_xxx built-ins with rte_atomic_xxx
2. fixed typo

v2:
1. error logged when scaling min freq exceeds max freq
2. workaound in test app to allow frequency deviation of up to 50Mhz
2. fixed indentation in release notes
---
 app/test/test_power.c  |   1 +
 app/test/test_power_cpufreq.c  |  13 +-
 doc/guides/rel_notes/release_23_11.rst |   4 +
 examples/l3fwd-power/main.c|   3 +
 lib/power/meson.build  |   1 +
 lib/power/power_amd_pstate_cpufreq.c   | 702 +
 lib/power/power_amd_pstate_cpufreq.h   | 219 
 lib/power/rte_power.c  |  26 +
 lib/power/rte_power.h  |   3 +-
 lib/power/rte_power_pmd_mgmt.c |   6 +-
 10 files changed, 974 insertions(+), 4 deletions(-)
 create mode 100644 lib/power/power_amd_pstate_cpufreq.c
 create mode 100644 lib/power/power_amd_pstate_cpufreq.h

diff --git a/app/test/test_power.c b/app/test/test_power.c
index 02ebc54d19..f1e80299d3 100644
--- a/app/test/test_power.c
+++ b/app/test/test_power.c
@@ -134,6 +134,7 @@ test_power(void)
const enum power_management_env envs[] = {PM_ENV_ACPI_CPUFREQ,
PM_ENV_KVM_VM,
PM_ENV_PSTATE_CPUFREQ,
+   PM_ENV_AMD_PSTATE_CPUFREQ,
PM_ENV_CPPC_CPUFREQ};
 
unsigned int i;
diff --git a/app/test/test_power_cpufreq.c b/app/test/test_power_cpufreq.c
index 10755a0d41..b050c47864 100644
--- a/app/test/test_power_cpufreq.c
+++ b/app/test/test_power_cpufreq.c
@@ -93,6 +93,17 @@ check_cur_freq(unsigned int lcore_id, uint32_t idx, bool 
turbo)
freq_conv = (cur_freq + TEST_FREQ_ROUNDING_DELTA)
/ TEST_ROUND_FREQ_TO_N_10;
freq_conv = freq_conv * TEST_ROUND_FREQ_TO_N_10;
+   } else if (env == PM_ENV_AMD_PSTATE_CPUFREQ) {
+   freq_conv = cur_freq > freqs[idx] ? (cur_freq - 
freqs[idx]) :
+   (freqs[idx] - cur_freq);
+   if (freq_conv <= TEST_FREQ_ROUNDING_DELTA) {
+   /* workaround: current frequency may deviate 
from
+* nominal freq. Allow deviation of up to 50Mhz.
+*/
+   printf("current frequency deviated from nominal 
"
+   "frequency by %d Khz!\n", freq_conv);
+   freq_conv = freqs[idx];
+   }
}
 
if (turbo)
@@ -502,7 +513,7 @@ test_power_cpufreq(void)
/* Test environment configuration */
env = rte_power_get_env();
if ((env != PM_ENV_ACPI_CPUFREQ) && (env != PM_ENV_PSTATE_CPUFREQ) &&
-   (env != PM_ENV_CPPC_CPUFREQ)) {
+   (env != PM_ENV_CPPC_CPUFREQ) && (env != 
PM_ENV_AMD_PSTATE_CPUFREQ)) {
printf("Unexpectedly got an environment other than 
ACPI/PSTATE\n");
goto fail_all;
}
diff --git a/doc/guides/rel_notes/release_23_11.rst 
b/doc/guides/rel_notes/release_23_11.rst
index eaa1d58f32..63c3d5bbaf 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -80,6 +80,10 @@ New Features
   device is different from the Tx Ethernet device with respective driver
   callback functions in ``rte_eth_recycle_mbufs``.
 
+* **Added amd-pstate driver support to power management library.**
+
+  Added support for amd-pstate driver which works on AMD EPYC processors.
+
 * **Updated Solarflare net driver.**
 
   * Added support for transfer flow action ``INDIRECT`` with subtype 
``VXLAN_ENCAP``.
diff --git a/examples/l3fwd-power/main.c b/examples/l3fwd-power/main.c
index 3f01cbd9e2..b9bec79cb2 100644
--- a/examples/l3fwd-power/main.c
+++ b/examples/l3fwd-power/main.c
@@ -2245,6 +2245,7 @@ init_power_library(void)
env = rte_power_get_env();
if (env != PM_ENV_ACPI_CPUFREQ &&
env != PM_ENV_PSTATE_CPUFREQ &&
+   env != PM_ENV_AMD_PSTATE_CPUFREQ &&
env != PM_ENV_CPPC_CPUFREQ) {
RTE_LOG(ERR, POWER,
"Only ACPI, PSTATE and CPPC mode are 
supported\n");
@@ -2417,6 +2418,8 @@ autodetect_mode(void)
return APP_MODE_LEGACY;
if (rte_power_check_env_supported(PM_ENV_PSTATE_CPUFREQ))
return APP_MODE_LEGACY;
+   if (rte_power_check_env_supported(PM_ENV_AMD_PSTATE_CP

Re: [PATCH] net/netvsc: add support for mtu_set

2023-10-09 Thread Stephen Hemminger

On Thu, 5 Oct 2023 23:17:28 +
Sam Andrew  wrote:

> +
> +static int
> +hn_dev_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
> +{
> + struct hn_data *hv = dev->data->dev_private;
> + unsigned int orig_mtu = dev->data->mtu;
> + uint32_t rndis_mtu;
> + int ret = 0;
> + int i;
> +
> + if (dev->data->dev_started) {
> + PMD_DRV_LOG(ERR, "Device must be stopped before changing MTU");
> + return -EIO;
> + }
> +

It looks like this proposed patch does not have the accelerated networking
virtual device case.  The driver needs to first update the MTU of the underlying
VF device (and handle errors), then reinit the vmbus device.

Re: [RFC 2/2] test: add pointer compress tests to ring perf test

2023-10-09 Thread Thomas Monjalon

27/09/2023 17:08, Paul Szczepanek:
> Add a test that runs a zero copy burst enqueue and dequeue on a ring
> of raw pointers and compressed pointers at different burst sizes to
> showcase performance benefits of newly added pointer compression APIs
> 
> To reuse existing code, some refactoring was done to pass more
> parameters to test threads. Additionally more bulk sizes were
> added to showcase their effects on compression. To keep runtime
> reasoanble iterations where adjusted to take into account bulk sizes.

typo: reasonable

How much time does it take before/after?

Re: [RFC 1/2] eal: add pointer compression functions

2023-10-09 Thread Thomas Monjalon

27/09/2023 17:08, Paul Szczepanek:
> Add a new utility header for compressing pointers. Pointers are
> compressed by taking advantage of their locality. Instead of
> storing the full address only an offset from a known base is stored.

You probably need to insert some explanations from the cover letter.

> The provided functions can store pointers in 32bit offsets.
> 
> Suggested-by: Honnappa Nagarahalli 
> Signed-off-by: Paul Szczepanek 
> Signed-off-by: Kamalakshitha Aligeri 
> Reviewed-by: Honnappa Nagarahalli 
[...]
> --- a/lib/eal/include/meson.build
> +++ b/lib/eal/include/meson.build
> @@ -35,6 +35,7 @@ headers += files(
>  'rte_pci_dev_feature_defs.h',
>  'rte_pci_dev_features.h',
>  'rte_per_lcore.h',
> + 'rte_ptr_compress.h',
>  'rte_pflock.h',
>  'rte_random.h',
>  'rte_reciprocal.h',

Did you try to sort alphabetically? failed :)

> +#ifndef _RTE_PTR_COMPRESS_H_
> +#define _RTE_PTR_COMPRESS_H_

No need extra underscores.

> +
> +/**
> + * @file
> + * RTE pointer compression and decompression.

RTE has no mean here I think.

> + */
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +/**
> + * Compress pointers into 32 bit offsets from base pointer.

I think it should be "32-bit".

> + *
> + * @note Offsets from the base pointer must fit within 32bits. Alignment 
> allows
> + * us to drop bits from the offsets - this means that for pointers aligned by
> + * 8 bytes they must be within 32GB of the base pointer. Unaligned pointers
> + * must be within 4GB.

Not clear what is "alignment".
> + *
> + * @param ptr_base
> + *   A pointer used to calculate offsets of pointers in src_table.
> + * @param src_table
> + *   A pointer to an array of pointers.
> + * @param dest_table
> + *   A pointer to an array of compressed pointers returned by this function.
> + * @param n
> + *   The number of objects to compress, must be strictly positive.
> + * @param bit_shift
> + *   Byte alignment of memory pointed to by the pointers allows for
> + *   bits to be dropped from the offset and hence widen the memory region 
> that
> + *   can be covered. This controls how many bits are right shifted.
> + **/
> +static __rte_always_inline void
> +rte_ptr_compress_32(void *ptr_base, void **src_table,
> + uint32_t *dest_table, unsigned int n, unsigned int bit_shift)
> +{
> + unsigned int i = 0;
> +#if defined RTE_HAS_SVE_ACLE
> + svuint64_t v_src_table;
> + svuint64_t v_dest_table;
> + svbool_t pg = svwhilelt_b64(i, n);
> + do {
> + v_src_table = svld1_u64(pg, (uint64_t *)src_table + i);
> + v_dest_table = svsub_x(pg, v_src_table, (uint64_t)ptr_base);
> + v_dest_table = svlsr_x(pg, v_dest_table, bit_shift);
> + svst1w(pg, &dest_table[i], v_dest_table);
> + i += svcntd();
> + pg = svwhilelt_b64(i, n);
> + } while (svptest_any(svptrue_b64(), pg));
> +#elif defined __ARM_NEON
> + uint64_t ptr_diff;
> + uint64x2_t v_src_table;
> + uint64x2_t v_dest_table;
> + /* right shift is done by left shifting by negative int */
> + int64x2_t v_shift = vdupq_n_s64(-bit_shift);
> + uint64x2_t v_ptr_base = vdupq_n_u64((uint64_t)ptr_base);
> + for (; i < (n & ~0x1); i += 2) {
> + v_src_table = vld1q_u64((const uint64_t *)src_table + i);
> + v_dest_table = vsubq_u64(v_src_table, v_ptr_base);
> + v_dest_table = vshlq_u64(v_dest_table, v_shift);
> + vst1_u32(dest_table + i, vqmovn_u64(v_dest_table));
> + }
> + /* process leftover single item in case of odd number of n */
> + if (unlikely(n & 0x1)) {
> + ptr_diff = RTE_PTR_DIFF(src_table[i], ptr_base);
> + dest_table[i] = (uint32_t) (ptr_diff >> bit_shift);
> + }
> +#else
> + uint64_t ptr_diff;
> + for (; i < n; i++) {
> + ptr_diff = RTE_PTR_DIFF(src_table[i], ptr_base);
> + /* save extra bits that are redundant due to alignment */
> + ptr_diff = ptr_diff >> bit_shift;
> + /* make sure no truncation will happen when casting */
> + RTE_ASSERT(ptr_diff <= UINT32_MAX);
> + dest_table[i] = (uint32_t) ptr_diff;
> + }
> +#endif
> +}

I see it is providing some per-CPU optimizations,
so it is in favor of having it in DPDK.
Other than that, it looks very generic, so it is questionable to have in DPDK.

[PATCH v2] ethdev: add packet type matching item

2023-10-09 Thread Alexander Kozyrev

Add RTE_FLOW_ITEM_TYPE_PTYPE to allow matching on
L2/L3/L4 and tunnel information as defined in mbuf.

To match on RTE_PTYPE_L4_TCP and RTE_PTYPE_INNER_L4_UDP:
  flow pattern_template 0 create pattern_template_id 1
ingress template ptype packet_type mask 0x0f000f00 / end
  flow queue 0 create 0 template_table 1 pattern_template 0 actions_template 0
pattern ptype packet_type is 0x02000100 / end actions queue index 1 / end

Signed-off-by: Alexander Kozyrev 
Acked-by: Ori Kam 
---
 app/test-pmd/cmdline_flow.c | 27 +
 doc/guides/nics/features/default.ini|  1 +
 doc/guides/prog_guide/rte_flow.rst  |  7 ++
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  4 +++
 lib/ethdev/rte_flow.c   |  1 +
 lib/ethdev/rte_flow.h   | 25 +++
 6 files changed, 65 insertions(+)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 12809f1042..cb203ad99c 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -535,6 +535,8 @@ enum index {
ITEM_IPV6_PUSH_REMOVE_EXT,
ITEM_IPV6_PUSH_REMOVE_EXT_TYPE,
ITEM_NSH,
+   ITEM_PTYPE,
+   ITEM_PTYPE_VALUE,
 
/* Validate/create actions. */
ACTIONS,
@@ -1581,6 +1583,7 @@ static const enum index next_item[] = {
ITEM_TX_QUEUE,
ITEM_IB_BTH,
ITEM_NSH,
+   ITEM_PTYPE,
END_SET,
ZERO,
 };
@@ -2106,6 +2109,12 @@ static const enum index item_nsh[] = {
ZERO,
 };
 
+static const enum index item_ptype[] = {
+   ITEM_PTYPE_VALUE,
+   ITEM_NEXT,
+   ZERO,
+};
+
 static const enum index next_action[] = {
ACTION_END,
ACTION_VOID,
@@ -5921,6 +5930,21 @@ static const struct token token_list[] = {
.next = NEXT(item_nsh),
.call = parse_vc,
},
+   [ITEM_PTYPE] = {
+   .name = "ptype",
+   .help = "match L2/L3/L4 and tunnel information",
+   .priv = PRIV_ITEM(PTYPE,
+ sizeof(struct rte_flow_item_ptype)),
+   .next = NEXT(item_ptype),
+   .call = parse_vc,
+   },
+   [ITEM_PTYPE_VALUE] = {
+   .name = "packet_type",
+   .help = "packet type as defined in rte_mbuf_ptype",
+   .next = NEXT(item_ptype, NEXT_ENTRY(COMMON_UNSIGNED),
+item_param),
+   .args = ARGS(ARGS_ENTRY(struct rte_flow_item_ptype, 
packet_type)),
+   },
 
/* Validate/create actions. */
[ACTIONS] = {
@@ -12836,6 +12860,9 @@ flow_item_default_mask(const struct rte_flow_item *item)
case RTE_FLOW_ITEM_TYPE_IB_BTH:
mask = &rte_flow_item_ib_bth_mask;
break;
+   case RTE_FLOW_ITEM_TYPE_PTYPE:
+   mask = &rte_flow_item_ptype_mask;
+   break;
default:
break;
}
diff --git a/doc/guides/nics/features/default.ini 
b/doc/guides/nics/features/default.ini
index 2011e97127..e41a97b3bb 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -137,6 +137,7 @@ ppp  =
 pppoed   =
 pppoes   =
 pppoe_proto_id   =
+ptype=
 quota=
 raw  =
 represented_port =
diff --git a/doc/guides/prog_guide/rte_flow.rst 
b/doc/guides/prog_guide/rte_flow.rst
index 860e42025f..b65b25d443 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1566,6 +1566,13 @@ Matches an InfiniBand base transport header in RoCE 
packet.
 
 - ``hdr``: InfiniBand base transport header definition (``rte_ib.h``).
 
+Item: ``PTYPE``
+^^^
+
+Matches the packet type as defined in rte_mbuf_ptype.
+
+- ``packet_type``: L2/L3/L4 and tunnel information.
+
 Actions
 ~~~
 
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst 
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index e6d218caaa..07bac9a311 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -3808,6 +3808,10 @@ This section lists supported pattern items and their 
attributes, if any.
 
 - ``send_to_kernel``: send packets to kernel.
 
+- ``ptype``: match the packet type (L2/L3/L4 and tunnel information).
+
+- ``packet_type {unsigned}``: packet type.
+
 
 Actions list
 
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index c9d23da702..ba8bf27090 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -167,6 +167,7 @@ static const struct rte_flow_desc_data rte_flow_desc_item[] 
= {
MK_FLOW_ITEM(AGGR_AFFINITY, sizeof(struct rte_flow_item_aggr_affinity)),
MK_FLOW_ITEM(TX_QUEUE, sizeof(struct rte_flow_item_tx_queue)),
MK_FLOW_ITEM(IB_BTH, sizeof(struct rte_flow_item_ib_bth)),
+   MK_FLOW_ITEM(PTYPE, sizeof(struct rte_flow_item_ptype)),

Re: [PATCH v6 1/3] eal: add x86 cpuid support for monitorx

2023-10-09 Thread Patrick Robb

Recheck-request: iol-unit-amd64-testing

Failed for service_autotest on windows. I'm doing a retest to see if it's
reproducible.

[PATCH v3] ethdev: add packet type matching item

2023-10-09 Thread Alexander Kozyrev

Add RTE_FLOW_ITEM_TYPE_PTYPE to allow matching on
L2/L3/L4 and tunnel information as defined in mbuf.

To match on RTE_PTYPE_L4_TCP and RTE_PTYPE_INNER_L4_UDP:
  flow pattern_template 0 create pattern_template_id 1
ingress template ptype packet_type mask 0x0f000f00 / end
  flow queue 0 create 0 template_table 1
pattern_template 0 actions_template 0
pattern ptype packet_type is 0x02000100 / end
actions queue index 1 / end

Signed-off-by: Alexander Kozyrev 
Acked-by: Ori Kam 
---
 app/test-pmd/cmdline_flow.c | 28 +
 doc/guides/nics/features/default.ini|  1 +
 doc/guides/prog_guide/rte_flow.rst  |  7 ++
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  4 +++
 lib/ethdev/rte_flow.c   |  1 +
 lib/ethdev/rte_flow.h   | 25 ++
 6 files changed, 66 insertions(+)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 2b1d9b70ee..02874c4597 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -534,6 +534,8 @@ enum index {
ITEM_IB_BTH_PSN,
ITEM_IPV6_PUSH_REMOVE_EXT,
ITEM_IPV6_PUSH_REMOVE_EXT_TYPE,
+   ITEM_PTYPE,
+   ITEM_PTYPE_VALUE,
 
/* Validate/create actions. */
ACTIONS,
@@ -1579,6 +1581,7 @@ static const enum index next_item[] = {
ITEM_AGGR_AFFINITY,
ITEM_TX_QUEUE,
ITEM_IB_BTH,
+   ITEM_PTYPE,
END_SET,
ZERO,
 };
@@ -2099,6 +2102,12 @@ static const enum index item_ib_bth[] = {
ZERO,
 };
 
+static const enum index item_ptype[] = {
+   ITEM_PTYPE_VALUE,
+   ITEM_NEXT,
+   ZERO,
+};
+
 static const enum index next_action[] = {
ACTION_END,
ACTION_VOID,
@@ -5906,6 +5915,22 @@ static const struct token token_list[] = {
.args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ib_bth,
 hdr.psn)),
},
+   [ITEM_PTYPE] = {
+   .name = "ptype",
+   .help = "match L2/L3/L4 and tunnel information",
+   .priv = PRIV_ITEM(PTYPE,
+ sizeof(struct rte_flow_item_ptype)),
+   .next = NEXT(item_ptype),
+   .call = parse_vc,
+   },
+   [ITEM_PTYPE_VALUE] = {
+   .name = "packet_type",
+   .help = "packet type as defined in rte_mbuf_ptype",
+   .next = NEXT(item_ptype, NEXT_ENTRY(COMMON_UNSIGNED),
+item_param),
+   .args = ARGS(ARGS_ENTRY(struct rte_flow_item_ptype, 
packet_type)),
+   },
+
/* Validate/create actions. */
[ACTIONS] = {
.name = "actions",
@@ -12820,6 +12845,9 @@ flow_item_default_mask(const struct rte_flow_item *item)
case RTE_FLOW_ITEM_TYPE_IB_BTH:
mask = &rte_flow_item_ib_bth_mask;
break;
+   case RTE_FLOW_ITEM_TYPE_PTYPE:
+   mask = &rte_flow_item_ptype_mask;
+   break;
default:
break;
}
diff --git a/doc/guides/nics/features/default.ini 
b/doc/guides/nics/features/default.ini
index 2011e97127..e41a97b3bb 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -137,6 +137,7 @@ ppp  =
 pppoed   =
 pppoes   =
 pppoe_proto_id   =
+ptype=
 quota=
 raw  =
 represented_port =
diff --git a/doc/guides/prog_guide/rte_flow.rst 
b/doc/guides/prog_guide/rte_flow.rst
index 860e42025f..b65b25d443 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1566,6 +1566,13 @@ Matches an InfiniBand base transport header in RoCE 
packet.
 
 - ``hdr``: InfiniBand base transport header definition (``rte_ib.h``).
 
+Item: ``PTYPE``
+^^^
+
+Matches the packet type as defined in rte_mbuf_ptype.
+
+- ``packet_type``: L2/L3/L4 and tunnel information.
+
 Actions
 ~~~
 
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst 
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index e6d218caaa..07bac9a311 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -3808,6 +3808,10 @@ This section lists supported pattern items and their 
attributes, if any.
 
 - ``send_to_kernel``: send packets to kernel.
 
+- ``ptype``: match the packet type (L2/L3/L4 and tunnel information).
+
+- ``packet_type {unsigned}``: packet type.
+
 
 Actions list
 
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index c9d23da702..ba8bf27090 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -167,6 +167,7 @@ static const struct rte_flow_desc_data rte_flow_desc_item[] 
= {
MK_FLOW_ITEM(AGGR_AFFINITY, sizeof(struct rte_flow_item_aggr_affinity)),
MK_FLOW_ITEM(TX_QUEUE, sizeof(struct rte_flow_item_tx_queue)),
MK

[PATCH] usertools/rss: add CNXK RSS key

2023-10-09 Thread skori

From: Sunil Kumar Kori 

This patch adds RSS key for CNXK platforms. CNXK platform uses
48 bytes long key for hash calculations.

For the same patch also updates help mesaages to provide range
information for supporting NICs/platforms.

Also CNXK uses reta size as 64 so to get correct offset to retrieve
queue index, user must pass reta_size option as 64 i.e. -t 64.

Examples:
$ ./dpdk-rss-flows.py -k cnxk 8 28.0.0.0/24 40.0.0.0/24 -t 64
SRC_IP  DST_IP   QUEUE
28.0.0.140.0.0.1 7
28.0.0.140.0.0.2 2
28.0.0.140.0.0.3 4
28.0.0.140.0.0.7 1
28.0.0.140.0.0.8 3
28.0.0.140.0.0.9 5
28.0.0.140.0.0.100
28.0.0.140.0.0.116

Signed-off-by: Sunil Kumar Kori 
Change-Id: I631639d74c0bf91759f8aa188836019b4990caf2
---
 usertools/dpdk-rss-flows.py | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/usertools/dpdk-rss-flows.py b/usertools/dpdk-rss-flows.py
index 73821eb471..b6edd7a2e0 100755
--- a/usertools/dpdk-rss-flows.py
+++ b/usertools/dpdk-rss-flows.py
@@ -188,11 +188,24 @@ def balanced_traffic(
 0x81, 0x15, 0x03, 0x66,
 )
 )
+# rss_key_default, see drivers/net/cnxk/cnxk_flow.c
+# Marvell's cnxk NICs take 48 bytes keys
+RSS_KEY_CNXK = bytes(
+(
+0xfe, 0xed, 0x0b, 0xad, 0xfe, 0xed, 0x0b, 0xad,
+0xfe, 0xed, 0x0b, 0xad, 0xfe, 0xed, 0x0b, 0xad,
+0xfe, 0xed, 0x0b, 0xad, 0xfe, 0xed, 0x0b, 0xad,
+0xfe, 0xed, 0x0b, 0xad, 0xfe, 0xed, 0x0b, 0xad,
+0xfe, 0xed, 0x0b, 0xad, 0xfe, 0xed, 0x0b, 0xad,
+0xfe, 0xed, 0x0b, 0xad, 0xfe, 0xed, 0x0b, 0xad,
+)
+)
 # fmt: on
 DEFAULT_DRIVER_KEYS = {
 "intel": RSS_KEY_INTEL,
 "mlx": RSS_KEY_MLX,
 "i40e": RSS_KEY_I40E,
+"cnxk": RSS_KEY_CNXK,
 }
 
 
@@ -202,7 +215,7 @@ def rss_key(value):
 try:
 key = binascii.unhexlify(value)
 if len(key) not in (40, 52):
-raise argparse.ArgumentTypeError("The key must be 40 or 52 bytes 
long")
+raise argparse.ArgumentTypeError("The key must be 40 to 52 bytes 
long")
 return key
 except (TypeError, ValueError) as e:
 raise argparse.ArgumentTypeError(str(e)) from e
@@ -299,7 +312,7 @@ def parse_args():
 default=RSS_KEY_INTEL,
 type=rss_key,
 help="""
-The random 40-bytes key used to compute the RSS hash. This option
+The random 40 to 52 bytes key used to compute the RSS hash. This option
 supports either a well-known name or the hex value of the key
 (well-known names: "intel", "mlx", default: "intel").
 """,
-- 
2.25.1

[PATCH v2 1/1] usertools/rss: add CNXK RSS key

2023-10-09 Thread skori

From: Sunil Kumar Kori 

This patch adds RSS key for CNXK platforms. CNXK platform uses
48 bytes long key for hash calculations.

For the same patch also updates help mesaages to provide range
information for supporting NICs/platforms.

Also CNXK uses reta size as 64 so to get correct offset to retrieve
queue index, user must pass reta_size option as 64 i.e. -t 64.

Examples:
$ ./dpdk-rss-flows.py -k cnxk 8 28.0.0.0/24 40.0.0.0/24 -t 64
SRC_IP  DST_IP   QUEUE
28.0.0.140.0.0.1 7
28.0.0.140.0.0.2 2
28.0.0.140.0.0.3 4
28.0.0.140.0.0.7 1
28.0.0.140.0.0.8 3
28.0.0.140.0.0.9 5
28.0.0.140.0.0.100
28.0.0.140.0.0.116

Signed-off-by: Sunil Kumar Kori 
---
v1..v2:
 - Fix checkpatch errors.

 usertools/dpdk-rss-flows.py | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/usertools/dpdk-rss-flows.py b/usertools/dpdk-rss-flows.py
index 73821eb471..b6edd7a2e0 100755
--- a/usertools/dpdk-rss-flows.py
+++ b/usertools/dpdk-rss-flows.py
@@ -188,11 +188,24 @@ def balanced_traffic(
 0x81, 0x15, 0x03, 0x66,
 )
 )
+# rss_key_default, see drivers/net/cnxk/cnxk_flow.c
+# Marvell's cnxk NICs take 48 bytes keys
+RSS_KEY_CNXK = bytes(
+(
+0xfe, 0xed, 0x0b, 0xad, 0xfe, 0xed, 0x0b, 0xad,
+0xfe, 0xed, 0x0b, 0xad, 0xfe, 0xed, 0x0b, 0xad,
+0xfe, 0xed, 0x0b, 0xad, 0xfe, 0xed, 0x0b, 0xad,
+0xfe, 0xed, 0x0b, 0xad, 0xfe, 0xed, 0x0b, 0xad,
+0xfe, 0xed, 0x0b, 0xad, 0xfe, 0xed, 0x0b, 0xad,
+0xfe, 0xed, 0x0b, 0xad, 0xfe, 0xed, 0x0b, 0xad,
+)
+)
 # fmt: on
 DEFAULT_DRIVER_KEYS = {
 "intel": RSS_KEY_INTEL,
 "mlx": RSS_KEY_MLX,
 "i40e": RSS_KEY_I40E,
+"cnxk": RSS_KEY_CNXK,
 }
 
 
@@ -202,7 +215,7 @@ def rss_key(value):
 try:
 key = binascii.unhexlify(value)
 if len(key) not in (40, 52):
-raise argparse.ArgumentTypeError("The key must be 40 or 52 bytes 
long")
+raise argparse.ArgumentTypeError("The key must be 40 to 52 bytes 
long")
 return key
 except (TypeError, ValueError) as e:
 raise argparse.ArgumentTypeError(str(e)) from e
@@ -299,7 +312,7 @@ def parse_args():
 default=RSS_KEY_INTEL,
 type=rss_key,
 help="""
-The random 40-bytes key used to compute the RSS hash. This option
+The random 40 to 52 bytes key used to compute the RSS hash. This option
 supports either a well-known name or the hex value of the key
 (well-known names: "intel", "mlx", default: "intel").
 """,
-- 
2.25.1

[PATCH 1/5] net/mlx5: add support for ptype match in hardware steering

2023-10-09 Thread Alexander Kozyrev

The packet type matching provides quick way of finding out
L2/L3/L4 protocols in a given packet. That helps with
optimized flow rules matching, eliminating the need of
stacking all the packet headers in the matching criteria.

Signed-off-by: Alexander Kozyrev 
---
 drivers/net/mlx5/hws/mlx5dr_definer.c | 170 ++
 drivers/net/mlx5/hws/mlx5dr_definer.h |   8 ++
 drivers/net/mlx5/mlx5_flow.h  |   3 +
 drivers/net/mlx5/mlx5_flow_hw.c   |   1 +
 4 files changed, 182 insertions(+)

diff --git a/drivers/net/mlx5/hws/mlx5dr_definer.c 
b/drivers/net/mlx5/hws/mlx5dr_definer.c
index 88f22e7f70..e3f4a3c0a8 100644
--- a/drivers/net/mlx5/hws/mlx5dr_definer.c
+++ b/drivers/net/mlx5/hws/mlx5dr_definer.c
@@ -16,11 +16,14 @@
 #define STE_NO_VLAN0x0
 #define STE_SVLAN  0x1
 #define STE_CVLAN  0x2
+#define STE_NO_L3  0x0
 #define STE_IPV4   0x1
 #define STE_IPV6   0x2
+#define STE_NO_L4  0x0
 #define STE_TCP0x1
 #define STE_UDP0x2
 #define STE_ICMP   0x3
+#define STE_ESP0x3
 
 #define MLX5DR_DEFINER_QUOTA_BLOCK 0
 #define MLX5DR_DEFINER_QUOTA_PASS  2
@@ -276,6 +279,88 @@ mlx5dr_definer_conntrack_tag(struct mlx5dr_definer_fc *fc,
DR_SET(tag, reg_value, fc->byte_off, fc->bit_off, fc->bit_mask);
 }
 
+static void
+mlx5dr_definer_ptype_l2_set(struct mlx5dr_definer_fc *fc,
+   const void *item_spec,
+   uint8_t *tag)
+{
+   bool inner = (fc->fname == MLX5DR_DEFINER_FNAME_PTYPE_L2_I);
+   const struct rte_flow_item_ptype *v = item_spec;
+   uint32_t packet_type = v->packet_type &
+   (inner ? RTE_PTYPE_INNER_L2_MASK : RTE_PTYPE_L2_MASK);
+   uint8_t l2_type = STE_NO_VLAN;
+
+   if (packet_type == (inner ? RTE_PTYPE_INNER_L2_ETHER : 
RTE_PTYPE_L2_ETHER))
+   l2_type = STE_NO_VLAN;
+   else if (packet_type == (inner ? RTE_PTYPE_INNER_L2_ETHER_VLAN : 
RTE_PTYPE_L2_ETHER_VLAN))
+   l2_type = STE_CVLAN;
+   else if (packet_type == (inner ? RTE_PTYPE_INNER_L2_ETHER_QINQ : 
RTE_PTYPE_L2_ETHER_QINQ))
+   l2_type = STE_SVLAN;
+
+   DR_SET(tag, l2_type, fc->byte_off, fc->bit_off, fc->bit_mask);
+}
+
+static void
+mlx5dr_definer_ptype_l3_set(struct mlx5dr_definer_fc *fc,
+   const void *item_spec,
+   uint8_t *tag)
+{
+   bool inner = (fc->fname == MLX5DR_DEFINER_FNAME_PTYPE_L3_I);
+   const struct rte_flow_item_ptype *v = item_spec;
+   uint32_t packet_type = v->packet_type &
+   (inner ? RTE_PTYPE_INNER_L3_MASK : RTE_PTYPE_L3_MASK);
+   uint8_t l3_type = STE_NO_L3;
+
+   if (packet_type == (inner ? RTE_PTYPE_INNER_L3_IPV4 : 
RTE_PTYPE_L3_IPV4))
+   l3_type = STE_IPV4;
+   else if (packet_type == (inner ? RTE_PTYPE_INNER_L3_IPV6 : 
RTE_PTYPE_L3_IPV6))
+   l3_type = STE_IPV6;
+
+   DR_SET(tag, l3_type, fc->byte_off, fc->bit_off, fc->bit_mask);
+}
+
+static void
+mlx5dr_definer_ptype_l4_set(struct mlx5dr_definer_fc *fc,
+   const void *item_spec,
+   uint8_t *tag)
+{
+   bool inner = (fc->fname == MLX5DR_DEFINER_FNAME_PTYPE_L4_I);
+   const struct rte_flow_item_ptype *v = item_spec;
+   uint32_t packet_type = v->packet_type &
+   (inner ? RTE_PTYPE_INNER_L4_MASK : RTE_PTYPE_L4_MASK);
+   uint8_t l4_type = STE_NO_L4;
+
+   if (packet_type == (inner ? RTE_PTYPE_INNER_L4_TCP : RTE_PTYPE_L4_TCP))
+   l4_type = STE_TCP;
+   else if (packet_type == (inner ? RTE_PTYPE_INNER_L4_UDP : 
RTE_PTYPE_L4_UDP))
+   l4_type = STE_UDP;
+   else if (packet_type == (inner ? RTE_PTYPE_INNER_L4_ESP : 
RTE_PTYPE_L4_ESP))
+   l4_type = STE_ESP;
+
+   DR_SET(tag, l4_type, fc->byte_off, fc->bit_off, fc->bit_mask);
+}
+
+static void
+mlx5dr_definer_ptype_l4_ext_set(struct mlx5dr_definer_fc *fc,
+   const void *item_spec,
+   uint8_t *tag)
+{
+   bool inner = (fc->fname == MLX5DR_DEFINER_FNAME_PTYPE_L4_EXT_I);
+   const struct rte_flow_item_ptype *v = item_spec;
+   uint32_t packet_type = v->packet_type &
+   (inner ? RTE_PTYPE_INNER_L4_MASK : RTE_PTYPE_L4_MASK);
+   uint8_t l4_type = STE_NO_L4;
+
+   if (packet_type == (inner ? RTE_PTYPE_INNER_L4_TCP : RTE_PTYPE_L4_TCP))
+   l4_type = STE_TCP;
+   else if (packet_type == (inner ? RTE_PTYPE_INNER_L4_UDP : 
RTE_PTYPE_L4_UDP))
+   l4_type = STE_UDP;
+   else if (packet_type == (inner ? RTE_PTYPE_INNER_L4_ICMP : 
RTE_PTYPE_L4_ICMP))
+   l4_type = STE_ICMP;
+
+   DR_SET(tag, l4_type, fc->byte_off, fc->bit_off, fc->bit_mask);
+}
+
 static void
 mlx5dr_definer_integrity_set(struct mlx5dr_definer_fc *fc,
 const void *item_spec,
@@ -1692,6 +1777,87 @@ mlx5dr_definer_conv_item_gre_key(st

[PATCH 2/5] net/mlx5/hws: add support for fragmented ptype match

2023-10-09 Thread Alexander Kozyrev

Expand packet type matching with support of the
Fragmented IP (Internet Protocol) packet type.

Signed-off-by: Alexander Kozyrev 
---
 drivers/net/mlx5/hws/mlx5dr_definer.c | 74 +++
 drivers/net/mlx5/hws/mlx5dr_definer.h |  2 +
 2 files changed, 56 insertions(+), 20 deletions(-)

diff --git a/drivers/net/mlx5/hws/mlx5dr_definer.c 
b/drivers/net/mlx5/hws/mlx5dr_definer.c
index e3f4a3c0a8..b2c0655790 100644
--- a/drivers/net/mlx5/hws/mlx5dr_definer.c
+++ b/drivers/net/mlx5/hws/mlx5dr_definer.c
@@ -361,6 +361,19 @@ mlx5dr_definer_ptype_l4_ext_set(struct mlx5dr_definer_fc 
*fc,
DR_SET(tag, l4_type, fc->byte_off, fc->bit_off, fc->bit_mask);
 }
 
+static void
+mlx5dr_definer_ptype_frag_set(struct mlx5dr_definer_fc *fc,
+ const void *item_spec,
+ uint8_t *tag)
+{
+   bool inner = (fc->fname == MLX5DR_DEFINER_FNAME_PTYPE_FRAG_I);
+   const struct rte_flow_item_ptype *v = item_spec;
+   uint32_t packet_type = v->packet_type &
+   (inner ? RTE_PTYPE_INNER_L4_FRAG : RTE_PTYPE_L4_FRAG);
+
+   DR_SET(tag, !!packet_type, fc->byte_off, fc->bit_off, fc->bit_mask);
+}
+
 static void
 mlx5dr_definer_integrity_set(struct mlx5dr_definer_fc *fc,
 const void *item_spec,
@@ -1828,31 +1841,52 @@ mlx5dr_definer_conv_item_ptype(struct 
mlx5dr_definer_conv_data *cd,
}
 
if (m->packet_type & RTE_PTYPE_L4_MASK) {
-   fc = &cd->fc[DR_CALC_FNAME(PTYPE_L4, false)];
-   fc->item_idx = item_idx;
-   fc->tag_set = &mlx5dr_definer_ptype_l4_set;
-   fc->tag_mask_set = &mlx5dr_definer_ones_set;
-   DR_CALC_SET(fc, eth_l2, l4_type_bwc, false);
+   /*
+* Fragmented IP (Internet Protocol) packet type.
+* Cannot be combined with Layer 4 Types (TCP/UDP).
+* The exact value must be specified in the mask.
+*/
+   if (m->packet_type == RTE_PTYPE_L4_FRAG) {
+   fc = &cd->fc[DR_CALC_FNAME(PTYPE_FRAG, false)];
+   fc->item_idx = item_idx;
+   fc->tag_set = &mlx5dr_definer_ptype_frag_set;
+   fc->tag_mask_set = &mlx5dr_definer_ones_set;
+   DR_CALC_SET(fc, eth_l2, ip_fragmented, false);
+   } else {
+   fc = &cd->fc[DR_CALC_FNAME(PTYPE_L4, false)];
+   fc->item_idx = item_idx;
+   fc->tag_set = &mlx5dr_definer_ptype_l4_set;
+   fc->tag_mask_set = &mlx5dr_definer_ones_set;
+   DR_CALC_SET(fc, eth_l2, l4_type_bwc, false);
 
-   fc = &cd->fc[DR_CALC_FNAME(PTYPE_L4_EXT, false)];
-   fc->item_idx = item_idx;
-   fc->tag_set = &mlx5dr_definer_ptype_l4_ext_set;
-   fc->tag_mask_set = &mlx5dr_definer_ones_set;
-   DR_CALC_SET(fc, eth_l2, l4_type, false);
+   fc = &cd->fc[DR_CALC_FNAME(PTYPE_L4_EXT, false)];
+   fc->item_idx = item_idx;
+   fc->tag_set = &mlx5dr_definer_ptype_l4_ext_set;
+   fc->tag_mask_set = &mlx5dr_definer_ones_set;
+   DR_CALC_SET(fc, eth_l2, l4_type, false);
+   }
}
 
if (m->packet_type & RTE_PTYPE_INNER_L4_MASK) {
-   fc = &cd->fc[DR_CALC_FNAME(PTYPE_L4, true)];
-   fc->item_idx = item_idx;
-   fc->tag_set = &mlx5dr_definer_ptype_l4_set;
-   fc->tag_mask_set = &mlx5dr_definer_ones_set;
-   DR_CALC_SET(fc, eth_l2, l4_type_bwc, true);
+   if (m->packet_type == RTE_PTYPE_INNER_L4_FRAG) {
+   fc = &cd->fc[DR_CALC_FNAME(PTYPE_FRAG, true)];
+   fc->item_idx = item_idx;
+   fc->tag_set = &mlx5dr_definer_ptype_frag_set;
+   fc->tag_mask_set = &mlx5dr_definer_ones_set;
+   DR_CALC_SET(fc, eth_l2, ip_fragmented, true);
+   } else {
+   fc = &cd->fc[DR_CALC_FNAME(PTYPE_L4, true)];
+   fc->item_idx = item_idx;
+   fc->tag_set = &mlx5dr_definer_ptype_l4_set;
+   fc->tag_mask_set = &mlx5dr_definer_ones_set;
+   DR_CALC_SET(fc, eth_l2, l4_type_bwc, true);
 
-   fc = &cd->fc[DR_CALC_FNAME(PTYPE_L4_EXT, true)];
-   fc->item_idx = item_idx;
-   fc->tag_set = &mlx5dr_definer_ptype_l4_ext_set;
-   fc->tag_mask_set = &mlx5dr_definer_ones_set;
-   DR_CALC_SET(fc, eth_l2, l4_type, true);
+   fc = &cd->fc[DR_CALC_FNAME(PTYPE_L4_EXT, true)];
+   fc->item_idx = item_idx;
+   fc->tag_set = &mlx5dr_definer_ptype_l4_ext_set;
+   fc->tag_mask_set = &mlx5dr_defi

[PATCH 3/5] doc: add PMD ptype item limitations

2023-10-09 Thread Alexander Kozyrev

From: Michael Baum 

Add limitations for ptype item support in "mlx5.rst" file.

Signed-off-by: Michael Baum 
---
 doc/guides/nics/features/mlx5.ini |  1 +
 doc/guides/nics/mlx5.rst  | 19 +++
 2 files changed, 20 insertions(+)

diff --git a/doc/guides/nics/features/mlx5.ini 
b/doc/guides/nics/features/mlx5.ini
index c0e0b779cf..ca23355a21 100644
--- a/doc/guides/nics/features/mlx5.ini
+++ b/doc/guides/nics/features/mlx5.ini
@@ -85,6 +85,7 @@ mpls = Y
 nvgre= Y
 port_id  = Y
 port_representor = Y
+ptype= Y
 quota= Y
 tag  = Y
 tcp  = Y
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 7bee57d9dd..26cf310e8e 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -646,6 +646,25 @@ Limitations
   - When using HWS flow engine (``dv_flow_en`` = 2),
 only meter mark action is supported.
 
+- Ptype:
+
+  - Only supports HW steering (``dv_flow_en=2``).
+  - The ``RTE_PTYPE_L2_ETHER_TIMESYNC``, ``RTE_PTYPE_L2_ETHER_ARP``, 
``RTE_PTYPE_L2_ETHER_LLDP``,
+``RTE_PTYPE_L2_ETHER_NSH``, ``RTE_PTYPE_L2_ETHER_PPPOE``, 
``RTE_PTYPE_L2_ETHER_FCOE``,
+``RTE_PTYPE_L2_ETHER_MPLS``, ``RTE_PTYPE_L3_IPV4_EXT``, 
``RTE_PTYPE_L3_IPV4_EXT_UNKNOWN``,
+``RTE_PTYPE_L3_IPV6_EXT``, ``RTE_PTYPE_L3_IPV6_EXT_UNKNOWN``, 
``RTE_PTYPE_L4_SCTP``,
+``RTE_PTYPE_L4_NONFRAG``, ``RTE_PTYPE_L4_IGMP``, 
``RTE_PTYPE_INNER_L3_IPV4_EXT``,
+``RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN``, ``RTE_PTYPE_INNER_L3_IPV6_EXT``,
+``RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN``, ``RTE_PTYPE_INNER_L4_SCTP`` and
+``RTE_PTYPE_INNER_L4_NONFRAG`` values are not supported.
+Using them as a value will cause unexpected behavior.
+  - The ``RTE_PTYPE_TUNNEL_X`` values are not supported. Using them as a 
value should fail.
+  - Matching on both outer and inner IP fragmented is supported using 
``RTE_PTYPE_L4_FRAG`` and
+``RTE_PTYPE_INNER_L4_FRAG`` values. They are not part of L4 types, so they 
should be provided
+explicitly as mask value during pattern template creation. Providing 
``RTE_PTYPE_L4_MASK``
+during pattern template creation and ``RTE_PTYPE_L4_FRAG`` during flow 
rule creation,
+will cause unexpected behavior.
+
 - Integrity:
 
   - Integrity offload is enabled starting from **ConnectX-6 Dx**.
-- 
2.18.2

[PATCH 0/5] ptype matching support in mlx5

2023-10-09 Thread Alexander Kozyrev

Add support for RTE_FLOW_ITEM_TYPE_PTYPE in mlx5 PMD.

Alexander Kozyrev (3):
  net/mlx5: add support for ptype match in hardware steering
  net/mlx5/hws: add support for fragmented ptype match
  net/mlx5/hws: fix integrity bits level

Michael Baum (2):
  doc: add PMD ptype item limitations
  net/mlx5/hws: remove csum check from L3 ok check

 doc/guides/nics/features/mlx5.ini |   1 +
 doc/guides/nics/mlx5.rst  |  38 -
 drivers/net/mlx5/hws/mlx5dr_definer.c | 216 +-
 drivers/net/mlx5/hws/mlx5dr_definer.h |  10 ++
 drivers/net/mlx5/mlx5_flow.h  |   3 +
 drivers/net/mlx5/mlx5_flow_hw.c   |   1 +
 6 files changed, 254 insertions(+), 15 deletions(-)

-- 
2.18.2

[PATCH 4/5] net/mlx5/hws: remove csum check from L3 ok check

2023-10-09 Thread Alexander Kozyrev

From: Michael Baum 

This patch changes the integrity item behavior for HW steering.

Old behavior: the "ipv4_csum_ok" checks only IPv4 checksum and "l3_ok"
checks everything is ok including IPv4 checksum.

New behavior: the "l3_ok" checks everything is ok excluding IPv4
checksum.

This change enables matching "l3_ok" in IPv6 packets since for IPv6
packets "ipv4_csum_ok" is always miss.
For SW steering the old behavior is kept as same as for L4 ok.

Signed-off-by: Michael Baum 
---
 doc/guides/nics/mlx5.rst  | 19 ---
 drivers/net/mlx5/hws/mlx5dr_definer.c |  6 ++
 2 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 26cf310e8e..ddec84a9bb 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -667,18 +667,23 @@ Limitations
 
 - Integrity:
 
-  - Integrity offload is enabled starting from **ConnectX-6 Dx**.
   - Verification bits provided by the hardware are ``l3_ok``, 
``ipv4_csum_ok``, ``l4_ok``, ``l4_csum_ok``.
   - ``level`` value 0 references outer headers.
   - Negative integrity item verification is not supported.
-  - Multiple integrity items not supported in a single flow rule.
-  - Flow rule items supplied by application must explicitly specify network 
headers referred by integrity item.
-For example, if integrity item mask sets ``l4_ok`` or ``l4_csum_ok`` bits, 
reference to L4 network header,
-TCP or UDP, must be in the rule pattern as well::
+  - With SW steering (``dv_flow_en=1``)
+- Integrity offload is enabled starting from **ConnectX-6 Dx**.
+- Multiple integrity items not supported in a single flow rule.
+- Flow rule items supplied by application must explicitly specify network 
headers referred by integrity item.
+  For example, if integrity item mask sets ``l4_ok`` or ``l4_csum_ok`` 
bits, reference to L4 network header,
+  TCP or UDP, must be in the rule pattern as well::
 
-  flow create 0 ingress pattern integrity level is 0 value mask l3_ok 
value spec l3_ok / eth / ipv6 / end …
+flow create 0 ingress pattern integrity level is 0 value mask l3_ok 
value spec l3_ok / eth / ipv6 / end …
 
-  flow create 0 ingress pattern integrity level is 0 value mask l4_ok 
value spec l4_ok / eth / ipv4 proto is udp / end …
+flow create 0 ingress pattern integrity level is 0 value mask l4_ok 
value spec l4_ok / eth / ipv4 proto is udp / end …
+
+  - With HW steering (``dv_flow_en=2``)
+- The ``l3_ok`` field represents all L3 checks, but nothing about whether 
IPv4 checksum ok.
+- The ``l4_ok`` field represents all L4 checks including L4 checksum ok.
 
 - Connection tracking:
 
diff --git a/drivers/net/mlx5/hws/mlx5dr_definer.c 
b/drivers/net/mlx5/hws/mlx5dr_definer.c
index b2c0655790..84d15a41df 100644
--- a/drivers/net/mlx5/hws/mlx5dr_definer.c
+++ b/drivers/net/mlx5/hws/mlx5dr_definer.c
@@ -384,10 +384,8 @@ mlx5dr_definer_integrity_set(struct mlx5dr_definer_fc *fc,
uint32_t ok1_bits = 0;
 
if (v->l3_ok)
-   ok1_bits |= inner ? BIT(MLX5DR_DEFINER_OKS1_SECOND_L3_OK) |
-   
BIT(MLX5DR_DEFINER_OKS1_SECOND_IPV4_CSUM_OK) :
-   BIT(MLX5DR_DEFINER_OKS1_FIRST_L3_OK) |
-   BIT(MLX5DR_DEFINER_OKS1_FIRST_IPV4_CSUM_OK);
+   ok1_bits |= inner ? BIT(MLX5DR_DEFINER_OKS1_SECOND_L3_OK) :
+   BIT(MLX5DR_DEFINER_OKS1_FIRST_L3_OK);
 
if (v->ipv4_csum_ok)
ok1_bits |= inner ? 
BIT(MLX5DR_DEFINER_OKS1_SECOND_IPV4_CSUM_OK) :
-- 
2.18.2

[PATCH 5/5] net/mlx5/hws: fix integrity bits level

2023-10-09 Thread Alexander Kozyrev

The level field in the integrity item is not taken into account
in the current implementation of hardware steering.
Use this value instead of trying to find out the encapsulation
level according to the protocol items involved.

Fixes: c55c2bf35333 ("net/mlx5/hws: add definer layer")

Signed-off-by: Alexander Kozyrev 
---
 drivers/net/mlx5/hws/mlx5dr_definer.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/mlx5/hws/mlx5dr_definer.c 
b/drivers/net/mlx5/hws/mlx5dr_definer.c
index 84d15a41df..b092249c0a 100644
--- a/drivers/net/mlx5/hws/mlx5dr_definer.c
+++ b/drivers/net/mlx5/hws/mlx5dr_definer.c
@@ -1897,7 +1897,6 @@ mlx5dr_definer_conv_item_integrity(struct 
mlx5dr_definer_conv_data *cd,
 {
const struct rte_flow_item_integrity *m = item->mask;
struct mlx5dr_definer_fc *fc;
-   bool inner = cd->tunnel;
 
if (!m)
return 0;
@@ -1908,7 +1907,7 @@ mlx5dr_definer_conv_item_integrity(struct 
mlx5dr_definer_conv_data *cd,
}
 
if (m->l3_ok || m->ipv4_csum_ok || m->l4_ok || m->l4_csum_ok) {
-   fc = &cd->fc[DR_CALC_FNAME(INTEGRITY, inner)];
+   fc = &cd->fc[DR_CALC_FNAME(INTEGRITY, m->level)];
fc->item_idx = item_idx;
fc->tag_set = &mlx5dr_definer_integrity_set;
DR_CALC_SET_HDR(fc, oks1, oks1_bits);
@@ -2456,8 +2455,7 @@ mlx5dr_definer_conv_items_to_hl(struct mlx5dr_context 
*ctx,
break;
case RTE_FLOW_ITEM_TYPE_INTEGRITY:
ret = mlx5dr_definer_conv_item_integrity(&cd, items, i);
-   item_flags |= cd.tunnel ? 
MLX5_FLOW_ITEM_INNER_INTEGRITY :
- 
MLX5_FLOW_ITEM_OUTER_INTEGRITY;
+   item_flags |= MLX5_FLOW_ITEM_INTEGRITY;
break;
case RTE_FLOW_ITEM_TYPE_CONNTRACK:
ret = mlx5dr_definer_conv_item_conntrack(&cd, items, i);
-- 
2.18.2

RE: [EXTERNAL] Re: [PATCH] net/netvsc: add support for mtu_set

2023-10-09 Thread Sam Andrew

Hi Stephen,

From: Stephen Hemminger  
Sent: Monday, October 9, 2023 8:18 AM

> On Thu, 5 Oct 2023 23:17:28 +
> Sam Andrew  wrote:

> > +
> > +static int
> > +hn_dev_mtu_set(struct rte_eth_dev *dev, uint16_t mtu) {
> > +   struct hn_data *hv = dev->data->dev_private;
> > +   unsigned int orig_mtu = dev->data->mtu;
> > +   uint32_t rndis_mtu;
> > +   int ret = 0;
> > +   int i;
> > +
> > +   if (dev->data->dev_started) {
> > +   PMD_DRV_LOG(ERR, "Device must be stopped before changing MTU");
> > +   return -EIO;
> > +   }
> > +

> It looks like this proposed patch does not have the accelerated networking
> virtual device case.  The driver needs to first update the MTU of the 
> underlying
> VF device (and handle errors), then reinit the vmbus device.

The following line should handle the AN virtual device case:

+   /* Change MTU of underlying VF dev first, if it exists */
+   ret = hn_vf_mtu_set(dev, mtu);
+   if (ret)
+   return ret;

This is the new method added in hn_vf.c:

--- a/drivers/net/netvsc/hn_vf.c
+++ b/drivers/net/netvsc/hn_vf.c
@@ -778,3 +784,18 @@ int hn_vf_reta_hash_update(struct rte_eth_dev *dev,
 
return ret;
 }
+
+int hn_vf_mtu_set(struct rte_eth_dev *dev, uint16_t mtu) {
+   struct hn_data *hv = dev->data->dev_private;
+   struct rte_eth_dev *vf_dev;
+   int ret = 0;
+
+   rte_rwlock_read_lock(&hv->vf_lock);
+   vf_dev = hn_get_vf_dev(hv);
+   if (hv->vf_ctx.vf_vsc_switched && vf_dev)
+   ret = vf_dev->dev_ops->mtu_set(vf_dev, mtu);
+   rte_rwlock_read_unlock(&hv->vf_lock);
+
+   return ret;
+}

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

2023-10-09 Thread Mattias Rönnblom


On 2023-10-06 10:46, David Marchand wrote:

Hello Mattias,

On Thu, Oct 5, 2023 at 12:09 PM Mattias Rönnblom  wrote:

+
+deps += ['eventdev']
diff --git a/lib/dispatcher/rte_dispatcher.c b/lib/dispatcher/rte_dispatcher.c
new file mode 100644
index 00..0e69db2b9b
--- /dev/null
+++ b/lib/dispatcher/rte_dispatcher.c
@@ -0,0 +1,708 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2023 Ericsson AB
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "eventdev_pmd.h"
+
+#include 
+
+#define EVD_MAX_PORTS_PER_LCORE 4
+#define EVD_MAX_HANDLERS 32
+#define EVD_MAX_FINALIZERS 16
+#define EVD_AVG_PRIO_INTERVAL 2000
+#define EVD_SERVICE_NAME "dispatcher"
+
+struct rte_dispatcher_lcore_port {
+   uint8_t port_id;
+   uint16_t batch_size;
+   uint64_t timeout;
+};
+
+struct rte_dispatcher_handler {
+   int id;
+   rte_dispatcher_match_t match_fun;
+   void *match_data;
+   rte_dispatcher_process_t process_fun;
+   void *process_data;
+};
+
+struct rte_dispatcher_finalizer {
+   int id;
+   rte_dispatcher_finalize_t finalize_fun;
+   void *finalize_data;
+};
+
+struct rte_dispatcher_lcore {
+   uint8_t num_ports;
+   uint16_t num_handlers;
+   int32_t prio_count;
+   struct rte_dispatcher_lcore_port ports[EVD_MAX_PORTS_PER_LCORE];
+   struct rte_dispatcher_handler handlers[EVD_MAX_HANDLERS];
+   struct rte_dispatcher_stats stats;
+} __rte_cache_aligned;
+
+struct rte_dispatcher {
+   uint8_t event_dev_id;
+   int socket_id;
+   uint32_t service_id;
+   struct rte_dispatcher_lcore lcores[RTE_MAX_LCORE];
+   uint16_t num_finalizers;
+   struct rte_dispatcher_finalizer finalizers[EVD_MAX_FINALIZERS];
+};
+
+static int
+evd_lookup_handler_idx(struct rte_dispatcher_lcore *lcore,
+  const struct rte_event *event)


Wrt DPDK coding tyle, indent is a single tab.
Adding an extra tab is recommended when continuing control statements
like if()/for()/..



Sure, but I don't understand why you mention this.


I wanted to remind the DPDK coding style which I try to more closely
enforce for new code.
indent is off in this file (especially for function prototypes with
multiple tabs used).



I just didn't understand what rule I was breaking, but I see now.




On the other hand, max accepted length for a line is 100 columns.

Wdyt of a single line for this specific case?



Are you asking why the evd_lookup_handler_idx() function prototype is
not a single line?

It would make it long, that's why. Even if 100 wide lines are allowed,
it doesn't means the author is forced to use such long lines?


I find it more readable.
If you want to stick to 80 columns, please comply with a single tab for indent.

[snip]



+static int
+evd_set_service_runstate(struct rte_dispatcher *dispatcher, int state)
+{
+   int rc;
+
+   rc = rte_service_component_runstate_set(dispatcher->service_id,
+   state);
+
+   if (rc != 0) {
+   RTE_EDEV_LOG_ERR("Unexpected error %d occurred while setting "
+"service component run state to %d\n", rc,
+state);
+   RTE_ASSERT(0);


Why not propagating the error to callers?




The root cause would be a programming error, hence an assertion is more
appropriate way to deal with the situation.


Without building RTE_ENABLE_ASSERT (disabled by default), the code
later in this function will still be executed.



If RTE_ASSERT() is not the way to assure a consistent internal library 
state, what is? RTE_VERIFY()?


A side note: in the DPDK code base, the majority of 
rte_service_component_runstate_set() calls ignore the return value. No 
big surprise, since in many cases this error can't happen with less than 
the internal state being inconsistent.



[snip]



+typedef void
+(*rte_dispatcher_finalize_t)(uint8_t event_dev_id, uint8_t event_port_id,
+  void *cb_data);
+
+/**
+ * Dispatcher statistics
+ */
+struct rte_dispatcher_stats {
+   uint64_t poll_count;
+   /**< Number of event dequeue calls made toward the event device. */


We had a number of issues with doxygen post annotations.
Prefer the prefixed ones.



OK. More readable, too. I just used the postfix syntax since it seemed
the only one used in DPDK.


Historically yes, but we started cleaning headers for readability
(like in ethdev) and after catching a few errors with postfix
comments.

Re: [PATCH v5 2/3] test: add dispatcher test suite

2023-10-09 Thread Mattias Rönnblom


On 2023-10-06 10:52, David Marchand wrote:

On Thu, Oct 5, 2023 at 1:26 PM Mattias Rönnblom  wrote:

[snip]


+#define RETURN_ON_ERROR(rc) \
+   do {\
+   if (rc != TEST_SUCCESS) \
+   return rc;  \
+   } while (0)


TEST_ASSERT?
This gives context about which part of a test failed.



This macro is used in a situation where the failure has occured and has
been reported already.

Maybe it would be better to replace the macro instationation with just
the if+return statements.

RETURN_ON_ERROR(rc);

->

if (rc != TEST_SUCCESS)
 return rc;


Yes, this macro does not add much, you can remove it.



OK, will do.


[snip]



+   for (i = 0; i < NUM_SERVICE_CORES; i++)
+   if (app->service_lcores[i] == lcore_id)
+   return i;


This construct is hard to read and prone to error if the code is updated later.

for () {
if ()
  return i;
}




I wouldn't consider that an improvement (rather the opposite).


Well, I disagree, but it is not enforced in the coding style so I won't insist.

[snip]



+static struct unit_test_suite test_suite = {
+   .suite_name = "Event dispatcher test suite",
+   .unit_test_cases = {
+   TEST_CASE_ST(test_setup, test_teardown, test_basic),
+   TEST_CASE_ST(test_setup, test_teardown, test_drop),
+   TEST_CASE_ST(test_setup, test_teardown,
+test_many_handler_registrations),
+   TEST_CASE_ST(test_setup, test_teardown,
+test_many_finalize_registrations),
+   TEST_CASES_END()
+   }
+};
+
+static int
+test_dispatcher(void)
+{
+   return unit_test_suite_runner(&test_suite);
+}
+
+REGISTER_TEST_COMMAND(dispatcher_autotest, test_dispatcher);


We have new macros (see REGISTER_FAST_TEST for example) so a test is
associated to an existing testsuite.
I think this test should be part of the fast-test testsuite, wdyt?




It needs setup and teardown methods, so I assume a generic test suite
woulnd't do.

The dispatcher tests do have fairly short run times, so in that sense
they should qualify.



So please use REGISTER_FAST_TEST().
Thanks.




OK.

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

2023-10-09 Thread Mattias Rönnblom


On 2023-10-06 11:03, Thomas Monjalon wrote:

06/10/2023 10:46, David Marchand:

On Thu, Oct 5, 2023 at 12:09 PM Mattias Rönnblom  wrote:

+static int
+evd_lookup_handler_idx(struct rte_dispatcher_lcore *lcore,
+  const struct rte_event *event)


Wrt DPDK coding tyle, indent is a single tab.
Adding an extra tab is recommended when continuing control statements
like if()/for()/..



Sure, but I don't understand why you mention this.


I wanted to remind the DPDK coding style which I try to more closely
enforce for new code.
indent is off in this file (especially for function prototypes with
multiple tabs used).




On the other hand, max accepted length for a line is 100 columns.

Wdyt of a single line for this specific case?



Are you asking why the evd_lookup_handler_idx() function prototype is
not a single line?

It would make it long, that's why. Even if 100 wide lines are allowed,
it doesn't means the author is forced to use such long lines?


I find it more readable.
If you want to stick to 80 columns, please comply with a single tab for indent.


I think this is a case of continuation line, so it should be 2 tabs.
We can make it clear in the doc.



+static int
+evd_set_service_runstate(struct rte_dispatcher *dispatcher, int state)
+{
+   int rc;
+
+   rc = rte_service_component_runstate_set(dispatcher->service_id,
+   state);
+
+   if (rc != 0) {
+   RTE_EDEV_LOG_ERR("Unexpected error %d occurred while setting "
+"service component run state to %d\n", rc,
+state);
+   RTE_ASSERT(0);


Why not propagating the error to callers?




The root cause would be a programming error, hence an assertion is more
appropriate way to deal with the situation.


Without building RTE_ENABLE_ASSERT (disabled by default), the code
later in this function will still be executed.


Don't forget you are writing a library, so you shouldn't stop runtime
because of an error. It is always better to return errors.
Assert should be used only for debugging, that's why it is disabled by default.





A breach of the API contract should always be met with an assertion - 
library or not. That is the most helpful thing you can do, so that one 
fails early and programmer can go fix the bug.


The use of EINVAL and attempts to return error in the face of API 
violations is a bad practice, in my opinion. What could the program 
possible do, if it learns it's using a function the wrong way? If the 
two memory areas in memmove() overlap, should there be a error code, so 
that caller can retry but "please not with overlapping memory regions 
this time".


I know that the EINVAL pattern is wide-spread practice in DPDK, at the 
cost of performance and complexity, I would argue. I guess this practice 
originates from the kernel/libc tradition of validating system calls (a 
place where this can be actually be done in a reliable manner, unlike in 
normal user code).

[PATCH v6 0/3] Add dispatcher library

2023-10-09 Thread Mattias Rönnblom

The purpose of the dispatcher library is to decouple different parts
of an eventdev-based application (e.g., processing pipeline stages),
sharing the same underlying event device.

The dispatcher replaces the conditional logic (often, a switch
statement) that typically follows an event device dequeue operation,
where events are dispatched to different parts of the application
based on event meta data, such as the queue id or scheduling type.

The concept is similar to a UNIX file descriptor event loop library.
Instead of tying callback functions to fds as for example libevent
does, the dispatcher relies on application-supplied matching callback
functions to decide where to deliver events.

A dispatcher is configured to dequeue events from a specific event
device, and ties into the service core framework, to do its (and the
application's) work.

The dispatcher provides a convenient way for an eventdev-based
application to use service cores for application-level processing, and
thus for sharing those cores with other DPDK services.

Although the dispatcher adds some overhead, experience suggests that
the net effect on the application (both synthetic benchmarks and more
real-world applications) may well be positive. This is primarily due
to clustering (see programming guide) reducing cache misses.

Benchmarking indicates that the overhead is ~10 cc/event (on a
large core), with a handful of often-used handlers.

The dispatcher does not support run-time reconfiguration.

The use of the dispatcher library is optional, and an eventdev-based
application may still opt to access the event device using direct
eventdev API calls, or by some other means.

Mattias Rönnblom (3):
  lib: introduce dispatcher library
  test: add dispatcher test suite
  doc: add dispatcher programming guide

 MAINTAINERS  |6 +
 app/test/meson.build |1 +
 app/test/test_dispatcher.c   | 1045 ++
 doc/api/doxy-api-index.md|1 +
 doc/api/doxy-api.conf.in |1 +
 doc/guides/prog_guide/dispatcher_lib.rst |  433 +
 doc/guides/prog_guide/index.rst  |1 +
 doc/guides/rel_notes/release_23_11.rst   |5 +
 lib/dispatcher/meson.build   |   13 +
 lib/dispatcher/rte_dispatcher.c  |  691 ++
 lib/dispatcher/rte_dispatcher.h  |  466 ++
 lib/dispatcher/version.map   |   20 +
 lib/meson.build  |2 +
 13 files changed, 2685 insertions(+)
 create mode 100644 app/test/test_dispatcher.c
 create mode 100644 doc/guides/prog_guide/dispatcher_lib.rst
 create mode 100644 lib/dispatcher/meson.build
 create mode 100644 lib/dispatcher/rte_dispatcher.c
 create mode 100644 lib/dispatcher/rte_dispatcher.h
 create mode 100644 lib/dispatcher/version.map

-- 
2.34.1

[PATCH v6 1/3] lib: introduce dispatcher library

2023-10-09 Thread Mattias Rönnblom

The purpose of the dispatcher library is to help reduce coupling in an
Eventdev-based DPDK application.

In addition, the dispatcher also provides a convenient and flexible
way for the application to use service cores for application-level
processing.

Signed-off-by: Mattias Rönnblom 
Tested-by: Peter Nilsson 
Reviewed-by: Heng Wang 

--

PATCH v6:
 o Use single tab as indentation for continuation lines in multiple-line
   function prototypes. (David Marchand)
 o Add dispatcher library release note. (David Marchand)
 o Various indentation and spelling improvements. (David Marchand)
 o Add direct ,  and  includes,
   instead of relying on . (David Marchand)
 o Avoid Doxygen post annotations for struct fields. (David Marchand)

PATCH v5:
 o Move from using an integer id to a pointer to reference a dispatcher
   instance, to simplify the API.
 o Fix bug where dispatcher stats retrieval function erroneously depended
   on the user-supplied stats buffer being all-zero.

PATCH v4:
 o Fix bugs in handler and finalizer unregistration. (Naga Harish)
 o Return -EINVAL in cases where NULL pointers were provided in
   calls requiring non-NULL pointers. (Naga Harish)
 o Add experimental warning for the whole API. (Jerin Jacob)

PATCH v3:
 o To underline its optional character and since it does not provide
   hardware abstraction, the event dispatcher is now a separate
   library.
 o Change name from rte_event_dispatcher -> rte_dispatcher, to make it
   shorter and to avoid the rte_event_* namespace.

PATCH v2:
 o Add dequeue batch count statistic.
 o Add statistics reset function to API.
 o Clarify MT safety guarantees (or lack thereof) in the API documentation.
 o Change loop variable type in evd_lcore_get_handler_by_id() to uint16_t,
   to be consistent with similar loops elsewhere in the dispatcher.
 o Fix variable names in finalizer unregister function.

PATCH:
 o Change prefix from RED to EVD, to avoid confusion with random
   early detection.

RFC v4:
 o Move handlers to per-lcore data structures.
 o Introduce mechanism which rearranges handlers so that often-used
   handlers tend to be tried first.
 o Terminate dispatch loop in case all events are delivered.
 o To avoid the dispatcher's service function hogging the CPU, process
   only one batch per call.
 o Have service function return -EAGAIN if no work is performed.
 o Events delivered in the process function is no longer marked 'const',
   since modifying them may be useful for the application and cause
   no difficulties for the dispatcher.
 o Various minor API documentation improvements.

RFC v3:
 o Add stats_get() function to the version.map file.
---
 MAINTAINERS|   4 +
 doc/api/doxy-api-index.md  |   1 +
 doc/api/doxy-api.conf.in   |   1 +
 doc/guides/rel_notes/release_23_11.rst |   5 +
 lib/dispatcher/meson.build |  13 +
 lib/dispatcher/rte_dispatcher.c| 691 +
 lib/dispatcher/rte_dispatcher.h| 466 +
 lib/dispatcher/version.map |  20 +
 lib/meson.build|   2 +
 9 files changed, 1203 insertions(+)
 create mode 100644 lib/dispatcher/meson.build
 create mode 100644 lib/dispatcher/rte_dispatcher.c
 create mode 100644 lib/dispatcher/rte_dispatcher.h
 create mode 100644 lib/dispatcher/version.map

diff --git a/MAINTAINERS b/MAINTAINERS
index 00f5a5f9e6..a4372701c4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1733,6 +1733,10 @@ M: Nithin Dabilpuram 
 M: Pavan Nikhilesh 
 F: lib/node/
 
+Dispatcher - EXPERIMENTAL
+M: Mattias Rönnblom 
+F: lib/dispatcher/
+
 
 Test Applications
 -
diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
index fdeda13932..7d0cad9fed 100644
--- a/doc/api/doxy-api-index.md
+++ b/doc/api/doxy-api-index.md
@@ -155,6 +155,7 @@ The public API headers are grouped by topics:
 
 - **classification**
   [reorder](@ref rte_reorder.h),
+  [dispatcher](@ref rte_dispatcher.h),
   [distributor](@ref rte_distributor.h),
   [EFD](@ref rte_efd.h),
   [ACL](@ref rte_acl.h),
diff --git a/doc/api/doxy-api.conf.in b/doc/api/doxy-api.conf.in
index df801d32f9..93709e1d2c 100644
--- a/doc/api/doxy-api.conf.in
+++ b/doc/api/doxy-api.conf.in
@@ -34,6 +34,7 @@ INPUT   = @TOPDIR@/doc/api/doxy-api-index.md \
   @TOPDIR@/lib/cmdline \
   @TOPDIR@/lib/compressdev \
   @TOPDIR@/lib/cryptodev \
+  @TOPDIR@/lib/dispatcher \
   @TOPDIR@/lib/distributor \
   @TOPDIR@/lib/dmadev \
   @TOPDIR@/lib/efd \
diff --git a/doc/guides/rel_notes/release_23_11.rst 
b/doc/guides/rel_notes/release_23_11.rst
index 9319c86cd8..b5c5073018 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -80,6 +80,11 @@ New Features
   device is different from the Tx Ethernet device with re

[PATCH v6 3/3] doc: add dispatcher programming guide

2023-10-09 Thread Mattias Rönnblom

Provide programming guide for the dispatcher library.

Signed-off-by: Mattias Rönnblom 

--

PATCH v6:
 o Eliminate unneeded white space in code blocks. (David Marchand)

PATCH v5:
 o Update guide to match API changes related to dispatcher ids.

PATCH v3:
 o Adapt guide to the dispatcher API name changes.

PATCH:
 o Improve grammar and spelling.

RFC v4:
 o Extend event matching section of the programming guide.
 o Improve grammar and spelling.
---
 MAINTAINERS  |   1 +
 doc/guides/prog_guide/dispatcher_lib.rst | 433 +++
 doc/guides/prog_guide/index.rst  |   1 +
 3 files changed, 435 insertions(+)
 create mode 100644 doc/guides/prog_guide/dispatcher_lib.rst

diff --git a/MAINTAINERS b/MAINTAINERS
index 262401d43d..748c15cfe9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1737,6 +1737,7 @@ Dispatcher - EXPERIMENTAL
 M: Mattias Rönnblom 
 F: lib/dispatcher/
 F: app/test/test_dispatcher.c
+F: doc/guides/prog_guide/dispatcher_lib.rst
 
 
 Test Applications
diff --git a/doc/guides/prog_guide/dispatcher_lib.rst 
b/doc/guides/prog_guide/dispatcher_lib.rst
new file mode 100644
index 00..2ab798920c
--- /dev/null
+++ b/doc/guides/prog_guide/dispatcher_lib.rst
@@ -0,0 +1,433 @@
+..  SPDX-License-Identifier: BSD-3-Clause
+Copyright(c) 2023 Ericsson AB.
+
+Dispatcher
+==
+
+Overview
+
+
+The purpose of the dispatcher is to help reduce coupling in an
+:doc:`Eventdev `-based DPDK application.
+
+In particular, the dispatcher addresses a scenario where an
+application's modules share the same event device and event device
+ports, and performs work on the same lcore threads.
+
+The dispatcher replaces the conditional logic that follows an event
+device dequeue operation, where events are dispatched to different
+parts of the application, typically based on fields in the
+``rte_event``, such as the ``queue_id``, ``sub_event_type``, or
+``sched_type``.
+
+Below is an excerpt from a fictitious application consisting of two
+modules; A and B. In this example, event-to-module routing is based
+purely on queue id, where module A expects all events to a certain
+queue id, and module B two other queue ids. [#Mapping]_
+
+.. code-block:: c
+
+for (;;) {
+struct rte_event events[MAX_BURST];
+unsigned int n;
+
+n = rte_event_dequeue_burst(dev_id, port_id, events,
+   MAX_BURST, 0);
+
+for (i = 0; i < n; i++) {
+const struct rte_event *event = &events[i];
+
+switch (event->queue_id) {
+case MODULE_A_QUEUE_ID:
+module_a_process(event);
+break;
+case MODULE_B_STAGE_0_QUEUE_ID:
+module_b_process_stage_0(event);
+break;
+case MODULE_B_STAGE_1_QUEUE_ID:
+module_b_process_stage_1(event);
+break;
+}
+}
+}
+
+The issue this example attempts to illustrate is that the centralized
+conditional logic has knowledge of things that should be private to
+the modules. In other words, this pattern leads to a violation of
+module encapsulation.
+
+The shared conditional logic contains explicit knowledge about what
+events should go where. In case, for example, the
+``module_a_process()`` is broken into two processing stages — a
+module-internal affair — the shared conditional code must be updated
+to reflect this change.
+
+The centralized event routing code becomes an issue in larger
+applications, where modules are developed by different organizations.
+This pattern also makes module reuse across different application more
+difficult. The part of the conditional logic relevant for a particular
+application may need to be duplicated across many module
+instantiations (e.g., applications and test setups).
+
+The dispatcher separates the mechanism (routing events to their
+receiver) from the policy (which events should go where).
+
+The basic operation of the dispatcher is as follows:
+
+* Dequeue a batch of events from the event device.
+* For each event determine which handler should receive the event, using
+  a set of application-provided, per-handler event matching callback
+  functions.
+* Provide events matching a particular handler, to that handler, using
+  its process callback.
+
+If the above application would have made use of the dispatcher, the
+code relevant for its module A may have looked something like this:
+
+.. code-block:: c
+
+static bool
+module_a_match(const struct rte_event *event, void *cb_data)
+{
+   return event->queue_id == MODULE_A_QUEUE_ID;
+}
+
+static void
+module_a_process_events(uint8_t event_dev_id, uint8_t event_port_id,
+const struct rte_event *events,
+   uint16_t n

[PATCH v6 2/3] test: add dispatcher test suite

2023-10-09 Thread Mattias Rönnblom

Add unit tests for the dispatcher.

--

PATCH v6:
 o Register test as "fast". (David Marchand)
 o Use single tab as indentation for continuation lines in multiple-line
   function prototypes. (David Marchand)
 o Add Signed-off-by line. (David Marchand)
 o Use DPDK atomics wrapper API instead of C11 atomics.

PATCH v5:
 o Update test suite to use pointer and not integer id when calling
   dispatcher functions.

PATCH v3:
 o Adapt the test suite to dispatcher API name changes.

PATCH v2:
 o Test finalize callback functionality.
 o Test handler and finalizer count upper limits.
 o Add statistics reset test.
 o Make sure dispatcher supply the proper event dev id and port id back
   to the application.

PATCH:
 o Extend test to cover often-used handler optimization feature.

RFC v4:
 o Adapt to non-const events in process function prototype.

Signed-off-by: Mattias Rönnblom 
---
 MAINTAINERS|1 +
 app/test/meson.build   |1 +
 app/test/test_dispatcher.c | 1050 
 3 files changed, 1052 insertions(+)
 create mode 100644 app/test/test_dispatcher.c

diff --git a/MAINTAINERS b/MAINTAINERS
index a4372701c4..262401d43d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1736,6 +1736,7 @@ F: lib/node/
 Dispatcher - EXPERIMENTAL
 M: Mattias Rönnblom 
 F: lib/dispatcher/
+F: app/test/test_dispatcher.c
 
 
 Test Applications
diff --git a/app/test/meson.build b/app/test/meson.build
index bf9fc90612..ace10327f8 100644
--- a/app/test/meson.build
+++ b/app/test/meson.build
@@ -59,6 +59,7 @@ source_file_deps = {
 'test_cycles.c': [],
 'test_debug.c': [],
 'test_devargs.c': ['kvargs'],
+'test_dispatcher.c': ['dispatcher'],
 'test_distributor.c': ['distributor'],
 'test_distributor_perf.c': ['distributor'],
 'test_dmadev.c': ['dmadev', 'bus_vdev'],
diff --git a/app/test/test_dispatcher.c b/app/test/test_dispatcher.c
new file mode 100644
index 00..5a9c972d1f
--- /dev/null
+++ b/app/test/test_dispatcher.c
@@ -0,0 +1,1050 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2023 Ericsson AB
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "test.h"
+
+#define NUM_WORKERS 3
+
+#define NUM_PORTS (NUM_WORKERS + 1)
+#define WORKER_PORT_ID(worker_idx) (worker_idx)
+#define DRIVER_PORT_ID (NUM_PORTS - 1)
+
+#define NUM_SERVICE_CORES NUM_WORKERS
+
+/* Eventdev */
+#define NUM_QUEUES 8
+#define LAST_QUEUE_ID (NUM_QUEUES - 1)
+#define MAX_EVENTS 4096
+#define NEW_EVENT_THRESHOLD (MAX_EVENTS / 2)
+#define DEQUEUE_BURST_SIZE 32
+#define ENQUEUE_BURST_SIZE 32
+
+#define NUM_EVENTS 1000
+#define NUM_FLOWS 16
+
+#define DSW_VDEV "event_dsw0"
+
+struct app_queue {
+   uint8_t queue_id;
+   uint64_t sn[NUM_FLOWS];
+   int dispatcher_reg_id;
+};
+
+struct cb_count {
+   uint8_t expected_event_dev_id;
+   uint8_t expected_event_port_id[RTE_MAX_LCORE];
+   RTE_ATOMIC(int) count;
+};
+
+struct test_app {
+   uint8_t event_dev_id;
+   struct rte_dispatcher *dispatcher;
+   uint32_t dispatcher_service_id;
+
+   unsigned int service_lcores[NUM_SERVICE_CORES];
+
+   int never_match_reg_id;
+   uint64_t never_match_count;
+   struct cb_count never_process_count;
+
+   struct app_queue queues[NUM_QUEUES];
+
+   int finalize_reg_id;
+   struct cb_count finalize_count;
+
+   bool running;
+
+   RTE_ATOMIC(int) completed_events;
+   RTE_ATOMIC(int) errors;
+};
+
+static struct test_app *
+test_app_create(void)
+{
+   int i;
+   struct test_app *app;
+
+   app = calloc(1, sizeof(struct test_app));
+
+   if (app == NULL)
+   return NULL;
+
+   for (i = 0; i < NUM_QUEUES; i++)
+   app->queues[i].queue_id = i;
+
+   return app;
+}
+
+static void
+test_app_free(struct test_app *app)
+{
+   free(app);
+}
+
+static int
+test_app_create_vdev(struct test_app *app)
+{
+   int rc;
+
+   rc = rte_vdev_init(DSW_VDEV, NULL);
+   if (rc < 0)
+   return TEST_SKIPPED;
+
+   rc = rte_event_dev_get_dev_id(DSW_VDEV);
+
+   app->event_dev_id = (uint8_t)rc;
+
+   return TEST_SUCCESS;
+}
+
+static int
+test_app_destroy_vdev(struct test_app *app)
+{
+   int rc;
+
+   rc = rte_event_dev_close(app->event_dev_id);
+   TEST_ASSERT_SUCCESS(rc, "Error while closing event device");
+
+   rc = rte_vdev_uninit(DSW_VDEV);
+   TEST_ASSERT_SUCCESS(rc, "Error while uninitializing virtual device");
+
+   return TEST_SUCCESS;
+}
+
+static int
+test_app_setup_event_dev(struct test_app *app)
+{
+   int rc;
+   int i;
+
+   rc = test_app_create_vdev(app);
+   if (rc < 0)
+   return rc;
+
+   struct rte_event_dev_config config = {
+   .nb_event_queues = NUM_QUEUES,
+   .nb_event_ports = NUM_PORTS,
+   .nb_events_limit = MAX_EVENTS,
+   .nb_event_queue_flows = 64,
+   .nb_event_port_dequeue_

RE: [PATCH v4 0/7] cryptodev: support digest message in SM2

2023-10-09 Thread Akhil Goyal

> Subject: [PATCH v4 0/7] cryptodev: support digest message in SM2
> 
> This patch series fixes SM2 algorithm implementation to
> support digest message as input along with plain message
> as today.
> 
> v4:
>  - code rebase on next-crypto
> 

Added release notes for API changes introduced in 4/7 patch.
Updated some of the patch descriptions/title and release notes text.

Applied to dpdk-next-crypto

Thanks.

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

2023-10-09 Thread Patrick Robb

On Wed, Oct 4, 2023 at 11:13 AM Aaron Conole  wrote:

> Patrick Robb  writes:
>
> > Thanks, this should help greatly going forward in the community lab.
> >
> > As it relates to our arm64 unit testing, I will give it a few days (or
> longer if needed) for next branches to rebase off of
> > main and then re-enable arm64 unit testing with the
> eal_flags_file_prefix_autotest added to the skipped list. David
> > explained to me on slack that this patch would not likely be a candidate
> for backporting, so of course LTS will be
> > excluded.
>
> This is in testing area, and maybe it can be considered as an exception
> if it allows for improved LTS testing.  CC'd Kevin.
>
> Hello,

Yes, backporting would be ideal from a CI perspective because without it we
can't run arm64 testing on LTS tests. But I know there are other
considerations which also have to be weighed.

David also has a patch[1] which should resolve the underlying issue which
introduces the failures on the unit test we want to skip. If that patch is
accepted, and backported, fixing our original problem with unit testing on
our arm testbeds, that's another solution, at least for this specific unit
test issue.

It would still be nice to have this feature in case we need it otherwise.

[1]
https://patches.dpdk.org/project/dpdk/patch/20230821085806.3062613-4-david.march...@redhat.com/

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

2023-10-09 Thread Akhil Goyal

> Subject: [PATCH v2 0/5] add TLS record processing security offload
> 
> Add Transport Layer Security (TLS) and Datagram Transport Layer Security
> (DTLS). The protocols provide communications privacy for L4 protocols
> such as TCP & UDP.
> 
> TLS (and DTLS) protocol is composed of two layers,
> 1. TLS Record Protocol
> 2. TLS Handshake Protocol
> 
> While TLS Handshake Protocol helps in establishing security parameters
> by which client and server can communicate, TLS Record Protocol provides
> the connection security. TLS Record Protocol leverages symmetric
> cryptographic operations such as data encryption and authentication for
> providing security to the communications.
> 
> Cryptodevs that are capable of offloading TLS Record Protocol may
> perform other operations like IV generation, header insertion, atomic
> sequence number updates and anti-replay window check in addition to
> cryptographic transformations.
> 
> In record write operations, message content type is a per packet field
> which is used in constructing the TLS header. One session is expected
> to handle all types of content types and so, 'rte_crypto_op.aux_flags'
> is used for passing the same.
> 
> Support for TLS record protocol is added for TLS 1.2, TLS 1.3 and
> DTLS 1.2.
> 
> Changes in v2:
> - Replaced CCS with CHANGE_CIPHER_SPEC (Harry)
> - Split patches to clarify lifetime tracking and notification of the
>   same in rte_crypto_op (Harry)
> - Use 8 bits reserved space in rte_crypto_op to pass content type from
>   application to PMD (in case of record write) and from PMD to
>   application (in case of of record read). TLS 1.3 has content type as
>   part of trailer which would be encrypted and would be removed by PMD.
> - Updated documentation (Harry)
> 
> Akhil Goyal (1):
>   net: add headers for TLS/DTLS packets
> 
> Anoob Joseph (2):
>   security: add TLS record processing
>   security: support extra padding with TLS
> 
> Vidya Sagar Velumuri (2):
>   security: support TLS record lifetime notification
>   cryptodev: add details of datapath handling of TLS records
> 
>  doc/api/doxy-api-index.md  |   2 +
>  doc/guides/prog_guide/rte_security.rst |  74 +
>  doc/guides/rel_notes/release_23_11.rst |   6 ++
>  lib/cryptodev/rte_crypto.h |  50 -
>  lib/net/meson.build|   2 +
>  lib/net/rte_dtls.h |  61 +++
>  lib/net/rte_tls.h  |  48 +
>  lib/security/rte_security.c|   4 +
>  lib/security/rte_security.h| 144 +
>  9 files changed, 388 insertions(+), 3 deletions(-)
>  create mode 100644 lib/net/rte_dtls.h
>  create mode 100644 lib/net/rte_tls.h
> 
Series Applied to dpdk-next-crypto
Updated comments with minor formatting across the patches. Please check.

Thanks.

RE: [PATCH v3 1/2] security: add fallback security processing and Rx inject

2023-10-09 Thread Akhil Goyal

> Subject: [PATCH v3 1/2] security: add fallback security processing and Rx 
> inject
> 
> Add alternate datapath API for security processing which would do Rx
> injection (similar to loopback) after successful security processing.
> 
> With inline protocol offload, variable part of the session context
> (AR windows, lifetime etc in case of IPsec), is not accessible to the
> application. If packets are not getting processed in the inline path
> due to non security reasons (such as outer fragmentation or rte_flow
> packet steering limitations), then the packet cannot be security
> processed as the session context is private to the PMD and security
> library doesn't provide alternate APIs to make use of the same session.
> 
> Introduce new API and Rx injection as fallback mechanism to security
> processing failures due to non-security reasons. For example, when there
> is outer fragmentation and PMD doesn't support reassembly of outer
> fragments, application would receive fragments which it can then
> reassemble. Post successful reassembly, packet can be submitted for
> security processing and Rx inject. The packets can be then received in
> the application as normal inline protocol processed packets.
> 
> Same API can be leveraged in lookaside protocol offload mode to inject
> packet to Rx. This would help in using rte_flow based packet parsing
> after security processing. For example, with IPsec, this will help in
> flow splitting after IPsec processing is done.
> 
> In both inline protocol capable ethdevs and lookaside protocol capable
> cryptodevs, the packet would be received back in eth port & queue based
> on rte_flow rules and packet parsing after security processing. The API
> would behave like a loopback but with the additional security
> processing.
> 
> Signed-off-by: Anoob Joseph 
> Signed-off-by: Vidya Sagar Velumuri 
> ---
> v3:
> * Resolved compilation error with 32 bit build
Series Acked-by: Akhil Goyal 

Please add release notes for the new feature.

Minutes of Technical Board Meeting 2023-10-04

2023-10-09 Thread Stephen Hemminger



Members Attending
-
Aaron Conole
Bruce Richardson
Hemant Agrawal
Honappa Nagarahalli
Jerin Jacob
Kevin Traynor
Konstantin Ananyev
Maxime Coquelin
Stephen Hemminger
Thomas Monjalon

NOTE: The technical board meetings are on every second Wednesday at 3 pm UTC.
Meetings are public, and DPDK community members are welcome to attend.
This meeting was special, in Dublin on September 11th before the summit.
Agenda and minutes can be found at http://core.dpdk.org/techboard/minutes

Next meeting will be on Wednesday 2023-Oct-18 @ 3pm UTC, and will
be chaired by Thomas.

Agenda Items


Bugzilla

Ajit has said he will continue maintaining Bugzilla.
What additional maintenance is necessary?
The bug backlog has grown and it is not being used as much as it could be.
Would be good to have (automated?) status report to mailing list.
Need to make sure that all bugs are assigned to correct owners.

Techboard Minutes
-
Last entry on DPDK techboard minutes is from May 17.
Need to fill in with later minutes.
There will be gap in summer because a couple meetings did not have quorum.

Power Management

There was a discussion of power management in DPDK.
Thomas raised the issue that we don't describe power management in the
web site and marketing which leads to assumptions that DPDK does not
do any power management.

Kevin said that recent OpenVswitch changes dramatically improved power
consumption. He is writing a blog describing details.

Many network equipment vendors use (or base their design) off of testpmd
application which has no power management integration.
There is a proposed patch which is not integrated to do some sleeps in testpmd.
   http://inbox.dpdk.org/dev/20230316151438.186241-2-ahari...@redhat.com/
   
https://patchwork.dpdk.org/project/dpdk/list/?series=27422&state=%2A&archive=both
Still needs followup. Perhaps a more general and complete solution.

Power management in VM's is even more difficult. Guest really does not
have a good way to tell host desired power profile. Right now, the method
is to use interrupts which has long latency.
There has be some ongoing work on QEMU side:
   https://patchew.org/QEMU/20230616140830.316655-1-ahari...@redhat.com/

Power management also depends on work load and application.
The high impact changes are in the application; and there is not
a simple API for doing PM in application. There is a library for
power management in DPDK but it is not complete enough.

Upcoming Joint Meeting
--
There is an upcoming joint meeting of Tech and Governing board
on 17th Oct @ 10am EDT, 7am PDT, 1400 UTC.

RE: [PATCH v10 0/9] add rte flow support for cpfl

2023-10-09 Thread Zhang, Qi Z




> -Original Message-
> From: Zhang, Yuying 
> Sent: Monday, October 9, 2023 12:00 PM
> To: Zhang, Yuying ; dev@dpdk.org; Zhang, Qi Z
> ; Wu, Jingjing ; Xing, Beilei
> 
> Subject: [PATCH v10 0/9] add rte flow support for cpfl
> 
> From: Yuying Zhang 
> 
> This patchset add rte flow support for cpfl driver.
> It depends on the following patch set:
> http://patchwork.dpdk.org/project/dpdk/cover/20230912173039.1612287-1-
> beilei.x...@intel.com/
> 
> Wenjing Qiao (2):
>   net/cpfl: parse flow offloading hint from JSON
>   net/cpfl: build action mapping rules from JSON
> 
> Yuying Zhang (7):
>   net/cpfl: set up flow offloading skeleton
>   net/cpfl: set up control path
>   net/cpfl: add FXP low level implementation
>   net/cpfl: implement FXP rule creation and destroying
>   net/cpfl: adapt FXP to flow engine
>   net/cpfl: support flow ops on representor
>   net/cpfl: support represented port action
> ---
> v10:
> * fix ci build issue
> 
> v9:
> * refine rx queue message process function
> 
> v8:
> * fix compile issues
> * refine document and separate patch with different features
> 
> v7:
> * refine commit log
> * fix compile issues
> 
> v6:
> * use existed jansson instead of json-c library
> * refine "add FXP low level implementation"
> 
> V5:
> * Add input validation for some functions
> 
>  doc/guides/nics/cpfl.rst|   52 +
>  doc/guides/rel_notes/release_23_11.rst  |1 +
>  drivers/net/cpfl/cpfl_actions.h |  858 +++
>  drivers/net/cpfl/cpfl_controlq.c|  801 ++
>  drivers/net/cpfl/cpfl_controlq.h|   75 +
>  drivers/net/cpfl/cpfl_ethdev.c  |  392 -
>  drivers/net/cpfl/cpfl_ethdev.h  |  128 ++
>  drivers/net/cpfl/cpfl_flow.c|  339 +
>  drivers/net/cpfl/cpfl_flow.h|   85 ++
>  drivers/net/cpfl/cpfl_flow_engine_fxp.c |  666 
>  drivers/net/cpfl/cpfl_flow_parser.c | 1835 +++
>  drivers/net/cpfl/cpfl_flow_parser.h |  268 
>  drivers/net/cpfl/cpfl_fxp_rule.c|  263 
>  drivers/net/cpfl/cpfl_fxp_rule.h|   68 +
>  drivers/net/cpfl/cpfl_representor.c |   29 +
>  drivers/net/cpfl/cpfl_rules.c   |  127 ++
>  drivers/net/cpfl/cpfl_rules.h   |  306 
>  drivers/net/cpfl/cpfl_vchnl.c   |  144 ++
>  drivers/net/cpfl/meson.build|   12 +
>  19 files changed, 6448 insertions(+), 1 deletion(-)  create mode 100644
> drivers/net/cpfl/cpfl_actions.h  create mode 100644
> drivers/net/cpfl/cpfl_controlq.c  create mode 100644
> drivers/net/cpfl/cpfl_controlq.h  create mode 100644
> drivers/net/cpfl/cpfl_flow.c  create mode 100644 drivers/net/cpfl/cpfl_flow.h
> create mode 100644 drivers/net/cpfl/cpfl_flow_engine_fxp.c
>  create mode 100644 drivers/net/cpfl/cpfl_flow_parser.c
>  create mode 100644 drivers/net/cpfl/cpfl_flow_parser.h
>  create mode 100644 drivers/net/cpfl/cpfl_fxp_rule.c  create mode 100644
> drivers/net/cpfl/cpfl_fxp_rule.h  create mode 100644
> drivers/net/cpfl/cpfl_rules.c  create mode 100644 
> drivers/net/cpfl/cpfl_rules.h
> 
> --
> 2.34.1

Applied to dpdk-next-net-intel after reverted the old version.

Thanks
Qi

Re: [PATCH v4 1/2] dmadev: offload to auto free DMA buffer

2023-10-09 Thread fengchengwen


Acked-by: Chengwen Feng 

On 2023/10/9 20:02, Amit Prakash Shukla wrote:

This changeset adds support in DMA library to auto free DMA buffer by
hardware. On a supported hardware, application can pass on the mempool
information as part of vchan config.

Signed-off-by: Amit Prakash Shukla
Acked-by: Morten Brørup
Acked-by: Anoob Joseph
---
  lib/dmadev/rte_dmadev.h | 43 +
  1 file changed, 43 insertions(+)
...

RE: [PATCH v1] net/idpf: fix incorrect status calculation

2023-10-09 Thread Xing, Beilei




> -Original Message-
> From: Zhang, Yuying 
> Sent: Thursday, September 28, 2023 1:05 PM
> To: Zhang, Yuying ; dev@dpdk.org; Zhang, Qi Z
> ; Wu, Jingjing ; Xing, Beilei
> 
> Cc: sta...@dpdk.org
> Subject: [PATCH v1] net/idpf: fix incorrect status calculation
> 
> From: Yuying Zhang 
> 
> Fix the incorrect ingress packet number calculation.
> 
> Fixes: 7514d76d407b ("net/idpf: add basic statistics")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Yuying Zhang 
> ---
>  drivers/net/idpf/idpf_ethdev.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/idpf/idpf_ethdev.c b/drivers/net/idpf/idpf_ethdev.c
> index 3af7cf0bb7..6ae2ac2681 100644
> --- a/drivers/net/idpf/idpf_ethdev.c
> +++ b/drivers/net/idpf/idpf_ethdev.c
> @@ -281,7 +281,7 @@ idpf_dev_stats_get(struct rte_eth_dev *dev, struct
> rte_eth_stats *stats)
> 
>   idpf_vport_stats_update(&vport->eth_stats_offset, pstats);
>   stats->ipackets = pstats->rx_unicast + pstats->rx_multicast +
> - pstats->rx_broadcast - pstats->rx_discards;
> + pstats->rx_broadcast;

Seems rx_error is also considered in ingress packets.
Same for cpfl.

>   stats->opackets = pstats->tx_broadcast + pstats->tx_multicast
> +
>   pstats->tx_unicast;
>   stats->ierrors = pstats->rx_errors;
> --
> 2.34.1

[PATCH v2] net/virtio: fixed missing next flag when sending packets in packed mode

2023-10-09 Thread liufengjiang.0426

When the packets is sent in packed mode, and the packets data and
virtio-header are divided into two desc, set the next flag of
virtio-header desc

>> Fix the warning that a single line of commit log exceeds 75 chars

Bugzilla ID: 1295
Fixes: 892dc798fa9c ("net/virtio: implement Tx path for packed queues")

Signed-off-by: liufengjiang.0426 
---
 drivers/net/virtio/virtqueue.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/virtio/virtqueue.h b/drivers/net/virtio/virtqueue.h
index 9d4aba11a3..4e9f2d0358 100644
--- a/drivers/net/virtio/virtqueue.h
+++ b/drivers/net/virtio/virtqueue.h
@@ -672,6 +672,7 @@ virtqueue_enqueue_xmit_packed(struct virtnet_tx *txvq, 
struct rte_mbuf *cookie,
 */
start_dp[idx].addr = txvq->hdr_mem + 
RTE_PTR_DIFF(&txr[idx].tx_hdr, txr);
start_dp[idx].len = vq->hw->vtnet_hdr_size;
+   head_flags |= VRING_DESC_F_NEXT;
hdr = (struct virtio_net_hdr *)&txr[idx].tx_hdr;
idx++;
if (idx >= vq->vq_nentries) {
-- 
2.37.0.windows.1

Re: [PATCH v7 0/3] add telemetry cmds for ring

2023-10-09 Thread Jie Hai


Hi, Thomas,

Kindly ping for review.

Thanks,
Jie Hai

On 2023/7/4 17:04, Jie Hai wrote:

This patch set supports telemetry cmd to list rings and dump information
of a ring by its name.

v1->v2:
1. Add space after "switch".
2. Fix wrong strlen parameter.

v2->v3:
1. Remove prefix "rte_" for static function.
2. Add Acked-by Konstantin Ananyev for PATCH 1.
3. Introduce functions to return strings instead copy strings.
4. Check pointer to memzone of ring.
5. Remove redundant variable.
6. Hold lock when access ring data.

v3->v4:
1. Update changelog according to reviews of Honnappa Nagarahalli.
2. Add Reviewed-by Honnappa Nagarahalli.
3. Correct grammar in help information.
4. Correct spell warning on "te" reported by checkpatch.pl.
5. Use ring_walk() to query ring info instead of rte_ring_lookup().
6. Fix that type definition the flag field of rte_ring does not match the usage.
7. Use rte_tel_data_add_dict_uint_hex instead of rte_tel_data_add_dict_u64
for mask and flags.

v4->v5:
1. Add Acked-by Konstantin Ananyev and Chengwen Feng.
2. Add ABI change explanation for commit message of patch 1/3.

v5->v6:
1. Add Acked-by Morten Brørup.
2. Fix incorrect reference of commit.

v6->v7:
1. Remove prod/consumer head/tail info.

Jie Hai (3):
   ring: fix unmatched type definition and usage
   ring: add telemetry cmd to list rings
   ring: add telemetry cmd for ring info

  lib/ring/meson.build |   1 +
  lib/ring/rte_ring.c  | 135 +++
  lib/ring/rte_ring_core.h |   2 +-
  3 files changed, 137 insertions(+), 1 deletion(-)

RE: [PATCH v2] config/arm: update aarch32 build with gcc13

2023-10-09 Thread Ruifeng Wang

> -Original Message-
> From: Juraj Linkeš 
> Sent: Monday, October 9, 2023 5:53 PM
> To: tho...@monjalon.net; Honnappa Nagarahalli ;
> bruce.richard...@intel.com; Ruifeng Wang 
> Cc: dev@dpdk.org; Juraj Linkeš 
> Subject: [PATCH v2] config/arm: update aarch32 build with gcc13
> 
> The aarch32 with gcc13 fails with:
> 
> Compiler for C supports arguments -march=armv8-a: NO
> 
> ../config/arm/meson.build:714:12: ERROR: Problem encountered: No suitable 
> armv8 march
> version found.
> 
> This is because we test -march=armv8-a alone (without the -mpfu option), 
> which is no
> longer supported in gcc13 aarch32 builds.
> 
> The most recent recommendation from the compiler team is to build with 
> -march=armv8-a+simd
> -mfpu=auto, which should work for compilers old and new. The suggestion is to 
> first check
> -march=armv8-a+simd and only then check -mfpu=auto.
> 
> To address this, add a way to force the architecture (the value of the -march 
> option).
> 
> Signed-off-by: Juraj Linkeš 
> ---
>  config/arm/meson.build | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/config/arm/meson.build b/config/arm/meson.build index 
> 3f22d8a2fc..5303d0e969
> 100644
> --- a/config/arm/meson.build
> +++ b/config/arm/meson.build
> @@ -43,7 +43,9 @@ implementer_generic = {
>  },
>  'generic_aarch32': {
>  'march': 'armv8-a',
> -'compiler_options': ['-mfpu=neon'],
> +'force_march': true,
> +'march_features': ['simd'],
> +'compiler_options': ['-mfpu=auto'],
>  'flags': [
>  ['RTE_ARCH_ARM_NEON_MEMCPY', false],
>  ['RTE_ARCH_STRICT_ALIGN', true], @@ -711,7 +713,11 @@ if 
> update_flags
>  endif
>  endforeach
>  if candidate_march == ''
> -error('No suitable armv8 march version found.')
> +if part_number_config.get('force_march', false)
> +candidate_march = part_number_config['march']
> +else
> +error('No suitable armv8 march version found.')
> +endif
>  endif
>  if candidate_march != part_number_config['march']
>  warning('Configuration march version is ' + @@ -741,7 +747,7 @@ 
> if
> update_flags
>  # apply supported compiler options
>  if part_number_config.has_key('compiler_options')
>  foreach flag: part_number_config['compiler_options']
> -if cc.has_argument(flag)
> +if cc.has_multi_arguments(machine_args + [flag])
>  machine_args += flag
>  else
>  warning('Configuration compiler option ' +
> --
> 2.34.1

Acked-by: Ruifeng Wang

Re: [PATCH v2 1/1] usertools/rss: add CNXK RSS key

2023-10-09 Thread Jerin Jacob

On Mon, Oct 9, 2023 at 10:06 PM  wrote:
>
> From: Sunil Kumar Kori 
>
> This patch adds RSS key for CNXK platforms. CNXK platform uses
> 48 bytes long key for hash calculations.
>
> For the same patch also updates help mesaages to provide range
> information for supporting NICs/platforms.
>
> Also CNXK uses reta size as 64 so to get correct offset to retrieve
> queue index, user must pass reta_size option as 64 i.e. -t 64.
>
> Examples:
> $ ./dpdk-rss-flows.py -k cnxk 8 28.0.0.0/24 40.0.0.0/24 -t 64
> SRC_IP  DST_IP   QUEUE
> 28.0.0.140.0.0.1 7
> 28.0.0.140.0.0.2 2
> 28.0.0.140.0.0.3 4
> 28.0.0.140.0.0.7 1
> 28.0.0.140.0.0.8 3
> 28.0.0.140.0.0.9 5
> 28.0.0.140.0.0.100
> 28.0.0.140.0.0.116
>
> Signed-off-by: Sunil Kumar Kori 

Acked-by: Jerin Jacob

[PATCH] net/nfp: fix the initialization of physical representors

2023-10-09 Thread Chaoyong He

From: Zerun Fu 

The former logic of initializing the array of physical port
representors is according to 'nfp_idx', but referencing based
on 'port_id'. This is a potential bug and will cause segment
fault when these two values are not equal. Fix it by using the
'port_id' as index at all time.

Fixes: e1124c4f8a45 ("net/nfp: add flower representor framework")
Cc: chaoyong...@corigine.com
Cc: sta...@dpdk.org

Signed-off-by: Zerun Fu 
Reviewed-by: Long Wu 
Reviewed-by: Peng Zhang 
Reviewed-by: Chaoyong He 
---
 drivers/net/nfp/flower/nfp_flower_representor.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/net/nfp/flower/nfp_flower_representor.c 
b/drivers/net/nfp/flower/nfp_flower_representor.c
index 55ca3e6db0..e4c5d765e7 100644
--- a/drivers/net/nfp/flower/nfp_flower_representor.c
+++ b/drivers/net/nfp/flower/nfp_flower_representor.c
@@ -646,6 +646,7 @@ nfp_flower_repr_init(struct rte_eth_dev *eth_dev,
void *init_params)
 {
int ret;
+   uint16_t index;
unsigned int numa_node;
char ring_name[RTE_ETH_NAME_MAX_LEN];
struct nfp_app_fw_flower *app_fw_flower;
@@ -719,10 +720,13 @@ nfp_flower_repr_init(struct rte_eth_dev *eth_dev,
}
 
/* Add repr to correct array */
-   if (repr->repr_type == NFP_REPR_TYPE_PHYS_PORT)
-   app_fw_flower->phy_reprs[repr->nfp_idx] = repr;
-   else
-   app_fw_flower->vf_reprs[repr->vf_id] = repr;
+   if (repr->repr_type == NFP_REPR_TYPE_PHYS_PORT) {
+   index = NFP_FLOWER_CMSG_PORT_PHYS_PORT_NUM(repr->port_id);
+   app_fw_flower->phy_reprs[index] = repr;
+   } else {
+   index = repr->vf_id;
+   app_fw_flower->vf_reprs[index] = repr;
+   }
 
return 0;
 
-- 
2.39.1

[PATCH] net/nfp: update incorrect MAC stats offset

2023-10-09 Thread Chaoyong He

From: James Hershaw 

The pointer to the beginning of the MAC stats counters for port 1 are
incorrectly set as the pointer to the beginning of the port 0 MAC stats
counters, plus the size of the MAC stats counters multiplied by the port
number.

This patch corrects this by setting the multiplier as the eth_table
index of the port.

Fixes: f26e82397f6d ("net/nfp: implement xstats")
Cc: sta...@dpdk.org

Signed-off-by: James Hershaw 
Reviewed-by: Peng Zhang 
Reviewed-by: Chaoyong He 
---
 drivers/net/nfp/nfp_ethdev.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/nfp/nfp_ethdev.c b/drivers/net/nfp/nfp_ethdev.c
index ebc5538291..0645123c99 100644
--- a/drivers/net/nfp/nfp_ethdev.c
+++ b/drivers/net/nfp/nfp_ethdev.c
@@ -547,7 +547,8 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
return -ENODEV;
/* Use port offset in pf ctrl_bar for this ports control bar */
hw->ctrl_bar = pf_dev->ctrl_bar + (port * 
NFP_PF_CSR_SLICE_SIZE);
-   hw->mac_stats = app_fw_nic->ports[0]->mac_stats_bar + (port * 
NFP_MAC_STATS_SIZE);
+   hw->mac_stats = app_fw_nic->ports[0]->mac_stats_bar +
+   (hw->nfp_idx * NFP_MAC_STATS_SIZE);
}
 
PMD_INIT_LOG(DEBUG, "ctrl bar: %p", hw->ctrl_bar);
-- 
2.39.1

[PATCH] net/nfp: fix jumbo packet descriptors for NFDk

2023-10-09 Thread Chaoyong He

From: Long Wu 

When sending a jumbo packet on NFDk the packet must be split between
multiple descriptors. The first descriptor contains the packet header
and is limited to NFDK_DESC_TX_DMA_LEN_HEAD bytes. If the packet is
large, one or more payload descriptors, without a packet header, and
a size limit of NFDK_DESC_TX_DMA_LEN bytes are appended.

When adjusting the coding style for the for NFDk datapath an error was
made and the total packet size was modified when creating the first
descriptor. This resulted in no payload descriptors being created and
the jumbo packets where truncated.

Fix this by not modifying the total packet length when constructing the
first descriptor, allowing one or more payload descriptors to be
created.

Fixes: d7f6d9b21ffa ("net/nfp: adjust coding style for NFDk")
Cc: chaoyong...@corigine.com
Cc: sta...@dpdk.org

Signed-off-by: Long Wu 
Reviewed-by: Chaoyong He 
---
 drivers/net/nfp/nfdk/nfp_nfdk_dp.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/nfp/nfdk/nfp_nfdk_dp.c 
b/drivers/net/nfp/nfdk/nfp_nfdk_dp.c
index d4bd5edb0a..3f8230f89c 100644
--- a/drivers/net/nfp/nfdk/nfp_nfdk_dp.c
+++ b/drivers/net/nfp/nfdk/nfp_nfdk_dp.c
@@ -354,8 +354,10 @@ nfp_net_nfdk_xmit_pkts_common(void *tx_queue,
 * than packet head len.
 */
if (dma_len > NFDK_DESC_TX_DMA_LEN_HEAD)
-   dma_len = NFDK_DESC_TX_DMA_LEN_HEAD;
-   dlen_type = dma_len | (NFDK_DESC_TX_TYPE_HEAD & (type << 12));
+   tmp_dlen = NFDK_DESC_TX_DMA_LEN_HEAD;
+   else
+   tmp_dlen = dma_len;
+   dlen_type = tmp_dlen | (NFDK_DESC_TX_TYPE_HEAD & (type << 12));
ktxds->dma_len_type = rte_cpu_to_le_16(dlen_type);
dma_addr = rte_mbuf_data_iova(pkt);
ktxds->dma_addr_hi = rte_cpu_to_le_16(dma_addr >> 32);
@@ -366,7 +368,6 @@ nfp_net_nfdk_xmit_pkts_common(void *tx_queue,
 * Preserve the original dlen_type, this way below the EOP logic
 * can use dlen_type.
 */
-   tmp_dlen = dlen_type & NFDK_DESC_TX_DMA_LEN_HEAD;
dma_len -= tmp_dlen;
dma_addr += tmp_dlen + 1;
 
-- 
2.39.1

[PATCH 0/2] Fix two converity issue of NFP PMD

2023-10-09 Thread Chaoyong He

This patch series fix two converity issue 403098 and 403100.

Long Wu (2):
  net/nfp: fix checking return value
  net/nfp: fix illegal memory accesses

 drivers/net/nfp/nfpcore/nfp6000_pcie.c | 8 +---
 drivers/net/nfp/nfpcore/nfp_rtsym.c| 2 +-
 2 files changed, 6 insertions(+), 4 deletions(-)

-- 
2.39.1

1 2 >

1 - 100 of 106 matches

Mail list logo