date:20200712

11/07/2020 20:58, Ivan Dyukov:
> 11.07.2020 14:27, Thomas Monjalon пишет:
> > 11/07/2020 12:43, Ivan Dyukov:
> >> +__rte_experimental
> >> +int rte_eth_link_printf(const char *const fmt,
> >> +   const struct rte_eth_link *eth_link);
> >>
> > Maybe I missed your reply,
> > I still don't understand the need for this function.
> >
> I used it few times in apps in this patchset.  It allows to avoid code 
> duplication in examples. i.e. declare array, call rte_eth_link_to_str, 
> call printf.
> 
> It's simple and usefull function.  Why not?

Why not is not a good justification :)
We must avoid adding too much in the API.

Re: [dpdk-dev] [PATCH v5 1/2] rte_flow: add eCPRI key fields to flow API

2020-07-12 Thread Olivier Matz

Hi Bing,

On Sat, Jul 11, 2020 at 04:25:49AM +, Bing Zhao wrote:
> Hi Olivier,
> Many thanks for your comments.

[...]

> > > +/**
> > > + * eCPRI Common Header
> > > + */
> > > +RTE_STD_C11
> > > +struct rte_ecpri_common_hdr {
> > > +#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
> > > + uint32_t size:16;   /**< Payload Size */
> > > + uint32_t type:8;/**< Message Type */
> > > + uint32_t c:1;   /**< Concatenation Indicator
> > */
> > > + uint32_t res:3; /**< Reserved */
> > > + uint32_t revision:4;/**< Protocol Revision */
> > > +#elif RTE_BYTE_ORDER == RTE_BIG_ENDIAN
> > > + uint32_t revision:4;/**< Protocol Revision */
> > > + uint32_t res:3; /**< Reserved */
> > > + uint32_t c:1;   /**< Concatenation Indicator
> > */
> > > + uint32_t type:8;/**< Message Type */
> > > + uint32_t size:16;   /**< Payload Size */
> > > +#endif
> > > +} __rte_packed;
> > 
> > Does it really need to be packed? Why next types do not need it?
> > It looks only those which have bitfields are.
> > 
> 
> Nice catch, thanks. For the common header, there is no need to use
> the packed attribute, because it is a u32 and the bitfields will be
> aligned.
> I checked all the definitions again. Only " Type #4: Remote Memory Access"
> needs to use the packed attribute.
> For other sub-types, "sub-header" part of the message payload will get
> aligned by nature. For example, u16 after u16, u8 after u16, these should
> be OK.
> But in type #4, the address is 48bits wide, with 16bits MSB and 32bits LSB (no
> detailed description in the specification, correct me if anything wrong.) 
> Usually,
> the 48bits address will be devided as this in a system. And there is no 
> 48-bits
> type at all. So we need to define two parts for it: 32b LSB follows 16b MSB.
> u32 after u16 should be with packed attribute. Thanks

What about using a bitfield into a uint64_t ? I mean:

struct rte_ecpri_msg_rm_access {
if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
...
uint64_t length:16; /**< number of bytes */
uint64_t addr:48;   /**< address */
#else
...
uint64_t addr:48;   /**< address */
uint64_t length:16; /**< number of bytes */
#endif
};


> 
> > 
> > I wonder if the 'dw0' could be in this definition instead of in struct
> > rte_ecpri_msg_hdr?
> > 
> > Something like this:
> > 
> > struct rte_ecpri_common_hdr {
> > union {
> > uint32_t u32;
> > struct {
> > ...
> > };
> > };
> > };
> > 
> > I see 2 advantages:
> > 
> > - someone that only uses the common_hdr struct can use the .u32
> >   in its software
> > - when using it in messages, it looks clearer to me:
> > msg.common_hdr.u32 = value;
> >   instead of:
> > msg.dw0 = value;
> > 
> > What do you think?
> 
> Thanks for the suggestion, this is much better, I will change it.
> Indeed, in my original version, no DW(u32) is defined for the header.
> After that, I noticed that it would not be easy for the static casting to a 
> u32
> from bitfield(the compiler will complain), and it would not be clear to
> swap the endian if the user wants to use this header. I added this DW(u32)
> to simplify the usage of this header. But yes, if I do not add it here, it 
> would
> be not easy or clear for users who just use this header structure.
> I will change it. Is it OK if I use the name "dw0"?

In my opinion, u32 is more usual than dw0.

> 
> > 
> > > +
> > > +/**
> > > + * eCPRI Message Header of Type #0: IQ Data  */ struct
> > > +rte_ecpri_msg_iq_data {
> > > + rte_be16_t pc_id;   /**< Physical channel ID */
> > > + rte_be16_t seq_id;  /**< Sequence ID */
> > > +};
> > > +
> > > +/**
> > > + * eCPRI Message Header of Type #1: Bit Sequence  */ struct
> > > +rte_ecpri_msg_bit_seq {
> > > + rte_be16_t pc_id;   /**< Physical channel ID */
> > > + rte_be16_t seq_id;  /**< Sequence ID */
> > > +};
> > > +
> > > +/**
> > > + * eCPRI Message Header of Type #2: Real-Time Control Data  */
> > struct
> > > +rte_ecpri_msg_rtc_ctrl {
> > > + rte_be16_t rtc_id;  /**< Real-Time Control Data ID
> > */
> > > + rte_be16_t seq_id;  /**< Sequence ID */
> > > +};
> > > +
> > > +/**
> > > + * eCPRI Message Header of Type #3: Generic Data Transfer  */
> > struct
> > > +rte_ecpri_msg_gen_data {
> > > + rte_be32_t pc_id;   /**< Physical channel ID */
> > > + rte_be32_t seq_id;  /**< Sequence ID */
> > > +};
> > > +
> > > +/**
> > > + * eCPRI Message Header of Type #4: Remote Memory Access  */
> > > +RTE_STD_C11
> > > +struct rte_ecpri_msg_rm_access {
> > > +#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
> > > + uint32_t ele_id:16; /**< Element ID */
> > > + uint32_t rr:4;

[dpdk-dev] [PATCH v6 0/2] rte_flow: introduce eCPRI item for rte_flow

This patch set contains two commits.
1. header definition of the ethdev API
2. testpmd support for the eCPRI flow item

---
v2: Add dw0 for the eCPRI common header to switch the endianess, and
use fixed u32 value with big-endian for rte_flow_item_ecpri_mask.
It is due to the fact that global variable only support constant
expression in C when building.
v3: Add commit for testpmd support.
v4: update release notes part.
v5: fix type#6 define, add event indication macros, and comments for
revisions.
v6: 1. change the doxygen format into standard format
2. change the members definition of 'struct rte_ecpri_common_hdr'
3. fix the missing '^' in prog guide
4. change the address define in type #4, removed '__packed__'
5. change the name of 'rte_ecpri_msg_hdr'
   to 'rte_ecpri_combined_msg_hdr'
---

Bing Zhao (2):
  rte_flow: add eCPRI key fields to flow API
  app/testpmd: add eCPRI in flow creation patterns

 app/test-pmd/cmdline_flow.c| 144 ++
 doc/guides/prog_guide/rte_flow.rst |   8 ++
 doc/guides/rel_notes/release_20_08.rst |   5 +
 lib/librte_ethdev/rte_flow.c   |   1 +
 lib/librte_ethdev/rte_flow.h   |  33 ++
 lib/librte_net/Makefile|   1 +
 lib/librte_net/meson.build |   3 +-
 lib/librte_net/rte_ecpri.h | 183 +
 lib/librte_net/rte_ether.h |   1 +
 9 files changed, 378 insertions(+), 1 deletion(-)
 create mode 100644 lib/librte_net/rte_ecpri.h

-- 
1.8.3.1

[dpdk-dev] [PATCH v6 1/2] rte_flow: add eCPRI key fields to flow API

Add a new item "rte_flow_item_ecpri" in order to match eCRPI header.

eCPRI is a packet based protocol used in the fronthaul interface of
5G networks. Header format definition could be found in the
specification via the link below:
https://www.gigalight.com/downloads/standards/ecpri-specification.pdf

eCPRI message can be over Ethernet layer (.1Q supported also) or over
UDP layer. Message header formats are the same in these two variants.

Signed-off-by: Bing Zhao 
Acked-by: Ori Kam 
---
v2: Add dw0 for the eCPRI common header to switch the endianess, and
use fixed u32 value with big-endian for rte_flow_item_ecpri_mask.
It is due to the fact that global variable only support constant
expression in C when building.
v4: update release notes part.
v5: fix type#6 define, add event indication macros, and comments for
revisions.
v6: 1. change the doxygen format into standard format
2. change the members definition of 'struct rte_ecpri_common_hdr'
3. fix the missing '^' in prog guide
4. change the address define in type #4, removed '__packed__'
5. change the name of 'rte_ecpri_msg_hdr'
   to 'rte_ecpri_combined_msg_hdr'
---
 doc/guides/prog_guide/rte_flow.rst |   8 ++
 doc/guides/rel_notes/release_20_08.rst |   5 +
 lib/librte_ethdev/rte_flow.c   |   1 +
 lib/librte_ethdev/rte_flow.h   |  33 ++
 lib/librte_net/Makefile|   1 +
 lib/librte_net/meson.build |   3 +-
 lib/librte_net/rte_ecpri.h | 183 +
 lib/librte_net/rte_ether.h |   1 +
 8 files changed, 234 insertions(+), 1 deletion(-)
 create mode 100644 lib/librte_net/rte_ecpri.h

diff --git a/doc/guides/prog_guide/rte_flow.rst 
b/doc/guides/prog_guide/rte_flow.rst
index d5dd18c..3e5cd1e 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1362,6 +1362,14 @@ Matches a PFCP Header.
 - ``seid``: session endpoint identifier.
 - Default ``mask`` matches s_field and seid.
 
+Item: ``ECPRI``
+^^^
+
+Matches a eCPRI header.
+
+- ``hdr``: eCPRI header definition (``rte_ecpri.h``).
+- Default ``mask`` matches nothing, for all eCPRI messages.
+
 Actions
 ~~~
 
diff --git a/doc/guides/rel_notes/release_20_08.rst 
b/doc/guides/rel_notes/release_20_08.rst
index 3e07ee6..67888aa 100644
--- a/doc/guides/rel_notes/release_20_08.rst
+++ b/doc/guides/rel_notes/release_20_08.rst
@@ -205,6 +205,11 @@ New Features
   the  ``5tswap`` swaps source and destination in layers 2,3,4
   for ipv4 and ipv6 in L3 and UDP and TCP in L4.
 
+* **Added eCPRI protocol support in rte_flow.**
+
+  The ``ECPRI`` item have been added to support eCPRI packet offloading for
+  5G network.
+
 * **Added flow performance test application.**
 
   Added new application to test ``rte_flow`` performance, including:
diff --git a/lib/librte_ethdev/rte_flow.c b/lib/librte_ethdev/rte_flow.c
index 1685be5..f8fdd68 100644
--- a/lib/librte_ethdev/rte_flow.c
+++ b/lib/librte_ethdev/rte_flow.c
@@ -95,6 +95,7 @@ struct rte_flow_desc_data {
MK_FLOW_ITEM(HIGIG2, sizeof(struct rte_flow_item_higig2_hdr)),
MK_FLOW_ITEM(L2TPV3OIP, sizeof(struct rte_flow_item_l2tpv3oip)),
MK_FLOW_ITEM(PFCP, sizeof(struct rte_flow_item_pfcp)),
+   MK_FLOW_ITEM(ECPRI, sizeof(struct rte_flow_item_ecpri)),
 };
 
 /** Generate flow_action[] entry. */
diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
index b0e4199..da8bfa5 100644
--- a/lib/librte_ethdev/rte_flow.h
+++ b/lib/librte_ethdev/rte_flow.h
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -527,6 +528,15 @@ enum rte_flow_item_type {
 */
RTE_FLOW_ITEM_TYPE_PFCP,
 
+   /**
+* Matches eCPRI Header.
+*
+* Configure flow for eCPRI over ETH or UDP packets.
+*
+* See struct rte_flow_item_ecpri.
+*/
+   RTE_FLOW_ITEM_TYPE_ECPRI,
+
 };
 
 /**
@@ -1547,6 +1557,29 @@ struct rte_flow_item_pfcp {
 #endif
 
 /**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * RTE_FLOW_ITEM_TYPE_ECPRI
+ *
+ * Match eCPRI Header
+ */
+struct rte_flow_item_ecpri {
+   struct rte_ecpri_combined_msg_hdr hdr;
+};
+
+/** Default mask for RTE_FLOW_ITEM_TYPE_ECPRI. */
+#ifndef __cplusplus
+static const struct rte_flow_item_ecpri rte_flow_item_ecpri_mask = {
+   .hdr = {
+   .common = {
+   .u32 = 0x0,
+   },
+   },
+};
+#endif
+
+/**
  * Matching pattern item definition.
  *
  * A pattern is formed by stacking items starting from the lowest protocol
diff --git a/lib/librte_net/Makefile b/lib/librte_net/Makefile
index aa1d6fe..9830e77 100644
--- a/lib/librte_net/Makefile
+++ b/lib/librte_net/Makefile
@@ -20,5 +20,6 @@ SYMLINK-$(CONFIG_RTE_LIBRTE_NET)-include += rte_sctp.h 
rte_icmp.h rte_arp.h
 SYMLINK-$(CONFIG_RTE_LIBRTE_NET)-include += rte_ether.h rte_gre.h rte_net.h
 SYMLINK-$(CON

[dpdk-dev] [PATCH v6 2/2] app/testpmd: add eCPRI in flow creation patterns

In order to verify offloading of eCPRI protocol via flow rules, the
command line of flow creation should support the parsing of the eCPRI
pattern.

Based on the specification, one eCPRI message will have the common
header and payload. Payload format is various based on the type field
of the common header. Fixed strings will be used instead of integer
to make the CLI easy for auto-completion.

The testpmd command line examples of flow to match eCPRI item are
listed below:
  1. flow create 0 ... pattern eth / ecpri / end actions ...
This is to match all eCPRI messages.
  2. flow create 0 ... pattern eth / ecpri common type rtc_ctrl / end actions 
...
This is to match all eCPRI messages with the type #2 - "Real-Time
Control Data".
  3. flow create 0 ... pattern eth / ecpri common type iq_data pc_id is 
[U16Int] / end actions ...
This is to match eCPRI messages with the type #0 - "IQ Data", and
the physical channel ID 'pc_id' of the messages is a specific
value. Since the sequence ID is changeable, there is no need to
match that field in the flow.
Currently, only type #0, #2 and #5 will be supported.

Since eCPRI could be over Ethernet layer (or after .1Q) and UDP
layer, it is the PMD driver's responsibility to check whether eCPRI
is supported and which protocol stack is supported. Network byte
order should be used for eCPRI header, the same as other headers.

Signed-off-by: Bing Zhao 
Acked-by: Ori Kam 
---
v3: Add commit for testpmd support.
v6: change the members definition of 'struct rte_ecpri_common_hdr'
---
 app/test-pmd/cmdline_flow.c | 144 
 1 file changed, 144 insertions(+)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 4e2006c..6263d30 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -230,6 +230,15 @@ enum index {
ITEM_PFCP,
ITEM_PFCP_S_FIELD,
ITEM_PFCP_SEID,
+   ITEM_ECPRI,
+   ITEM_ECPRI_COMMON,
+   ITEM_ECPRI_COMMON_TYPE,
+   ITEM_ECPRI_COMMON_TYPE_IQ_DATA,
+   ITEM_ECPRI_COMMON_TYPE_RTC_CTRL,
+   ITEM_ECPRI_COMMON_TYPE_DLY_MSR,
+   ITEM_ECPRI_MSG_IQ_DATA_PCID,
+   ITEM_ECPRI_MSG_RTC_CTRL_RTCID,
+   ITEM_ECPRI_MSG_DLY_MSR_MSRID,
 
/* Validate/create actions. */
ACTIONS,
@@ -791,6 +800,7 @@ struct parse_action_priv {
ITEM_ESP,
ITEM_AH,
ITEM_PFCP,
+   ITEM_ECPRI,
END_SET,
ZERO,
 };
@@ -1101,6 +,24 @@ struct parse_action_priv {
ZERO,
 };
 
+static const enum index item_ecpri[] = {
+   ITEM_ECPRI_COMMON,
+   ITEM_NEXT,
+   ZERO,
+};
+
+static const enum index item_ecpri_common[] = {
+   ITEM_ECPRI_COMMON_TYPE,
+   ZERO,
+};
+
+static const enum index item_ecpri_common_type[] = {
+   ITEM_ECPRI_COMMON_TYPE_IQ_DATA,
+   ITEM_ECPRI_COMMON_TYPE_RTC_CTRL,
+   ITEM_ECPRI_COMMON_TYPE_DLY_MSR,
+   ZERO,
+};
+
 static const enum index next_action[] = {
ACTION_END,
ACTION_VOID,
@@ -1409,6 +1437,9 @@ static int parse_vc_spec(struct context *, const struct 
token *,
 const char *, unsigned int, void *, unsigned int);
 static int parse_vc_conf(struct context *, const struct token *,
 const char *, unsigned int, void *, unsigned int);
+static int parse_vc_item_ecpri_type(struct context *, const struct token *,
+   const char *, unsigned int,
+   void *, unsigned int);
 static int parse_vc_action_rss(struct context *, const struct token *,
   const char *, unsigned int, void *,
   unsigned int);
@@ -2802,6 +2833,66 @@ static int comp_set_raw_index(struct context *, const 
struct token *,
.next = NEXT(item_pfcp, NEXT_ENTRY(UNSIGNED), item_param),
.args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_pfcp, seid)),
},
+   [ITEM_ECPRI] = {
+   .name = "ecpri",
+   .help = "match eCPRI header",
+   .priv = PRIV_ITEM(ECPRI, sizeof(struct rte_flow_item_ecpri)),
+   .next = NEXT(item_ecpri),
+   .call = parse_vc,
+   },
+   [ITEM_ECPRI_COMMON] = {
+   .name = "common",
+   .help = "eCPRI common header",
+   .next = NEXT(item_ecpri_common),
+   },
+   [ITEM_ECPRI_COMMON_TYPE] = {
+   .name = "type",
+   .help = "type of common header",
+   .next = NEXT(item_ecpri_common_type),
+   .args = ARGS(ARG_ENTRY_HTON(struct rte_flow_item_ecpri)),
+   },
+   [ITEM_ECPRI_COMMON_TYPE_IQ_DATA] = {
+   .name = "iq_data",
+   .help = "Type #0: IQ Data",
+   .next = NEXT(NEXT_ENTRY(ITEM_ECPRI_MSG_IQ_DATA_PCID,
+   ITEM_NEXT)),
+   .call = parse_vc_item_ecpri_type,
+   },
+

Re: [dpdk-dev] [PATCH 20.11 3/5] rawdev: add private data length parameter to config fn

2020-07-12 Thread Xu, Rosen

Hi,

Reviewed-by: Rosen Xu 

> -Original Message-
> From: Richardson, Bruce 
> Sent: Thursday, July 09, 2020 23:21
> To: Nipun Gupta ; Hemant Agrawal
> 
> Cc: dev@dpdk.org; Xu, Rosen ; Zhang, Tianfei
> ; Li, Xiaoyun ; Wu, Jingjing
> ; Satha Rao ; Mahipal
> Challa ; Jerin Jacob ;
> Richardson, Bruce 
> Subject: [PATCH 20.11 3/5] rawdev: add private data length parameter to
> config fn
> 
> Currently with the rawdev API there is no way to check that the structure
> passed in via the dev_private pointer in the structure passed to configure API
> is of the correct type - it's just checked that it is non-NULL. Adding in the
> length of the expected structure provides a measure of typechecking, and
> can also be used for ABI compatibility in future, since ABI changes involving
> structs almost always involve a change in size.
> 
> Signed-off-by:  Bruce Richardson 
> ---
>  drivers/raw/ifpga/ifpga_rawdev.c| 3 ++-
>  drivers/raw/ioat/ioat_rawdev.c  | 5 +++--
>  drivers/raw/ioat/ioat_rawdev_test.c | 2 +-
>  drivers/raw/ntb/ntb.c   | 6 +-
>  drivers/raw/octeontx2_dma/otx2_dpi_rawdev.c | 7 ---
>  drivers/raw/octeontx2_dma/otx2_dpi_test.c   | 3 ++-
>  drivers/raw/octeontx2_ep/otx2_ep_rawdev.c   | 7 ---
>  drivers/raw/octeontx2_ep/otx2_ep_test.c | 2 +-
>  drivers/raw/skeleton/skeleton_rawdev.c  | 5 +++--
>  drivers/raw/skeleton/skeleton_rawdev_test.c | 5 +++--
>  examples/ioat/ioatfwd.c | 2 +-
>  examples/ntb/ntb_fwd.c  | 2 +-
>  lib/librte_rawdev/rte_rawdev.c  | 6 --
>  lib/librte_rawdev/rte_rawdev.h  | 8 +++-
>  lib/librte_rawdev/rte_rawdev_pmd.h  | 3 ++-
>  15 files changed, 43 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/raw/ifpga/ifpga_rawdev.c
> b/drivers/raw/ifpga/ifpga_rawdev.c
> index 32a2b96c9..a50173264 100644
> --- a/drivers/raw/ifpga/ifpga_rawdev.c
> +++ b/drivers/raw/ifpga/ifpga_rawdev.c
> @@ -684,7 +684,8 @@ ifpga_rawdev_info_get(struct rte_rawdev *dev,
> 
>  static int
>  ifpga_rawdev_configure(const struct rte_rawdev *dev,
> - rte_rawdev_obj_t config)
> + rte_rawdev_obj_t config,
> + size_t config_size __rte_unused)
>  {
>   IFPGA_RAWDEV_PMD_FUNC_TRACE();
> 
> diff --git a/drivers/raw/ioat/ioat_rawdev.c b/drivers/raw/ioat/ioat_rawdev.c
> index 6a336795d..b29ff983f 100644
> --- a/drivers/raw/ioat/ioat_rawdev.c
> +++ b/drivers/raw/ioat/ioat_rawdev.c
> @@ -41,7 +41,8 @@ RTE_LOG_REGISTER(ioat_pmd_logtype, rawdev.ioat,
> INFO);  #define COMPLETION_SZ sizeof(__m128i)
> 
>  static int
> -ioat_dev_configure(const struct rte_rawdev *dev, rte_rawdev_obj_t config)
> +ioat_dev_configure(const struct rte_rawdev *dev, rte_rawdev_obj_t
> config,
> + size_t config_size)
>  {
>   struct rte_ioat_rawdev_config *params = config;
>   struct rte_ioat_rawdev *ioat = dev->dev_private; @@ -51,7 +52,7
> @@ ioat_dev_configure(const struct rte_rawdev *dev, rte_rawdev_obj_t
> config)
>   if (dev->started)
>   return -EBUSY;
> 
> - if (params == NULL)
> + if (params == NULL || config_size != sizeof(*params))
>   return -EINVAL;
> 
>   if (params->ring_size > 4096 || params->ring_size < 64 || diff --git
> a/drivers/raw/ioat/ioat_rawdev_test.c
> b/drivers/raw/ioat/ioat_rawdev_test.c
> index 90f5974cd..e5b50ae9f 100644
> --- a/drivers/raw/ioat/ioat_rawdev_test.c
> +++ b/drivers/raw/ioat/ioat_rawdev_test.c
> @@ -165,7 +165,7 @@ ioat_rawdev_test(uint16_t dev_id)
>   }
> 
>   p.ring_size = IOAT_TEST_RINGSIZE;
> - if (rte_rawdev_configure(dev_id, &info) != 0) {
> + if (rte_rawdev_configure(dev_id, &info, sizeof(p)) != 0) {
>   printf("Error with rte_rawdev_configure()\n");
>   return -1;
>   }
> diff --git a/drivers/raw/ntb/ntb.c b/drivers/raw/ntb/ntb.c index
> eaeb67b74..c181094d5 100644
> --- a/drivers/raw/ntb/ntb.c
> +++ b/drivers/raw/ntb/ntb.c
> @@ -837,13 +837,17 @@ ntb_dev_info_get(struct rte_rawdev *dev,
> rte_rawdev_obj_t dev_info,  }
> 
>  static int
> -ntb_dev_configure(const struct rte_rawdev *dev, rte_rawdev_obj_t config)
> +ntb_dev_configure(const struct rte_rawdev *dev, rte_rawdev_obj_t
> config,
> + size_t config_size)
>  {
>   struct ntb_dev_config *conf = config;
>   struct ntb_hw *hw = dev->dev_private;
>   uint32_t xstats_num;
>   int ret;
> 
> + if (conf == NULL || config_size != sizeof(*conf))
> + return -EINVAL;
> +
>   hw->queue_pairs = conf->num_queues;
>   hw->queue_size = conf->queue_size;
>   hw->used_mw_num = conf->mz_num;
> diff --git a/drivers/raw/octeontx2_dma/otx2_dpi_rawdev.c
> b/drivers/raw/octeontx2_dma/otx2_dpi_rawdev.c
> index e398abb75..5b496446c 100644
> --- a/drivers/raw/octeontx2_dma/otx2_dpi_rawdev.c
> +++ b/drivers/raw/octeontx2_dma/otx2_dpi_rawdev.c
> @@ -294,7 +294,8 @@ otx2_dpi_rawdev_reset(struct rte_rawdev *dev)  }
> 
>  stat

Re: [dpdk-dev] [PATCH 20.11 1/5] rawdev: add private data length parameter to info fn

2020-07-12 Thread Xu, Rosen

Hi,

Reviewed-by: Rosen Xu 

> -Original Message-
> From: Richardson, Bruce 
> Sent: Thursday, July 09, 2020 23:21
> To: Nipun Gupta ; Hemant Agrawal
> 
> Cc: dev@dpdk.org; Xu, Rosen ; Zhang, Tianfei
> ; Li, Xiaoyun ; Wu, Jingjing
> ; Satha Rao ; Mahipal
> Challa ; Jerin Jacob ;
> Richardson, Bruce 
> Subject: [PATCH 20.11 1/5] rawdev: add private data length parameter to info
> fn
> 
> Currently with the rawdev API there is no way to check that the structure
> passed in via the dev_private pointer in the dev_info structure is of the
> correct type - it's just checked that it is non-NULL. Adding in the length of 
> the
> expected structure provides a measure of typechecking, and can also be
> used for ABI compatibility in future, since ABI changes involving structs
> almost always involve a change in size.
> 
> Signed-off-by:  Bruce Richardson 
> ---
>  drivers/bus/ifpga/ifpga_bus.c   |  2 +-
>  drivers/raw/ifpga/ifpga_rawdev.c|  5 +++--
>  drivers/raw/ioat/ioat_rawdev.c  |  5 +++--
>  drivers/raw/ioat/ioat_rawdev_test.c |  4 ++--
>  drivers/raw/ntb/ntb.c   |  8 +++-
>  drivers/raw/skeleton/skeleton_rawdev.c  |  5 +++--
>  drivers/raw/skeleton/skeleton_rawdev_test.c | 19 ---
>  examples/ioat/ioatfwd.c |  2 +-
>  examples/ntb/ntb_fwd.c  |  2 +-
>  lib/librte_rawdev/rte_rawdev.c  |  6 --
>  lib/librte_rawdev/rte_rawdev.h  |  9 -
>  lib/librte_rawdev/rte_rawdev_pmd.h  |  5 -
>  12 files changed, 49 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/bus/ifpga/ifpga_bus.c b/drivers/bus/ifpga/ifpga_bus.c
> index 6b16a20bb..bb8b3dcfb 100644
> --- a/drivers/bus/ifpga/ifpga_bus.c
> +++ b/drivers/bus/ifpga/ifpga_bus.c
> @@ -162,7 +162,7 @@ ifpga_scan_one(struct rte_rawdev *rawdev,
>   afu_dev->id.port  = afu_pr_conf.afu_id.port;
> 
>   if (rawdev->dev_ops && rawdev->dev_ops->dev_info_get)
> - rawdev->dev_ops->dev_info_get(rawdev, afu_dev);
> + rawdev->dev_ops->dev_info_get(rawdev, afu_dev,
> sizeof(*afu_dev));
> 
>   if (rawdev->dev_ops &&
>   rawdev->dev_ops->dev_start &&
> diff --git a/drivers/raw/ifpga/ifpga_rawdev.c
> b/drivers/raw/ifpga/ifpga_rawdev.c
> index cc25c662b..47cfa3877 100644
> --- a/drivers/raw/ifpga/ifpga_rawdev.c
> +++ b/drivers/raw/ifpga/ifpga_rawdev.c
> @@ -605,7 +605,8 @@ ifpga_fill_afu_dev(struct opae_accelerator *acc,
> 
>  static void
>  ifpga_rawdev_info_get(struct rte_rawdev *dev,
> -  rte_rawdev_obj_t dev_info)
> +   rte_rawdev_obj_t dev_info,
> +   size_t dev_info_size)
>  {
>   struct opae_adapter *adapter;
>   struct opae_accelerator *acc;
> @@ -617,7 +618,7 @@ ifpga_rawdev_info_get(struct rte_rawdev *dev,
> 
>   IFPGA_RAWDEV_PMD_FUNC_TRACE();
> 
> - if (!dev_info) {
> + if (!dev_info || dev_info_size != sizeof(*afu_dev)) {
>   IFPGA_RAWDEV_PMD_ERR("Invalid request");
>   return;
>   }
> diff --git a/drivers/raw/ioat/ioat_rawdev.c b/drivers/raw/ioat/ioat_rawdev.c
> index f876ffc3f..8dd856c55 100644
> --- a/drivers/raw/ioat/ioat_rawdev.c
> +++ b/drivers/raw/ioat/ioat_rawdev.c
> @@ -113,12 +113,13 @@ ioat_dev_stop(struct rte_rawdev *dev)  }
> 
>  static void
> -ioat_dev_info_get(struct rte_rawdev *dev, rte_rawdev_obj_t dev_info)
> +ioat_dev_info_get(struct rte_rawdev *dev, rte_rawdev_obj_t dev_info,
> + size_t dev_info_size)
>  {
>   struct rte_ioat_rawdev_config *cfg = dev_info;
>   struct rte_ioat_rawdev *ioat = dev->dev_private;
> 
> - if (cfg != NULL)
> + if (cfg != NULL && dev_info_size == sizeof(*cfg))
>   cfg->ring_size = ioat->ring_size;
>  }
> 
> diff --git a/drivers/raw/ioat/ioat_rawdev_test.c
> b/drivers/raw/ioat/ioat_rawdev_test.c
> index d99f1bd6b..90f5974cd 100644
> --- a/drivers/raw/ioat/ioat_rawdev_test.c
> +++ b/drivers/raw/ioat/ioat_rawdev_test.c
> @@ -157,7 +157,7 @@ ioat_rawdev_test(uint16_t dev_id)
>   return TEST_SKIPPED;
>   }
> 
> - rte_rawdev_info_get(dev_id, &info);
> + rte_rawdev_info_get(dev_id, &info, sizeof(p));
>   if (p.ring_size != expected_ring_size[dev_id]) {
>   printf("Error, initial ring size is not as expected (Actual: %d,
> Expected: %d)\n",
>   (int)p.ring_size, expected_ring_size[dev_id]);
> @@ -169,7 +169,7 @@ ioat_rawdev_test(uint16_t dev_id)
>   printf("Error with rte_rawdev_configure()\n");
>   return -1;
>   }
> - rte_rawdev_info_get(dev_id, &info);
> + rte_rawdev_info_get(dev_id, &info, sizeof(p));
>   if (p.ring_size != IOAT_TEST_RINGSIZE) {
>   printf("Error, ring size is not %d (%d)\n",
>   IOAT_TEST_RINGSIZE, (int)p.ring_size); diff --
> git a/drivers/raw/ntb/ntb.c b/drivers/raw/ntb/ntb.c index
> e40412bb

Re: [dpdk-dev] [PATCH 20.11 2/5] rawdev: allow drivers to return error from info function

2020-07-12 Thread Xu, Rosen

Hi,

Reviewed-by: Rosen Xu 

> -Original Message-
> From: Richardson, Bruce 
> Sent: Thursday, July 09, 2020 23:21
> To: Nipun Gupta ; Hemant Agrawal
> 
> Cc: dev@dpdk.org; Xu, Rosen ; Zhang, Tianfei
> ; Li, Xiaoyun ; Wu, Jingjing
> ; Satha Rao ; Mahipal
> Challa ; Jerin Jacob ;
> Richardson, Bruce 
> Subject: [PATCH 20.11 2/5] rawdev: allow drivers to return error from info
> function
> 
> Since we now allow some parameter checking inside the driver info_get()
> functions, it makes sense to allow error return from those functions to the
> caller. Therefore we change the driver callback return type from void to int.
> 
> Signed-off-by: Bruce Richardson 
> ---
>  drivers/raw/ifpga/ifpga_rawdev.c   | 15 ---
>  drivers/raw/ioat/ioat_rawdev.c |  9 ++---
>  drivers/raw/ntb/ntb.c  |  8 +---
>  drivers/raw/skeleton/skeleton_rawdev.c |  6 --
>  lib/librte_rawdev/rte_rawdev.c |  6 --
>  lib/librte_rawdev/rte_rawdev_pmd.h |  4 ++--
>  6 files changed, 29 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/raw/ifpga/ifpga_rawdev.c
> b/drivers/raw/ifpga/ifpga_rawdev.c
> index 47cfa3877..32a2b96c9 100644
> --- a/drivers/raw/ifpga/ifpga_rawdev.c
> +++ b/drivers/raw/ifpga/ifpga_rawdev.c
> @@ -603,7 +603,7 @@ ifpga_fill_afu_dev(struct opae_accelerator *acc,
>   return 0;
>  }
> 
> -static void
> +static int
>  ifpga_rawdev_info_get(struct rte_rawdev *dev,
> rte_rawdev_obj_t dev_info,
> size_t dev_info_size)
> @@ -620,12 +620,12 @@ ifpga_rawdev_info_get(struct rte_rawdev *dev,
> 
>   if (!dev_info || dev_info_size != sizeof(*afu_dev)) {
>   IFPGA_RAWDEV_PMD_ERR("Invalid request");
> - return;
> + return -EINVAL;
>   }
> 
>   adapter = ifpga_rawdev_get_priv(dev);
>   if (!adapter)
> - return;
> + return -ENOENT;
> 
>   afu_dev = dev_info;
>   afu_dev->rawdev = dev;
> @@ -637,7 +637,7 @@ ifpga_rawdev_info_get(struct rte_rawdev *dev,
> 
>   if (ifpga_fill_afu_dev(acc, afu_dev)) {
>   IFPGA_RAWDEV_PMD_ERR("cannot get info\n");
> - return;
> + return -ENOENT;
>   }
>   }
> 
> @@ -647,21 +647,21 @@ ifpga_rawdev_info_get(struct rte_rawdev *dev,
>   /* get LineSide BAR Index */
>   if (opae_manager_get_eth_group_region_info(mgr, 0,
>   &opae_lside_eth_info)) {
> - return;
> + return -ENOENT;
>   }
>   lside_bar_idx = opae_lside_eth_info.mem_idx;
> 
>   /* get NICSide BAR Index */
>   if (opae_manager_get_eth_group_region_info(mgr, 1,
>   &opae_nside_eth_info)) {
> - return;
> + return -ENOENT;
>   }
>   nside_bar_idx = opae_nside_eth_info.mem_idx;
> 
>   if (lside_bar_idx >= PCI_MAX_RESOURCE ||
>   nside_bar_idx >= PCI_MAX_RESOURCE ||
>   lside_bar_idx == nside_bar_idx)
> - return;
> + return -ENOENT;
> 
>   /* fill LineSide BAR Index */
>   afu_dev->mem_resource[lside_bar_idx].phys_addr = @@ -
> 679,6 +679,7 @@ ifpga_rawdev_info_get(struct rte_rawdev *dev,
>   afu_dev->mem_resource[nside_bar_idx].addr =
>   opae_nside_eth_info.addr;
>   }
> + return 0;
>  }
> 
>  static int
> diff --git a/drivers/raw/ioat/ioat_rawdev.c b/drivers/raw/ioat/ioat_rawdev.c
> index 8dd856c55..6a336795d 100644
> --- a/drivers/raw/ioat/ioat_rawdev.c
> +++ b/drivers/raw/ioat/ioat_rawdev.c
> @@ -112,15 +112,18 @@ ioat_dev_stop(struct rte_rawdev *dev)
>   RTE_SET_USED(dev);
>  }
> 
> -static void
> +static int
>  ioat_dev_info_get(struct rte_rawdev *dev, rte_rawdev_obj_t dev_info,
>   size_t dev_info_size)
>  {
>   struct rte_ioat_rawdev_config *cfg = dev_info;
>   struct rte_ioat_rawdev *ioat = dev->dev_private;
> 
> - if (cfg != NULL && dev_info_size == sizeof(*cfg))
> - cfg->ring_size = ioat->ring_size;
> + if (dev_info == NULL || dev_info_size != sizeof(*cfg))
> + return -EINVAL;
> +
> + cfg->ring_size = ioat->ring_size;
> + return 0;
>  }
> 
>  static const char * const xstat_names[] = { diff --git 
> a/drivers/raw/ntb/ntb.c
> b/drivers/raw/ntb/ntb.c index 4676c6f8f..eaeb67b74 100644
> --- a/drivers/raw/ntb/ntb.c
> +++ b/drivers/raw/ntb/ntb.c
> @@ -800,7 +800,7 @@ ntb_dequeue_bufs(struct rte_rawdev *dev,
>   return nb_rx;
>  }
> 
> -static void
> +static int
>  ntb_dev_info_get(struct rte_rawdev *dev, rte_rawdev_obj_t dev_info,
>   size_t dev_info_size)
>  {
> @@ -809,7 +809,7 @@ ntb_dev_info_get(struct rte_rawdev *dev,
> rte_rawdev_obj_t dev_info,
> 
>   if (dev_info_size != sizeof(*info)){
>   NTB_LO

Re: [dpdk-dev] [PATCH v5 1/2] rte_flow: add eCPRI key fields to flow API

Hi Olivier,
Thanks

BR. Bing

> -Original Message-
> From: Olivier Matz 
> Sent: Sunday, July 12, 2020 9:18 PM
> To: Bing Zhao 
> Cc: Ori Kam ; john.mcnam...@intel.com;
> marko.kovace...@intel.com; Thomas Monjalon
> ; ferruh.yi...@intel.com;
> arybche...@solarflare.com; akhil.go...@nxp.com; dev@dpdk.org;
> wenzhuo...@intel.com; beilei.x...@intel.com;
> bernard.iremon...@intel.com
> Subject: Re: [PATCH v5 1/2] rte_flow: add eCPRI key fields to flow API
> 
> Hi Bing,
> 
> On Sat, Jul 11, 2020 at 04:25:49AM +, Bing Zhao wrote:
> > Hi Olivier,
> > Many thanks for your comments.
> 
> [...]
> 
> > > > +/**
> > > > + * eCPRI Common Header
> > > > + */
> > > > +RTE_STD_C11
> > > > +struct rte_ecpri_common_hdr {
> > > > +#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
> > > > +   uint32_t size:16;   /**< Payload Size */
> > > > +   uint32_t type:8;/**< Message Type */
> > > > +   uint32_t c:1;   /**< Concatenation Indicator
> > > */
> > > > +   uint32_t res:3; /**< Reserved */
> > > > +   uint32_t revision:4;/**< Protocol Revision */
> > > > +#elif RTE_BYTE_ORDER == RTE_BIG_ENDIAN
> > > > +   uint32_t revision:4;/**< Protocol Revision */
> > > > +   uint32_t res:3; /**< Reserved */
> > > > +   uint32_t c:1;   /**< Concatenation Indicator
> > > */
> > > > +   uint32_t type:8;/**< Message Type */
> > > > +   uint32_t size:16;   /**< Payload Size */
> > > > +#endif
> > > > +} __rte_packed;
> > >
> > > Does it really need to be packed? Why next types do not need it?
> > > It looks only those which have bitfields are.
> > >
> >
> > Nice catch, thanks. For the common header, there is no need to use
> the
> > packed attribute, because it is a u32 and the bitfields will be
> > aligned.
> > I checked all the definitions again. Only " Type #4: Remote Memory
> Access"
> > needs to use the packed attribute.
> > For other sub-types, "sub-header" part of the message payload will
> get
> > aligned by nature. For example, u16 after u16, u8 after u16, these
> > should be OK.
> > But in type #4, the address is 48bits wide, with 16bits MSB and 32bits
> > LSB (no detailed description in the specification, correct me if
> > anything wrong.) Usually, the 48bits address will be devided as this
> > in a system. And there is no 48-bits type at all. So we need to define
> two parts for it: 32b LSB follows 16b MSB.
> > u32 after u16 should be with packed attribute. Thanks
> 
> What about using a bitfield into a uint64_t ? I mean:
> 
>   struct rte_ecpri_msg_rm_access {
> if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
>   ...
>   uint64_t length:16; /**< number of bytes
> */
>   uint64_t addr:48;   /**< address */
> #else
>   ...
>   uint64_t addr:48;   /**< address */
>   uint64_t length:16; /**< number of bytes
> */
> #endif
>   };
> 

Thanks for your suggestion.
https://stackoverflow.com/questions/10906238/warning-when-using-bitfield-with-unsigned-char
AFAIK (from this page), bitfields support only support bool and int. uint64_t 
is some type of "long"
and most of the compilers should support it. But I am not sure if it is a 
standard implementation.

> 
> >
> > >
> > > I wonder if the 'dw0' could be in this definition instead of in
> > > struct rte_ecpri_msg_hdr?
> > >
> > > Something like this:
> > >
> > > struct rte_ecpri_common_hdr {
> > >   union {
> > >   uint32_t u32;
> > >   struct {
> > >   ...
> > >   };
> > >   };
> > > };
> > >
> > > I see 2 advantages:
> > >
> > > - someone that only uses the common_hdr struct can use the .u32
> > >   in its software
> > > - when using it in messages, it looks clearer to me:
> > > msg.common_hdr.u32 = value;
> > >   instead of:
> > > msg.dw0 = value;
> > >
> > > What do you think?
> >
> > Thanks for the suggestion, this is much better, I will change it.
> > Indeed, in my original version, no DW(u32) is defined for the header.
> > After that, I noticed that it would not be easy for the static casting
> > to a u32 from bitfield(the compiler will complain), and it would not
> > be clear to swap the endian if the user wants to use this header. I
> > added this DW(u32) to simplify the usage of this header. But yes, if I
> > do not add it here, it would be not easy or clear for users who just
> use this header structure.
> > I will change it. Is it OK if I use the name "dw0"?
> 
> In my opinion, u32 is more usual than dw0.
> 

I sent patch set v6 with this change, thanks.

> >
> > >
> > > > +
> > > > +/**
> > > > + * eCPRI Message Header of Type #0: IQ Data  */ struct
> > > > +rte_ecpri_msg_iq_data {
> > > > +   rte_be16_t pc_id;   /**< Physical channel ID */
> > > > +   rte_be16_t seq_id;  /**< Sequence ID */
> > > >

Re: [dpdk-dev] [PATCH v5 1/2] rte_flow: add eCPRI key fields to flow API

2020-07-12 Thread Olivier Matz

On Sun, Jul 12, 2020 at 02:28:03PM +, Bing Zhao wrote:
> Hi Olivier,
> Thanks
> 
> BR. Bing
> 
> > -Original Message-
> > From: Olivier Matz 
> > Sent: Sunday, July 12, 2020 9:18 PM
> > To: Bing Zhao 
> > Cc: Ori Kam ; john.mcnam...@intel.com;
> > marko.kovace...@intel.com; Thomas Monjalon
> > ; ferruh.yi...@intel.com;
> > arybche...@solarflare.com; akhil.go...@nxp.com; dev@dpdk.org;
> > wenzhuo...@intel.com; beilei.x...@intel.com;
> > bernard.iremon...@intel.com
> > Subject: Re: [PATCH v5 1/2] rte_flow: add eCPRI key fields to flow API
> > 
> > Hi Bing,
> > 
> > On Sat, Jul 11, 2020 at 04:25:49AM +, Bing Zhao wrote:
> > > Hi Olivier,
> > > Many thanks for your comments.
> > 
> > [...]
> > 
> > > > > +/**
> > > > > + * eCPRI Common Header
> > > > > + */
> > > > > +RTE_STD_C11
> > > > > +struct rte_ecpri_common_hdr {
> > > > > +#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
> > > > > + uint32_t size:16;   /**< Payload Size */
> > > > > + uint32_t type:8;/**< Message Type */
> > > > > + uint32_t c:1;   /**< Concatenation Indicator
> > > > */
> > > > > + uint32_t res:3; /**< Reserved */
> > > > > + uint32_t revision:4;/**< Protocol Revision */
> > > > > +#elif RTE_BYTE_ORDER == RTE_BIG_ENDIAN
> > > > > + uint32_t revision:4;/**< Protocol Revision */
> > > > > + uint32_t res:3; /**< Reserved */
> > > > > + uint32_t c:1;   /**< Concatenation Indicator
> > > > */
> > > > > + uint32_t type:8;/**< Message Type */
> > > > > + uint32_t size:16;   /**< Payload Size */
> > > > > +#endif
> > > > > +} __rte_packed;
> > > >
> > > > Does it really need to be packed? Why next types do not need it?
> > > > It looks only those which have bitfields are.
> > > >
> > >
> > > Nice catch, thanks. For the common header, there is no need to use
> > the
> > > packed attribute, because it is a u32 and the bitfields will be
> > > aligned.
> > > I checked all the definitions again. Only " Type #4: Remote Memory
> > Access"
> > > needs to use the packed attribute.
> > > For other sub-types, "sub-header" part of the message payload will
> > get
> > > aligned by nature. For example, u16 after u16, u8 after u16, these
> > > should be OK.
> > > But in type #4, the address is 48bits wide, with 16bits MSB and 32bits
> > > LSB (no detailed description in the specification, correct me if
> > > anything wrong.) Usually, the 48bits address will be devided as this
> > > in a system. And there is no 48-bits type at all. So we need to define
> > two parts for it: 32b LSB follows 16b MSB.
> > > u32 after u16 should be with packed attribute. Thanks
> > 
> > What about using a bitfield into a uint64_t ? I mean:
> > 
> > struct rte_ecpri_msg_rm_access {
> > if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
> > ...
> > uint64_t length:16; /**< number of bytes
> > */
> > uint64_t addr:48;   /**< address */
> > #else
> > ...
> > uint64_t addr:48;   /**< address */
> > uint64_t length:16; /**< number of bytes
> > */
> > #endif
> > };
> > 
> 
> Thanks for your suggestion.
> https://stackoverflow.com/questions/10906238/warning-when-using-bitfield-with-unsigned-char
> AFAIK (from this page), bitfields support only support bool and int. uint64_t 
> is some type of "long"
> and most of the compilers should support it. But I am not sure if it is a 
> standard implementation.

The uint8_t[6], as in your v6, is a good idea.


> > >
> > > >
> > > > I wonder if the 'dw0' could be in this definition instead of in
> > > > struct rte_ecpri_msg_hdr?
> > > >
> > > > Something like this:
> > > >
> > > > struct rte_ecpri_common_hdr {
> > > > union {
> > > > uint32_t u32;
> > > > struct {
> > > > ...
> > > > };
> > > > };
> > > > };
> > > >
> > > > I see 2 advantages:
> > > >
> > > > - someone that only uses the common_hdr struct can use the .u32
> > > >   in its software
> > > > - when using it in messages, it looks clearer to me:
> > > > msg.common_hdr.u32 = value;
> > > >   instead of:
> > > > msg.dw0 = value;
> > > >
> > > > What do you think?
> > >
> > > Thanks for the suggestion, this is much better, I will change it.
> > > Indeed, in my original version, no DW(u32) is defined for the header.
> > > After that, I noticed that it would not be easy for the static casting
> > > to a u32 from bitfield(the compiler will complain), and it would not
> > > be clear to swap the endian if the user wants to use this header. I
> > > added this DW(u32) to simplify the usage of this header. But yes, if I
> > > do not add it here, it would be not easy or clear for users who just
> > use this header structure.
> > > I will change it. Is it OK if I use the name "dw0"?
> > 
> > In my opini

Re: [dpdk-dev] [PATCH v6 1/2] rte_flow: add eCPRI key fields to flow API

2020-07-12 Thread Olivier Matz

On Sun, Jul 12, 2020 at 09:35:02PM +0800, Bing Zhao wrote:
> Add a new item "rte_flow_item_ecpri" in order to match eCRPI header.
> 
> eCPRI is a packet based protocol used in the fronthaul interface of
> 5G networks. Header format definition could be found in the
> specification via the link below:
> https://www.gigalight.com/downloads/standards/ecpri-specification.pdf
> 
> eCPRI message can be over Ethernet layer (.1Q supported also) or over
> UDP layer. Message header formats are the same in these two variants.
> 
> Signed-off-by: Bing Zhao 
> Acked-by: Ori Kam 

Acked-by: Olivier Matz 

Thanks!

Re: [dpdk-dev] [PATCH v6 1/2] rte_flow: add eCPRI key fields to flow API

Many thanks for your big help.

BR. Bing

> -Original Message-
> From: Olivier Matz 
> Sent: Sunday, July 12, 2020 10:46 PM
> To: Bing Zhao 
> Cc: Ori Kam ; john.mcnam...@intel.com;
> marko.kovace...@intel.com; Thomas Monjalon
> ; ferruh.yi...@intel.com;
> arybche...@solarflare.com; akhil.go...@nxp.com; dev@dpdk.org;
> wenzhuo...@intel.com; beilei.x...@intel.com;
> bernard.iremon...@intel.com
> Subject: Re: [PATCH v6 1/2] rte_flow: add eCPRI key fields to flow API
> 
> On Sun, Jul 12, 2020 at 09:35:02PM +0800, Bing Zhao wrote:
> > Add a new item "rte_flow_item_ecpri" in order to match eCRPI
> header.
> >
> > eCPRI is a packet based protocol used in the fronthaul interface of 5G
> > networks. Header format definition could be found in the
> specification
> > via the link below:
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.
> > gigalight.com%2Fdownloads%2Fstandards%2Fecpri-
> specification.pdf&da
> >
> ta=02%7C01%7Cbingz%40mellanox.com%7C5ffe8275a9594dfc6d9f08d
> 826724506%7
> >
> Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C1%7C6373016195227
> 27143&sda
> >
> ta=%2BdY5DigE0mMLu7dOVl3OqPrVvquDLCKTtWI3M%2BSfK3A%3D&
> amp;reserved=0
> >
> > eCPRI message can be over Ethernet layer (.1Q supported also) or
> over
> > UDP layer. Message header formats are the same in these two
> variants.
> >
> > Signed-off-by: Bing Zhao 
> > Acked-by: Ori Kam 
> 
> Acked-by: Olivier Matz 
> 
> Thanks!

Re: [dpdk-dev] [RFC] - Offloading tunnel ports

2020-07-12 Thread William Tu

Hi Oz,

I started to learn about this and have a couple of questions below.
Thank you in advance.

On Tue, Jun 9, 2020 at 8:07 AM Oz Shlomo  wrote:
>
> Rte_flow API provides the building blocks for vendor agnostic flow
> classification offloads.  The rte_flow match and action primitives are fine
> grained, thus enabling DPDK applications the flexibility to offload network
> stacks and complex pipelines.
>
> Applications wishing to offload complex data structures (e.g. tunnel virtual
> ports) are required to use the rte_flow primitives, such as group, meta, mark,
> tag and others to model their high level objects.
>
> The hardware model design for high level software objects is not trivial.
> Furthermore, an optimal design is often vendor specific.
>
> The goal of this RFC is to provide applications with the hardware offload
> model for common high level software objects which is optimal in regards
> to the underlying hardware.
>
> Tunnel ports are the first of such objects.
>
> Tunnel ports
> 
> Ingress processing of tunneled traffic requires the classification
> of the tunnel type followed by a decap action.
>
> In software, once a packet is decapsulated the in_port field is changed
> to a virtual port representing the tunnel type. The outer header fields
> are stored as packet metadata members and may be matched by proceeding
> flows.
>
> Openvswitch, for example, uses two flows:
> 1. classification flow - setting the virtual port representing the tunnel type
> For example: match on udp port 4789 actions=tnl_pop(vxlan_vport)
> 2. steering flow according to outer and inner header matches
> match on in_port=vxlan_vport and outer/inner header matches actions=forward 
> to port X
> The benefits of multi-flow tables are described in [1].
>
> Offloading tunnel ports
> ---
> Tunnel ports introduce a new stateless field that can be matched on.
> Currently the rte_flow library provides an API to encap, decap and match
> on tunnel headers. However, there is no rte_flow primitive to set and
> match tunnel virtual ports.
>
> There are several possible hardware models for offloading virtual tunnel port
> flows including, but not limited to, the following:
> 1. Setting the virtual port on a hw register using the rte_flow_action_mark/
> rte_flow_action_tag/rte_flow_set_meta objects.
> 2. Mapping a virtual port to an rte_flow group
> 3. Avoiding the need to match on transient objects by merging multi-table
> flows to a single rte_flow rule.
>
> Every approach has its pros and cons.
> The preferred approach should take into account the entire system architecture
> and is very often vendor specific.

Are these three solutions mutually exclusive?
And IIUC, based on the description below, you're proposing solution 1, right?
and the patch on OVS is using solution 2?
https://patchwork.ozlabs.org/project/openvswitch/cover/20200120150830.16262-1-el...@mellanox.com/

>
> The proposed rte_flow_tunnel_port_set helper function (drafted below) is 
> designed
> to provide a common, vendor agnostic, API for setting the virtual port value.
> The helper API enables PMD implementations to return vendor specific 
> combination of
> rte_flow actions realizing the vendor's hardware model for setting a tunnel 
> port.
> Applications may append the list of actions returned from the helper function 
> when
> creating an rte_flow rule in hardware.
>
> Similarly, the rte_flow_tunnel_port_match helper (drafted below) allows for
> multiple hardware implementations to return a list of fte_flow items.
>
And if we're using solution 1 "Setting the virtual port on a hw
register using the rte_flow_action_mark/
rte_flow_action_tag/rte_flow_set_meta objects."
For the classification flow, does that mean HW no longer needs to
translate tnl_pop to mark + jump,
but the HW can directly execute the tnl_pop(vxlan_vport) action
because the outer header is
saved using rte_flow_set_meta?

> Miss handling
> -
> Packets going through multiple rte_flow groups are exposed to hw misses due to
> partial packet processing. In such cases, the software should continue the
> packet's processing from the point where the hardware missed.
>
> We propose a generic rte_flow_restore structure providing the state that was
> stored in hardware when the packet missed.
>
> Currently, the structure will provide the tunnel state of the packet that
> missed, namely:
> 1. The group id that missed
> 2. The tunnel port that missed
> 3. Tunnel information that was stored in memory (due to decap action).
> In the future, we may add additional fields as more state may be stored in
> the device memory (e.g. ct_state).
>
> Applications may query the state via a new rte_flow_get_restore_info(mbuf) 
> API,
> thus allowing a vendor specific implementation.
>

Thanks
William

Re: [dpdk-dev] [PATCH v8 02/24] ethdev: add a link status text representation

2020-07-12 Thread Stephen Hemminger

On Sun, 12 Jul 2020 09:35:23 +0200
Thomas Monjalon  wrote:

> 11/07/2020 20:58, Ivan Dyukov:
> > 11.07.2020 14:27, Thomas Monjalon пишет:  
> > > 11/07/2020 12:43, Ivan Dyukov:  
> > >> +__rte_experimental
> > >> +int rte_eth_link_printf(const char *const fmt,
> > >> +   const struct rte_eth_link *eth_link);
> > >>  
> > > Maybe I missed your reply,
> > > I still don't understand the need for this function.
> > >  
> > I used it few times in apps in this patchset.  It allows to avoid code 
> > duplication in examples. i.e. declare array, call rte_eth_link_to_str, 
> > call printf.
> > 
> > It's simple and usefull function.  Why not?  
> 
> Why not is not a good justification :)
> We must avoid adding too much in the API.
> 
> 

I agree with Thomas, this whole exercise seems like a lot of effort for
a log message that probably should be debug only.

The DPDK should adopt the policy that all core and drivers print
no log messages by default, and only log at NOTICE or  higher in case
of error.

Re: [dpdk-dev] [PATCH v8 02/24] ethdev: add a link status text representation

2020-07-12 Thread Ivan Dyukov

12.07.2020 10:35, Thomas Monjalon пишет:
> 11/07/2020 20:58, Ivan Dyukov:
>> 11.07.2020 14:27, Thomas Monjalon пишет:
>>> 11/07/2020 12:43, Ivan Dyukov:
 +__rte_experimental
 +int rte_eth_link_printf(const char *const fmt,
 +   const struct rte_eth_link *eth_link);

>>> Maybe I missed your reply,
>>> I still don't understand the need for this function.
>>>
>> I used it few times in apps in this patchset.  It allows to avoid code
>> duplication in examples. i.e. declare array, call rte_eth_link_to_str,
>> call printf.
>>
>> It's simple and usefull function.  Why not?
> Why not is not a good justification :)
I still don't understand your objections against this tiny shiny function.
> We must avoid adding too much in the API.
>
>
I agree that this function is superfluous for DPDK library, but I would 
note that it's not just 'DPDK library' change, it's 'DPDK library + DPDK 
examples' change. With this change, the entire code is getting better. 
The new function adds usefull functionality. It allows to reduce code 
size and remove duplicates. so technically it's good change but 
practically I would like to ask maintainers to decide this.


P.S.

I'll we on vacation next two weeks. May be I'll check email but I don't 
guarantee that.

[dpdk-dev] [PATCH v2 02/20] regex/mlx5: add log utils

From: Yuval Avnery 

Add the DRV_LOG macro which should be used for error prints.

Signed-off-by: Yuval Avnery 
Acked-by: Ori Kam 

---
 drivers/regex/mlx5/Makefile   |  1 +
 drivers/regex/mlx5/mlx5_regex.c   |  4 
 drivers/regex/mlx5/mlx5_regex_utils.h | 19 +++
 3 files changed, 24 insertions(+)
 create mode 100644 drivers/regex/mlx5/mlx5_regex_utils.h

diff --git a/drivers/regex/mlx5/Makefile b/drivers/regex/mlx5/Makefile
index 1a16ab2..f495659 100644
--- a/drivers/regex/mlx5/Makefile
+++ b/drivers/regex/mlx5/Makefile
@@ -15,6 +15,7 @@ CFLAGS += -std=c11 -Wall -Wextra
 CFLAGS += -g
 CFLAGS += -I$(RTE_SDK)/drivers/common/mlx5
 CFLAGS += -I$(BUILDDIR)/drivers/common/mlx5
+CFLAGS += -I$(RTE_SDK)/drivers/common/mlx5/linux
 CFLAGS += -D_BSD_SOURCE
 CFLAGS += -D_DEFAULT_SOURCE
 CFLAGS += -D_XOPEN_SOURCE=600
diff --git a/drivers/regex/mlx5/mlx5_regex.c b/drivers/regex/mlx5/mlx5_regex.c
index b942a75..06826a6 100644
--- a/drivers/regex/mlx5/mlx5_regex.c
+++ b/drivers/regex/mlx5/mlx5_regex.c
@@ -3,3 +3,7 @@
  */
 
 #include "mlx5_regex.h"
+#include "mlx5_regex_utils.h"
+
+int mlx5_regex_logtype;
+
diff --git a/drivers/regex/mlx5/mlx5_regex_utils.h 
b/drivers/regex/mlx5/mlx5_regex_utils.h
new file mode 100644
index 000..adca846
--- /dev/null
+++ b/drivers/regex/mlx5/mlx5_regex_utils.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2020 Mellanox Technologies, Ltd
+ */
+
+#ifndef RTE_PMD_MLX5_REGEX_UTILS_H_
+#define RTE_PMD_MLX5_REGEX_UTILS_H_
+
+#include 
+
+extern int mlx5_regex_logtype;
+
+#define MLX5_REGEX_LOG_PREFIX "regex_mlx5"
+/* Generic printf()-like logging macro with automatic line feed. */
+#define DRV_LOG(level, ...) \
+   PMD_DRV_LOG_(level, mlx5_regex_logtype, MLX5_REGEX_LOG_PREFIX, \
+   __VA_ARGS__ PMD_DRV_LOG_STRIP PMD_DRV_LOG_OPAREN, \
+   PMD_DRV_LOG_CPAREN)
+
+#endif /* RTE_PMD_MLX5_REGEX_UTILS_H_ */
-- 
1.8.3.1

[dpdk-dev] [PATCH v2 01/20] regex/mlx5: add RegEx PMD layer and mlx5 driver

From: Yuval Avnery 

This commit introduce the RegEx poll mode drivers class, and
adds Mellanox RegEx PMD.

Signed-off-by: Yuval Avnery 
Signed-off-by: Ori Kam 
---
v2:
* Add documantion.

---
 MAINTAINERS   |  12 +++
 config/common_base|   5 +
 doc/guides/index.rst  |   1 +
 doc/guides/regexdevs/features/default.ini |  17 
 doc/guides/regexdevs/features/mlx5.ini|  10 ++
 doc/guides/regexdevs/features_overview.rst| 118 ++
 doc/guides/regexdevs/index.rst|  15 +++
 doc/guides/regexdevs/mlx5.rst |  95 +
 doc/guides/regexdevs/overview_feature_table.txt   | 105 +++
 doc/guides/rel_notes/release_20_08.rst|   5 +
 drivers/Makefile  |   2 +
 drivers/common/Makefile   |   2 +-
 drivers/common/mlx5/Makefile  |   4 +-
 drivers/meson.build   |   3 +-
 drivers/regex/Makefile|   8 ++
 drivers/regex/meson.build |   9 ++
 drivers/regex/mlx5/Makefile   |  34 +++
 drivers/regex/mlx5/meson.build|  32 ++
 drivers/regex/mlx5/mlx5_regex.c   |   5 +
 drivers/regex/mlx5/mlx5_regex.h   |   8 ++
 drivers/regex/mlx5/rte_pmd_mlx5_regex_version.map |   3 +
 mk/rte.app.mk |   5 +-
 22 files changed, 492 insertions(+), 6 deletions(-)
 create mode 100644 doc/guides/regexdevs/features/default.ini
 create mode 100644 doc/guides/regexdevs/features/mlx5.ini
 create mode 100644 doc/guides/regexdevs/features_overview.rst
 create mode 100644 doc/guides/regexdevs/index.rst
 create mode 100644 doc/guides/regexdevs/mlx5.rst
 create mode 100644 doc/guides/regexdevs/overview_feature_table.txt
 create mode 100644 drivers/regex/Makefile
 create mode 100644 drivers/regex/meson.build
 create mode 100644 drivers/regex/mlx5/Makefile
 create mode 100644 drivers/regex/mlx5/meson.build
 create mode 100644 drivers/regex/mlx5/mlx5_regex.c
 create mode 100644 drivers/regex/mlx5/mlx5_regex.h
 create mode 100644 drivers/regex/mlx5/rte_pmd_mlx5_regex_version.map

diff --git a/MAINTAINERS b/MAINTAINERS
index 3cd402b..272359f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -453,7 +453,9 @@ F: doc/guides/compressdevs/features/default.ini
 RegEx API - EXPERIMENTAL
 M: Ori Kam 
 F: lib/librte_regexdev/
+F: drivers/regex/
 F: doc/guides/prog_guide/regexdev.rst
+F: doc/guides/regexdevs/features/default.ini
 
 Eventdev API
 M: Jerin Jacob 
@@ -1128,6 +1130,16 @@ F: doc/guides/compressdevs/zlib.rst
 F: doc/guides/compressdevs/features/zlib.ini
 
 
+RegEx Drivers
+--
+
+Mellanox MLX5
+M: Ori Kam 
+F: drivers/regex/mlx5/
+F: doc/guides/regexdevs/mlx5.rst
+F: doc/guides/regexdevs/features/mlx5.ini
+
+
 vDPA Drivers
 
 T: git://dpdk.org/next/dpdk-next-virtio
diff --git a/config/common_base b/config/common_base
index f7a8824..f76585f 100644
--- a/config/common_base
+++ b/config/common_base
@@ -375,6 +375,11 @@ CONFIG_RTE_LIBRTE_MLX5_PMD=n
 CONFIG_RTE_LIBRTE_MLX5_DEBUG=n
 
 #
+# Compile regex-oriented Mellanox PMD
+#
+CONFIG_RTE_LIBRTE_MLX5_REGEX_PMD=n
+
+#
 # Compile vdpa-oriented Mellanox ConnectX-6 & BlueField (MLX5) PMD
 #
 CONFIG_RTE_LIBRTE_MLX5_VDPA_PMD=n
diff --git a/doc/guides/index.rst b/doc/guides/index.rst
index 988c6ea..857f036 100644
--- a/doc/guides/index.rst
+++ b/doc/guides/index.rst
@@ -20,6 +20,7 @@ DPDK documentation
cryptodevs/index
compressdevs/index
vdpadevs/index
+   regexdevs/index
eventdevs/index
rawdevs/index
mempool/index
diff --git a/doc/guides/regexdevs/features/default.ini 
b/doc/guides/regexdevs/features/default.ini
new file mode 100644
index 000..4d284dd
--- /dev/null
+++ b/doc/guides/regexdevs/features/default.ini
@@ -0,0 +1,17 @@
+;
+; Features of a default RegEx driver.
+;
+; This file defines the features that are valid for inclusion in
+; the other driver files and also the order that they appear in
+; the features table in the documentation. The feature description
+; string should not exceed feature_str_len defined in conf.py.
+;
+[Features]
+ARMv7=
+ARMv8=
+Power8   =
+x86-32   =
+x86-64   =
+Usage doc=
+Design doc   =
+Perf doc =
diff --git a/doc/guides/regexdevs/features/mlx5.ini 
b/doc/guides/regexdevs/features/mlx5.ini
new file mode 100644
index 000..fa03d79
--- /dev/null
+++ b/doc/guides/regexdevs/features/mlx5.ini
@@ -0,0 +1,10 @@
+;
+; Supported features of the 'mlx5' RegEx driver.
+;
+; Refer to default.ini for the full list of available driver features.
+;
+[Features]
+ARMv8= Y
+x86-32   = Y
+x86-64   = Y
+
diff --git a/doc/guides/regexdevs/f

[dpdk-dev] [PATCH v2 04/20] common/mlx5: add mlx5 regex command structs

From: Yuval Avnery 

Add regex commands structs to support regex.

Signed-off-by: Yuval Avnery 
Acked-by: Viacheslav Ovsiienko 

---
 drivers/common/mlx5/mlx5_prm.h | 89 +-
 1 file changed, 88 insertions(+), 1 deletion(-)

diff --git a/drivers/common/mlx5/mlx5_prm.h b/drivers/common/mlx5/mlx5_prm.h
index c2b9a20..ede7810 100644
--- a/drivers/common/mlx5/mlx5_prm.h
+++ b/drivers/common/mlx5/mlx5_prm.h
@@ -795,7 +795,7 @@ enum {
MLX5_CMD_OP_CREATE_GENERAL_OBJECT = 0xa00,
MLX5_CMD_OP_MODIFY_GENERAL_OBJECT = 0xa01,
MLX5_CMD_OP_QUERY_GENERAL_OBJECT = 0xa02,
-   MLX5_CMD_SET_REGEX_PARAM = 0xb04,
+   MLX5_CMD_SET_REGEX_PARAMS = 0xb04,
MLX5_CMD_QUERY_REGEX_PARAMS = 0xb05,
MLX5_CMD_SET_REGEX_REGISTERS = 0xb06,
MLX5_CMD_QUERY_REGEX_REGISTERS = 0xb07,
@@ -2526,6 +2526,93 @@ struct mlx5_ifc_query_qp_in_bits {
u8 reserved_at_60[0x20];
 };
 
+struct regexp_params_field_select_bits {
+   u8 reserved_at_0[0x1e];
+   u8 stop_engine[0x1];
+   u8 db_umem_id[0x1];
+};
+
+struct mlx5_ifc_regexp_params_bits {
+   u8 reserved_at_0[0x1f];
+   u8 stop_engine[0x1];
+   u8 db_umem_id[0x20];
+   u8 db_umem_offset[0x40];
+   u8 reserved_at_80[0x100];
+};
+
+struct mlx5_ifc_set_regexp_params_in_bits {
+   u8 opcode[0x10];
+   u8 uid[0x10];
+   u8 reserved_at_20[0x10];
+   u8 op_mod[0x10];
+   u8 reserved_at_40[0x18];
+   u8 engine_id[0x8];
+   struct regexp_params_field_select_bits field_select;
+   struct mlx5_ifc_regexp_params_bits regexp_params;
+};
+
+struct mlx5_ifc_set_regexp_params_out_bits {
+   u8 status[0x8];
+   u8 reserved_at_8[0x18];
+   u8 syndrome[0x20];
+   u8 reserved_at_18[0x40];
+};
+
+struct mlx5_ifc_query_regexp_params_in_bits {
+   u8 opcode[0x10];
+   u8 uid[0x10];
+   u8 reserved_at_20[0x10];
+   u8 op_mod[0x10];
+   u8 reserved_at_40[0x18];
+   u8 engine_id[0x8];
+   u8 reserved[0x20];
+};
+
+struct mlx5_ifc_query_regexp_params_out_bits {
+   u8 status[0x8];
+   u8 reserved_at_8[0x18];
+   u8 syndrome[0x20];
+   u8 reserved[0x40];
+   struct mlx5_ifc_regexp_params_bits regexp_params;
+};
+
+struct mlx5_ifc_set_regexp_register_in_bits {
+   u8 opcode[0x10];
+   u8 uid[0x10];
+   u8 reserved_at_20[0x10];
+   u8 op_mod[0x10];
+   u8 reserved_at_40[0x18];
+   u8 engine_id[0x8];
+   u8 register_address[0x20];
+   u8 register_data[0x20];
+   u8 reserved[0x40];
+};
+
+struct mlx5_ifc_set_regexp_register_out_bits {
+   u8 status[0x8];
+   u8 reserved_at_8[0x18];
+   u8 syndrome[0x20];
+   u8 reserved[0x40];
+};
+
+struct mlx5_ifc_query_regexp_register_in_bits {
+   u8 opcode[0x10];
+   u8 uid[0x10];
+   u8 reserved_at_20[0x10];
+   u8 op_mod[0x10];
+   u8 reserved_at_40[0x18];
+   u8 engine_id[0x8];
+   u8 register_address[0x20];
+};
+
+struct mlx5_ifc_query_regexp_register_out_bits {
+   u8 status[0x8];
+   u8 reserved_at_8[0x18];
+   u8 syndrome[0x20];
+   u8 reserved[0x20];
+   u8 register_data[0x20];
+};
+
 /* CQE format mask. */
 #define MLX5E_CQE_FORMAT_MASK 0xc
 
-- 
1.8.3.1

[dpdk-dev] [PATCH v2 00/20] add Mellanox RegEx PMD



This patch series introduce the Mellanox BF2 RegEx PMD.

Mellanox BF2 RegEx PMD implement the API defined in the
regexdev lib [1].

This PMD allows a DPDK application to offload the RegEx functionality
to Mellanox BF2 RegEx engine.


[1] https://patches.dpdk.org/cover/72792/


v2:
* Rebase.
* Add release notes.

Francis Kelly (1):
  regex/mlx5: add program rules support

Ori Kam (9):
  regex/mlx5: add probe function
  common/mlx5: add rxp database set cmd
  common/mlx5: add write and read RXP registers
  regex/mlx5: add engine status check
  regex/mlx5: add get info function
  regex/mlx5: add configure function
  regex/mlx5: add completion queue creation
  regex/mlx5: add send queue support
  regex/mlx5: add start stop functions

Parav Pandit (1):
  regex/mlx5: add RXP register definitions

Yuval Avnery (9):
  regex/mlx5: add RegEx PMD layer and mlx5 driver
  regex/mlx5: add log utils
  common/mlx5: add MMO and regexp structs/opcodes
  common/mlx5: add mlx5 regex command structs
  common/mlx5: add support for regex capability query
  common/mlx5: add match tuple hw layout
  regex/mlx5: fastpath setup
  regex/mlx5: add enqueue implementation
  regex/mlx5: implement dequeue function

 MAINTAINERS   |   12 +
 config/common_base|5 +
 doc/guides/index.rst  |1 +
 doc/guides/regexdevs/features/default.ini |   17 +
 doc/guides/regexdevs/features/mlx5.ini|   10 +
 doc/guides/regexdevs/features_overview.rst|  118 ++
 doc/guides/regexdevs/index.rst|   15 +
 doc/guides/regexdevs/mlx5.rst |   95 ++
 doc/guides/regexdevs/overview_feature_table.txt   |  105 ++
 doc/guides/rel_notes/release_20_08.rst|5 +
 drivers/Makefile  |2 +
 drivers/common/Makefile   |2 +-
 drivers/common/mlx5/Makefile  |4 +-
 drivers/common/mlx5/mlx5_devx_cmds.c  |  185 +++
 drivers/common/mlx5/mlx5_devx_cmds.h  |   20 +-
 drivers/common/mlx5/mlx5_prm.h|  142 ++-
 drivers/common/mlx5/rte_common_mlx5_version.map   |5 +
 drivers/meson.build   |3 +-
 drivers/regex/Makefile|8 +
 drivers/regex/meson.build |9 +
 drivers/regex/mlx5/Makefile   |   41 +
 drivers/regex/mlx5/meson.build|   35 +
 drivers/regex/mlx5/mlx5_regex.c   |  314 ++
 drivers/regex/mlx5/mlx5_regex.h   |  110 ++
 drivers/regex/mlx5/mlx5_regex_control.c   |  368 ++
 drivers/regex/mlx5/mlx5_regex_fastpath.c  |  434 
 drivers/regex/mlx5/mlx5_regex_utils.h |   19 +
 drivers/regex/mlx5/mlx5_rxp.c | 1236 +
 drivers/regex/mlx5/mlx5_rxp.h |  138 +++
 drivers/regex/mlx5/mlx5_rxp_csrs.h|  338 ++
 drivers/regex/mlx5/rte_pmd_mlx5_regex_version.map |3 +
 mk/rte.app.mk |6 +-
 32 files changed, 3796 insertions(+), 9 deletions(-)
 create mode 100644 doc/guides/regexdevs/features/default.ini
 create mode 100644 doc/guides/regexdevs/features/mlx5.ini
 create mode 100644 doc/guides/regexdevs/features_overview.rst
 create mode 100644 doc/guides/regexdevs/index.rst
 create mode 100644 doc/guides/regexdevs/mlx5.rst
 create mode 100644 doc/guides/regexdevs/overview_feature_table.txt
 create mode 100644 drivers/regex/Makefile
 create mode 100644 drivers/regex/meson.build
 create mode 100644 drivers/regex/mlx5/Makefile
 create mode 100644 drivers/regex/mlx5/meson.build
 create mode 100644 drivers/regex/mlx5/mlx5_regex.c
 create mode 100644 drivers/regex/mlx5/mlx5_regex.h
 create mode 100644 drivers/regex/mlx5/mlx5_regex_control.c
 create mode 100644 drivers/regex/mlx5/mlx5_regex_fastpath.c
 create mode 100644 drivers/regex/mlx5/mlx5_regex_utils.h
 create mode 100644 drivers/regex/mlx5/mlx5_rxp.c
 create mode 100644 drivers/regex/mlx5/mlx5_rxp.h
 create mode 100644 drivers/regex/mlx5/mlx5_rxp_csrs.h
 create mode 100644 drivers/regex/mlx5/rte_pmd_mlx5_regex_version.map

-- 
1.8.3.1

[dpdk-dev] [PATCH v2 03/20] common/mlx5: add MMO and regexp structs/opcodes

From: Yuval Avnery 

Added General purpose PRM MMO structs, and regex specific structs.

Signed-off-by: Yuval Avnery 
Signed-off-by: Ori Kam 
---
 drivers/common/mlx5/mlx5_prm.h | 40 
 1 file changed, 40 insertions(+)

diff --git a/drivers/common/mlx5/mlx5_prm.h b/drivers/common/mlx5/mlx5_prm.h
index c63795f..c2b9a20 100644
--- a/drivers/common/mlx5/mlx5_prm.h
+++ b/drivers/common/mlx5/mlx5_prm.h
@@ -373,6 +373,42 @@ struct mlx5_cqe {
uint8_t op_own;
 };
 
+/* MMO metadata segment */
+
+#defineMLX5_OPCODE_MMO 0x2f
+#defineMLX5_OPC_MOD_MMO_REGEX 0x4
+
+struct mlx5_wqe_metadata_seg {
+   uint32_t mmo_control_31_0; /* mmo_control_63_32 is in ctrl_seg.imm */
+   uint32_t lkey;
+   uint64_t addr;
+};
+
+struct mlx5_ifc_regexp_mmo_control_bits {
+   uint8_t reserved_at_31[0x2];
+   uint8_t le[0x1];
+   uint8_t reserved_at_28[0x1];
+   uint8_t subset_id_0[0xc];
+   uint8_t reserved_at_16[0x4];
+   uint8_t subset_id_1[0xc];
+   uint8_t ctrl[0x4];
+   uint8_t subset_id_2[0xc];
+   uint8_t reserved_at_16_1[0x4];
+   uint8_t subset_id_3[0xc];
+};
+
+struct mlx5_ifc_regexp_metadata_bits {
+   uint8_t rof_version[0x10];
+   uint8_t latency_count[0x10];
+   uint8_t instruction_count[0x10];
+   uint8_t primary_thread_count[0x10];
+   uint8_t match_count[0x8];
+   uint8_t detected_match_count[0x8];
+   uint8_t status[0x10];
+   uint8_t job_id[0x20];
+   uint8_t reserved[0x80];
+};
+
 /* Adding direct verbs to data-path. */
 
 /* CQ sequence number mask. */
@@ -759,6 +795,10 @@ enum {
MLX5_CMD_OP_CREATE_GENERAL_OBJECT = 0xa00,
MLX5_CMD_OP_MODIFY_GENERAL_OBJECT = 0xa01,
MLX5_CMD_OP_QUERY_GENERAL_OBJECT = 0xa02,
+   MLX5_CMD_SET_REGEX_PARAM = 0xb04,
+   MLX5_CMD_QUERY_REGEX_PARAMS = 0xb05,
+   MLX5_CMD_SET_REGEX_REGISTERS = 0xb06,
+   MLX5_CMD_QUERY_REGEX_REGISTERS = 0xb07,
 };
 
 enum {
-- 
1.8.3.1

[dpdk-dev] [PATCH v2 08/20] regex/mlx5: add RXP register definitions

From: Parav Pandit 

This commit indroduce the mlx5_rxp_csrs.h file. This file holds all the
relevant defines for the RXP engine.

Signed-off-by: Parav Pandit 
Signed-off-by: Ori Kam 
---
 drivers/regex/mlx5/mlx5_rxp_csrs.h | 338 +
 1 file changed, 338 insertions(+)
 create mode 100644 drivers/regex/mlx5/mlx5_rxp_csrs.h

diff --git a/drivers/regex/mlx5/mlx5_rxp_csrs.h 
b/drivers/regex/mlx5/mlx5_rxp_csrs.h
new file mode 100644
index 000..bab2946
--- /dev/null
+++ b/drivers/regex/mlx5/mlx5_rxp_csrs.h
@@ -0,0 +1,338 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2020 Mellanox Technologies, Ltd
+ */
+#ifndef _MLX5_RXP_CSRS_H_
+#define _MLX5_RXP_CSRS_H_
+
+/*
+ * Common to all RXP implementations
+ */
+#define MLX5_RXP_CSR_BASE_ADDRESS 0xul
+#define MLX5_RXP_RTRU_CSR_BASE_ADDRESS 0x0100ul
+#define MLX5_RXP_STATS_CSR_BASE_ADDRESS0x0200ul
+#define MLX5_RXP_ROYALTY_CSR_BASE_ADDRESS 0x0600ul
+
+#define MLX5_RXP_CSR_WIDTH 4
+
+/* This is the identifier we expect to see in the first RXP CSR */
+#define MLX5_RXP_IDENTIFER 0x5254
+
+/* Hyperion specific BAR0 offsets */
+#define MLX5_RXP_FPGA_BASE_ADDRESS 0xul
+#define MLX5_RXP_PCIE_BASE_ADDRESS 0x1000ul
+#define MLX5_RXP_IDMA_BASE_ADDRESS 0x2000ul
+#define MLX5_RXP_EDMA_BASE_ADDRESS 0x3000ul
+#define MLX5_RXP_SYSMON_BASE_ADDRESS 0xf300ul
+#define MLX5_RXP_ISP_CSR_BASE_ADDRESS 0xf400ul
+
+/* Offset to the RXP common 4K CSR space */
+#define MLX5_RXP_PCIE_CSR_BASE_ADDRESS 0xf000ul
+
+/* FPGA CSRs */
+
+#define MLX5_RXP_FPGA_VERSION (MLX5_RXP_FPGA_BASE_ADDRESS + \
+  MLX5_RXP_CSR_WIDTH * 0)
+
+/* PCIe CSRs */
+#define MLX5_RXP_PCIE_INIT_ISR (MLX5_RXP_PCIE_BASE_ADDRESS + \
+   MLX5_RXP_CSR_WIDTH * 0)
+#define MLX5_RXP_PCIE_INIT_IMR (MLX5_RXP_PCIE_BASE_ADDRESS + \
+   MLX5_RXP_CSR_WIDTH * 1)
+#define MLX5_RXP_PCIE_INIT_CFG_STAT (MLX5_RXP_PCIE_BASE_ADDRESS + \
+MLX5_RXP_CSR_WIDTH * 2)
+#define MLX5_RXP_PCIE_INIT_FLR (MLX5_RXP_PCIE_BASE_ADDRESS + \
+   MLX5_RXP_CSR_WIDTH * 3)
+#define MLX5_RXP_PCIE_INIT_CTRL(MLX5_RXP_PCIE_BASE_ADDRESS + \
+MLX5_RXP_CSR_WIDTH * 4)
+
+/* IDMA CSRs */
+#define MLX5_RXP_IDMA_ISR (MLX5_RXP_IDMA_BASE_ADDRESS + MLX5_RXP_CSR_WIDTH * 0)
+#define MLX5_RXP_IDMA_IMR (MLX5_RXP_IDMA_BASE_ADDRESS + MLX5_RXP_CSR_WIDTH * 1)
+#define MLX5_RXP_IDMA_CSR (MLX5_RXP_IDMA_BASE_ADDRESS + MLX5_RXP_CSR_WIDTH * 4)
+#define MLX5_RXP_IDMA_CSR_RST_MSK 0x0001
+#define MLX5_RXP_IDMA_CSR_PDONE_MSK 0x0002
+#define MLX5_RXP_IDMA_CSR_INIT_MSK 0x0004
+#define MLX5_RXP_IDMA_CSR_EN_MSK 0x0008
+#define MLX5_RXP_IDMA_QCR (MLX5_RXP_IDMA_BASE_ADDRESS + MLX5_RXP_CSR_WIDTH * 5)
+#define MLX5_RXP_IDMA_QCR_QAVAIL_MSK 0x00FF
+#define MLX5_RXP_IDMA_QCR_QEN_MSK 0xFF00
+#define MLX5_RXP_IDMA_DCR (MLX5_RXP_IDMA_BASE_ADDRESS + MLX5_RXP_CSR_WIDTH * 6)
+#define MLX5_RXP_IDMA_DWCTR (MLX5_RXP_IDMA_BASE_ADDRESS + \
+MLX5_RXP_CSR_WIDTH * 7)
+#define MLX5_RXP_IDMA_DWTOR (MLX5_RXP_IDMA_BASE_ADDRESS + \
+MLX5_RXP_CSR_WIDTH * 8)
+#define MLX5_RXP_IDMA_PADCR (MLX5_RXP_IDMA_BASE_ADDRESS + \
+MLX5_RXP_CSR_WIDTH * 9)
+#define MLX5_RXP_IDMA_DFCR (MLX5_RXP_IDMA_BASE_ADDRESS + \
+   MLX5_RXP_CSR_WIDTH * 10)
+#define MLX5_RXP_IDMA_FOFLR0 (MLX5_RXP_IDMA_BASE_ADDRESS + \
+ MLX5_RXP_CSR_WIDTH * 16)
+#define MLX5_RXP_IDMA_FOFLR1 (MLX5_RXP_IDMA_BASE_ADDRESS + \
+ MLX5_RXP_CSR_WIDTH * 17)
+#define MLX5_RXP_IDMA_FOFLR2 (MLX5_RXP_IDMA_BASE_ADDRESS + \
+ MLX5_RXP_CSR_WIDTH * 18)
+#define MLX5_RXP_IDMA_FUFLR0 (MLX5_RXP_IDMA_BASE_ADDRESS + \
+ MLX5_RXP_CSR_WIDTH * 24)
+#define MLX5_RXP_IDMA_FUFLR1 (MLX5_RXP_IDMA_BASE_ADDRESS + \
+ MLX5_RXP_CSR_WIDTH * 25)
+#define MLX5_RXP_IDMA_FUFLR2 (MLX5_RXP_IDMA_BASE_ADDRESS + \
+ MLX5_RXP_CSR_WIDTH * 26)
+
+#define MLX5_RXP_IDMA_QCSR_BASE(MLX5_RXP_IDMA_BASE_ADDRESS + \
+MLX5_RXP_CSR_WIDTH * 128)
+#define MLX5_RXP_IDMA_QCSR_RST_MSK 0x0001
+#define MLX5_RXP_IDMA_QCSR_PDONE_MSK 0x0002
+#define MLX5_RXP_IDMA_QCSR_INIT_MSK 0x0004
+#define MLX5_RXP_IDMA_QCSR_EN_MSK 0x0008
+#define MLX5_RXP_IDMA_QDPTR_BASE (MLX5_RXP_IDMA_BASE_ADDRESS + \
+ MLX5_RXP_CSR_WIDTH * 192)
+#define MLX5_RXP_IDMA_QTPTR_BASE (MLX5_RXP_IDMA_BASE_ADDRESS + \
+ MLX5_RXP_CSR_WIDTH * 256)
+#define MLX5_RXP_IDMA_QDRPTR_BASE (MLX5_RXP_IDMA_BASE_ADDRESS + \
+  MLX5_RXP_CSR_WIDTH * 320)
+#define MLX5_RXP_IDMA_QDRALR_BASE (MLX5_RXP_IDMA_BASE_ADDRESS + \
+  MLX5_RXP_CSR_WIDTH * 384)
+#define MLX5_RXP_IDMA_QDRAHR_BASE (MLX5_RXP_IDMA_BASE_ADDRES

[dpdk-dev] [PATCH v2 09/20] common/mlx5: add write and read RXP registers

This commits add the write and read RXP registers functionality.

Signed-off-by: Ori Kam 
Acked-by: Viacheslav Ovsiienko 

---
 drivers/common/mlx5/mlx5_devx_cmds.c| 78 +
 drivers/common/mlx5/mlx5_devx_cmds.h| 10 
 drivers/common/mlx5/rte_common_mlx5_version.map |  2 +
 3 files changed, 90 insertions(+)

diff --git a/drivers/common/mlx5/mlx5_devx_cmds.c 
b/drivers/common/mlx5/mlx5_devx_cmds.c
index fe781c7..9094012 100644
--- a/drivers/common/mlx5/mlx5_devx_cmds.c
+++ b/drivers/common/mlx5/mlx5_devx_cmds.c
@@ -1720,3 +1720,81 @@ struct mlx5_devx_obj *
return 0;
 }
 
+/**
+ * Write to RXP registers.
+ *
+ * @param ctx
+ *   ibv device handle
+ * @param engine_id
+ *   Chooses on which engine the register will be written..
+ * @param addr
+ *   Register address.
+ * @param data
+ *   Data to be written to the register.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+int
+mlx5_devx_regex_register_write(struct ibv_context *ctx, int engine_id,
+  uint32_t addr, uint32_t data)
+{
+   uint32_t out[MLX5_ST_SZ_DW(set_regexp_register_out)] = {0};
+   uint32_t in[MLX5_ST_SZ_DW(set_regexp_register_in)] = {0};
+   int ret;
+
+   MLX5_SET(set_regexp_register_in, in, opcode,
+MLX5_CMD_SET_REGEX_REGISTERS);
+   MLX5_SET(set_regexp_register_in, in, engine_id, engine_id);
+   MLX5_SET(set_regexp_register_in, in, register_address, addr);
+   MLX5_SET(set_regexp_register_in, in, register_data, data);
+
+   ret = mlx5_glue->devx_general_cmd(ctx, in, sizeof(in), out,
+ sizeof(out));
+   if (ret) {
+   DRV_LOG(ERR, "Set regexp register failed %d", ret);
+   rte_errno = errno;
+   return -errno;
+   }
+   return 0;
+}
+
+
+/**
+ * Read from RXP registers
+ *
+ * @param ctx
+ *   ibv device handle
+ * @param engine_id
+ *   Chooses from which engine to read.
+ * @param addr
+ *   Register address.
+ * @param data
+ *   Output containing the pointer to the data..
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+int
+mlx5_devx_regex_register_read(struct ibv_context *ctx, int engine_id,
+ uint32_t addr, uint32_t *data)
+{
+   uint32_t out[MLX5_ST_SZ_DW(query_regexp_register_out)] = {0};
+   uint32_t in[MLX5_ST_SZ_DW(query_regexp_register_in)] = {0};
+   int ret;
+
+   MLX5_SET(query_regexp_register_in, in, opcode,
+MLX5_CMD_QUERY_REGEX_REGISTERS);
+   MLX5_SET(query_regexp_register_in, in, engine_id, engine_id);
+   MLX5_SET(query_regexp_register_in, in, register_address, addr);
+
+   ret = mlx5_glue->devx_general_cmd(ctx, in, sizeof(in), out,
+ sizeof(out));
+   if (ret) {
+   DRV_LOG(ERR, "Query regexp register failed %d", ret);
+   rte_errno = errno;
+   return -errno;
+   }
+   *data = MLX5_GET(query_regexp_register_out, out, register_data);
+   return 0;
+}
diff --git a/drivers/common/mlx5/mlx5_devx_cmds.h 
b/drivers/common/mlx5/mlx5_devx_cmds.h
index 655e31f..a2a9045 100644
--- a/drivers/common/mlx5/mlx5_devx_cmds.h
+++ b/drivers/common/mlx5/mlx5_devx_cmds.h
@@ -374,6 +374,10 @@ int mlx5_devx_cmd_modify_qp_state(struct mlx5_devx_obj *qp,
 __rte_internal
 int mlx5_devx_cmd_modify_rqt(struct mlx5_devx_obj *rqt,
 struct mlx5_devx_rqt_attr *rqt_attr);
+int mlx5_devx_regex_register_write(struct ibv_context *ctx, int engine_id,
+  uint32_t addr, uint32_t data);
+int mlx5_devx_regex_register_read(struct ibv_context *ctx, int engine_id,
+ uint32_t addr, uint32_t *data);
 
 /**
  * Create virtio queue counters object DevX API.
@@ -408,4 +412,10 @@ int mlx5_devx_cmd_query_virtio_q_counters(struct 
mlx5_devx_obj *couners_obj,
 __rte_internal
 int mlx5_devx_regex_database_program(void *ctx, uint8_t engine,
 uint32_t umem_id, uint64_t umem_offset);
+__rte_internal
+int mlx5_devx_regex_register_read(struct ibv_context *ctx, int engine_id,
+ uint32_t addr, uint32_t *data);
+__rte_internal
+int mlx5_devx_regex_register_write(struct ibv_context *ctx, int engine_id,
+  uint32_t addr, uint32_t data);
 #endif /* RTE_PMD_MLX5_DEVX_CMDS_H_ */
diff --git a/drivers/common/mlx5/rte_common_mlx5_version.map 
b/drivers/common/mlx5/rte_common_mlx5_version.map
index 6054d39..138719d 100644
--- a/drivers/common/mlx5/rte_common_mlx5_version.map
+++ b/drivers/common/mlx5/rte_common_mlx5_version.map
@@ -38,6 +38,8 @@ INTERNAL {
mlx5_devx_regex_database_program;
mlx5_devx_regex_database_resume;
mlx5_devx_regex_database_stop;
+   mlx5_devx_regex_register_read;
+   mlx

[dpdk-dev] [PATCH v2 10/20] regex/mlx5: add engine status check

This commit checks the engine status.

Signed-off-by: Ori Kam 
---
 drivers/regex/mlx5/mlx5_regex.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/regex/mlx5/mlx5_regex.c b/drivers/regex/mlx5/mlx5_regex.c
index d264ecd..c469a10 100644
--- a/drivers/regex/mlx5/mlx5_regex.c
+++ b/drivers/regex/mlx5/mlx5_regex.c
@@ -17,6 +17,7 @@
 
 #include "mlx5_regex.h"
 #include "mlx5_regex_utils.h"
+#include "mlx5_rxp_csrs.h"
 
 int mlx5_regex_logtype;
 
@@ -49,6 +50,28 @@
mlx5_glue->free_device_list(ibv_list);
return ibv_match;
 }
+static int
+mlx5_regex_engines_status(struct ibv_context *ctx, int num_engines)
+{
+   uint32_t fpga_ident = 0;
+   int err;
+   int i;
+
+   for (i = 0; i < num_engines; i++) {
+   err = mlx5_devx_regex_register_read(ctx, i,
+   MLX5_RXP_CSR_IDENTIFIER,
+   &fpga_ident);
+   fpga_ident = (fpga_ident & (0x));
+   if (err || fpga_ident != MLX5_RXP_IDENTIFER) {
+   DRV_LOG(ERR, "Failed setup RXP %d err %d database "
+   "memory 0x%x", i, err, fpga_ident);
+   if (!err)
+   err = EINVAL;
+   return err;
+   }
+   }
+   return 0;
+}
 
 static void
 mlx5_regex_get_name(char *name, struct rte_pci_device *pci_dev __rte_unused)
@@ -109,6 +132,11 @@
rte_errno = ENOTSUP;
goto error;
}
+   if (mlx5_regex_engines_status(ctx, 2)) {
+   DRV_LOG(ERR, "RegEx engine error.");
+   rte_errno = ENOMEM;
+   goto error;
+   }
priv = rte_zmalloc("mlx5 regex device private", sizeof(*priv),
   RTE_CACHE_LINE_SIZE);
if (!priv) {
-- 
1.8.3.1

[dpdk-dev] [PATCH v2 07/20] common/mlx5: add rxp database set cmd

This commit adds the database set command for the RXP engine.

Signed-off-by: Ori Kam 
Acked-by: Viacheslav Ovsiienko 

---
 drivers/common/mlx5/mlx5_devx_cmds.c| 104 
 drivers/common/mlx5/mlx5_devx_cmds.h|   8 +-
 drivers/common/mlx5/rte_common_mlx5_version.map |   3 +
 3 files changed, 114 insertions(+), 1 deletion(-)

diff --git a/drivers/common/mlx5/mlx5_devx_cmds.c 
b/drivers/common/mlx5/mlx5_devx_cmds.c
index 54b20a7..fe781c7 100644
--- a/drivers/common/mlx5/mlx5_devx_cmds.c
+++ b/drivers/common/mlx5/mlx5_devx_cmds.c
@@ -1616,3 +1616,107 @@ struct mlx5_devx_obj *
invalid_buffer);
return ret;
 }
+
+/**
+ * Issue the RXP stop database command.
+ *
+ * @param[in] ctx
+ *   Context returned from mlx5 open_device() glue function.
+ * @param[in] engine
+ *   The engine to stop.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+int
+mlx5_devx_regex_database_stop(void *ctx, uint8_t engine)
+{
+   uint32_t out[MLX5_ST_SZ_DW(set_regexp_params_out)] = {0};
+   uint32_t in[MLX5_ST_SZ_DW(set_regexp_params_in)] = {0};
+   int ret;
+
+   MLX5_SET(set_regexp_params_in, in, opcode, MLX5_CMD_SET_REGEX_PARAMS);
+   MLX5_SET(set_regexp_params_in, in, engine_id, engine);
+   MLX5_SET(set_regexp_params_in, in, regexp_params.stop_engine, 1);
+   MLX5_SET(set_regexp_params_in, in, field_select.stop_engine, 1);
+   ret = mlx5_glue->devx_general_cmd(ctx, in, sizeof(in), out,
+ sizeof(out));
+   if (ret) {
+   DRV_LOG(ERR, "Database stop failed %d", ret);
+   rte_errno = errno;
+   return -errno;
+   }
+   return 0;
+}
+
+/**
+ * Issue the RXP resume database command.
+ *
+ * @param[in] ctx
+ *   Context returned from mlx5 open_device() glue function.
+ * @param[in] engine
+ *   The engine to start.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+int
+mlx5_devx_regex_database_resume(void *ctx, uint8_t engine)
+{
+   uint32_t out[MLX5_ST_SZ_DW(set_regexp_params_out)] = {0};
+   uint32_t in[MLX5_ST_SZ_DW(set_regexp_params_in)] = {0};
+   int ret;
+
+   MLX5_SET(set_regexp_params_in, in, opcode, MLX5_CMD_SET_REGEX_PARAMS);
+   MLX5_SET(set_regexp_params_in, in, engine_id, engine);
+   MLX5_SET(set_regexp_params_in, in, regexp_params.stop_engine, 0);
+   MLX5_SET(set_regexp_params_in, in, field_select.stop_engine, 1);
+   ret = mlx5_glue->devx_general_cmd(ctx, in, sizeof(in), out,
+ sizeof(out));
+   if (ret) {
+   DRV_LOG(ERR, "Database start failed %d", ret);
+   rte_errno = errno;
+   return -errno;
+   }
+   return 0;
+}
+
+/**
+ * Issue the RXP program database command.
+ *
+ * @param[in] ctx
+ *   Context returned from mlx5 open_device() glue function.
+ * @param[in] engine
+ *   The engine to program.
+ * @param[in] umem_id
+ *   The umem id to use.
+ * @param[in] umem_offset
+ *   The offset in the umem to start copying from.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+int
+mlx5_devx_regex_database_program(void *ctx, uint8_t engine, uint32_t umem_id,
+uint64_t umem_offset)
+{
+   uint32_t out[MLX5_ST_SZ_DW(set_regexp_params_out)] = {0};
+   uint32_t in[MLX5_ST_SZ_DW(set_regexp_params_in)] = {0};
+   int ret;
+
+   MLX5_SET(set_regexp_params_in, in, opcode, MLX5_CMD_SET_REGEX_PARAMS);
+   MLX5_SET(set_regexp_params_in, in, engine_id, engine);
+   MLX5_SET(set_regexp_params_in, in, regexp_params.db_umem_id, umem_id);
+   MLX5_SET64(set_regexp_params_in, in, regexp_params.db_umem_offset,
+  umem_offset);
+   MLX5_SET(set_regexp_params_in, in, field_select.db_umem_id, 1);
+   ret = mlx5_glue->devx_general_cmd(ctx, in, sizeof(in), out,
+ sizeof(out));
+   if (ret) {
+   DRV_LOG(ERR, "Database program failed %d", ret);
+   rte_errno = errno;
+   return -errno;
+   }
+   return 0;
+}
+
diff --git a/drivers/common/mlx5/mlx5_devx_cmds.h 
b/drivers/common/mlx5/mlx5_devx_cmds.h
index bb14ca5..655e31f 100644
--- a/drivers/common/mlx5/mlx5_devx_cmds.h
+++ b/drivers/common/mlx5/mlx5_devx_cmds.h
@@ -401,5 +401,11 @@ int mlx5_devx_cmd_modify_rqt(struct mlx5_devx_obj *rqt,
 __rte_internal
 int mlx5_devx_cmd_query_virtio_q_counters(struct mlx5_devx_obj *couners_obj,
  struct mlx5_devx_virtio_q_couners_attr *attr);
-
+__rte_internal
+int mlx5_devx_regex_database_stop(void *ctx, uint8_t engine);
+__rte_internal
+int mlx5_devx_regex_database_resume(void *ctx, uint8_t engine);
+__rte_internal
+int mlx5_devx_regex_database_program(void *ctx, uint8_t engine,
+

[dpdk-dev] [PATCH v2 05/20] common/mlx5: add support for regex capability query

From: Yuval Avnery 

Update hca cap struct and common query hca cap function.

Signed-off-by: Yuval Avnery 
Acked-by: Viacheslav Ovsiienko 

---
 drivers/common/mlx5/mlx5_devx_cmds.c | 3 +++
 drivers/common/mlx5/mlx5_devx_cmds.h | 2 ++
 drivers/common/mlx5/mlx5_prm.h   | 9 +++--
 3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/common/mlx5/mlx5_devx_cmds.c 
b/drivers/common/mlx5/mlx5_devx_cmds.c
index 2179a83..54b20a7 100644
--- a/drivers/common/mlx5/mlx5_devx_cmds.c
+++ b/drivers/common/mlx5/mlx5_devx_cmds.c
@@ -467,6 +467,9 @@ struct mlx5_devx_obj *
attr->vdpa.queue_counters_valid = !!(MLX5_GET64(cmd_hca_cap, hcattr,
general_obj_types) &
  MLX5_GENERAL_OBJ_TYPES_CAP_VIRTIO_Q_COUNTERS);
+   attr->regex = MLX5_GET(cmd_hca_cap, hcattr, regexp);
+   attr->regexp_num_of_engines = MLX5_GET(cmd_hca_cap, hcattr,
+  regexp_num_of_engines);
if (attr->qos.sup) {
MLX5_SET(query_hca_cap_in, in, op_mod,
 MLX5_GET_HCA_CAP_OP_MOD_QOS_CAP |
diff --git a/drivers/common/mlx5/mlx5_devx_cmds.h 
b/drivers/common/mlx5/mlx5_devx_cmds.h
index 25704ef..bb14ca5 100644
--- a/drivers/common/mlx5/mlx5_devx_cmds.h
+++ b/drivers/common/mlx5/mlx5_devx_cmds.h
@@ -90,6 +90,8 @@ struct mlx5_hca_attr {
uint32_t vhca_id:16;
uint32_t relaxed_ordering_write:1;
uint32_t relaxed_ordering_read:1;
+   uint32_t regex:1;
+   uint32_t regexp_num_of_engines;
struct mlx5_hca_qos_attr qos;
struct mlx5_hca_vdpa_attr vdpa;
 };
diff --git a/drivers/common/mlx5/mlx5_prm.h b/drivers/common/mlx5/mlx5_prm.h
index ede7810..bfbc58b 100644
--- a/drivers/common/mlx5/mlx5_prm.h
+++ b/drivers/common/mlx5/mlx5_prm.h
@@ -1034,9 +1034,14 @@ struct mlx5_ifc_cmd_hca_cap_bits {
u8 log_max_qp_sz[0x8];
u8 reserved_at_90[0xb];
u8 log_max_qp[0x5];
-   u8 reserved_at_a0[0xb];
+   u8 regexp[0x1];
+   u8 reserved_at_a1[0x3];
+   u8 regexp_num_of_engines[0x4];
+   u8 reserved_at_a8[0x3];
u8 log_max_srq[0x5];
-   u8 reserved_at_b0[0x10];
+   u8 reserved_at_b0[0x3];
+   u8 regexp_log_crspace_size[0x5];
+   u8 reserved_at_b8[0x8];
u8 reserved_at_c0[0x8];
u8 log_max_cq_sz[0x8];
u8 reserved_at_d0[0xb];
-- 
1.8.3.1

[dpdk-dev] [PATCH v2 06/20] regex/mlx5: add probe function

This commit adds the probe function to the RegEx PMD.

Signed-off-by: Parav Pandit 
Signed-off-by: Ori Kam 
---
 drivers/regex/mlx5/Makefile |   3 +
 drivers/regex/mlx5/meson.build  |   2 +-
 drivers/regex/mlx5/mlx5_regex.c | 215 
 drivers/regex/mlx5/mlx5_regex.h |   6 ++
 mk/rte.app.mk   |   1 +
 5 files changed, 226 insertions(+), 1 deletion(-)

diff --git a/drivers/regex/mlx5/Makefile b/drivers/regex/mlx5/Makefile
index f495659..3b99570 100644
--- a/drivers/regex/mlx5/Makefile
+++ b/drivers/regex/mlx5/Makefile
@@ -16,6 +16,8 @@ CFLAGS += -g
 CFLAGS += -I$(RTE_SDK)/drivers/common/mlx5
 CFLAGS += -I$(BUILDDIR)/drivers/common/mlx5
 CFLAGS += -I$(RTE_SDK)/drivers/common/mlx5/linux
+CFLAGS += -I$(RTE_SDK)/drivers/common/mlx5/linux
+CFLAGS += -I$(BUILDDIR)/drivers/common/mlx5/linux
 CFLAGS += -D_BSD_SOURCE
 CFLAGS += -D_DEFAULT_SOURCE
 CFLAGS += -D_XOPEN_SOURCE=600
@@ -26,6 +28,7 @@ LDLIBS += -lm
 LDLIBS += -lrte_eal -lrte_mbuf
 LDLIBS += -lrte_kvargs
 LDLIBS += -lrte_bus_pci
+LDLIBS += -lrte_regexdev
 
 # A few warnings cannot be avoided in external headers.
 CFLAGS += -Wno-error=cast-qual
diff --git a/drivers/regex/mlx5/meson.build b/drivers/regex/mlx5/meson.build
index e31b34a..327c0ad 100644
--- a/drivers/regex/mlx5/meson.build
+++ b/drivers/regex/mlx5/meson.build
@@ -8,7 +8,7 @@ if not is_linux
 endif
 
 fmt_name = 'mlx5_regex'
-deps += ['common_mlx5', 'pci', 'bus_pci', 'eal', 'sched']
+deps += ['common_mlx5', 'pci', 'bus_pci', 'eal', 'sched', 'regexdev']
 sources = files(
'mlx5_regex.c',
 )
diff --git a/drivers/regex/mlx5/mlx5_regex.c b/drivers/regex/mlx5/mlx5_regex.c
index 06826a6..d264ecd 100644
--- a/drivers/regex/mlx5/mlx5_regex.c
+++ b/drivers/regex/mlx5/mlx5_regex.c
@@ -2,8 +2,223 @@
  * Copyright 2020 Mellanox Technologies, Ltd
  */
 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
 #include "mlx5_regex.h"
 #include "mlx5_regex_utils.h"
 
 int mlx5_regex_logtype;
 
+static const struct rte_regexdev_ops mlx5_regexdev_ops = {};
+
+static struct ibv_device *
+mlx5_regex_get_ib_device_match(struct rte_pci_addr *addr)
+{
+   int n;
+   struct ibv_device **ibv_list = mlx5_glue->get_device_list(&n);
+   struct ibv_device *ibv_match = NULL;
+
+   if (!ibv_list) {
+   rte_errno = ENOSYS;
+   return NULL;
+   }
+   while (n-- > 0) {
+   struct rte_pci_addr pci_addr;
+
+   DRV_LOG(DEBUG, "Checking device \"%s\"..", ibv_list[n]->name);
+   if (mlx5_dev_to_pci_addr(ibv_list[n]->ibdev_path, &pci_addr))
+   continue;
+   if (rte_pci_addr_cmp(addr, &pci_addr))
+   continue;
+   ibv_match = ibv_list[n];
+   break;
+   }
+   if (!ibv_match)
+   rte_errno = ENOENT;
+   mlx5_glue->free_device_list(ibv_list);
+   return ibv_match;
+}
+
+static void
+mlx5_regex_get_name(char *name, struct rte_pci_device *pci_dev __rte_unused)
+{
+   sprintf(name, "mlx5_regex_%02x:%02x.%02x", pci_dev->addr.bus,
+   pci_dev->addr.devid, pci_dev->addr.function);
+}
+
+/**
+ * DPDK callback to register a PCI device.
+ *
+ * This function spawns RegEx device out of a given PCI device.
+ *
+ * @param[in] pci_drv
+ *   PCI driver structure (mlx5_regex_driver).
+ * @param[in] pci_dev
+ *   PCI device information.
+ *
+ * @return
+ *   0 on success, 1 to skip this driver, a negative errno value otherwise
+ *   and rte_errno is set.
+ */
+static int
+mlx5_regex_pci_probe(struct rte_pci_driver *pci_drv __rte_unused,
+struct rte_pci_device *pci_dev)
+{
+   struct ibv_device *ibv;
+   struct mlx5_regex_priv *priv = NULL;
+   struct ibv_context *ctx = NULL;
+   struct mlx5_hca_attr attr;
+   char name[RTE_REGEXDEV_NAME_MAX_LEN];
+   int ret;
+
+   ibv = mlx5_regex_get_ib_device_match(&pci_dev->addr);
+   if (!ibv) {
+   DRV_LOG(ERR, "No matching IB device for PCI slot "
+   PCI_PRI_FMT ".", pci_dev->addr.domain,
+   pci_dev->addr.bus, pci_dev->addr.devid,
+   pci_dev->addr.function);
+   return -rte_errno;
+   }
+   DRV_LOG(INFO, "PCI information matches for device \"%s\".",
+   ibv->name);
+   ctx = mlx5_glue->dv_open_device(ibv);
+   if (!ctx) {
+   DRV_LOG(ERR, "Failed to open IB device \"%s\".", ibv->name);
+   rte_errno = ENODEV;
+   return -rte_errno;
+   }
+   ret = mlx5_devx_cmd_query_hca_attr(ctx, &attr);
+   if (ret) {
+   DRV_LOG(ERR, "Unable to read HCA capabilities.");
+   rte_errno = ENOTSUP;
+   goto error;
+   } else if (!attr.regex || attr.regexp_num_of_engines == 0) {
+   DRV_LOG(ERR, "Not enough capabilities to support RegEx, ma

[dpdk-dev] [PATCH v2 14/20] regex/mlx5: add completion queue creation

This commit adds the creation of CQ

Signed-off-by: Ori Kam 
---
 drivers/regex/mlx5/Makefile |   1 +
 drivers/regex/mlx5/meson.build  |   1 +
 drivers/regex/mlx5/mlx5_regex.c |   1 +
 drivers/regex/mlx5/mlx5_regex.h |   4 +-
 drivers/regex/mlx5/mlx5_regex_control.c | 195 
 drivers/regex/mlx5/mlx5_rxp.c   |   1 +
 6 files changed, 201 insertions(+), 2 deletions(-)
 create mode 100644 drivers/regex/mlx5/mlx5_regex_control.c

diff --git a/drivers/regex/mlx5/Makefile b/drivers/regex/mlx5/Makefile
index be23b5a..3d3fc5d 100644
--- a/drivers/regex/mlx5/Makefile
+++ b/drivers/regex/mlx5/Makefile
@@ -9,6 +9,7 @@ LIB = librte_pmd_mlx5_regex.a
 # Sources.
 SRCS-$(CONFIG_RTE_LIBRTE_MLX5_REGEX_PMD) += mlx5_regex.c
 SRCS-$(CONFIG_RTE_LIBRTE_MLX5_REGEX_PMD) += mlx5_rxp.c
+SRCS-$(CONFIG_RTE_LIBRTE_MLX5_REGEX_PMD) += mlx5_regex_control.c
 
 # Basic CFLAGS.
 CFLAGS += -O3
diff --git a/drivers/regex/mlx5/meson.build b/drivers/regex/mlx5/meson.build
index d8d35c3..c7406fe 100644
--- a/drivers/regex/mlx5/meson.build
+++ b/drivers/regex/mlx5/meson.build
@@ -12,6 +12,7 @@ deps += ['common_mlx5', 'pci', 'bus_pci', 'eal', 'sched', 
'regexdev']
 sources = files(
'mlx5_regex.c',
'mlx5_rxp.c',
+   'mlx5_regex_control.c',
 )
 cflags_options = [
'-std=c11',
diff --git a/drivers/regex/mlx5/mlx5_regex.c b/drivers/regex/mlx5/mlx5_regex.c
index d5b33ad..f06f817 100644
--- a/drivers/regex/mlx5/mlx5_regex.c
+++ b/drivers/regex/mlx5/mlx5_regex.c
@@ -25,6 +25,7 @@
.dev_info_get = mlx5_regex_info_get,
.dev_configure = mlx5_regex_configure,
.dev_db_import = mlx5_regex_rules_db_import,
+   .dev_qp_setup = mlx5_regex_qp_setup,
 };
 
 
diff --git a/drivers/regex/mlx5/mlx5_regex.h b/drivers/regex/mlx5/mlx5_regex.h
index a3a0e55..515c9f4 100644
--- a/drivers/regex/mlx5/mlx5_regex.h
+++ b/drivers/regex/mlx5/mlx5_regex.h
@@ -23,7 +23,7 @@ struct mlx5_regex_sq {
struct mlx5_devx_obj *obj; /* The SQ DevX object. */
int64_t dbr_offset; /* Door bell record offset. */
uint32_t dbr_umem; /* Door bell record umem id. */
-   volatile struct mlx5_cqe *wqe; /* The SQ ring buffer. */
+   uint8_t *wqe; /* The SQ ring buffer. */
struct mlx5dv_devx_umem *wqe_umem; /* SQ buffer umem. */
 };
 
@@ -66,10 +66,10 @@ struct mlx5_regex_priv {
struct mlx5_regex_db db[MLX5_RXP_MAX_ENGINES +
MLX5_RXP_EM_COUNT];
uint32_t nb_engines; /* Number of RegEx engines. */
-   struct mlx5_dbr_page_list dbrpgs; /* Door-bell pages. */
uint32_t eqn; /* EQ number. */
struct mlx5dv_devx_uar *uar; /* UAR object. */
struct ibv_pd *pd;
+   struct mlx5_dbr_page_list dbrpgs; /* Door-bell pages. */
 };
 
 /* mlx5_rxp.c */
diff --git a/drivers/regex/mlx5/mlx5_regex_control.c 
b/drivers/regex/mlx5/mlx5_regex_control.c
new file mode 100644
index 000..577965f
--- /dev/null
+++ b/drivers/regex/mlx5/mlx5_regex_control.c
@@ -0,0 +1,195 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2020 Mellanox Technologies, Ltd
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "mlx5_regex.h"
+#include "mlx5_regex_utils.h"
+#include "mlx5_rxp_csrs.h"
+#include "mlx5_rxp.h"
+
+#define MLX5_REGEX_NUM_WQE_PER_PAGE (4096/64)
+
+/**
+ * Returns the number of qp obj to be created.
+ *
+ * @param nb_desc
+ *   The number of descriptors for the queue.
+ *
+ * @return
+ *   The number of obj to be created.
+ */
+static uint16_t
+regex_ctrl_get_nb_obj(uint16_t nb_desc)
+{
+   return ((nb_desc / MLX5_REGEX_NUM_WQE_PER_PAGE) +
+   !!(nb_desc % MLX5_REGEX_NUM_WQE_PER_PAGE));
+}
+
+/**
+ * destroy CQ.
+ *
+ * @param priv
+ *   Pointer to the priv object.
+ * @param cp
+ *   Pointer to the CQ to be destroyed.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+regex_ctrl_destroy_cq(struct mlx5_regex_priv *priv, struct mlx5_regex_cq *cq)
+{
+   if (cq->cqe_umem) {
+   mlx5_glue->devx_umem_dereg(cq->cqe_umem);
+   cq->cqe_umem = NULL;
+   }
+   if (cq->cqe) {
+   rte_free((void *)(uintptr_t)cq->cqe);
+   cq->cqe = NULL;
+   }
+   if (cq->dbr_offset) {
+   mlx5_release_dbr(&priv->dbrpgs, cq->dbr_umem, cq->dbr_offset);
+   cq->dbr_offset = -1;
+   }
+   if (cq->obj) {
+   mlx5_devx_cmd_destroy(cq->obj);
+   cq->obj = NULL;
+   }
+   return 0;
+}
+
+/**
+ * create the CQ object.
+ *
+ * @param priv
+ *   Pointer to the priv object.
+ * @param cp
+ *   Pointer to the CQ to be created.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+regex_ctrl_create_cq(struct mlx5_regex_priv *priv, struct mlx5_regex_cq *cq)
+{
+

[dpdk-dev] [PATCH v2 15/20] regex/mlx5: add send queue support

This commit introduce the SQ creation.
The SQ is used for enqueuing a job.

In order to support out of order matches, we create number
os SQ per one applicaiton QP.

Signed-off-by: Ori Kam 
---
 drivers/regex/mlx5/mlx5_regex.h |   2 +
 drivers/regex/mlx5/mlx5_regex_control.c | 168 
 2 files changed, 170 insertions(+)

diff --git a/drivers/regex/mlx5/mlx5_regex.h b/drivers/regex/mlx5/mlx5_regex.h
index 515c9f4..12033e8 100644
--- a/drivers/regex/mlx5/mlx5_regex.h
+++ b/drivers/regex/mlx5/mlx5_regex.h
@@ -25,6 +25,7 @@ struct mlx5_regex_sq {
uint32_t dbr_umem; /* Door bell record umem id. */
uint8_t *wqe; /* The SQ ring buffer. */
struct mlx5dv_devx_umem *wqe_umem; /* SQ buffer umem. */
+   uint32_t *dbr;
 };
 
 struct mlx5_regex_cq {
@@ -34,6 +35,7 @@ struct mlx5_regex_cq {
uint32_t dbr_umem; /* Door bell record umem id. */
volatile struct mlx5_cqe *cqe; /* The CQ ring buffer. */
struct mlx5dv_devx_umem *cqe_umem; /* CQ buffer umem. */
+   uint32_t *dbr;
 };
 
 struct mlx5_regex_qp {
diff --git a/drivers/regex/mlx5/mlx5_regex_control.c 
b/drivers/regex/mlx5/mlx5_regex_control.c
index 577965f..d378f48 100644
--- a/drivers/regex/mlx5/mlx5_regex_control.c
+++ b/drivers/regex/mlx5/mlx5_regex_control.c
@@ -105,6 +105,9 @@
goto error;
}
cq->dbr_umem = mlx5_os_get_umem_id(dbr_page->umem);
+   cq->dbr = (uint32_t *)((uintptr_t)dbr_page->dbrs +
+  (uintptr_t)cq->dbr_offset);
+
buf = rte_calloc(NULL, 1, sizeof(struct mlx5_cqe) * cq_size, 4096);
if (!buf) {
DRV_LOG(ERR, "Can't allocate cqe buffer.");
@@ -145,6 +148,159 @@
return -rte_errno;
 }
 
+static int
+regex_get_pdn(void *pd, uint32_t *pdn)
+{
+   struct mlx5dv_obj obj;
+   struct mlx5dv_pd pd_info;
+   int ret = 0;
+
+   obj.pd.in = pd;
+   obj.pd.out = &pd_info;
+   ret = mlx5_glue->dv_init_obj(&obj, MLX5DV_OBJ_PD);
+   if (ret) {
+   DRV_LOG(DEBUG, "Fail to get PD object info");
+   return ret;
+   }
+   *pdn = pd_info.pdn;
+   return 0;
+}
+
+/**
+ * create the SQ object.
+ *
+ * @param priv
+ *   Pointer to the priv object.
+ * @param qp
+ *   Pointer to the QP element
+ * @param q_ind
+ *   The index of the queue.
+ * @param log_nb_desc
+ *   Log 2 of the number of descriptors to be used.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+regex_ctrl_create_sq(struct mlx5_regex_priv *priv, struct mlx5_regex_qp *qp,
+uint16_t q_ind, uint16_t log_nb_desc)
+{
+   struct mlx5_devx_create_sq_attr attr = { 0 };
+   struct mlx5_devx_modify_sq_attr modify_attr = { 0 };
+   struct mlx5_devx_wq_attr *wq_attr = &attr.wq_attr;
+   struct mlx5_devx_dbr_page *dbr_page = NULL;
+   struct mlx5_regex_sq *sq = &qp->sqs[q_ind];
+   void *buf = NULL;
+   uint32_t sq_size;
+   uint32_t pd_num = 0;
+   int ret;
+
+   sq->log_nb_desc = log_nb_desc;
+   sq_size = 1 << sq->log_nb_desc;
+   sq->dbr_offset = mlx5_get_dbr(priv->ctx, &priv->dbrpgs, &dbr_page);
+   if (sq->dbr_offset < 0) {
+   DRV_LOG(ERR, "Can't allocate sq door bell record.");
+   rte_errno  = ENOMEM;
+   goto error;
+   }
+   sq->dbr_umem = mlx5_os_get_umem_id(dbr_page->umem);
+   sq->dbr = (uint32_t *)((uintptr_t)dbr_page->dbrs +
+  (uintptr_t)sq->dbr_offset);
+
+   buf = rte_calloc(NULL, 1, 64 * sq_size, 4096);
+   if (!buf) {
+   DRV_LOG(ERR, "Can't allocate wqe buffer.");
+   rte_errno  = ENOMEM;
+   goto error;
+   }
+   sq->wqe = buf;
+   sq->wqe_umem = mlx5_glue->devx_umem_reg(priv->ctx, buf, 64 * sq_size,
+   7);
+   if (!sq->wqe_umem) {
+   DRV_LOG(ERR, "Can't register wqe mem.");
+   rte_errno  = ENOMEM;
+   goto error;
+   }
+   attr.state = MLX5_SQC_STATE_RST;
+   attr.tis_lst_sz = 0;
+   attr.tis_num = 0;
+   attr.user_index = q_ind;
+   attr.cqn = qp->cq.obj->id;
+   wq_attr->uar_page = priv->uar->page_id;
+   regex_get_pdn(priv->pd, &pd_num);
+   wq_attr->pd = pd_num;
+   wq_attr->wq_type = MLX5_WQ_TYPE_CYCLIC;
+   wq_attr->dbr_umem_id = sq->dbr_umem;
+   wq_attr->dbr_addr = sq->dbr_offset;
+   wq_attr->dbr_umem_valid = 1;
+   wq_attr->wq_umem_id = mlx5_os_get_umem_id(sq->wqe_umem);
+   wq_attr->wq_umem_offset = 0;
+   wq_attr->wq_umem_valid = 1;
+   wq_attr->log_wq_stride = 6;
+   wq_attr->log_wq_sz = sq->log_nb_desc;
+   sq->obj = mlx5_devx_cmd_create_sq(priv->ctx, &attr);
+   if (!sq->obj) {
+   DRV_LOG(ERR, "Can't create sq object.");
+   rte_errno  = ENOMEM;
+   goto error;
+   }

[dpdk-dev] [PATCH v2 13/20] regex/mlx5: add program rules support

From: Francis Kelly 

This commit introduce the ability to program rules to the
RegEx engine.

Signed-off-by: Francis Kelly 
---
 drivers/regex/mlx5/mlx5_regex.c |   34 ++
 drivers/regex/mlx5/mlx5_regex.h |   56 ++-
 drivers/regex/mlx5/mlx5_rxp.c   | 1015 +--
 drivers/regex/mlx5/mlx5_rxp.h   |  138 ++
 4 files changed, 1191 insertions(+), 52 deletions(-)
 create mode 100644 drivers/regex/mlx5/mlx5_rxp.h

diff --git a/drivers/regex/mlx5/mlx5_regex.c b/drivers/regex/mlx5/mlx5_regex.c
index 94e4352..d5b33ad 100644
--- a/drivers/regex/mlx5/mlx5_regex.c
+++ b/drivers/regex/mlx5/mlx5_regex.c
@@ -24,6 +24,7 @@
 const struct rte_regexdev_ops mlx5_regexdev_ops = {
.dev_info_get = mlx5_regex_info_get,
.dev_configure = mlx5_regex_configure,
+   .dev_db_import = mlx5_regex_rules_db_import,
 };
 
 
@@ -149,6 +150,9 @@
goto error;
}
priv->ctx = ctx;
+   priv->nb_engines = 2; /* attr.regexp_num_of_engines */
+   /* Default RXP programming mode to Shared. */
+   priv->prog_mode = MLX5_RXP_SHARED_PROG_MODE;
mlx5_regex_get_name(name, pci_dev);
priv->regexdev = rte_regexdev_register(name);
if (priv->regexdev == NULL) {
@@ -156,6 +160,24 @@
rte_errno = rte_errno ? rte_errno : EINVAL;
goto error;
}
+   ret = mlx5_glue->devx_query_eqn(ctx, 0, &priv->eqn);
+   if (ret) {
+   DRV_LOG(ERR, "can't query event queue number.");
+   rte_errno = ENOMEM;
+   goto error;
+   }
+   priv->uar = mlx5_glue->devx_alloc_uar(ctx, 0);
+   if (!priv->uar) {
+   DRV_LOG(ERR, "can't allocate uar.");
+   rte_errno = ENOMEM;
+   goto error;
+   }
+   priv->pd = mlx5_glue->alloc_pd(ctx);
+   if (!priv->pd) {
+   DRV_LOG(ERR, "can't allocate pd.");
+   rte_errno = ENOMEM;
+   goto error;
+   }
priv->regexdev->dev_ops = &mlx5_regexdev_ops;
priv->regexdev->device = (struct rte_device *)pci_dev;
priv->regexdev->data->dev_private = priv;
@@ -163,6 +185,12 @@
return 0;
 
 error:
+   if (priv->pd)
+   mlx5_glue->dealloc_pd(priv->pd);
+   if (priv->uar)
+   mlx5_glue->devx_free_uar(priv->uar);
+   if (priv->regexdev)
+   rte_regexdev_unregister(priv->regexdev);
if (ctx)
mlx5_glue->close_device(ctx);
if (priv)
@@ -194,6 +222,12 @@
return 0;
priv = dev->data->dev_private;
if (priv) {
+   if (priv->pd)
+   mlx5_glue->dealloc_pd(priv->pd);
+   if (priv->uar)
+   mlx5_glue->devx_free_uar(priv->uar);
+   if (priv->regexdev)
+   rte_regexdev_unregister(priv->regexdev);
if (priv->ctx)
mlx5_glue->close_device(priv->ctx);
if (priv->regexdev)
diff --git a/drivers/regex/mlx5/mlx5_regex.h b/drivers/regex/mlx5/mlx5_regex.h
index 5238f24..a3a0e55 100644
--- a/drivers/regex/mlx5/mlx5_regex.h
+++ b/drivers/regex/mlx5/mlx5_regex.h
@@ -5,14 +5,53 @@
 #ifndef MLX5_REGEX_H
 #define MLX5_REGEX_H
 
+#ifdef PEDANTIC
+#pragma GCC diagnostic ignored "-Wpedantic"
+#endif
+#include 
+#include 
+#ifdef PEDANTIC
+#pragma GCC diagnostic error "-Wpedantic"
+#endif
+
+#include 
+
+#include "mlx5_rxp.h"
+
 struct mlx5_regex_sq {
-   uint32_t nb_desc; /* Number of desc for this object. */
+   uint16_t log_nb_desc; /* Log 2 number of desc for this object. */
+   struct mlx5_devx_obj *obj; /* The SQ DevX object. */
+   int64_t dbr_offset; /* Door bell record offset. */
+   uint32_t dbr_umem; /* Door bell record umem id. */
+   volatile struct mlx5_cqe *wqe; /* The SQ ring buffer. */
+   struct mlx5dv_devx_umem *wqe_umem; /* SQ buffer umem. */
+};
+
+struct mlx5_regex_cq {
+   uint32_t log_nb_desc; /* Log 2 number of desc for this object. */
+   struct mlx5_devx_obj *obj; /* The CQ DevX object. */
+   int64_t dbr_offset; /* Door bell record offset. */
+   uint32_t dbr_umem; /* Door bell record umem id. */
+   volatile struct mlx5_cqe *cqe; /* The CQ ring buffer. */
+   struct mlx5dv_devx_umem *cqe_umem; /* CQ buffer umem. */
 };
 
 struct mlx5_regex_qp {
uint32_t flags; /* QP user flags. */
-   uint32_t nb_desc; /* Total number of desc for thsi qp. */
+   uint16_t nb_desc; /* Total number of desc for this qp. */
struct mlx5_regex_sq *sqs; /* Pointer to sq array. */
+   uint16_t nb_obj; /* Number of sq objects. */
+   struct mlx5_regex_cq cq; /* CQ struct. */
+};
+
+struct mlx5_regex_db {
+   void *ptr; /* Pointer to the db memory. */
+   uint32_t len; /* The memory len. */
+   bool active; /* Active flag. */
+   uint8_t db_assigned_to_eng_num;
+   /**< To which engine the db is connected. */
+

[dpdk-dev] [PATCH v2 12/20] regex/mlx5: add configure function

This commit implements the configure function.
This function is responsible to configure the RegEx engine.

Signed-off-by: Ori Kam 
---
 drivers/regex/mlx5/mlx5_regex.c |   2 +
 drivers/regex/mlx5/mlx5_regex.h |  15 +++
 drivers/regex/mlx5/mlx5_rxp.c   | 279 +++-
 3 files changed, 295 insertions(+), 1 deletion(-)

diff --git a/drivers/regex/mlx5/mlx5_regex.c b/drivers/regex/mlx5/mlx5_regex.c
index 2c4b7ce..94e4352 100644
--- a/drivers/regex/mlx5/mlx5_regex.c
+++ b/drivers/regex/mlx5/mlx5_regex.c
@@ -23,6 +23,7 @@
 
 const struct rte_regexdev_ops mlx5_regexdev_ops = {
.dev_info_get = mlx5_regex_info_get,
+   .dev_configure = mlx5_regex_configure,
 };
 
 
@@ -158,6 +159,7 @@
priv->regexdev->dev_ops = &mlx5_regexdev_ops;
priv->regexdev->device = (struct rte_device *)pci_dev;
priv->regexdev->data->dev_private = priv;
+   priv->regexdev->state = RTE_REGEXDEV_READY;
return 0;
 
 error:
diff --git a/drivers/regex/mlx5/mlx5_regex.h b/drivers/regex/mlx5/mlx5_regex.h
index 9d0fc16..5238f24 100644
--- a/drivers/regex/mlx5/mlx5_regex.h
+++ b/drivers/regex/mlx5/mlx5_regex.h
@@ -5,15 +5,30 @@
 #ifndef MLX5_REGEX_H
 #define MLX5_REGEX_H
 
+struct mlx5_regex_sq {
+   uint32_t nb_desc; /* Number of desc for this object. */
+};
+
+struct mlx5_regex_qp {
+   uint32_t flags; /* QP user flags. */
+   uint32_t nb_desc; /* Total number of desc for thsi qp. */
+   struct mlx5_regex_sq *sqs; /* Pointer to sq array. */
+};
+
 struct mlx5_regex_priv {
TAILQ_ENTRY(mlx5_regex_priv) next;
struct ibv_context *ctx; /* Device context. */
struct rte_pci_device *pci_dev;
struct rte_regexdev *regexdev; /* Pointer to the RegEx dev. */
+   uint16_t nb_queues; /* Number of queues. */
+   struct mlx5_regex_qp *qps; /* Pointer to the qp array. */
+   uint16_t nb_max_matches; /* Max number of matches. */
 };
 
 /* mlx5_rxp.c */
 int mlx5_regex_info_get(struct rte_regexdev *dev,
struct rte_regexdev_info *info);
+int mlx5_regex_configure(struct rte_regexdev *dev,
+const struct rte_regexdev_config *cfg);
 
 #endif /* MLX5_REGEX_H */
diff --git a/drivers/regex/mlx5/mlx5_rxp.c b/drivers/regex/mlx5/mlx5_rxp.c
index 12d55ed..60a4640 100644
--- a/drivers/regex/mlx5/mlx5_rxp.c
+++ b/drivers/regex/mlx5/mlx5_rxp.c
@@ -2,13 +2,22 @@
  * Copyright 2020 Mellanox Technologies, Ltd
  */
 
+#include 
+
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 
+#include 
+#include 
+#include 
+
 #include "mlx5_regex.h"
+#include "mlx5_regex_utils.h"
+#include "mlx5_rxp_csrs.h"
 
 #define MLX5_REGEX_MAX_MATCHES 255
 #define MLX5_REGEX_MAX_PAYLOAD_SIZE UINT16_MAX
@@ -29,7 +38,7 @@
  */
 int
 mlx5_regex_info_get(struct rte_regexdev *dev __rte_unused,
- struct rte_regexdev_info *info)
+   struct rte_regexdev_info *info)
 {
info->max_matches = MLX5_REGEX_MAX_MATCHES;
info->max_payload_size = MLX5_REGEX_MAX_PAYLOAD_SIZE;
@@ -39,3 +48,271 @@
info->rule_flags = 0;
return 0;
 }
+
+static int
+rxp_poll_csr_for_value(struct ibv_context *ctx, uint32_t *value,
+  uint32_t address, uint32_t expected_value,
+  uint32_t expected_mask, uint32_t timeout_ms, uint8_t id)
+{
+   unsigned int i;
+   int ret;
+
+   ret = -EBUSY;
+   for (i = 0; i < timeout_ms; i++) {
+   if (mlx5_devx_regex_register_read(ctx, id, address, value))
+   return -1;
+
+   if ((*value & expected_mask) == expected_value) {
+   ret = 0;
+   break;
+   }
+   rte_delay_us(1000);
+   }
+   return ret;
+}
+
+/**
+ * Start the selected engine.
+ *
+ * @param ctx
+ *   The IBV context.
+ * @param id
+ *   The selected engine.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+rxp_start_engine(struct ibv_context *ctx, uint8_t id)
+{
+   uint32_t ctrl;
+   int ret;
+
+   ret = mlx5_devx_regex_register_read(ctx, id, MLX5_RXP_CSR_CTRL, &ctrl);
+   if (ret)
+   return ret;
+   ctrl |= MLX5_RXP_CSR_CTRL_GO;
+   ret = mlx5_devx_regex_register_write(ctx, id, MLX5_RXP_CSR_CTRL, ctrl);
+   return ret;
+}
+
+/**
+ * Stop the selected engine.
+ *
+ * @param ctx
+ *   The IBV context.
+ * @param id
+ *   The selected engine.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+rxp_stop_engine(struct ibv_context *ctx, uint8_t id)
+{
+   uint32_t ctrl;
+   int ret;
+
+   ret = mlx5_devx_regex_register_read(ctx, id, MLX5_RXP_CSR_CTRL, &ctrl);
+   if (ret)
+   return ret;
+   ctrl &= ~MLX5_RXP_CSR_CTRL_GO;
+   ret = mlx5_devx_regex_register_write(ctx, id, MLX5_RXP_CSR_CTRL, ctrl);
+   return ret;
+}
+
+static int
+

[dpdk-dev] [PATCH v2 11/20] regex/mlx5: add get info function

This commit adds the get info function.

Signed-off-by: Ori Kam 
---
 drivers/regex/mlx5/Makefile |  1 +
 drivers/regex/mlx5/meson.build  |  1 +
 drivers/regex/mlx5/mlx5_regex.c |  5 -
 drivers/regex/mlx5/mlx5_regex.h |  5 +
 drivers/regex/mlx5/mlx5_rxp.c   | 41 +
 5 files changed, 52 insertions(+), 1 deletion(-)
 create mode 100644 drivers/regex/mlx5/mlx5_rxp.c

diff --git a/drivers/regex/mlx5/Makefile b/drivers/regex/mlx5/Makefile
index 3b99570..be23b5a 100644
--- a/drivers/regex/mlx5/Makefile
+++ b/drivers/regex/mlx5/Makefile
@@ -8,6 +8,7 @@ LIB = librte_pmd_mlx5_regex.a
 
 # Sources.
 SRCS-$(CONFIG_RTE_LIBRTE_MLX5_REGEX_PMD) += mlx5_regex.c
+SRCS-$(CONFIG_RTE_LIBRTE_MLX5_REGEX_PMD) += mlx5_rxp.c
 
 # Basic CFLAGS.
 CFLAGS += -O3
diff --git a/drivers/regex/mlx5/meson.build b/drivers/regex/mlx5/meson.build
index 327c0ad..d8d35c3 100644
--- a/drivers/regex/mlx5/meson.build
+++ b/drivers/regex/mlx5/meson.build
@@ -11,6 +11,7 @@ fmt_name = 'mlx5_regex'
 deps += ['common_mlx5', 'pci', 'bus_pci', 'eal', 'sched', 'regexdev']
 sources = files(
'mlx5_regex.c',
+   'mlx5_rxp.c',
 )
 cflags_options = [
'-std=c11',
diff --git a/drivers/regex/mlx5/mlx5_regex.c b/drivers/regex/mlx5/mlx5_regex.c
index c469a10..2c4b7ce 100644
--- a/drivers/regex/mlx5/mlx5_regex.c
+++ b/drivers/regex/mlx5/mlx5_regex.c
@@ -21,7 +21,10 @@
 
 int mlx5_regex_logtype;
 
-static const struct rte_regexdev_ops mlx5_regexdev_ops = {};
+const struct rte_regexdev_ops mlx5_regexdev_ops = {
+   .dev_info_get = mlx5_regex_info_get,
+};
+
 
 static struct ibv_device *
 mlx5_regex_get_ib_device_match(struct rte_pci_addr *addr)
diff --git a/drivers/regex/mlx5/mlx5_regex.h b/drivers/regex/mlx5/mlx5_regex.h
index 0ce1e4d..9d0fc16 100644
--- a/drivers/regex/mlx5/mlx5_regex.h
+++ b/drivers/regex/mlx5/mlx5_regex.h
@@ -11,4 +11,9 @@ struct mlx5_regex_priv {
struct rte_pci_device *pci_dev;
struct rte_regexdev *regexdev; /* Pointer to the RegEx dev. */
 };
+
+/* mlx5_rxp.c */
+int mlx5_regex_info_get(struct rte_regexdev *dev,
+   struct rte_regexdev_info *info);
+
 #endif /* MLX5_REGEX_H */
diff --git a/drivers/regex/mlx5/mlx5_rxp.c b/drivers/regex/mlx5/mlx5_rxp.c
new file mode 100644
index 000..12d55ed
--- /dev/null
+++ b/drivers/regex/mlx5/mlx5_rxp.c
@@ -0,0 +1,41 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2020 Mellanox Technologies, Ltd
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "mlx5_regex.h"
+
+#define MLX5_REGEX_MAX_MATCHES 255
+#define MLX5_REGEX_MAX_PAYLOAD_SIZE UINT16_MAX
+#define MLX5_REGEX_MAX_RULES_PER_GROUP UINT16_MAX
+#define MLX5_REGEX_MAX_GROUPS UINT16_MAX
+
+/**
+ * DPDK callback for reading device info.
+ *
+ * @param dev
+ *   Pointer to RegEx device structure.
+ * @param[out] info
+ *   Pointer to the regexdev info structure to be filled with the contextual
+ *   information of the device.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+int
+mlx5_regex_info_get(struct rte_regexdev *dev __rte_unused,
+ struct rte_regexdev_info *info)
+{
+   info->max_matches = MLX5_REGEX_MAX_MATCHES;
+   info->max_payload_size = MLX5_REGEX_MAX_PAYLOAD_SIZE;
+   info->max_rules_per_group = MLX5_REGEX_MAX_RULES_PER_GROUP;
+   info->max_groups = MLX5_REGEX_MAX_GROUPS;
+   info->regexdev_capa = RTE_REGEXDEV_SUPP_PCRE_GREEDY_F;
+   info->rule_flags = 0;
+   return 0;
+}
-- 
1.8.3.1

[dpdk-dev] [PATCH v2 20/20] regex/mlx5: add start stop functions

Add the start, stop and close functions.
In current implementation they are empty functions
and are only exists in order that when called
from rte level, the function will return with success code.

Signed-off-by: Ori Kam 
---
 drivers/regex/mlx5/mlx5_regex.c | 20 
 drivers/regex/mlx5/mlx5_regex.h |  6 ++
 2 files changed, 26 insertions(+)

diff --git a/drivers/regex/mlx5/mlx5_regex.c b/drivers/regex/mlx5/mlx5_regex.c
index 765b67b..8c1ec23 100644
--- a/drivers/regex/mlx5/mlx5_regex.c
+++ b/drivers/regex/mlx5/mlx5_regex.c
@@ -26,8 +26,28 @@
.dev_configure = mlx5_regex_configure,
.dev_db_import = mlx5_regex_rules_db_import,
.dev_qp_setup = mlx5_regex_qp_setup,
+   .dev_start = mlx5_regex_start,
+   .dev_stop = mlx5_regex_stop,
+   .dev_close = mlx5_regex_close,
 };
 
+int
+mlx5_regex_start(struct rte_regexdev *dev __rte_unused)
+{
+   return 0;
+}
+
+int
+mlx5_regex_stop(struct rte_regexdev *dev __rte_unused)
+{
+   return 0;
+}
+
+int
+mlx5_regex_close(struct rte_regexdev *dev __rte_unused)
+{
+   return 0;
+}
 
 static struct ibv_device *
 mlx5_regex_get_ib_device_match(struct rte_pci_addr *addr)
diff --git a/drivers/regex/mlx5/mlx5_regex.h b/drivers/regex/mlx5/mlx5_regex.h
index aefd7da..a472414 100644
--- a/drivers/regex/mlx5/mlx5_regex.h
+++ b/drivers/regex/mlx5/mlx5_regex.h
@@ -84,6 +84,12 @@ struct mlx5_regex_priv {
struct mlx5_dbr_page_list dbrpgs; /* Door-bell pages. */
 };
 
+/* mlx5_regex.c */
+
+int mlx5_regex_start(struct rte_regexdev *dev);
+int mlx5_regex_stop(struct rte_regexdev *dev);
+int mlx5_regex_close(struct rte_regexdev *dev);
+
 /* mlx5_rxp.c */
 int mlx5_regex_info_get(struct rte_regexdev *dev,
struct rte_regexdev_info *info);
-- 
1.8.3.1

[dpdk-dev] [PATCH v2 18/20] regex/mlx5: add enqueue implementation

From: Yuval Avnery 

Will look for a free SQ to send the job on.
doorbell will be given when sq is full, or no more jobs on the burst.

Signed-off-by: Yuval Avnery 
Acked-by: Ori Kam 

---
 drivers/regex/mlx5/mlx5_regex.c  |   1 +
 drivers/regex/mlx5/mlx5_regex.h  |   6 ++
 drivers/regex/mlx5/mlx5_regex_control.c  |   2 +
 drivers/regex/mlx5/mlx5_regex_fastpath.c | 146 +--
 4 files changed, 148 insertions(+), 7 deletions(-)

diff --git a/drivers/regex/mlx5/mlx5_regex.c b/drivers/regex/mlx5/mlx5_regex.c
index f06f817..d823e17 100644
--- a/drivers/regex/mlx5/mlx5_regex.c
+++ b/drivers/regex/mlx5/mlx5_regex.c
@@ -180,6 +180,7 @@
goto error;
}
priv->regexdev->dev_ops = &mlx5_regexdev_ops;
+   priv->regexdev->enqueue = mlx5_regexdev_enqueue;
priv->regexdev->device = (struct rte_device *)pci_dev;
priv->regexdev->data->dev_private = priv;
priv->regexdev->state = RTE_REGEXDEV_READY;
diff --git a/drivers/regex/mlx5/mlx5_regex.h b/drivers/regex/mlx5/mlx5_regex.h
index cf8863f..468772c 100644
--- a/drivers/regex/mlx5/mlx5_regex.h
+++ b/drivers/regex/mlx5/mlx5_regex.h
@@ -25,6 +25,9 @@ struct mlx5_regex_sq {
uint32_t dbr_umem; /* Door bell record umem id. */
uint8_t *wqe; /* The SQ ring buffer. */
struct mlx5dv_devx_umem *wqe_umem; /* SQ buffer umem. */
+   size_t pi, db_pi;
+   size_t ci;
+   uint32_t sqn;
uint32_t *dbr;
 };
 
@@ -49,6 +52,7 @@ struct mlx5_regex_qp {
struct ibv_mr *metadata;
struct ibv_mr *inputs;
struct ibv_mr *outputs;
+   size_t ci, pi;
 };
 
 struct mlx5_regex_db {
@@ -91,4 +95,6 @@ int mlx5_regex_rules_db_import(struct rte_regexdev *dev,
 
 /* mlx5_regex_fastpath.c */
 int mlx5_regexdev_setup_fastpath(struct mlx5_regex_priv *priv, uint32_t qp_id);
+uint16_t mlx5_regexdev_enqueue(struct rte_regexdev *dev, uint16_t qp_id,
+  struct rte_regex_ops **ops, uint16_t nb_ops);
 #endif /* MLX5_REGEX_H */
diff --git a/drivers/regex/mlx5/mlx5_regex_control.c 
b/drivers/regex/mlx5/mlx5_regex_control.c
index 9b3f39e..c2d080f 100644
--- a/drivers/regex/mlx5/mlx5_regex_control.c
+++ b/drivers/regex/mlx5/mlx5_regex_control.c
@@ -216,6 +216,8 @@
sq->wqe = buf;
sq->wqe_umem = mlx5_glue->devx_umem_reg(priv->ctx, buf, 64 * sq_size,
7);
+   sq->ci = 0;
+   sq->pi = 0;
if (!sq->wqe_umem) {
DRV_LOG(ERR, "Can't register wqe mem.");
rte_errno  = ENOMEM;
diff --git a/drivers/regex/mlx5/mlx5_regex_fastpath.c 
b/drivers/regex/mlx5/mlx5_regex_fastpath.c
index b5147ce..1823353 100644
--- a/drivers/regex/mlx5/mlx5_regex_fastpath.c
+++ b/drivers/regex/mlx5/mlx5_regex_fastpath.c
@@ -33,10 +33,14 @@
 #pragma GCC diagnostic error "-Wpedantic"
 #endif
 
-#define MAX_WQE_INDEX 0x
+#define MLX5_REGEX_MAX_WQE_INDEX 0x
 #define MLX5_REGEX_METADATA_SIZE 64
-#define MLX5_REGEX_MAX_INPUT (1<<14)
-#define MLX5_REGEX_MAX_OUTPUT (1<<11)
+#define MLX5_REGEX_MAX_INPUT (1 << 14)
+#define MLX5_REGEX_MAX_OUTPUT (1 << 11)
+#define MLX5_REGEX_WQE_CTRL_OFFSET 12
+#define MLX5_REGEX_WQE_METADATA_OFFSET 16
+#define MLX5_REGEX_WQE_GATHER_OFFSET 32
+#define MLX5_REGEX_WQE_SCATTER_OFFSET 48
 
 
 static inline uint32_t
@@ -77,6 +81,134 @@ struct mlx5_regex_job {
seg->addr = rte_cpu_to_be_64(address);
 }
 
+static inline void
+set_regex_ctrl_seg(void *seg, uint8_t le, uint16_t subset_id0,
+  uint16_t subset_id1, uint16_t subset_id2,
+  uint16_t subset_id3, uint8_t ctrl)
+{
+   DEVX_SET(regexp_mmo_control, seg, le, le);
+   DEVX_SET(regexp_mmo_control, seg, ctrl, ctrl);
+   DEVX_SET(regexp_mmo_control, seg, subset_id_0, subset_id0);
+   DEVX_SET(regexp_mmo_control, seg, subset_id_1, subset_id1);
+   DEVX_SET(regexp_mmo_control, seg, subset_id_2, subset_id2);
+   DEVX_SET(regexp_mmo_control, seg, subset_id_3, subset_id3);
+}
+
+static inline void
+set_wqe_ctrl_seg(struct mlx5_wqe_ctrl_seg *seg, uint16_t pi, uint8_t opcode,
+uint8_t opmod, uint32_t qp_num, uint8_t fm_ce_se, uint8_t ds,
+uint8_t signature, uint32_t imm)
+{
+   seg->opmod_idx_opcode = rte_cpu_to_be_32(((uint32_t)opmod << 24) |
+((uint32_t)pi << 8) |
+opcode);
+   seg->qpn_ds = rte_cpu_to_be_32((qp_num << 8) | ds);
+   seg->fm_ce_se = fm_ce_se;
+   seg->signature = signature;
+   seg->imm = imm;
+}
+
+static inline void
+prep_one(struct mlx5_regex_sq *sq, struct rte_regex_ops *op,
+struct mlx5_regex_job *job)
+{
+   size_t wqe_offset = (sq->pi % sq_size_get(sq)) * MLX5_SEND_WQE_BB;
+   uint8_t *wqe = (uint8_t *)sq->wqe + wqe_offset;
+   int ds = 4; /*  ctrl + meta + input + output */
+
+   memcpy(job->input,
+   rte_pktmbuf_mtod(op->mbuf, voi

[dpdk-dev] [PATCH v2 16/20] common/mlx5: add match tuple hw layout

From: Yuval Avnery 

Add the found match tuple.

Signed-off-by: Yuval Avnery 
Acked-by: Viacheslav Ovsiienko 

---
 drivers/common/mlx5/mlx5_prm.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/common/mlx5/mlx5_prm.h b/drivers/common/mlx5/mlx5_prm.h
index bfbc58b..874dde6 100644
--- a/drivers/common/mlx5/mlx5_prm.h
+++ b/drivers/common/mlx5/mlx5_prm.h
@@ -409,6 +409,12 @@ struct mlx5_ifc_regexp_metadata_bits {
uint8_t reserved[0x80];
 };
 
+struct mlx5_ifc_regexp_match_tuple_bits {
+   uint8_t length[0x10];
+   uint8_t start_ptr[0x10];
+   uint8_t rule_id[0x20];
+};
+
 /* Adding direct verbs to data-path. */
 
 /* CQ sequence number mask. */
-- 
1.8.3.1

[dpdk-dev] [PATCH v2 19/20] regex/mlx5: implement dequeue function

From: Yuval Avnery 

Implement dequeue function for the regex API.

Signed-off-by: Yuval Avnery 
Acked-by: Ori Kam 

---
 drivers/regex/mlx5/mlx5_regex.c  |   1 +
 drivers/regex/mlx5/mlx5_regex.h  |   4 ++
 drivers/regex/mlx5/mlx5_regex_control.c  |   1 +
 drivers/regex/mlx5/mlx5_regex_fastpath.c | 104 +++
 4 files changed, 110 insertions(+)

diff --git a/drivers/regex/mlx5/mlx5_regex.c b/drivers/regex/mlx5/mlx5_regex.c
index d823e17..765b67b 100644
--- a/drivers/regex/mlx5/mlx5_regex.c
+++ b/drivers/regex/mlx5/mlx5_regex.c
@@ -181,6 +181,7 @@
}
priv->regexdev->dev_ops = &mlx5_regexdev_ops;
priv->regexdev->enqueue = mlx5_regexdev_enqueue;
+   priv->regexdev->dequeue = mlx5_regexdev_dequeue;
priv->regexdev->device = (struct rte_device *)pci_dev;
priv->regexdev->data->dev_private = priv;
priv->regexdev->state = RTE_REGEXDEV_READY;
diff --git a/drivers/regex/mlx5/mlx5_regex.h b/drivers/regex/mlx5/mlx5_regex.h
index 468772c..aefd7da 100644
--- a/drivers/regex/mlx5/mlx5_regex.h
+++ b/drivers/regex/mlx5/mlx5_regex.h
@@ -38,6 +38,7 @@ struct mlx5_regex_cq {
uint32_t dbr_umem; /* Door bell record umem id. */
volatile struct mlx5_cqe *cqe; /* The CQ ring buffer. */
struct mlx5dv_devx_umem *cqe_umem; /* CQ buffer umem. */
+   size_t ci;
uint32_t *dbr;
 };
 
@@ -97,4 +98,7 @@ int mlx5_regex_rules_db_import(struct rte_regexdev *dev,
 int mlx5_regexdev_setup_fastpath(struct mlx5_regex_priv *priv, uint32_t qp_id);
 uint16_t mlx5_regexdev_enqueue(struct rte_regexdev *dev, uint16_t qp_id,
   struct rte_regex_ops **ops, uint16_t nb_ops);
+uint16_t mlx5_regexdev_dequeue(struct rte_regexdev *dev, uint16_t qp_id,
+  struct rte_regex_ops **ops, uint16_t nb_ops);
+
 #endif /* MLX5_REGEX_H */
diff --git a/drivers/regex/mlx5/mlx5_regex_control.c 
b/drivers/regex/mlx5/mlx5_regex_control.c
index c2d080f..65c623a 100644
--- a/drivers/regex/mlx5/mlx5_regex_control.c
+++ b/drivers/regex/mlx5/mlx5_regex_control.c
@@ -120,6 +120,7 @@
cq->cqe_umem = mlx5_glue->devx_umem_reg(priv->ctx, buf,
sizeof(struct mlx5_cqe) *
cq_size, 7);
+   cq->ci = 0;
if (!cq->cqe_umem) {
DRV_LOG(ERR, "Can't register cqe mem.");
rte_errno  = ENOMEM;
diff --git a/drivers/regex/mlx5/mlx5_regex_fastpath.c 
b/drivers/regex/mlx5/mlx5_regex_fastpath.c
index 1823353..0d4d069 100644
--- a/drivers/regex/mlx5/mlx5_regex_fastpath.c
+++ b/drivers/regex/mlx5/mlx5_regex_fastpath.c
@@ -41,6 +41,7 @@
 #define MLX5_REGEX_WQE_METADATA_OFFSET 16
 #define MLX5_REGEX_WQE_GATHER_OFFSET 32
 #define MLX5_REGEX_WQE_SCATTER_OFFSET 48
+#define MLX5_REGEX_METADATA_OFF 32
 
 
 static inline uint32_t
@@ -209,6 +210,109 @@ struct mlx5_regex_job {
return i;
 }
 
+#define MLX5_REGEX_RESP_SZ 8
+
+static inline void
+extract_result(struct rte_regex_ops *op, struct mlx5_regex_job *job)
+{
+   size_t j, offset;
+   op->user_id = job->user_id;
+   op->nb_matches = DEVX_GET(regexp_metadata, job->metadata +
+ MLX5_REGEX_METADATA_OFF, match_count);
+   op->nb_actual_matches = DEVX_GET(regexp_metadata, job->metadata +
+MLX5_REGEX_METADATA_OFF,
+detected_match_count);
+   for (j = 0; j < op->nb_matches; j++) {
+   offset = MLX5_REGEX_RESP_SZ * j;
+   op->matches[j].rule_id =
+   DEVX_GET(regexp_match_tuple, (job->output + offset),
+rule_id);
+   op->matches[j].start_offset =
+   DEVX_GET(regexp_match_tuple, (job->output +  offset),
+start_ptr);
+   op->matches[j].len =
+   DEVX_GET(regexp_match_tuple, (job->output +  offset),
+length);
+   }
+}
+
+static inline volatile struct mlx5_cqe *
+poll_one(struct mlx5_regex_cq *cq)
+{
+   volatile struct mlx5_cqe *cqe;
+   size_t next_cqe_offset;
+
+   next_cqe_offset =  (cq->ci % cq_size_get(cq)) * sizeof(*cqe);
+   cqe = (volatile struct mlx5_cqe *)(cq->cqe + next_cqe_offset);
+   rte_cio_wmb();
+
+   int ret = check_cqe(cqe, cq_size_get(cq), cq->ci);
+
+   if (unlikely(ret == MLX5_CQE_STATUS_ERR)) {
+   DRV_LOG(ERR, "Completion with error on qp 0x%x",  0);
+   return NULL;
+   }
+
+   if (unlikely(ret != MLX5_CQE_STATUS_SW_OWN))
+   return NULL;
+
+   return cqe;
+}
+
+
+/**
+ * DPDK callback for dequeue.
+ *
+ * @param dev
+ *   Pointer to the regex dev structure.
+ * @param qp_id
+ *   The queue to enqueue the traffic to.
+ * @param ops
+ *   List of regex ops to dequeue.
+ * @param nb_ops
+ *   Number of ops in ops parameter.
+

[dpdk-dev] [PATCH v2 17/20] regex/mlx5: fastpath setup

From: Yuval Avnery 

Allocated and register input/output buffers and metadata.

Signed-off-by: Yuval Avnery 
Acked-by: Ori Kam 

---
 drivers/regex/mlx5/Makefile  |   1 +
 drivers/regex/mlx5/meson.build   |   1 +
 drivers/regex/mlx5/mlx5_regex.h  |   8 ++
 drivers/regex/mlx5/mlx5_regex_control.c  |   2 +
 drivers/regex/mlx5/mlx5_regex_fastpath.c | 198 +++
 5 files changed, 210 insertions(+)
 create mode 100644 drivers/regex/mlx5/mlx5_regex_fastpath.c

diff --git a/drivers/regex/mlx5/Makefile b/drivers/regex/mlx5/Makefile
index 3d3fc5d..79bc0b8 100644
--- a/drivers/regex/mlx5/Makefile
+++ b/drivers/regex/mlx5/Makefile
@@ -10,6 +10,7 @@ LIB = librte_pmd_mlx5_regex.a
 SRCS-$(CONFIG_RTE_LIBRTE_MLX5_REGEX_PMD) += mlx5_regex.c
 SRCS-$(CONFIG_RTE_LIBRTE_MLX5_REGEX_PMD) += mlx5_rxp.c
 SRCS-$(CONFIG_RTE_LIBRTE_MLX5_REGEX_PMD) += mlx5_regex_control.c
+SRCS-$(CONFIG_RTE_LIBRTE_MLX5_REGEX_PMD) += mlx5_regex_fastpath.c
 
 # Basic CFLAGS.
 CFLAGS += -O3
diff --git a/drivers/regex/mlx5/meson.build b/drivers/regex/mlx5/meson.build
index c7406fe..a459f78 100644
--- a/drivers/regex/mlx5/meson.build
+++ b/drivers/regex/mlx5/meson.build
@@ -13,6 +13,7 @@ sources = files(
'mlx5_regex.c',
'mlx5_rxp.c',
'mlx5_regex_control.c',
+   'mlx5_regex_fastpath.c',
 )
 cflags_options = [
'-std=c11',
diff --git a/drivers/regex/mlx5/mlx5_regex.h b/drivers/regex/mlx5/mlx5_regex.h
index 12033e8..cf8863f 100644
--- a/drivers/regex/mlx5/mlx5_regex.h
+++ b/drivers/regex/mlx5/mlx5_regex.h
@@ -44,6 +44,11 @@ struct mlx5_regex_qp {
struct mlx5_regex_sq *sqs; /* Pointer to sq array. */
uint16_t nb_obj; /* Number of sq objects. */
struct mlx5_regex_cq cq; /* CQ struct. */
+   uint32_t free_sqs;
+   struct mlx5_regex_job *jobs;
+   struct ibv_mr *metadata;
+   struct ibv_mr *inputs;
+   struct ibv_mr *outputs;
 };
 
 struct mlx5_regex_db {
@@ -83,4 +88,7 @@ int mlx5_regex_qp_setup(struct rte_regexdev *dev, uint16_t 
qp_ind,
const struct rte_regexdev_qp_conf *cfg);
 int mlx5_regex_rules_db_import(struct rte_regexdev *dev,
 const char *rule_db, uint32_t rule_db_len);
+
+/* mlx5_regex_fastpath.c */
+int mlx5_regexdev_setup_fastpath(struct mlx5_regex_priv *priv, uint32_t qp_id);
 #endif /* MLX5_REGEX_H */
diff --git a/drivers/regex/mlx5/mlx5_regex_control.c 
b/drivers/regex/mlx5/mlx5_regex_control.c
index d378f48..9b3f39e 100644
--- a/drivers/regex/mlx5/mlx5_regex_control.c
+++ b/drivers/regex/mlx5/mlx5_regex_control.c
@@ -352,6 +352,8 @@
goto error;
}
}
+
+   mlx5_regexdev_setup_fastpath(priv, qp_ind);
return 0;
 
 error:
diff --git a/drivers/regex/mlx5/mlx5_regex_fastpath.c 
b/drivers/regex/mlx5/mlx5_regex_fastpath.c
new file mode 100644
index 000..b5147ce
--- /dev/null
+++ b/drivers/regex/mlx5/mlx5_regex_fastpath.c
@@ -0,0 +1,198 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2020 Mellanox Technologies, Ltd
+ */
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "mlx5_regex_utils.h"
+#include "mlx5_rxp.h"
+#include "mlx5_regex.h"
+
+/* Verbs header. */
+/* ISO C doesn't support unnamed structs/unions, disabling -pedantic. */
+#ifdef PEDANTIC
+#pragma GCC diagnostic ignored "-Wpedantic"
+#endif
+#include 
+#ifdef PEDANTIC
+#pragma GCC diagnostic error "-Wpedantic"
+#endif
+
+#define MAX_WQE_INDEX 0x
+#define MLX5_REGEX_METADATA_SIZE 64
+#define MLX5_REGEX_MAX_INPUT (1<<14)
+#define MLX5_REGEX_MAX_OUTPUT (1<<11)
+
+
+static inline uint32_t
+sq_size_get(struct mlx5_regex_sq *sq)
+{
+   return (1U << sq->log_nb_desc);
+}
+static inline uint32_t
+cq_size_get(struct mlx5_regex_cq *cq)
+{
+   return (1U << cq->log_nb_desc);
+}
+
+struct mlx5_regex_job {
+   uint64_t user_id;
+   uint8_t *input;
+   volatile uint8_t *output;
+   volatile uint8_t *metadata;
+} __rte_cached_aligned;
+
+static inline void
+set_data_seg(struct mlx5_wqe_data_seg *seg,
+uint32_t length, uint32_t lkey,
+uintptr_t address)
+{
+   seg->byte_count = rte_cpu_to_be_32(length);
+   seg->lkey = rte_cpu_to_be_32(lkey);
+   seg->addr = rte_cpu_to_be_64(address);
+}
+
+static inline void
+set_metadata_seg(struct mlx5_wqe_metadata_seg *seg,
+uint32_t mmo_control_31_0, uint32_t lkey,
+uintptr_t address)
+{
+   seg->mmo_control_31_0 = htobe32(mmo_control_31_0);
+   seg->lkey = rte_cpu_to_be_32(lkey);
+   seg->addr = rte_cpu_to_be_64(address);
+}
+
+static void
+setup_sqs(struct mlx5_regex_qp *queue)
+{
+   size_t sqid, entry;
+   uint32_t job_id;
+   for (sqid = 0; sqid < queue->nb_obj; sqid++) {
+   struct mlx5_regex_sq *sq = &queue->sqs[sqid];
+   uint8_t *wqe = (uint8_t *)sq->wqe;
+

Re: [dpdk-dev] [PATCH 1/3] examples/fips_validation: fix TDES interim callback

02/07/2020 20:53, Akhil Goyal:
> Hi Marko/Fan,
> 
> Could you please review this series?

What happens? Nobody to review this?

> > Subject: [PATCH 1/3] examples/fips_validation: fix TDES interim callback
> > 
> > Fix missing callback registration and the incorrect
> > callback definition for interim NK_STR. The callback
> > should compare input key against the interim.
> > 
> > Fixes: 527cbf3d5ee3 ("examples/fips_validation: support TDES parsing")
> > 
> > Signed-off-by: Archana Muniganti

Re: [dpdk-dev] [PATCH v6 1/2] rte_flow: add eCPRI key fields to flow API

12/07/2020 16:45, Olivier Matz:
> On Sun, Jul 12, 2020 at 09:35:02PM +0800, Bing Zhao wrote:
> > Add a new item "rte_flow_item_ecpri" in order to match eCRPI header.
> > 
> > eCPRI is a packet based protocol used in the fronthaul interface of
> > 5G networks. Header format definition could be found in the
> > specification via the link below:
> > https://www.gigalight.com/downloads/standards/ecpri-specification.pdf
> > 
> > eCPRI message can be over Ethernet layer (.1Q supported also) or over
> > UDP layer. Message header formats are the same in these two variants.
> > 
> > Signed-off-by: Bing Zhao 
> > Acked-by: Ori Kam 
> 
> Acked-by: Olivier Matz 
> 
> Thanks!

Glad to see this 5G feature is ready to be merged in last minute of 20.08-rc1.

Applied, thanks

[dpdk-dev] [dpdk-announce] release candidate 20.08-rc1

A new DPDK release candidate is ready for testing:
https://git.dpdk.org/dpdk/tag/?id=v20.08-rc1

There are 778 new patches in this snapshot.

Release notes:
https://doc.dpdk.org/guides/rel_notes/release_20_08.html

Highlights of 20.08-rc1, grouped by category:
* General
- external thread registration API
- bit operations API for drivers
- VFIO PF with VF token
* Networking
- eCPRI offload with flow API
- Tx scheduling offload
* Cryptography
- crypto-CRC chained operation for DOCSIS protocol
* RegEx
- new device class API for future RegEx drivers
* Tools
- testpmd 5-tuple swap for L2/L3/L4
- performance test application for flow rules
- l2fwd forwarding between asymmetric ports

We must complete this release cycle in the beginning of August.
DPDK 20.08-rc2 is expected in one week on July 20.

Please test and report issues on bugs.dpdk.org.

We should publish the roadmap for DPDK 20.11 now.

Thank you everyone

Re: [dpdk-dev] [PATCH v3] net/mlx5: relaxed ordering for multi-packet RQ buffer refcnt

Hi,

We are also doing C11 atomics converting for other components.
Your insight would be much appreciated.

Thanks,
Phil Yang

> -Original Message-
> From: dev  On Behalf Of Phil Yang
> Sent: Tuesday, June 23, 2020 4:27 PM
> To: dev@dpdk.org
> Cc: ma...@mellanox.com; shah...@mellanox.com;
> viachesl...@mellanox.com; Honnappa Nagarahalli
> ; d...@linux.vnet.ibm.com; nd
> 
> Subject: [dpdk-dev] [PATCH v3] net/mlx5: relaxed ordering for multi-packet
> RQ buffer refcnt
> 
> Use c11 atomics with explicit ordering instead of the rte_atomic ops
> which enforce unnecessary barriers on aarch64.
> 
> Signed-off-by: Phil Yang 
> ---
> v3:
> Split from the patchset:
> http://patchwork.dpdk.org/cover/68159/
> 
>  drivers/net/mlx5/mlx5_rxq.c  |  2 +-
>  drivers/net/mlx5/mlx5_rxtx.c | 16 +---
>  drivers/net/mlx5/mlx5_rxtx.h |  2 +-
>  3 files changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/net/mlx5/mlx5_rxq.c b/drivers/net/mlx5/mlx5_rxq.c
> index dda0073..7f487f1 100644
> --- a/drivers/net/mlx5/mlx5_rxq.c
> +++ b/drivers/net/mlx5/mlx5_rxq.c
> @@ -1545,7 +1545,7 @@ mlx5_mprq_buf_init(struct rte_mempool *mp,
> void *opaque_arg,
> 
>   memset(_m, 0, sizeof(*buf));
>   buf->mp = mp;
> - rte_atomic16_set(&buf->refcnt, 1);
> + __atomic_store_n(&buf->refcnt, 1, __ATOMIC_RELAXED);
>   for (j = 0; j != strd_n; ++j) {
>   shinfo = &buf->shinfos[j];
>   shinfo->free_cb = mlx5_mprq_buf_free_cb;
> diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
> index e4106bf..f0eda88 100644
> --- a/drivers/net/mlx5/mlx5_rxtx.c
> +++ b/drivers/net/mlx5/mlx5_rxtx.c
> @@ -1595,10 +1595,11 @@ mlx5_mprq_buf_free_cb(void *addr
> __rte_unused, void *opaque)
>  {
>   struct mlx5_mprq_buf *buf = opaque;
> 
> - if (rte_atomic16_read(&buf->refcnt) == 1) {
> + if (__atomic_load_n(&buf->refcnt, __ATOMIC_RELAXED) == 1) {
>   rte_mempool_put(buf->mp, buf);
> - } else if (rte_atomic16_add_return(&buf->refcnt, -1) == 0) {
> - rte_atomic16_set(&buf->refcnt, 1);
> + } else if (unlikely(__atomic_sub_fetch(&buf->refcnt, 1,
> +__ATOMIC_RELAXED) == 0)) {
> + __atomic_store_n(&buf->refcnt, 1, __ATOMIC_RELAXED);
>   rte_mempool_put(buf->mp, buf);
>   }
>  }
> @@ -1678,7 +1679,8 @@ mlx5_rx_burst_mprq(void *dpdk_rxq, struct
> rte_mbuf **pkts, uint16_t pkts_n)
> 
>   if (consumed_strd == strd_n) {
>   /* Replace WQE only if the buffer is still in use. */
> - if (rte_atomic16_read(&buf->refcnt) > 1) {
> + if (__atomic_load_n(&buf->refcnt,
> + __ATOMIC_RELAXED) > 1) {
>   mprq_buf_replace(rxq, rq_ci & wq_mask,
> strd_n);
>   /* Release the old buffer. */
>   mlx5_mprq_buf_free(buf);
> @@ -1790,9 +1792,9 @@ mlx5_rx_burst_mprq(void *dpdk_rxq, struct
> rte_mbuf **pkts, uint16_t pkts_n)
>   void *buf_addr;
> 
>   /* Increment the refcnt of the whole chunk. */
> - rte_atomic16_add_return(&buf->refcnt, 1);
> - MLX5_ASSERT((uint16_t)rte_atomic16_read(&buf-
> >refcnt) <=
> - strd_n + 1);
> + __atomic_add_fetch(&buf->refcnt, 1,
> __ATOMIC_ACQUIRE);
> + MLX5_ASSERT(__atomic_load_n(&buf->refcnt,
> + __ATOMIC_RELAXED) <= strd_n + 1);
>   buf_addr = RTE_PTR_SUB(addr,
> RTE_PKTMBUF_HEADROOM);
>   /*
>* MLX5 device doesn't use iova but it is necessary in
> a
> diff --git a/drivers/net/mlx5/mlx5_rxtx.h b/drivers/net/mlx5/mlx5_rxtx.h
> index 26621ff..0fc15f3 100644
> --- a/drivers/net/mlx5/mlx5_rxtx.h
> +++ b/drivers/net/mlx5/mlx5_rxtx.h
> @@ -78,7 +78,7 @@ struct rxq_zip {
>  /* Multi-Packet RQ buffer header. */
>  struct mlx5_mprq_buf {
>   struct rte_mempool *mp;
> - rte_atomic16_t refcnt; /* Atomically accessed refcnt. */
> + uint16_t refcnt; /* Atomically accessed refcnt. */
>   uint8_t pad[RTE_PKTMBUF_HEADROOM]; /* Headroom for the first
> packet. */
>   struct rte_mbuf_ext_shared_info shinfos[];
>   /*
> --
> 2.7.4

Re: [dpdk-dev] [PATCH v2 03/29] net/dpaa2: enable timestamp for Rx offload case as well

2020-07-12 Thread Hemant Agrawal



-Original Message-
From: Thomas Monjalon  
Sent: Saturday, July 11, 2020 7:16 PM
To: Gagandeep Singh ; Hemant Agrawal 
Cc: dev@dpdk.org; ferruh.yi...@intel.com
Subject: Re: [dpdk-dev] [PATCH v2 03/29] net/dpaa2: enable timestamp for Rx 
offload case as well
Importance: High

07/07/2020 11:22, Hemant Agrawal:
> From: Gagandeep Singh 
> 
> This patch enables the packet timestamping conditionally when Rx 
> offload is enabled for timestamp.
> 
> Signed-off-by: Gagandeep Singh 
> ---
>  drivers/net/dpaa2/dpaa2_ethdev.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/dpaa2/dpaa2_ethdev.c 
> b/drivers/net/dpaa2/dpaa2_ethdev.c
> index a1f19194d..8edd4b3cd 100644
> --- a/drivers/net/dpaa2/dpaa2_ethdev.c
> +++ b/drivers/net/dpaa2/dpaa2_ethdev.c
> @@ -524,8 +524,10 @@ dpaa2_eth_dev_configure(struct rte_eth_dev *dev)
>   return ret;
>   }
>  
> +#if !defined(RTE_LIBRTE_IEEE1588)
>   if (rx_offloads & DEV_RX_OFFLOAD_TIMESTAMP)
> - dpaa2_enable_ts = true;
> +#endif
> + dpaa2_enable_ts = true;

I don't understand this patch at all.
There is no comment in the code, and the commit log is not very explanatory.

You are lucky Ferruh is less strict than me.
I remember I already said I was bored of the lack of explanations in NXP 
drivers.

[Hemant] We will improve next time. 
The patch description says:  "> This patch enables the packet timestamping 
conditionally when Rx 
> offload is enabled for timestamp."
It should be improved with - Enable the timestamping by default when IEEE1588 
is enabled irrespective of offload flag.

Re: [dpdk-dev] [PATCH v2] app/procinfo: enhance port mempool and crypto info

2020-07-12 Thread Hemant Agrawal



-Original Message-
From: Stephen Hemminger  
Sent: Sunday, July 12, 2020 8:42 AM
To: Hemant Agrawal 
Cc: dev@dpdk.org; maryam.tah...@intel.com; reshma.pat...@intel.com
Subject: Re: [dpdk-dev] [PATCH v2] app/procinfo: enhance port mempool and 
crypto info
Importance: High

On Sat, 11 Jul 2020 15:23:43 +0530
Hemant Agrawal  wrote:

> This patch enhances the port info for more details about the port and 
> queues.
> This patch also add support to get info about the mempool ops and 
> security context for crypto devices.
> 
> Signed-off-by: Hemant Agrawal 

What ever happened to my procinfo patch series.


[Hemant] I will review and rebase my patch over your series. 
You could have informed me about it during v1 review.

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.dpdk.org%2Fpatch%2F69877%2F&data=02%7C01%7Chemant.agrawal%40nxp.com%7Cd616d57af9fc4dadc4d808d8261169c9%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637301203517775492&sdata=LZDTf1w%2B%2Bc%2BM%2BC4Ytkm2Ug6DTMCYPFartS%2FT6KwFtcQ%3D&reserved=0

Re: [dpdk-dev] [RFC] - Offloading tunnel ports

2020-07-12 Thread Oz Shlomo

Hi William,

On 7/12/2020 7:34 PM, William Tu wrote:

Hi Oz,

I started to learn about this and have a couple of questions below.
Thank you in advance.

On Tue, Jun 9, 2020 at 8:07 AM Oz Shlomo wrote:

Rte_flow API provides the building blocks for vendor agnostic flow
classification offloads. The rte_flow match and action primitives are fine
grained, thus enabling DPDK applications the flexibility to offload network
stacks and complex pipelines.

Applications wishing to offload complex data structures (e.g. tunnel virtual
ports) are required to use the rte_flow primitives, such as group, meta, mark,
tag and others to model their high level objects.

The hardware model design for high level software objects is not trivial.
Furthermore, an optimal design is often vendor specific.

The goal of this RFC is to provide applications with the hardware offload
model for common high level software objects which is optimal in regards
to the underlying hardware.

Tunnel ports are the first of such objects.

Tunnel ports

Ingress processing of tunneled traffic requires the classification
of the tunnel type followed by a decap action.

In software, once a packet is decapsulated the in_port field is changed
to a virtual port representing the tunnel type. The outer header fields
are stored as packet metadata members and may be matched by proceeding
flows.

Openvswitch, for example, uses two flows:
1. classification flow - setting the virtual port representing the tunnel type
For example: match on udp port 4789 actions=tnl_pop(vxlan_vport)
2. steering flow according to outer and inner header matches
match on in_port=vxlan_vport and outer/inner header matches actions=forward to
port X
The benefits of multi-flow tables are described in [1].

Offloading tunnel ports
---
Tunnel ports introduce a new stateless field that can be matched on.
Currently the rte_flow library provides an API to encap, decap and match
on tunnel headers. However, there is no rte_flow primitive to set and
match tunnel virtual ports.

There are several possible hardware models for offloading virtual tunnel port
flows including, but not limited to, the following:
1. Setting the virtual port on a hw register using the rte_flow_action_mark/
rte_flow_action_tag/rte_flow_set_meta objects.
2. Mapping a virtual port to an rte_flow group
3. Avoiding the need to match on transient objects by merging multi-table
flows to a single rte_flow rule.

Every approach has its pros and cons.
The preferred approach should take into account the entire system architecture
and is very often vendor specific.

Are these three solutions mutually exclusive?
And IIUC, based on the description below, you're proposing solution 1, right?
and the patch on OVS is using solution 2?
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.ozlabs.org%2Fproject%2Fopenvswitch%2Fcover%2F20200120150830.16262-1-elibr%40mellanox.com%2F&data=02%7C01%7Cozsh%40mellanox.com%7C4ece31d745d246e30f9308d8268185cb%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C637301685025981024&sdata=mPCFG468xYkHRX3HJRkrrDix4hfDLstAZtlILQfGxr8%3D&reserved=0

From the OVS patchset we learned that it might be better to provide each vendor
with the flexibility to implement its optimal hardware model.
We propose this design as an alternative to the submitted OVS patchset.

This patch is designed to provide an abstract API.
As such, any of the solutions listed above, or others, are possible.
The Mellanox PMD is planned to implemented solution 2.

The proposed rte_flow_tunnel_port_set helper function (drafted below) is
designed
to provide a common, vendor agnostic, API for setting the virtual port value.
The helper API enables PMD implementations to return vendor specific
combination of
rte_flow actions realizing the vendor's hardware model for setting a tunnel
port.
Applications may append the list of actions returned from the helper function
when
creating an rte_flow rule in hardware.

Similarly, the rte_flow_tunnel_port_match helper (drafted below) allows for
multiple hardware implementations to return a list of fte_flow items.

And if we're using solution 1 "Setting the virtual port on a hw
register using the rte_flow_action_mark/
rte_flow_action_tag/rte_flow_set_meta objects."
For the classification flow, does that mean HW no longer needs to
translate tnl_pop to mark + jump,
but the HW can directly execute the tnl_pop(vxlan_vport) action
because the outer header is
saved using rte_flow_set_meta?

In this case we would need to map the outer header fields to a unique id.
This can be done either from the datapath (for capable hardware) or from the
flows. The latter option, requires the flow to match on the outer header fields
that should be stored. OVS matches on the outer header fields only after it
classifies the tunnel port (i.e. after the tnl_pop action).

Miss handling
-
Packets going through multiple rte_flow groups are exposed to hw misse

[dpdk-dev] [Bug 503] can not detected device when use meson build dpdk

2020-07-12 Thread bugzilla

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

lihong (lihongx...@intel.com) changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #10 from lihong (lihongx...@intel.com) ---
dpdk master: 9d2b24593724a98d03f16c18c1e

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

[dpdk-dev] [PATCH v7 1/3] doc: add generic atomic deprecation section

Add deprecating the generic rte_atomic_xx APIs to C11 atomic built-ins
guide and examples.

Signed-off-by: Phil Yang 
Signed-off-by: Honnappa Nagarahalli 
---
 doc/guides/prog_guide/writing_efficient_code.rst | 64 +++-
 1 file changed, 63 insertions(+), 1 deletion(-)

diff --git a/doc/guides/prog_guide/writing_efficient_code.rst 
b/doc/guides/prog_guide/writing_efficient_code.rst
index 849f63e..16d6188 100644
--- a/doc/guides/prog_guide/writing_efficient_code.rst
+++ b/doc/guides/prog_guide/writing_efficient_code.rst
@@ -167,7 +167,13 @@ but with the added cost of lower throughput.
 Locks and Atomic Operations
 ---
 
-Atomic operations imply a lock prefix before the instruction,
+This section describes some key considerations when using locks and atomic
+operations in the DPDK environment.
+
+Locks
+~
+
+On x86, atomic operations imply a lock prefix before the instruction,
 causing the processor's LOCK# signal to be asserted during execution of the 
following instruction.
 This has a big impact on performance in a multicore environment.
 
@@ -176,6 +182,62 @@ It can often be replaced by other solutions like per-lcore 
variables.
 Also, some locking techniques are more efficient than others.
 For instance, the Read-Copy-Update (RCU) algorithm can frequently replace 
simple rwlocks.
 
+Atomic Operations: Use C11 Atomic Built-ins
+~~~
+
+DPDK generic rte_atomic operations are implemented by `__sync built-ins
+`_.
+These __sync built-ins result in full barriers on aarch64, which are 
unnecessary
+in many use cases. They can be replaced by `__atomic built-ins
+`_
+that conform to the C11 memory model and provide finer memory order control.
+
+So replacing the rte_atomic operations with __atomic built-ins might improve
+performance for aarch64 machines.
+
+Some typical optimization cases are listed below:
+
+Atomicity
+^
+
+Some use cases require atomicity alone, the ordering of the memory operations
+does not matter. For example the packets statistics in ``virtio_xmit()``
+function of ``vhost`` example application. It just updates the number of
+transmitted packets, no subsequent logic depends on these counters. So the
+RELAXED memory ordering is sufficient.
+
+One-way Barrier
+^^^
+
+Some use cases allow for memory reordering in one way while requiring memory
+ordering in the other direction.
+
+For example, the memory operations before the ``rte_spinlock_lock()`` can move
+to the critical section, but the memory operations in the critical section
+cannot move above the lock. In this case, the full memory barrier in the
+compare-and-swap operation can be replaced to ACQUIRE. On the other hand, the
+memory operations after the ``rte_spinlock_unlock()`` can move to the critical
+section, but the memory operations in the critical section cannot move below
+the unlock. So the full barrier in the STORE operation can be replaced with
+RELEASE.
+
+Reader-Writer Concurrency
+^
+
+Lock-free reader-writer concurrency is one of the common use cases in DPDK.
+
+The payload or the data that the writer wants to communicate to the reader,
+can be written with RELAXED memory order. However, the guard variable should
+be written with RELEASE memory order. This ensures that the store to guard
+variable is observable only after the store to payload is observable.
+Refer to ``rte_hash_cuckoo_insert_mw()`` for an example.
+
+Correspondingly, on the reader side, the guard variable should be read
+with ACQUIRE memory order. The payload or the data the writer communicated,
+can be read with RELAXED memory order. This ensures that, if the store to
+guard variable is observable, the store to payload is also observable.
+Refer to rte_hash ``search_one_bucket_lf()`` for an example.
+
 Coding Considerations
 -
 
-- 
2.7.4

[dpdk-dev] [PATCH v7 3/3] eal/atomic: add wrapper for C11 atomic thread fence

Provide a wrapper for __atomic_thread_fence built-in to support
optimized code for __ATOMIC_SEQ_CST memory order for x86 platforms.

Suggested-by: Honnappa Nagarahalli 
Signed-off-by: Phil Yang 
Reviewed-by: Ola Liljedahl 
Acked-by: Konstantin Ananyev 
---
 lib/librte_eal/arm/include/rte_atomic_32.h  |  6 ++
 lib/librte_eal/arm/include/rte_atomic_64.h  |  6 ++
 lib/librte_eal/include/generic/rte_atomic.h |  6 ++
 lib/librte_eal/ppc/include/rte_atomic.h |  6 ++
 lib/librte_eal/x86/include/rte_atomic.h | 17 +
 5 files changed, 41 insertions(+)

diff --git a/lib/librte_eal/arm/include/rte_atomic_32.h 
b/lib/librte_eal/arm/include/rte_atomic_32.h
index 7dc0d06..dbe7cc6 100644
--- a/lib/librte_eal/arm/include/rte_atomic_32.h
+++ b/lib/librte_eal/arm/include/rte_atomic_32.h
@@ -37,6 +37,12 @@ extern "C" {
 
 #define rte_cio_rmb() rte_rmb()
 
+static __rte_always_inline void
+rte_atomic_thread_fence(int mo)
+{
+   __atomic_thread_fence(mo);
+}
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/lib/librte_eal/arm/include/rte_atomic_64.h 
b/lib/librte_eal/arm/include/rte_atomic_64.h
index e42f69e..bf885ad 100644
--- a/lib/librte_eal/arm/include/rte_atomic_64.h
+++ b/lib/librte_eal/arm/include/rte_atomic_64.h
@@ -41,6 +41,12 @@ extern "C" {
 
 #define rte_cio_rmb() rte_rmb()
 
+static __rte_always_inline void
+rte_atomic_thread_fence(int mo)
+{
+   __atomic_thread_fence(mo);
+}
+
 /* 128 bit atomic operations 
-*/
 
 #if defined(__ARM_FEATURE_ATOMICS) || defined(RTE_ARM_FEATURE_ATOMICS)
diff --git a/lib/librte_eal/include/generic/rte_atomic.h 
b/lib/librte_eal/include/generic/rte_atomic.h
index e6ab15a..5b941db 100644
--- a/lib/librte_eal/include/generic/rte_atomic.h
+++ b/lib/librte_eal/include/generic/rte_atomic.h
@@ -158,6 +158,12 @@ static inline void rte_cio_rmb(void);
asm volatile ("" : : : "memory");   \
 } while(0)
 
+/**
+ * Synchronization fence between threads based on the specified
+ * memory order.
+ */
+static inline void rte_atomic_thread_fence(int mo);
+
 /*- 16 bit atomic operations 
-*/
 
 /**
diff --git a/lib/librte_eal/ppc/include/rte_atomic.h 
b/lib/librte_eal/ppc/include/rte_atomic.h
index 7e3e131..91c5f30 100644
--- a/lib/librte_eal/ppc/include/rte_atomic.h
+++ b/lib/librte_eal/ppc/include/rte_atomic.h
@@ -40,6 +40,12 @@ extern "C" {
 
 #define rte_cio_rmb() rte_rmb()
 
+static __rte_always_inline void
+rte_atomic_thread_fence(int mo)
+{
+   __atomic_thread_fence(mo);
+}
+
 /*- 16 bit atomic operations 
-*/
 /* To be compatible with Power7, use GCC built-in functions for 16 bit
  * operations */
diff --git a/lib/librte_eal/x86/include/rte_atomic.h 
b/lib/librte_eal/x86/include/rte_atomic.h
index b9dcd30..bd256e7 100644
--- a/lib/librte_eal/x86/include/rte_atomic.h
+++ b/lib/librte_eal/x86/include/rte_atomic.h
@@ -83,6 +83,23 @@ rte_smp_mb(void)
 
 #define rte_cio_rmb() rte_compiler_barrier()
 
+/**
+ * Synchronization fence between threads based on the specified
+ * memory order.
+ *
+ * On x86 the __atomic_thread_fence(__ATOMIC_SEQ_CST) generates
+ * full 'mfence' which is quite expensive. The optimized
+ * implementation of rte_smp_mb is used instead.
+ */
+static __rte_always_inline void
+rte_atomic_thread_fence(int mo)
+{
+   if (mo == __ATOMIC_SEQ_CST)
+   rte_smp_mb();
+   else
+   __atomic_thread_fence(mo);
+}
+
 /*- 16 bit atomic operations 
-*/
 
 #ifndef RTE_FORCE_INTRINSICS
-- 
2.7.4

[dpdk-dev] [PATCH v7 0/3] generic rte atomic APIs deprecate proposal

DPDK provides generic rte_atomic APIs to do several atomic operations.
These APIs are using the deprecated __sync built-ins and enforce full
memory barriers on aarch64. However, full barriers are not necessary
in many use cases. In order to address such use cases, C language offers
C11 atomic APIs. The C11 atomic APIs provide finer memory barrier control
by making use of the memory ordering parameter provided by the user.
Various patches submitted in the past [2] and the patches in this series
indicate significant performance gains on multiple aarch64 CPUs and no
performance loss on x86.

But the existing rte_atomic API implementations cannot be changed as the
APIs do not take the memory ordering parameter. The only choice available
is replacing the usage of the rte_atomic APIs with C11 atomic APIs. In
order to make this change, the following steps are proposed:

[1] deprecate rte_atomic APIs so that future patches do not use rte_atomic
APIs (a script is added to flag the usages).
[2] refactor the code that uses rte_atomic APIs to use c11 atomic APIs.

This patchset contains:
1) changes to programmer guide describing writing efficient code for aarch64.
2) the checkpatch script changes to flag rte_atomicNN_xxx API usage in patches.
3) wraps up __atomic_thread_fence with explicit memory ordering parameter.

v7:
1. Remove code blocks in the guidance.
2. Remove code reference links in the guidance.
3. Remove the update of C11 atomics maintainers.

v6:
Add check for rte_smp barriers APIs in the new code.

v5:
1. Wraps up __atomic_thread_fence to support optimized code for
__ATOMIC_SEQ_CST memory order.
2. Flag __atomic_thread_fence with __ATOMIC_SEQ_CST in new patches.
3. Fix email address typo in patch 2/4.

v4:
1. add reader-writer concurrency case describing.
2. claim maintainership of c11 atomics code for each platforms.
3. flag rte_atomicNN_xxx in new patches for modules that have been converted to
c11 style.
4. flag __sync_xxx built-ins in new patches.
5. wraps up compiler atomic built-ins
6. move the changes of libraries which make use of c11 atomic APIs out of this
patchset.

v3:
add libatomic dependency for 32-bit clang

v2:
1. fix Clang '-Wincompatible-pointer-types' WARNING.
2. fix typos.

Phil Yang (3):
  doc: add generic atomic deprecation section
  devtools: prevent use of rte atomic APIs in future patches
  eal/atomic: add wrapper for C11 atomic thread fence

 devtools/checkpatches.sh | 40 +++
 doc/guides/prog_guide/writing_efficient_code.rst | 64 +++-
 lib/librte_eal/arm/include/rte_atomic_32.h   |  6 +++
 lib/librte_eal/arm/include/rte_atomic_64.h   |  6 +++
 lib/librte_eal/include/generic/rte_atomic.h  |  6 +++
 lib/librte_eal/ppc/include/rte_atomic.h  |  6 +++
 lib/librte_eal/x86/include/rte_atomic.h  | 17 +++
 7 files changed, 144 insertions(+), 1 deletion(-)

-- 
2.7.4

[dpdk-dev] [PATCH v7 2/3] devtools: prevent use of rte atomic APIs in future patches

In order to deprecate the rte_atomic and rte_smp barrier APIs, prevent
the patches from using these APIs in the converted modules and compilers
__sync built-ins in all modules.

The converted modules:
lib/librte_distributor
lib/librte_hash
lib/librte_kni
lib/librte_lpm
lib/librte_rcu
lib/librte_ring
lib/librte_stack
lib/librte_vhost
lib/librte_timer
lib/librte_ipsec
drivers/event/octeontx
drivers/event/octeontx2
drivers/event/opdl
drivers/net/bnx2x
drivers/net/hinic
drivers/net/hns3
drivers/net/memif
drivers/net/thunderx
drivers/net/virtio
examples/l2fwd-event

On x86 the __atomic_thread_fence(__ATOMIC_SEQ_CST) is quite expensive
for SMP case. Flag the new code which use __atomic_thread_fence API.

Signed-off-by: Phil Yang 
Reviewed-by: Ruifeng Wang 
---
 devtools/checkpatches.sh | 40 
 1 file changed, 40 insertions(+)

diff --git a/devtools/checkpatches.sh b/devtools/checkpatches.sh
index 58021aa..6d0452f 100755
--- a/devtools/checkpatches.sh
+++ b/devtools/checkpatches.sh
@@ -51,6 +51,13 @@ print_usage () {
 
 check_forbidden_additions() { # 
res=0
+   c11_atomics_dir="lib/librte_distributor lib/librte_hash lib/librte_kni
+lib/librte_lpm lib/librte_rcu lib/librte_ring
+lib/librte_stack lib/librte_vhost
+drivers/event/octeontx drivers/event/octeontx2
+drivers/event/opdl drivers/net/bnx2x drivers/net/hinic
+drivers/net/hns3 drivers/net/memif drivers/net/thunderx
+drivers/net/virtio examples/l2fwd-event"
 
# refrain from new additions of rte_panic() and rte_exit()
# multiple folders and expressions are separated by spaces
@@ -74,6 +81,39 @@ check_forbidden_additions() { # 
-v 
EXPRESSIONS='for[[:space:]]*\\((char|u?int|unsigned|s?size_t)' \
-v RET_ON_FAIL=1 \
-v MESSAGE='Declaring a variable inside for()' \
+
+   # refrain from new additions of 16/32/64 bits rte_atomic_xxx()
+   # multiple folders and expressions are separated by spaces
+   awk -v FOLDERS="$c11_atomics_dir" \
+   -v EXPRESSIONS="rte_atomic[0-9][0-9]_.*\\\(" \
+   -v RET_ON_FAIL=1 \
+   -v MESSAGE='Use of rte_atomicNN_xxx APIs not allowed, use 
__atomic_xxx built-ins' \
+   -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
+   "$1" || res=1
+
+   # refrain from new additions of rte_smp_XXmb()
+   # multiple folders and expressions are separated by spaces
+   awk -v FOLDERS="$c11_atomics_dir" \
+   -v EXPRESSIONS="rte_smp_(r|w)?mb\\\(" \
+   -v RET_ON_FAIL=1 \
+   -v MESSAGE='Use of rte_smp_r/wmb not allowed, use __atomic_xxx 
built-ins' \
+   -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
+   "$1" || res=1
+
+   # refrain from using compiler __sync built-ins
+   awk -v FOLDERS="lib drivers app examples" \
+   -v EXPRESSIONS="__sync_.*\\\(" \
+   -v RET_ON_FAIL=1 \
+   -v MESSAGE='Use of __sync_xxx built-ins not allowed, use 
__atomic_xxx built-ins' \
+   -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
+   "$1" || res=1
+
+   # refrain from using compiler __atomic_thread_fence()
+   # It should be avoided on x86 for SMP case.
+   awk -v FOLDERS="lib drivers app examples" \
+   -v EXPRESSIONS="__atomic_thread_fence\\\(" \
+   -v RET_ON_FAIL=1 \
+   -v MESSAGE='The __atomic_thread_fence is not allowed, use 
rte_atomic_thread_fence' \
-f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
"$1" || res=1
 
-- 
2.7.4

Re: [dpdk-dev] [PATCH v6 2/4] maintainers: claim maintainers of C11 atomics