DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] [PATCH v1 0/4] add RegEx class
@ 2020-03-29  6:47 Ori Kam
  2020-03-29  6:47 ` [dpdk-dev] [PATCH v1 1/4] regexdev: introduce regexdev subsystem Ori Kam
                   ` (8 more replies)
  0 siblings, 9 replies; 96+ messages in thread
From: Ori Kam @ 2020-03-29  6:47 UTC (permalink / raw)
  To: jerinj, xiang.w.wang
  Cc: dev, pbhagavatula, shahafs, hemant.agrawal, opher, alexr, dovrat,
	pkapoor, nipun.gupta, bruce.richardson, yang.a.hong, harry.chang,
	gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai, yuyingxia,
	fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc, jim,
	hongjun.ni, j.bromhead, deri, fc, arthur.su, thomas, orika

This patch set adds the RegEx class, which enables RegEx pattern
matching, both on HW/SW PMDs.

Example for applications that will benefit from this class:
* Next Generation Firewalls (NGFW)
* Deep Packet and Flow Inspection (DPI)
* Intrusion Prevention Systems (IPS)
* DDoS Mitigation
* Network Monitoring
* Data Loss Prevention (DLP)
* Smart NICs
* Grammar based content processing
* URL, spam and adware filtering
* Advanced auditing and policing of user/application security policies
* Financial data mining - parsing of streamed financial feeds
* Application recognition.
* Dmemory introspection.
* Natural Language Processing (NLP)
* Sentiment Analysis.
* Big data databse acceleration.
* Computational storage. 

This patch set is based on RFC[1]

This class should be merged only after there is at least
one PMD that implements it. Also the test application will
be added when the first PMD is added.



[1] https://patches.dpdk.org/patch/66501/

Jerin Jacob (1):
  regexdev: introduce regexdev subsystem

Ori Kam (3):
  regexdev: add regex core h file
  regexdev: add regexdev core functions
  regexdev: implement regex rte level functions

 config/common_base                           |    8 +
 config/meson.build                           |    1 +
 doc/api/doxy-api-index.md                    |    1 +
 doc/api/doxy-api.conf.in                     |    1 +
 doc/guides/prog_guide/index.rst              |    1 +
 doc/guides/prog_guide/regexdev_lib.rst       |  177 +++
 lib/Makefile                                 |    2 +
 lib/librte_regexdev/Makefile                 |   33 +
 lib/librte_regexdev/meson.build              |   10 +
 lib/librte_regexdev/rte_regexdev.c           |  376 +++++++
 lib/librte_regexdev/rte_regexdev.h           | 1482 ++++++++++++++++++++++++++
 lib/librte_regexdev/rte_regexdev_core.h      |  149 +++
 lib/librte_regexdev/rte_regexdev_driver.h    |   50 +
 lib/librte_regexdev/rte_regexdev_version.map |   26 +
 lib/meson.build                              |    3 +-
 meson_options.txt                            |    2 +
 16 files changed, 2321 insertions(+), 1 deletion(-)
 create mode 100644 doc/guides/prog_guide/regexdev_lib.rst
 create mode 100644 lib/librte_regexdev/Makefile
 create mode 100644 lib/librte_regexdev/meson.build
 create mode 100644 lib/librte_regexdev/rte_regexdev.c
 create mode 100644 lib/librte_regexdev/rte_regexdev.h
 create mode 100644 lib/librte_regexdev/rte_regexdev_core.h
 create mode 100644 lib/librte_regexdev/rte_regexdev_driver.h
 create mode 100644 lib/librte_regexdev/rte_regexdev_version.map

-- 
1.8.3.1


^ permalink raw reply	[flat|nested] 96+ messages in thread

* [dpdk-dev] [PATCH v1 1/4] regexdev: introduce regexdev subsystem
  2020-03-29  6:47 [dpdk-dev] [PATCH v1 0/4] add RegEx class Ori Kam
@ 2020-03-29  6:47 ` Ori Kam
  2020-04-04 15:04   ` [dpdk-dev] [EXT] " Pavan Nikhilesh Bhagavatula
  2020-03-29  6:47 ` [dpdk-dev] [PATCH v1 2/4] regexdev: add regex core h file Ori Kam
                   ` (7 subsequent siblings)
  8 siblings, 1 reply; 96+ messages in thread
From: Ori Kam @ 2020-03-29  6:47 UTC (permalink / raw)
  To: jerinj, xiang.w.wang
  Cc: dev, pbhagavatula, shahafs, hemant.agrawal, opher, alexr, dovrat,
	pkapoor, nipun.gupta, bruce.richardson, yang.a.hong, harry.chang,
	gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai, yuyingxia,
	fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc, jim,
	hongjun.ni, j.bromhead, deri, fc, arthur.su, thomas, orika

From: Jerin Jacob <jerinj@marvell.com>

As RegEx usage become more used by DPDK applications, for example:
* Next Generation Firewalls (NGFW)
* Deep Packet and Flow Inspection (DPI)
* Intrusion Prevention Systems (IPS)
* DDoS Mitigation
* Network Monitoring
* Data Loss Prevention (DLP)
* Smart NICs
* Grammar based content processing
* URL, spam and adware filtering
* Advanced auditing and policing of user/application security policies
* Financial data mining - parsing of streamed financial feeds
* Application recognition.
* Dmemory introspection.
* Natural Language Processing (NLP)
* Sentiment Analysis.
* Big data databse acceleration.
* Computational storage.

Number of PMD providers started to work on HW implementation,
along side with SW implementations.

This lib adds the support for those kind of devices.

The RegEx Device API is composed of two parts:
- The application-oriented RegEx API that includes functions to setup
  a RegEx device (configure it, setup its queue pairs and start it),
  update the rule database and so on.

- The driver-oriented RegEx API that exports a function allowing
  a RegEx poll Mode Driver (PMD) to simultaneously register itself as
  a RegEx device driver.

RegEx device components and definitions:

    +-----------------+
    |                 |
    |                 o---------+    rte_regexdev_[en|de]queue_burst()
    |   PCRE based    o------+  |               |
    |  RegEx pattern  |      |  |  +--------+   |
    | matching engine o------+--+--o        |   |    +------+
    |                 |      |  |  | queue  |<==o===>|Core 0|
    |                 o----+ |  |  | pair 0 |        |      |
    |                 |    | |  |  +--------+        +------+
    +-----------------+    | |  |
           ^               | |  |  +--------+
           |               | |  |  |        |        +------+
           |               | +--+--o queue  |<======>|Core 1|
       Rule|Database       |    |  | pair 1 |        |      |
    +------+----------+    |    |  +--------+        +------+
    |     Group 0     |    |    |
    | +-------------+ |    |    |  +--------+        +------+
    | | Rules 0..n  | |    |    |  |        |        |Core 2|
    | +-------------+ |    |    +--o queue  |<======>|      |
    |     Group 1     |    |       | pair 2 |        +------+
    | +-------------+ |    |       +--------+
    | | Rules 0..n  | |    |
    | +-------------+ |    |       +--------+
    |     Group 2     |    |       |        |        +------+
    | +-------------+ |    |       | queue  |<======>|Core n|
    | | Rules 0..n  | |    +-------o pair n |        |      |
    | +-------------+ |            +--------+        +------+
    |     Group n     |
    | +-------------+ |<-------rte_regexdev_rule_db_update()
    | |             | |<-------rte_regexdev_rule_db_compile_activate()
    | | Rules 0..n  | |<-------rte_regexdev_rule_db_import()
    | +-------------+ |------->rte_regexdev_rule_db_export()
    +-----------------+

RegEx: A regular expression is a concise and flexible means for matching
strings of text, such as particular characters, words, or patterns of
characters. A common abbreviation for this is â~@~\RegExâ~@~].

RegEx device: A hardware or software-based implementation of RegEx
device API for PCRE based pattern matching syntax and semantics.

PCRE RegEx syntax and semantics specification:
http://regexkit.sourceforge.net/Documentation/pcre/pcrepattern.html

RegEx queue pair: Each RegEx device should have one or more queue pair to
transmit a burst of pattern matching request and receive a burst of
receive the pattern matching response. The pattern matching
request/response embedded in *rte_regex_ops* structure.

Rule: A pattern matching rule expressed in PCRE RegEx syntax along with
Match ID and Group ID to identify the rule upon the match.

Rule database: The RegEx device accepts regular expressions and converts
them into a compiled rule database that can then be used to scan data.
Compilation allows the device to analyze the given pattern(s) and
pre-determine how to scan for these patterns in an optimized fashion that
would be far too expensive to compute at run-time. A rule database
contains a set of rules that compiled in device specific binary form.

Match ID or Rule ID: A unique identifier provided at the time of rule
creation for the application to identify the rule upon match.

Group ID: Group of rules can be grouped under one group ID to enable
rule isolation and effective pattern matching. A unique group identifier
provided at the time of rule creation for the application to identify
the rule upon match.

Scan: A pattern matching request through *enqueue* API.

It may possible that a given RegEx device may not support all the
features
of PCRE. The application may probe unsupported features through
struct rte_regexdev_info::pcre_unsup_flags

By default, all the functions of the RegEx Device API exported by a PMD
are lock-free functions which assume to not be invoked in parallel on
different logical cores to work on the same target object. For instance,
the dequeue function of a PMD cannot be invoked in parallel on two logical
cores to operates on same RegEx queue pair. Of course, this function
can be invoked in parallel by different logical core on different queue
pair. It is the responsibility of the upper level application to
enforce this rule.

In all functions of the RegEx API, the RegEx device is
designated by an integer >= 0 named the device identifier *dev_id*

At the RegEx driver level, RegEx devices are represented by a generic
data structure of type *rte_regexdev*.
RegEx devices are dynamically registered during the PCI/SoC device
probing phase performed at EAL initialization time.
When a RegEx device is being probed, a *rte_regexdev* structure and
a new device identifier are allocated for that device. Then, the
regexdev_init() function supplied by the RegEx driver matching the
probed device is invoked to properly initialize the device.

The role of the device init function consists of resetting the hardware
or software RegEx driver implementations.

If the device init operation is successful, the correspondence between
the device identifier assigned to the new device and its associated
*rte_regexdev* structure is effectively registered.
Otherwise, both the *rte_regexdev* structure and the device identifier
are freed.

The functions exported by the application RegEx API to setup a device
designated by its device identifier must be invoked in the following
order:
    - rte_regexdev_configure()
    - rte_regexdev_queue_pair_setup()
    - rte_regexdev_start()

Then, the application can invoke, in any order, the functions
exported by the RegEx API to enqueue pattern matching job, dequeue
pattern matching response, get the stats, update the rule database,
get/set device attributes and so on

If the application wants to change the configuration (i.e. call
rte_regexdev_configure() or rte_regexdev_queue_pair_setup()), it must
call rte_regexdev_stop() first to stop the device and then do the
reconfiguration before calling rte_regexdev_start() again. The enqueue and
dequeue functions should not be invoked when the device is stopped.

Finally, an application can close a RegEx device by invoking the
rte_regexdev_close() function.

Each function of the application RegEx API invokes a specific function
of the PMD that controls the target device designated by its device
identifier.

For this purpose, all device-specific functions of a RegEx driver are
supplied through a set of pointers contained in a generic structure of
type *regexdev_ops*.
The address of the *regexdev_ops* structure is stored in the
*rte_regexdev* structure by the device init function of the RegEx driver,
which is invoked during the PCI/SoC device probing phase, as explained
earlier.

In other words, each function of the RegEx API simply retrieves the
*rte_regexdev* structure associated with the device identifier and
performs an indirect invocation of the corresponding driver function
supplied in the *regexdev_ops* structure of the *rte_regexdev*
structure.

For performance reasons, the address of the fast-path functions of the
RegEx driver is not contained in the *regexdev_ops* structure.
Instead, they are directly stored at the beginning of the *rte_regexdev*
structure to avoid an extra indirect memory access during their
invocation.

RTE RegEx device drivers do not use interrupts for enqueue or dequeue
operation. Instead, RegEx drivers export Poll-Mode enqueue and dequeue
functions to applications.

The *enqueue* operation submits a burst of RegEx pattern matching
request to the RegEx device and the *dequeue* operation gets a burst of
pattern matching response for the ones submitted through *enqueue*
operation.

Typical application utilisation of the RegEx device API will follow the
following programming flow.

- rte_regexdev_configure()
- rte_regexdev_queue_pair_setup()
- rte_regexdev_rule_db_update() Needs to invoke if precompiled rule
  database not
  provided in rte_regexdev_config::rule_db for rte_regexdev_configure()
  and/or application needs to update rule database.
- rte_regexdev_rule_db_compile_activate() Needs to invoke if
  rte_regexdev_rule_db_update function was used.
- Create or reuse exiting mempool for *rte_regex_ops* objects.
- rte_regexdev_start()
- rte_regexdev_enqueue_burst()
- rte_regexdev_dequeue_burst()

Signed-off-by: Jerin Jacob <jerinj@marvell.com>
Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
Signed-off-by: Ori Kam <orika@mellanox.com>
---
 config/common_base                           |    7 +
 doc/api/doxy-api-index.md                    |    1 +
 doc/api/doxy-api.conf.in                     |    1 +
 doc/guides/prog_guide/index.rst              |    1 +
 doc/guides/prog_guide/regexdev_lib.rst       |  177 ++++
 lib/Makefile                                 |    2 +
 lib/librte_regexdev/Makefile                 |   31 +
 lib/librte_regexdev/meson.build              |    7 +
 lib/librte_regexdev/rte_regexdev.c           |    6 +
 lib/librte_regexdev/rte_regexdev.h           | 1473 ++++++++++++++++++++++++++
 lib/librte_regexdev/rte_regexdev_version.map |   26 +
 lib/meson.build                              |    3 +-
 12 files changed, 1734 insertions(+), 1 deletion(-)
 create mode 100644 doc/guides/prog_guide/regexdev_lib.rst
 create mode 100644 lib/librte_regexdev/Makefile
 create mode 100644 lib/librte_regexdev/meson.build
 create mode 100644 lib/librte_regexdev/rte_regexdev.c
 create mode 100644 lib/librte_regexdev/rte_regexdev.h
 create mode 100644 lib/librte_regexdev/rte_regexdev_version.map

diff --git a/config/common_base b/config/common_base
index c31175f..58c0865 100644
--- a/config/common_base
+++ b/config/common_base
@@ -819,6 +819,12 @@ CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_EP_RAWDEV=y
 CONFIG_RTE_LIBRTE_PMD_NTB_RAWDEV=y
 
 #
+# Compile regex device support
+#
+CONFIG_RTE_LIBRTE_REGEXDEV=y
+CONFIG_RTE_LIBRTE_REGEXDEV_DEBUG=n
+
+#
 # Compile librte_ring
 #
 CONFIG_RTE_LIBRTE_RING=y
@@ -1111,3 +1117,4 @@ CONFIG_RTE_APP_CRYPTO_PERF=y
 # Compile the eventdev application
 #
 CONFIG_RTE_APP_EVENTDEV=y
+
diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
index dff496b..787f7c2 100644
--- a/doc/api/doxy-api-index.md
+++ b/doc/api/doxy-api-index.md
@@ -26,6 +26,7 @@ The public API headers are grouped by topics:
   [event_timer_adapter]    (@ref rte_event_timer_adapter.h),
   [event_crypto_adapter]   (@ref rte_event_crypto_adapter.h),
   [rawdev]             (@ref rte_rawdev.h),
+  [regexdev]           (@ref rte_regexdev.h),
   [metrics]            (@ref rte_metrics.h),
   [bitrate]            (@ref rte_bitrate.h),
   [latency]            (@ref rte_latencystats.h),
diff --git a/doc/api/doxy-api.conf.in b/doc/api/doxy-api.conf.in
index 1c4392e..56c08eb 100644
--- a/doc/api/doxy-api.conf.in
+++ b/doc/api/doxy-api.conf.in
@@ -58,6 +58,7 @@ INPUT                   = @TOPDIR@/doc/api/doxy-api-index.md \
                           @TOPDIR@/lib/librte_rcu \
                           @TOPDIR@/lib/librte_reorder \
                           @TOPDIR@/lib/librte_rib \
+                          @TOPDIR@/lib/librte_regexdev \
                           @TOPDIR@/lib/librte_ring \
                           @TOPDIR@/lib/librte_sched \
                           @TOPDIR@/lib/librte_security \
diff --git a/doc/guides/prog_guide/index.rst b/doc/guides/prog_guide/index.rst
index fb250ab..11f3b60 100644
--- a/doc/guides/prog_guide/index.rst
+++ b/doc/guides/prog_guide/index.rst
@@ -70,3 +70,4 @@ Programmer's Guide
     lto
     profile_app
     glossary
+    regexdev_lib
diff --git a/doc/guides/prog_guide/regexdev_lib.rst b/doc/guides/prog_guide/regexdev_lib.rst
new file mode 100644
index 0000000..1ecbf1c
--- /dev/null
+++ b/doc/guides/prog_guide/regexdev_lib.rst
@@ -0,0 +1,177 @@
+..  SPDX-License-Identifier: BSD-3-Clause
+    Copyright(c) 2020 Mellanox Corporation.
+
+RegEx Device Library
+=====================
+
+The RegEx library provides a RegEx device framework for management and
+provisioning of hardware and software RegEx poll mode drivers, defining generic
+APIs which support a number of different RegEx operations.
+
+
+Design Principles
+-----------------
+
+The RegEx library follows the same basic principles as those used in DPDK's
+Ethernet Device framework and the Crypto framework. The RegEx framework provides
+a generic Crypto device framework which supports both physical (hardware)
+and virtual (software) RegEx devices as well as a generic RegEx API which allows
+RegEx devices to be managed and configured and supports RegEx operations to be
+provisioned on RegEx poll mode driver.
+
+
+Device Management
+-----------------
+
+Device Creation
+~~~~~~~~~~~~~~~
+
+Physical RegEx devices are discovered during the PCI probe/enumeration of the
+EAL function which is executed at DPDK initialization, based on
+their PCI device identifier, each unique PCI BDF (bus/bridge, device,
+function). Specific physical ReEx devices, like other physical devices in DPDK
+can be white-listed or black-listed using the EAL command line options.
+
+
+Device Identification
+~~~~~~~~~~~~~~~~~~~~~
+
+Each device, whether virtual or physical is uniquely designated by two
+identifiers:
+
+- A unique device index used to designate the RegEx device in all functions
+  exported by the regexdev API.
+
+- A device name used to designate the RegEx device in console messages, for
+  administration or debugging purposes.
+
+
+Device Configuration
+~~~~~~~~~~~~~~~~~~~~
+
+The configuration of each RegEx device includes the following operations:
+
+- Allocation of resources, including hardware resources if a physical device.
+- Resetting the device into a well-known default state.
+- Initialization of statistics counters.
+
+The rte_regexdev_configure API is used to configure a RegEx device.
+
+.. code-block:: c
+
+   int rte_regexdev_configure(uint8_t dev_id,
+                              const struct rte_regexdev_config *cfg);
+
+The ``rte_regexdev_config`` structure is used to pass the configuration
+parameters for the RegEx device for example  number of queue pairs, number of
+groups, max number of matches and so on.
+
+.. code-block:: c
+
+   struct rte_regexdev_config {
+        uint16_t nb_max_matches;
+        /**< Maximum matches per scan configured on this device.
+         * This value cannot exceed the *max_matches*
+         * which previously provided in rte_regexdev_info_get().
+         * The value 0 is allowed, in which case, value 1 used.
+         * @see struct rte_regexdev_info::max_matches
+         */
+        uint16_t nb_queue_pairs;
+        /**< Number of RegEx queue pairs to configure on this device.
+         * This value cannot exceed the *max_queue_pairs* which previously
+         * provided in rte_regexdev_info_get().
+         * @see struct rte_regexdev_info::max_queue_pairs
+         */
+        uint32_t nb_rules_per_group;
+        /**< Number of rules per group to configure on this device.
+         * This value cannot exceed the *max_rules_per_group*
+         * which previously provided in rte_regexdev_info_get().
+         * The value 0 is allowed, in which case,
+         * struct rte_regexdev_info::max_rules_per_group used.
+         * @see struct rte_regexdev_info::max_rules_per_group
+         */
+        uint16_t nb_groups;
+        /**< Number of groups to configure on this device.
+         * This value cannot exceed the *max_groups*
+         * which previously provided in rte_regexdev_info_get().
+         * @see struct rte_regexdev_info::max_groups
+         */
+        const char *rule_db;
+        /**< Import initial set of prebuilt rule database on this device.
+         * The value NULL is allowed, in which case, the device will not
+         * be configured prebuilt rule database. Application may use
+         * rte_regexdev_rule_db_update() or rte_regexdev_rule_db_import() API
+         * to update or import rule database after the
+         * rte_regexdev_configure().
+         * @see rte_regexdev_rule_db_update(), rte_regexdev_rule_db_import()
+         */
+        uint32_t rule_db_len;
+        /**< Length of *rule_db* buffer. */
+        uint32_t dev_cfg_flags;
+        /**< RegEx device configuration flags, See RTE_REGEXDEV_CFG_*  */
+    };
+
+
+Configuration of Rules Database
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Each Regex device should be configured with the rule database.
+There are two modes of setting the rule database, online or offline.
+The online mode means, that the rule database in being compiled by the
+RegEx PMD while in the offline mode the rule database is compiled by external
+compiler, and is being loaded to the PMD as a buffer.
+The configuration mode is depended on the PMD capabilities.
+
+Online rule configuration is done using the following API functions:
+``rte_regexdev_rule_db_update`` which add / remove rules from the rules
+precomplied list, and ``rte_regexdev_rule_db_compile_activate``
+which compile the rules and loads them to the RegEx HW.
+
+Offline rule configuration can be done by adding a pointer to the compiled
+rule database in the configuration step, or by using
+``rte_regexdev_rule_db_import`` API.
+
+
+Configuration of Queue Pairs
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Each RegEx device can be configured with number of queue pairs.
+Each queue pair is configured using ``rte_regexdev_queue_pair_setup``
+
+
+Logical Cores, Memory and Queues Pair Relationships
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Multiple logical cores should never share the same queue pair for enqueuing
+operations or dequeuing operations on the same RegEx device since this would
+require global locks and hinder performance.
+
+
+Device Features and Capabilities
+---------------------------------
+
+RegEx devices may support different feature set.
+In order to get the supported PMD feature ``rte_regexdev_info_get``
+API which return the info of the device and it's supported features.
+
+
+Enqueue / Dequeue Burst APIs
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The burst enqueue API uses a RegEx device identifier and a queue pair
+identifier to specify the device queue pair to schedule the processing on.
+The ``nb_ops`` parameter is the number of operations to process which are
+supplied in the ``ops`` array of ``rte_regex_ops`` structures.
+The enqueue function returns the number of operations it actually enqueued for
+processing, a return value equal to ``nb_ops`` means that all packets have been
+enqueued.
+
+Data pointed in each op, should not be released until the dequeue of for that
+op.
+
+The dequeue API uses the same format as the enqueue API of processed but
+the ``nb_ops`` and ``ops`` parameters are now used to specify the max processed
+operations the user wishes to retrieve and the location in which to store them.
+The API call returns the actual number of processed operations returned, this
+can never be larger than ``nb_ops``.
+
diff --git a/lib/Makefile b/lib/Makefile
index 46b91ae..a273564 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -44,6 +44,8 @@ DEPDIRS-librte_eventdev := librte_eal librte_ring librte_ethdev librte_hash \
                            librte_mempool librte_timer librte_cryptodev
 DIRS-$(CONFIG_RTE_LIBRTE_RAWDEV) += librte_rawdev
 DEPDIRS-librte_rawdev := librte_eal librte_ethdev
+DIRS-$(CONFIG_RTE_LIBRTE_REGEXDEV) += librte_regexdev
+DEPDIRS-librte_regexdev := librte_eal librte_mbuf
 DIRS-$(CONFIG_RTE_LIBRTE_VHOST) += librte_vhost
 DEPDIRS-librte_vhost := librte_eal librte_mempool librte_mbuf librte_ethdev \
 			librte_net librte_hash librte_cryptodev
diff --git a/lib/librte_regexdev/Makefile b/lib/librte_regexdev/Makefile
new file mode 100644
index 0000000..6f4cc63
--- /dev/null
+++ b/lib/librte_regexdev/Makefile
@@ -0,0 +1,31 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(C) 2019 Marvell International Ltd.
+# Copyright(C) 2020 Mellanox International Ltd.
+#
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+# library name
+LIB = librte_regexdev.a
+
+EXPORT_MAP := rte_regex_version.map
+
+# library version
+LIBABIVER := 1
+
+# build flags
+CFLAGS += -O3
+CFLAGS += $(WERROR_FLAGS)
+LDLIBS += -lrte_eal -lrte_mbuf
+
+# library source files
+# all source are stored in SRCS-y
+SRCS-$(CONFIG_RTE_LIBRTE_REGEXDEV) := rte_regexdev.c
+
+# export include files
+SYMLINK-$(CONFIG_RTE_LIBRTE_REGEXDEV)-include += rte_regexdev.h
+
+# versioning export map
+EXPORT_MAP := rte_regexdev_version.map
+
+include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_regexdev/meson.build b/lib/librte_regexdev/meson.build
new file mode 100644
index 0000000..f4db748
--- /dev/null
+++ b/lib/librte_regexdev/meson.build
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2020 Mellanox Corporation
+
+allow_experimental_apis = true
+sources = files('rte_regexdev.c')
+headers = files('rte_regexdev.h')
+deps += ['mbuf']
diff --git a/lib/librte_regexdev/rte_regexdev.c b/lib/librte_regexdev/rte_regexdev.c
new file mode 100644
index 0000000..b901877
--- /dev/null
+++ b/lib/librte_regexdev/rte_regexdev.c
@@ -0,0 +1,6 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2019 Marvell International Ltd.
+ * Copyright(C) 2020 Mellanox International Ltd.
+ */
+
+#include <rte_regexdev.h>
diff --git a/lib/librte_regexdev/rte_regexdev.h b/lib/librte_regexdev/rte_regexdev.h
new file mode 100644
index 0000000..7e688d9
--- /dev/null
+++ b/lib/librte_regexdev/rte_regexdev.h
@@ -0,0 +1,1473 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2019 Marvell International Ltd.
+ * Copyright(C) 2020 Mellanox International Ltd.
+ * Copyright(C) 2020 Intel International Ltd.
+ */
+
+#ifndef _RTE_REGEXDEV_H_
+#define _RTE_REGEXDEV_H_
+
+/**
+ * @file
+ *
+ * RTE RegEx Device API
+ *
+ * Defines RTE RegEx Device APIs for RegEx operations and its provisioning.
+ *
+ * The RegEx Device API is composed of two parts:
+ *
+ * - The application-oriented RegEx API that includes functions to setup
+ *   a RegEx device (configure it, setup its queue pairs and start it),
+ *   update the rule database and so on.
+ *
+ * - The driver-oriented RegEx API that exports a function allowing
+ *   a RegEx poll Mode Driver (PMD) to simultaneously register itself as
+ *   a RegEx device driver.
+ *
+ * RegEx device components and definitions:
+ *
+ *     +-----------------+
+ *     |                 |
+ *     |                 o---------+    rte_regexdev_[en|de]queue_burst()
+ *     |   PCRE based    o------+  |               |
+ *     |  RegEx pattern  |      |  |  +--------+   |
+ *     | matching engine o------+--+--o        |   |    +------+
+ *     |                 |      |  |  | queue  |<==o===>|Core 0|
+ *     |                 o----+ |  |  | pair 0 |        |      |
+ *     |                 |    | |  |  +--------+        +------+
+ *     +-----------------+    | |  |
+ *            ^               | |  |  +--------+
+ *            |               | |  |  |        |        +------+
+ *            |               | +--+--o queue  |<======>|Core 1|
+ *        Rule|Database       |    |  | pair 1 |        |      |
+ *     +------+----------+    |    |  +--------+        +------+
+ *     |     Group 0     |    |    |
+ *     | +-------------+ |    |    |  +--------+        +------+
+ *     | | Rules 0..n  | |    |    |  |        |        |Core 2|
+ *     | +-------------+ |    |    +--o queue  |<======>|      |
+ *     |     Group 1     |    |       | pair 2 |        +------+
+ *     | +-------------+ |    |       +--------+
+ *     | | Rules 0..n  | |    |
+ *     | +-------------+ |    |       +--------+
+ *     |     Group 2     |    |       |        |        +------+
+ *     | +-------------+ |    |       | queue  |<======>|Core n|
+ *     | | Rules 0..n  | |    +-------o pair n |        |      |
+ *     | +-------------+ |            +--------+        +------+
+ *     |     Group n     |
+ *     | +-------------+ |<-------rte_regexdev_rule_db_update()
+ *     | |             | |<-------rte_regexdev_rule_db_compile_activate()
+ *     | | Rules 0..n  | |<-------rte_regexdev_rule_db_import()
+ *     | +-------------+ |------->rte_regexdev_rule_db_export()
+ *     +-----------------+
+ *
+ * RegEx: A regular expression is a concise and flexible means for matching
+ * strings of text, such as particular characters, words, or patterns of
+ * characters. A common abbreviation for this is “RegEx”.
+ *
+ * RegEx device: A hardware or software-based implementation of RegEx
+ * device API for PCRE based pattern matching syntax and semantics.
+ *
+ * PCRE RegEx syntax and semantics specification:
+ * http://regexkit.sourceforge.net/Documentation/pcre/pcrepattern.html
+ *
+ * RegEx queue pair: Each RegEx device should have one or more queue pair to
+ * transmit a burst of pattern matching request and receive a burst of
+ * receive the pattern matching response. The pattern matching request/response
+ * embedded in *rte_regex_ops* structure.
+ *
+ * Rule: A pattern matching rule expressed in PCRE RegEx syntax along with
+ * Match ID and Group ID to identify the rule upon the match.
+ *
+ * Rule database: The RegEx device accepts regular expressions and converts them
+ * into a compiled rule database that can then be used to scan data.
+ * Compilation allows the device to analyze the given pattern(s) and
+ * pre-determine how to scan for these patterns in an optimized fashion that
+ * would be far too expensive to compute at run-time. A rule database contains
+ * a set of rules that compiled in device specific binary form.
+ *
+ * Match ID or Rule ID: A unique identifier provided at the time of rule
+ * creation for the application to identify the rule upon match.
+ *
+ * Group ID: Group of rules can be grouped under one group ID to enable
+ * rule isolation and effective pattern matching. A unique group identifier
+ * provided at the time of rule creation for the application to identify the
+ * rule upon match.
+ *
+ * Scan: A pattern matching request through *enqueue* API.
+ *
+ * It may possible that a given RegEx device may not support all the features
+ * of PCRE. The application may probe unsupported features through
+ * struct rte_regexdev_info::pcre_unsup_flags
+ *
+ * By default, all the functions of the RegEx Device API exported by a PMD
+ * are lock-free functions which assume to not be invoked in parallel on
+ * different logical cores to work on the same target object. For instance,
+ * the dequeue function of a PMD cannot be invoked in parallel on two logical
+ * cores to operates on same RegEx queue pair. Of course, this function
+ * can be invoked in parallel by different logical core on different queue pair.
+ * It is the responsibility of the upper level application to enforce this rule.
+ *
+ * In all functions of the RegEx API, the RegEx device is
+ * designated by an integer >= 0 named the device identifier *dev_id*
+ *
+ * At the RegEx driver level, RegEx devices are represented by a generic
+ * data structure of type *rte_regexdev*.
+ *
+ * RegEx devices are dynamically registered during the PCI/SoC device probing
+ * phase performed at EAL initialization time.
+ * When a RegEx device is being probed, a *rte_regexdev* structure and
+ * a new device identifier are allocated for that device. Then, the
+ * regexdev_init() function supplied by the RegEx driver matching the probed
+ * device is invoked to properly initialize the device.
+ *
+ * The role of the device init function consists of resetting the hardware or
+ * software RegEx driver implementations.
+ *
+ * If the device init operation is successful, the correspondence between
+ * the device identifier assigned to the new device and its associated
+ * *rte_regexdev* structure is effectively registered.
+ * Otherwise, both the *rte_regexdev* structure and the device identifier are
+ * freed.
+ *
+ * The functions exported by the application RegEx API to setup a device
+ * designated by its device identifier must be invoked in the following order:
+ *     - rte_regexdev_configure()
+ *     - rte_regexdev_queue_pair_setup()
+ *     - rte_regexdev_start()
+ *
+ * Then, the application can invoke, in any order, the functions
+ * exported by the RegEx API to enqueue pattern matching job, dequeue pattern
+ * matching response, get the stats, update the rule database,
+ * get/set device attributes and so on
+ *
+ * If the application wants to change the configuration (i.e. call
+ * rte_regexdev_configure() or rte_regexdev_queue_pair_setup()), it must call
+ * rte_regexdev_stop() first to stop the device and then do the reconfiguration
+ * before calling rte_regexdev_start() again. The enqueue and dequeue
+ * functions should not be invoked when the device is stopped.
+ *
+ * Finally, an application can close a RegEx device by invoking the
+ * rte_regexdev_close() function.
+ *
+ * Each function of the application RegEx API invokes a specific function
+ * of the PMD that controls the target device designated by its device
+ * identifier.
+ *
+ * For this purpose, all device-specific functions of a RegEx driver are
+ * supplied through a set of pointers contained in a generic structure of type
+ * *regexdev_ops*.
+ * The address of the *regexdev_ops* structure is stored in the *rte_regexdev*
+ * structure by the device init function of the RegEx driver, which is
+ * invoked during the PCI/SoC device probing phase, as explained earlier.
+ *
+ * In other words, each function of the RegEx API simply retrieves the
+ * *rte_regexdev* structure associated with the device identifier and
+ * performs an indirect invocation of the corresponding driver function
+ * supplied in the *regexdev_ops* structure of the *rte_regexdev* structure.
+ *
+ * For performance reasons, the address of the fast-path functions of the
+ * RegEx driver is not contained in the *regexdev_ops* structure.
+ * Instead, they are directly stored at the beginning of the *rte_regexdev*
+ * structure to avoid an extra indirect memory access during their invocation.
+ *
+ * RTE RegEx device drivers do not use interrupts for enqueue or dequeue
+ * operation. Instead, RegEx drivers export Poll-Mode enqueue and dequeue
+ * functions to applications.
+ *
+ * The *enqueue* operation submits a burst of RegEx pattern matching request
+ * to the RegEx device and the *dequeue* operation gets a burst of pattern
+ * matching response for the ones submitted through *enqueue* operation.
+ *
+ * Typical application utilisation of the RegEx device API will follow the
+ * following programming flow.
+ *
+ * - rte_regexdev_configure()
+ * - rte_regexdev_queue_pair_setup()
+ * - rte_regexdev_rule_db_update() Needs to invoke if precompiled rule database
+ *   not provided in rte_regexdev_config::rule_db for rte_regexdev_configure()
+ *   and/or application needs to update rule database.
+ * - rte_regexdev_rule_db_compile_activate() Needs to invoke if
+ *   rte_regexdev_rule_db_update function was used.
+ * - Create or reuse exiting mempool for *rte_regex_ops* objects.
+ * - rte_regexdev_start()
+ * - rte_regexdev_enqueue_burst()
+ * - rte_regexdev_dequeue_burst()
+ *
+ */
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include <rte_common.h>
+#include <rte_config.h>
+#include <rte_dev.h>
+#include <rte_errno.h>
+#include <rte_mbuf.h>
+#include <rte_memory.h>
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Get the total number of RegEx devices that have been successfully
+ * initialised.
+ *
+ * @return
+ *   The total number of usable RegEx devices.
+ */
+__rte_experimental
+uint8_t
+rte_regexdev_count(void);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Get the device identifier for the named RegEx device.
+ *
+ * @param name
+ *   RegEx device name to select the RegEx device identifier.
+ *
+ * @return
+ *   Returns RegEx device identifier on success.
+ *   - <0: Failure to find named RegEx device.
+ */
+__rte_experimental
+int
+rte_regexdev_get_dev_id(const char *name);
+
+/* Enumerates RegEx device capabilities */
+#define RTE_REGEXDEV_CAPA_RUNTIME_COMPILATION_F (1ULL << 0)
+/**< RegEx device does support compiling the rules at runtime unlike
+ * loading only the pre-built rule database using
+ * struct rte_regexdev_config::rule_db in rte_regexdev_configure()
+ *
+ * @see struct rte_regexdev_config::rule_db, rte_regexdev_configure()
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_CAPA_SUPP_PCRE_START_ANCHOR_F (1ULL << 1)
+/**< RegEx device support PCRE Anchor to start of match flag.
+ * Example RegEx is '/\Gfoo\d/'. Here '\G' asserts position at the end of the
+ * previous match or the start of the string for the first match.
+ * This position will change each time the RegEx is applied to the subject
+ * string. If the RegEx is applied to 'foo1foo2Zfoo3' the first two matches will
+ * be successful for 'foo1foo2' and fail for 'Zfoo3'.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_CAPA_SUPP_PCRE_ATOMIC_GROUPING_F (1ULL << 2)
+/**< RegEx device support PCRE Atomic grouping.
+ * Atomic groups are represented by '(?>)'. An atomic group is a group that,
+ * when the RegEx engine exits from it, automatically throws away all
+ * backtracking positions remembered by any tokens inside the group.
+ * Example RegEx is 'a(?>bc|b)c' if the given patterns are 'abc' and 'abcc' then
+ * 'a(bc|b)c' matches both where as 'a(?>bc|b)c' matches only abcc because
+ * atomic groups don't allow backtracing back to 'b'.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_BACKTRACKING_CTRL_F (1ULL << 3)
+/**< RegEx device support PCRE backtracking control verbs.
+ * Some examples of backtracing verbs are (*COMMIT), (*ACCEPT), (*FAIL),
+ * (*SKIP), (*PRUNE).
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_CALLOUTS_F (1ULL << 4)
+/**< RegEx device support PCRE callouts.
+ * PCRE supports calling external function in between matches by using '(?C)'.
+ * Example RegEx 'ABC(?C)D' if a given patter is 'ABCD' then the RegEx engine
+ * will parse ABC perform a userdefined callout and return a successful match at
+ * D.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_BACKREFERENCE_F (1ULL << 5)
+/**< RegEx device support PCRE backreference.
+ * Example RegEx is '(\2ABC|(GHI))+' \2 matches the same text as most recently
+ * matched by the 2nd capturing group i.e. 'GHI'.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_GREEDY_F (1ULL << 6)
+/**< RegEx device support PCRE Greedy mode.
+ * For example if the RegEx is 'AB\d*?' then '*?' represents zero or unlimited
+ * matches. In greedy mode the pattern 'AB12345' will be matched completely
+ * where as the ungreedy mode 'AB' will be returned as the match.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_MATCH_ALL_F (1ULL << 7)
+/**< RegEx device support match all mode.
+ * For example if the RegEx is 'AB\d*?' then '*?' represents zero or unlimited
+ * matches. In match all mode the pattern 'AB12345' will return 6 matches.
+ * AB, AB1, AB12, AB123, AB1234, AB12345.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_LOOKAROUND_ASRT_F (1ULL << 8)
+/**< RegEx device support PCRE Lookaround assertions
+ * (Zero-width assertions). Example RegEx is '[a-z]+\d+(?=!{3,})' if
+ * the given pattern is 'dwad1234!' the RegEx engine doesn't report any matches
+ * because the assert '(?=!{3,})' fails. The pattern 'dwad123!!!' would return a
+ * successful match.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_MATCH_POINT_RST_F (1ULL << 9)
+/**< RegEx device doesn't support PCRE match point reset directive.
+ * Example RegEx is '[a-z]+\K\d+' if the pattern is 'dwad123'
+ * then even though the entire pattern matches only '123'
+ * is reported as a match.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_NEWLINE_CONVENTIONS_F (1ULL << 10)
+/**< RegEx support PCRE newline convention.
+ * Newline conventions are represented as follows:
+ * (*CR)        carriage return
+ * (*LF)        linefeed
+ * (*CRLF)      carriage return, followed by linefeed
+ * (*ANYCRLF)   any of the three above
+ * (*ANY)       all Unicode newline sequences
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_NEWLINE_SEQ_F (1ULL << 11)
+/**< RegEx device support PCRE newline sequence.
+ * The escape sequence '\R' will match any newline sequence.
+ * It is equivalent to: '(?>\r\n|\n|\x0b|\f|\r|\x85)'.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_POSSESSIVE_QUALIFIERS_F (1ULL << 12)
+/**< RegEx device support PCRE possessive qualifiers.
+ * Example RegEx possessive qualifiers '*+', '++', '?+', '{m,n}+'.
+ * Possessive quantifier repeats the token as many times as possible and it does
+ * not give up matches as the engine backtracks. With a possessive quantifier,
+ * the deal is all or nothing.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_SUBROUTINE_REFERENCES_F (1ULL << 13)
+/**< RegEx device support PCRE Subroutine references.
+ * PCRE Subroutine references allow for sub patterns to be assessed
+ * as part of the RegEx. Example RegEx is '(foo|fuzz)\g<1>+bar' matches the
+ * pattern 'foofoofuzzfoofuzzbar'.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_UTF_8_F (1ULL << 14)
+/**< RegEx device support UTF-8 character encoding.
+ *
+ * @see struct rte_regexdev_info::pcre_unsup_flags
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_UTF_16_F (1ULL << 15)
+/**< RegEx device support UTF-16 character encoding.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_UTF_32_F (1ULL << 16)
+/**< RegEx device support UTF-32 character encoding.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_WORD_BOUNDARY_F (1ULL << 17)
+/**< RegEx device support word boundaries.
+ * The meta character '\b' represents word boundary anchor.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_FORWARD_REFERENCES_F (1ULL << 18)
+/**< RegEx device support Forward references.
+ * Forward references allow you to use a back reference to a group that appears
+ * later in the RegEx. Example RegEx is '(\3ABC|(DEF|(GHI)))+' matches the
+ * following string 'GHIGHIABCDEF'.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_MATCH_AS_END_F (1ULL << 19)
+/**< RegEx device support match as end.
+ * Match as end means that the match result holds the end offset of the
+ * detected match. No len value is set.
+ * If the device doesn't support this feature it means the match
+ * result holds the starting position of match and the length of the match.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_CROSS_BUFFER_F (1ULL << 20)
+/**< RegEx device support cross buffer match.
+ * Cross buffer matching means that the match can be detected even if the
+ * string was started in previous buffer.
+ * In case the device is configured as RTE_REGEXDEV_CFG_MATCH_AS_END
+ * the end offset will be relative for the first packet.
+ * For example RegEx is ABC the first buffer is xxxx second buffer yyyA and
+ * the last buffer BCzz.
+ * In case the match as end is configured the end offset will be 10.
+ *
+ * @see RTE_REGEXDEV_CFG_MATCH_AS_END_F
+ * @see RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F
+ * @see RTE_REGEX_OPS_RSP_PMI_SOJ_F
+ * @see RTE_REGEX_OPS_RSP_PMI_EOJ_F
+ */
+
+#define RTE_REGEXDEV_SUPP_MATCH_ALL_F (1ULL << 21)
+/**< RegEx device support match all.
+ * Match all means that the RegEx engine will return all possible matches.
+ * For example, assume the RegEx is 'A+b', given the input AAAb the
+ * returned matches will be: Ab, AAb and AAAb.
+ *
+ * @see RTE_REGEXDEV_CFG_MATCH_ALL_F
+ */
+
+/* Enumerates PCRE rule flags */
+#define RTE_REGEX_PCRE_RULE_ALLOW_EMPTY_F (1ULL << 0)
+/**< When this flag is set, the pattern that can match against an empty string,
+ * such as '.*' are allowed.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_ANCHORED_F (1ULL << 1)
+/**< When this flag is set, the pattern is forced to be "anchored", that is, it
+ * is constrained to match only at the first matching point in the string that
+ * is being searched. Similar to '^' and represented by \A.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_CASELESS_F (1ULL << 2)
+/**< When this flag is set, letters in the pattern match both upper and lower
+ * case letters in the subject.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_DOTALL_F (1ULL << 3)
+/**< When this flag is set, a dot metacharacter in the pattern matches any
+ * character, including one that indicates a newline.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_DUPNAMES_F (1ULL << 4)
+/**< When this flag is set, names used to identify capture groups need not be
+ * unique.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_EXTENDED_F (1ULL << 5)
+/**< When this flag is set, most white space characters in the pattern are
+ * totally ignored except when escaped or inside a character class.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_MATCH_UNSET_BACKREF_F (1ULL << 6)
+/**< When this flag is set, a backreference to an unset capture group matches an
+ * empty string.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_MULTILINE_F (1ULL << 7)
+/**< When this flag  is set, the '^' and '$' constructs match immediately
+ * following or immediately before internal newlines in the subject string,
+ * respectively, as well as at the very start and end.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_NO_AUTO_CAPTURE_F (1ULL << 8)
+/**< When this Flag is set, it disables the use of numbered capturing
+ * parentheses in the pattern. References to capture groups (backreferences or
+ * recursion/subroutine calls) may only refer to named groups, though the
+ * reference can be by name or by number.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_UCP_F (1ULL << 9)
+/**< By default, only ASCII characters are recognized, When this flag is set,
+ * Unicode properties are used instead to classify characters.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_UNGREEDY_F (1ULL << 10)
+/**< When this flag is set, the "greediness" of the quantifiers is inverted
+ * so that they are not greedy by default, but become greedy if followed by
+ * '?'.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_UTF_F (1ULL << 11)
+/**< When this flag is set, RegEx engine has to regard both the pattern and the
+ * subject strings that are subsequently processed as strings of UTF characters
+ * instead of single-code-unit strings.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_NEVER_BACKSLASH_C_F (1ULL << 12)
+/**< This flag locks out the use of '\C' in the pattern that is being compiled.
+ * This escape matches one data unit, even in UTF mode which can cause
+ * unpredictable behavior in UTF-8 or UTF-16 modes, because it may leave the
+ * current matching point in the mi:set hlsearchddle of a multi-code-unit
+ * character.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+/**
+ * RegEx device information
+ */
+struct rte_regexdev_info {
+	const char *driver_name; /**< RegEx driver name. */
+	struct rte_device *dev;	/**< Device information. */
+	uint16_t max_matches;
+	/**< Maximum matches per scan supported by this device. */
+	uint16_t max_queue_pairs;
+	/**< Maximum queue pairs supported by this device. */
+	uint16_t max_payload_size;
+	/**< Maximum payload size for a pattern match request or scan.
+	 * @see RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F
+	 */
+	uint32_t max_rules_per_group;
+	/**< Maximum rules supported per group by this device. */
+	uint16_t max_groups;
+	/**< Maximum groups supported by this device. */
+	uint32_t regexdev_capa;
+	/**< RegEx device capabilities. @see RTE_REGEXDEV_CAPA_* */
+	uint64_t rule_flags;
+	/**< Supported compiler rule flags.
+	 * @see RTE_REGEX_PCRE_RULE_*, struct rte_regexdev_rule::rule_flags
+	 */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Retrieve the contextual information of a RegEx device.
+ *
+ * @param dev_id
+ *   The identifier of the device.
+ *
+ * @param[out] dev_info
+ *   A pointer to a structure of type *rte_regexdev_info* to be filled with the
+ *   contextual information of the device.
+ *
+ * @return
+ *   - 0: Success, driver updates the contextual information of the RegEx device
+ *   - <0: Error code returned by the driver info get function.
+ */
+__rte_experimental
+int
+rte_regexdev_info_get(uint8_t dev_id, struct rte_regexdev_info *dev_info);
+
+/* Enumerates RegEx device configuration flags */
+#define RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F (1ULL << 0)
+/**< Cross buffer scan refers to the ability to be able to detect
+ * matches that occur across buffer boundaries, where the buffers are related
+ * to each other in some way. Enable this flag when to scan payload size
+ * greater than struct rte_regexdev_info::max_payload_size and/or
+ * matches can present across scan buffer boundaries.
+ *
+ * @see struct rte_regexdev_info::max_payload_size
+ * @see struct rte_regexdev_config::dev_cfg_flags, rte_regexdev_configure()
+ * @see RTE_REGEX_OPS_RSP_PMI_SOJ_F
+ * @see RTE_REGEX_OPS_RSP_PMI_EOJ_F
+ */
+
+#define RTE_REGEXDEV_CFG_MATCH_AS_END_F (1ULL << 1)
+/**< Match as end is the ability to return the result as ending offset.
+ * When this flag is set, the result for each match will hold the ending
+ * offset of the match in end_offset.
+ * If this flag is not set, then the match result will hold the starting offset
+ * in start_offset, and the length of the match in len.
+ *
+ * @see RTE_REGEXDEV_SUPP_MATCH_AS_END_F
+ */
+
+#define RTE_REGEXDEV_CFG_MATCH_ALL_F (1ULL << 2)
+/**< Match all is the ability to return all possible results.
+ *
+ * @see RTE_REGEXDEV_SUPP_MATCH_ALL_F
+ */
+
+/** RegEx device configuration structure */
+struct rte_regexdev_config {
+	uint16_t nb_max_matches;
+	/**< Maximum matches per scan configured on this device.
+	 * This value cannot exceed the *max_matches*
+	 * which previously provided in rte_regexdev_info_get().
+	 * The value 0 is allowed, in which case, value 1 used.
+	 * @see struct rte_regexdev_info::max_matches
+	 */
+	uint16_t nb_queue_pairs;
+	/**< Number of RegEx queue pairs to configure on this device.
+	 * This value cannot exceed the *max_queue_pairs* which previously
+	 * provided in rte_regexdev_info_get().
+	 * @see struct rte_regexdev_info::max_queue_pairs
+	 */
+	uint32_t nb_rules_per_group;
+	/**< Number of rules per group to configure on this device.
+	 * This value cannot exceed the *max_rules_per_group*
+	 * which previously provided in rte_regexdev_info_get().
+	 * The value 0 is allowed, in which case,
+	 * struct rte_regexdev_info::max_rules_per_group used.
+	 * @see struct rte_regexdev_info::max_rules_per_group
+	 */
+	uint16_t nb_groups;
+	/**< Number of groups to configure on this device.
+	 * This value cannot exceed the *max_groups*
+	 * which previously provided in rte_regexdev_info_get().
+	 * @see struct rte_regexdev_info::max_groups
+	 */
+	const char *rule_db;
+	/**< Import initial set of prebuilt rule database on this device.
+	 * The value NULL is allowed, in which case, the device will not
+	 * be configured prebuilt rule database. Application may use
+	 * rte_regexdev_rule_db_update() or rte_regexdev_rule_db_import() API
+	 * to update or import rule database after the
+	 * rte_regexdev_configure().
+	 * @see rte_regexdev_rule_db_update(), rte_regexdev_rule_db_import()
+	 */
+	uint32_t rule_db_len;
+	/**< Length of *rule_db* buffer. */
+	uint32_t dev_cfg_flags;
+	/**< RegEx device configuration flags, See RTE_REGEXDEV_CFG_*  */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Configure a RegEx device.
+ *
+ * This function must be invoked first before any other function in the
+ * API. This function can also be re-invoked when a device is in the
+ * stopped state.
+ *
+ * The caller may use rte_regexdev_info_get() to get the capability of each
+ * resources available for this regex device.
+ *
+ * @param dev_id
+ *   The identifier of the device to configure.
+ * @param cfg
+ *   The RegEx device configuration structure.
+ *
+ * @return
+ *   - 0: Success, device configured. Otherwise negative errno is returned.
+ */
+__rte_experimental
+int
+rte_regexdev_configure(uint8_t dev_id, const struct rte_regexdev_config *cfg);
+
+/* Enumerates RegEx queue pair configuration flags */
+#define RTE_REGEX_QUEUE_PAIR_CFG_OOS_F (1ULL << 0)
+/**< Out of order scan, If not set, a scan must retire after previously issued
+ * in-order scans to this queue pair. If set, this scan can be retired as soon
+ * as device returns completion. Application should not set out of order scan
+ * flag if it needs to maintain the ingress order of scan request.
+ *
+ * @see struct rte_regexdev_qp_conf::qp_conf_flags
+ * @see rte_regexdev_queue_pair_setup()
+ */
+
+struct rte_regex_ops;
+typedef void (*regexdev_stop_flush_t)(uint8_t dev_id, uint16_t qp_id,
+				      struct rte_regex_ops *op);
+/**< Callback function called during rte_regexdev_stop(), invoked once per
+ * flushed RegEx op.
+ */
+
+/** RegEx queue pair configuration structure */
+struct rte_regexdev_qp_conf {
+	uint32_t qp_conf_flags;
+	/**< Queue pair config flags, See RTE_REGEX_QUEUE_PAIR_CFG_* */
+	uint16_t nb_desc;
+	/**< The number of descriptors to allocate for this queue pair. */
+	regexdev_stop_flush_t cb;
+	/**< Callback function called during rte_regexdev_stop(), invoked
+	 * once per flushed regex op. Value NULL is allowed, in which case
+	 * callback will not be invoked. This function can be used to properly
+	 * dispose of outstanding regex ops from response queue,
+	 * for example ops containing memory pointers.
+	 * @see rte_regexdev_stop()
+	 */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Allocate and set up a RegEx queue pair for a RegEx device.
+ *
+ * @param dev_id
+ *   The identifier of the device.
+ * @param queue_pair_id
+ *   The index of the RegEx queue pair to setup. The value must be in the range
+ *   [0, nb_queue_pairs - 1] previously supplied to rte_regexdev_configure().
+ * @param qp_conf
+ *   The pointer to the configuration data to be used for the RegEx queue pair.
+ *   NULL value is allowed, in which case default configuration	used.
+ *
+ * @return
+ *   0 on success. Otherwise negative errno is returned.
+ */
+__rte_experimental
+int
+rte_regexdev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
+			      const struct rte_regexdev_qp_conf *qp_conf);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Start a RegEx device.
+ *
+ * The device start step is the last one and consists of setting the RegEx
+ * queues to start accepting the pattern matching scan requests.
+ *
+ * On success, all basic functions exported by the API (RegEx enqueue,
+ * RegEx dequeue and so on) can be invoked.
+ *
+ * @param dev_id
+ *   RegEx device identifier.
+ *
+ * @return
+ *   0 on success. Otherwise negative errno is returned.
+ */
+__rte_experimental
+int
+rte_regexdev_start(uint8_t dev_id);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Stop a RegEx device.
+ *
+ * Stop a RegEx device. The device can be restarted with a call to
+ * rte_regexdev_start().
+ *
+ * This function causes all queued response regex ops to be drained in the
+ * response queue. While draining ops out of the device,
+ * struct rte_regexdev_qp_conf::cb will be invoked for each ops.
+ *
+ * @param dev_id
+ *   RegEx device identifier.
+ *
+ * @see struct rte_regexdev_qp_conf::cb, rte_regexdev_queue_pair_setup()
+ */
+__rte_experimental
+void
+rte_regexdev_stop(uint8_t dev_id);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Close a RegEx device. The device cannot be restarted!
+ *
+ * @param dev_id
+ *   RegEx device identifier
+ *
+ * @return
+ *   0 on success. Otherwise negative errno is returned.
+ */
+__rte_experimental
+int
+rte_regexdev_close(uint8_t dev_id);
+
+/* Device get/set attributes */
+
+/** Enumerates RegEx device attribute identifier */
+enum rte_regexdev_attr_id {
+	RTE_REGEXDEV_ATTR_SOCKET_ID,
+	/**< The NUMA socket id to which the device is connected or
+	 * a default of zero if the socket could not be determined.
+	 * datatype: *int*
+	 * operation: *get*
+	 */
+	RTE_REGEXDEV_ATTR_MAX_MATCHES,
+	/**< Maximum number of matches per scan.
+	 * datatype: *uint8_t*
+	 * operation: *get* and *set*
+	 * @see RTE_REGEX_OPS_RSP_MAX_MATCH_F
+	 */
+	RTE_REGEXDEV_ATTR_MAX_SCAN_TIMEOUT,
+	/**< Upper bound scan time in ns.
+	 * datatype: *uint16_t*
+	 * operation: *get* and *set*
+	 * @see RTE_REGEX_OPS_RSP_MAX_SCAN_TIMEOUT_F
+	 */
+	RTE_REGEXDEV_ATTR_MAX_PREFIX,
+	/**< Maximum number of prefix detected per scan.
+	 * This would be useful for denial of service detection.
+	 * datatype: *uint16_t*
+	 * operation: *get* and *set*
+	 * @see RTE_REGEX_OPS_RSP_MAX_PREFIX_F
+	 */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Get an attribute from a RegEx device.
+ *
+ * @param dev_id
+ *   RegEx device identifier.
+ * @param attr_id
+ *   The attribute ID to retrieve.
+ * @param attr_value
+ *   A pointer that will be filled in with the attribute
+ *   value if successful.
+ *
+ * @return
+ *   - 0: Successfully retrieved attribute value.
+ *   - -EINVAL: Invalid device or  *attr_id* provided, or *attr_value* is NULL.
+ *   - -ENOTSUP: if the device doesn't support specific *attr_id*.
+ */
+__rte_experimental
+int
+rte_regexdev_attr_get(uint8_t dev_id, enum rte_regexdev_attr_id attr_id,
+		      void *attr_value);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Set an attribute to a RegEx device.
+ *
+ * @param dev_id
+ *   RegEx device identifier.
+ * @param attr_id
+ *   The attribute ID to retrieve.
+ * @param attr_value
+ *   Pointer that will be filled in with the attribute value
+ *   by the application.
+ *
+ * @return
+ *   - 0: Successfully applied the attribute value.
+ *   - -EINVAL: Invalid device or  *attr_id* provided, or *attr_value* is NULL.
+ *   - -ENOTSUP: if the device doesn't support specific *attr_id*.
+ */
+__rte_experimental
+int
+rte_regexdev_attr_set(uint8_t dev_id, enum rte_regexdev_attr_id attr_id,
+		      const void *attr_value);
+
+/* Rule related APIs */
+/** Enumerates RegEx rule operation. */
+enum rte_regexdev_rule_op {
+	RTE_REGEX_RULE_OP_ADD,
+	/**< Add RegEx rule to rule database. */
+	RTE_REGEX_RULE_OP_REMOVE
+	/**< Remove RegEx rule from rule database. */
+};
+
+/** Structure to hold a RegEx rule attributes. */
+struct rte_regexdev_rule {
+	enum rte_regexdev_rule_op op;
+	/**< OP type of the rule either a OP_ADD or OP_DELETE. */
+	uint16_t group_id;
+	/**< Group identifier to which the rule belongs to. */
+	uint32_t rule_id;
+	/**< Rule identifier which is returned on successful match. */
+	const char *pcre_rule;
+	/**< Buffer to hold the PCRE rule. */
+	uint16_t pcre_rule_len;
+	/**< Length of the PCRE rule. */
+	uint64_t rule_flags;
+	/* PCRE rule flags. Supported device specific PCRE rules enumerated
+	 * in struct rte_regexdev_info::rule_flags. For successful rule
+	 * database update, application needs to provide only supported
+	 * rule flags.
+	 * @See RTE_REGEX_PCRE_RULE_*, struct rte_regexdev_info::rule_flags
+	 */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Update the local rule set.
+ * This functions only modify the rule set in memory.
+ * In order for the changes to take effect, the function
+ * rte_regexdev_rule_db_compile_active must be called.
+ *
+ * @param dev_id
+ *   RegEx device identifier.
+ * @param rules
+ *   Points to an array of *nb_rules* objects of type *rte_regexdev_rule*
+ *   structure which contain the regex rules attributes to be updated
+ *   in rule database.
+ * @param nb_rules
+ *   The number of PCRE rules to update the rule database.
+ *
+ * @return
+ *   The number of regex rules actually updated on the regex device's rule
+ *   database. The return value can be less than the value of the *nb_rules*
+ *   parameter when the regex devices fails to update the rule database or
+ *   if invalid parameters are specified in a *rte_regexdev_rule*.
+ *   If the return value is less than *nb_rules*, the remaining PCRE rules
+ *   at the end of *rules* are not consumed and the caller has to take
+ *   care of them and rte_errno is set accordingly.
+ *   Possible errno values include:
+ *   - -EINVAL:  Invalid device ID or rules is NULL
+ *   - -ENOTSUP: The last processed rule is not supported on this device.
+ *   - -ENOSPC: No space available in rule database.
+ *
+ * @see rte_regexdev_rule_db_import(), rte_regexdev_rule_db_export(),
+ *   rte_regexdev_rule_db_compile_activate()
+ */
+__rte_experimental
+int
+rte_regexdev_rule_db_update(uint8_t dev_id,
+			    const struct rte_regexdev_rule *rules,
+			    uint32_t nb_rules);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Compile local rule set and burn the complied result to the
+ * RegEx deive.
+ *
+ * @param dev_id
+ *   RegEx device identifier.
+ *
+ * @return
+ *   0 on success, otherwise negative errno.
+ *
+ * @see rte_regexdev_rule_db_import(), rte_regexdev_rule_db_export(),
+ *   rte_regexdev_rule_db_update()
+ */
+__rte_experimental
+int
+rte_regexdev_rule_db_compile_activate(uint8_t dev_id);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Import a prebuilt rule database from a buffer to a RegEx device.
+ *
+ * @param dev_id
+ *   RegEx device identifier.
+ * @param rule_db
+ *   Points to prebuilt rule database.
+ * @param rule_db_len
+ *   Length of the rule database.
+ *
+ * @return
+ *   - 0: Successfully updated the prebuilt rule database.
+ *   - -EINVAL:  Invalid device ID or rule_db is NULL
+ *   - -ENOTSUP: Rule database import is not supported on this device.
+ *   - -ENOSPC: No space available in rule database.
+ *
+ * @see rte_regexdev_rule_db_update(), rte_regexdev_rule_db_export()
+ */
+__rte_experimental
+int
+rte_regexdev_rule_db_import(uint8_t dev_id, const char *rule_db,
+			    uint32_t rule_db_len);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Export the prebuilt rule database from a RegEx device to the buffer.
+ *
+ * @param dev_id
+ *   RegEx device identifier.
+ * @param[out] rule_db
+ *   Block of memory to insert the rule database. Must be at least size in
+ *   capacity. If set to NULL, function returns required capacity.
+ *
+ * @return
+ *   - 0: Successfully exported the prebuilt rule database.
+ *   - size: If rule_db set to NULL then required capacity for *rule_db*
+ *   - -EINVAL:  Invalid device ID
+ *   - -ENOTSUP: Rule database export is not supported on this device.
+ *
+ * @see rte_regexdev_rule_db_update(), rte_regexdev_rule_db_import()
+ */
+__rte_experimental
+int
+rte_regexdev_rule_db_export(uint8_t dev_id, char *rule_db);
+
+/* Extended statistics */
+/** Maximum name length for extended statistics counters */
+#define RTE_REGEXDEV_XSTATS_NAME_SIZE 64
+
+/**
+ * A name-key lookup element for extended statistics.
+ *
+ * This structure is used to map between names and ID numbers
+ * for extended RegEx device statistics.
+ */
+struct rte_regexdev_xstats_map {
+	uint16_t id;
+	/**< xstat identifier */
+	char name[RTE_REGEXDEV_XSTATS_NAME_SIZE];
+	/**< xstat name */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Retrieve names of extended statistics of a regex device.
+ *
+ * @param dev_id
+ *   The identifier of the regex device.
+ * @param[out] xstats_map
+ *   Block of memory to insert id and names into. Must be at least size in
+ *   capacity. If set to NULL, function returns required capacity.
+ * @return
+ *   - Positive value on success:
+ *        -The return value is the number of entries filled in the stats map.
+ *        -If xstats_map set to NULL then required capacity for xstats_map.
+ *   - Negative value on error:
+ *      -ENODEV for invalid *dev_id*
+ *      -ENOTSUP if the device doesn't support this function.
+ */
+__rte_experimental
+int
+rte_regexdev_xstats_names_get(uint8_t dev_id,
+			      struct rte_regexdev_xstats_map *xstats_map);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Retrieve extended statistics of an regex device.
+ *
+ * @param dev_id
+ *   The identifier of the device.
+ * @param ids
+ *   The id numbers of the stats to get. The ids can be got from the stat
+ *   position in the stat list from rte_regexdev_xstats_names_get(), or
+ *   by using rte_regexdev_xstats_by_name_get().
+ * @param values
+ *   The values for each stats request by ID.
+ * @param nb_values
+ *   The number of stats requested.
+ * @return
+ *   - Positive value: number of stat entries filled into the values array
+ *   - Negative value on error:
+ *      -ENODEV for invalid *dev_id*
+ *      -ENOTSUP if the device doesn't support this function.
+ */
+__rte_experimental
+int
+rte_regexdev_xstats_get(uint8_t dev_id, const uint16_t *ids,
+			uint64_t *values, uint16_t nb_values);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Retrieve the value of a single stat by requesting it by name.
+ *
+ * @param dev_id
+ *   The identifier of the device.
+ * @param name
+ *   The stat name to retrieve.
+ * @param id
+ *   If non-NULL, the numerical id of the stat will be returned, so that further
+ *   requests for the stat can be got using rte_regexdev_xstats_get, which will
+ *   be faster as it doesn't need to scan a list of names for the stat.
+ * @param[out] value
+ *   Must be non-NULL, retrieved xstat value will be stored in this address.
+ *
+ * @return
+ *   - 0: Successfully retrieved xstat value.
+ *   - -EINVAL: invalid parameters
+ *   - -ENOTSUP: if not supported.
+ */
+__rte_experimental
+int
+rte_regexdev_xstats_by_name_get(uint8_t dev_id, const char *name,
+				uint16_t *id, uint64_t *value);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Reset the values of the xstats of the selected component in the device.
+ *
+ * @param dev_id
+ *   The identifier of the device.
+ * @param ids
+ *   Selects specific statistics to be reset. When NULL, all statistics will be
+ *   reset. If non-NULL, must point to array of at least *nb_ids* size.
+ * @param nb_ids
+ *   The number of ids available from the *ids* array. Ignored when ids is NULL.
+ *
+ * @return
+ *   - 0: Successfully reset the statistics to zero.
+ *   - -EINVAL: invalid parameters.
+ *   - -ENOTSUP: if not supported.
+ */
+__rte_experimental
+int
+rte_regexdev_xstats_reset(uint8_t dev_id, const uint16_t *ids,
+			  uint16_t nb_ids);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Trigger the RegEx device self test.
+ *
+ * @param dev_id
+ *   The identifier of the device.
+ * @return
+ *   - 0: Selftest successful.
+ *   - -ENOTSUP if the device doesn't support selftest.
+ *   - other values < 0 on failure.
+ */
+__rte_experimental
+int
+rte_regexdev_selftest(uint8_t dev_id);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Dump internal information about *dev_id* to the FILE* provided in *f*.
+ *
+ * @param dev_id
+ *   The identifier of the device.
+ * @param f
+ *   A pointer to a file for output.
+ *
+ * @return
+ *   0 on success, negative errno on failure.
+ */
+__rte_experimental
+int
+rte_regexdev_dump(uint8_t dev_id, FILE *f);
+
+/* Fast path APIs */
+
+/**
+ * The generic *rte_regexdev_match* structure to hold the RegEx match
+ * attributes.
+ * @see struct rte_regex_ops::matches
+ */
+struct rte_regexdev_match {
+	RTE_STD_C11
+	union {
+		uint64_t u64;
+		struct {
+			uint32_t rule_id:20;
+			/**< Rule identifier to which the pattern matched.
+			 * @see struct rte_regexdev_rule::rule_id
+			 */
+			uint32_t group_id:12;
+			/**< Group identifier of the rule which the pattern
+			 * matched. @see struct rte_regexdev_rule::group_id
+			 */
+			uint16_t start_offset;
+			/**< Starting Byte Position for matched rule. */
+			RTE_STD_C11
+			union {
+				uint16_t len;
+				/**< Length of match in bytes */
+				uint16_t end_offset;
+				/**< The end offset of the match. In case
+				 * MATCH_AS_END configuration is enabled.
+				 * @see RTE_REGEXDEV_CFG_MATCH_AS_END
+				 */
+			};
+		};
+	};
+};
+
+/* Enumerates RegEx request flags. */
+#define RTE_REGEX_OPS_REQ_GROUP_ID0_VALID_F (1 << 0)
+/**< Set when struct rte_regexdev_rule::group_id0 is valid. */
+
+#define RTE_REGEX_OPS_REQ_GROUP_ID1_VALID_F (1 << 1)
+/**< Set when struct rte_regexdev_rule::group_id1 is valid. */
+
+#define RTE_REGEX_OPS_REQ_GROUP_ID2_VALID_F (1 << 2)
+/**< Set when struct rte_regexdev_rule::group_id2 is valid. */
+
+#define RTE_REGEX_OPS_REQ_GROUP_ID3_VALID_F (1 << 3)
+/**< Set when struct rte_regexdev_rule::group_id3 is valid. */
+
+#define RTE_REGEX_OPS_REQ_STOP_ON_MATCH_F (1 << 4)
+/**< The RegEx engine will stop scanning and return the first match. */
+
+#define RTE_REGEX_OPS_REQ_MATCH_HIGH_PRIORITY_F (1 << 5)
+/**< In High Priority mode a maximum of one match will be returned per scan to
+ * reduce the post-processing required by the application. The match with the
+ * lowest Rule id, lowest start pointer and lowest match length will be
+ * returned.
+ *
+ * @see struct rte_regex_ops::nb_actual_matches
+ * @see struct rte_regex_ops::nb_matches
+ */
+
+
+/* Enumerates RegEx response flags. */
+#define RTE_REGEX_OPS_RSP_PMI_SOJ_F (1 << 0)
+/**< Indicates that the RegEx device has encountered a partial match at the
+ * start of scan in the given buffer.
+ *
+ * @see RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F
+ */
+
+#define RTE_REGEX_OPS_RSP_PMI_EOJ_F (1 << 1)
+/**< Indicates that the RegEx device has encountered a partial match at the
+ * end of scan in the given buffer.
+ *
+ * @see RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F
+ */
+
+#define RTE_REGEX_OPS_RSP_MAX_SCAN_TIMEOUT_F (1 << 2)
+/**< Indicates that the RegEx device has exceeded the max timeout while
+ * scanning the given buffer.
+ *
+ * @see RTE_REGEXDEV_ATTR_MAX_SCAN_TIMEOUT
+ */
+
+#define RTE_REGEX_OPS_RSP_MAX_MATCH_F (1 << 3)
+/**< Indicates that the RegEx device has exceeded the max matches while
+ * scanning the given buffer.
+ *
+ * @see RTE_REGEXDEV_ATTR_MAX_MATCHES
+ */
+
+#define RTE_REGEX_OPS_RSP_MAX_PREFIX_F (1 << 4)
+/**< Indicates that the RegEx device has reached the max allowed prefix length
+ * while scanning the given buffer.
+ *
+ * @see RTE_REGEXDEV_ATTR_MAX_PREFIX
+ */
+
+/**
+ * The generic *rte_regex_ops* structure to hold the RegEx attributes
+ * for enqueue and dequeue operation.
+ */
+struct rte_regex_ops {
+	/* W0 */
+	uint16_t req_flags;
+	/**< Request flags for the RegEx ops.
+	 * @see RTE_REGEX_OPS_REQ_*
+	 */
+	uint16_t rsp_flags;
+	/**< Response flags for the RegEx ops.
+	 * @see RTE_REGEX_OPS_RSP_*
+	 */
+	uint16_t nb_actual_matches;
+	/**< The total number of actual matches detected by the Regex device.*/
+	uint16_t nb_matches;
+	/**< The total number of matches returned by the RegEx device for this
+	 * scan. The size of *rte_regex_ops::matches* zero length array will be
+	 * this value.
+	 *
+	 * @see struct rte_regex_ops::matches, struct rte_regexdev_match
+	 */
+
+	/* W1 */
+	struct rte_mbuf *mbuf; /**< source mbuf, to search in. */
+
+	/* W2 */
+	uint16_t group_id0;
+	/**< First group_id to match the rule against. At minimum one group
+	 * should be valid. Behaviour is undefined non of the groups are valid.
+	 *
+	 * @see RTE_REGEX_OPS_REQ_GROUP_ID0_VALID_F
+	 */
+	uint16_t group_id1;
+	/**< Second group_id to match the rule against.
+	 *
+	 * @see RTE_REGEX_OPS_REQ_GROUP_ID1_VALID_F
+	 */
+	uint16_t group_id2;
+	/**< Third group_id to match the rule against.
+	 *
+	 * @see RTE_REGEX_OPS_REQ_GROUP_ID2_VALID_F
+	 */
+	uint16_t group_id3;
+	/**< Forth group_id to match the rule against.
+	 *
+	 * @see RTE_REGEX_OPS_REQ_GROUP_ID3_VALID_F
+	 */
+
+	/* W3 */
+	RTE_STD_C11
+	union {
+		uint64_t user_id;
+		/**< Application specific opaque value. An application may use
+		 * this field to hold application specific value to share
+		 * between dequeue and enqueue operation.
+		 * Implementation should not modify this field.
+		 */
+		void *user_ptr;
+		/**< Pointer representation of *user_id* */
+	};
+
+	/* W4 */
+	RTE_STD_C11
+	union {
+		uint64_t cross_buf_id;
+		/**< ID used by the RegEx device in order to support cross
+		 * packet detection.
+		 * This ID is returned from the RegEx device on the dequeue
+		 * function. The application must send it back when calling
+		 * enqueue with the following packet.
+		 */
+		void *cross_buf_ptr;
+		/**< Pointer representation of *corss_buf_id* */
+	};
+
+	/* W5 */
+	struct rte_regexdev_match matches[];
+	/**< Zero length array to hold the match tuples.
+	 * The struct rte_regex_ops::nb_matches value holds the number of
+	 * elements in this array.
+	 *
+	 * @see struct rte_regex_ops::nb_matches
+	 */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Enqueue a burst of scan request on a RegEx device.
+ *
+ * The rte_regexdev_enqueue_burst() function is invoked to place
+ * regex operations on the queue *qp_id* of the device designated by
+ * its *dev_id*.
+ *
+ * The *nb_ops* parameter is the number of operations to process which are
+ * supplied in the *ops* array of *rte_regexdev_op* structures.
+ *
+ * The rte_regexdev_enqueue_burst() function returns the number of
+ * operations it actually enqueued for processing. A return value equal to
+ * *nb_ops* means that all packets have been enqueued.
+ *
+ * @param dev_id
+ *   The identifier of the device.
+ * @param qp_id
+ *   The index of the queue pair which packets are to be enqueued for
+ *   processing. The value must be in the range [0, nb_queue_pairs - 1]
+ *   previously supplied to rte_regexdev_configure().
+ * @param ops
+ *   The address of an array of *nb_ops* pointers to *rte_regexdev_op*
+ *   structures which contain the regex operations to be processed.
+ * @param nb_ops
+ *   The number of operations to process.
+ *
+ * @return
+ *   The number of operations actually enqueued on the regex device. The return
+ *   value can be less than the value of the *nb_ops* parameter when the
+ *   regex devices queue is full or if invalid parameters are specified in
+ *   a *rte_regexdev_op*. If the return value is less than *nb_ops*, the
+ *   remaining ops at the end of *ops* are not consumed and the caller has
+ *   to take care of them.
+ */
+__rte_experimental
+uint16_t
+rte_regexdev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
+			   struct rte_regex_ops **ops, uint16_t nb_ops);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Dequeue a burst of scan response from a queue on the RegEx device.
+ * The dequeued operation are stored in *rte_regexdev_op* structures
+ * whose pointers are supplied in the *ops* array.
+ *
+ * The rte_regexdev_dequeue_burst() function returns the number of ops
+ * actually dequeued, which is the number of *rte_regexdev_op* data structures
+ * effectively supplied into the *ops* array.
+ *
+ * A return value equal to *nb_ops* indicates that the queue contained
+ * at least *nb_ops* operations, and this is likely to signify that other
+ * processed operations remain in the devices output queue. Applications
+ * implementing a "retrieve as many processed operations as possible" policy
+ * can check this specific case and keep invoking the
+ * rte_regexdev_dequeue_burst() function until a value less than
+ * *nb_ops* is returned.
+ *
+ * The rte_regexdev_dequeue_burst() function does not provide any error
+ * notification to avoid the corresponding overhead.
+ *
+ * @param dev_id
+ *   The RegEx device identifier
+ * @param qp_id
+ *   The index of the queue pair from which to retrieve processed packets.
+ *   The value must be in the range [0, nb_queue_pairs - 1] previously
+ *   supplied to rte_regexdev_configure().
+ * @param ops
+ *   The address of an array of pointers to *rte_regexdev_op* structures
+ *   that must be large enough to store *nb_ops* pointers in it.
+ * @param nb_ops
+ *   The maximum number of operations to dequeue.
+ *
+ * @return
+ *   The number of operations actually dequeued, which is the number
+ *   of pointers to *rte_regexdev_op* structures effectively supplied to the
+ *   *ops* array. If the return value is less than *nb_ops*, the remaining
+ *   ops at the end of *ops* are not consumed and the caller has to take care
+ *   of them.
+ */
+__rte_experimental
+uint16_t
+rte_regexdev_dequeue_burst(uint8_t dev_id, uint16_t qp_id,
+			   struct rte_regex_ops **ops, uint16_t nb_ops);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_REGEXDEV_H_ */
diff --git a/lib/librte_regexdev/rte_regexdev_version.map b/lib/librte_regexdev/rte_regexdev_version.map
new file mode 100644
index 0000000..d400624
--- /dev/null
+++ b/lib/librte_regexdev/rte_regexdev_version.map
@@ -0,0 +1,26 @@
+EXPERIMENTAL {
+	global:
+
+	rte_regexdev_count;
+	rte_regexdev_get_dev_id;
+	rte_regexdev_info_get;
+	rte_regexdev_configure;
+	rte_regexdev_queue_pair_setup;
+	rte_regexdev_start;
+	rte_regexdev_stop;
+	rte_regexdev_close;
+	rte_regexdev_attr_get;
+	rte_regexdev_attr_set;
+	rte_regexdev_rule_db_update;
+	rte_regexdev_rule_db_compile_activate;
+	rte_regexdev_rule_db_import;
+	rte_regexdev_rule_db_export;
+	rte_regexdev_xstats_names_get;
+	rte_regexdev_xstats_get;
+	rte_regexdev_xstats_by_name_get;
+	rte_regexdev_xstats_reset;
+	rte_regexdev_selftest;
+	rte_regexdev_dump;
+	rte_regexdev_enqueue_burst;
+	rte_regexdev_dequeue_burst;
+};
diff --git a/lib/meson.build b/lib/meson.build
index 9c3cc55..61a0353 100644
--- a/lib/meson.build
+++ b/lib/meson.build
@@ -22,7 +22,8 @@ libraries = [
 	'gro', 'gso', 'ip_frag', 'jobstats',
 	'kni', 'latencystats', 'lpm', 'member',
 	'power', 'pdump', 'rawdev',
-	'rcu', 'rib', 'reorder', 'sched', 'security', 'stack', 'vhost',
+	'rcu', 'regexdev', 'rib', 'reorder', 'sched', 'security', 'stack',
+	'vhost',
 	# ipsec lib depends on net, crypto and security
 	'ipsec',
 	#fib lib depends on rib
-- 
1.8.3.1


^ permalink raw reply	[flat|nested] 96+ messages in thread

* [dpdk-dev] [PATCH v1 2/4] regexdev: add regex core h file
  2020-03-29  6:47 [dpdk-dev] [PATCH v1 0/4] add RegEx class Ori Kam
  2020-03-29  6:47 ` [dpdk-dev] [PATCH v1 1/4] regexdev: introduce regexdev subsystem Ori Kam
@ 2020-03-29  6:47 ` Ori Kam
       [not found]   ` <DM5PR18MB221411AAEAFFA9D9F373292BC6C20@DM5PR18MB2214.namprd18.prod.outlook.com>
  2020-03-29  6:47 ` [dpdk-dev] [PATCH v1 3/4] regexdev: add regexdev core functions Ori Kam
                   ` (6 subsequent siblings)
  8 siblings, 1 reply; 96+ messages in thread
From: Ori Kam @ 2020-03-29  6:47 UTC (permalink / raw)
  To: jerinj, xiang.w.wang
  Cc: dev, pbhagavatula, shahafs, hemant.agrawal, opher, alexr, dovrat,
	pkapoor, nipun.gupta, bruce.richardson, yang.a.hong, harry.chang,
	gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai, yuyingxia,
	fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc, jim,
	hongjun.ni, j.bromhead, deri, fc, arthur.su, thomas, orika

This commit introduce the rte_regexdev_core.h file.
This file holds internal structures and API that are used by
the regexdev.

Signed-off-by: Ori Kam <orika@mellanox.com>
---
 lib/librte_regexdev/Makefile            |   1 +
 lib/librte_regexdev/meson.build         |   2 +-
 lib/librte_regexdev/rte_regexdev.h      |   2 +
 lib/librte_regexdev/rte_regexdev_core.h | 147 ++++++++++++++++++++++++++++++++
 4 files changed, 151 insertions(+), 1 deletion(-)
 create mode 100644 lib/librte_regexdev/rte_regexdev_core.h

diff --git a/lib/librte_regexdev/Makefile b/lib/librte_regexdev/Makefile
index 6f4cc63..9012d29 100644
--- a/lib/librte_regexdev/Makefile
+++ b/lib/librte_regexdev/Makefile
@@ -24,6 +24,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_REGEXDEV) := rte_regexdev.c
 
 # export include files
 SYMLINK-$(CONFIG_RTE_LIBRTE_REGEXDEV)-include += rte_regexdev.h
+SYMLINK-$(CONFIG_RTE_LIBRTE_REGEXDEV)-include += rte_regexdev_core.h
 
 # versioning export map
 EXPORT_MAP := rte_regexdev_version.map
diff --git a/lib/librte_regexdev/meson.build b/lib/librte_regexdev/meson.build
index f4db748..1816754 100644
--- a/lib/librte_regexdev/meson.build
+++ b/lib/librte_regexdev/meson.build
@@ -3,5 +3,5 @@
 
 allow_experimental_apis = true
 sources = files('rte_regexdev.c')
-headers = files('rte_regexdev.h')
+headers = files('rte_regexdev.h', 'rte_regexdev_core.h')
 deps += ['mbuf']
diff --git a/lib/librte_regexdev/rte_regexdev.h b/lib/librte_regexdev/rte_regexdev.h
index 7e688d9..bbc56f9 100644
--- a/lib/librte_regexdev/rte_regexdev.h
+++ b/lib/librte_regexdev/rte_regexdev.h
@@ -1466,6 +1466,8 @@ struct rte_regex_ops {
 rte_regexdev_dequeue_burst(uint8_t dev_id, uint16_t qp_id,
 			   struct rte_regex_ops **ops, uint16_t nb_ops);
 
+#include "rte_regexdev_core.h"
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/lib/librte_regexdev/rte_regexdev_core.h b/lib/librte_regexdev/rte_regexdev_core.h
new file mode 100644
index 0000000..e30865d
--- /dev/null
+++ b/lib/librte_regexdev/rte_regexdev_core.h
@@ -0,0 +1,147 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2019 Mellanox Corporation
+ */
+
+#ifndef _RTE_REGEX_CORE_H_
+#define _RTE_REGEX_CORE_H_
+
+/**
+ * @file
+ *
+ * RTE RegEx Device internal header.
+ *
+ * This header contains internal data types, that are used by the RegEx devices
+ * in order to expose their ops to the class.
+ *
+ * Applications should not use these API directly.
+ *
+ */
+
+struct rte_regexdev;
+
+typedef int (*regexdev_info_get_t)(struct rte_regexdev *dev,
+				   struct rte_regexdev_info *info);
+/**< @internal Get the RegEx device info. */
+
+typedef int (*regexdev_configure_t)(struct rte_regexdev *dev,
+				    const struct rte_regexdev_config *cfg);
+/**< @internal Configure the RegEx device. */
+
+typedef int (*regexdev_qp_setup_t)(struct rte_regexdev *dev, uint8_t id,
+				   const struct rte_regexdev_qp_conf *qp_conf);
+/**< @internal Setup a queue pair.*/
+
+typedef int (*regexdev_start_t)(struct rte_regexdev *dev);
+/**< @internal Start the RegEx device. */
+
+typedef int (*regexdev_stop_t)(struct rte_regexdev *dev);
+/**< @internal Stop the RegEx device. */
+
+typedef int (*regexdev_close_t)(struct rte_regexdev *dev);
+/**< @internal Close the RegEx device. */
+
+typedef int (*regexdev_attr_get_t)(struct rte_regexdev *dev,
+				   enum rte_regexdev_attr_id id,
+				   void *value);
+/**< @internal Get selected attribute from RegEx device. */
+
+typedef int (*regexdev_attr_set_t)(struct rte_regexdev *dev,
+				   enum rte_regexdev_attr_id id,
+				   const void *value);
+/**< @internal Set selected attribute to RegEx device. */
+
+typedef int (*regexdev_rule_db_update_t)(struct rte_regexdev *dev,
+					 const struct rte_regexdev_rule *rules,
+					 uint16_t nb_rules);
+/**< @internal Update the rule database for the RegEx device. */
+
+typedef int (*regexdev_rule_db_compile_activate_t)(struct rte_regexdev *dev);
+/**< @internal Compile the rule database and activate it. */
+
+typedef int (*regexdev_rule_db_import_t)(struct rte_regexdev *dev,
+					 const char *rule_db,
+					 uint32_t rule_db_len);
+/**< @internal Upload a pre created rule database to the RegEx device. */
+
+typedef int (*regexdev_rule_db_export_t)(struct rte_regexdev *dev,
+					 const char *rule_db);
+/**< @internal Export the current rule database from the RegEx device. */
+
+typedef int (*regexdev_xstats_names_get_t)(struct rte_regexdev *dev,
+					   struct rte_regexdev_xstats_map
+					   *xstats_map);
+/**< @internal Get xstats name map for the RegEx device. */
+
+typedef int (*regexdev_xstats_get_t)(struct rte_regexdev *dev,
+				     const uint16_t *ids, uint64_t *values,
+				     uint16_t nb_values);
+/**< @internal Get xstats values for the RegEx device. */
+
+typedef int (*regexdev_xstats_by_name_get_t)(struct rte_regexdev *dev,
+					     const char *name, uint16_t *id,
+					     uint64_t *value);
+/**< @internal Get xstat value for the RegEx device based on the xstats name. */
+
+typedef int (*regexdev_xstats_reset_t)(struct rte_regexdev *dev,
+				       const uint16_t *ids,
+				       uint16_t nb_ids);
+/**< @internal Reset xstats values for the RegEx device. */
+
+typedef int (*regexdev_selftest_t)(struct rte_regexdev *dev);
+/**< @internal Trigger RegEx self test. */
+
+typedef int (*regexdev_dump_t)(struct rte_regexdev *dev, FILE *f);
+/**< @internal Dump internal information about the RegEx device. */
+
+typedef int (*regexdev_enqueue_t)(struct rte_regexdev *dev, uint16_t qp_id,
+				  struct rte_regex_ops **ops, uint16_t nb_ops);
+/**< @internal Enqueue a burst of scan requests to a queue on RegEx device. */
+
+typedef int (*regexdev_dequeue_t)(struct rte_regexdev *dev, uint16_t qp_id,
+				  struct rte_regex_ops **ops,
+				  uint16_t nb_ops);
+/**< @internal Dequeue a burst of scan response from a queue on RegEx device. */
+
+/**
+ * RegEx device operations
+ */
+struct rte_regexdev_ops {
+	regexdev_info_get_t dev_info_get;
+	regexdev_configure_t dev_configure;
+	regexdev_qp_setup_t dev_qp_setup;
+	regexdev_start_t dev_start;
+	regexdev_stop_t dev_stop;
+	regexdev_close_t dev_close;
+	regexdev_attr_get_t dev_attr_get;
+	regexdev_attr_set_t dev_attr_set;
+	regexdev_rule_db_update_t dev_rule_db_update;
+	regexdev_rule_db_compile_activate_t dev_rule_db_compile_activate;
+	regexdev_rule_db_import_t dev_db_import;
+	regexdev_rule_db_export_t dev_db_export;
+	regexdev_xstats_names_get_t dev_xstats_names_get;
+	regexdev_xstats_get_t dev_xstats_get;
+	regexdev_xstats_by_name_get_t dev_xstats_by_name_get;
+	regexdev_xstats_reset_t dev_xstats_reset;
+	regexdev_selftest_t dev_selftest;
+	regexdev_dump_t dev_dump;
+};
+
+/**
+ * @internal
+ * The generic data structure associated with each RegEx device.
+ *
+ * Pointers to burst-oriented packet receive and transmit functions are
+ * located at the beginning of the structure, along with the pointer to
+ * where all the data elements for the particular device are stored in shared
+ * memory. This split allows the function pointer and driver data to be per-
+ * process, while the actual configuration data for the device is shared.
+ */
+struct rte_regexdev {
+	regexdev_enqueue_t enqueue;
+	regexdev_dequeue_t dequeue;
+	const struct rte_regexdev_ops *dev_ops;
+	/**< Functions exported by PMD */
+	struct rte_device *device; /**< Backing device */
+} __rte_cache_aligned;
+
+#endif /* _RTE_REGEX_CORE_H_ */
-- 
1.8.3.1


^ permalink raw reply	[flat|nested] 96+ messages in thread

* [dpdk-dev] [PATCH v1 3/4] regexdev: add regexdev core functions
  2020-03-29  6:47 [dpdk-dev] [PATCH v1 0/4] add RegEx class Ori Kam
  2020-03-29  6:47 ` [dpdk-dev] [PATCH v1 1/4] regexdev: introduce regexdev subsystem Ori Kam
  2020-03-29  6:47 ` [dpdk-dev] [PATCH v1 2/4] regexdev: add regex core h file Ori Kam
@ 2020-03-29  6:47 ` Ori Kam
  2020-04-04 15:01   ` [dpdk-dev] [EXT] " Pavan Nikhilesh Bhagavatula
  2020-03-29  6:47 ` [dpdk-dev] [PATCH v1 4/4] regexdev: implement regex rte level functions Ori Kam
                   ` (5 subsequent siblings)
  8 siblings, 1 reply; 96+ messages in thread
From: Ori Kam @ 2020-03-29  6:47 UTC (permalink / raw)
  To: jerinj, xiang.w.wang
  Cc: dev, pbhagavatula, shahafs, hemant.agrawal, opher, alexr, dovrat,
	pkapoor, nipun.gupta, bruce.richardson, yang.a.hong, harry.chang,
	gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai, yuyingxia,
	fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc, jim,
	hongjun.ni, j.bromhead, deri, fc, arthur.su, thomas, orika,
	Parav Pandit

This commit introduce the API that is needed by the RegEx devices in
order to work with the RegEX lib.

During the probe of a RegEx device, the device should configure itself,
and allocate the resources it requires.
On completion of the device init, it should call the
rte_regex_dev_register in order to register itself as a RegEx device.

Signed-off-by: Ori Kam <orika@mellanox.com>
Signed-off-by: Parav Pandit <parav@mellanox.com>
---
 config/common_base                        |  3 +-
 config/meson.build                        |  1 +
 lib/librte_regexdev/Makefile              |  1 +
 lib/librte_regexdev/meson.build           |  5 ++-
 lib/librte_regexdev/rte_regexdev.c        | 74 ++++++++++++++++++++++++++++++-
 lib/librte_regexdev/rte_regexdev.h        |  7 +++
 lib/librte_regexdev/rte_regexdev_core.h   |  2 +
 lib/librte_regexdev/rte_regexdev_driver.h | 50 +++++++++++++++++++++
 meson_options.txt                         |  2 +
 9 files changed, 142 insertions(+), 3 deletions(-)
 create mode 100644 lib/librte_regexdev/rte_regexdev_driver.h

diff --git a/config/common_base b/config/common_base
index 58c0865..f6466a8 100644
--- a/config/common_base
+++ b/config/common_base
@@ -819,10 +819,11 @@ CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_EP_RAWDEV=y
 CONFIG_RTE_LIBRTE_PMD_NTB_RAWDEV=y
 
 #
-# Compile regex device support
+# Compile RexEx device support
 #
 CONFIG_RTE_LIBRTE_REGEXDEV=y
 CONFIG_RTE_LIBRTE_REGEXDEV_DEBUG=n
+CONFIG_RTE_MAX_REGEXDEV_DEVS=32
 
 #
 # Compile librte_ring
diff --git a/config/meson.build b/config/meson.build
index abedd76..fb05639 100644
--- a/config/meson.build
+++ b/config/meson.build
@@ -221,6 +221,7 @@ endforeach
 dpdk_conf.set('RTE_MAX_LCORE', get_option('max_lcores'))
 dpdk_conf.set('RTE_MAX_NUMA_NODES', get_option('max_numa_nodes'))
 dpdk_conf.set('RTE_MAX_ETHPORTS', get_option('max_ethports'))
+dpdk_conf.set('RTE_MAX_REGEXDEV_DEVS', get_option('max_regexdev_devs'))
 dpdk_conf.set('RTE_LIBEAL_USE_HPET', get_option('use_hpet'))
 # values which have defaults which may be overridden
 dpdk_conf.set('RTE_MAX_VFIO_GROUPS', 64)
diff --git a/lib/librte_regexdev/Makefile b/lib/librte_regexdev/Makefile
index 9012d29..6ba09f0 100644
--- a/lib/librte_regexdev/Makefile
+++ b/lib/librte_regexdev/Makefile
@@ -25,6 +25,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_REGEXDEV) := rte_regexdev.c
 # export include files
 SYMLINK-$(CONFIG_RTE_LIBRTE_REGEXDEV)-include += rte_regexdev.h
 SYMLINK-$(CONFIG_RTE_LIBRTE_REGEXDEV)-include += rte_regexdev_core.h
+SYMLINK-$(CONFIG_RTE_LIBRTE_REGEXDEV)-include += rte_regexdev_driver.h
 
 # versioning export map
 EXPORT_MAP := rte_regexdev_version.map
diff --git a/lib/librte_regexdev/meson.build b/lib/librte_regexdev/meson.build
index 1816754..719ee82 100644
--- a/lib/librte_regexdev/meson.build
+++ b/lib/librte_regexdev/meson.build
@@ -1,7 +1,10 @@
 # SPDX-License-Identifier: BSD-3-Clause
 # Copyright(c) 2020 Mellanox Corporation
 
+name = 'regexdev'
 allow_experimental_apis = true
 sources = files('rte_regexdev.c')
-headers = files('rte_regexdev.h', 'rte_regexdev_core.h')
+headers = files('rte_regexdev.h',
+	'rte_regexdev_core.h',
+	'rte_regexdev_driver.h')
 deps += ['mbuf']
diff --git a/lib/librte_regexdev/rte_regexdev.c b/lib/librte_regexdev/rte_regexdev.c
index b901877..4396bb5 100644
--- a/lib/librte_regexdev/rte_regexdev.c
+++ b/lib/librte_regexdev/rte_regexdev.c
@@ -3,4 +3,76 @@
  * Copyright(C) 2020 Mellanox International Ltd.
  */
 
-#include <rte_regexdev.h>
+#include <string.h>
+
+#include <rte_spinlock.h>
+#include <rte_memory.h>
+#include <rte_memcpy.h>
+#include <rte_memzone.h>
+#include <rte_string_fns.h>
+
+#include "rte_regexdev.h"
+#include "rte_regexdev_driver.h"
+
+static struct rte_regexdev *regex_devices[RTE_MAX_REGEXDEV_DEVS];
+
+int rte_regexdev_logtype;
+
+static uint16_t
+regexdev_find_free_dev(void)
+{
+	uint16_t i;
+
+	for (i = 0; i < RTE_MAX_REGEXDEV_DEVS; i++) {
+		if (regex_devices[i] == NULL)
+			return i;
+	}
+	return RTE_MAX_REGEXDEV_DEVS;
+}
+
+static const struct rte_regexdev*
+regexdev_allocated(const char *name)
+{
+	uint16_t i;
+
+	for (i = 0; i < RTE_MAX_REGEXDEV_DEVS; i++) {
+		if (regex_devices[i] != NULL)
+			if (!strcmp(name, regex_devices[i]->dev_name))
+				return regex_devices[i];
+	}
+	return NULL;
+}
+
+int
+rte_regexdev_register(struct rte_regexdev *dev)
+{
+	uint16_t dev_id;
+	int res;
+
+	if (dev->dev_ops == NULL) {
+		RTE_REGEXDEV_LOG(ERR, "RegEx device invalid device ops\n");
+		return -EINVAL;
+	}
+	if (regexdev_allocated(dev->dev_name) != NULL) {
+		RTE_REGEXDEV_LOG
+			(ERR, "RegEx device with name %s already allocated\n",
+			 dev->dev_name);
+		return -ENOMEM;
+	}
+	dev_id = regexdev_find_free_dev();
+	if (dev_id == RTE_MAX_REGEXDEV_DEVS) {
+		RTE_REGEXDEV_LOG
+			(ERR, "Reached maximum number of regex devs\n");
+		return -ENOMEM;
+	}
+	dev->dev_id = dev_id;
+	regex_devices[dev_id] = dev;
+	res = dev_id;
+	return res;
+}
+
+void
+rte_regexdev_unregister(struct rte_regexdev *dev)
+{
+	regex_devices[dev->dev_id] = NULL;
+}
diff --git a/lib/librte_regexdev/rte_regexdev.h b/lib/librte_regexdev/rte_regexdev.h
index bbc56f9..d901417 100644
--- a/lib/librte_regexdev/rte_regexdev.h
+++ b/lib/librte_regexdev/rte_regexdev.h
@@ -206,6 +206,13 @@
 #include <rte_mbuf.h>
 #include <rte_memory.h>
 
+#define RTE_REGEX_NAME_MAX_LEN RTE_DEV_NAME_MAX_LEN
+
+extern int rte_regexdev_logtype;
+
+#define RTE_REGEXDEV_LOG(level, ...) \
+	rte_log(RTE_LOG_ ## level, rte_regexdev_logtype, "" __VA_ARGS__)
+
 /**
  * @warning
  * @b EXPERIMENTAL: this API may change without prior notice.
diff --git a/lib/librte_regexdev/rte_regexdev_core.h b/lib/librte_regexdev/rte_regexdev_core.h
index e30865d..e380f84 100644
--- a/lib/librte_regexdev/rte_regexdev_core.h
+++ b/lib/librte_regexdev/rte_regexdev_core.h
@@ -142,6 +142,8 @@ struct rte_regexdev {
 	const struct rte_regexdev_ops *dev_ops;
 	/**< Functions exported by PMD */
 	struct rte_device *device; /**< Backing device */
+	char dev_name[RTE_REGEX_NAME_MAX_LEN]; /**< Unique identifier name */
+	uint16_t dev_id; /**< Device [external]  identifier. */
 } __rte_cache_aligned;
 
 #endif /* _RTE_REGEX_CORE_H_ */
diff --git a/lib/librte_regexdev/rte_regexdev_driver.h b/lib/librte_regexdev/rte_regexdev_driver.h
new file mode 100644
index 0000000..cb18640
--- /dev/null
+++ b/lib/librte_regexdev/rte_regexdev_driver.h
@@ -0,0 +1,50 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2020 Mellanox Corporation
+ */
+
+#ifndef _RTE_REGEXDEV_DRIVER_H_
+#define _RTE_REGEXDEV_DRIVER_H_
+
+/**
+ * @file
+ *
+ * RTE RegEx Device PMD API
+ *
+ * APIs that are used by the RegEx drivers, to comunicate with the
+ * RegEx lib.
+ */
+
+#include "rte_regexdev.h"
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/**
+ * @internal
+ * Register a new regexdev slot for a RegEx device and returns the id
+ * to that slot for the driver to use.
+ *
+ * @param dev
+ *   RegEx device structure..
+ *
+ * @return
+ *   Slot in the rte_regex_devices array for a new device in case of success,
+ *   negative errno otherwise.
+ */
+int rte_regexdev_register(struct rte_regexdev *dev);
+
+/**
+ * @internal
+ * Unregister the specified regexdev port.
+ *
+ * @param dev
+ *   Device to be released.
+ */
+void rte_regexdev_unregister(struct rte_regexdev *dev);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_REGEXDEV_DRIVER_H_ */
diff --git a/meson_options.txt b/meson_options.txt
index 9e4923a..7e54d8a 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -30,6 +30,8 @@ option('max_lcores', type: 'integer', value: 128,
 	description: 'maximum number of cores/threads supported by EAL')
 option('max_numa_nodes', type: 'integer', value: 4,
 	description: 'maximum number of NUMA nodes supported by EAL')
+option('max_regexdev_devs', type: 'integer', value: 32,
+	description: 'maximum number of RegEx devices')
 option('tests', type: 'boolean', value: true,
 	description: 'build unit tests')
 option('use_hpet', type: 'boolean', value: false,
-- 
1.8.3.1


^ permalink raw reply	[flat|nested] 96+ messages in thread

* [dpdk-dev] [PATCH v1 4/4] regexdev: implement regex rte level functions
  2020-03-29  6:47 [dpdk-dev] [PATCH v1 0/4] add RegEx class Ori Kam
                   ` (2 preceding siblings ...)
  2020-03-29  6:47 ` [dpdk-dev] [PATCH v1 3/4] regexdev: add regexdev core functions Ori Kam
@ 2020-03-29  6:47 ` Ori Kam
  2020-04-04 14:27   ` [dpdk-dev] [EXT] " Pavan Nikhilesh Bhagavatula
  2020-04-04 13:06 ` [dpdk-dev] [EXT] [PATCH v1 0/4] add RegEx class Pavan Nikhilesh Bhagavatula
                   ` (4 subsequent siblings)
  8 siblings, 1 reply; 96+ messages in thread
From: Ori Kam @ 2020-03-29  6:47 UTC (permalink / raw)
  To: jerinj, xiang.w.wang
  Cc: dev, pbhagavatula, shahafs, hemant.agrawal, opher, alexr, dovrat,
	pkapoor, nipun.gupta, bruce.richardson, yang.a.hong, harry.chang,
	gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai, yuyingxia,
	fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc, jim,
	hongjun.ni, j.bromhead, deri, fc, arthur.su, thomas, orika

This commit implements all the RegEx public API.

Signed-off-by: Ori Kam <orika@mellanox.com>
---
 lib/librte_regexdev/rte_regexdev.c | 298 +++++++++++++++++++++++++++++++++++++
 1 file changed, 298 insertions(+)

diff --git a/lib/librte_regexdev/rte_regexdev.c b/lib/librte_regexdev/rte_regexdev.c
index 4396bb5..72f18fb 100644
--- a/lib/librte_regexdev/rte_regexdev.c
+++ b/lib/librte_regexdev/rte_regexdev.c
@@ -76,3 +76,301 @@
 {
 	regex_devices[dev->dev_id] = NULL;
 }
+
+uint8_t
+rte_regexdev_count(void)
+{
+	int i;
+	int count = 0;
+
+	for (i = 0; i < RTE_MAX_REGEXDEV_DEVS; i++) {
+		if (regex_devices[i] != NULL)
+			count++;
+	}
+	return count;
+}
+
+int
+rte_regexdev_get_dev_id(const char *name)
+{
+	int i;
+	int id = -EINVAL;
+
+	if (name == NULL)
+		return -EINVAL;
+	for (i = 0; i < RTE_MAX_REGEXDEV_DEVS; i++) {
+		if (regex_devices[i] != NULL)
+			if (strcmp(name, regex_devices[i]->dev_name)) {
+				id = regex_devices[i]->dev_id;
+				break;
+			}
+	}
+	return id;
+}
+
+int
+rte_regexdev_info_get(uint8_t dev_id, struct rte_regexdev_info *dev_info)
+{
+	if (dev_id >= RTE_MAX_REGEXDEV_DEVS)
+		return -EINVAL;
+	if (regex_devices[dev_id] == NULL)
+		return -EINVAL;
+	if (dev_info == NULL)
+		return -EINVAL;
+	if (regex_devices[dev_id]->dev_ops->dev_info_get == NULL)
+		return -ENOTSUP;
+	return regex_devices[dev_id]->dev_ops->dev_info_get
+		(regex_devices[dev_id], dev_info);
+}
+
+int
+rte_regexdev_configure(uint8_t dev_id, const struct rte_regexdev_config *cfg)
+{
+	if (dev_id >= RTE_MAX_REGEXDEV_DEVS)
+		return -EINVAL;
+	if (regex_devices[dev_id] == NULL)
+		return -EINVAL;
+	if (cfg == NULL)
+		return -EINVAL;
+	if (regex_devices[dev_id]->dev_ops->dev_configure == NULL)
+		return -ENOTSUP;
+	return regex_devices[dev_id]->dev_ops->dev_configure
+		(regex_devices[dev_id], cfg);
+}
+
+int
+rte_regexdev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
+			   const struct rte_regexdev_qp_conf *qp_conf)
+{
+	if (dev_id >= RTE_MAX_REGEXDEV_DEVS)
+		return -EINVAL;
+	if (regex_devices[dev_id] == NULL)
+		return -EINVAL;
+	if (regex_devices[dev_id]->dev_ops->dev_qp_setup == NULL)
+		return -ENOTSUP;
+	return regex_devices[dev_id]->dev_ops->dev_qp_setup
+		(regex_devices[dev_id], queue_pair_id, qp_conf);
+}
+
+int
+rte_regexdev_start(uint8_t dev_id)
+{
+	if (dev_id >= RTE_MAX_REGEXDEV_DEVS)
+		return -EINVAL;
+	if (regex_devices[dev_id] == NULL)
+		return -EINVAL;
+	if (regex_devices[dev_id]->dev_ops->dev_start == NULL)
+		return -ENOTSUP;
+	return regex_devices[dev_id]->dev_ops->dev_start(regex_devices[dev_id]);
+}
+
+void
+rte_regexdev_stop(uint8_t dev_id)
+{
+	if (dev_id >= RTE_MAX_REGEXDEV_DEVS)
+		return;
+	if (regex_devices[dev_id] == NULL)
+		return;
+	regex_devices[dev_id]->dev_ops->dev_stop(regex_devices[dev_id]);
+}
+
+int
+rte_regexdev_close(uint8_t dev_id)
+{
+	if (dev_id >= RTE_MAX_REGEXDEV_DEVS)
+		return -EINVAL;
+	if (regex_devices[dev_id] == NULL)
+		return -EINVAL;
+	if (regex_devices[dev_id]->dev_ops->dev_close == NULL)
+		return -ENOTSUP;
+	regex_devices[dev_id]->dev_ops->dev_close(regex_devices[dev_id]);
+	return 0;
+}
+
+int
+rte_regexdev_attr_get(uint8_t dev_id, enum rte_regexdev_attr_id attr_id,
+		      void *attr_value)
+{
+	if (dev_id >= RTE_MAX_REGEXDEV_DEVS)
+		return -EINVAL;
+	if (regex_devices[dev_id] == NULL)
+		return -EINVAL;
+	if (regex_devices[dev_id]->dev_ops->dev_attr_get == NULL)
+		return -ENOTSUP;
+	return regex_devices[dev_id]->dev_ops->dev_attr_get
+		(regex_devices[dev_id], attr_id, attr_value);
+}
+
+int
+rte_regexdev_attr_set(uint8_t dev_id, enum rte_regexdev_attr_id attr_id,
+		      const void *attr_value)
+{
+	if (dev_id >= RTE_MAX_REGEXDEV_DEVS)
+		return -EINVAL;
+	if (regex_devices[dev_id] == NULL)
+		return -EINVAL;
+	if (regex_devices[dev_id]->dev_ops->dev_attr_set == NULL)
+		return -ENOTSUP;
+	return regex_devices[dev_id]->dev_ops->dev_attr_set
+		(regex_devices[dev_id], attr_id, attr_value);
+}
+
+int
+rte_regexdev_rule_db_update(uint8_t dev_id,
+			    const struct rte_regexdev_rule *rules,
+			    uint32_t nb_rules)
+{
+	if (dev_id >= RTE_MAX_REGEXDEV_DEVS)
+		return -EINVAL;
+	if (regex_devices[dev_id] == NULL)
+		return -EINVAL;
+	if (regex_devices[dev_id]->dev_ops->dev_rule_db_update == NULL)
+		return -ENOTSUP;
+	return regex_devices[dev_id]->dev_ops->dev_rule_db_update
+		(regex_devices[dev_id], rules, nb_rules);
+}
+
+int
+rte_regexdev_rule_db_compile_activate(uint8_t dev_id)
+{
+	if (dev_id >= RTE_MAX_REGEXDEV_DEVS)
+		return -EINVAL;
+	if (regex_devices[dev_id] == NULL)
+		return -EINVAL;
+	if (regex_devices[dev_id]->dev_ops->dev_rule_db_compile_activate ==
+	    NULL)
+		return -ENOTSUP;
+	return regex_devices[dev_id]->dev_ops->dev_rule_db_compile_activate
+		(regex_devices[dev_id]);
+}
+
+int
+rte_regexdev_rule_db_import(uint8_t dev_id, const char *rule_db,
+			    uint32_t rule_db_len)
+{
+	if (dev_id >= RTE_MAX_REGEXDEV_DEVS)
+		return -EINVAL;
+	if (regex_devices[dev_id] == NULL)
+		return -EINVAL;
+	if (rule_db == NULL)
+		return -EINVAL;
+	if (regex_devices[dev_id]->dev_ops->dev_db_import == NULL)
+		return -ENOTSUP;
+	return regex_devices[dev_id]->dev_ops->dev_db_import
+		(regex_devices[dev_id], rule_db, rule_db_len);
+}
+
+int
+rte_regexdev_rule_db_export(uint8_t dev_id, char *rule_db)
+{
+	if (dev_id >= RTE_MAX_REGEXDEV_DEVS)
+		return -EINVAL;
+	if (regex_devices[dev_id] == NULL)
+		return -EINVAL;
+	if (regex_devices[dev_id]->dev_ops->dev_db_export == NULL)
+		return -ENOTSUP;
+	return regex_devices[dev_id]->dev_ops->dev_db_export
+		(regex_devices[dev_id], rule_db);
+}
+
+int
+rte_regexdev_xstats_names_get(uint8_t dev_id,
+			      struct rte_regexdev_xstats_map *xstats_map)
+{
+	if (dev_id >= RTE_MAX_REGEXDEV_DEVS)
+		return -EINVAL;
+	if (regex_devices[dev_id] == NULL)
+		return -EINVAL;
+	if (xstats_map == NULL)
+		return -EINVAL;
+	if (regex_devices[dev_id]->dev_ops->dev_xstats_names_get == NULL)
+		return -ENOTSUP;
+	return regex_devices[dev_id]->dev_ops->dev_xstats_names_get
+		(regex_devices[dev_id], xstats_map);
+}
+
+int
+rte_regexdev_xstats_get(uint8_t dev_id, const uint16_t *ids,
+			uint64_t *values, uint16_t n)
+{
+	if (dev_id >= RTE_MAX_REGEXDEV_DEVS)
+		return -EINVAL;
+	if (regex_devices[dev_id] == NULL)
+		return -EINVAL;
+	if (regex_devices[dev_id]->dev_ops->dev_xstats_get == NULL)
+		return -ENOTSUP;
+	return regex_devices[dev_id]->dev_ops->dev_xstats_get
+		(regex_devices[dev_id], ids, values, n);
+}
+
+int
+rte_regexdev_xstats_by_name_get(uint8_t dev_id, const char *name,
+				uint16_t *id, uint64_t *value)
+{
+	if (dev_id >= RTE_MAX_REGEXDEV_DEVS)
+		return -EINVAL;
+	if (regex_devices[dev_id] == NULL)
+		return -EINVAL;
+	if (regex_devices[dev_id]->dev_ops->dev_xstats_by_name_get == NULL)
+		return -ENOTSUP;
+	return regex_devices[dev_id]->dev_ops->dev_xstats_by_name_get
+		(regex_devices[dev_id], name, id, value);
+}
+
+int
+rte_regexdev_xstats_reset(uint8_t dev_id, const uint16_t *ids,
+			  uint16_t nb_ids)
+{
+	if (dev_id >= RTE_MAX_REGEXDEV_DEVS)
+		return -EINVAL;
+	if (regex_devices[dev_id] == NULL)
+		return -EINVAL;
+	if (regex_devices[dev_id]->dev_ops->dev_xstats_reset == NULL)
+		return -ENOTSUP;
+	return regex_devices[dev_id]->dev_ops->dev_xstats_reset
+		(regex_devices[dev_id], ids, nb_ids);
+}
+
+int
+rte_regexdev_selftest(uint8_t dev_id)
+{
+	if (dev_id >= RTE_MAX_REGEXDEV_DEVS)
+		return -EINVAL;
+	if (regex_devices[dev_id] == NULL)
+		return -EINVAL;
+	if (regex_devices[dev_id]->dev_ops->dev_selftest == NULL)
+		return -ENOTSUP;
+	return regex_devices[dev_id]->dev_ops->dev_selftest
+		(regex_devices[dev_id]);
+}
+
+int
+rte_regexdev_dump(uint8_t dev_id, FILE *f)
+{
+	if (dev_id >= RTE_MAX_REGEXDEV_DEVS)
+		return -EINVAL;
+	if (regex_devices[dev_id] == NULL)
+		return -EINVAL;
+	if (f == NULL)
+		return -EINVAL;
+	if (regex_devices[dev_id]->dev_ops->dev_dump == NULL)
+		return -ENOTSUP;
+	return regex_devices[dev_id]->dev_ops->dev_dump
+		(regex_devices[dev_id], f);
+}
+
+uint16_t
+rte_regexdev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
+			   struct rte_regex_ops **ops, uint16_t nb_ops)
+{
+	return regex_devices[dev_id]->enqueue(regex_devices[dev_id], qp_id,
+					      ops, nb_ops);
+}
+
+uint16_t
+rte_regexdev_dequeue_burst(uint8_t dev_id, uint16_t qp_id,
+			   struct rte_regex_ops **ops, uint16_t nb_ops)
+{
+	return regex_devices[dev_id]->dequeue(regex_devices[dev_id], qp_id,
+					      ops, nb_ops);
+}
-- 
1.8.3.1


^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 0/4] add RegEx class
  2020-03-29  6:47 [dpdk-dev] [PATCH v1 0/4] add RegEx class Ori Kam
                   ` (3 preceding siblings ...)
  2020-03-29  6:47 ` [dpdk-dev] [PATCH v1 4/4] regexdev: implement regex rte level functions Ori Kam
@ 2020-04-04 13:06 ` Pavan Nikhilesh Bhagavatula
  2020-04-05 15:03   ` Ori Kam
  2020-04-17 12:43 ` [dpdk-dev] [PATCH v2 " Ori Kam
                   ` (3 subsequent siblings)
  8 siblings, 1 reply; 96+ messages in thread
From: Pavan Nikhilesh Bhagavatula @ 2020-04-04 13:06 UTC (permalink / raw)
  To: Ori Kam, Jerin Jacob Kollanukkaran, xiang.w.wang
  Cc: dev, shahafs, hemant.agrawal, opher, alexr, Dovrat Zifroni,
	Prasun Kapoor, nipun.gupta, bruce.richardson, yang.a.hong,
	harry.chang, gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai,
	yuyingxia, fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc,
	jim, hongjun.ni, j.bromhead, deri, fc, arthur.su, thomas

Hi Ori, 

Looks like the series is missing support for virtual devices i.e. vdev 
@see rte_eventdev_pmd_vdev.h, rte_ethdev_vdev.h.

Hyperscan and PCRE based regexdev would need vdev support.

Thanks,
Pavan.

>This patch set adds the RegEx class, which enables RegEx pattern
>matching, both on HW/SW PMDs.
>
>Example for applications that will benefit from this class:
>* Next Generation Firewalls (NGFW)
>* Deep Packet and Flow Inspection (DPI)
>* Intrusion Prevention Systems (IPS)
>* DDoS Mitigation
>* Network Monitoring
>* Data Loss Prevention (DLP)
>* Smart NICs
>* Grammar based content processing
>* URL, spam and adware filtering
>* Advanced auditing and policing of user/application security policies
>* Financial data mining - parsing of streamed financial feeds
>* Application recognition.
>* Dmemory introspection.
>* Natural Language Processing (NLP)
>* Sentiment Analysis.
>* Big data databse acceleration.
>* Computational storage.
>
>This patch set is based on RFC[1]
>
>This class should be merged only after there is at least
>one PMD that implements it. Also the test application will
>be added when the first PMD is added.
>
>
>
>[1] https://urldefense.proofpoint.com/v2/url?u=https-
>3A__patches.dpdk.org_patch_66501_&d=DwIDaQ&c=nKjWec2b6R0mO
>yPaz7xtfQ&r=E3SgYMjtKCMVsB-fmvgGV3o-
>g_fjLhk5Pupi9ijohpc&m=bE-
>KQdo2pQktvXoSvAAe5ppq2423AEYlpW5MTK90UyY&s=qLgLlewFToFlkH
>yUBQcGVYU6fG2t5yNg2uAz7h_OlVA&e=
>
>Jerin Jacob (1):
>  regexdev: introduce regexdev subsystem
>
>Ori Kam (3):
>  regexdev: add regex core h file
>  regexdev: add regexdev core functions
>  regexdev: implement regex rte level functions
>
> config/common_base                           |    8 +
> config/meson.build                           |    1 +
> doc/api/doxy-api-index.md                    |    1 +
> doc/api/doxy-api.conf.in                     |    1 +
> doc/guides/prog_guide/index.rst              |    1 +
> doc/guides/prog_guide/regexdev_lib.rst       |  177 +++
> lib/Makefile                                 |    2 +
> lib/librte_regexdev/Makefile                 |   33 +
> lib/librte_regexdev/meson.build              |   10 +
> lib/librte_regexdev/rte_regexdev.c           |  376 +++++++
> lib/librte_regexdev/rte_regexdev.h           | 1482
>++++++++++++++++++++++++++
> lib/librte_regexdev/rte_regexdev_core.h      |  149 +++
> lib/librte_regexdev/rte_regexdev_driver.h    |   50 +
> lib/librte_regexdev/rte_regexdev_version.map |   26 +
> lib/meson.build                              |    3 +-
> meson_options.txt                            |    2 +
> 16 files changed, 2321 insertions(+), 1 deletion(-)
> create mode 100644 doc/guides/prog_guide/regexdev_lib.rst
> create mode 100644 lib/librte_regexdev/Makefile
> create mode 100644 lib/librte_regexdev/meson.build
> create mode 100644 lib/librte_regexdev/rte_regexdev.c
> create mode 100644 lib/librte_regexdev/rte_regexdev.h
> create mode 100644 lib/librte_regexdev/rte_regexdev_core.h
> create mode 100644 lib/librte_regexdev/rte_regexdev_driver.h
> create mode 100644 lib/librte_regexdev/rte_regexdev_version.map
>
>--
>1.8.3.1


^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 4/4] regexdev: implement regex rte level functions
  2020-03-29  6:47 ` [dpdk-dev] [PATCH v1 4/4] regexdev: implement regex rte level functions Ori Kam
@ 2020-04-04 14:27   ` Pavan Nikhilesh Bhagavatula
  2020-04-05 15:04     ` Ori Kam
  0 siblings, 1 reply; 96+ messages in thread
From: Pavan Nikhilesh Bhagavatula @ 2020-04-04 14:27 UTC (permalink / raw)
  To: Ori Kam, Jerin Jacob Kollanukkaran, xiang.w.wang
  Cc: dev, shahafs, hemant.agrawal, opher, alexr, Dovrat Zifroni,
	Prasun Kapoor, nipun.gupta, bruce.richardson, yang.a.hong,
	harry.chang, gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai,
	yuyingxia, fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc,
	jim, hongjun.ni, j.bromhead, deri, fc, arthur.su, thomas

>This commit implements all the RegEx public API.
>
>Signed-off-by: Ori Kam <orika@mellanox.com>
>---
> lib/librte_regexdev/rte_regexdev.c | 298
>+++++++++++++++++++++++++++++++++++++
> 1 file changed, 298 insertions(+)
>
>diff --git a/lib/librte_regexdev/rte_regexdev.c
>b/lib/librte_regexdev/rte_regexdev.c
>index 4396bb5..72f18fb 100644
>--- a/lib/librte_regexdev/rte_regexdev.c
>+++ b/lib/librte_regexdev/rte_regexdev.c
>@@ -76,3 +76,301 @@
> {
> 	regex_devices[dev->dev_id] = NULL;
> }
>+

<snip>

>+
>+int
>+rte_regexdev_info_get(uint8_t dev_id, struct rte_regexdev_info
>*dev_info)
>+{
>+	if (dev_id >= RTE_MAX_REGEXDEV_DEVS)
>+		return -EINVAL;

We should use macro for this similar to ethdev/eventdev across the file.

RTE_ETH_VALID_PORTID_OR_ERR_RET
RTE_FUNC_PTR_OR_ERR_RET


>+	if (regex_devices[dev_id] == NULL)
>+		return -EINVAL;
>+	if (dev_info == NULL)
>+		return -EINVAL;
>+	if (regex_devices[dev_id]->dev_ops->dev_info_get == NULL)
>+		return -ENOTSUP;
>+	return regex_devices[dev_id]->dev_ops->dev_info_get
>+		(regex_devices[dev_id], dev_info);
>+}
>+
>+int
>+rte_regexdev_configure(uint8_t dev_id, const struct
>rte_regexdev_config *cfg)
>+{
>+	if (dev_id >= RTE_MAX_REGEXDEV_DEVS)
>+		return -EINVAL;
>+	if (regex_devices[dev_id] == NULL)
>+		return -EINVAL;
>+	if (cfg == NULL)
>+		return -EINVAL;

Please handle re-configure cases, add error checks for cfg passed based on dev info.

>+	if (regex_devices[dev_id]->dev_ops->dev_configure == NULL)
>+		return -ENOTSUP;
>+	return regex_devices[dev_id]->dev_ops->dev_configure
>+		(regex_devices[dev_id], cfg);
>+}
>+

<Snip>

>+
>+uint16_t
>+rte_regexdev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
>+			   struct rte_regex_ops **ops, uint16_t nb_ops)
>+{
>+	return regex_devices[dev_id]-
>>enqueue(regex_devices[dev_id], qp_id,
>+					      ops, nb_ops);
>+}

Move these functions to .h in-lining them.
Also, please add debug checks @see rte_eth_rx_burst/rte_eth_tx_burst.

>+
>+uint16_t
>+rte_regexdev_dequeue_burst(uint8_t dev_id, uint16_t qp_id,
>+			   struct rte_regex_ops **ops, uint16_t nb_ops)
>+{
>+	return regex_devices[dev_id]-
>>dequeue(regex_devices[dev_id], qp_id,
>+					      ops, nb_ops);
>+}
>--
>1.8.3.1


^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core functions
  2020-03-29  6:47 ` [dpdk-dev] [PATCH v1 3/4] regexdev: add regexdev core functions Ori Kam
@ 2020-04-04 15:01   ` Pavan Nikhilesh Bhagavatula
  2020-04-05 15:05     ` Ori Kam
  0 siblings, 1 reply; 96+ messages in thread
From: Pavan Nikhilesh Bhagavatula @ 2020-04-04 15:01 UTC (permalink / raw)
  To: Ori Kam, Jerin Jacob Kollanukkaran, xiang.w.wang
  Cc: dev, shahafs, hemant.agrawal, opher, alexr, Dovrat Zifroni,
	Prasun Kapoor, nipun.gupta, bruce.richardson, yang.a.hong,
	harry.chang, gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai,
	yuyingxia, fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc,
	jim, hongjun.ni, j.bromhead, deri, fc, arthur.su, thomas,
	Parav Pandit

Looks like this implementation is incomplete?
I don't see any pmd specific helper functions for @see rte_cryptodev_pmd.c, rte_eventdev_pmd*

>This commit introduce the API that is needed by the RegEx devices in
>order to work with the RegEX lib.
>
>During the probe of a RegEx device, the device should configure itself,
>and allocate the resources it requires.
>On completion of the device init, it should call the
>rte_regex_dev_register in order to register itself as a RegEx device.
>
>Signed-off-by: Ori Kam <orika@mellanox.com>
>Signed-off-by: Parav Pandit <parav@mellanox.com>
>---
> config/common_base                        |  3 +-
> config/meson.build                        |  1 +
> lib/librte_regexdev/Makefile              |  1 +
> lib/librte_regexdev/meson.build           |  5 ++-
> lib/librte_regexdev/rte_regexdev.c        | 74
>++++++++++++++++++++++++++++++-
> lib/librte_regexdev/rte_regexdev.h        |  7 +++
> lib/librte_regexdev/rte_regexdev_core.h   |  2 +
> lib/librte_regexdev/rte_regexdev_driver.h | 50
>+++++++++++++++++++++
> meson_options.txt                         |  2 +
> 9 files changed, 142 insertions(+), 3 deletions(-)
> create mode 100644 lib/librte_regexdev/rte_regexdev_driver.h
>

<snip>

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 1/4] regexdev: introduce regexdev subsystem
  2020-03-29  6:47 ` [dpdk-dev] [PATCH v1 1/4] regexdev: introduce regexdev subsystem Ori Kam
@ 2020-04-04 15:04   ` Pavan Nikhilesh Bhagavatula
  2020-04-05 15:03     ` Ori Kam
  0 siblings, 1 reply; 96+ messages in thread
From: Pavan Nikhilesh Bhagavatula @ 2020-04-04 15:04 UTC (permalink / raw)
  To: Ori Kam, Jerin Jacob Kollanukkaran, xiang.w.wang
  Cc: dev, shahafs, hemant.agrawal, opher, alexr, Dovrat Zifroni,
	Prasun Kapoor, nipun.gupta, bruce.richardson, yang.a.hong,
	harry.chang, gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai,
	yuyingxia, fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc,
	jim, hongjun.ni, j.bromhead, deri, fc, arthur.su, thomas

<Snip>

> #
>+# Compile regex device support
>+#
>+CONFIG_RTE_LIBRTE_REGEXDEV=y
>+CONFIG_RTE_LIBRTE_REGEXDEV_DEBUG=n

The above flag is never used in the patchset.

>+
>+#
> # Compile librte_ring
> #
> CONFIG_RTE_LIBRTE_RING=y
>@@ -1111,3 +1117,4 @@ CONFIG_RTE_APP_CRYPTO_PERF=y
> # Compile the eventdev application
> #
> CONFIG_RTE_APP_EVENTDEV=y
>+


^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 1/4] regexdev: introduce regexdev subsystem
  2020-04-04 15:04   ` [dpdk-dev] [EXT] " Pavan Nikhilesh Bhagavatula
@ 2020-04-05 15:03     ` Ori Kam
  0 siblings, 0 replies; 96+ messages in thread
From: Ori Kam @ 2020-04-05 15:03 UTC (permalink / raw)
  To: Pavan Nikhilesh Bhagavatula, Jerin Jacob Kollanukkaran, xiang.w.wang
  Cc: dev, Shahaf Shuler, hemant.agrawal, Opher Reviv, Alex Rosenbaum,
	Dovrat Zifroni, Prasun Kapoor, nipun.gupta, bruce.richardson,
	yang.a.hong, harry.chang, gu.jian1, shanjiangh, zhangy.yun,
	lixingfu, wushuai, yuyingxia, fanchenggang, davidfgao, liuzhong1,
	zhaoyong11, oc, jim, hongjun.ni, j.bromhead, deri, fc, arthur.su,
	Thomas Monjalon

Hi Pavan,

Thanks for your review, PSB.

Best,
Ori

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Pavan Nikhilesh Bhagavatula
> 
> <Snip>
> 
> > #
> >+# Compile regex device support
> >+#
> >+CONFIG_RTE_LIBRTE_REGEXDEV=y
> >+CONFIG_RTE_LIBRTE_REGEXDEV_DEBUG=n
> 
> The above flag is never used in the patchset.
> 

Correct will be used after applying your comments about debug in 
enqueue and  dequeue.

> >+
> >+#
> > # Compile librte_ring
> > #
> > CONFIG_RTE_LIBRTE_RING=y
> >@@ -1111,3 +1117,4 @@ CONFIG_RTE_APP_CRYPTO_PERF=y
> > # Compile the eventdev application
> > #
> > CONFIG_RTE_APP_EVENTDEV=y
> >+


^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 0/4] add RegEx class
  2020-04-04 13:06 ` [dpdk-dev] [EXT] [PATCH v1 0/4] add RegEx class Pavan Nikhilesh Bhagavatula
@ 2020-04-05 15:03   ` Ori Kam
  0 siblings, 0 replies; 96+ messages in thread
From: Ori Kam @ 2020-04-05 15:03 UTC (permalink / raw)
  To: Pavan Nikhilesh Bhagavatula, Jerin Jacob Kollanukkaran, xiang.w.wang
  Cc: dev, Shahaf Shuler, hemant.agrawal, Opher Reviv, Alex Rosenbaum,
	Dovrat Zifroni, Prasun Kapoor, nipun.gupta, bruce.richardson,
	yang.a.hong, harry.chang, gu.jian1, shanjiangh, zhangy.yun,
	lixingfu, wushuai, yuyingxia, fanchenggang, davidfgao, liuzhong1,
	zhaoyong11, oc, jim, hongjun.ni, j.bromhead, deri, fc, arthur.su,
	Thomas Monjalon

Hi Pavan,

Thanks for your comments, PSB.

Best,
Ori

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Pavan Nikhilesh Bhagavatula
> Subject: Re: [dpdk-dev] [EXT] [PATCH v1 0/4] add RegEx class
> 
> Hi Ori,
> 
> Looks like the series is missing support for virtual devices i.e. vdev
> @see rte_eventdev_pmd_vdev.h, rte_ethdev_vdev.h.
> 
> Hyperscan and PCRE based regexdev would need vdev support.
> 

As far as I can see,  the functions in rte_ethdev_vdev.h for example, are just
wrapper functions. I don't think they are needed at least not in current stage,
the vdev PMD can just call the register function by himself.
I think that if we see we have a need or large code base that should/can
be shared between devices then we will add such functions.

> Thanks,
> Pavan.
> 
> >This patch set adds the RegEx class, which enables RegEx pattern
> >matching, both on HW/SW PMDs.
> >
> >Example for applications that will benefit from this class:
> >* Next Generation Firewalls (NGFW)
> >* Deep Packet and Flow Inspection (DPI)
> >* Intrusion Prevention Systems (IPS)
> >* DDoS Mitigation
> >* Network Monitoring
> >* Data Loss Prevention (DLP)
> >* Smart NICs
> >* Grammar based content processing
> >* URL, spam and adware filtering
> >* Advanced auditing and policing of user/application security policies
> >* Financial data mining - parsing of streamed financial feeds
> >* Application recognition.
> >* Dmemory introspection.
> >* Natural Language Processing (NLP)
> >* Sentiment Analysis.
> >* Big data databse acceleration.
> >* Computational storage.
> >
> >This patch set is based on RFC[1]
> >
> >This class should be merged only after there is at least
> >one PMD that implements it. Also the test application will
> >be added when the first PMD is added.
> >
> >
> >
> >[1]
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefens
> e.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-
> &amp;data=02%7C01%7Corika%40mellanox.com%7C96aa12eaf0a349c42c720
> 8d7d89918ea%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C637216
> 024425556482&amp;sdata=1FaqurdBqd9FzkKJ8Dmpr7BQSiTfDQhWP51zbdmau
> %2BA%3D&amp;reserved=0
> >3A__patches.dpdk.org_patch_66501_&d=DwIDaQ&c=nKjWec2b6R0mO
> >yPaz7xtfQ&r=E3SgYMjtKCMVsB-fmvgGV3o-
> >g_fjLhk5Pupi9ijohpc&m=bE-
> >KQdo2pQktvXoSvAAe5ppq2423AEYlpW5MTK90UyY&s=qLgLlewFToFlkH
> >yUBQcGVYU6fG2t5yNg2uAz7h_OlVA&e=
> >
> >Jerin Jacob (1):
> >  regexdev: introduce regexdev subsystem
> >
> >Ori Kam (3):
> >  regexdev: add regex core h file
> >  regexdev: add regexdev core functions
> >  regexdev: implement regex rte level functions
> >
> > config/common_base                           |    8 +
> > config/meson.build                           |    1 +
> > doc/api/doxy-api-index.md                    |    1 +
> > doc/api/doxy-api.conf.in                     |    1 +
> > doc/guides/prog_guide/index.rst              |    1 +
> > doc/guides/prog_guide/regexdev_lib.rst       |  177 +++
> > lib/Makefile                                 |    2 +
> > lib/librte_regexdev/Makefile                 |   33 +
> > lib/librte_regexdev/meson.build              |   10 +
> > lib/librte_regexdev/rte_regexdev.c           |  376 +++++++
> > lib/librte_regexdev/rte_regexdev.h           | 1482
> >++++++++++++++++++++++++++
> > lib/librte_regexdev/rte_regexdev_core.h      |  149 +++
> > lib/librte_regexdev/rte_regexdev_driver.h    |   50 +
> > lib/librte_regexdev/rte_regexdev_version.map |   26 +
> > lib/meson.build                              |    3 +-
> > meson_options.txt                            |    2 +
> > 16 files changed, 2321 insertions(+), 1 deletion(-)
> > create mode 100644 doc/guides/prog_guide/regexdev_lib.rst
> > create mode 100644 lib/librte_regexdev/Makefile
> > create mode 100644 lib/librte_regexdev/meson.build
> > create mode 100644 lib/librte_regexdev/rte_regexdev.c
> > create mode 100644 lib/librte_regexdev/rte_regexdev.h
> > create mode 100644 lib/librte_regexdev/rte_regexdev_core.h
> > create mode 100644 lib/librte_regexdev/rte_regexdev_driver.h
> > create mode 100644 lib/librte_regexdev/rte_regexdev_version.map
> >
> >--
> >1.8.3.1


^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 4/4] regexdev: implement regex rte level functions
  2020-04-04 14:27   ` [dpdk-dev] [EXT] " Pavan Nikhilesh Bhagavatula
@ 2020-04-05 15:04     ` Ori Kam
  2020-04-05 16:48       ` Pavan Nikhilesh Bhagavatula
  2020-04-06 11:16       ` Thomas Monjalon
  0 siblings, 2 replies; 96+ messages in thread
From: Ori Kam @ 2020-04-05 15:04 UTC (permalink / raw)
  To: Pavan Nikhilesh Bhagavatula, Jerin Jacob Kollanukkaran, xiang.w.wang
  Cc: dev, Shahaf Shuler, hemant.agrawal, Opher Reviv, Alex Rosenbaum,
	Dovrat Zifroni, Prasun Kapoor, nipun.gupta, bruce.richardson,
	yang.a.hong, harry.chang, gu.jian1, shanjiangh, zhangy.yun,
	lixingfu, wushuai, yuyingxia, fanchenggang, davidfgao, liuzhong1,
	zhaoyong11, oc, jim, hongjun.ni, j.bromhead, deri, fc, arthur.su,
	Thomas Monjalon

Hi Pavan,

Thanks for the review, PSB

Thanks,
Ori

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Pavan Nikhilesh Bhagavatula
> 
> >This commit implements all the RegEx public API.
> >
> >Signed-off-by: Ori Kam <orika@mellanox.com>
> >---
> > lib/librte_regexdev/rte_regexdev.c | 298
> >+++++++++++++++++++++++++++++++++++++
> > 1 file changed, 298 insertions(+)
> >
> >diff --git a/lib/librte_regexdev/rte_regexdev.c
> >b/lib/librte_regexdev/rte_regexdev.c
> >index 4396bb5..72f18fb 100644
> >--- a/lib/librte_regexdev/rte_regexdev.c
> >+++ b/lib/librte_regexdev/rte_regexdev.c
> >@@ -76,3 +76,301 @@
> > {
> > 	regex_devices[dev->dev_id] = NULL;
> > }
> >+
> 
> <snip>
> 
> >+
> >+int
> >+rte_regexdev_info_get(uint8_t dev_id, struct rte_regexdev_info
> >*dev_info)
> >+{
> >+	if (dev_id >= RTE_MAX_REGEXDEV_DEVS)
> >+		return -EINVAL;
> 
> We should use macro for this similar to ethdev/eventdev across the file.
> 
> RTE_ETH_VALID_PORTID_OR_ERR_RET
> RTE_FUNC_PTR_OR_ERR_RET
> 

O.K will move to macro.

> 
> >+	if (regex_devices[dev_id] == NULL)
> >+		return -EINVAL;
> >+	if (dev_info == NULL)
> >+		return -EINVAL;
> >+	if (regex_devices[dev_id]->dev_ops->dev_info_get == NULL)
> >+		return -ENOTSUP;
> >+	return regex_devices[dev_id]->dev_ops->dev_info_get
> >+		(regex_devices[dev_id], dev_info);
> >+}
> >+
> >+int
> >+rte_regexdev_configure(uint8_t dev_id, const struct
> >rte_regexdev_config *cfg)
> >+{
> >+	if (dev_id >= RTE_MAX_REGEXDEV_DEVS)
> >+		return -EINVAL;
> >+	if (regex_devices[dev_id] == NULL)
> >+		return -EINVAL;
> >+	if (cfg == NULL)
> >+		return -EINVAL;
> 
> Please handle re-configure cases, add error checks for cfg passed based on dev
> info.
> 

I don't think the checks that you suggest should be done in this level.
The RTE level isn't aware on the specific capabilities of the PMD.
I think it is the responsibility of the PMD to check. 

> >+	if (regex_devices[dev_id]->dev_ops->dev_configure == NULL)
> >+		return -ENOTSUP;
> >+	return regex_devices[dev_id]->dev_ops->dev_configure
> >+		(regex_devices[dev_id], cfg);
> >+}
> >+
> 
> <Snip>
> 
> >+
> >+uint16_t
> >+rte_regexdev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
> >+			   struct rte_regex_ops **ops, uint16_t nb_ops)
> >+{
> >+	return regex_devices[dev_id]-
> >>enqueue(regex_devices[dev_id], qp_id,
> >+					      ops, nb_ops);
> >+}
> 
> Move these functions to .h in-lining them.
> Also, please add debug checks @see rte_eth_rx_burst/rte_eth_tx_burst.
> 

O.K will update.

> >+
> >+uint16_t
> >+rte_regexdev_dequeue_burst(uint8_t dev_id, uint16_t qp_id,
> >+			   struct rte_regex_ops **ops, uint16_t nb_ops)
> >+{
> >+	return regex_devices[dev_id]-
> >>dequeue(regex_devices[dev_id], qp_id,
> >+					      ops, nb_ops);
> >+}
> >--
> >1.8.3.1


^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core functions
  2020-04-04 15:01   ` [dpdk-dev] [EXT] " Pavan Nikhilesh Bhagavatula
@ 2020-04-05 15:05     ` Ori Kam
  2020-04-05 17:10       ` Pavan Nikhilesh Bhagavatula
  0 siblings, 1 reply; 96+ messages in thread
From: Ori Kam @ 2020-04-05 15:05 UTC (permalink / raw)
  To: Pavan Nikhilesh Bhagavatula, Jerin Jacob Kollanukkaran, xiang.w.wang
  Cc: dev, Shahaf Shuler, hemant.agrawal, Opher Reviv, Alex Rosenbaum,
	Dovrat Zifroni, Prasun Kapoor, nipun.gupta, bruce.richardson,
	yang.a.hong, harry.chang, gu.jian1, shanjiangh, zhangy.yun,
	lixingfu, wushuai, yuyingxia, fanchenggang, davidfgao, liuzhong1,
	zhaoyong11, oc, jim, hongjun.ni, j.bromhead, deri, fc, arthur.su,
	Thomas Monjalon, Parav Pandit

Hi Pavan,

Thanks for your review, PSB.

Best,
Ori

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Pavan Nikhilesh Bhagavatula
> 
> Looks like this implementation is incomplete?
> I don't see any pmd specific helper functions for @see rte_cryptodev_pmd.c,
> rte_eventdev_pmd*
>
I think the current implementation includes all needed functions,
at least for the first stage.
You can find in rte_regexdev_driver.h the functions that should be called
by the PMD. We have the register / unregister which acts the same as create
and destroy. For parsing argument the PMD may call rte_kvargs_parse.

 
> >This commit introduce the API that is needed by the RegEx devices in
> >order to work with the RegEX lib.
> >
> >During the probe of a RegEx device, the device should configure itself,
> >and allocate the resources it requires.
> >On completion of the device init, it should call the
> >rte_regex_dev_register in order to register itself as a RegEx device.
> >
> >Signed-off-by: Ori Kam <orika@mellanox.com>
> >Signed-off-by: Parav Pandit <parav@mellanox.com>
> >---
> > config/common_base                        |  3 +-
> > config/meson.build                        |  1 +
> > lib/librte_regexdev/Makefile              |  1 +
> > lib/librte_regexdev/meson.build           |  5 ++-
> > lib/librte_regexdev/rte_regexdev.c        | 74
> >++++++++++++++++++++++++++++++-
> > lib/librte_regexdev/rte_regexdev.h        |  7 +++
> > lib/librte_regexdev/rte_regexdev_core.h   |  2 +
> > lib/librte_regexdev/rte_regexdev_driver.h | 50
> >+++++++++++++++++++++
> > meson_options.txt                         |  2 +
> > 9 files changed, 142 insertions(+), 3 deletions(-)
> > create mode 100644 lib/librte_regexdev/rte_regexdev_driver.h
> >
> 
> <snip>

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 4/4] regexdev: implement regex rte level functions
  2020-04-05 15:04     ` Ori Kam
@ 2020-04-05 16:48       ` Pavan Nikhilesh Bhagavatula
  2020-04-05 19:46         ` Ori Kam
  2020-04-06 11:16       ` Thomas Monjalon
  1 sibling, 1 reply; 96+ messages in thread
From: Pavan Nikhilesh Bhagavatula @ 2020-04-05 16:48 UTC (permalink / raw)
  To: Ori Kam, Jerin Jacob Kollanukkaran, xiang.w.wang
  Cc: dev, Shahaf Shuler, hemant.agrawal, Opher Reviv, Alex Rosenbaum,
	Dovrat Zifroni, Prasun Kapoor, nipun.gupta, bruce.richardson,
	yang.a.hong, harry.chang, gu.jian1, shanjiangh, zhangy.yun,
	lixingfu, wushuai, yuyingxia, fanchenggang, davidfgao, liuzhong1,
	zhaoyong11, oc, jim, hongjun.ni, j.bromhead, deri, fc, arthur.su,
	Thomas Monjalon

>> >+
>> >+int
>> >+rte_regexdev_configure(uint8_t dev_id, const struct
>> >rte_regexdev_config *cfg)
>> >+{
>> >+	if (dev_id >= RTE_MAX_REGEXDEV_DEVS)
>> >+		return -EINVAL;
>> >+	if (regex_devices[dev_id] == NULL)
>> >+		return -EINVAL;
>> >+	if (cfg == NULL)
>> >+		return -EINVAL;
>>
>> Please handle re-configure cases, add error checks for cfg passed
>based on dev
>> info.
>>
>
>I don't think the checks that you suggest should be done in this level.
>The RTE level isn't aware on the specific capabilities of the PMD.

PMD capabilities are standardized through dev_info.
All the PMD capabilities needs to be exposed to RTE level through dev_info else 
how would an application using rte_regexdev would know the capabilities of the driver.

>I think it is the responsibility of the PMD to check.

The checks would be same for all the pmds which would just be unnecessary code repetition.
Instead RTE layer should probe dev_info and compare against dev_configure.

>
>> >+	if (regex_devices[dev_id]->dev_ops->dev_configure == NULL)
>> >+		return -ENOTSUP;
>> >+	return regex_devices[dev_id]->dev_ops->dev_configure
>> >+		(regex_devices[dev_id], cfg);
>> >+}
>> >+
>>
>> <Snip>
>>
>> >+
>> >+uint16_t
>> >+rte_regexdev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
>> >+			   struct rte_regex_ops **ops, uint16_t nb_ops)
>> >+{
>> >+	return regex_devices[dev_id]-
>> >>enqueue(regex_devices[dev_id], qp_id,
>> >+					      ops, nb_ops);
>> >+}
>>
>> Move these functions to .h in-lining them.
>> Also, please add debug checks @see
>rte_eth_rx_burst/rte_eth_tx_burst.
>>
>
>O.K will update.
>
>> >+
>> >+uint16_t
>> >+rte_regexdev_dequeue_burst(uint8_t dev_id, uint16_t qp_id,
>> >+			   struct rte_regex_ops **ops, uint16_t nb_ops)
>> >+{
>> >+	return regex_devices[dev_id]-
>> >>dequeue(regex_devices[dev_id], qp_id,
>> >+					      ops, nb_ops);
>> >+}
>> >--
>> >1.8.3.1


^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core functions
  2020-04-05 15:05     ` Ori Kam
@ 2020-04-05 17:10       ` Pavan Nikhilesh Bhagavatula
  2020-04-05 20:02         ` Ori Kam
  0 siblings, 1 reply; 96+ messages in thread
From: Pavan Nikhilesh Bhagavatula @ 2020-04-05 17:10 UTC (permalink / raw)
  To: Ori Kam, Jerin Jacob Kollanukkaran, xiang.w.wang
  Cc: dev, Shahaf Shuler, hemant.agrawal, Opher Reviv, Alex Rosenbaum,
	Dovrat Zifroni, Prasun Kapoor, nipun.gupta, bruce.richardson,
	yang.a.hong, harry.chang, gu.jian1, shanjiangh, zhangy.yun,
	lixingfu, wushuai, yuyingxia, fanchenggang, davidfgao, liuzhong1,
	zhaoyong11, oc, jim, hongjun.ni, j.bromhead, deri, fc, arthur.su,
	Thomas Monjalon, Parav Pandit

Hi Ori,

>> From: dev <dev-bounces@dpdk.org> On Behalf Of Pavan Nikhilesh
>Bhagavatula
>>
>> Looks like this implementation is incomplete?
>> I don't see any pmd specific helper functions for @see
>rte_cryptodev_pmd.c,
>> rte_eventdev_pmd*
>>
>I think the current implementation includes all needed functions,
>at least for the first stage.
>You can find in rte_regexdev_driver.h the functions that should be
>called
>by the PMD. We have the register / unregister which acts the same as
>create
>and destroy. For parsing argument the PMD may call rte_kvargs_parse.
>

_driver.h should atleast include 
rte_regex_dev_pci_generic_probe/rte_regex_pmd_vdev_init
else there would be a lot of code repetition and possibly udefined behavior
at the driver layer.

And also why take a different path than the rest of the rte subsystems?

>
>> >This commit introduce the API that is needed by the RegEx devices in
>> >order to work with the RegEX lib.
>> >
>> >During the probe of a RegEx device, the device should configure
>itself,
>> >and allocate the resources it requires.
>> >On completion of the device init, it should call the
>> >rte_regex_dev_register in order to register itself as a RegEx device.
>> >
>> >Signed-off-by: Ori Kam <orika@mellanox.com>
>> >Signed-off-by: Parav Pandit <parav@mellanox.com>
>> >---
>> > config/common_base                        |  3 +-
>> > config/meson.build                        |  1 +
>> > lib/librte_regexdev/Makefile              |  1 +
>> > lib/librte_regexdev/meson.build           |  5 ++-
>> > lib/librte_regexdev/rte_regexdev.c        | 74
>> >++++++++++++++++++++++++++++++-
>> > lib/librte_regexdev/rte_regexdev.h        |  7 +++
>> > lib/librte_regexdev/rte_regexdev_core.h   |  2 +
>> > lib/librte_regexdev/rte_regexdev_driver.h | 50
>> >+++++++++++++++++++++
>> > meson_options.txt                         |  2 +
>> > 9 files changed, 142 insertions(+), 3 deletions(-)
>> > create mode 100644 lib/librte_regexdev/rte_regexdev_driver.h
>> >
>>
>> <snip>

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 4/4] regexdev: implement regex rte level functions
  2020-04-05 16:48       ` Pavan Nikhilesh Bhagavatula
@ 2020-04-05 19:46         ` Ori Kam
  0 siblings, 0 replies; 96+ messages in thread
From: Ori Kam @ 2020-04-05 19:46 UTC (permalink / raw)
  To: Pavan Nikhilesh Bhagavatula, Jerin Jacob Kollanukkaran, xiang.w.wang
  Cc: dev, Shahaf Shuler, hemant.agrawal, Opher Reviv, Alex Rosenbaum,
	Dovrat Zifroni, Prasun Kapoor, nipun.gupta, bruce.richardson,
	yang.a.hong, harry.chang, gu.jian1, shanjiangh, zhangy.yun,
	lixingfu, wushuai, yuyingxia, fanchenggang, davidfgao, liuzhong1,
	zhaoyong11, oc, jim, hongjun.ni, j.bromhead, deri, fc, arthur.su,
	Thomas Monjalon

Hi Pavan,

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Pavan Nikhilesh Bhagavatula
> 
> >> >+
> >> >+int
> >> >+rte_regexdev_configure(uint8_t dev_id, const struct
> >> >rte_regexdev_config *cfg)
> >> >+{
> >> >+	if (dev_id >= RTE_MAX_REGEXDEV_DEVS)
> >> >+		return -EINVAL;
> >> >+	if (regex_devices[dev_id] == NULL)
> >> >+		return -EINVAL;
> >> >+	if (cfg == NULL)
> >> >+		return -EINVAL;
> >>
> >> Please handle re-configure cases, add error checks for cfg passed
> >based on dev
> >> info.
> >>
> >
> >I don't think the checks that you suggest should be done in this level.
> >The RTE level isn't aware on the specific capabilities of the PMD.
> 
> PMD capabilities are standardized through dev_info.
> All the PMD capabilities needs to be exposed to RTE level through dev_info else
> how would an application using rte_regexdev would know the capabilities of
> the driver.
> 

The capabilities are exposed to the application using rte_regexdev_info_get.

> >I think it is the responsibility of the PMD to check.
> 
> The checks would be same for all the pmds which would just be unnecessary
> code repetition.
> Instead RTE layer should probe dev_info and compare against dev_configure.
> 

I accept your comment I will add the missing checks, and re-configuration cases.

> >
> >> >+	if (regex_devices[dev_id]->dev_ops->dev_configure == NULL)
> >> >+		return -ENOTSUP;
> >> >+	return regex_devices[dev_id]->dev_ops->dev_configure
> >> >+		(regex_devices[dev_id], cfg);
> >> >+}
> >> >+
> >>
> >> <Snip>
> >>
> >> >+
> >> >+uint16_t
> >> >+rte_regexdev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
> >> >+			   struct rte_regex_ops **ops, uint16_t nb_ops)
> >> >+{
> >> >+	return regex_devices[dev_id]-
> >> >>enqueue(regex_devices[dev_id], qp_id,
> >> >+					      ops, nb_ops);
> >> >+}
> >>
> >> Move these functions to .h in-lining them.
> >> Also, please add debug checks @see
> >rte_eth_rx_burst/rte_eth_tx_burst.
> >>
> >
> >O.K will update.
> >
> >> >+
> >> >+uint16_t
> >> >+rte_regexdev_dequeue_burst(uint8_t dev_id, uint16_t qp_id,
> >> >+			   struct rte_regex_ops **ops, uint16_t nb_ops)
> >> >+{
> >> >+	return regex_devices[dev_id]-
> >> >>dequeue(regex_devices[dev_id], qp_id,
> >> >+					      ops, nb_ops);
> >> >+}
> >> >--
> >> >1.8.3.1


^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core functions
  2020-04-05 17:10       ` Pavan Nikhilesh Bhagavatula
@ 2020-04-05 20:02         ` Ori Kam
  2020-04-06 12:48           ` Pavan Nikhilesh Bhagavatula
  0 siblings, 1 reply; 96+ messages in thread
From: Ori Kam @ 2020-04-05 20:02 UTC (permalink / raw)
  To: Pavan Nikhilesh Bhagavatula, Jerin Jacob Kollanukkaran, xiang.w.wang
  Cc: dev, Shahaf Shuler, hemant.agrawal, Opher Reviv, Alex Rosenbaum,
	Dovrat Zifroni, Prasun Kapoor, nipun.gupta, bruce.richardson,
	yang.a.hong, harry.chang, gu.jian1, shanjiangh, zhangy.yun,
	lixingfu, wushuai, yuyingxia, fanchenggang, davidfgao, liuzhong1,
	zhaoyong11, oc, jim, hongjun.ni, j.bromhead, deri, fc, arthur.su,
	Thomas Monjalon, Parav Pandit

Hi Pavan,

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Pavan Nikhilesh Bhagavatula
> Sent: Sunday, April 5, 2020 8:11 PM
> To: Ori Kam <orika@mellanox.com>; Jerin Jacob Kollanukkaran
> <jerinj@marvell.com>; xiang.w.wang@intel.com
> Cc: dev@dpdk.org; Shahaf Shuler <shahafs@mellanox.com>;
> hemant.agrawal@nxp.com; Opher Reviv <opher@mellanox.com>; Alex
> Rosenbaum <alexr@mellanox.com>; Dovrat Zifroni <dovrat@marvell.com>;
> Prasun Kapoor <pkapoor@marvell.com>; nipun.gupta@nxp.com;
> bruce.richardson@intel.com; yang.a.hong@intel.com; harry.chang@intel.com;
> gu.jian1@zte.com.cn; shanjiangh@chinatelecom.cn;
> zhangy.yun@chinatelecom.cn; lixingfu@huachentel.com; wushuai@inspur.com;
> yuyingxia@yxlink.com; fanchenggang@sunyainfo.com;
> davidfgao@tencent.com; liuzhong1@chinaunicom.cn;
> zhaoyong11@huawei.com; oc@yunify.com; jim@netgate.com;
> hongjun.ni@intel.com; j.bromhead@titan-ic.com; deri@ntop.org;
> fc@napatech.com; arthur.su@lionic.com; Thomas Monjalon
> <thomas@monjalon.net>; Parav Pandit <parav@mellanox.com>
> Subject: Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core
> functions
> 
> Hi Ori,
> 
> >> From: dev <dev-bounces@dpdk.org> On Behalf Of Pavan Nikhilesh
> >Bhagavatula
> >>
> >> Looks like this implementation is incomplete?
> >> I don't see any pmd specific helper functions for @see
> >rte_cryptodev_pmd.c,
> >> rte_eventdev_pmd*
> >>
> >I think the current implementation includes all needed functions,
> >at least for the first stage.
> >You can find in rte_regexdev_driver.h the functions that should be
> >called
> >by the PMD. We have the register / unregister which acts the same as
> >create
> >and destroy. For parsing argument the PMD may call rte_kvargs_parse.
> >
> 
> _driver.h should atleast include
> rte_regex_dev_pci_generic_probe/rte_regex_pmd_vdev_init
> else there would be a lot of code repetition and possibly udefined behavior
> at the driver layer.
> 
Why should they be included? At least in this stage, there is no code to share
ethdev why should we add code for the vdev? 
I agree that if we see that there is shared code, we should think about creating
those functions.

> And also why take a different path than the rest of the rte subsystems?
>

Even now if you look at the reference code you will see that there is really minimum shared code.
also this result in that the PMD is not free to allocate resource in the order he needs.
My thinking is that if there are only 2 lines of shared code I prefer to let the PMD handle it.
I know that sharing code should be the first option, but this also makes the PMD developer unaware what is going on.
and lose some control. For example if the PMD programmer wants to create hybrid PMD net +
regex for example, then either he will be forced to do some hacks or just by pass the function
so when this function will be updated his code will break. So I prefer if it is very short code
and this code can be developed in different ways to leave it to the PMD.
I suggest that if needed we will add such function. Is that O.K by you?
 
> >
> >> >This commit introduce the API that is needed by the RegEx devices in
> >> >order to work with the RegEX lib.
> >> >
> >> >During the probe of a RegEx device, the device should configure
> >itself,
> >> >and allocate the resources it requires.
> >> >On completion of the device init, it should call the
> >> >rte_regex_dev_register in order to register itself as a RegEx device.
> >> >
> >> >Signed-off-by: Ori Kam <orika@mellanox.com>
> >> >Signed-off-by: Parav Pandit <parav@mellanox.com>
> >> >---
> >> > config/common_base                        |  3 +-
> >> > config/meson.build                        |  1 +
> >> > lib/librte_regexdev/Makefile              |  1 +
> >> > lib/librte_regexdev/meson.build           |  5 ++-
> >> > lib/librte_regexdev/rte_regexdev.c        | 74
> >> >++++++++++++++++++++++++++++++-
> >> > lib/librte_regexdev/rte_regexdev.h        |  7 +++
> >> > lib/librte_regexdev/rte_regexdev_core.h   |  2 +
> >> > lib/librte_regexdev/rte_regexdev_driver.h | 50
> >> >+++++++++++++++++++++
> >> > meson_options.txt                         |  2 +
> >> > 9 files changed, 142 insertions(+), 3 deletions(-)
> >> > create mode 100644 lib/librte_regexdev/rte_regexdev_driver.h
> >> >
> >>
> >> <snip>

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 4/4] regexdev: implement regex rte level functions
  2020-04-05 15:04     ` Ori Kam
  2020-04-05 16:48       ` Pavan Nikhilesh Bhagavatula
@ 2020-04-06 11:16       ` Thomas Monjalon
  2020-04-06 12:33         ` Pavan Nikhilesh Bhagavatula
  1 sibling, 1 reply; 96+ messages in thread
From: Thomas Monjalon @ 2020-04-06 11:16 UTC (permalink / raw)
  To: Pavan Nikhilesh Bhagavatula, Ori Kam
  Cc: Jerin Jacob Kollanukkaran, xiang.w.wang, dev, Shahaf Shuler,
	hemant.agrawal, Opher Reviv, Alex Rosenbaum, Dovrat Zifroni,
	Prasun Kapoor, nipun.gupta, bruce.richardson, yang.a.hong,
	harry.chang, gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai,
	yuyingxia, fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc,
	jim, hongjun.ni, j.bromhead, deri, fc, arthur.su, david.marchand

05/04/2020 17:04, Ori Kam:
> From: Pavan Nikhilesh Bhagavatula
> > >+uint16_t
> > >+rte_regexdev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
> > >+			   struct rte_regex_ops **ops, uint16_t nb_ops)
> > >+{
> > >+	return regex_devices[dev_id]-
> > >>enqueue(regex_devices[dev_id], qp_id,
> > >+					      ops, nb_ops);
> > >+}
> > 
> > Move these functions to .h in-lining them.
> > Also, please add debug checks @see rte_eth_rx_burst/rte_eth_tx_burst.
> 
> O.K will update.

In general, inlining is a pain for ABI compatibility.
Please inline only if the gain is very significant.



^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 4/4] regexdev: implement regex rte level functions
  2020-04-06 11:16       ` Thomas Monjalon
@ 2020-04-06 12:33         ` Pavan Nikhilesh Bhagavatula
  2020-04-06 13:14           ` Thomas Monjalon
  0 siblings, 1 reply; 96+ messages in thread
From: Pavan Nikhilesh Bhagavatula @ 2020-04-06 12:33 UTC (permalink / raw)
  To: Thomas Monjalon, Ori Kam
  Cc: Jerin Jacob Kollanukkaran, xiang.w.wang, dev, Shahaf Shuler,
	hemant.agrawal, Opher Reviv, Alex Rosenbaum, Dovrat Zifroni,
	Prasun Kapoor, nipun.gupta, bruce.richardson, yang.a.hong,
	harry.chang, gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai,
	yuyingxia, fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc,
	jim, hongjun.ni, j.bromhead, deri, fc, arthur.su, david.marchand

>> From: Pavan Nikhilesh Bhagavatula
>> > >+uint16_t
>> > >+rte_regexdev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
>> > >+			   struct rte_regex_ops **ops, uint16_t nb_ops)
>> > >+{
>> > >+	return regex_devices[dev_id]-
>> > >>enqueue(regex_devices[dev_id], qp_id,
>> > >+					      ops, nb_ops);
>> > >+}
>> >
>> > Move these functions to .h in-lining them.
>> > Also, please add debug checks @see
>rte_eth_rx_burst/rte_eth_tx_burst.
>>
>> O.K will update.
>
>In general, inlining is a pain for ABI compatibility.
>Please inline only if the gain is very significant.
>

The performance gain mostly comes from hoisting `regex_devices[dev_id]` load above the 
poll loop. 
Since, the performance measurement application is still in pipeline and regexdev would be 
experimental for next couple of releases I suggest inlining it now and worrying about ABI when
experimental tag needs to be removed.

We can follow the same path as done by ethdev [https://www.mail-archive.com/dev@dpdk.org/msg142392.html]

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core functions
  2020-04-05 20:02         ` Ori Kam
@ 2020-04-06 12:48           ` Pavan Nikhilesh Bhagavatula
  2020-04-06 13:29             ` Thomas Monjalon
  2020-04-08  9:41             ` Ori Kam
  0 siblings, 2 replies; 96+ messages in thread
From: Pavan Nikhilesh Bhagavatula @ 2020-04-06 12:48 UTC (permalink / raw)
  To: Ori Kam, Jerin Jacob Kollanukkaran, xiang.w.wang
  Cc: dev, Shahaf Shuler, hemant.agrawal, Opher Reviv, Alex Rosenbaum,
	Dovrat Zifroni, Prasun Kapoor, nipun.gupta, bruce.richardson,
	yang.a.hong, harry.chang, gu.jian1, shanjiangh, zhangy.yun,
	lixingfu, wushuai, yuyingxia, fanchenggang, davidfgao, liuzhong1,
	zhaoyong11, oc, jim, hongjun.ni, j.bromhead, deri, fc, arthur.su,
	Thomas Monjalon, Parav Pandit

Hi Ori,

>Hi Pavan,
>
>> -----Original Message-----
>> From: dev <dev-bounces@dpdk.org> On Behalf Of Pavan Nikhilesh
>Bhagavatula
>> Sent: Sunday, April 5, 2020 8:11 PM
>> To: Ori Kam <orika@mellanox.com>; Jerin Jacob Kollanukkaran
>> <jerinj@marvell.com>; xiang.w.wang@intel.com
>> Cc: dev@dpdk.org; Shahaf Shuler <shahafs@mellanox.com>;
>> hemant.agrawal@nxp.com; Opher Reviv <opher@mellanox.com>;
>Alex
>> Rosenbaum <alexr@mellanox.com>; Dovrat Zifroni
><dovrat@marvell.com>;
>> Prasun Kapoor <pkapoor@marvell.com>; nipun.gupta@nxp.com;
>> bruce.richardson@intel.com; yang.a.hong@intel.com;
>harry.chang@intel.com;
>> gu.jian1@zte.com.cn; shanjiangh@chinatelecom.cn;
>> zhangy.yun@chinatelecom.cn; lixingfu@huachentel.com;
>wushuai@inspur.com;
>> yuyingxia@yxlink.com; fanchenggang@sunyainfo.com;
>> davidfgao@tencent.com; liuzhong1@chinaunicom.cn;
>> zhaoyong11@huawei.com; oc@yunify.com; jim@netgate.com;
>> hongjun.ni@intel.com; j.bromhead@titan-ic.com; deri@ntop.org;
>> fc@napatech.com; arthur.su@lionic.com; Thomas Monjalon
>> <thomas@monjalon.net>; Parav Pandit <parav@mellanox.com>
>> Subject: Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev
>core
>> functions
>>
>> Hi Ori,
>>
>> >> From: dev <dev-bounces@dpdk.org> On Behalf Of Pavan
>Nikhilesh
>> >Bhagavatula
>> >>
>> >> Looks like this implementation is incomplete?
>> >> I don't see any pmd specific helper functions for @see
>> >rte_cryptodev_pmd.c,
>> >> rte_eventdev_pmd*
>> >>
>> >I think the current implementation includes all needed functions,
>> >at least for the first stage.
>> >You can find in rte_regexdev_driver.h the functions that should be
>> >called
>> >by the PMD. We have the register / unregister which acts the same
>as
>> >create
>> >and destroy. For parsing argument the PMD may call
>rte_kvargs_parse.
>> >
>>
>> _driver.h should atleast include
>> rte_regex_dev_pci_generic_probe/rte_regex_pmd_vdev_init
>> else there would be a lot of code repetition and possibly udefined
>behavior
>> at the driver layer.
>>
>Why should they be included? At least in this stage, there is no code to
>share
>ethdev why should we add code for the vdev?

Ok I think I failed to communicate my concerns across. 
Let me retry

1. SW based regex devices such as PCRE/Hyperscan rely on vdev framework
i.e. user needs to pass an EAL argument --vdev="regex_pcre" for the driver to 
initialize all the other EAL subsystems (ethdev, eventdev, cryptodev, etc..)support this.

2. HW based independent regex devices that are exposed as PCI devices would need
 pci probe helpers.


>I agree that if we see that there is shared code, we should think about
>creating
>those functions.
>
>> And also why take a different path than the rest of the rte
>subsystems?
>>
>
>Even now if you look at the reference code you will see that there is
>really minimum shared code.
>also this result in that the PMD is not free to allocate resource in the
>order he needs.
>My thinking is that if there are only 2 lines of shared code I prefer to let
>the PMD handle it.
>I know that sharing code should be the first option, but this also makes
>the PMD developer unaware what is going on.
>and lose some control. For example if the PMD programmer wants to
>create hybrid PMD net +
>regex for example, then either he will be forced to do some hacks or
>just by pass the function
>so when this function will be updated his code will break.

Shouldn't the application/end user make that decision rather than PMD programmer?.
If application wants to connect net to regex it should be made possible to do it via rte_flow.

As an example if we see event device spec. It has robust features to connect multiple 
subsystems(ethernet/crypto/timer) to event device and it is controlled from RTE layer.
PMD layer should act on the inputs from RTE layer rather than action on it own.

Thoughts?
Thanks,
Pavan.

 So I prefer if it
>is very short code
>and this code can be developed in different ways to leave it to the
>PMD.
>I suggest that if needed we will add such function. Is that O.K by you?
>
>> >
>> >> >This commit introduce the API that is needed by the RegEx
>devices in
>> >> >order to work with the RegEX lib.
>> >> >
>> >> >During the probe of a RegEx device, the device should configure
>> >itself,
>> >> >and allocate the resources it requires.
>> >> >On completion of the device init, it should call the
>> >> >rte_regex_dev_register in order to register itself as a RegEx
>device.
>> >> >
>> >> >Signed-off-by: Ori Kam <orika@mellanox.com>
>> >> >Signed-off-by: Parav Pandit <parav@mellanox.com>
>> >> >---
>> >> > config/common_base                        |  3 +-
>> >> > config/meson.build                        |  1 +
>> >> > lib/librte_regexdev/Makefile              |  1 +
>> >> > lib/librte_regexdev/meson.build           |  5 ++-
>> >> > lib/librte_regexdev/rte_regexdev.c        | 74
>> >> >++++++++++++++++++++++++++++++-
>> >> > lib/librte_regexdev/rte_regexdev.h        |  7 +++
>> >> > lib/librte_regexdev/rte_regexdev_core.h   |  2 +
>> >> > lib/librte_regexdev/rte_regexdev_driver.h | 50
>> >> >+++++++++++++++++++++
>> >> > meson_options.txt                         |  2 +
>> >> > 9 files changed, 142 insertions(+), 3 deletions(-)
>> >> > create mode 100644 lib/librte_regexdev/rte_regexdev_driver.h
>> >> >
>> >>
>> >> <snip>

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 4/4] regexdev: implement regex rte level functions
  2020-04-06 12:33         ` Pavan Nikhilesh Bhagavatula
@ 2020-04-06 13:14           ` Thomas Monjalon
  2020-04-06 13:20             ` Jerin Jacob
  2020-04-06 13:22             ` Pavan Nikhilesh Bhagavatula
  0 siblings, 2 replies; 96+ messages in thread
From: Thomas Monjalon @ 2020-04-06 13:14 UTC (permalink / raw)
  To: Pavan Nikhilesh Bhagavatula
  Cc: Ori Kam, Jerin Jacob Kollanukkaran, xiang.w.wang, dev,
	Shahaf Shuler, hemant.agrawal, Opher Reviv, Alex Rosenbaum,
	Dovrat Zifroni, Prasun Kapoor, nipun.gupta, bruce.richardson,
	yang.a.hong, harry.chang, gu.jian1, shanjiangh, zhangy.yun,
	lixingfu, wushuai, yuyingxia, fanchenggang, davidfgao, liuzhong1,
	zhaoyong11, oc, jim, hongjun.ni, j.bromhead, deri, fc, arthur.su,
	david.marchand

06/04/2020 14:33, Pavan Nikhilesh Bhagavatula:
> >> From: Pavan Nikhilesh Bhagavatula
> >> > >+uint16_t
> >> > >+rte_regexdev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
> >> > >+			   struct rte_regex_ops **ops, uint16_t nb_ops)
> >> > >+{
> >> > >+	return regex_devices[dev_id]-
> >> > >>enqueue(regex_devices[dev_id], qp_id,
> >> > >+					      ops, nb_ops);
> >> > >+}
> >> >
> >> > Move these functions to .h in-lining them.
> >> > Also, please add debug checks @see
> >rte_eth_rx_burst/rte_eth_tx_burst.
> >>
> >> O.K will update.
> >
> >In general, inlining is a pain for ABI compatibility.
> >Please inline only if the gain is very significant.
> >
> 
> The performance gain mostly comes from hoisting `regex_devices[dev_id]` load above the 
> poll loop. 
> Since, the performance measurement application is still in pipeline and regexdev would be 
> experimental for next couple of releases I suggest inlining it now and worrying about ABI when
> experimental tag needs to be removed.

No, we must worry about ABI from the beginning.

> We can follow the same path as done by ethdev [https://www.mail-archive.com/dev@dpdk.org/msg142392.html]

ethdev is not an argument.




^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 4/4] regexdev: implement regex rte level functions
  2020-04-06 13:14           ` Thomas Monjalon
@ 2020-04-06 13:20             ` Jerin Jacob
  2020-04-06 13:22             ` Pavan Nikhilesh Bhagavatula
  1 sibling, 0 replies; 96+ messages in thread
From: Jerin Jacob @ 2020-04-06 13:20 UTC (permalink / raw)
  To: Thomas Monjalon
  Cc: Pavan Nikhilesh Bhagavatula, Ori Kam, Jerin Jacob Kollanukkaran,
	xiang.w.wang, dev, Shahaf Shuler, hemant.agrawal, Opher Reviv,
	Alex Rosenbaum, Dovrat Zifroni, Prasun Kapoor, nipun.gupta,
	bruce.richardson, yang.a.hong, harry.chang, gu.jian1, shanjiangh,
	zhangy.yun, lixingfu, wushuai, yuyingxia, fanchenggang,
	davidfgao, liuzhong1, zhaoyong11, oc, jim, hongjun.ni,
	j.bromhead, deri, fc, arthur.su, david.marchand

On Mon, Apr 6, 2020 at 6:44 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 06/04/2020 14:33, Pavan Nikhilesh Bhagavatula:
> > >> From: Pavan Nikhilesh Bhagavatula
> > >> > >+uint16_t
> > >> > >+rte_regexdev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
> > >> > >+                          struct rte_regex_ops **ops, uint16_t nb_ops)
> > >> > >+{
> > >> > >+       return regex_devices[dev_id]-
> > >> > >>enqueue(regex_devices[dev_id], qp_id,
> > >> > >+                                             ops, nb_ops);
> > >> > >+}
> > >> >
> > >> > Move these functions to .h in-lining them.
> > >> > Also, please add debug checks @see
> > >rte_eth_rx_burst/rte_eth_tx_burst.
> > >>
> > >> O.K will update.
> > >
> > >In general, inlining is a pain for ABI compatibility.
> > >Please inline only if the gain is very significant.
> > >
> >
> > The performance gain mostly comes from hoisting `regex_devices[dev_id]` load above the
> > poll loop.
> > Since, the performance measurement application is still in pipeline and regexdev would be
> > experimental for next couple of releases I suggest inlining it now and worrying about ABI when
> > experimental tag needs to be removed.
>
> No, we must worry about ABI from the beginning.

I think, we need to have the performance number first before we decide
one or another.


>
> > We can follow the same path as done by ethdev [https://www.mail-archive.com/dev@dpdk.org/msg142392.html]
>
> ethdev is not an argument.

Actually this thread explains how to make it inline without exposing
the internal structure unlike existing ethdev. The effort
is stalled due to PMD changes required. In this case, regexdev is new
so it is the correct time to add such code.




>
>
>

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 4/4] regexdev: implement regex rte level functions
  2020-04-06 13:14           ` Thomas Monjalon
  2020-04-06 13:20             ` Jerin Jacob
@ 2020-04-06 13:22             ` Pavan Nikhilesh Bhagavatula
  2020-04-06 13:36               ` Thomas Monjalon
  1 sibling, 1 reply; 96+ messages in thread
From: Pavan Nikhilesh Bhagavatula @ 2020-04-06 13:22 UTC (permalink / raw)
  To: Thomas Monjalon
  Cc: Ori Kam, Jerin Jacob Kollanukkaran, xiang.w.wang, dev,
	Shahaf Shuler, hemant.agrawal, Opher Reviv, Alex Rosenbaum,
	Dovrat Zifroni, Prasun Kapoor, nipun.gupta, bruce.richardson,
	yang.a.hong, harry.chang, gu.jian1, shanjiangh, zhangy.yun,
	lixingfu, wushuai, yuyingxia, fanchenggang, davidfgao, liuzhong1,
	zhaoyong11, oc, jim, hongjun.ni, j.bromhead, deri, fc, arthur.su,
	david.marchand

>06/04/2020 14:33, Pavan Nikhilesh Bhagavatula:
>> >> From: Pavan Nikhilesh Bhagavatula
>> >> > >+uint16_t
>> >> > >+rte_regexdev_enqueue_burst(uint8_t dev_id, uint16_t
>qp_id,
>> >> > >+			   struct rte_regex_ops **ops, uint16_t
>nb_ops)
>> >> > >+{
>> >> > >+	return regex_devices[dev_id]-
>> >> > >>enqueue(regex_devices[dev_id], qp_id,
>> >> > >+					      ops, nb_ops);
>> >> > >+}
>> >> >
>> >> > Move these functions to .h in-lining them.
>> >> > Also, please add debug checks @see
>> >rte_eth_rx_burst/rte_eth_tx_burst.
>> >>
>> >> O.K will update.
>> >
>> >In general, inlining is a pain for ABI compatibility.
>> >Please inline only if the gain is very significant.
>> >
>>
>> The performance gain mostly comes from hoisting
>`regex_devices[dev_id]` load above the
>> poll loop.
>> Since, the performance measurement application is still in pipeline
>and regexdev would be
>> experimental for next couple of releases I suggest inlining it now and
>worrying about ABI when
>> experimental tag needs to be removed.
>
>No, we must worry about ABI from the beginning.

I though performance was the primary objective :-).

>
>> We can follow the same path as done by ethdev
>[https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mail-
>2Darchive.com_dev-
>40dpdk.org_msg142392.html&d=DwICAg&c=nKjWec2b6R0mOyPaz7xtf
>Q&r=E3SgYMjtKCMVsB-fmvgGV3o-
>g_fjLhk5Pupi9ijohpc&m=7Gqb6WKmZV5uY3xa7FRVrRVDz8Usrsd-
>rDjIKr6CUQQ&s=sQo2Kx9fzTNXwiQ2Fzki3s5GSuiiAEzz2VtN68_KKXo&e=
>]
>
>ethdev is not an argument.

What about ring? [http://mails.dpdk.org/archives/dev/2020-April/161506.html]

Why do we need to prove the same performance advantage using in-lining for datapath 
critical functions again and again?

>
>


^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core functions
  2020-04-06 12:48           ` Pavan Nikhilesh Bhagavatula
@ 2020-04-06 13:29             ` Thomas Monjalon
  2020-04-06 13:38               ` Jerin Jacob
  2020-04-08  8:39               ` Ori Kam
  2020-04-08  9:41             ` Ori Kam
  1 sibling, 2 replies; 96+ messages in thread
From: Thomas Monjalon @ 2020-04-06 13:29 UTC (permalink / raw)
  To: Ori Kam, Jerin Jacob Kollanukkaran, xiang.w.wang,
	Pavan Nikhilesh Bhagavatula
  Cc: dev, Shahaf Shuler, hemant.agrawal, Opher Reviv, Alex Rosenbaum,
	Dovrat Zifroni, Prasun Kapoor, nipun.gupta, bruce.richardson,
	yang.a.hong, harry.chang, gu.jian1, shanjiangh, zhangy.yun,
	lixingfu, wushuai, yuyingxia, fanchenggang, davidfgao, liuzhong1,
	zhaoyong11, oc, jim, hongjun.ni, j.bromhead, deri, fc, arthur.su,
	Parav Pandit

06/04/2020 14:48, Pavan Nikhilesh Bhagavatula:
> > From: Pavan Nikhilesh Bhagavatula
> >> >> From: Pavan Nikhilesh Bhagavatula
> >> >>
> >> >> Looks like this implementation is incomplete?
> >> >> I don't see any pmd specific helper functions for @see
> >> >rte_cryptodev_pmd.c,
> >> >> rte_eventdev_pmd*
> >> >>
> >> >I think the current implementation includes all needed functions,
> >> >at least for the first stage.
> >> >You can find in rte_regexdev_driver.h the functions that should be
> >> >called
> >> >by the PMD. We have the register / unregister which acts the same
> >as
> >> >create
> >> >and destroy. For parsing argument the PMD may call
> >rte_kvargs_parse.
> >> >
> >>
> >> _driver.h should atleast include
> >> rte_regex_dev_pci_generic_probe/rte_regex_pmd_vdev_init
> >> else there would be a lot of code repetition and possibly udefined
> >behavior
> >> at the driver layer.
> >>
> >Why should they be included? At least in this stage, there is no code to
> >share
> >ethdev why should we add code for the vdev?
> 
> Ok I think I failed to communicate my concerns across. 
> Let me retry
> 
> 1. SW based regex devices such as PCRE/Hyperscan rely on vdev framework
> i.e. user needs to pass an EAL argument --vdev="regex_pcre" for the driver to 
> initialize all the other EAL subsystems (ethdev, eventdev, cryptodev, etc..)support this.

vdev helpers do not have to be part of the first patches which define API.
It should be added when adding the first vdev driver.

> 2. HW based independent regex devices that are exposed as PCI devices would need
>  pci probe helpers.

Same, PCI helpers can be added while adding the first PCI driver.

We can synchronize about how to split the work, avoiding two developers
doing the same thing. But let's not mandate this work to be done
as part of this first series.




^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 4/4] regexdev: implement regex rte level functions
  2020-04-06 13:22             ` Pavan Nikhilesh Bhagavatula
@ 2020-04-06 13:36               ` Thomas Monjalon
  2020-04-06 13:50                 ` Pavan Nikhilesh Bhagavatula
  0 siblings, 1 reply; 96+ messages in thread
From: Thomas Monjalon @ 2020-04-06 13:36 UTC (permalink / raw)
  To: Pavan Nikhilesh Bhagavatula
  Cc: Ori Kam, Jerin Jacob Kollanukkaran, xiang.w.wang, dev,
	Shahaf Shuler, hemant.agrawal, Opher Reviv, Alex Rosenbaum,
	Dovrat Zifroni, Prasun Kapoor, nipun.gupta, bruce.richardson,
	yang.a.hong, harry.chang, gu.jian1, shanjiangh, zhangy.yun,
	lixingfu, wushuai, yuyingxia, fanchenggang, davidfgao, liuzhong1,
	zhaoyong11, oc, jim, hongjun.ni, j.bromhead, deri, fc, arthur.su,
	david.marchand

06/04/2020 15:22, Pavan Nikhilesh Bhagavatula:
> >06/04/2020 14:33, Pavan Nikhilesh Bhagavatula:
> >> >> From: Pavan Nikhilesh Bhagavatula
> >> >> > >+uint16_t
> >> >> > >+rte_regexdev_enqueue_burst(uint8_t dev_id, uint16_t
> >qp_id,
> >> >> > >+			   struct rte_regex_ops **ops, uint16_t
> >nb_ops)
> >> >> > >+{
> >> >> > >+	return regex_devices[dev_id]-
> >> >> > >>enqueue(regex_devices[dev_id], qp_id,
> >> >> > >+					      ops, nb_ops);
> >> >> > >+}
> >> >> >
> >> >> > Move these functions to .h in-lining them.
> >> >> > Also, please add debug checks @see
> >> >rte_eth_rx_burst/rte_eth_tx_burst.
> >> >>
> >> >> O.K will update.
> >> >
> >> >In general, inlining is a pain for ABI compatibility.
> >> >Please inline only if the gain is very significant.
> >> >
> >>
> >> The performance gain mostly comes from hoisting
> >`regex_devices[dev_id]` load above the
> >> poll loop.
> >> Since, the performance measurement application is still in pipeline
> >and regexdev would be
> >> experimental for next couple of releases I suggest inlining it now and
> >worrying about ABI when
> >> experimental tag needs to be removed.
> >
> >No, we must worry about ABI from the beginning.
> 
> I though performance was the primary objective :-).

It is.

> >> We can follow the same path as done by ethdev
> >[https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mail-
> >2Darchive.com_dev-
> >40dpdk.org_msg142392.html&d=DwICAg&c=nKjWec2b6R0mOyPaz7xtf
> >Q&r=E3SgYMjtKCMVsB-fmvgGV3o-
> >g_fjLhk5Pupi9ijohpc&m=7Gqb6WKmZV5uY3xa7FRVrRVDz8Usrsd-
> >rDjIKr6CUQQ&s=sQo2Kx9fzTNXwiQ2Fzki3s5GSuiiAEzz2VtN68_KKXo&e=
> >]
> >
> >ethdev is not an argument.
> 
> What about ring? [http://mails.dpdk.org/archives/dev/2020-April/161506.html]
> 
> Why do we need to prove the same performance advantage using in-lining for datapath 
> critical functions again and again?

Because every libraries have not the same usage and load.
We should compare how much cycle is saved with inline vs
how much cycles is, "in average", a regex burst?

If you tell me regex processing is fast, OK, let's inline.



^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core functions
  2020-04-06 13:29             ` Thomas Monjalon
@ 2020-04-06 13:38               ` Jerin Jacob
  2020-04-06 19:11                 ` Ori Kam
  2020-04-08  8:39               ` Ori Kam
  1 sibling, 1 reply; 96+ messages in thread
From: Jerin Jacob @ 2020-04-06 13:38 UTC (permalink / raw)
  To: Thomas Monjalon
  Cc: Ori Kam, Jerin Jacob Kollanukkaran, xiang.w.wang,
	Pavan Nikhilesh Bhagavatula, dev, Shahaf Shuler, hemant.agrawal,
	Opher Reviv, Alex Rosenbaum, Dovrat Zifroni, Prasun Kapoor,
	nipun.gupta, bruce.richardson, yang.a.hong, harry.chang,
	gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai, yuyingxia,
	fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc, jim,
	hongjun.ni, j.bromhead, deri, fc, arthur.su, Parav Pandit

On Mon, Apr 6, 2020 at 7:00 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 06/04/2020 14:48, Pavan Nikhilesh Bhagavatula:
> > > From: Pavan Nikhilesh Bhagavatula
> > >> >> From: Pavan Nikhilesh Bhagavatula
> > >> >>
> > >> >> Looks like this implementation is incomplete?
> > >> >> I don't see any pmd specific helper functions for @see
> > >> >rte_cryptodev_pmd.c,
> > >> >> rte_eventdev_pmd*
> > >> >>
> > >> >I think the current implementation includes all needed functions,
> > >> >at least for the first stage.
> > >> >You can find in rte_regexdev_driver.h the functions that should be
> > >> >called
> > >> >by the PMD. We have the register / unregister which acts the same
> > >as
> > >> >create
> > >> >and destroy. For parsing argument the PMD may call
> > >rte_kvargs_parse.
> > >> >
> > >>
> > >> _driver.h should atleast include
> > >> rte_regex_dev_pci_generic_probe/rte_regex_pmd_vdev_init
> > >> else there would be a lot of code repetition and possibly udefined
> > >behavior
> > >> at the driver layer.
> > >>
> > >Why should they be included? At least in this stage, there is no code to
> > >share
> > >ethdev why should we add code for the vdev?
> >
> > Ok I think I failed to communicate my concerns across.
> > Let me retry
> >
> > 1. SW based regex devices such as PCRE/Hyperscan rely on vdev framework
> > i.e. user needs to pass an EAL argument --vdev="regex_pcre" for the driver to
> > initialize all the other EAL subsystems (ethdev, eventdev, cryptodev, etc..)support this.
>
> vdev helpers do not have to be part of the first patches which define API.
> It should be added when adding the first vdev driver.

Yes. When we add vdev, we should not rewrite again to support vdev.
So care must taken for proper implementation in the first place avoid rework.

If it abstracts it properly adding vdev and PCI is a simple change.
See

lib/librte_eventdev/rte_eventdev_pmd_vdev.h
lib/librte_eventdev/rte_eventdev_pmd_pci.h

I think, the common code should take from other matured subsystem instead if
writing from scratch,


>
> > 2. HW based independent regex devices that are exposed as PCI devices would need
> >  pci probe helpers.
>
> Same, PCI helpers can be added while adding the first PCI driver.
>
> We can synchronize about how to split the work, avoiding two developers
> doing the same thing. But let's not mandate this work to be done
> as part of this first series.
>
>
>

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 4/4] regexdev: implement regex rte level functions
  2020-04-06 13:36               ` Thomas Monjalon
@ 2020-04-06 13:50                 ` Pavan Nikhilesh Bhagavatula
  2020-04-06 14:00                   ` Thomas Monjalon
  0 siblings, 1 reply; 96+ messages in thread
From: Pavan Nikhilesh Bhagavatula @ 2020-04-06 13:50 UTC (permalink / raw)
  To: Thomas Monjalon
  Cc: Ori Kam, Jerin Jacob Kollanukkaran, xiang.w.wang, dev,
	Shahaf Shuler, hemant.agrawal, Opher Reviv, Alex Rosenbaum,
	Dovrat Zifroni, Prasun Kapoor, nipun.gupta, bruce.richardson,
	yang.a.hong, harry.chang, gu.jian1, shanjiangh, zhangy.yun,
	lixingfu, wushuai, yuyingxia, fanchenggang, davidfgao, liuzhong1,
	zhaoyong11, oc, jim, hongjun.ni, j.bromhead, deri, fc, arthur.su,
	david.marchand



>-----Original Message-----
>From: Thomas Monjalon <thomas@monjalon.net>
>Sent: Monday, April 6, 2020 7:07 PM
>To: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>
>Cc: Ori Kam <orika@mellanox.com>; Jerin Jacob Kollanukkaran
><jerinj@marvell.com>; xiang.w.wang@intel.com; dev@dpdk.org;
>Shahaf Shuler <shahafs@mellanox.com>; hemant.agrawal@nxp.com;
>Opher Reviv <opher@mellanox.com>; Alex Rosenbaum
><alexr@mellanox.com>; Dovrat Zifroni <dovrat@marvell.com>; Prasun
>Kapoor <pkapoor@marvell.com>; nipun.gupta@nxp.com;
>bruce.richardson@intel.com; yang.a.hong@intel.com;
>harry.chang@intel.com; gu.jian1@zte.com.cn;
>shanjiangh@chinatelecom.cn; zhangy.yun@chinatelecom.cn;
>lixingfu@huachentel.com; wushuai@inspur.com;
>yuyingxia@yxlink.com; fanchenggang@sunyainfo.com;
>davidfgao@tencent.com; liuzhong1@chinaunicom.cn;
>zhaoyong11@huawei.com; oc@yunify.com; jim@netgate.com;
>hongjun.ni@intel.com; j.bromhead@titan-ic.com; deri@ntop.org;
>fc@napatech.com; arthur.su@lionic.com; david.marchand@redhat.com
>Subject: Re: [EXT] [PATCH v1 4/4] regexdev: implement regex rte level
>functions
>
>06/04/2020 15:22, Pavan Nikhilesh Bhagavatula:
>> >06/04/2020 14:33, Pavan Nikhilesh Bhagavatula:
>> >> >> From: Pavan Nikhilesh Bhagavatula
>> >> >> > >+uint16_t
>> >> >> > >+rte_regexdev_enqueue_burst(uint8_t dev_id, uint16_t
>> >qp_id,
>> >> >> > >+			   struct rte_regex_ops **ops, uint16_t
>> >nb_ops)
>> >> >> > >+{
>> >> >> > >+	return regex_devices[dev_id]-
>> >> >> > >>enqueue(regex_devices[dev_id], qp_id,
>> >> >> > >+					      ops, nb_ops);
>> >> >> > >+}
>> >> >> >
>> >> >> > Move these functions to .h in-lining them.
>> >> >> > Also, please add debug checks @see
>> >> >rte_eth_rx_burst/rte_eth_tx_burst.
>> >> >>
>> >> >> O.K will update.
>> >> >
>> >> >In general, inlining is a pain for ABI compatibility.
>> >> >Please inline only if the gain is very significant.
>> >> >
>> >>
>> >> The performance gain mostly comes from hoisting
>> >`regex_devices[dev_id]` load above the
>> >> poll loop.
>> >> Since, the performance measurement application is still in pipeline
>> >and regexdev would be
>> >> experimental for next couple of releases I suggest inlining it now
>and
>> >worrying about ABI when
>> >> experimental tag needs to be removed.
>> >
>> >No, we must worry about ABI from the beginning.
>>
>> I though performance was the primary objective :-).
>
>It is.
>
>> >> We can follow the same path as done by ethdev
>> >[https://urldefense.proofpoint.com/v2/url?u=https-
>3A__www.mail-
>> >2Darchive.com_dev-
>>
>>40dpdk.org_msg142392.html&d=DwICAg&c=nKjWec2b6R0mOyPaz7xt
>f
>> >Q&r=E3SgYMjtKCMVsB-fmvgGV3o-
>> >g_fjLhk5Pupi9ijohpc&m=7Gqb6WKmZV5uY3xa7FRVrRVDz8Usrsd-
>>
>>rDjIKr6CUQQ&s=sQo2Kx9fzTNXwiQ2Fzki3s5GSuiiAEzz2VtN68_KKXo&e
>=
>> >]
>> >
>> >ethdev is not an argument.
>>
>> What about ring? [https://urldefense.proofpoint.com/v2/url?u=http-
>3A__mails.dpdk.org_archives_dev_2020-
>2DApril_161506.html&d=DwICAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3S
>gYMjtKCMVsB-fmvgGV3o-
>g_fjLhk5Pupi9ijohpc&m=u9gnM_YrOJDusN4yR8YUcUuUkri4tOjnHrQ0A
>Qd5zTw&s=uv6AQA-
>Zu7o6ugyhpGHLxFOk4SfEdkHfFGDmhzANRME&e= ]
>>
>> Why do we need to prove the same performance advantage using in-
>lining for datapath
>> critical functions again and again?
>
>Because every libraries have not the same usage and load.
>We should compare how much cycle is saved with inline vs
>how much cycles is, "in average", a regex burst?
>
>If you tell me regex processing is fast, OK, let's inline.
>

Regex processing speed would still be dependent on underlying device capabilities.

All we are trying to do is reduce the enqueue/dequeue completion time which would 
bring down the overall latency.

Thanks,
Pavan.

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 4/4] regexdev: implement regex rte level functions
  2020-04-06 13:50                 ` Pavan Nikhilesh Bhagavatula
@ 2020-04-06 14:00                   ` Thomas Monjalon
  2020-04-06 18:53                     ` Ori Kam
  0 siblings, 1 reply; 96+ messages in thread
From: Thomas Monjalon @ 2020-04-06 14:00 UTC (permalink / raw)
  To: Pavan Nikhilesh Bhagavatula, Ori Kam
  Cc: Jerin Jacob Kollanukkaran, xiang.w.wang, dev, Shahaf Shuler,
	hemant.agrawal, Opher Reviv, Alex Rosenbaum, Dovrat Zifroni,
	Prasun Kapoor, nipun.gupta, bruce.richardson, yang.a.hong,
	harry.chang, gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai,
	yuyingxia, fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc,
	jim, hongjun.ni, j.bromhead, deri, fc, arthur.su, david.marchand

06/04/2020 15:50, Pavan Nikhilesh Bhagavatula:
> From: Thomas Monjalon <thomas@monjalon.net>
> >> >06/04/2020 14:33, Pavan Nikhilesh Bhagavatula:
> >> >> >> From: Pavan Nikhilesh Bhagavatula
> >> >> >> > >+uint16_t
> >> >> >> > >+rte_regexdev_enqueue_burst(uint8_t dev_id, uint16_t
> >> >qp_id,
> >> >> >> > >+			   struct rte_regex_ops **ops, uint16_t
> >> >nb_ops)
> >> >> >> > >+{
> >> >> >> > >+	return regex_devices[dev_id]-
> >> >> >> > >>enqueue(regex_devices[dev_id], qp_id,
> >> >> >> > >+					      ops, nb_ops);
> >> >> >> > >+}
> >> >> >> >
> >> >> >> > Move these functions to .h in-lining them.
> >> >> >> > Also, please add debug checks @see
> >> >> >rte_eth_rx_burst/rte_eth_tx_burst.
> >> >> >>
> >> >> >> O.K will update.
> >> >> >
> >> >> >In general, inlining is a pain for ABI compatibility.
> >> >> >Please inline only if the gain is very significant.
> >> >> >
> >> >>
> >> >> The performance gain mostly comes from hoisting
> >> >`regex_devices[dev_id]` load above the
> >> >> poll loop.
> >> >> Since, the performance measurement application is still in pipeline
> >> >and regexdev would be
> >> >> experimental for next couple of releases I suggest inlining it now
> >and
> >> >worrying about ABI when
> >> >> experimental tag needs to be removed.
> >> >
> >> >No, we must worry about ABI from the beginning.
> >>
> >> I though performance was the primary objective :-).
> >
> >It is.
> >
> >> >> We can follow the same path as done by ethdev
> >> >[https://urldefense.proofpoint.com/v2/url?u=https-
> >3A__www.mail-
> >> >2Darchive.com_dev-
> >>
> >>40dpdk.org_msg142392.html&d=DwICAg&c=nKjWec2b6R0mOyPaz7xt
> >f
> >> >Q&r=E3SgYMjtKCMVsB-fmvgGV3o-
> >> >g_fjLhk5Pupi9ijohpc&m=7Gqb6WKmZV5uY3xa7FRVrRVDz8Usrsd-
> >>
> >>rDjIKr6CUQQ&s=sQo2Kx9fzTNXwiQ2Fzki3s5GSuiiAEzz2VtN68_KKXo&e
> >=
> >> >]
> >> >
> >> >ethdev is not an argument.
> >>
> >> What about ring? [https://urldefense.proofpoint.com/v2/url?u=http-
> >3A__mails.dpdk.org_archives_dev_2020-
> >2DApril_161506.html&d=DwICAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3S
> >gYMjtKCMVsB-fmvgGV3o-
> >g_fjLhk5Pupi9ijohpc&m=u9gnM_YrOJDusN4yR8YUcUuUkri4tOjnHrQ0A
> >Qd5zTw&s=uv6AQA-
> >Zu7o6ugyhpGHLxFOk4SfEdkHfFGDmhzANRME&e= ]
> >>
> >> Why do we need to prove the same performance advantage using in-
> >lining for datapath
> >> critical functions again and again?
> >
> >Because every libraries have not the same usage and load.
> >We should compare how much cycle is saved with inline vs
> >how much cycles is, "in average", a regex burst?
> >
> >If you tell me regex processing is fast, OK, let's inline.
> >
> 
> Regex processing speed would still be dependent on underlying device capabilities.
> 
> All we are trying to do is reduce the enqueue/dequeue completion time which would 
> bring down the overall latency.

Take your regex HW and do a simple regex processing burst.
How many cycles it takes to complete?
How many cycles you lose if not inline?
If the ratio is lower than 1/200, I think inline is not a must.

Ori, please consider the same measure for your HW.



^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 4/4] regexdev: implement regex rte level functions
  2020-04-06 14:00                   ` Thomas Monjalon
@ 2020-04-06 18:53                     ` Ori Kam
  0 siblings, 0 replies; 96+ messages in thread
From: Ori Kam @ 2020-04-06 18:53 UTC (permalink / raw)
  To: Thomas Monjalon, Pavan Nikhilesh Bhagavatula
  Cc: Jerin Jacob Kollanukkaran, xiang.w.wang, dev, Shahaf Shuler,
	hemant.agrawal, Opher Reviv, Alex Rosenbaum, Dovrat Zifroni,
	Prasun Kapoor, nipun.gupta, bruce.richardson, yang.a.hong,
	harry.chang, gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai,
	yuyingxia, fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc,
	jim, hongjun.ni, j.bromhead, deri, fc, arthur.su, david.marchand



> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Thomas Monjalon
> Sent: Monday, April 6, 2020 5:00 PM
> To: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Ori Kam
> <orika@mellanox.com>
> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; xiang.w.wang@intel.com;
> dev@dpdk.org; Shahaf Shuler <shahafs@mellanox.com>;
> hemant.agrawal@nxp.com; Opher Reviv <opher@mellanox.com>; Alex
> Rosenbaum <alexr@mellanox.com>; Dovrat Zifroni <dovrat@marvell.com>;
> Prasun Kapoor <pkapoor@marvell.com>; nipun.gupta@nxp.com;
> bruce.richardson@intel.com; yang.a.hong@intel.com; harry.chang@intel.com;
> gu.jian1@zte.com.cn; shanjiangh@chinatelecom.cn;
> zhangy.yun@chinatelecom.cn; lixingfu@huachentel.com; wushuai@inspur.com;
> yuyingxia@yxlink.com; fanchenggang@sunyainfo.com;
> davidfgao@tencent.com; liuzhong1@chinaunicom.cn;
> zhaoyong11@huawei.com; oc@yunify.com; jim@netgate.com;
> hongjun.ni@intel.com; j.bromhead@titan-ic.com; deri@ntop.org;
> fc@napatech.com; arthur.su@lionic.com; david.marchand@redhat.com
> Subject: Re: [dpdk-dev] [EXT] [PATCH v1 4/4] regexdev: implement regex rte
> level functions
> 
> 06/04/2020 15:50, Pavan Nikhilesh Bhagavatula:
> > From: Thomas Monjalon <thomas@monjalon.net>
> > >> >06/04/2020 14:33, Pavan Nikhilesh Bhagavatula:
> > >> >> >> From: Pavan Nikhilesh Bhagavatula
> > >> >> >> > >+uint16_t
> > >> >> >> > >+rte_regexdev_enqueue_burst(uint8_t dev_id, uint16_t
> > >> >qp_id,
> > >> >> >> > >+			   struct rte_regex_ops **ops, uint16_t
> > >> >nb_ops)
> > >> >> >> > >+{
> > >> >> >> > >+	return regex_devices[dev_id]-
> > >> >> >> > >>enqueue(regex_devices[dev_id], qp_id,
> > >> >> >> > >+					      ops, nb_ops);
> > >> >> >> > >+}
> > >> >> >> >
> > >> >> >> > Move these functions to .h in-lining them.
> > >> >> >> > Also, please add debug checks @see
> > >> >> >rte_eth_rx_burst/rte_eth_tx_burst.
> > >> >> >>
> > >> >> >> O.K will update.
> > >> >> >
> > >> >> >In general, inlining is a pain for ABI compatibility.
> > >> >> >Please inline only if the gain is very significant.
> > >> >> >
> > >> >>
> > >> >> The performance gain mostly comes from hoisting
> > >> >`regex_devices[dev_id]` load above the
> > >> >> poll loop.
> > >> >> Since, the performance measurement application is still in pipeline
> > >> >and regexdev would be
> > >> >> experimental for next couple of releases I suggest inlining it now
> > >and
> > >> >worrying about ABI when
> > >> >> experimental tag needs to be removed.
> > >> >
> > >> >No, we must worry about ABI from the beginning.
> > >>
> > >> I though performance was the primary objective :-).
> > >
> > >It is.
> > >
> > >> >> We can follow the same path as done by ethdev
> > >>
> >[https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefe
> nse.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-
> &amp;data=02%7C01%7Corika%40mellanox.com%7Cc3e07910f52846f64b5008
> d7da32d82e%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C6372177
> 84252928490&amp;sdata=8Pxq8ciUVW7bMiB1XmQBNm%2Fsmy8m1Wa7yKXK
> JRL4d%2B4%3D&amp;reserved=0
> >
> >3A__https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww
> w.mail-
> %2F&amp;data=02%7C01%7Corika%40mellanox.com%7Cc3e07910f52846f64b
> 5008d7da32d82e%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C637
> 217784252928490&amp;sdata=sTDsN85xShTU7WOLQQ2iF8eh%2FyoVHYwDq%
> 2FTdgdHdlbM%3D&amp;reserved=0
> > >> >2Darchive.com_dev-
> > >>
> > >>40dpdk.org_msg142392.html&d=DwICAg&c=nKjWec2b6R0mOyPaz7xt
> > >f
> > >> >Q&r=E3SgYMjtKCMVsB-fmvgGV3o-
> > >> >g_fjLhk5Pupi9ijohpc&m=7Gqb6WKmZV5uY3xa7FRVrRVDz8Usrsd-
> > >>
> > >>rDjIKr6CUQQ&s=sQo2Kx9fzTNXwiQ2Fzki3s5GSuiiAEzz2VtN68_KKXo&e
> > >=
> > >> >]
> > >> >
> > >> >ethdev is not an argument.
> > >>
> > >> What about ring?
> [https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefens
> e.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-
> &amp;data=02%7C01%7Corika%40mellanox.com%7Cc3e07910f52846f64b5008
> d7da32d82e%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C6372177
> 84252928490&amp;sdata=t2qUIj51WPzqQhJngheYh1s7DWzOxd%2FcAyAQK39C
> HgQ%3D&amp;reserved=0
> > >3A__mails.dpdk.org_archives_dev_2020-
> > >2DApril_161506.html&d=DwICAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3S
> > >gYMjtKCMVsB-fmvgGV3o-
> > >g_fjLhk5Pupi9ijohpc&m=u9gnM_YrOJDusN4yR8YUcUuUkri4tOjnHrQ0A
> > >Qd5zTw&s=uv6AQA-
> > >Zu7o6ugyhpGHLxFOk4SfEdkHfFGDmhzANRME&e= ]
> > >>
> > >> Why do we need to prove the same performance advantage using in-
> > >lining for datapath
> > >> critical functions again and again?
> > >
> > >Because every libraries have not the same usage and load.
> > >We should compare how much cycle is saved with inline vs
> > >how much cycles is, "in average", a regex burst?
> > >
> > >If you tell me regex processing is fast, OK, let's inline.
> > >
> >
> > Regex processing speed would still be dependent on underlying device
> capabilities.
> >
> > All we are trying to do is reduce the enqueue/dequeue completion time
> which would
> > bring down the overall latency.
> 
> Take your regex HW and do a simple regex processing burst.
> How many cycles it takes to complete?
> How many cycles you lose if not inline?
> If the ratio is lower than 1/200, I think inline is not a must.
> 
> Ori, please consider the same measure for your HW.
> 
I think that the default for data path should be inline.
In this specific case maybe the benefit is small.
I guess that by definition the RegEx is slower than the net device.
It is much harder to check the performance of RegEx device due to the 
fact that it depends on the data itself and on the rules.

I don't have HW to check the numbers right now. Even if I have them
this is for Mellanox implementation other PMD may have different values.
I suggest that we change to inline, and after getting the HW we will run some tests
and based on them we can decide if the API should be changed.
Please note that the API change will be before the first integration of this patch
so it is not real API change.

 


^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core functions
  2020-04-06 13:38               ` Jerin Jacob
@ 2020-04-06 19:11                 ` Ori Kam
  2020-04-07  5:49                   ` Jerin Jacob
  2020-04-07 14:21                   ` Guy Kaneti
  0 siblings, 2 replies; 96+ messages in thread
From: Ori Kam @ 2020-04-06 19:11 UTC (permalink / raw)
  To: Jerin Jacob, Thomas Monjalon
  Cc: Jerin Jacob Kollanukkaran, xiang.w.wang,
	Pavan Nikhilesh Bhagavatula, dev, Shahaf Shuler, hemant.agrawal,
	Opher Reviv, Alex Rosenbaum, Dovrat Zifroni, Prasun Kapoor,
	nipun.gupta, bruce.richardson, yang.a.hong, harry.chang,
	gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai, yuyingxia,
	fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc, jim,
	hongjun.ni, j.bromhead, deri, fc, arthur.su, Parav Pandit

Hi 

Best,
Ori
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Monday, April 6, 2020 4:39 PM
> To: Thomas Monjalon <thomas@monjalon.net>
> Cc: Ori Kam <orika@mellanox.com>; Jerin Jacob Kollanukkaran
> <jerinj@marvell.com>; xiang.w.wang@intel.com; Pavan Nikhilesh Bhagavatula
> <pbhagavatula@marvell.com>; dev@dpdk.org; Shahaf Shuler
> <shahafs@mellanox.com>; hemant.agrawal@nxp.com; Opher Reviv
> <opher@mellanox.com>; Alex Rosenbaum <alexr@mellanox.com>; Dovrat
> Zifroni <dovrat@marvell.com>; Prasun Kapoor <pkapoor@marvell.com>;
> nipun.gupta@nxp.com; bruce.richardson@intel.com; yang.a.hong@intel.com;
> harry.chang@intel.com; gu.jian1@zte.com.cn; shanjiangh@chinatelecom.cn;
> zhangy.yun@chinatelecom.cn; lixingfu@huachentel.com; wushuai@inspur.com;
> yuyingxia@yxlink.com; fanchenggang@sunyainfo.com;
> davidfgao@tencent.com; liuzhong1@chinaunicom.cn;
> zhaoyong11@huawei.com; oc@yunify.com; jim@netgate.com;
> hongjun.ni@intel.com; j.bromhead@titan-ic.com; deri@ntop.org;
> fc@napatech.com; arthur.su@lionic.com; Parav Pandit <parav@mellanox.com>
> Subject: Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core
> functions
> 
> On Mon, Apr 6, 2020 at 7:00 PM Thomas Monjalon <thomas@monjalon.net>
> wrote:
> >
> > 06/04/2020 14:48, Pavan Nikhilesh Bhagavatula:
> > > > From: Pavan Nikhilesh Bhagavatula
> > > >> >> From: Pavan Nikhilesh Bhagavatula
> > > >> >>
> > > >> >> Looks like this implementation is incomplete?
> > > >> >> I don't see any pmd specific helper functions for @see
> > > >> >rte_cryptodev_pmd.c,
> > > >> >> rte_eventdev_pmd*
> > > >> >>
> > > >> >I think the current implementation includes all needed functions,
> > > >> >at least for the first stage.
> > > >> >You can find in rte_regexdev_driver.h the functions that should be
> > > >> >called
> > > >> >by the PMD. We have the register / unregister which acts the same
> > > >as
> > > >> >create
> > > >> >and destroy. For parsing argument the PMD may call
> > > >rte_kvargs_parse.
> > > >> >
> > > >>
> > > >> _driver.h should atleast include
> > > >> rte_regex_dev_pci_generic_probe/rte_regex_pmd_vdev_init
> > > >> else there would be a lot of code repetition and possibly udefined
> > > >behavior
> > > >> at the driver layer.
> > > >>
> > > >Why should they be included? At least in this stage, there is no code to
> > > >share
> > > >ethdev why should we add code for the vdev?
> > >
> > > Ok I think I failed to communicate my concerns across.
> > > Let me retry
> > >
> > > 1. SW based regex devices such as PCRE/Hyperscan rely on vdev framework
> > > i.e. user needs to pass an EAL argument --vdev="regex_pcre" for the driver
> to
> > > initialize all the other EAL subsystems (ethdev, eventdev, cryptodev,
> etc..)support this.
> >
> > vdev helpers do not have to be part of the first patches which define API.
> > It should be added when adding the first vdev driver.
> 
> Yes. When we add vdev, we should not rewrite again to support vdev.
> So care must taken for proper implementation in the first place avoid rework.
> 
> If it abstracts it properly adding vdev and PCI is a simple change.
> See
> 
> lib/librte_eventdev/rte_eventdev_pmd_vdev.h
> lib/librte_eventdev/rte_eventdev_pmd_pci.h
> 
> I think, the common code should take from other matured subsystem instead if
> writing from scratch,
> 
I agree with you about the rewrite, but this is why I don't want to add this code
until I know what this code should do and how it should be used.
I  don't agree, that one subsystem is like other one by default, and that if something
is done for one subsystem it should be done for other.
Not always what was done before is the best.

Some time back there was a long thread about ethdev and the rte device
where should it be released and by whom. 
My basic thinking is that unless proven otherwise the code should be in the PMD
this is also why it is important for me to get this rte level API acked.
when starting to implement the code for the PMD it will be cleared what 
is the shared code and how it is best to configure the system.
Also this is not external API so it can be changed at any time. 
Saying that I don't think we should wait long before adding such code.
I think that when we will have our first PMD we know better if such 
function is needed.
Also think about that maybe this PMD will be shared with the 
net PMD so such function will also introduce more complexity.

> 
> >
> > > 2. HW based independent regex devices that are exposed as PCI devices
> would need
> > >  pci probe helpers.
> >
> > Same, PCI helpers can be added while adding the first PCI driver.
> >
> > We can synchronize about how to split the work, avoiding two developers
> > doing the same thing. But let's not mandate this work to be done
> > as part of this first series.
> >
> >
> >

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core functions
  2020-04-06 19:11                 ` Ori Kam
@ 2020-04-07  5:49                   ` Jerin Jacob
  2020-04-07  6:46                     ` Ori Kam
  2020-04-07 12:27                     ` Thomas Monjalon
  2020-04-07 14:21                   ` Guy Kaneti
  1 sibling, 2 replies; 96+ messages in thread
From: Jerin Jacob @ 2020-04-07  5:49 UTC (permalink / raw)
  To: Ori Kam
  Cc: Thomas Monjalon, Jerin Jacob Kollanukkaran, xiang.w.wang,
	Pavan Nikhilesh Bhagavatula, dev, Shahaf Shuler, hemant.agrawal,
	Opher Reviv, Alex Rosenbaum, Dovrat Zifroni, Prasun Kapoor,
	nipun.gupta, bruce.richardson, yang.a.hong, harry.chang,
	gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai, yuyingxia,
	fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc, jim,
	hongjun.ni, j.bromhead, deri, fc, arthur.su, Parav Pandit

> >
> > If it abstracts it properly adding vdev and PCI is a simple change.
> > See
> >
> > lib/librte_eventdev/rte_eventdev_pmd_vdev.h
> > lib/librte_eventdev/rte_eventdev_pmd_pci.h
> >
> > I think, the common code should take from other matured subsystem instead if
> > writing from scratch,
> >
> I agree with you about the rewrite, but this is why I don't want to add this code
> until I know what this code should do and how it should be used.
> I  don't agree, that one subsystem is like other one by default, and that if something
> is done for one subsystem it should be done for other.
> Not always what was done before is the best.
>
> Some time back there was a long thread about ethdev and the rte device
> where should it be released and by whom.
> My basic thinking is that unless proven otherwise the code should be in the PMD
> this is also why it is important for me to get this rte level API acked.
> when starting to implement the code for the PMD it will be cleared what
> is the shared code and how it is best to configure the system.
> Also this is not external API so it can be changed at any time.
> Saying that I don't think we should wait long before adding such code.
> I think that when we will have our first PMD we know better if such
> function is needed.
> Also think about that maybe this PMD will be shared with the
> net PMD so such function will also introduce more complexity.


My thought process was I like this when I added the common code for eventdev.
I have checked ethdev, cryptodev and followed a similar scheme
wherever it applicable for eventdev.
If we see the regexdev API, it is similar to ethdev. cryptodev and
eventdev API. From the device
API PoV, the framework needs to follow the same behavior to avoid
having new behavior for regexdev,
Especially in configure->queue_setup->start->rx_burst->tx_burst->stop->reconfigure->start
sequence.


Ethdev may be bloated by features, My request is to take cryptodev and
eventdev as a base
change to accordingly. That makes review process easy, As reviewer
needs only think, The rationale  behind,
Why it regexdev common code chosen a different approach. Writing from
scratch makes the reviewer's job
difficult.

We spend a lot of time reviewing and make mature cryptodev and
eventdev common code, Please leverage that.

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core functions
  2020-04-07  5:49                   ` Jerin Jacob
@ 2020-04-07  6:46                     ` Ori Kam
  2020-04-07  7:22                       ` Jerin Jacob
  2020-04-07 12:27                     ` Thomas Monjalon
  1 sibling, 1 reply; 96+ messages in thread
From: Ori Kam @ 2020-04-07  6:46 UTC (permalink / raw)
  To: Jerin Jacob
  Cc: Thomas Monjalon, Jerin Jacob Kollanukkaran, xiang.w.wang,
	Pavan Nikhilesh Bhagavatula, dev, Shahaf Shuler, hemant.agrawal,
	Opher Reviv, Alex Rosenbaum, Dovrat Zifroni, Prasun Kapoor,
	nipun.gupta, bruce.richardson, yang.a.hong, harry.chang,
	gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai, yuyingxia,
	fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc, jim,
	hongjun.ni, j.bromhead, deri, fc, arthur.su, Parav Pandit



> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Tuesday, April 7, 2020 8:50 AM
> To: Ori Kam <orika@mellanox.com>
> Cc: Thomas Monjalon <thomas@monjalon.net>; Jerin Jacob Kollanukkaran
> <jerinj@marvell.com>; xiang.w.wang@intel.com; Pavan Nikhilesh Bhagavatula
> <pbhagavatula@marvell.com>; dev@dpdk.org; Shahaf Shuler
> <shahafs@mellanox.com>; hemant.agrawal@nxp.com; Opher Reviv
> <opher@mellanox.com>; Alex Rosenbaum <alexr@mellanox.com>; Dovrat
> Zifroni <dovrat@marvell.com>; Prasun Kapoor <pkapoor@marvell.com>;
> nipun.gupta@nxp.com; bruce.richardson@intel.com; yang.a.hong@intel.com;
> harry.chang@intel.com; gu.jian1@zte.com.cn; shanjiangh@chinatelecom.cn;
> zhangy.yun@chinatelecom.cn; lixingfu@huachentel.com; wushuai@inspur.com;
> yuyingxia@yxlink.com; fanchenggang@sunyainfo.com;
> davidfgao@tencent.com; liuzhong1@chinaunicom.cn;
> zhaoyong11@huawei.com; oc@yunify.com; jim@netgate.com;
> hongjun.ni@intel.com; j.bromhead@titan-ic.com; deri@ntop.org;
> fc@napatech.com; arthur.su@lionic.com; Parav Pandit <parav@mellanox.com>
> Subject: Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core
> functions
> 
> > >
> > > If it abstracts it properly adding vdev and PCI is a simple change.
> > > See
> > >
> > > lib/librte_eventdev/rte_eventdev_pmd_vdev.h
> > > lib/librte_eventdev/rte_eventdev_pmd_pci.h
> > >
> > > I think, the common code should take from other matured subsystem
> instead if
> > > writing from scratch,
> > >
> > I agree with you about the rewrite, but this is why I don't want to add this
> code
> > until I know what this code should do and how it should be used.
> > I  don't agree, that one subsystem is like other one by default, and that if
> something
> > is done for one subsystem it should be done for other.
> > Not always what was done before is the best.
> >
> > Some time back there was a long thread about ethdev and the rte device
> > where should it be released and by whom.
> > My basic thinking is that unless proven otherwise the code should be in the
> PMD
> > this is also why it is important for me to get this rte level API acked.
> > when starting to implement the code for the PMD it will be cleared what
> > is the shared code and how it is best to configure the system.
> > Also this is not external API so it can be changed at any time.
> > Saying that I don't think we should wait long before adding such code.
> > I think that when we will have our first PMD we know better if such
> > function is needed.
> > Also think about that maybe this PMD will be shared with the
> > net PMD so such function will also introduce more complexity.
> 
> 
> My thought process was I like this when I added the common code for
> eventdev.
> I have checked ethdev, cryptodev and followed a similar scheme
> wherever it applicable for eventdev.
> If we see the regexdev API, it is similar to ethdev. cryptodev and
> eventdev API. From the device
> API PoV, the framework needs to follow the same behavior to avoid
> having new behavior for regexdev,
> Especially in configure->queue_setup->start->rx_burst->tx_burst->stop-
> >reconfigure->start
> sequence.
> 
> 
> Ethdev may be bloated by features, My request is to take cryptodev and
> eventdev as a base
> change to accordingly. That makes review process easy, As reviewer
> needs only think, The rationale  behind,
> Why it regexdev common code chosen a different approach. Writing from
> scratch makes the reviewer's job
> difficult.
> 
> We spend a lot of time reviewing and make mature cryptodev and
> eventdev common code, Please leverage that.

I fully agree with you that we should leverage known code as much as we
can. But just like you said the idea is to know what the RegEx needs 
and then see how it is done in other modules.
I don't know how the vdev pmd will look like (I can guess)
So I prefer to add this code in later stage where we will get better
Understanding on how best to implement it. 

We have the configure, queue_setup, start, enqueue, dequeue and stop.
I will add support for reconfigure like I said in previous code.
So if I understand correctly from your point of view, this patch is just missing
the vdev functions right? If so lets keep them out for now, I promise you that if needed
I will add this function.


^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core functions
  2020-04-07  6:46                     ` Ori Kam
@ 2020-04-07  7:22                       ` Jerin Jacob
  0 siblings, 0 replies; 96+ messages in thread
From: Jerin Jacob @ 2020-04-07  7:22 UTC (permalink / raw)
  To: Ori Kam
  Cc: Thomas Monjalon, Jerin Jacob Kollanukkaran, xiang.w.wang,
	Pavan Nikhilesh Bhagavatula, dev, Shahaf Shuler, hemant.agrawal,
	Opher Reviv, Alex Rosenbaum, Dovrat Zifroni, Prasun Kapoor,
	nipun.gupta, bruce.richardson, yang.a.hong, harry.chang,
	gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai, yuyingxia,
	fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc, jim,
	hongjun.ni, j.bromhead, deri, fc, arthur.su, Parav Pandit

On Tue, Apr 7, 2020 at 12:16 PM Ori Kam <orika@mellanox.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Tuesday, April 7, 2020 8:50 AM
> > To: Ori Kam <orika@mellanox.com>
> > Cc: Thomas Monjalon <thomas@monjalon.net>; Jerin Jacob Kollanukkaran
> > <jerinj@marvell.com>; xiang.w.wang@intel.com; Pavan Nikhilesh Bhagavatula
> > <pbhagavatula@marvell.com>; dev@dpdk.org; Shahaf Shuler
> > <shahafs@mellanox.com>; hemant.agrawal@nxp.com; Opher Reviv
> > <opher@mellanox.com>; Alex Rosenbaum <alexr@mellanox.com>; Dovrat
> > Zifroni <dovrat@marvell.com>; Prasun Kapoor <pkapoor@marvell.com>;
> > nipun.gupta@nxp.com; bruce.richardson@intel.com; yang.a.hong@intel.com;
> > harry.chang@intel.com; gu.jian1@zte.com.cn; shanjiangh@chinatelecom.cn;
> > zhangy.yun@chinatelecom.cn; lixingfu@huachentel.com; wushuai@inspur.com;
> > yuyingxia@yxlink.com; fanchenggang@sunyainfo.com;
> > davidfgao@tencent.com; liuzhong1@chinaunicom.cn;
> > zhaoyong11@huawei.com; oc@yunify.com; jim@netgate.com;
> > hongjun.ni@intel.com; j.bromhead@titan-ic.com; deri@ntop.org;
> > fc@napatech.com; arthur.su@lionic.com; Parav Pandit <parav@mellanox.com>
> > Subject: Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core
> > functions
> >
> > > >
> > > > If it abstracts it properly adding vdev and PCI is a simple change.
> > > > See
> > > >
> > > > lib/librte_eventdev/rte_eventdev_pmd_vdev.h
> > > > lib/librte_eventdev/rte_eventdev_pmd_pci.h
> > > >
> > > > I think, the common code should take from other matured subsystem
> > instead if
> > > > writing from scratch,
> > > >
> > > I agree with you about the rewrite, but this is why I don't want to add this
> > code
> > > until I know what this code should do and how it should be used.
> > > I  don't agree, that one subsystem is like other one by default, and that if
> > something
> > > is done for one subsystem it should be done for other.
> > > Not always what was done before is the best.
> > >
> > > Some time back there was a long thread about ethdev and the rte device
> > > where should it be released and by whom.
> > > My basic thinking is that unless proven otherwise the code should be in the
> > PMD
> > > this is also why it is important for me to get this rte level API acked.
> > > when starting to implement the code for the PMD it will be cleared what
> > > is the shared code and how it is best to configure the system.
> > > Also this is not external API so it can be changed at any time.
> > > Saying that I don't think we should wait long before adding such code.
> > > I think that when we will have our first PMD we know better if such
> > > function is needed.
> > > Also think about that maybe this PMD will be shared with the
> > > net PMD so such function will also introduce more complexity.
> >
> >
> > My thought process was I like this when I added the common code for
> > eventdev.
> > I have checked ethdev, cryptodev and followed a similar scheme
> > wherever it applicable for eventdev.
> > If we see the regexdev API, it is similar to ethdev. cryptodev and
> > eventdev API. From the device
> > API PoV, the framework needs to follow the same behavior to avoid
> > having new behavior for regexdev,
> > Especially in configure->queue_setup->start->rx_burst->tx_burst->stop-
> > >reconfigure->start
> > sequence.
> >
> >
> > Ethdev may be bloated by features, My request is to take cryptodev and
> > eventdev as a base
> > change to accordingly. That makes review process easy, As reviewer
> > needs only think, The rationale  behind,
> > Why it regexdev common code chosen a different approach. Writing from
> > scratch makes the reviewer's job
> > difficult.
> >
> > We spend a lot of time reviewing and make mature cryptodev and
> > eventdev common code, Please leverage that.
>
> I fully agree with you that we should leverage known code as much as we
> can. But just like you said the idea is to know what the RegEx needs
> and then see how it is done in other modules.
> I don't know how the vdev pmd will look like (I can guess)
> So I prefer to add this code in later stage where we will get better
> Understanding on how best to implement it.

OK.

>
> We have the configure, queue_setup, start, enqueue, dequeue and stop.
> I will add support for reconfigure like I said in previous code.
> So if I understand correctly from your point of view, this patch is just missing
> the vdev functions right? If so lets keep them out for now, I promise you that if needed
> I will add this function.

OK. Just to clarify, what I meant is, when we add the vdev, it should
simple as following[1]
ie. rte_event_pmd_allocate()  and rte_event_pmd_release() etc reused
from PCI and VDEV.
i.e
a) lets have common routes like rte_event_pmd_allocate() for PMD
device allocation irrespective of VDEV for PCI
b) add PCI specific code
c) add VDEV specific code like [1]

[1]
static inline struct rte_eventdev *
rte_event_pmd_vdev_init(const char *name, size_t dev_private_size,
                int socket_id)
{

        struct rte_eventdev *eventdev;

        /* Allocate device structure */
        eventdev = rte_event_pmd_allocate(name, socket_id);
        if (eventdev == NULL)
                return NULL;

        /* Allocate private device structure */
        if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
                eventdev->data->dev_private =
                                rte_zmalloc_socket("eventdev device private",
                                                dev_private_size,
                                                RTE_CACHE_LINE_SIZE,
                                                socket_id);

                if (eventdev->data->dev_private == NULL)
                        rte_panic("Cannot allocate memzone for private device"
                                        " data");
        }

        return eventdev;
}


static inline int
rte_event_pmd_vdev_uninit(const char *name)
{
        int ret;
        struct rte_eventdev *eventdev;

        if (name == NULL)
                return -EINVAL;

        eventdev = rte_event_pmd_get_named_dev(name);
        if (eventdev == NULL)
                return -ENODEV;

        ret = rte_event_dev_close(eventdev->data->dev_id);
        if (ret < 0)
                return ret;

        /* Free the event device */
        rte_event_pmd_release(eventdev);

        return 0;
}
>

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [PATCH v1 2/4] regexdev: add regex core h file
       [not found]   ` <DM5PR18MB221411AAEAFFA9D9F373292BC6C20@DM5PR18MB2214.namprd18.prod.outlook.com>
@ 2020-04-07  8:53     ` Guy Kaneti
  2020-04-07 16:16       ` Ori Kam
  0 siblings, 1 reply; 96+ messages in thread
From: Guy Kaneti @ 2020-04-07  8:53 UTC (permalink / raw)
  To: Ori Kam, Jerin Jacob Kollanukkaran, xiang.w.wang
  Cc: dev, Pavan Nikhilesh Bhagavatula, Shahaf Shuler, hemant.agrawal,
	Opher Reviv, Alex Rosenbaum, Dovrat Zifroni, Prasun Kapoor,
	nipun.gupta, bruce.richardson, yang.a.hong, harry.chang,
	gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai, yuyingxia,
	fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc, jim,
	hongjun.ni, j.bromhead, deri, fc, arthur.su, Thomas Monjalon,
	Parav Pandit

> +
> +/**
> + * @internal
> + * The generic data structure associated with each RegEx device.
> + *
> + * Pointers to burst-oriented packet receive and transmit functions are
> + * located at the beginning of the structure, along with the pointer to
> + * where all the data elements for the particular device are stored in
> +shared
> + * memory. This split allows the function pointer and driver data to be
> +per-
> + * process, while the actual configuration data for the device is shared.
> + */
> +struct rte_regexdev {
> +	regexdev_enqueue_t enqueue;
> +	regexdev_dequeue_t dequeue;
> +	const struct rte_regexdev_ops *dev_ops;
> +	/**< Functions exported by PMD */
> +	struct rte_device *device; /**< Backing device */ }
> +__rte_cache_aligned;
> +

What about a handle for the PMD private data such as
	struct rte_eventdev_data *data;
	/**< Pointer to device data */

	struct rte_cryptodev_data *data;
	/**< Pointer to device data */

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core functions
  2020-04-07  5:49                   ` Jerin Jacob
  2020-04-07  6:46                     ` Ori Kam
@ 2020-04-07 12:27                     ` Thomas Monjalon
  2020-04-07 12:54                       ` Jerin Jacob
  1 sibling, 1 reply; 96+ messages in thread
From: Thomas Monjalon @ 2020-04-07 12:27 UTC (permalink / raw)
  To: Jerin Jacob, Jerin Jacob Kollanukkaran
  Cc: Ori Kam, xiang.w.wang, Pavan Nikhilesh Bhagavatula, dev,
	Shahaf Shuler, hemant.agrawal, Opher Reviv, Alex Rosenbaum,
	Dovrat Zifroni, Prasun Kapoor, nipun.gupta, bruce.richardson,
	yang.a.hong, harry.chang, gu.jian1, shanjiangh, zhangy.yun,
	lixingfu, wushuai, yuyingxia, fanchenggang, davidfgao, liuzhong1,
	zhaoyong11, oc, jim, hongjun.ni, j.bromhead, deri, fc, arthur.su,
	Parav Pandit

07/04/2020 07:49, Jerin Jacob:
> > >
> > > If it abstracts it properly adding vdev and PCI is a simple change.
> > > See
> > >
> > > lib/librte_eventdev/rte_eventdev_pmd_vdev.h
> > > lib/librte_eventdev/rte_eventdev_pmd_pci.h
> > >
> > > I think, the common code should take from other matured subsystem instead if
> > > writing from scratch,
> > >
> > I agree with you about the rewrite, but this is why I don't want to add this code
> > until I know what this code should do and how it should be used.
> > I  don't agree, that one subsystem is like other one by default, and that if something
> > is done for one subsystem it should be done for other.
> > Not always what was done before is the best.
> >
> > Some time back there was a long thread about ethdev and the rte device
> > where should it be released and by whom.
> > My basic thinking is that unless proven otherwise the code should be in the PMD
> > this is also why it is important for me to get this rte level API acked.
> > when starting to implement the code for the PMD it will be cleared what
> > is the shared code and how it is best to configure the system.
> > Also this is not external API so it can be changed at any time.
> > Saying that I don't think we should wait long before adding such code.
> > I think that when we will have our first PMD we know better if such
> > function is needed.
> > Also think about that maybe this PMD will be shared with the
> > net PMD so such function will also introduce more complexity.
> 
> 
> My thought process was I like this when I added the common code for eventdev.
> I have checked ethdev, cryptodev and followed a similar scheme
> wherever it applicable for eventdev.
> If we see the regexdev API, it is similar to ethdev. cryptodev and
> eventdev API. From the device
> API PoV, the framework needs to follow the same behavior to avoid
> having new behavior for regexdev,
> Especially in configure->queue_setup->start->rx_burst->tx_burst->stop->reconfigure->start
> sequence.
> 
> 
> Ethdev may be bloated by features,

No, ethdev has more features and is evolving as a better API.

> My request is to take cryptodev and
> eventdev as a base
> change to accordingly.

When writing a new API, we should learn from past lessons,
including eventdev and cryptodev, but also all the things evolving
in ethdev.

> That makes review process easy, As reviewer
> needs only think, The rationale  behind,
> Why it regexdev common code chosen a different approach. Writing from
> scratch makes the reviewer's job
> difficult.
> 
> We spend a lot of time reviewing and make mature cryptodev and
> eventdev common code, Please leverage that.

Again, leveraging doesn't mean to implement all in one patch.
Instead of asking for adding more, please focus on what must be changed
in what is proposed in this series.



^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core functions
  2020-04-07 12:27                     ` Thomas Monjalon
@ 2020-04-07 12:54                       ` Jerin Jacob
  0 siblings, 0 replies; 96+ messages in thread
From: Jerin Jacob @ 2020-04-07 12:54 UTC (permalink / raw)
  To: Thomas Monjalon
  Cc: Jerin Jacob Kollanukkaran, Ori Kam, xiang.w.wang,
	Pavan Nikhilesh Bhagavatula, dev, Shahaf Shuler, hemant.agrawal,
	Opher Reviv, Alex Rosenbaum, Dovrat Zifroni, Prasun Kapoor,
	nipun.gupta, bruce.richardson, yang.a.hong, harry.chang,
	gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai, yuyingxia,
	fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc, jim,
	hongjun.ni, j.bromhead, deri, fc, arthur.su, Parav Pandit

On Tue, Apr 7, 2020 at 5:57 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 07/04/2020 07:49, Jerin Jacob:
> > > >
> > > > If it abstracts it properly adding vdev and PCI is a simple change.
> > > > See
> > > >
> > > > lib/librte_eventdev/rte_eventdev_pmd_vdev.h
> > > > lib/librte_eventdev/rte_eventdev_pmd_pci.h
> > > >
> > > > I think, the common code should take from other matured subsystem instead if
> > > > writing from scratch,
> > > >
> > > I agree with you about the rewrite, but this is why I don't want to add this code
> > > until I know what this code should do and how it should be used.
> > > I  don't agree, that one subsystem is like other one by default, and that if something
> > > is done for one subsystem it should be done for other.
> > > Not always what was done before is the best.
> > >
> > > Some time back there was a long thread about ethdev and the rte device
> > > where should it be released and by whom.
> > > My basic thinking is that unless proven otherwise the code should be in the PMD
> > > this is also why it is important for me to get this rte level API acked.
> > > when starting to implement the code for the PMD it will be cleared what
> > > is the shared code and how it is best to configure the system.
> > > Also this is not external API so it can be changed at any time.
> > > Saying that I don't think we should wait long before adding such code.
> > > I think that when we will have our first PMD we know better if such
> > > function is needed.
> > > Also think about that maybe this PMD will be shared with the
> > > net PMD so such function will also introduce more complexity.
> >
> >
> > My thought process was I like this when I added the common code for eventdev.
> > I have checked ethdev, cryptodev and followed a similar scheme
> > wherever it applicable for eventdev.
> > If we see the regexdev API, it is similar to ethdev. cryptodev and
> > eventdev API. From the device
> > API PoV, the framework needs to follow the same behavior to avoid
> > having new behavior for regexdev,
> > Especially in configure->queue_setup->start->rx_burst->tx_burst->stop->reconfigure->start
> > sequence.
> >
> >
> > Ethdev may be bloated by features,
>
> No, ethdev has more features and is evolving as a better API.

I meant the same, where ethdev filled with "ethdev specific" features,
better take another subsystem for devices
specific thing.

>
> > My request is to take cryptodev and
> > eventdev as a base
> > change to accordingly.
>
> When writing a new API, we should learn from past lessons,
> including eventdev and cryptodev, but also all the things evolving
> in ethdev.

It looks out of context.

>
> > That makes review process easy, As reviewer
> > needs only think, The rationale  behind,
> > Why it regexdev common code chosen a different approach. Writing from
> > scratch makes the reviewer's job
> > difficult.
> >
> > We spend a lot of time reviewing and make mature cryptodev and
> > eventdev common code, Please leverage that.
>
> Again, leveraging doesn't mean to implement all in one patch.
> Instead of asking for adding more, please focus on what must be changed
> in what is proposed in this series.


Look at the configure function[1], Does it take care of reconfiguration?
Common code takes care of allocating memory for point for queue
objects. Where is that?

http://patches.dpdk.org/patch/67311/

I will put in other way out, We know how other devices works in DPDK,
if we are changing
the means then please mention in the cover letter for the proposed
design and why would
think, the new solution is better.

Regexdev specification(patch 1/4) is not different than other devices'
fundamental view.

In my understanding, we don't put any effort to understand, why other
subsystems were chosen the specific
implementation in the common code. For me, it worth spending my time
on the review once basic stuff is there.

int
rte_regexdev_configure(uint8_t dev_id, const struct rte_regexdev_config *cfg)
{
if (dev_id >= RTE_MAX_REGEXDEV_DEVS)
return -EINVAL;
if (regex_devices[dev_id] == NULL)
return -EINVAL;
if (cfg == NULL)
return -EINVAL;
if (regex_devices[dev_id]->dev_ops->dev_configure == NULL)
return -ENOTSUP;
return regex_devices[dev_id]->dev_ops->dev_configure
(regex_devices[dev_id], cfg);
}

>
>

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core functions
  2020-04-06 19:11                 ` Ori Kam
  2020-04-07  5:49                   ` Jerin Jacob
@ 2020-04-07 14:21                   ` Guy Kaneti
  2020-04-07 16:28                     ` Ori Kam
  1 sibling, 1 reply; 96+ messages in thread
From: Guy Kaneti @ 2020-04-07 14:21 UTC (permalink / raw)
  To: Ori Kam, Jerin Jacob, Thomas Monjalon
  Cc: Jerin Jacob Kollanukkaran, xiang.w.wang,
	Pavan Nikhilesh Bhagavatula, dev, Shahaf Shuler, hemant.agrawal,
	Opher Reviv, Alex Rosenbaum, Dovrat Zifroni, Prasun Kapoor,
	nipun.gupta, bruce.richardson, yang.a.hong, harry.chang,
	gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai, yuyingxia,
	fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc, jim,
	hongjun.ni, j.bromhead, deri, fc, arthur.su, Parav Pandit

Hi Ori,

>+int
>+rte_regexdev_register(struct rte_regexdev *dev)
>+{
>+	uint16_t dev_id;
>+	int res;
>+
>+	if (dev->dev_ops == NULL) {
>+		RTE_REGEXDEV_LOG(ERR, "RegEx device invalid device ops\n");
>+		return -EINVAL;
>+	}
>+	if (regexdev_allocated(dev->dev_name) != NULL) {
>+		RTE_REGEXDEV_LOG
>+			(ERR, "RegEx device with name %s already allocated\n",
>+			 dev->dev_name);
>+		return -ENOMEM;
>+	}
>+	dev_id = regexdev_find_free_dev();
>+	if (dev_id == RTE_MAX_REGEXDEV_DEVS) {
>+		RTE_REGEXDEV_LOG
>+			(ERR, "Reached maximum number of regex devs\n");
>+		return -ENOMEM;
>+	}
>+	dev->dev_id = dev_id;

dev is of type struct rte_regexdev *, but I don't see in the definition of struct rte_regexdev a field dev_id

>+	regex_devices[dev_id] = dev;
>+	res = dev_id;
>+	return res;
>+}

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [PATCH v1 2/4] regexdev: add regex core h file
  2020-04-07  8:53     ` Guy Kaneti
@ 2020-04-07 16:16       ` Ori Kam
  2020-04-07 16:27         ` Jerin Jacob
  0 siblings, 1 reply; 96+ messages in thread
From: Ori Kam @ 2020-04-07 16:16 UTC (permalink / raw)
  To: Guy Kaneti, Jerin Jacob Kollanukkaran, xiang.w.wang
  Cc: dev, Pavan Nikhilesh Bhagavatula, Shahaf Shuler, hemant.agrawal,
	Opher Reviv, Alex Rosenbaum, Dovrat Zifroni, Prasun Kapoor,
	nipun.gupta, bruce.richardson, yang.a.hong, harry.chang,
	gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai, yuyingxia,
	fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc, jim,
	hongjun.ni, j.bromhead, deri, fc, arthur.su, Thomas Monjalon,
	Parav Pandit

Hi Guy,

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Guy Kaneti
> Sent: Tuesday, April 7, 2020 11:54 AM
> To: Ori Kam <orika@mellanox.com>; Jerin Jacob Kollanukkaran
> <jerinj@marvell.com>; xiang.w.wang@intel.com
> Cc: dev@dpdk.org; Pavan Nikhilesh Bhagavatula
> <pbhagavatula@marvell.com>; Shahaf Shuler <shahafs@mellanox.com>;
> hemant.agrawal@nxp.com; Opher Reviv <opher@mellanox.com>; Alex
> Rosenbaum <alexr@mellanox.com>; Dovrat Zifroni <dovrat@marvell.com>;
> Prasun Kapoor <pkapoor@marvell.com>; nipun.gupta@nxp.com;
> bruce.richardson@intel.com; yang.a.hong@intel.com; harry.chang@intel.com;
> gu.jian1@zte.com.cn; shanjiangh@chinatelecom.cn;
> zhangy.yun@chinatelecom.cn; lixingfu@huachentel.com; wushuai@inspur.com;
> yuyingxia@yxlink.com; fanchenggang@sunyainfo.com;
> davidfgao@tencent.com; liuzhong1@chinaunicom.cn;
> zhaoyong11@huawei.com; oc@yunify.com; jim@netgate.com;
> hongjun.ni@intel.com; j.bromhead@titan-ic.com; deri@ntop.org;
> fc@napatech.com; arthur.su@lionic.com; Thomas Monjalon
> <thomas@monjalon.net>; Parav Pandit <parav@mellanox.com>
> Subject: Re: [dpdk-dev] [PATCH v1 2/4] regexdev: add regex core h file
> 
> > +
> > +/**
> > + * @internal
> > + * The generic data structure associated with each RegEx device.
> > + *
> > + * Pointers to burst-oriented packet receive and transmit functions are
> > + * located at the beginning of the structure, along with the pointer to
> > + * where all the data elements for the particular device are stored in
> > +shared
> > + * memory. This split allows the function pointer and driver data to be
> > +per-
> > + * process, while the actual configuration data for the device is shared.
> > + */
> > +struct rte_regexdev {
> > +	regexdev_enqueue_t enqueue;
> > +	regexdev_dequeue_t dequeue;
> > +	const struct rte_regexdev_ops *dev_ops;
> > +	/**< Functions exported by PMD */
> > +	struct rte_device *device; /**< Backing device */ }
> > +__rte_cache_aligned;
> > +
> 
> What about a handle for the PMD private data such as
> 	struct rte_eventdev_data *data;
> 	/**< Pointer to device data */
> 
> 	struct rte_cryptodev_data *data;
> 	/**< Pointer to device data */

I was thinking about new approach. To use container of.
Meaning each PMD will create like normal its priv structure.
In this structure there will be a regex_dev member.
For example:
struct mlx5_regex_priv {
	struct rte_regex_dev regex_dev;
	//private fields
	...
	...
}
On registration the PMD will give the rte_regexdev the reference to the regex_dev.
The PMD will use container_of

This approach  hides the private data from the application,
saves malloc, a bit faster, and saves the use of references.

So a better approach 😊 also this approach is in use by the rte_device.



^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [PATCH v1 2/4] regexdev: add regex core h file
  2020-04-07 16:16       ` Ori Kam
@ 2020-04-07 16:27         ` Jerin Jacob
  2020-04-08  7:37           ` Ori Kam
  0 siblings, 1 reply; 96+ messages in thread
From: Jerin Jacob @ 2020-04-07 16:27 UTC (permalink / raw)
  To: Ori Kam
  Cc: Guy Kaneti, Jerin Jacob Kollanukkaran, xiang.w.wang, dev,
	Pavan Nikhilesh Bhagavatula, Shahaf Shuler, hemant.agrawal,
	Opher Reviv, Alex Rosenbaum, Dovrat Zifroni, Prasun Kapoor,
	nipun.gupta, bruce.richardson, yang.a.hong, harry.chang,
	gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai, yuyingxia,
	fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc, jim,
	hongjun.ni, j.bromhead, deri, fc, arthur.su, Thomas Monjalon,
	Parav Pandit

On Tue, Apr 7, 2020 at 9:46 PM Ori Kam <orika@mellanox.com> wrote:

> Hi Guy,
>
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Guy Kaneti
> > Sent: Tuesday, April 7, 2020 11:54 AM
> > To: Ori Kam <orika@mellanox.com>; Jerin Jacob Kollanukkaran
> > <jerinj@marvell.com>; xiang.w.wang@intel.com
> > Cc: dev@dpdk.org; Pavan Nikhilesh Bhagavatula
> > <pbhagavatula@marvell.com>; Shahaf Shuler <shahafs@mellanox.com>;
> > hemant.agrawal@nxp.com; Opher Reviv <opher@mellanox.com>; Alex
> > Rosenbaum <alexr@mellanox.com>; Dovrat Zifroni <dovrat@marvell.com>;
> > Prasun Kapoor <pkapoor@marvell.com>; nipun.gupta@nxp.com;
> > bruce.richardson@intel.com; yang.a.hong@intel.com; harry.chang@intel.com
> ;
> > gu.jian1@zte.com.cn; shanjiangh@chinatelecom.cn;
> > zhangy.yun@chinatelecom.cn; lixingfu@huachentel.com; wushuai@inspur.com;
> > yuyingxia@yxlink.com; fanchenggang@sunyainfo.com;
> > davidfgao@tencent.com; liuzhong1@chinaunicom.cn;
> > zhaoyong11@huawei.com; oc@yunify.com; jim@netgate.com;
> > hongjun.ni@intel.com; j.bromhead@titan-ic.com; deri@ntop.org;
> > fc@napatech.com; arthur.su@lionic.com; Thomas Monjalon
> > <thomas@monjalon.net>; Parav Pandit <parav@mellanox.com>
> > Subject: Re: [dpdk-dev] [PATCH v1 2/4] regexdev: add regex core h file
> >
> > > +
> > > +/**
> > > + * @internal
> > > + * The generic data structure associated with each RegEx device.
> > > + *
> > > + * Pointers to burst-oriented packet receive and transmit functions
> are
> > > + * located at the beginning of the structure, along with the pointer
> to
> > > + * where all the data elements for the particular device are stored in
> > > +shared
> > > + * memory. This split allows the function pointer and driver data to
> be
> > > +per-
> > > + * process, while the actual configuration data for the device is
> shared.
> > > + */
> > > +struct rte_regexdev {
> > > +   regexdev_enqueue_t enqueue;
> > > +   regexdev_dequeue_t dequeue;
> > > +   const struct rte_regexdev_ops *dev_ops;
> > > +   /**< Functions exported by PMD */
> > > +   struct rte_device *device; /**< Backing device */ }
> > > +__rte_cache_aligned;
> > > +
> >
> > What about a handle for the PMD private data such as
> >       struct rte_eventdev_data *data;
> >       /**< Pointer to device data */
> >
> >       struct rte_cryptodev_data *data;
> >       /**< Pointer to device data */
>
> I was thinking about new approach. To use container of.
> Meaning each PMD will create like normal its priv structure.
> In this structure there will be a regex_dev member.
> For example:
> struct mlx5_regex_priv {
>         struct rte_regex_dev regex_dev;
>

The  rte_regex_dev which has  enqueue() and  dequeue() function pointer
should not be NOT allocated from hugepage
as per process it will have different enqueue() and dequeue() function
pointer value. Making it hugepage, another process
overwrites it.



>         //private fields
>         ...
>         ...
> }
> On registration the PMD will give the rte_regexdev the reference to the
> regex_dev.
> The PMD will use container_of
>
> This approach  hides the private data from the application,
> saves malloc, a bit faster, and saves the use of references.
>
> So a better approach 😊 also this approach is in use by the rte_device.
>
>
>

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core functions
  2020-04-07 14:21                   ` Guy Kaneti
@ 2020-04-07 16:28                     ` Ori Kam
  2020-04-07 16:37                       ` Guy Kaneti
  0 siblings, 1 reply; 96+ messages in thread
From: Ori Kam @ 2020-04-07 16:28 UTC (permalink / raw)
  To: Guy Kaneti, Jerin Jacob, Thomas Monjalon
  Cc: Jerin Jacob Kollanukkaran, xiang.w.wang,
	Pavan Nikhilesh Bhagavatula, dev, Shahaf Shuler, hemant.agrawal,
	Opher Reviv, Alex Rosenbaum, Dovrat Zifroni, Prasun Kapoor,
	nipun.gupta, bruce.richardson, yang.a.hong, harry.chang,
	gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai, yuyingxia,
	fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc, jim,
	hongjun.ni, j.bromhead, deri, fc, arthur.su, Parav Pandit

Hi Guy,
Thanks for your review

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Guy Kaneti
> Sent: Tuesday, April 7, 2020 5:22 PM
> To: Ori Kam <orika@mellanox.com>; Jerin Jacob <jerinjacobk@gmail.com>;
> Thomas Monjalon <thomas@monjalon.net>
> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; xiang.w.wang@intel.com;
> Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; dev@dpdk.org;
> Shahaf Shuler <shahafs@mellanox.com>; hemant.agrawal@nxp.com; Opher
> Reviv <opher@mellanox.com>; Alex Rosenbaum <alexr@mellanox.com>;
> Dovrat Zifroni <dovrat@marvell.com>; Prasun Kapoor
> <pkapoor@marvell.com>; nipun.gupta@nxp.com; bruce.richardson@intel.com;
> yang.a.hong@intel.com; harry.chang@intel.com; gu.jian1@zte.com.cn;
> shanjiangh@chinatelecom.cn; zhangy.yun@chinatelecom.cn;
> lixingfu@huachentel.com; wushuai@inspur.com; yuyingxia@yxlink.com;
> fanchenggang@sunyainfo.com; davidfgao@tencent.com;
> liuzhong1@chinaunicom.cn; zhaoyong11@huawei.com; oc@yunify.com;
> jim@netgate.com; hongjun.ni@intel.com; j.bromhead@titan-ic.com;
> deri@ntop.org; fc@napatech.com; arthur.su@lionic.com; Parav Pandit
> <parav@mellanox.com>
> Subject: Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core
> functions
> 
> Hi Ori,
> 
> >+int
> >+rte_regexdev_register(struct rte_regexdev *dev)
> >+{
> >+	uint16_t dev_id;
> >+	int res;
> >+
> >+	if (dev->dev_ops == NULL) {
> >+		RTE_REGEXDEV_LOG(ERR, "RegEx device invalid device
> ops\n");
> >+		return -EINVAL;
> >+	}
> >+	if (regexdev_allocated(dev->dev_name) != NULL) {
> >+		RTE_REGEXDEV_LOG
> >+			(ERR, "RegEx device with name %s already
> allocated\n",
> >+			 dev->dev_name);
> >+		return -ENOMEM;
> >+	}
> >+	dev_id = regexdev_find_free_dev();
> >+	if (dev_id == RTE_MAX_REGEXDEV_DEVS) {
> >+		RTE_REGEXDEV_LOG
> >+			(ERR, "Reached maximum number of regex devs\n");
> >+		return -ENOMEM;
> >+	}
> >+	dev->dev_id = dev_id;
> 
> dev is of type struct rte_regexdev *, but I don't see in the definition of struct
> rte_regexdev a field dev_id
> 

The definition of rte_regexdev appears in rte_regecdev_core.h
and the last member in this struct is the dev_id. (line146) it is added in this 
commit.

> >+	regex_devices[dev_id] = dev;
> >+	res = dev_id;
> >+	return res;
> >+}

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core functions
  2020-04-07 16:28                     ` Ori Kam
@ 2020-04-07 16:37                       ` Guy Kaneti
  2020-04-08  6:52                         ` Ori Kam
  0 siblings, 1 reply; 96+ messages in thread
From: Guy Kaneti @ 2020-04-07 16:37 UTC (permalink / raw)
  To: Ori Kam, Jerin Jacob, Thomas Monjalon
  Cc: Jerin Jacob Kollanukkaran, xiang.w.wang,
	Pavan Nikhilesh Bhagavatula, dev, Shahaf Shuler, hemant.agrawal,
	Opher Reviv, Alex Rosenbaum, Dovrat Zifroni, Prasun Kapoor,
	nipun.gupta, bruce.richardson, yang.a.hong, harry.chang,
	gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai, yuyingxia,
	fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc, jim,
	hongjun.ni, j.bromhead, deri, fc, arthur.su, Parav Pandit



> -----Original Message-----
> From: Ori Kam <orika@mellanox.com>
> Sent: Tuesday, April 07, 2020 7:29 PM
> To: Guy Kaneti <guyk@marvell.com>; Jerin Jacob <jerinjacobk@gmail.com>;
> Thomas Monjalon <thomas@monjalon.net>
> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>;
> xiang.w.wang@intel.com; Pavan Nikhilesh Bhagavatula
> <pbhagavatula@marvell.com>; dev@dpdk.org; Shahaf Shuler
> <shahafs@mellanox.com>; hemant.agrawal@nxp.com; Opher Reviv
> <opher@mellanox.com>; Alex Rosenbaum <alexr@mellanox.com>; Dovrat
> Zifroni <dovrat@marvell.com>; Prasun Kapoor <pkapoor@marvell.com>;
> nipun.gupta@nxp.com; bruce.richardson@intel.com;
> yang.a.hong@intel.com; harry.chang@intel.com; gu.jian1@zte.com.cn;
> shanjiangh@chinatelecom.cn; zhangy.yun@chinatelecom.cn;
> lixingfu@huachentel.com; wushuai@inspur.com; yuyingxia@yxlink.com;
> fanchenggang@sunyainfo.com; davidfgao@tencent.com;
> liuzhong1@chinaunicom.cn; zhaoyong11@huawei.com; oc@yunify.com;
> jim@netgate.com; hongjun.ni@intel.com; j.bromhead@titan-ic.com;
> deri@ntop.org; fc@napatech.com; arthur.su@lionic.com; Parav Pandit
> <parav@mellanox.com>
> Subject: RE: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core
> functions
> 
> Hi Guy,
> Thanks for your review
> 
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Guy Kaneti
> > Sent: Tuesday, April 7, 2020 5:22 PM
> > To: Ori Kam <orika@mellanox.com>; Jerin Jacob <jerinjacobk@gmail.com>;
> > Thomas Monjalon <thomas@monjalon.net>
> > Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>;
> > xiang.w.wang@intel.com; Pavan Nikhilesh Bhagavatula
> > <pbhagavatula@marvell.com>; dev@dpdk.org; Shahaf Shuler
> > <shahafs@mellanox.com>; hemant.agrawal@nxp.com; Opher Reviv
> > <opher@mellanox.com>; Alex Rosenbaum <alexr@mellanox.com>; Dovrat
> > Zifroni <dovrat@marvell.com>; Prasun Kapoor <pkapoor@marvell.com>;
> > nipun.gupta@nxp.com; bruce.richardson@intel.com;
> > yang.a.hong@intel.com; harry.chang@intel.com; gu.jian1@zte.com.cn;
> > shanjiangh@chinatelecom.cn; zhangy.yun@chinatelecom.cn;
> > lixingfu@huachentel.com; wushuai@inspur.com; yuyingxia@yxlink.com;
> > fanchenggang@sunyainfo.com; davidfgao@tencent.com;
> > liuzhong1@chinaunicom.cn; zhaoyong11@huawei.com; oc@yunify.com;
> > jim@netgate.com; hongjun.ni@intel.com; j.bromhead@titan-ic.com;
> > deri@ntop.org; fc@napatech.com; arthur.su@lionic.com; Parav Pandit
> > <parav@mellanox.com>
> > Subject: Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev
> > core functions
> >
> > Hi Ori,
> >
> > >+int
> > >+rte_regexdev_register(struct rte_regexdev *dev) {
> > >+	uint16_t dev_id;
> > >+	int res;
> > >+
> > >+	if (dev->dev_ops == NULL) {
> > >+		RTE_REGEXDEV_LOG(ERR, "RegEx device invalid device
> > ops\n");
> > >+		return -EINVAL;
> > >+	}
> > >+	if (regexdev_allocated(dev->dev_name) != NULL) {
> > >+		RTE_REGEXDEV_LOG
> > >+			(ERR, "RegEx device with name %s already
> > allocated\n",
> > >+			 dev->dev_name);
> > >+		return -ENOMEM;
> > >+	}
> > >+	dev_id = regexdev_find_free_dev();
> > >+	if (dev_id == RTE_MAX_REGEXDEV_DEVS) {
> > >+		RTE_REGEXDEV_LOG
> > >+			(ERR, "Reached maximum number of regex devs\n");
> > >+		return -ENOMEM;
> > >+	}
> > >+	dev->dev_id = dev_id;
> >
> > dev is of type struct rte_regexdev *, but I don't see in the
> > definition of struct rte_regexdev a field dev_id
> >
> 
> The definition of rte_regexdev appears in rte_regecdev_core.h and the last
> member in this struct is the dev_id. (line146) it is added in this commit.
> 

I was looking for it in [v1,2/4] regexdev: add regex core h file
https://patches.dpdk.org/patch/67309/

> > >+	regex_devices[dev_id] = dev;
> > >+	res = dev_id;
> > >+	return res;
> > >+}

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core functions
  2020-04-07 16:37                       ` Guy Kaneti
@ 2020-04-08  6:52                         ` Ori Kam
  0 siblings, 0 replies; 96+ messages in thread
From: Ori Kam @ 2020-04-08  6:52 UTC (permalink / raw)
  To: Guy Kaneti, Jerin Jacob, Thomas Monjalon
  Cc: Jerin Jacob Kollanukkaran, xiang.w.wang,
	Pavan Nikhilesh Bhagavatula, dev, Shahaf Shuler, hemant.agrawal,
	Opher Reviv, Alex Rosenbaum, Dovrat Zifroni, Prasun Kapoor,
	nipun.gupta, bruce.richardson, yang.a.hong, harry.chang,
	gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai, yuyingxia,
	fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc, jim,
	hongjun.ni, j.bromhead, deri, fc, arthur.su, Parav Pandit

Hi Guy,

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Guy Kaneti
> Sent: Tuesday, April 7, 2020 7:37 PM
> To: Ori Kam <orika@mellanox.com>; Jerin Jacob <jerinjacobk@gmail.com>;
> Thomas Monjalon <thomas@monjalon.net>
> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; xiang.w.wang@intel.com;
> Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; dev@dpdk.org;
> Shahaf Shuler <shahafs@mellanox.com>; hemant.agrawal@nxp.com; Opher
> Reviv <opher@mellanox.com>; Alex Rosenbaum <alexr@mellanox.com>;
> Dovrat Zifroni <dovrat@marvell.com>; Prasun Kapoor
> <pkapoor@marvell.com>; nipun.gupta@nxp.com; bruce.richardson@intel.com;
> yang.a.hong@intel.com; harry.chang@intel.com; gu.jian1@zte.com.cn;
> shanjiangh@chinatelecom.cn; zhangy.yun@chinatelecom.cn;
> lixingfu@huachentel.com; wushuai@inspur.com; yuyingxia@yxlink.com;
> fanchenggang@sunyainfo.com; davidfgao@tencent.com;
> liuzhong1@chinaunicom.cn; zhaoyong11@huawei.com; oc@yunify.com;
> jim@netgate.com; hongjun.ni@intel.com; j.bromhead@titan-ic.com;
> deri@ntop.org; fc@napatech.com; arthur.su@lionic.com; Parav Pandit
> <parav@mellanox.com>
> Subject: Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core
> functions
> 
> 
> 
> > -----Original Message-----
> > From: Ori Kam <orika@mellanox.com>
> > Sent: Tuesday, April 07, 2020 7:29 PM
> > To: Guy Kaneti <guyk@marvell.com>; Jerin Jacob <jerinjacobk@gmail.com>;
> > Thomas Monjalon <thomas@monjalon.net>
> > Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>;
> > xiang.w.wang@intel.com; Pavan Nikhilesh Bhagavatula
> > <pbhagavatula@marvell.com>; dev@dpdk.org; Shahaf Shuler
> > <shahafs@mellanox.com>; hemant.agrawal@nxp.com; Opher Reviv
> > <opher@mellanox.com>; Alex Rosenbaum <alexr@mellanox.com>; Dovrat
> > Zifroni <dovrat@marvell.com>; Prasun Kapoor <pkapoor@marvell.com>;
> > nipun.gupta@nxp.com; bruce.richardson@intel.com;
> > yang.a.hong@intel.com; harry.chang@intel.com; gu.jian1@zte.com.cn;
> > shanjiangh@chinatelecom.cn; zhangy.yun@chinatelecom.cn;
> > lixingfu@huachentel.com; wushuai@inspur.com; yuyingxia@yxlink.com;
> > fanchenggang@sunyainfo.com; davidfgao@tencent.com;
> > liuzhong1@chinaunicom.cn; zhaoyong11@huawei.com; oc@yunify.com;
> > jim@netgate.com; hongjun.ni@intel.com; j.bromhead@titan-ic.com;
> > deri@ntop.org; fc@napatech.com; arthur.su@lionic.com; Parav Pandit
> > <parav@mellanox.com>
> > Subject: RE: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core
> > functions
> >
> > Hi Guy,
> > Thanks for your review
> >
> > > -----Original Message-----
> > > From: dev <dev-bounces@dpdk.org> On Behalf Of Guy Kaneti
> > > Sent: Tuesday, April 7, 2020 5:22 PM
> > > To: Ori Kam <orika@mellanox.com>; Jerin Jacob <jerinjacobk@gmail.com>;
> > > Thomas Monjalon <thomas@monjalon.net>
> > > Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>;
> > > xiang.w.wang@intel.com; Pavan Nikhilesh Bhagavatula
> > > <pbhagavatula@marvell.com>; dev@dpdk.org; Shahaf Shuler
> > > <shahafs@mellanox.com>; hemant.agrawal@nxp.com; Opher Reviv
> > > <opher@mellanox.com>; Alex Rosenbaum <alexr@mellanox.com>; Dovrat
> > > Zifroni <dovrat@marvell.com>; Prasun Kapoor <pkapoor@marvell.com>;
> > > nipun.gupta@nxp.com; bruce.richardson@intel.com;
> > > yang.a.hong@intel.com; harry.chang@intel.com; gu.jian1@zte.com.cn;
> > > shanjiangh@chinatelecom.cn; zhangy.yun@chinatelecom.cn;
> > > lixingfu@huachentel.com; wushuai@inspur.com; yuyingxia@yxlink.com;
> > > fanchenggang@sunyainfo.com; davidfgao@tencent.com;
> > > liuzhong1@chinaunicom.cn; zhaoyong11@huawei.com; oc@yunify.com;
> > > jim@netgate.com; hongjun.ni@intel.com; j.bromhead@titan-ic.com;
> > > deri@ntop.org; fc@napatech.com; arthur.su@lionic.com; Parav Pandit
> > > <parav@mellanox.com>
> > > Subject: Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev
> > > core functions
> > >
> > > Hi Ori,
> > >
> > > >+int
> > > >+rte_regexdev_register(struct rte_regexdev *dev) {
> > > >+	uint16_t dev_id;
> > > >+	int res;
> > > >+
> > > >+	if (dev->dev_ops == NULL) {
> > > >+		RTE_REGEXDEV_LOG(ERR, "RegEx device invalid device
> > > ops\n");
> > > >+		return -EINVAL;
> > > >+	}
> > > >+	if (regexdev_allocated(dev->dev_name) != NULL) {
> > > >+		RTE_REGEXDEV_LOG
> > > >+			(ERR, "RegEx device with name %s already
> > > allocated\n",
> > > >+			 dev->dev_name);
> > > >+		return -ENOMEM;
> > > >+	}
> > > >+	dev_id = regexdev_find_free_dev();
> > > >+	if (dev_id == RTE_MAX_REGEXDEV_DEVS) {
> > > >+		RTE_REGEXDEV_LOG
> > > >+			(ERR, "Reached maximum number of regex devs\n");
> > > >+		return -ENOMEM;
> > > >+	}
> > > >+	dev->dev_id = dev_id;
> > >
> > > dev is of type struct rte_regexdev *, but I don't see in the
> > > definition of struct rte_regexdev a field dev_id
> > >
> >
> > The definition of rte_regexdev appears in rte_regecdev_core.h and the last
> > member in this struct is the dev_id. (line146) it is added in this commit.
> >
> 
> I was looking for it in [v1,2/4] regexdev: add regex core h file
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatches.d
> pdk.org%2Fpatch%2F67309%2F&amp;data=02%7C01%7Corika%40mellanox.co
> m%7C5a297f12b59e49eb078e08d7db11fc2c%7Ca652971c7d2e4d9ba6a4d1492
> 56f461b%7C0%7C0%7C637218742604895700&amp;sdata=6jJU9mMnmjf7fcMb
> rV00QMG8qcHt%2BfuPULHsUSbwTeY%3D&amp;reserved=0
> 

No problem, I added it  when I had use for it.

It would be great if you can add your ack.

> > > >+	regex_devices[dev_id] = dev;
> > > >+	res = dev_id;
> > > >+	return res;
> > > >+}

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [PATCH v1 2/4] regexdev: add regex core h file
  2020-04-07 16:27         ` Jerin Jacob
@ 2020-04-08  7:37           ` Ori Kam
  2020-04-08  7:48             ` Jerin Jacob
  0 siblings, 1 reply; 96+ messages in thread
From: Ori Kam @ 2020-04-08  7:37 UTC (permalink / raw)
  To: Jerin Jacob
  Cc: Guy Kaneti, Jerin Jacob Kollanukkaran, xiang.w.wang, dev,
	Pavan Nikhilesh Bhagavatula, Shahaf Shuler, hemant.agrawal,
	Opher Reviv, Alex Rosenbaum, Dovrat Zifroni, Prasun Kapoor,
	nipun.gupta, bruce.richardson, yang.a.hong, harry.chang,
	gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai, yuyingxia,
	fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc, jim,
	hongjun.ni, j.bromhead, deri, fc, arthur.su, Thomas Monjalon,
	Parav Pandit



> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Jerin Jacob
> Sent: Tuesday, April 7, 2020 7:27 PM
> Subject: Re: [dpdk-dev] [PATCH v1 2/4] regexdev: add regex core h file
> 
> On Tue, Apr 7, 2020 at 9:46 PM Ori Kam <orika@mellanox.com> wrote:
> 
> > Hi Guy,
> >
> > > -----Original Message-----
> > > From: dev <dev-bounces@dpdk.org> On Behalf Of Guy Kaneti
> > > Sent: Tuesday, April 7, 2020 11:54 AM
> > > > +
> > > > +/**
> > > > + * @internal
> > > > + * The generic data structure associated with each RegEx device.
> > > > + *
> > > > + * Pointers to burst-oriented packet receive and transmit functions
> > are
> > > > + * located at the beginning of the structure, along with the pointer
> > to
> > > > + * where all the data elements for the particular device are stored in
> > > > +shared
> > > > + * memory. This split allows the function pointer and driver data to
> > be
> > > > +per-
> > > > + * process, while the actual configuration data for the device is
> > shared.
> > > > + */
> > > > +struct rte_regexdev {
> > > > +   regexdev_enqueue_t enqueue;
> > > > +   regexdev_dequeue_t dequeue;
> > > > +   const struct rte_regexdev_ops *dev_ops;
> > > > +   /**< Functions exported by PMD */
> > > > +   struct rte_device *device; /**< Backing device */ }
> > > > +__rte_cache_aligned;
> > > > +
> > >
> > > What about a handle for the PMD private data such as
> > >       struct rte_eventdev_data *data;
> > >       /**< Pointer to device data */
> > >
> > >       struct rte_cryptodev_data *data;
> > >       /**< Pointer to device data */
> >
> > I was thinking about new approach. To use container of.
> > Meaning each PMD will create like normal its priv structure.
> > In this structure there will be a regex_dev member.
> > For example:
> > struct mlx5_regex_priv {
> >         struct rte_regex_dev regex_dev;
> >
> 
> The  rte_regex_dev which has  enqueue() and  dequeue() function pointer
> should not be NOT allocated from hugepage
> as per process it will have different enqueue() and dequeue() function
> pointer value. Making it hugepage, another process
> overwrites it.
> 
> 

I didn't say this structure should be allocated from huge page.
Unless I'm missing something, from memory this is exactly the same
as if we had pointer to the priv.

> 
> >         //private fields
> >         ...
> >         ...
> > }
> > On registration the PMD will give the rte_regexdev the reference to the
> > regex_dev.
> > The PMD will use container_of
> >
> > This approach  hides the private data from the application,
> > saves malloc, a bit faster, and saves the use of references.
> >
> > So a better approach 😊 also this approach is in use by the rte_device.
> >
> >
> >

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [PATCH v1 2/4] regexdev: add regex core h file
  2020-04-08  7:37           ` Ori Kam
@ 2020-04-08  7:48             ` Jerin Jacob
  2020-04-08  8:31               ` Ori Kam
  0 siblings, 1 reply; 96+ messages in thread
From: Jerin Jacob @ 2020-04-08  7:48 UTC (permalink / raw)
  To: Ori Kam
  Cc: Guy Kaneti, Jerin Jacob Kollanukkaran, xiang.w.wang, dev,
	Pavan Nikhilesh Bhagavatula, Shahaf Shuler, hemant.agrawal,
	Opher Reviv, Alex Rosenbaum, Dovrat Zifroni, Prasun Kapoor,
	nipun.gupta, bruce.richardson, yang.a.hong, harry.chang,
	gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai, yuyingxia,
	fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc, jim,
	hongjun.ni, j.bromhead, deri, fc, arthur.su, Thomas Monjalon,
	Parav Pandit

On Wed, Apr 8, 2020 at 1:07 PM Ori Kam <orika@mellanox.com> wrote:

>
>
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Jerin Jacob
> > Sent: Tuesday, April 7, 2020 7:27 PM
> > Subject: Re: [dpdk-dev] [PATCH v1 2/4] regexdev: add regex core h file
> >
> > On Tue, Apr 7, 2020 at 9:46 PM Ori Kam <orika@mellanox.com> wrote:
> >
> > > Hi Guy,
> > >
> > > > -----Original Message-----
> > > > From: dev <dev-bounces@dpdk.org> On Behalf Of Guy Kaneti
> > > > Sent: Tuesday, April 7, 2020 11:54 AM
> > > > > +
> > > > > +/**
> > > > > + * @internal
> > > > > + * The generic data structure associated with each RegEx device.
> > > > > + *
> > > > > + * Pointers to burst-oriented packet receive and transmit
> functions
> > > are
> > > > > + * located at the beginning of the structure, along with the
> pointer
> > > to
> > > > > + * where all the data elements for the particular device are
> stored in
> > > > > +shared
> > > > > + * memory. This split allows the function pointer and driver data
> to
> > > be
> > > > > +per-
> > > > > + * process, while the actual configuration data for the device is
> > > shared.
> > > > > + */
> > > > > +struct rte_regexdev {
> > > > > +   regexdev_enqueue_t enqueue;
> > > > > +   regexdev_dequeue_t dequeue;
> > > > > +   const struct rte_regexdev_ops *dev_ops;
> > > > > +   /**< Functions exported by PMD */
> > > > > +   struct rte_device *device; /**< Backing device */ }
> > > > > +__rte_cache_aligned;
> > > > > +
> > > >
> > > > What about a handle for the PMD private data such as
> > > >       struct rte_eventdev_data *data;
> > > >       /**< Pointer to device data */
> > > >
> > > >       struct rte_cryptodev_data *data;
> > > >       /**< Pointer to device data */
> > >
> > > I was thinking about new approach. To use container of.
> > > Meaning each PMD will create like normal its priv structure.
> > > In this structure there will be a regex_dev member.
> > > For example:
> > > struct mlx5_regex_priv {
> > >         struct rte_regex_dev regex_dev;
> > >
> >
> > The  rte_regex_dev which has  enqueue() and  dequeue() function pointer
> > should not be NOT allocated from hugepage
> > as per process it will have different enqueue() and dequeue() function
> > pointer value. Making it hugepage, another process
> > overwrites it.
> >
> >
>
> I didn't say this structure should be allocated from huge page.
> Unless I'm missing something, from memory this is exactly the same
> as if we had pointer to the priv.
>

Private data should be allocated from the hugepage so that multiple
processes can access it.
Whereas the memory that contains the  enqueue() and dequeue() should not
be  from hugepage.
So both can not be from the same memory. Right?




> >
> > >         //private fields
> > >         ...
> > >         ...
> > > }
> > > On registration the PMD will give the rte_regexdev the reference to the
> > > regex_dev.
> > > The PMD will use container_of
> > >
> > > This approach  hides the private data from the application,
> > > saves malloc, a bit faster, and saves the use of references.
> > >
> > > So a better approach 😊 also this approach is in use by the rte_device.
> > >
> > >
> > >
>

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [PATCH v1 2/4] regexdev: add regex core h file
  2020-04-08  7:48             ` Jerin Jacob
@ 2020-04-08  8:31               ` Ori Kam
  2020-04-08  8:38                 ` Jerin Jacob
  0 siblings, 1 reply; 96+ messages in thread
From: Ori Kam @ 2020-04-08  8:31 UTC (permalink / raw)
  To: Jerin Jacob
  Cc: Guy Kaneti, Jerin Jacob Kollanukkaran, xiang.w.wang, dev,
	Pavan Nikhilesh Bhagavatula, Shahaf Shuler, hemant.agrawal,
	Opher Reviv, Alex Rosenbaum, Dovrat Zifroni, Prasun Kapoor,
	nipun.gupta, bruce.richardson, yang.a.hong, harry.chang,
	gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai, yuyingxia,
	fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc, jim,
	hongjun.ni, j.bromhead, deri, fc, arthur.su, Thomas Monjalon,
	Parav Pandit

> 
> From: Jerin Jacob <jerinjacobk@gmail.com> 
> Sent: Wednesday, April 8, 2020 10:49 AM
> Subject: Re: [dpdk-dev] [PATCH v1 2/4] regexdev: add regex core h file
> 
> On Wed, Apr 8, 2020 at 1:07 PM Ori Kam <mailto:orika@mellanox.com> wrote:
> 
> 
> > -----Original Message-----
> > From: dev <mailto:dev-bounces@dpdk.org> On Behalf Of Jerin Jacob
> > Sent: Tuesday, April 7, 2020 7:27 PM
> > Subject: Re: [dpdk-dev] [PATCH v1 2/4] regexdev: add regex core h file
> > 
> > On Tue, Apr 7, 2020 at 9:46 PM Ori Kam <mailto:orika@mellanox.com> wrote:
> > 
> > > Hi Guy,
> > >
> > > > -----Original Message-----
> > > > From: dev <mailto:dev-bounces@dpdk.org> On Behalf Of Guy Kaneti
> > > > Sent: Tuesday, April 7, 2020 11:54 AM
> > > > > +
> > > > > +/**
> > > > > + * @internal
> > > > > + * The generic data structure associated with each RegEx device.
> > > > > + *
> > > > > + * Pointers to burst-oriented packet receive and transmit functions
> > > are
> > > > > + * located at the beginning of the structure, along with the pointer
> > > to
> > > > > + * where all the data elements for the particular device are stored in
> > > > > +shared
> > > > > + * memory. This split allows the function pointer and driver data to
> > > be
> > > > > +per-
> > > > > + * process, while the actual configuration data for the device is
> > > shared.
> > > > > + */
> > > > > +struct rte_regexdev {
> > > > > +   regexdev_enqueue_t enqueue;
> > > > > +   regexdev_dequeue_t dequeue;
> > > > > +   const struct rte_regexdev_ops *dev_ops;
> > > > > +   /**< Functions exported by PMD */
> > > > > +   struct rte_device *device; /**< Backing device */ }
> > > > > +__rte_cache_aligned;
> > > > > +
> > > >
> > > > What about a handle for the PMD private data such as
> > > >       struct rte_eventdev_data *data;
> > > >       /**< Pointer to device data */
> > > >
> > > >       struct rte_cryptodev_data *data;
> > > >       /**< Pointer to device data */
> > >
> > > I was thinking about new approach. To use container of.
> > > Meaning each PMD will create like normal its priv structure.
> > > In this structure there will be a regex_dev member.
> > > For example:
> > > struct mlx5_regex_priv {
> > >         struct rte_regex_dev regex_dev;
> > >
> > 
> > The  rte_regex_dev which has  enqueue() and  dequeue() function pointer
> > should not be NOT allocated from hugepage
> > as per process it will have different enqueue() and dequeue() function
> > pointer value. Making it hugepage, another process
> > overwrites it.
> > 
> > 
> 
> I didn't say this structure should be allocated from huge page.
> Unless I'm missing something, from memory this is exactly the same
> as if we had pointer to the priv.
> 
> Private data should be allocated from the hugepage so that multiple processes can access it.
> Whereas the memory that contains the  enqueue() and dequeue() should not be  from hugepage.
> So both can not be from the same memory. Right?
> 

Yes you are right, in current implementation the idea was to support only single process.
But I will update this code, to make it more like ethdev.

> 
> 
> 
> > 
> > >         //private fields
> > >         ...
> > >         ...
> > > }
> > > On registration the PMD will give the rte_regexdev the reference to the
> > > regex_dev.
> > > The PMD will use container_of
> > >
> > > This approach  hides the private data from the application,
> > > saves malloc, a bit faster, and saves the use of references.
> > >
> > > So a better approach 😊 also this approach is in use by the rte_device.
> > >
> > >
> > >
>

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [PATCH v1 2/4] regexdev: add regex core h file
  2020-04-08  8:31               ` Ori Kam
@ 2020-04-08  8:38                 ` Jerin Jacob
  2020-04-08  9:51                   ` Ori Kam
  0 siblings, 1 reply; 96+ messages in thread
From: Jerin Jacob @ 2020-04-08  8:38 UTC (permalink / raw)
  To: Ori Kam
  Cc: Guy Kaneti, Jerin Jacob Kollanukkaran, xiang.w.wang, dev,
	Pavan Nikhilesh Bhagavatula, Shahaf Shuler, hemant.agrawal,
	Opher Reviv, Alex Rosenbaum, Dovrat Zifroni, Prasun Kapoor,
	nipun.gupta, bruce.richardson, yang.a.hong, harry.chang,
	gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai, yuyingxia,
	fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc, jim,
	hongjun.ni, j.bromhead, deri, fc, arthur.su, Thomas Monjalon,
	Parav Pandit

>
> > > The  rte_regex_dev which has  enqueue() and  dequeue() function pointer
> > > should not be NOT allocated from hugepage
> > > as per process it will have different enqueue() and dequeue() function
> > > pointer value. Making it hugepage, another process
> > > overwrites it.
> > >
> > >
> >
> > I didn't say this structure should be allocated from huge page.
> > Unless I'm missing something, from memory this is exactly the same
> > as if we had pointer to the priv.
> >
> > Private data should be allocated from the hugepage so that multiple
> processes can access it.
> > Whereas the memory that contains the  enqueue() and dequeue() should not
> be  from hugepage.
> > So both can not be from the same memory. Right?
> >
>
> Yes you are right, in current implementation the idea was to support only
> single process.
> But I will update this code, to make it more like ethdev.
>

Thanks for understanding. We would like to avoid rework when we add
multi-process.
Please check the [re]configure the function  and it memory allocation
requirement for storing the queue pointers as well
from ethdev subsystem(in fact, all existing subsystem has same scheme).

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core functions
  2020-04-06 13:29             ` Thomas Monjalon
  2020-04-06 13:38               ` Jerin Jacob
@ 2020-04-08  8:39               ` Ori Kam
  2020-04-19 10:38                 ` Guy Kaneti
  1 sibling, 1 reply; 96+ messages in thread
From: Ori Kam @ 2020-04-08  8:39 UTC (permalink / raw)
  To: Thomas Monjalon, Jerin Jacob Kollanukkaran, xiang.w.wang,
	Pavan Nikhilesh Bhagavatula
  Cc: dev, Shahaf Shuler, hemant.agrawal, Opher Reviv, Alex Rosenbaum,
	Dovrat Zifroni, Prasun Kapoor, nipun.gupta, bruce.richardson,
	yang.a.hong, harry.chang, gu.jian1, shanjiangh, zhangy.yun,
	lixingfu, wushuai, yuyingxia, fanchenggang, davidfgao, liuzhong1,
	zhaoyong11, oc, jim, hongjun.ni, j.bromhead, deri, fc, arthur.su,
	Parav Pandit



> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Thomas Monjalon
> Sent: Monday, April 6, 2020 4:30 PM
> To: Ori Kam <orika@mellanox.com>; Jerin Jacob Kollanukkaran
> <jerinj@marvell.com>; xiang.w.wang@intel.com; Pavan Nikhilesh Bhagavatula
> <pbhagavatula@marvell.com>
> Cc: dev@dpdk.org; Shahaf Shuler <shahafs@mellanox.com>;
> hemant.agrawal@nxp.com; Opher Reviv <opher@mellanox.com>; Alex
> Rosenbaum <alexr@mellanox.com>; Dovrat Zifroni <dovrat@marvell.com>;
> Prasun Kapoor <pkapoor@marvell.com>; nipun.gupta@nxp.com;
> bruce.richardson@intel.com; yang.a.hong@intel.com; harry.chang@intel.com;
> gu.jian1@zte.com.cn; shanjiangh@chinatelecom.cn;
> zhangy.yun@chinatelecom.cn; lixingfu@huachentel.com; wushuai@inspur.com;
> yuyingxia@yxlink.com; fanchenggang@sunyainfo.com;
> davidfgao@tencent.com; liuzhong1@chinaunicom.cn;
> zhaoyong11@huawei.com; oc@yunify.com; jim@netgate.com;
> hongjun.ni@intel.com; j.bromhead@titan-ic.com; deri@ntop.org;
> fc@napatech.com; arthur.su@lionic.com; Parav Pandit <parav@mellanox.com>
> Subject: Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core
> functions
> 
> 06/04/2020 14:48, Pavan Nikhilesh Bhagavatula:
> > > From: Pavan Nikhilesh Bhagavatula
> > >> >> From: Pavan Nikhilesh Bhagavatula
> > >> >>
> > >> >> Looks like this implementation is incomplete?
> > >> >> I don't see any pmd specific helper functions for @see
> > >> >rte_cryptodev_pmd.c,
> > >> >> rte_eventdev_pmd*
> > >> >>
> > >> >I think the current implementation includes all needed functions,
> > >> >at least for the first stage.
> > >> >You can find in rte_regexdev_driver.h the functions that should be
> > >> >called
> > >> >by the PMD. We have the register / unregister which acts the same
> > >as
> > >> >create
> > >> >and destroy. For parsing argument the PMD may call
> > >rte_kvargs_parse.
> > >> >
> > >>
> > >> _driver.h should atleast include
> > >> rte_regex_dev_pci_generic_probe/rte_regex_pmd_vdev_init
> > >> else there would be a lot of code repetition and possibly udefined
> > >behavior
> > >> at the driver layer.
> > >>
> > >Why should they be included? At least in this stage, there is no code to
> > >share
> > >ethdev why should we add code for the vdev?
> >
> > Ok I think I failed to communicate my concerns across.
> > Let me retry
> >
> > 1. SW based regex devices such as PCRE/Hyperscan rely on vdev framework
> > i.e. user needs to pass an EAL argument --vdev="regex_pcre" for the driver to
> > initialize all the other EAL subsystems (ethdev, eventdev, cryptodev,
> etc..)support this.
> 
> vdev helpers do not have to be part of the first patches which define API.
> It should be added when adding the first vdev driver.
> 
> > 2. HW based independent regex devices that are exposed as PCI devices
> would need
> >  pci probe helpers.
> 
> Same, PCI helpers can be added while adding the first PCI driver.
> 
> We can synchronize about how to split the work, avoiding two developers
> doing the same thing. But let's not mandate this work to be done
> as part of this first series.
> 
> 
I agree with Thomas, let's discuss this when adding the PMDs.


^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core functions
  2020-04-06 12:48           ` Pavan Nikhilesh Bhagavatula
  2020-04-06 13:29             ` Thomas Monjalon
@ 2020-04-08  9:41             ` Ori Kam
  1 sibling, 0 replies; 96+ messages in thread
From: Ori Kam @ 2020-04-08  9:41 UTC (permalink / raw)
  To: Pavan Nikhilesh Bhagavatula, Jerin Jacob Kollanukkaran, xiang.w.wang
  Cc: dev, Shahaf Shuler, hemant.agrawal, Opher Reviv, Alex Rosenbaum,
	Dovrat Zifroni, Prasun Kapoor, nipun.gupta, bruce.richardson,
	yang.a.hong, harry.chang, gu.jian1, shanjiangh, zhangy.yun,
	lixingfu, wushuai, yuyingxia, fanchenggang, davidfgao, liuzhong1,
	zhaoyong11, oc, jim, hongjun.ni, j.bromhead, deri, fc, arthur.su,
	Thomas Monjalon, Parav Pandit

Hi Pavan

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Pavan Nikhilesh Bhagavatula
> Sent: Monday, April 6, 2020 3:48 PM
> 
> Hi Ori,
> 
> >Hi Pavan,
> >
> >> -----Original Message-----
> >> From: dev <dev-bounces@dpdk.org> On Behalf Of Pavan Nikhilesh
> >Bhagavatula
> >> Sent: Sunday, April 5, 2020 8:11 PM
> >> To: Ori Kam <orika@mellanox.com>; Jerin Jacob Kollanukkaran
> >> <jerinj@marvell.com>; xiang.w.wang@intel.com
> >> Cc: dev@dpdk.org; Shahaf Shuler <shahafs@mellanox.com>;
> >> hemant.agrawal@nxp.com; Opher Reviv <opher@mellanox.com>;
> >Alex
> >> Rosenbaum <alexr@mellanox.com>; Dovrat Zifroni
> ><dovrat@marvell.com>;
> >> Prasun Kapoor <pkapoor@marvell.com>; nipun.gupta@nxp.com;
> >> bruce.richardson@intel.com; yang.a.hong@intel.com;
> >harry.chang@intel.com;
> >> gu.jian1@zte.com.cn; shanjiangh@chinatelecom.cn;
> >> zhangy.yun@chinatelecom.cn; lixingfu@huachentel.com;
> >wushuai@inspur.com;
> >> yuyingxia@yxlink.com; fanchenggang@sunyainfo.com;
> >> davidfgao@tencent.com; liuzhong1@chinaunicom.cn;
> >> zhaoyong11@huawei.com; oc@yunify.com; jim@netgate.com;
> >> hongjun.ni@intel.com; j.bromhead@titan-ic.com; deri@ntop.org;
> >> fc@napatech.com; arthur.su@lionic.com; Thomas Monjalon
> >> <thomas@monjalon.net>; Parav Pandit <parav@mellanox.com>
> >> Subject: Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev
> >core
> >> functions
> >>
> >> Hi Ori,
> >>
> >> >> From: dev <dev-bounces@dpdk.org> On Behalf Of Pavan
> >Nikhilesh
> >> >Bhagavatula
> >> >>
> >> >> Looks like this implementation is incomplete?
> >> >> I don't see any pmd specific helper functions for @see
> >> >rte_cryptodev_pmd.c,
> >> >> rte_eventdev_pmd*
> >> >>
> >> >I think the current implementation includes all needed functions,
> >> >at least for the first stage.
> >> >You can find in rte_regexdev_driver.h the functions that should be
> >> >called
> >> >by the PMD. We have the register / unregister which acts the same
> >as
> >> >create
> >> >and destroy. For parsing argument the PMD may call
> >rte_kvargs_parse.
> >> >
> >>
> >> _driver.h should atleast include
> >> rte_regex_dev_pci_generic_probe/rte_regex_pmd_vdev_init
> >> else there would be a lot of code repetition and possibly udefined
> >behavior
> >> at the driver layer.
> >>
> >Why should they be included? At least in this stage, there is no code to
> >share
> >ethdev why should we add code for the vdev?
> 
> Ok I think I failed to communicate my concerns across.
> Let me retry
> 
> 1. SW based regex devices such as PCRE/Hyperscan rely on vdev framework
> i.e. user needs to pass an EAL argument --vdev="regex_pcre" for the driver to
> initialize all the other EAL subsystems (ethdev, eventdev, cryptodev,
> etc..)support this.
> 
> 2. HW based independent regex devices that are exposed as PCI devices would
> need
>  pci probe helpers.
> 
> 

Like mentions in other treads lets leave it as is for now,
And based on PMD implementation add the required functions.

> >I agree that if we see that there is shared code, we should think about
> >creating
> >those functions.
> >
> >> And also why take a different path than the rest of the rte
> >subsystems?
> >>
> >
> >Even now if you look at the reference code you will see that there is
> >really minimum shared code.
> >also this result in that the PMD is not free to allocate resource in the
> >order he needs.
> >My thinking is that if there are only 2 lines of shared code I prefer to let
> >the PMD handle it.
> >I know that sharing code should be the first option, but this also makes
> >the PMD developer unaware what is going on.
> >and lose some control. For example if the PMD programmer wants to
> >create hybrid PMD net +
> >regex for example, then either he will be forced to do some hacks or
> >just by pass the function
> >so when this function will be updated his code will break.
> 
> Shouldn't the application/end user make that decision rather than PMD
> programmer?.
> If application wants to connect net to regex it should be made possible to do it
> via rte_flow.
> 
In this case there will be I guess new rte_flow command, and there will be no
no use for the enqueue/deques or there will not be use for rx_burst / tx_burst
This is a story for another day.
In any case the PMD should be as flexiable as possible.  This is why I think that
the most code should be in the PMD since it is PMD implemetion and if we add
common code in rte level this can make the PMD less flexable. For example how
to share resource between net / regex device. For example even in current 
stage the application can receive packets from the net device and send those 
packets to the regex device, if the application uses both devices from the same 
company they can share information that can save time, for example memory 
registration values.
 
> As an example if we see event device spec. It has robust features to connect
> multiple
> subsystems(ethernet/crypto/timer) to event device and it is controlled from
> RTE layer.
> PMD layer should act on the inputs from RTE layer rather than action on it own.
> 
> Thoughts?
> Thanks,
> Pavan.
> 
Like I said above until we support inline regex, the application 
moves the packets just like it moves them between net devices,
so each PMD should have the ability to configure itself as best as it can.
Again I totally in favor that if we see common code we should
move it to rte level. But this should be done only after we have a code
and in any case this doesn't effect the API.
 
>  So I prefer if it
> >is very short code
> >and this code can be developed in different ways to leave it to the
> >PMD.
> >I suggest that if needed we will add such function. Is that O.K by you?
> >
> >> >
> >> >> >This commit introduce the API that is needed by the RegEx
> >devices in
> >> >> >order to work with the RegEX lib.
> >> >> >
> >> >> >During the probe of a RegEx device, the device should configure
> >> >itself,
> >> >> >and allocate the resources it requires.
> >> >> >On completion of the device init, it should call the
> >> >> >rte_regex_dev_register in order to register itself as a RegEx
> >device.
> >> >> >
> >> >> >Signed-off-by: Ori Kam <orika@mellanox.com>
> >> >> >Signed-off-by: Parav Pandit <parav@mellanox.com>
> >> >> >---
> >> >> > config/common_base                        |  3 +-
> >> >> > config/meson.build                        |  1 +
> >> >> > lib/librte_regexdev/Makefile              |  1 +
> >> >> > lib/librte_regexdev/meson.build           |  5 ++-
> >> >> > lib/librte_regexdev/rte_regexdev.c        | 74
> >> >> >++++++++++++++++++++++++++++++-
> >> >> > lib/librte_regexdev/rte_regexdev.h        |  7 +++
> >> >> > lib/librte_regexdev/rte_regexdev_core.h   |  2 +
> >> >> > lib/librte_regexdev/rte_regexdev_driver.h | 50
> >> >> >+++++++++++++++++++++
> >> >> > meson_options.txt                         |  2 +
> >> >> > 9 files changed, 142 insertions(+), 3 deletions(-)
> >> >> > create mode 100644 lib/librte_regexdev/rte_regexdev_driver.h
> >> >> >
> >> >>
> >> >> <snip>

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [PATCH v1 2/4] regexdev: add regex core h file
  2020-04-08  8:38                 ` Jerin Jacob
@ 2020-04-08  9:51                   ` Ori Kam
  0 siblings, 0 replies; 96+ messages in thread
From: Ori Kam @ 2020-04-08  9:51 UTC (permalink / raw)
  To: Jerin Jacob
  Cc: Guy Kaneti, Jerin Jacob Kollanukkaran, xiang.w.wang, dev,
	Pavan Nikhilesh Bhagavatula, Shahaf Shuler, hemant.agrawal,
	Opher Reviv, Alex Rosenbaum, Dovrat Zifroni, Prasun Kapoor,
	nipun.gupta, bruce.richardson, yang.a.hong, harry.chang,
	gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai, yuyingxia,
	fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc, jim,
	hongjun.ni, j.bromhead, deri, fc, arthur.su, Thomas Monjalon,
	Parav Pandit

> > 
> > From: Jerin Jacob <jerinjacobk@gmail.com> 
> > Sent: Wednesday, April 8, 2020 10:49 AM
> > 
> > 
> > 
> > On Wed, Apr 8, 2020 at 1:07 PM Ori Kam <mailto:orika@mellanox.com> wrote:
> > 
> > 
> > > -----Original Message-----
> > > From: dev <mailto:dev-bounces@dpdk.org> On Behalf Of Jerin Jacob
> > > Sent: Tuesday, April 7, 2020 7:27 PM
> > > Subject: Re: [dpdk-dev] [PATCH v1 2/4] regexdev: add regex core h file
> > > 
> > > On Tue, Apr 7, 2020 at 9:46 PM Ori Kam <mailto:orika@mellanox.com> wrote:
> > > 
> > > > Hi Guy,
> > > >
> > > > > -----Original Message-----
> > > > > From: dev <mailto:dev-bounces@dpdk.org> On Behalf Of Guy Kaneti
> > > > > Sent: Tuesday, April 7, 2020 11:54 AM
> > > > > > +
> > > > > > +/**
> > > > > > + * @internal
> > > > > > + * The generic data structure associated with each RegEx device.
> > > > > > + *
> > > > > > + * Pointers to burst-oriented packet receive and transmit functions
> > > > are
> > > > > > + * located at the beginning of the structure, along with the pointer
> > > > to
> > > > > > + * where all the data elements for the particular device are stored in
> > > > > > +shared
> > > > > > + * memory. This split allows the function pointer and driver data to
> > > > be
> > > > > > +per-
> > > > > > + * process, while the actual configuration data for the device is
> > > > shared.
> > > > > > + */
> > > > > > +struct rte_regexdev {
> > > > > > +   regexdev_enqueue_t enqueue;
> > > > > > +   regexdev_dequeue_t dequeue;
> > > > > > +   const struct rte_regexdev_ops *dev_ops;
> > > > > > +   /**< Functions exported by PMD */
> > > > > > +   struct rte_device *device; /**< Backing device */ }
> > > > > > +__rte_cache_aligned;
> > > > > > +
> > > > >
> > > > > What about a handle for the PMD private data such as
> > > > >       struct rte_eventdev_data *data;
> > > > >       /**< Pointer to device data */
> > > > >
> > > > >       struct rte_cryptodev_data *data;
> > > > >       /**< Pointer to device data */
> > > >
> > > > I was thinking about new approach. To use container of.
> > > > Meaning each PMD will create like normal its priv structure.
> > > > In this structure there will be a regex_dev member.
> > > > For example:
> > > > struct mlx5_regex_priv {
> > > >         struct rte_regex_dev regex_dev;
> > > >
> > > 
> > > The  rte_regex_dev which has  enqueue() and  dequeue() function pointer
> > > should not be NOT allocated from hugepage
> > > as per process it will have different enqueue() and dequeue() function
> > > pointer value. Making it hugepage, another process
> > > overwrites it.
> > > 
> > > 
> > 
> > I didn't say this structure should be allocated from huge page.
> > Unless I'm missing something, from memory this is exactly the same
> > as if we had pointer to the priv.
> > 
> > Private data should be allocated from the hugepage so that multiple processes can access it.
> > Whereas the memory that contains the  enqueue() and dequeue() should not be  from hugepage.
> > So both can not be from the same memory. Right?
> > 
> > 
> > 
> > 
> > > 
> > > >         //private fields
> > > >         ...
> > > >         ...
> > > > }
> > > > On registration the PMD will give the rte_regexdev the reference to the
> > > > regex_dev.
> > > > The PMD will use container_of
> > > >
> > > > This approach  hides the private data from the application,
> > > > saves malloc, a bit faster, and saves the use of references.
> > > >
> 
> 
> > > The  rte_regex_dev which has  enqueue() and  dequeue() function pointer
> > > should not be NOT allocated from hugepage
> > > as per process it will have different enqueue() and dequeue() function
> > > pointer value. Making it hugepage, another process
> > > overwrites it.
> > > 
> > > 
> > 
> > I didn't say this structure should be allocated from huge page.
> > Unless I'm missing something, from memory this is exactly the same
> > as if we had pointer to the priv.
> > 
> > Private data should be allocated from the hugepage so that multiple processes can access it.
> > Whereas the memory that contains the  enqueue() and dequeue() should not be  from hugepage.
> > So both can not be from the same memory. Right?
> > 
> 
> Yes you are right, in current implementation the idea was to support only single process.
> But I will update this code, to make it more like ethdev.
> 
> Thanks for understanding. We would like to avoid rework when we add multi-process.
> Please check the [re]configure the function  and it memory allocation requirement for storing the queue pointers as well
> from ethdev subsystem(in fact, all existing subsystem has same scheme).
> 

Will fix.

> > > > So a better approach 😊 also this approach is in use by the rte_device.
> > > >
> > > >
> > > >
> >

^ permalink raw reply	[flat|nested] 96+ messages in thread

* [dpdk-dev] [PATCH v2 0/4] add RegEx class
  2020-03-29  6:47 [dpdk-dev] [PATCH v1 0/4] add RegEx class Ori Kam
                   ` (4 preceding siblings ...)
  2020-04-04 13:06 ` [dpdk-dev] [EXT] [PATCH v1 0/4] add RegEx class Pavan Nikhilesh Bhagavatula
@ 2020-04-17 12:43 ` Ori Kam
  2020-04-17 12:43   ` [dpdk-dev] [PATCH v2 1/4] regexdev: introduce regexdev subsystem Ori Kam
                     ` (3 more replies)
  2020-05-07  9:45 ` [dpdk-dev] [PATCH v3 0/4] add RegEx class Ori Kam
                   ` (2 subsequent siblings)
  8 siblings, 4 replies; 96+ messages in thread
From: Ori Kam @ 2020-04-17 12:43 UTC (permalink / raw)
  To: jerinj, xiang.w.wang
  Cc: dev, pbhagavatula, shahafs, hemant.agrawal, opher, alexr, dovrat,
	pkapoor, nipun.gupta, bruce.richardson, yang.a.hong, harry.chang,
	gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai, yuyingxia,
	fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc, jim,
	hongjun.ni, j.bromhead, deri, fc, arthur.su, thomas, orika

This patch set adds the RegEx class, which enables RegEx pattern
matching, both on HW/SW PMDs.

Example for applications that will benefit from this class:
* Next Generation Firewalls (NGFW)
* Deep Packet and Flow Inspection (DPI)
* Intrusion Prevention Systems (IPS)
* DDoS Mitigation
* Network Monitoring
* Data Loss Prevention (DLP)
* Smart NICs
* Grammar based content processing
* URL, spam and adware filtering
* Advanced auditing and policing of user/application security policies
* Financial data mining - parsing of streamed financial feeds
* Application recognition.
* Dmemory introspection.
* Natural Language Processing (NLP)
* Sentiment Analysis.
* Big data databse acceleration.
* Computational storage. 

This patch set is based on RFC[1]

This class should be merged only after there is at least
one PMD that implements it. Also the test application will
be added when the first PMD is added.



[1] https://patches.dpdk.org/patch/66501/

V2:
* address ML comments.

Jerin Jacob (1):
  regexdev: introduce regexdev subsystem

Ori Kam (3):
  regexdev: add regex core h file
  regexdev: add regexdev core functions
  regexdev: implement regex rte level functions

 config/common_base                           |    8 +
 config/meson.build                           |    1 +
 doc/api/doxy-api-index.md                    |    1 +
 doc/api/doxy-api.conf.in                     |    1 +
 doc/guides/prog_guide/index.rst              |    1 +
 doc/guides/prog_guide/regexdev_lib.rst       |  177 +++
 lib/Makefile                                 |    2 +
 lib/librte_regexdev/Makefile                 |   33 +
 lib/librte_regexdev/meson.build              |   10 +
 lib/librte_regexdev/rte_regexdev.c           |  549 +++++++++
 lib/librte_regexdev/rte_regexdev.h           | 1534 ++++++++++++++++++++++++++
 lib/librte_regexdev/rte_regexdev_core.h      |  183 +++
 lib/librte_regexdev/rte_regexdev_driver.h    |   50 +
 lib/librte_regexdev/rte_regexdev_version.map |   26 +
 lib/meson.build                              |    3 +-
 meson_options.txt                            |    2 +
 16 files changed, 2580 insertions(+), 1 deletion(-)
 create mode 100644 doc/guides/prog_guide/regexdev_lib.rst
 create mode 100644 lib/librte_regexdev/Makefile
 create mode 100644 lib/librte_regexdev/meson.build
 create mode 100644 lib/librte_regexdev/rte_regexdev.c
 create mode 100644 lib/librte_regexdev/rte_regexdev.h
 create mode 100644 lib/librte_regexdev/rte_regexdev_core.h
 create mode 100644 lib/librte_regexdev/rte_regexdev_driver.h
 create mode 100644 lib/librte_regexdev/rte_regexdev_version.map

-- 
1.8.3.1


^ permalink raw reply	[flat|nested] 96+ messages in thread

* [dpdk-dev] [PATCH v2 1/4] regexdev: introduce regexdev subsystem
  2020-04-17 12:43 ` [dpdk-dev] [PATCH v2 " Ori Kam
@ 2020-04-17 12:43   ` Ori Kam
  2020-04-17 12:43   ` [dpdk-dev] [PATCH v2 2/4] regexdev: add regex core h file Ori Kam
                     ` (2 subsequent siblings)
  3 siblings, 0 replies; 96+ messages in thread
From: Ori Kam @ 2020-04-17 12:43 UTC (permalink / raw)
  To: jerinj, xiang.w.wang
  Cc: dev, pbhagavatula, shahafs, hemant.agrawal, opher, alexr, dovrat,
	pkapoor, nipun.gupta, bruce.richardson, yang.a.hong, harry.chang,
	gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai, yuyingxia,
	fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc, jim,
	hongjun.ni, j.bromhead, deri, fc, arthur.su, thomas, orika

From: Jerin Jacob <jerinj@marvell.com>

As RegEx usage become more used by DPDK applications, for example:
* Next Generation Firewalls (NGFW)
* Deep Packet and Flow Inspection (DPI)
* Intrusion Prevention Systems (IPS)
* DDoS Mitigation
* Network Monitoring
* Data Loss Prevention (DLP)
* Smart NICs
* Grammar based content processing
* URL, spam and adware filtering
* Advanced auditing and policing of user/application security policies
* Financial data mining - parsing of streamed financial feeds
* Application recognition.
* Dmemory introspection.
* Natural Language Processing (NLP)
* Sentiment Analysis.
* Big data databse acceleration.
* Computational storage.

Number of PMD providers started to work on HW implementation,
along side with SW implementations.

This lib adds the support for those kind of devices.

The RegEx Device API is composed of two parts:
- The application-oriented RegEx API that includes functions to setup
  a RegEx device (configure it, setup its queue pairs and start it),
  update the rule database and so on.

- The driver-oriented RegEx API that exports a function allowing
  a RegEx poll Mode Driver (PMD) to simultaneously register itself as
  a RegEx device driver.

RegEx device components and definitions:

    +-----------------+
    |                 |
    |                 o---------+    rte_regexdev_[en|de]queue_burst()
    |   PCRE based    o------+  |               |
    |  RegEx pattern  |      |  |  +--------+   |
    | matching engine o------+--+--o        |   |    +------+
    |                 |      |  |  | queue  |<==o===>|Core 0|
    |                 o----+ |  |  | pair 0 |        |      |
    |                 |    | |  |  +--------+        +------+
    +-----------------+    | |  |
           ^               | |  |  +--------+
           |               | |  |  |        |        +------+
           |               | +--+--o queue  |<======>|Core 1|
       Rule|Database       |    |  | pair 1 |        |      |
    +------+----------+    |    |  +--------+        +------+
    |     Group 0     |    |    |
    | +-------------+ |    |    |  +--------+        +------+
    | | Rules 0..n  | |    |    |  |        |        |Core 2|
    | +-------------+ |    |    +--o queue  |<======>|      |
    |     Group 1     |    |       | pair 2 |        +------+
    | +-------------+ |    |       +--------+
    | | Rules 0..n  | |    |
    | +-------------+ |    |       +--------+
    |     Group 2     |    |       |        |        +------+
    | +-------------+ |    |       | queue  |<======>|Core n|
    | | Rules 0..n  | |    +-------o pair n |        |      |
    | +-------------+ |            +--------+        +------+
    |     Group n     |
    | +-------------+ |<-------rte_regexdev_rule_db_update()
    | |             | |<-------rte_regexdev_rule_db_compile_activate()
    | | Rules 0..n  | |<-------rte_regexdev_rule_db_import()
    | +-------------+ |------->rte_regexdev_rule_db_export()
    +-----------------+

RegEx: A regular expression is a concise and flexible means for matching
strings of text, such as particular characters, words, or patterns of
characters. A common abbreviation for this is â~@~\RegExâ~@~].

RegEx device: A hardware or software-based implementation of RegEx
device API for PCRE based pattern matching syntax and semantics.

PCRE RegEx syntax and semantics specification:
http://regexkit.sourceforge.net/Documentation/pcre/pcrepattern.html

RegEx queue pair: Each RegEx device should have one or more queue pair to
transmit a burst of pattern matching request and receive a burst of
receive the pattern matching response. The pattern matching
request/response embedded in *rte_regex_ops* structure.

Rule: A pattern matching rule expressed in PCRE RegEx syntax along with
Match ID and Group ID to identify the rule upon the match.

Rule database: The RegEx device accepts regular expressions and converts
them into a compiled rule database that can then be used to scan data.
Compilation allows the device to analyze the given pattern(s) and
pre-determine how to scan for these patterns in an optimized fashion that
would be far too expensive to compute at run-time. A rule database
contains a set of rules that compiled in device specific binary form.

Match ID or Rule ID: A unique identifier provided at the time of rule
creation for the application to identify the rule upon match.

Group ID: Group of rules can be grouped under one group ID to enable
rule isolation and effective pattern matching. A unique group identifier
provided at the time of rule creation for the application to identify
the rule upon match.

Scan: A pattern matching request through *enqueue* API.

It may possible that a given RegEx device may not support all the
features
of PCRE. The application may probe unsupported features through
struct rte_regexdev_info::pcre_unsup_flags

By default, all the functions of the RegEx Device API exported by a PMD
are lock-free functions which assume to not be invoked in parallel on
different logical cores to work on the same target object. For instance,
the dequeue function of a PMD cannot be invoked in parallel on two logical
cores to operates on same RegEx queue pair. Of course, this function
can be invoked in parallel by different logical core on different queue
pair. It is the responsibility of the upper level application to
enforce this rule.

In all functions of the RegEx API, the RegEx device is
designated by an integer >= 0 named the device identifier *dev_id*

At the RegEx driver level, RegEx devices are represented by a generic
data structure of type *rte_regexdev*.
RegEx devices are dynamically registered during the PCI/SoC device
probing phase performed at EAL initialization time.
When a RegEx device is being probed, a *rte_regexdev* structure and
a new device identifier are allocated for that device. Then, the
regexdev_init() function supplied by the RegEx driver matching the
probed device is invoked to properly initialize the device.

The role of the device init function consists of resetting the hardware
or software RegEx driver implementations.

If the device init operation is successful, the correspondence between
the device identifier assigned to the new device and its associated
*rte_regexdev* structure is effectively registered.
Otherwise, both the *rte_regexdev* structure and the device identifier
are freed.

The functions exported by the application RegEx API to setup a device
designated by its device identifier must be invoked in the following
order:
    - rte_regexdev_configure()
    - rte_regexdev_queue_pair_setup()
    - rte_regexdev_start()

Then, the application can invoke, in any order, the functions
exported by the RegEx API to enqueue pattern matching job, dequeue
pattern matching response, get the stats, update the rule database,
get/set device attributes and so on

If the application wants to change the configuration (i.e. call
rte_regexdev_configure() or rte_regexdev_queue_pair_setup()), it must
call rte_regexdev_stop() first to stop the device and then do the
reconfiguration before calling rte_regexdev_start() again. The enqueue and
dequeue functions should not be invoked when the device is stopped.

Finally, an application can close a RegEx device by invoking the
rte_regexdev_close() function.

Each function of the application RegEx API invokes a specific function
of the PMD that controls the target device designated by its device
identifier.

For this purpose, all device-specific functions of a RegEx driver are
supplied through a set of pointers contained in a generic structure of
type *regexdev_ops*.
The address of the *regexdev_ops* structure is stored in the
*rte_regexdev* structure by the device init function of the RegEx driver,
which is invoked during the PCI/SoC device probing phase, as explained
earlier.

In other words, each function of the RegEx API simply retrieves the
*rte_regexdev* structure associated with the device identifier and
performs an indirect invocation of the corresponding driver function
supplied in the *regexdev_ops* structure of the *rte_regexdev*
structure.

For performance reasons, the address of the fast-path functions of the
RegEx driver is not contained in the *regexdev_ops* structure.
Instead, they are directly stored at the beginning of the *rte_regexdev*
structure to avoid an extra indirect memory access during their
invocation.

RTE RegEx device drivers do not use interrupts for enqueue or dequeue
operation. Instead, RegEx drivers export Poll-Mode enqueue and dequeue
functions to applications.

The *enqueue* operation submits a burst of RegEx pattern matching
request to the RegEx device and the *dequeue* operation gets a burst of
pattern matching response for the ones submitted through *enqueue*
operation.

Typical application utilisation of the RegEx device API will follow the
following programming flow.

- rte_regexdev_configure()
- rte_regexdev_queue_pair_setup()
- rte_regexdev_rule_db_update() Needs to invoke if precompiled rule
  database not
  provided in rte_regexdev_config::rule_db for rte_regexdev_configure()
  and/or application needs to update rule database.
- rte_regexdev_rule_db_compile_activate() Needs to invoke if
  rte_regexdev_rule_db_update function was used.
- Create or reuse exiting mempool for *rte_regex_ops* objects.
- rte_regexdev_start()
- rte_regexdev_enqueue_burst()
- rte_regexdev_dequeue_burst()

Signed-off-by: Jerin Jacob <jerinj@marvell.com>
Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
Signed-off-by: Ori Kam <orika@mellanox.com>
---
v2:
* Move unused define to other patch. 
---
 config/common_base                           |    6 +
 doc/api/doxy-api-index.md                    |    1 +
 doc/api/doxy-api.conf.in                     |    1 +
 doc/guides/prog_guide/index.rst              |    1 +
 doc/guides/prog_guide/regexdev_lib.rst       |  177 ++++
 lib/Makefile                                 |    2 +
 lib/librte_regexdev/Makefile                 |   31 +
 lib/librte_regexdev/meson.build              |    7 +
 lib/librte_regexdev/rte_regexdev.c           |    6 +
 lib/librte_regexdev/rte_regexdev.h           | 1473 ++++++++++++++++++++++++++
 lib/librte_regexdev/rte_regexdev_version.map |   26 +
 lib/meson.build                              |    3 +-
 12 files changed, 1733 insertions(+), 1 deletion(-)
 create mode 100644 doc/guides/prog_guide/regexdev_lib.rst
 create mode 100644 lib/librte_regexdev/Makefile
 create mode 100644 lib/librte_regexdev/meson.build
 create mode 100644 lib/librte_regexdev/rte_regexdev.c
 create mode 100644 lib/librte_regexdev/rte_regexdev.h
 create mode 100644 lib/librte_regexdev/rte_regexdev_version.map

diff --git a/config/common_base b/config/common_base
index 00d8d07..0fc450f 100644
--- a/config/common_base
+++ b/config/common_base
@@ -826,6 +826,11 @@ CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_EP_RAWDEV=y
 CONFIG_RTE_LIBRTE_PMD_NTB_RAWDEV=y
 
 #
+# Compile regex device support
+#
+CONFIG_RTE_LIBRTE_REGEXDEV=y
+
+#
 # Compile librte_ring
 #
 CONFIG_RTE_LIBRTE_RING=y
@@ -1118,3 +1123,4 @@ CONFIG_RTE_APP_CRYPTO_PERF=y
 # Compile the eventdev application
 #
 CONFIG_RTE_APP_EVENTDEV=y
+
diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
index dff496b..787f7c2 100644
--- a/doc/api/doxy-api-index.md
+++ b/doc/api/doxy-api-index.md
@@ -26,6 +26,7 @@ The public API headers are grouped by topics:
   [event_timer_adapter]    (@ref rte_event_timer_adapter.h),
   [event_crypto_adapter]   (@ref rte_event_crypto_adapter.h),
   [rawdev]             (@ref rte_rawdev.h),
+  [regexdev]           (@ref rte_regexdev.h),
   [metrics]            (@ref rte_metrics.h),
   [bitrate]            (@ref rte_bitrate.h),
   [latency]            (@ref rte_latencystats.h),
diff --git a/doc/api/doxy-api.conf.in b/doc/api/doxy-api.conf.in
index 65e8146..84621ba 100644
--- a/doc/api/doxy-api.conf.in
+++ b/doc/api/doxy-api.conf.in
@@ -58,6 +58,7 @@ INPUT                   = @TOPDIR@/doc/api/doxy-api-index.md \
                           @TOPDIR@/lib/librte_rcu \
                           @TOPDIR@/lib/librte_reorder \
                           @TOPDIR@/lib/librte_rib \
+                          @TOPDIR@/lib/librte_regexdev \
                           @TOPDIR@/lib/librte_ring \
                           @TOPDIR@/lib/librte_sched \
                           @TOPDIR@/lib/librte_security \
diff --git a/doc/guides/prog_guide/index.rst b/doc/guides/prog_guide/index.rst
index fb250ab..11f3b60 100644
--- a/doc/guides/prog_guide/index.rst
+++ b/doc/guides/prog_guide/index.rst
@@ -70,3 +70,4 @@ Programmer's Guide
     lto
     profile_app
     glossary
+    regexdev_lib
diff --git a/doc/guides/prog_guide/regexdev_lib.rst b/doc/guides/prog_guide/regexdev_lib.rst
new file mode 100644
index 0000000..1ecbf1c
--- /dev/null
+++ b/doc/guides/prog_guide/regexdev_lib.rst
@@ -0,0 +1,177 @@
+..  SPDX-License-Identifier: BSD-3-Clause
+    Copyright(c) 2020 Mellanox Corporation.
+
+RegEx Device Library
+=====================
+
+The RegEx library provides a RegEx device framework for management and
+provisioning of hardware and software RegEx poll mode drivers, defining generic
+APIs which support a number of different RegEx operations.
+
+
+Design Principles
+-----------------
+
+The RegEx library follows the same basic principles as those used in DPDK's
+Ethernet Device framework and the Crypto framework. The RegEx framework provides
+a generic Crypto device framework which supports both physical (hardware)
+and virtual (software) RegEx devices as well as a generic RegEx API which allows
+RegEx devices to be managed and configured and supports RegEx operations to be
+provisioned on RegEx poll mode driver.
+
+
+Device Management
+-----------------
+
+Device Creation
+~~~~~~~~~~~~~~~
+
+Physical RegEx devices are discovered during the PCI probe/enumeration of the
+EAL function which is executed at DPDK initialization, based on
+their PCI device identifier, each unique PCI BDF (bus/bridge, device,
+function). Specific physical ReEx devices, like other physical devices in DPDK
+can be white-listed or black-listed using the EAL command line options.
+
+
+Device Identification
+~~~~~~~~~~~~~~~~~~~~~
+
+Each device, whether virtual or physical is uniquely designated by two
+identifiers:
+
+- A unique device index used to designate the RegEx device in all functions
+  exported by the regexdev API.
+
+- A device name used to designate the RegEx device in console messages, for
+  administration or debugging purposes.
+
+
+Device Configuration
+~~~~~~~~~~~~~~~~~~~~
+
+The configuration of each RegEx device includes the following operations:
+
+- Allocation of resources, including hardware resources if a physical device.
+- Resetting the device into a well-known default state.
+- Initialization of statistics counters.
+
+The rte_regexdev_configure API is used to configure a RegEx device.
+
+.. code-block:: c
+
+   int rte_regexdev_configure(uint8_t dev_id,
+                              const struct rte_regexdev_config *cfg);
+
+The ``rte_regexdev_config`` structure is used to pass the configuration
+parameters for the RegEx device for example  number of queue pairs, number of
+groups, max number of matches and so on.
+
+.. code-block:: c
+
+   struct rte_regexdev_config {
+        uint16_t nb_max_matches;
+        /**< Maximum matches per scan configured on this device.
+         * This value cannot exceed the *max_matches*
+         * which previously provided in rte_regexdev_info_get().
+         * The value 0 is allowed, in which case, value 1 used.
+         * @see struct rte_regexdev_info::max_matches
+         */
+        uint16_t nb_queue_pairs;
+        /**< Number of RegEx queue pairs to configure on this device.
+         * This value cannot exceed the *max_queue_pairs* which previously
+         * provided in rte_regexdev_info_get().
+         * @see struct rte_regexdev_info::max_queue_pairs
+         */
+        uint32_t nb_rules_per_group;
+        /**< Number of rules per group to configure on this device.
+         * This value cannot exceed the *max_rules_per_group*
+         * which previously provided in rte_regexdev_info_get().
+         * The value 0 is allowed, in which case,
+         * struct rte_regexdev_info::max_rules_per_group used.
+         * @see struct rte_regexdev_info::max_rules_per_group
+         */
+        uint16_t nb_groups;
+        /**< Number of groups to configure on this device.
+         * This value cannot exceed the *max_groups*
+         * which previously provided in rte_regexdev_info_get().
+         * @see struct rte_regexdev_info::max_groups
+         */
+        const char *rule_db;
+        /**< Import initial set of prebuilt rule database on this device.
+         * The value NULL is allowed, in which case, the device will not
+         * be configured prebuilt rule database. Application may use
+         * rte_regexdev_rule_db_update() or rte_regexdev_rule_db_import() API
+         * to update or import rule database after the
+         * rte_regexdev_configure().
+         * @see rte_regexdev_rule_db_update(), rte_regexdev_rule_db_import()
+         */
+        uint32_t rule_db_len;
+        /**< Length of *rule_db* buffer. */
+        uint32_t dev_cfg_flags;
+        /**< RegEx device configuration flags, See RTE_REGEXDEV_CFG_*  */
+    };
+
+
+Configuration of Rules Database
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Each Regex device should be configured with the rule database.
+There are two modes of setting the rule database, online or offline.
+The online mode means, that the rule database in being compiled by the
+RegEx PMD while in the offline mode the rule database is compiled by external
+compiler, and is being loaded to the PMD as a buffer.
+The configuration mode is depended on the PMD capabilities.
+
+Online rule configuration is done using the following API functions:
+``rte_regexdev_rule_db_update`` which add / remove rules from the rules
+precomplied list, and ``rte_regexdev_rule_db_compile_activate``
+which compile the rules and loads them to the RegEx HW.
+
+Offline rule configuration can be done by adding a pointer to the compiled
+rule database in the configuration step, or by using
+``rte_regexdev_rule_db_import`` API.
+
+
+Configuration of Queue Pairs
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Each RegEx device can be configured with number of queue pairs.
+Each queue pair is configured using ``rte_regexdev_queue_pair_setup``
+
+
+Logical Cores, Memory and Queues Pair Relationships
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Multiple logical cores should never share the same queue pair for enqueuing
+operations or dequeuing operations on the same RegEx device since this would
+require global locks and hinder performance.
+
+
+Device Features and Capabilities
+---------------------------------
+
+RegEx devices may support different feature set.
+In order to get the supported PMD feature ``rte_regexdev_info_get``
+API which return the info of the device and it's supported features.
+
+
+Enqueue / Dequeue Burst APIs
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The burst enqueue API uses a RegEx device identifier and a queue pair
+identifier to specify the device queue pair to schedule the processing on.
+The ``nb_ops`` parameter is the number of operations to process which are
+supplied in the ``ops`` array of ``rte_regex_ops`` structures.
+The enqueue function returns the number of operations it actually enqueued for
+processing, a return value equal to ``nb_ops`` means that all packets have been
+enqueued.
+
+Data pointed in each op, should not be released until the dequeue of for that
+op.
+
+The dequeue API uses the same format as the enqueue API of processed but
+the ``nb_ops`` and ``ops`` parameters are now used to specify the max processed
+operations the user wishes to retrieve and the location in which to store them.
+The API call returns the actual number of processed operations returned, this
+can never be larger than ``nb_ops``.
+
diff --git a/lib/Makefile b/lib/Makefile
index 46b91ae..a273564 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -44,6 +44,8 @@ DEPDIRS-librte_eventdev := librte_eal librte_ring librte_ethdev librte_hash \
                            librte_mempool librte_timer librte_cryptodev
 DIRS-$(CONFIG_RTE_LIBRTE_RAWDEV) += librte_rawdev
 DEPDIRS-librte_rawdev := librte_eal librte_ethdev
+DIRS-$(CONFIG_RTE_LIBRTE_REGEXDEV) += librte_regexdev
+DEPDIRS-librte_regexdev := librte_eal librte_mbuf
 DIRS-$(CONFIG_RTE_LIBRTE_VHOST) += librte_vhost
 DEPDIRS-librte_vhost := librte_eal librte_mempool librte_mbuf librte_ethdev \
 			librte_net librte_hash librte_cryptodev
diff --git a/lib/librte_regexdev/Makefile b/lib/librte_regexdev/Makefile
new file mode 100644
index 0000000..6f4cc63
--- /dev/null
+++ b/lib/librte_regexdev/Makefile
@@ -0,0 +1,31 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(C) 2019 Marvell International Ltd.
+# Copyright(C) 2020 Mellanox International Ltd.
+#
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+# library name
+LIB = librte_regexdev.a
+
+EXPORT_MAP := rte_regex_version.map
+
+# library version
+LIBABIVER := 1
+
+# build flags
+CFLAGS += -O3
+CFLAGS += $(WERROR_FLAGS)
+LDLIBS += -lrte_eal -lrte_mbuf
+
+# library source files
+# all source are stored in SRCS-y
+SRCS-$(CONFIG_RTE_LIBRTE_REGEXDEV) := rte_regexdev.c
+
+# export include files
+SYMLINK-$(CONFIG_RTE_LIBRTE_REGEXDEV)-include += rte_regexdev.h
+
+# versioning export map
+EXPORT_MAP := rte_regexdev_version.map
+
+include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_regexdev/meson.build b/lib/librte_regexdev/meson.build
new file mode 100644
index 0000000..f4db748
--- /dev/null
+++ b/lib/librte_regexdev/meson.build
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2020 Mellanox Corporation
+
+allow_experimental_apis = true
+sources = files('rte_regexdev.c')
+headers = files('rte_regexdev.h')
+deps += ['mbuf']
diff --git a/lib/librte_regexdev/rte_regexdev.c b/lib/librte_regexdev/rte_regexdev.c
new file mode 100644
index 0000000..b901877
--- /dev/null
+++ b/lib/librte_regexdev/rte_regexdev.c
@@ -0,0 +1,6 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2019 Marvell International Ltd.
+ * Copyright(C) 2020 Mellanox International Ltd.
+ */
+
+#include <rte_regexdev.h>
diff --git a/lib/librte_regexdev/rte_regexdev.h b/lib/librte_regexdev/rte_regexdev.h
new file mode 100644
index 0000000..7e688d9
--- /dev/null
+++ b/lib/librte_regexdev/rte_regexdev.h
@@ -0,0 +1,1473 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2019 Marvell International Ltd.
+ * Copyright(C) 2020 Mellanox International Ltd.
+ * Copyright(C) 2020 Intel International Ltd.
+ */
+
+#ifndef _RTE_REGEXDEV_H_
+#define _RTE_REGEXDEV_H_
+
+/**
+ * @file
+ *
+ * RTE RegEx Device API
+ *
+ * Defines RTE RegEx Device APIs for RegEx operations and its provisioning.
+ *
+ * The RegEx Device API is composed of two parts:
+ *
+ * - The application-oriented RegEx API that includes functions to setup
+ *   a RegEx device (configure it, setup its queue pairs and start it),
+ *   update the rule database and so on.
+ *
+ * - The driver-oriented RegEx API that exports a function allowing
+ *   a RegEx poll Mode Driver (PMD) to simultaneously register itself as
+ *   a RegEx device driver.
+ *
+ * RegEx device components and definitions:
+ *
+ *     +-----------------+
+ *     |                 |
+ *     |                 o---------+    rte_regexdev_[en|de]queue_burst()
+ *     |   PCRE based    o------+  |               |
+ *     |  RegEx pattern  |      |  |  +--------+   |
+ *     | matching engine o------+--+--o        |   |    +------+
+ *     |                 |      |  |  | queue  |<==o===>|Core 0|
+ *     |                 o----+ |  |  | pair 0 |        |      |
+ *     |                 |    | |  |  +--------+        +------+
+ *     +-----------------+    | |  |
+ *            ^               | |  |  +--------+
+ *            |               | |  |  |        |        +------+
+ *            |               | +--+--o queue  |<======>|Core 1|
+ *        Rule|Database       |    |  | pair 1 |        |      |
+ *     +------+----------+    |    |  +--------+        +------+
+ *     |     Group 0     |    |    |
+ *     | +-------------+ |    |    |  +--------+        +------+
+ *     | | Rules 0..n  | |    |    |  |        |        |Core 2|
+ *     | +-------------+ |    |    +--o queue  |<======>|      |
+ *     |     Group 1     |    |       | pair 2 |        +------+
+ *     | +-------------+ |    |       +--------+
+ *     | | Rules 0..n  | |    |
+ *     | +-------------+ |    |       +--------+
+ *     |     Group 2     |    |       |        |        +------+
+ *     | +-------------+ |    |       | queue  |<======>|Core n|
+ *     | | Rules 0..n  | |    +-------o pair n |        |      |
+ *     | +-------------+ |            +--------+        +------+
+ *     |     Group n     |
+ *     | +-------------+ |<-------rte_regexdev_rule_db_update()
+ *     | |             | |<-------rte_regexdev_rule_db_compile_activate()
+ *     | | Rules 0..n  | |<-------rte_regexdev_rule_db_import()
+ *     | +-------------+ |------->rte_regexdev_rule_db_export()
+ *     +-----------------+
+ *
+ * RegEx: A regular expression is a concise and flexible means for matching
+ * strings of text, such as particular characters, words, or patterns of
+ * characters. A common abbreviation for this is “RegEx”.
+ *
+ * RegEx device: A hardware or software-based implementation of RegEx
+ * device API for PCRE based pattern matching syntax and semantics.
+ *
+ * PCRE RegEx syntax and semantics specification:
+ * http://regexkit.sourceforge.net/Documentation/pcre/pcrepattern.html
+ *
+ * RegEx queue pair: Each RegEx device should have one or more queue pair to
+ * transmit a burst of pattern matching request and receive a burst of
+ * receive the pattern matching response. The pattern matching request/response
+ * embedded in *rte_regex_ops* structure.
+ *
+ * Rule: A pattern matching rule expressed in PCRE RegEx syntax along with
+ * Match ID and Group ID to identify the rule upon the match.
+ *
+ * Rule database: The RegEx device accepts regular expressions and converts them
+ * into a compiled rule database that can then be used to scan data.
+ * Compilation allows the device to analyze the given pattern(s) and
+ * pre-determine how to scan for these patterns in an optimized fashion that
+ * would be far too expensive to compute at run-time. A rule database contains
+ * a set of rules that compiled in device specific binary form.
+ *
+ * Match ID or Rule ID: A unique identifier provided at the time of rule
+ * creation for the application to identify the rule upon match.
+ *
+ * Group ID: Group of rules can be grouped under one group ID to enable
+ * rule isolation and effective pattern matching. A unique group identifier
+ * provided at the time of rule creation for the application to identify the
+ * rule upon match.
+ *
+ * Scan: A pattern matching request through *enqueue* API.
+ *
+ * It may possible that a given RegEx device may not support all the features
+ * of PCRE. The application may probe unsupported features through
+ * struct rte_regexdev_info::pcre_unsup_flags
+ *
+ * By default, all the functions of the RegEx Device API exported by a PMD
+ * are lock-free functions which assume to not be invoked in parallel on
+ * different logical cores to work on the same target object. For instance,
+ * the dequeue function of a PMD cannot be invoked in parallel on two logical
+ * cores to operates on same RegEx queue pair. Of course, this function
+ * can be invoked in parallel by different logical core on different queue pair.
+ * It is the responsibility of the upper level application to enforce this rule.
+ *
+ * In all functions of the RegEx API, the RegEx device is
+ * designated by an integer >= 0 named the device identifier *dev_id*
+ *
+ * At the RegEx driver level, RegEx devices are represented by a generic
+ * data structure of type *rte_regexdev*.
+ *
+ * RegEx devices are dynamically registered during the PCI/SoC device probing
+ * phase performed at EAL initialization time.
+ * When a RegEx device is being probed, a *rte_regexdev* structure and
+ * a new device identifier are allocated for that device. Then, the
+ * regexdev_init() function supplied by the RegEx driver matching the probed
+ * device is invoked to properly initialize the device.
+ *
+ * The role of the device init function consists of resetting the hardware or
+ * software RegEx driver implementations.
+ *
+ * If the device init operation is successful, the correspondence between
+ * the device identifier assigned to the new device and its associated
+ * *rte_regexdev* structure is effectively registered.
+ * Otherwise, both the *rte_regexdev* structure and the device identifier are
+ * freed.
+ *
+ * The functions exported by the application RegEx API to setup a device
+ * designated by its device identifier must be invoked in the following order:
+ *     - rte_regexdev_configure()
+ *     - rte_regexdev_queue_pair_setup()
+ *     - rte_regexdev_start()
+ *
+ * Then, the application can invoke, in any order, the functions
+ * exported by the RegEx API to enqueue pattern matching job, dequeue pattern
+ * matching response, get the stats, update the rule database,
+ * get/set device attributes and so on
+ *
+ * If the application wants to change the configuration (i.e. call
+ * rte_regexdev_configure() or rte_regexdev_queue_pair_setup()), it must call
+ * rte_regexdev_stop() first to stop the device and then do the reconfiguration
+ * before calling rte_regexdev_start() again. The enqueue and dequeue
+ * functions should not be invoked when the device is stopped.
+ *
+ * Finally, an application can close a RegEx device by invoking the
+ * rte_regexdev_close() function.
+ *
+ * Each function of the application RegEx API invokes a specific function
+ * of the PMD that controls the target device designated by its device
+ * identifier.
+ *
+ * For this purpose, all device-specific functions of a RegEx driver are
+ * supplied through a set of pointers contained in a generic structure of type
+ * *regexdev_ops*.
+ * The address of the *regexdev_ops* structure is stored in the *rte_regexdev*
+ * structure by the device init function of the RegEx driver, which is
+ * invoked during the PCI/SoC device probing phase, as explained earlier.
+ *
+ * In other words, each function of the RegEx API simply retrieves the
+ * *rte_regexdev* structure associated with the device identifier and
+ * performs an indirect invocation of the corresponding driver function
+ * supplied in the *regexdev_ops* structure of the *rte_regexdev* structure.
+ *
+ * For performance reasons, the address of the fast-path functions of the
+ * RegEx driver is not contained in the *regexdev_ops* structure.
+ * Instead, they are directly stored at the beginning of the *rte_regexdev*
+ * structure to avoid an extra indirect memory access during their invocation.
+ *
+ * RTE RegEx device drivers do not use interrupts for enqueue or dequeue
+ * operation. Instead, RegEx drivers export Poll-Mode enqueue and dequeue
+ * functions to applications.
+ *
+ * The *enqueue* operation submits a burst of RegEx pattern matching request
+ * to the RegEx device and the *dequeue* operation gets a burst of pattern
+ * matching response for the ones submitted through *enqueue* operation.
+ *
+ * Typical application utilisation of the RegEx device API will follow the
+ * following programming flow.
+ *
+ * - rte_regexdev_configure()
+ * - rte_regexdev_queue_pair_setup()
+ * - rte_regexdev_rule_db_update() Needs to invoke if precompiled rule database
+ *   not provided in rte_regexdev_config::rule_db for rte_regexdev_configure()
+ *   and/or application needs to update rule database.
+ * - rte_regexdev_rule_db_compile_activate() Needs to invoke if
+ *   rte_regexdev_rule_db_update function was used.
+ * - Create or reuse exiting mempool for *rte_regex_ops* objects.
+ * - rte_regexdev_start()
+ * - rte_regexdev_enqueue_burst()
+ * - rte_regexdev_dequeue_burst()
+ *
+ */
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include <rte_common.h>
+#include <rte_config.h>
+#include <rte_dev.h>
+#include <rte_errno.h>
+#include <rte_mbuf.h>
+#include <rte_memory.h>
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Get the total number of RegEx devices that have been successfully
+ * initialised.
+ *
+ * @return
+ *   The total number of usable RegEx devices.
+ */
+__rte_experimental
+uint8_t
+rte_regexdev_count(void);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Get the device identifier for the named RegEx device.
+ *
+ * @param name
+ *   RegEx device name to select the RegEx device identifier.
+ *
+ * @return
+ *   Returns RegEx device identifier on success.
+ *   - <0: Failure to find named RegEx device.
+ */
+__rte_experimental
+int
+rte_regexdev_get_dev_id(const char *name);
+
+/* Enumerates RegEx device capabilities */
+#define RTE_REGEXDEV_CAPA_RUNTIME_COMPILATION_F (1ULL << 0)
+/**< RegEx device does support compiling the rules at runtime unlike
+ * loading only the pre-built rule database using
+ * struct rte_regexdev_config::rule_db in rte_regexdev_configure()
+ *
+ * @see struct rte_regexdev_config::rule_db, rte_regexdev_configure()
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_CAPA_SUPP_PCRE_START_ANCHOR_F (1ULL << 1)
+/**< RegEx device support PCRE Anchor to start of match flag.
+ * Example RegEx is '/\Gfoo\d/'. Here '\G' asserts position at the end of the
+ * previous match or the start of the string for the first match.
+ * This position will change each time the RegEx is applied to the subject
+ * string. If the RegEx is applied to 'foo1foo2Zfoo3' the first two matches will
+ * be successful for 'foo1foo2' and fail for 'Zfoo3'.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_CAPA_SUPP_PCRE_ATOMIC_GROUPING_F (1ULL << 2)
+/**< RegEx device support PCRE Atomic grouping.
+ * Atomic groups are represented by '(?>)'. An atomic group is a group that,
+ * when the RegEx engine exits from it, automatically throws away all
+ * backtracking positions remembered by any tokens inside the group.
+ * Example RegEx is 'a(?>bc|b)c' if the given patterns are 'abc' and 'abcc' then
+ * 'a(bc|b)c' matches both where as 'a(?>bc|b)c' matches only abcc because
+ * atomic groups don't allow backtracing back to 'b'.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_BACKTRACKING_CTRL_F (1ULL << 3)
+/**< RegEx device support PCRE backtracking control verbs.
+ * Some examples of backtracing verbs are (*COMMIT), (*ACCEPT), (*FAIL),
+ * (*SKIP), (*PRUNE).
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_CALLOUTS_F (1ULL << 4)
+/**< RegEx device support PCRE callouts.
+ * PCRE supports calling external function in between matches by using '(?C)'.
+ * Example RegEx 'ABC(?C)D' if a given patter is 'ABCD' then the RegEx engine
+ * will parse ABC perform a userdefined callout and return a successful match at
+ * D.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_BACKREFERENCE_F (1ULL << 5)
+/**< RegEx device support PCRE backreference.
+ * Example RegEx is '(\2ABC|(GHI))+' \2 matches the same text as most recently
+ * matched by the 2nd capturing group i.e. 'GHI'.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_GREEDY_F (1ULL << 6)
+/**< RegEx device support PCRE Greedy mode.
+ * For example if the RegEx is 'AB\d*?' then '*?' represents zero or unlimited
+ * matches. In greedy mode the pattern 'AB12345' will be matched completely
+ * where as the ungreedy mode 'AB' will be returned as the match.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_MATCH_ALL_F (1ULL << 7)
+/**< RegEx device support match all mode.
+ * For example if the RegEx is 'AB\d*?' then '*?' represents zero or unlimited
+ * matches. In match all mode the pattern 'AB12345' will return 6 matches.
+ * AB, AB1, AB12, AB123, AB1234, AB12345.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_LOOKAROUND_ASRT_F (1ULL << 8)
+/**< RegEx device support PCRE Lookaround assertions
+ * (Zero-width assertions). Example RegEx is '[a-z]+\d+(?=!{3,})' if
+ * the given pattern is 'dwad1234!' the RegEx engine doesn't report any matches
+ * because the assert '(?=!{3,})' fails. The pattern 'dwad123!!!' would return a
+ * successful match.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_MATCH_POINT_RST_F (1ULL << 9)
+/**< RegEx device doesn't support PCRE match point reset directive.
+ * Example RegEx is '[a-z]+\K\d+' if the pattern is 'dwad123'
+ * then even though the entire pattern matches only '123'
+ * is reported as a match.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_NEWLINE_CONVENTIONS_F (1ULL << 10)
+/**< RegEx support PCRE newline convention.
+ * Newline conventions are represented as follows:
+ * (*CR)        carriage return
+ * (*LF)        linefeed
+ * (*CRLF)      carriage return, followed by linefeed
+ * (*ANYCRLF)   any of the three above
+ * (*ANY)       all Unicode newline sequences
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_NEWLINE_SEQ_F (1ULL << 11)
+/**< RegEx device support PCRE newline sequence.
+ * The escape sequence '\R' will match any newline sequence.
+ * It is equivalent to: '(?>\r\n|\n|\x0b|\f|\r|\x85)'.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_POSSESSIVE_QUALIFIERS_F (1ULL << 12)
+/**< RegEx device support PCRE possessive qualifiers.
+ * Example RegEx possessive qualifiers '*+', '++', '?+', '{m,n}+'.
+ * Possessive quantifier repeats the token as many times as possible and it does
+ * not give up matches as the engine backtracks. With a possessive quantifier,
+ * the deal is all or nothing.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_SUBROUTINE_REFERENCES_F (1ULL << 13)
+/**< RegEx device support PCRE Subroutine references.
+ * PCRE Subroutine references allow for sub patterns to be assessed
+ * as part of the RegEx. Example RegEx is '(foo|fuzz)\g<1>+bar' matches the
+ * pattern 'foofoofuzzfoofuzzbar'.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_UTF_8_F (1ULL << 14)
+/**< RegEx device support UTF-8 character encoding.
+ *
+ * @see struct rte_regexdev_info::pcre_unsup_flags
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_UTF_16_F (1ULL << 15)
+/**< RegEx device support UTF-16 character encoding.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_UTF_32_F (1ULL << 16)
+/**< RegEx device support UTF-32 character encoding.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_WORD_BOUNDARY_F (1ULL << 17)
+/**< RegEx device support word boundaries.
+ * The meta character '\b' represents word boundary anchor.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_FORWARD_REFERENCES_F (1ULL << 18)
+/**< RegEx device support Forward references.
+ * Forward references allow you to use a back reference to a group that appears
+ * later in the RegEx. Example RegEx is '(\3ABC|(DEF|(GHI)))+' matches the
+ * following string 'GHIGHIABCDEF'.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_MATCH_AS_END_F (1ULL << 19)
+/**< RegEx device support match as end.
+ * Match as end means that the match result holds the end offset of the
+ * detected match. No len value is set.
+ * If the device doesn't support this feature it means the match
+ * result holds the starting position of match and the length of the match.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_CROSS_BUFFER_F (1ULL << 20)
+/**< RegEx device support cross buffer match.
+ * Cross buffer matching means that the match can be detected even if the
+ * string was started in previous buffer.
+ * In case the device is configured as RTE_REGEXDEV_CFG_MATCH_AS_END
+ * the end offset will be relative for the first packet.
+ * For example RegEx is ABC the first buffer is xxxx second buffer yyyA and
+ * the last buffer BCzz.
+ * In case the match as end is configured the end offset will be 10.
+ *
+ * @see RTE_REGEXDEV_CFG_MATCH_AS_END_F
+ * @see RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F
+ * @see RTE_REGEX_OPS_RSP_PMI_SOJ_F
+ * @see RTE_REGEX_OPS_RSP_PMI_EOJ_F
+ */
+
+#define RTE_REGEXDEV_SUPP_MATCH_ALL_F (1ULL << 21)
+/**< RegEx device support match all.
+ * Match all means that the RegEx engine will return all possible matches.
+ * For example, assume the RegEx is 'A+b', given the input AAAb the
+ * returned matches will be: Ab, AAb and AAAb.
+ *
+ * @see RTE_REGEXDEV_CFG_MATCH_ALL_F
+ */
+
+/* Enumerates PCRE rule flags */
+#define RTE_REGEX_PCRE_RULE_ALLOW_EMPTY_F (1ULL << 0)
+/**< When this flag is set, the pattern that can match against an empty string,
+ * such as '.*' are allowed.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_ANCHORED_F (1ULL << 1)
+/**< When this flag is set, the pattern is forced to be "anchored", that is, it
+ * is constrained to match only at the first matching point in the string that
+ * is being searched. Similar to '^' and represented by \A.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_CASELESS_F (1ULL << 2)
+/**< When this flag is set, letters in the pattern match both upper and lower
+ * case letters in the subject.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_DOTALL_F (1ULL << 3)
+/**< When this flag is set, a dot metacharacter in the pattern matches any
+ * character, including one that indicates a newline.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_DUPNAMES_F (1ULL << 4)
+/**< When this flag is set, names used to identify capture groups need not be
+ * unique.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_EXTENDED_F (1ULL << 5)
+/**< When this flag is set, most white space characters in the pattern are
+ * totally ignored except when escaped or inside a character class.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_MATCH_UNSET_BACKREF_F (1ULL << 6)
+/**< When this flag is set, a backreference to an unset capture group matches an
+ * empty string.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_MULTILINE_F (1ULL << 7)
+/**< When this flag  is set, the '^' and '$' constructs match immediately
+ * following or immediately before internal newlines in the subject string,
+ * respectively, as well as at the very start and end.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_NO_AUTO_CAPTURE_F (1ULL << 8)
+/**< When this Flag is set, it disables the use of numbered capturing
+ * parentheses in the pattern. References to capture groups (backreferences or
+ * recursion/subroutine calls) may only refer to named groups, though the
+ * reference can be by name or by number.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_UCP_F (1ULL << 9)
+/**< By default, only ASCII characters are recognized, When this flag is set,
+ * Unicode properties are used instead to classify characters.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_UNGREEDY_F (1ULL << 10)
+/**< When this flag is set, the "greediness" of the quantifiers is inverted
+ * so that they are not greedy by default, but become greedy if followed by
+ * '?'.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_UTF_F (1ULL << 11)
+/**< When this flag is set, RegEx engine has to regard both the pattern and the
+ * subject strings that are subsequently processed as strings of UTF characters
+ * instead of single-code-unit strings.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_NEVER_BACKSLASH_C_F (1ULL << 12)
+/**< This flag locks out the use of '\C' in the pattern that is being compiled.
+ * This escape matches one data unit, even in UTF mode which can cause
+ * unpredictable behavior in UTF-8 or UTF-16 modes, because it may leave the
+ * current matching point in the mi:set hlsearchddle of a multi-code-unit
+ * character.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+/**
+ * RegEx device information
+ */
+struct rte_regexdev_info {
+	const char *driver_name; /**< RegEx driver name. */
+	struct rte_device *dev;	/**< Device information. */
+	uint16_t max_matches;
+	/**< Maximum matches per scan supported by this device. */
+	uint16_t max_queue_pairs;
+	/**< Maximum queue pairs supported by this device. */
+	uint16_t max_payload_size;
+	/**< Maximum payload size for a pattern match request or scan.
+	 * @see RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F
+	 */
+	uint32_t max_rules_per_group;
+	/**< Maximum rules supported per group by this device. */
+	uint16_t max_groups;
+	/**< Maximum groups supported by this device. */
+	uint32_t regexdev_capa;
+	/**< RegEx device capabilities. @see RTE_REGEXDEV_CAPA_* */
+	uint64_t rule_flags;
+	/**< Supported compiler rule flags.
+	 * @see RTE_REGEX_PCRE_RULE_*, struct rte_regexdev_rule::rule_flags
+	 */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Retrieve the contextual information of a RegEx device.
+ *
+ * @param dev_id
+ *   The identifier of the device.
+ *
+ * @param[out] dev_info
+ *   A pointer to a structure of type *rte_regexdev_info* to be filled with the
+ *   contextual information of the device.
+ *
+ * @return
+ *   - 0: Success, driver updates the contextual information of the RegEx device
+ *   - <0: Error code returned by the driver info get function.
+ */
+__rte_experimental
+int
+rte_regexdev_info_get(uint8_t dev_id, struct rte_regexdev_info *dev_info);
+
+/* Enumerates RegEx device configuration flags */
+#define RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F (1ULL << 0)
+/**< Cross buffer scan refers to the ability to be able to detect
+ * matches that occur across buffer boundaries, where the buffers are related
+ * to each other in some way. Enable this flag when to scan payload size
+ * greater than struct rte_regexdev_info::max_payload_size and/or
+ * matches can present across scan buffer boundaries.
+ *
+ * @see struct rte_regexdev_info::max_payload_size
+ * @see struct rte_regexdev_config::dev_cfg_flags, rte_regexdev_configure()
+ * @see RTE_REGEX_OPS_RSP_PMI_SOJ_F
+ * @see RTE_REGEX_OPS_RSP_PMI_EOJ_F
+ */
+
+#define RTE_REGEXDEV_CFG_MATCH_AS_END_F (1ULL << 1)
+/**< Match as end is the ability to return the result as ending offset.
+ * When this flag is set, the result for each match will hold the ending
+ * offset of the match in end_offset.
+ * If this flag is not set, then the match result will hold the starting offset
+ * in start_offset, and the length of the match in len.
+ *
+ * @see RTE_REGEXDEV_SUPP_MATCH_AS_END_F
+ */
+
+#define RTE_REGEXDEV_CFG_MATCH_ALL_F (1ULL << 2)
+/**< Match all is the ability to return all possible results.
+ *
+ * @see RTE_REGEXDEV_SUPP_MATCH_ALL_F
+ */
+
+/** RegEx device configuration structure */
+struct rte_regexdev_config {
+	uint16_t nb_max_matches;
+	/**< Maximum matches per scan configured on this device.
+	 * This value cannot exceed the *max_matches*
+	 * which previously provided in rte_regexdev_info_get().
+	 * The value 0 is allowed, in which case, value 1 used.
+	 * @see struct rte_regexdev_info::max_matches
+	 */
+	uint16_t nb_queue_pairs;
+	/**< Number of RegEx queue pairs to configure on this device.
+	 * This value cannot exceed the *max_queue_pairs* which previously
+	 * provided in rte_regexdev_info_get().
+	 * @see struct rte_regexdev_info::max_queue_pairs
+	 */
+	uint32_t nb_rules_per_group;
+	/**< Number of rules per group to configure on this device.
+	 * This value cannot exceed the *max_rules_per_group*
+	 * which previously provided in rte_regexdev_info_get().
+	 * The value 0 is allowed, in which case,
+	 * struct rte_regexdev_info::max_rules_per_group used.
+	 * @see struct rte_regexdev_info::max_rules_per_group
+	 */
+	uint16_t nb_groups;
+	/**< Number of groups to configure on this device.
+	 * This value cannot exceed the *max_groups*
+	 * which previously provided in rte_regexdev_info_get().
+	 * @see struct rte_regexdev_info::max_groups
+	 */
+	const char *rule_db;
+	/**< Import initial set of prebuilt rule database on this device.
+	 * The value NULL is allowed, in which case, the device will not
+	 * be configured prebuilt rule database. Application may use
+	 * rte_regexdev_rule_db_update() or rte_regexdev_rule_db_import() API
+	 * to update or import rule database after the
+	 * rte_regexdev_configure().
+	 * @see rte_regexdev_rule_db_update(), rte_regexdev_rule_db_import()
+	 */
+	uint32_t rule_db_len;
+	/**< Length of *rule_db* buffer. */
+	uint32_t dev_cfg_flags;
+	/**< RegEx device configuration flags, See RTE_REGEXDEV_CFG_*  */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Configure a RegEx device.
+ *
+ * This function must be invoked first before any other function in the
+ * API. This function can also be re-invoked when a device is in the
+ * stopped state.
+ *
+ * The caller may use rte_regexdev_info_get() to get the capability of each
+ * resources available for this regex device.
+ *
+ * @param dev_id
+ *   The identifier of the device to configure.
+ * @param cfg
+ *   The RegEx device configuration structure.
+ *
+ * @return
+ *   - 0: Success, device configured. Otherwise negative errno is returned.
+ */
+__rte_experimental
+int
+rte_regexdev_configure(uint8_t dev_id, const struct rte_regexdev_config *cfg);
+
+/* Enumerates RegEx queue pair configuration flags */
+#define RTE_REGEX_QUEUE_PAIR_CFG_OOS_F (1ULL << 0)
+/**< Out of order scan, If not set, a scan must retire after previously issued
+ * in-order scans to this queue pair. If set, this scan can be retired as soon
+ * as device returns completion. Application should not set out of order scan
+ * flag if it needs to maintain the ingress order of scan request.
+ *
+ * @see struct rte_regexdev_qp_conf::qp_conf_flags
+ * @see rte_regexdev_queue_pair_setup()
+ */
+
+struct rte_regex_ops;
+typedef void (*regexdev_stop_flush_t)(uint8_t dev_id, uint16_t qp_id,
+				      struct rte_regex_ops *op);
+/**< Callback function called during rte_regexdev_stop(), invoked once per
+ * flushed RegEx op.
+ */
+
+/** RegEx queue pair configuration structure */
+struct rte_regexdev_qp_conf {
+	uint32_t qp_conf_flags;
+	/**< Queue pair config flags, See RTE_REGEX_QUEUE_PAIR_CFG_* */
+	uint16_t nb_desc;
+	/**< The number of descriptors to allocate for this queue pair. */
+	regexdev_stop_flush_t cb;
+	/**< Callback function called during rte_regexdev_stop(), invoked
+	 * once per flushed regex op. Value NULL is allowed, in which case
+	 * callback will not be invoked. This function can be used to properly
+	 * dispose of outstanding regex ops from response queue,
+	 * for example ops containing memory pointers.
+	 * @see rte_regexdev_stop()
+	 */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Allocate and set up a RegEx queue pair for a RegEx device.
+ *
+ * @param dev_id
+ *   The identifier of the device.
+ * @param queue_pair_id
+ *   The index of the RegEx queue pair to setup. The value must be in the range
+ *   [0, nb_queue_pairs - 1] previously supplied to rte_regexdev_configure().
+ * @param qp_conf
+ *   The pointer to the configuration data to be used for the RegEx queue pair.
+ *   NULL value is allowed, in which case default configuration	used.
+ *
+ * @return
+ *   0 on success. Otherwise negative errno is returned.
+ */
+__rte_experimental
+int
+rte_regexdev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
+			      const struct rte_regexdev_qp_conf *qp_conf);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Start a RegEx device.
+ *
+ * The device start step is the last one and consists of setting the RegEx
+ * queues to start accepting the pattern matching scan requests.
+ *
+ * On success, all basic functions exported by the API (RegEx enqueue,
+ * RegEx dequeue and so on) can be invoked.
+ *
+ * @param dev_id
+ *   RegEx device identifier.
+ *
+ * @return
+ *   0 on success. Otherwise negative errno is returned.
+ */
+__rte_experimental
+int
+rte_regexdev_start(uint8_t dev_id);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Stop a RegEx device.
+ *
+ * Stop a RegEx device. The device can be restarted with a call to
+ * rte_regexdev_start().
+ *
+ * This function causes all queued response regex ops to be drained in the
+ * response queue. While draining ops out of the device,
+ * struct rte_regexdev_qp_conf::cb will be invoked for each ops.
+ *
+ * @param dev_id
+ *   RegEx device identifier.
+ *
+ * @see struct rte_regexdev_qp_conf::cb, rte_regexdev_queue_pair_setup()
+ */
+__rte_experimental
+void
+rte_regexdev_stop(uint8_t dev_id);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Close a RegEx device. The device cannot be restarted!
+ *
+ * @param dev_id
+ *   RegEx device identifier
+ *
+ * @return
+ *   0 on success. Otherwise negative errno is returned.
+ */
+__rte_experimental
+int
+rte_regexdev_close(uint8_t dev_id);
+
+/* Device get/set attributes */
+
+/** Enumerates RegEx device attribute identifier */
+enum rte_regexdev_attr_id {
+	RTE_REGEXDEV_ATTR_SOCKET_ID,
+	/**< The NUMA socket id to which the device is connected or
+	 * a default of zero if the socket could not be determined.
+	 * datatype: *int*
+	 * operation: *get*
+	 */
+	RTE_REGEXDEV_ATTR_MAX_MATCHES,
+	/**< Maximum number of matches per scan.
+	 * datatype: *uint8_t*
+	 * operation: *get* and *set*
+	 * @see RTE_REGEX_OPS_RSP_MAX_MATCH_F
+	 */
+	RTE_REGEXDEV_ATTR_MAX_SCAN_TIMEOUT,
+	/**< Upper bound scan time in ns.
+	 * datatype: *uint16_t*
+	 * operation: *get* and *set*
+	 * @see RTE_REGEX_OPS_RSP_MAX_SCAN_TIMEOUT_F
+	 */
+	RTE_REGEXDEV_ATTR_MAX_PREFIX,
+	/**< Maximum number of prefix detected per scan.
+	 * This would be useful for denial of service detection.
+	 * datatype: *uint16_t*
+	 * operation: *get* and *set*
+	 * @see RTE_REGEX_OPS_RSP_MAX_PREFIX_F
+	 */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Get an attribute from a RegEx device.
+ *
+ * @param dev_id
+ *   RegEx device identifier.
+ * @param attr_id
+ *   The attribute ID to retrieve.
+ * @param attr_value
+ *   A pointer that will be filled in with the attribute
+ *   value if successful.
+ *
+ * @return
+ *   - 0: Successfully retrieved attribute value.
+ *   - -EINVAL: Invalid device or  *attr_id* provided, or *attr_value* is NULL.
+ *   - -ENOTSUP: if the device doesn't support specific *attr_id*.
+ */
+__rte_experimental
+int
+rte_regexdev_attr_get(uint8_t dev_id, enum rte_regexdev_attr_id attr_id,
+		      void *attr_value);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Set an attribute to a RegEx device.
+ *
+ * @param dev_id
+ *   RegEx device identifier.
+ * @param attr_id
+ *   The attribute ID to retrieve.
+ * @param attr_value
+ *   Pointer that will be filled in with the attribute value
+ *   by the application.
+ *
+ * @return
+ *   - 0: Successfully applied the attribute value.
+ *   - -EINVAL: Invalid device or  *attr_id* provided, or *attr_value* is NULL.
+ *   - -ENOTSUP: if the device doesn't support specific *attr_id*.
+ */
+__rte_experimental
+int
+rte_regexdev_attr_set(uint8_t dev_id, enum rte_regexdev_attr_id attr_id,
+		      const void *attr_value);
+
+/* Rule related APIs */
+/** Enumerates RegEx rule operation. */
+enum rte_regexdev_rule_op {
+	RTE_REGEX_RULE_OP_ADD,
+	/**< Add RegEx rule to rule database. */
+	RTE_REGEX_RULE_OP_REMOVE
+	/**< Remove RegEx rule from rule database. */
+};
+
+/** Structure to hold a RegEx rule attributes. */
+struct rte_regexdev_rule {
+	enum rte_regexdev_rule_op op;
+	/**< OP type of the rule either a OP_ADD or OP_DELETE. */
+	uint16_t group_id;
+	/**< Group identifier to which the rule belongs to. */
+	uint32_t rule_id;
+	/**< Rule identifier which is returned on successful match. */
+	const char *pcre_rule;
+	/**< Buffer to hold the PCRE rule. */
+	uint16_t pcre_rule_len;
+	/**< Length of the PCRE rule. */
+	uint64_t rule_flags;
+	/* PCRE rule flags. Supported device specific PCRE rules enumerated
+	 * in struct rte_regexdev_info::rule_flags. For successful rule
+	 * database update, application needs to provide only supported
+	 * rule flags.
+	 * @See RTE_REGEX_PCRE_RULE_*, struct rte_regexdev_info::rule_flags
+	 */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Update the local rule set.
+ * This functions only modify the rule set in memory.
+ * In order for the changes to take effect, the function
+ * rte_regexdev_rule_db_compile_active must be called.
+ *
+ * @param dev_id
+ *   RegEx device identifier.
+ * @param rules
+ *   Points to an array of *nb_rules* objects of type *rte_regexdev_rule*
+ *   structure which contain the regex rules attributes to be updated
+ *   in rule database.
+ * @param nb_rules
+ *   The number of PCRE rules to update the rule database.
+ *
+ * @return
+ *   The number of regex rules actually updated on the regex device's rule
+ *   database. The return value can be less than the value of the *nb_rules*
+ *   parameter when the regex devices fails to update the rule database or
+ *   if invalid parameters are specified in a *rte_regexdev_rule*.
+ *   If the return value is less than *nb_rules*, the remaining PCRE rules
+ *   at the end of *rules* are not consumed and the caller has to take
+ *   care of them and rte_errno is set accordingly.
+ *   Possible errno values include:
+ *   - -EINVAL:  Invalid device ID or rules is NULL
+ *   - -ENOTSUP: The last processed rule is not supported on this device.
+ *   - -ENOSPC: No space available in rule database.
+ *
+ * @see rte_regexdev_rule_db_import(), rte_regexdev_rule_db_export(),
+ *   rte_regexdev_rule_db_compile_activate()
+ */
+__rte_experimental
+int
+rte_regexdev_rule_db_update(uint8_t dev_id,
+			    const struct rte_regexdev_rule *rules,
+			    uint32_t nb_rules);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Compile local rule set and burn the complied result to the
+ * RegEx deive.
+ *
+ * @param dev_id
+ *   RegEx device identifier.
+ *
+ * @return
+ *   0 on success, otherwise negative errno.
+ *
+ * @see rte_regexdev_rule_db_import(), rte_regexdev_rule_db_export(),
+ *   rte_regexdev_rule_db_update()
+ */
+__rte_experimental
+int
+rte_regexdev_rule_db_compile_activate(uint8_t dev_id);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Import a prebuilt rule database from a buffer to a RegEx device.
+ *
+ * @param dev_id
+ *   RegEx device identifier.
+ * @param rule_db
+ *   Points to prebuilt rule database.
+ * @param rule_db_len
+ *   Length of the rule database.
+ *
+ * @return
+ *   - 0: Successfully updated the prebuilt rule database.
+ *   - -EINVAL:  Invalid device ID or rule_db is NULL
+ *   - -ENOTSUP: Rule database import is not supported on this device.
+ *   - -ENOSPC: No space available in rule database.
+ *
+ * @see rte_regexdev_rule_db_update(), rte_regexdev_rule_db_export()
+ */
+__rte_experimental
+int
+rte_regexdev_rule_db_import(uint8_t dev_id, const char *rule_db,
+			    uint32_t rule_db_len);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Export the prebuilt rule database from a RegEx device to the buffer.
+ *
+ * @param dev_id
+ *   RegEx device identifier.
+ * @param[out] rule_db
+ *   Block of memory to insert the rule database. Must be at least size in
+ *   capacity. If set to NULL, function returns required capacity.
+ *
+ * @return
+ *   - 0: Successfully exported the prebuilt rule database.
+ *   - size: If rule_db set to NULL then required capacity for *rule_db*
+ *   - -EINVAL:  Invalid device ID
+ *   - -ENOTSUP: Rule database export is not supported on this device.
+ *
+ * @see rte_regexdev_rule_db_update(), rte_regexdev_rule_db_import()
+ */
+__rte_experimental
+int
+rte_regexdev_rule_db_export(uint8_t dev_id, char *rule_db);
+
+/* Extended statistics */
+/** Maximum name length for extended statistics counters */
+#define RTE_REGEXDEV_XSTATS_NAME_SIZE 64
+
+/**
+ * A name-key lookup element for extended statistics.
+ *
+ * This structure is used to map between names and ID numbers
+ * for extended RegEx device statistics.
+ */
+struct rte_regexdev_xstats_map {
+	uint16_t id;
+	/**< xstat identifier */
+	char name[RTE_REGEXDEV_XSTATS_NAME_SIZE];
+	/**< xstat name */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Retrieve names of extended statistics of a regex device.
+ *
+ * @param dev_id
+ *   The identifier of the regex device.
+ * @param[out] xstats_map
+ *   Block of memory to insert id and names into. Must be at least size in
+ *   capacity. If set to NULL, function returns required capacity.
+ * @return
+ *   - Positive value on success:
+ *        -The return value is the number of entries filled in the stats map.
+ *        -If xstats_map set to NULL then required capacity for xstats_map.
+ *   - Negative value on error:
+ *      -ENODEV for invalid *dev_id*
+ *      -ENOTSUP if the device doesn't support this function.
+ */
+__rte_experimental
+int
+rte_regexdev_xstats_names_get(uint8_t dev_id,
+			      struct rte_regexdev_xstats_map *xstats_map);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Retrieve extended statistics of an regex device.
+ *
+ * @param dev_id
+ *   The identifier of the device.
+ * @param ids
+ *   The id numbers of the stats to get. The ids can be got from the stat
+ *   position in the stat list from rte_regexdev_xstats_names_get(), or
+ *   by using rte_regexdev_xstats_by_name_get().
+ * @param values
+ *   The values for each stats request by ID.
+ * @param nb_values
+ *   The number of stats requested.
+ * @return
+ *   - Positive value: number of stat entries filled into the values array
+ *   - Negative value on error:
+ *      -ENODEV for invalid *dev_id*
+ *      -ENOTSUP if the device doesn't support this function.
+ */
+__rte_experimental
+int
+rte_regexdev_xstats_get(uint8_t dev_id, const uint16_t *ids,
+			uint64_t *values, uint16_t nb_values);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Retrieve the value of a single stat by requesting it by name.
+ *
+ * @param dev_id
+ *   The identifier of the device.
+ * @param name
+ *   The stat name to retrieve.
+ * @param id
+ *   If non-NULL, the numerical id of the stat will be returned, so that further
+ *   requests for the stat can be got using rte_regexdev_xstats_get, which will
+ *   be faster as it doesn't need to scan a list of names for the stat.
+ * @param[out] value
+ *   Must be non-NULL, retrieved xstat value will be stored in this address.
+ *
+ * @return
+ *   - 0: Successfully retrieved xstat value.
+ *   - -EINVAL: invalid parameters
+ *   - -ENOTSUP: if not supported.
+ */
+__rte_experimental
+int
+rte_regexdev_xstats_by_name_get(uint8_t dev_id, const char *name,
+				uint16_t *id, uint64_t *value);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Reset the values of the xstats of the selected component in the device.
+ *
+ * @param dev_id
+ *   The identifier of the device.
+ * @param ids
+ *   Selects specific statistics to be reset. When NULL, all statistics will be
+ *   reset. If non-NULL, must point to array of at least *nb_ids* size.
+ * @param nb_ids
+ *   The number of ids available from the *ids* array. Ignored when ids is NULL.
+ *
+ * @return
+ *   - 0: Successfully reset the statistics to zero.
+ *   - -EINVAL: invalid parameters.
+ *   - -ENOTSUP: if not supported.
+ */
+__rte_experimental
+int
+rte_regexdev_xstats_reset(uint8_t dev_id, const uint16_t *ids,
+			  uint16_t nb_ids);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Trigger the RegEx device self test.
+ *
+ * @param dev_id
+ *   The identifier of the device.
+ * @return
+ *   - 0: Selftest successful.
+ *   - -ENOTSUP if the device doesn't support selftest.
+ *   - other values < 0 on failure.
+ */
+__rte_experimental
+int
+rte_regexdev_selftest(uint8_t dev_id);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Dump internal information about *dev_id* to the FILE* provided in *f*.
+ *
+ * @param dev_id
+ *   The identifier of the device.
+ * @param f
+ *   A pointer to a file for output.
+ *
+ * @return
+ *   0 on success, negative errno on failure.
+ */
+__rte_experimental
+int
+rte_regexdev_dump(uint8_t dev_id, FILE *f);
+
+/* Fast path APIs */
+
+/**
+ * The generic *rte_regexdev_match* structure to hold the RegEx match
+ * attributes.
+ * @see struct rte_regex_ops::matches
+ */
+struct rte_regexdev_match {
+	RTE_STD_C11
+	union {
+		uint64_t u64;
+		struct {
+			uint32_t rule_id:20;
+			/**< Rule identifier to which the pattern matched.
+			 * @see struct rte_regexdev_rule::rule_id
+			 */
+			uint32_t group_id:12;
+			/**< Group identifier of the rule which the pattern
+			 * matched. @see struct rte_regexdev_rule::group_id
+			 */
+			uint16_t start_offset;
+			/**< Starting Byte Position for matched rule. */
+			RTE_STD_C11
+			union {
+				uint16_t len;
+				/**< Length of match in bytes */
+				uint16_t end_offset;
+				/**< The end offset of the match. In case
+				 * MATCH_AS_END configuration is enabled.
+				 * @see RTE_REGEXDEV_CFG_MATCH_AS_END
+				 */
+			};
+		};
+	};
+};
+
+/* Enumerates RegEx request flags. */
+#define RTE_REGEX_OPS_REQ_GROUP_ID0_VALID_F (1 << 0)
+/**< Set when struct rte_regexdev_rule::group_id0 is valid. */
+
+#define RTE_REGEX_OPS_REQ_GROUP_ID1_VALID_F (1 << 1)
+/**< Set when struct rte_regexdev_rule::group_id1 is valid. */
+
+#define RTE_REGEX_OPS_REQ_GROUP_ID2_VALID_F (1 << 2)
+/**< Set when struct rte_regexdev_rule::group_id2 is valid. */
+
+#define RTE_REGEX_OPS_REQ_GROUP_ID3_VALID_F (1 << 3)
+/**< Set when struct rte_regexdev_rule::group_id3 is valid. */
+
+#define RTE_REGEX_OPS_REQ_STOP_ON_MATCH_F (1 << 4)
+/**< The RegEx engine will stop scanning and return the first match. */
+
+#define RTE_REGEX_OPS_REQ_MATCH_HIGH_PRIORITY_F (1 << 5)
+/**< In High Priority mode a maximum of one match will be returned per scan to
+ * reduce the post-processing required by the application. The match with the
+ * lowest Rule id, lowest start pointer and lowest match length will be
+ * returned.
+ *
+ * @see struct rte_regex_ops::nb_actual_matches
+ * @see struct rte_regex_ops::nb_matches
+ */
+
+
+/* Enumerates RegEx response flags. */
+#define RTE_REGEX_OPS_RSP_PMI_SOJ_F (1 << 0)
+/**< Indicates that the RegEx device has encountered a partial match at the
+ * start of scan in the given buffer.
+ *
+ * @see RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F
+ */
+
+#define RTE_REGEX_OPS_RSP_PMI_EOJ_F (1 << 1)
+/**< Indicates that the RegEx device has encountered a partial match at the
+ * end of scan in the given buffer.
+ *
+ * @see RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F
+ */
+
+#define RTE_REGEX_OPS_RSP_MAX_SCAN_TIMEOUT_F (1 << 2)
+/**< Indicates that the RegEx device has exceeded the max timeout while
+ * scanning the given buffer.
+ *
+ * @see RTE_REGEXDEV_ATTR_MAX_SCAN_TIMEOUT
+ */
+
+#define RTE_REGEX_OPS_RSP_MAX_MATCH_F (1 << 3)
+/**< Indicates that the RegEx device has exceeded the max matches while
+ * scanning the given buffer.
+ *
+ * @see RTE_REGEXDEV_ATTR_MAX_MATCHES
+ */
+
+#define RTE_REGEX_OPS_RSP_MAX_PREFIX_F (1 << 4)
+/**< Indicates that the RegEx device has reached the max allowed prefix length
+ * while scanning the given buffer.
+ *
+ * @see RTE_REGEXDEV_ATTR_MAX_PREFIX
+ */
+
+/**
+ * The generic *rte_regex_ops* structure to hold the RegEx attributes
+ * for enqueue and dequeue operation.
+ */
+struct rte_regex_ops {
+	/* W0 */
+	uint16_t req_flags;
+	/**< Request flags for the RegEx ops.
+	 * @see RTE_REGEX_OPS_REQ_*
+	 */
+	uint16_t rsp_flags;
+	/**< Response flags for the RegEx ops.
+	 * @see RTE_REGEX_OPS_RSP_*
+	 */
+	uint16_t nb_actual_matches;
+	/**< The total number of actual matches detected by the Regex device.*/
+	uint16_t nb_matches;
+	/**< The total number of matches returned by the RegEx device for this
+	 * scan. The size of *rte_regex_ops::matches* zero length array will be
+	 * this value.
+	 *
+	 * @see struct rte_regex_ops::matches, struct rte_regexdev_match
+	 */
+
+	/* W1 */
+	struct rte_mbuf *mbuf; /**< source mbuf, to search in. */
+
+	/* W2 */
+	uint16_t group_id0;
+	/**< First group_id to match the rule against. At minimum one group
+	 * should be valid. Behaviour is undefined non of the groups are valid.
+	 *
+	 * @see RTE_REGEX_OPS_REQ_GROUP_ID0_VALID_F
+	 */
+	uint16_t group_id1;
+	/**< Second group_id to match the rule against.
+	 *
+	 * @see RTE_REGEX_OPS_REQ_GROUP_ID1_VALID_F
+	 */
+	uint16_t group_id2;
+	/**< Third group_id to match the rule against.
+	 *
+	 * @see RTE_REGEX_OPS_REQ_GROUP_ID2_VALID_F
+	 */
+	uint16_t group_id3;
+	/**< Forth group_id to match the rule against.
+	 *
+	 * @see RTE_REGEX_OPS_REQ_GROUP_ID3_VALID_F
+	 */
+
+	/* W3 */
+	RTE_STD_C11
+	union {
+		uint64_t user_id;
+		/**< Application specific opaque value. An application may use
+		 * this field to hold application specific value to share
+		 * between dequeue and enqueue operation.
+		 * Implementation should not modify this field.
+		 */
+		void *user_ptr;
+		/**< Pointer representation of *user_id* */
+	};
+
+	/* W4 */
+	RTE_STD_C11
+	union {
+		uint64_t cross_buf_id;
+		/**< ID used by the RegEx device in order to support cross
+		 * packet detection.
+		 * This ID is returned from the RegEx device on the dequeue
+		 * function. The application must send it back when calling
+		 * enqueue with the following packet.
+		 */
+		void *cross_buf_ptr;
+		/**< Pointer representation of *corss_buf_id* */
+	};
+
+	/* W5 */
+	struct rte_regexdev_match matches[];
+	/**< Zero length array to hold the match tuples.
+	 * The struct rte_regex_ops::nb_matches value holds the number of
+	 * elements in this array.
+	 *
+	 * @see struct rte_regex_ops::nb_matches
+	 */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Enqueue a burst of scan request on a RegEx device.
+ *
+ * The rte_regexdev_enqueue_burst() function is invoked to place
+ * regex operations on the queue *qp_id* of the device designated by
+ * its *dev_id*.
+ *
+ * The *nb_ops* parameter is the number of operations to process which are
+ * supplied in the *ops* array of *rte_regexdev_op* structures.
+ *
+ * The rte_regexdev_enqueue_burst() function returns the number of
+ * operations it actually enqueued for processing. A return value equal to
+ * *nb_ops* means that all packets have been enqueued.
+ *
+ * @param dev_id
+ *   The identifier of the device.
+ * @param qp_id
+ *   The index of the queue pair which packets are to be enqueued for
+ *   processing. The value must be in the range [0, nb_queue_pairs - 1]
+ *   previously supplied to rte_regexdev_configure().
+ * @param ops
+ *   The address of an array of *nb_ops* pointers to *rte_regexdev_op*
+ *   structures which contain the regex operations to be processed.
+ * @param nb_ops
+ *   The number of operations to process.
+ *
+ * @return
+ *   The number of operations actually enqueued on the regex device. The return
+ *   value can be less than the value of the *nb_ops* parameter when the
+ *   regex devices queue is full or if invalid parameters are specified in
+ *   a *rte_regexdev_op*. If the return value is less than *nb_ops*, the
+ *   remaining ops at the end of *ops* are not consumed and the caller has
+ *   to take care of them.
+ */
+__rte_experimental
+uint16_t
+rte_regexdev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
+			   struct rte_regex_ops **ops, uint16_t nb_ops);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Dequeue a burst of scan response from a queue on the RegEx device.
+ * The dequeued operation are stored in *rte_regexdev_op* structures
+ * whose pointers are supplied in the *ops* array.
+ *
+ * The rte_regexdev_dequeue_burst() function returns the number of ops
+ * actually dequeued, which is the number of *rte_regexdev_op* data structures
+ * effectively supplied into the *ops* array.
+ *
+ * A return value equal to *nb_ops* indicates that the queue contained
+ * at least *nb_ops* operations, and this is likely to signify that other
+ * processed operations remain in the devices output queue. Applications
+ * implementing a "retrieve as many processed operations as possible" policy
+ * can check this specific case and keep invoking the
+ * rte_regexdev_dequeue_burst() function until a value less than
+ * *nb_ops* is returned.
+ *
+ * The rte_regexdev_dequeue_burst() function does not provide any error
+ * notification to avoid the corresponding overhead.
+ *
+ * @param dev_id
+ *   The RegEx device identifier
+ * @param qp_id
+ *   The index of the queue pair from which to retrieve processed packets.
+ *   The value must be in the range [0, nb_queue_pairs - 1] previously
+ *   supplied to rte_regexdev_configure().
+ * @param ops
+ *   The address of an array of pointers to *rte_regexdev_op* structures
+ *   that must be large enough to store *nb_ops* pointers in it.
+ * @param nb_ops
+ *   The maximum number of operations to dequeue.
+ *
+ * @return
+ *   The number of operations actually dequeued, which is the number
+ *   of pointers to *rte_regexdev_op* structures effectively supplied to the
+ *   *ops* array. If the return value is less than *nb_ops*, the remaining
+ *   ops at the end of *ops* are not consumed and the caller has to take care
+ *   of them.
+ */
+__rte_experimental
+uint16_t
+rte_regexdev_dequeue_burst(uint8_t dev_id, uint16_t qp_id,
+			   struct rte_regex_ops **ops, uint16_t nb_ops);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_REGEXDEV_H_ */
diff --git a/lib/librte_regexdev/rte_regexdev_version.map b/lib/librte_regexdev/rte_regexdev_version.map
new file mode 100644
index 0000000..d400624
--- /dev/null
+++ b/lib/librte_regexdev/rte_regexdev_version.map
@@ -0,0 +1,26 @@
+EXPERIMENTAL {
+	global:
+
+	rte_regexdev_count;
+	rte_regexdev_get_dev_id;
+	rte_regexdev_info_get;
+	rte_regexdev_configure;
+	rte_regexdev_queue_pair_setup;
+	rte_regexdev_start;
+	rte_regexdev_stop;
+	rte_regexdev_close;
+	rte_regexdev_attr_get;
+	rte_regexdev_attr_set;
+	rte_regexdev_rule_db_update;
+	rte_regexdev_rule_db_compile_activate;
+	rte_regexdev_rule_db_import;
+	rte_regexdev_rule_db_export;
+	rte_regexdev_xstats_names_get;
+	rte_regexdev_xstats_get;
+	rte_regexdev_xstats_by_name_get;
+	rte_regexdev_xstats_reset;
+	rte_regexdev_selftest;
+	rte_regexdev_dump;
+	rte_regexdev_enqueue_burst;
+	rte_regexdev_dequeue_burst;
+};
diff --git a/lib/meson.build b/lib/meson.build
index 63c17ee..a5d63a4 100644
--- a/lib/meson.build
+++ b/lib/meson.build
@@ -22,7 +22,8 @@ libraries = [
 	'gro', 'gso', 'ip_frag', 'jobstats',
 	'kni', 'latencystats', 'lpm', 'member',
 	'power', 'pdump', 'rawdev',
-	'rcu', 'rib', 'reorder', 'sched', 'security', 'stack', 'vhost',
+	'rcu', 'regexdev', 'rib', 'reorder', 'sched', 'security', 'stack',
+	'vhost',
 	# ipsec lib depends on net, crypto and security
 	'ipsec',
 	#fib lib depends on rib
-- 
1.8.3.1


^ permalink raw reply	[flat|nested] 96+ messages in thread

* [dpdk-dev] [PATCH v2 2/4] regexdev: add regex core h file
  2020-04-17 12:43 ` [dpdk-dev] [PATCH v2 " Ori Kam
  2020-04-17 12:43   ` [dpdk-dev] [PATCH v2 1/4] regexdev: introduce regexdev subsystem Ori Kam
@ 2020-04-17 12:43   ` Ori Kam
  2020-04-20 10:48     ` Guy Kaneti
  2020-04-17 12:43   ` [dpdk-dev] [PATCH v2 3/4] regexdev: add regexdev core functions Ori Kam
  2020-04-17 12:43   ` [dpdk-dev] [PATCH v2 4/4] regexdev: implement regex rte level functions Ori Kam
  3 siblings, 1 reply; 96+ messages in thread
From: Ori Kam @ 2020-04-17 12:43 UTC (permalink / raw)
  To: jerinj, xiang.w.wang
  Cc: dev, pbhagavatula, shahafs, hemant.agrawal, opher, alexr, dovrat,
	pkapoor, nipun.gupta, bruce.richardson, yang.a.hong, harry.chang,
	gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai, yuyingxia,
	fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc, jim,
	hongjun.ni, j.bromhead, deri, fc, arthur.su, thomas, orika

This commit introduce the rte_regexdev_core.h file.
This file holds internal structures and API that are used by
the regexdev.

Signed-off-by: Ori Kam <orika@mellanox.com>
---
v2:
* Move private data to rte_regexdev struct.
---
 lib/librte_regexdev/Makefile            |   1 +
 lib/librte_regexdev/meson.build         |   2 +-
 lib/librte_regexdev/rte_regexdev.h      |   2 +
 lib/librte_regexdev/rte_regexdev_core.h | 160 ++++++++++++++++++++++++++++++++
 4 files changed, 164 insertions(+), 1 deletion(-)
 create mode 100644 lib/librte_regexdev/rte_regexdev_core.h

diff --git a/lib/librte_regexdev/Makefile b/lib/librte_regexdev/Makefile
index 6f4cc63..9012d29 100644
--- a/lib/librte_regexdev/Makefile
+++ b/lib/librte_regexdev/Makefile
@@ -24,6 +24,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_REGEXDEV) := rte_regexdev.c
 
 # export include files
 SYMLINK-$(CONFIG_RTE_LIBRTE_REGEXDEV)-include += rte_regexdev.h
+SYMLINK-$(CONFIG_RTE_LIBRTE_REGEXDEV)-include += rte_regexdev_core.h
 
 # versioning export map
 EXPORT_MAP := rte_regexdev_version.map
diff --git a/lib/librte_regexdev/meson.build b/lib/librte_regexdev/meson.build
index f4db748..1816754 100644
--- a/lib/librte_regexdev/meson.build
+++ b/lib/librte_regexdev/meson.build
@@ -3,5 +3,5 @@
 
 allow_experimental_apis = true
 sources = files('rte_regexdev.c')
-headers = files('rte_regexdev.h')
+headers = files('rte_regexdev.h', 'rte_regexdev_core.h')
 deps += ['mbuf']
diff --git a/lib/librte_regexdev/rte_regexdev.h b/lib/librte_regexdev/rte_regexdev.h
index 7e688d9..bbc56f9 100644
--- a/lib/librte_regexdev/rte_regexdev.h
+++ b/lib/librte_regexdev/rte_regexdev.h
@@ -1466,6 +1466,8 @@ struct rte_regex_ops {
 rte_regexdev_dequeue_burst(uint8_t dev_id, uint16_t qp_id,
 			   struct rte_regex_ops **ops, uint16_t nb_ops);
 
+#include "rte_regexdev_core.h"
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/lib/librte_regexdev/rte_regexdev_core.h b/lib/librte_regexdev/rte_regexdev_core.h
new file mode 100644
index 0000000..fb7a27e
--- /dev/null
+++ b/lib/librte_regexdev/rte_regexdev_core.h
@@ -0,0 +1,160 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2019 Mellanox Corporation
+ */
+
+#ifndef _RTE_REGEX_CORE_H_
+#define _RTE_REGEX_CORE_H_
+
+/**
+ * @file
+ *
+ * RTE RegEx Device internal header.
+ *
+ * This header contains internal data types, that are used by the RegEx devices
+ * in order to expose their ops to the class.
+ *
+ * Applications should not use these API directly.
+ *
+ */
+
+struct rte_regexdev;
+
+typedef int (*regexdev_info_get_t)(struct rte_regexdev *dev,
+				   struct rte_regexdev_info *info);
+/**< @internal Get the RegEx device info. */
+
+typedef int (*regexdev_configure_t)(struct rte_regexdev *dev,
+				    const struct rte_regexdev_config *cfg);
+/**< @internal Configure the RegEx device. */
+
+typedef int (*regexdev_qp_setup_t)(struct rte_regexdev *dev, uint8_t id,
+				   const struct rte_regexdev_qp_conf *qp_conf);
+/**< @internal Setup a queue pair.*/
+
+typedef int (*regexdev_start_t)(struct rte_regexdev *dev);
+/**< @internal Start the RegEx device. */
+
+typedef int (*regexdev_stop_t)(struct rte_regexdev *dev);
+/**< @internal Stop the RegEx device. */
+
+typedef int (*regexdev_close_t)(struct rte_regexdev *dev);
+/**< @internal Close the RegEx device. */
+
+typedef int (*regexdev_attr_get_t)(struct rte_regexdev *dev,
+				   enum rte_regexdev_attr_id id,
+				   void *value);
+/**< @internal Get selected attribute from RegEx device. */
+
+typedef int (*regexdev_attr_set_t)(struct rte_regexdev *dev,
+				   enum rte_regexdev_attr_id id,
+				   const void *value);
+/**< @internal Set selected attribute to RegEx device. */
+
+typedef int (*regexdev_rule_db_update_t)(struct rte_regexdev *dev,
+					 const struct rte_regexdev_rule *rules,
+					 uint16_t nb_rules);
+/**< @internal Update the rule database for the RegEx device. */
+
+typedef int (*regexdev_rule_db_compile_activate_t)(struct rte_regexdev *dev);
+/**< @internal Compile the rule database and activate it. */
+
+typedef int (*regexdev_rule_db_import_t)(struct rte_regexdev *dev,
+					 const char *rule_db,
+					 uint32_t rule_db_len);
+/**< @internal Upload a pre created rule database to the RegEx device. */
+
+typedef int (*regexdev_rule_db_export_t)(struct rte_regexdev *dev,
+					 const char *rule_db);
+/**< @internal Export the current rule database from the RegEx device. */
+
+typedef int (*regexdev_xstats_names_get_t)(struct rte_regexdev *dev,
+					   struct rte_regexdev_xstats_map
+					   *xstats_map);
+/**< @internal Get xstats name map for the RegEx device. */
+
+typedef int (*regexdev_xstats_get_t)(struct rte_regexdev *dev,
+				     const uint16_t *ids, uint64_t *values,
+				     uint16_t nb_values);
+/**< @internal Get xstats values for the RegEx device. */
+
+typedef int (*regexdev_xstats_by_name_get_t)(struct rte_regexdev *dev,
+					     const char *name, uint16_t *id,
+					     uint64_t *value);
+/**< @internal Get xstat value for the RegEx device based on the xstats name. */
+
+typedef int (*regexdev_xstats_reset_t)(struct rte_regexdev *dev,
+				       const uint16_t *ids,
+				       uint16_t nb_ids);
+/**< @internal Reset xstats values for the RegEx device. */
+
+typedef int (*regexdev_selftest_t)(struct rte_regexdev *dev);
+/**< @internal Trigger RegEx self test. */
+
+typedef int (*regexdev_dump_t)(struct rte_regexdev *dev, FILE *f);
+/**< @internal Dump internal information about the RegEx device. */
+
+typedef int (*regexdev_enqueue_t)(struct rte_regexdev *dev, uint16_t qp_id,
+				  struct rte_regex_ops **ops, uint16_t nb_ops);
+/**< @internal Enqueue a burst of scan requests to a queue on RegEx device. */
+
+typedef int (*regexdev_dequeue_t)(struct rte_regexdev *dev, uint16_t qp_id,
+				  struct rte_regex_ops **ops,
+				  uint16_t nb_ops);
+/**< @internal Dequeue a burst of scan response from a queue on RegEx device. */
+
+/**
+ * RegEx device operations
+ */
+struct rte_regexdev_ops {
+	regexdev_info_get_t dev_info_get;
+	regexdev_configure_t dev_configure;
+	regexdev_qp_setup_t dev_qp_setup;
+	regexdev_start_t dev_start;
+	regexdev_stop_t dev_stop;
+	regexdev_close_t dev_close;
+	regexdev_attr_get_t dev_attr_get;
+	regexdev_attr_set_t dev_attr_set;
+	regexdev_rule_db_update_t dev_rule_db_update;
+	regexdev_rule_db_compile_activate_t dev_rule_db_compile_activate;
+	regexdev_rule_db_import_t dev_db_import;
+	regexdev_rule_db_export_t dev_db_export;
+	regexdev_xstats_names_get_t dev_xstats_names_get;
+	regexdev_xstats_get_t dev_xstats_get;
+	regexdev_xstats_by_name_get_t dev_xstats_by_name_get;
+	regexdev_xstats_reset_t dev_xstats_reset;
+	regexdev_selftest_t dev_selftest;
+	regexdev_dump_t dev_dump;
+};
+
+#define RTE_REGEXDEV_NAME_MAX_LEN
+/**
+ * @internal
+ * The data part, with no function pointers, associated with each RegEx device.
+ *
+ * This structure is safe to place in shared memory to be common among different
+ * processes in a multi-process configuration.
+ */
+struct rte_regexdev_data {
+	void *dev_private; /**< PMD-specific private data. */
+} __rte_cache_aligned;
+
+/**
+ * @internal
+ * The generic data structure associated with each RegEx device.
+ *
+ * Pointers to burst-oriented packet receive and transmit functions are
+ * located at the beginning of the structure, along with the pointer to
+ * where all the data elements for the particular device are stored in shared
+ * memory. This split allows the function pointer and driver data to be per-
+ * process, while the actual configuration data for the device is shared.
+ */
+struct rte_regexdev {
+	regexdev_enqueue_t enqueue;
+	regexdev_dequeue_t dequeue;
+	const struct rte_regexdev_ops *dev_ops;
+	/**< Functions exported by PMD */
+	struct rte_device *device; /**< Backing device */
+	struct rte_regexdev_data *data;  /**< Pointer to device data. */
+} __rte_cache_aligned;
+
+#endif /* _RTE_REGEX_CORE_H_ */
-- 
1.8.3.1


^ permalink raw reply	[flat|nested] 96+ messages in thread

* [dpdk-dev] [PATCH v2 3/4] regexdev: add regexdev core functions
  2020-04-17 12:43 ` [dpdk-dev] [PATCH v2 " Ori Kam
  2020-04-17 12:43   ` [dpdk-dev] [PATCH v2 1/4] regexdev: introduce regexdev subsystem Ori Kam
  2020-04-17 12:43   ` [dpdk-dev] [PATCH v2 2/4] regexdev: add regex core h file Ori Kam
@ 2020-04-17 12:43   ` Ori Kam
  2020-04-17 12:43   ` [dpdk-dev] [PATCH v2 4/4] regexdev: implement regex rte level functions Ori Kam
  3 siblings, 0 replies; 96+ messages in thread
From: Ori Kam @ 2020-04-17 12:43 UTC (permalink / raw)
  To: jerinj, xiang.w.wang
  Cc: dev, pbhagavatula, shahafs, hemant.agrawal, opher, alexr, dovrat,
	pkapoor, nipun.gupta, bruce.richardson, yang.a.hong, harry.chang,
	gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai, yuyingxia,
	fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc, jim,
	hongjun.ni, j.bromhead, deri, fc, arthur.su, thomas, orika,
	Parav Pandit

This commit introduce the API that is needed by the RegEx devices in
order to work with the RegEX lib.

During the probe of a RegEx device, the device should configure itself,
and allocate the resources it requires.
On completion of the device init, it should call the
rte_regex_dev_register in order to register itself as a RegEx device.

Signed-off-by: Ori Kam <orika@mellanox.com>
Signed-off-by: Parav Pandit <parav@mellanox.com>
---
v2:
* Changes resulted from previous patch update.
---
 config/common_base                        |   3 +-
 config/meson.build                        |   1 +
 lib/librte_regexdev/Makefile              |   1 +
 lib/librte_regexdev/meson.build           |   5 +-
 lib/librte_regexdev/rte_regexdev.c        | 115 +++++++++++++++++++++++++++++-
 lib/librte_regexdev/rte_regexdev.h        |   7 ++
 lib/librte_regexdev/rte_regexdev_core.h   |  16 ++++-
 lib/librte_regexdev/rte_regexdev_driver.h |  50 +++++++++++++
 meson_options.txt                         |   2 +
 9 files changed, 196 insertions(+), 4 deletions(-)
 create mode 100644 lib/librte_regexdev/rte_regexdev_driver.h

diff --git a/config/common_base b/config/common_base
index 0fc450f..005cb11 100644
--- a/config/common_base
+++ b/config/common_base
@@ -826,9 +826,10 @@ CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_EP_RAWDEV=y
 CONFIG_RTE_LIBRTE_PMD_NTB_RAWDEV=y
 
 #
-# Compile regex device support
+# Compile RexEx device support
 #
 CONFIG_RTE_LIBRTE_REGEXDEV=y
+CONFIG_RTE_MAX_REGEXDEV_DEVS=32
 
 #
 # Compile librte_ring
diff --git a/config/meson.build b/config/meson.build
index 5842134..16dfa74 100644
--- a/config/meson.build
+++ b/config/meson.build
@@ -221,6 +221,7 @@ endforeach
 dpdk_conf.set('RTE_MAX_LCORE', get_option('max_lcores'))
 dpdk_conf.set('RTE_MAX_NUMA_NODES', get_option('max_numa_nodes'))
 dpdk_conf.set('RTE_MAX_ETHPORTS', get_option('max_ethports'))
+dpdk_conf.set('RTE_MAX_REGEXDEV_DEVS', get_option('max_regexdev_devs'))
 dpdk_conf.set('RTE_LIBEAL_USE_HPET', get_option('use_hpet'))
 # values which have defaults which may be overridden
 dpdk_conf.set('RTE_MAX_VFIO_GROUPS', 64)
diff --git a/lib/librte_regexdev/Makefile b/lib/librte_regexdev/Makefile
index 9012d29..6ba09f0 100644
--- a/lib/librte_regexdev/Makefile
+++ b/lib/librte_regexdev/Makefile
@@ -25,6 +25,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_REGEXDEV) := rte_regexdev.c
 # export include files
 SYMLINK-$(CONFIG_RTE_LIBRTE_REGEXDEV)-include += rte_regexdev.h
 SYMLINK-$(CONFIG_RTE_LIBRTE_REGEXDEV)-include += rte_regexdev_core.h
+SYMLINK-$(CONFIG_RTE_LIBRTE_REGEXDEV)-include += rte_regexdev_driver.h
 
 # versioning export map
 EXPORT_MAP := rte_regexdev_version.map
diff --git a/lib/librte_regexdev/meson.build b/lib/librte_regexdev/meson.build
index 1816754..719ee82 100644
--- a/lib/librte_regexdev/meson.build
+++ b/lib/librte_regexdev/meson.build
@@ -1,7 +1,10 @@
 # SPDX-License-Identifier: BSD-3-Clause
 # Copyright(c) 2020 Mellanox Corporation
 
+name = 'regexdev'
 allow_experimental_apis = true
 sources = files('rte_regexdev.c')
-headers = files('rte_regexdev.h', 'rte_regexdev_core.h')
+headers = files('rte_regexdev.h',
+	'rte_regexdev_core.h',
+	'rte_regexdev_driver.h')
 deps += ['mbuf']
diff --git a/lib/librte_regexdev/rte_regexdev.c b/lib/librte_regexdev/rte_regexdev.c
index b901877..10adc54 100644
--- a/lib/librte_regexdev/rte_regexdev.c
+++ b/lib/librte_regexdev/rte_regexdev.c
@@ -3,4 +3,117 @@
  * Copyright(C) 2020 Mellanox International Ltd.
  */
 
-#include <rte_regexdev.h>
+#include <string.h>
+
+#include <rte_memory.h>
+#include <rte_memcpy.h>
+#include <rte_memzone.h>
+#include <rte_string_fns.h>
+
+#include "rte_regexdev.h"
+#include "rte_regexdev_core.h"
+#include "rte_regexdev_driver.h"
+
+static const char *MZ_RTE_REGEXDEV_DATA = "rte_regexdev_data";
+static struct rte_regexdev regex_devices[RTE_MAX_REGEXDEV_DEVS];
+/* Shared memory between primary and secondary processes. */
+static struct {
+	struct rte_regexdev_data data[RTE_MAX_REGEXDEV_DEVS];
+} *rte_regexdev_shared_data;
+
+int rte_regexdev_logtype;
+
+static uint16_t
+regexdev_find_free_dev(void)
+{
+	uint16_t i;
+
+	for (i = 0; i < RTE_MAX_REGEXDEV_DEVS; i++) {
+		if (regex_devices[i].state == RTE_REGEXDEV_UNUSED)
+			return i;
+	}
+	return RTE_MAX_REGEXDEV_DEVS;
+}
+
+static struct rte_regexdev*
+regexdev_allocated(const char *name)
+{
+	uint16_t i;
+
+	for (i = 0; i < RTE_MAX_REGEXDEV_DEVS; i++) {
+		if (regex_devices[i].state != RTE_REGEXDEV_UNUSED)
+			if (!strcmp(name, regex_devices[i].data->dev_name))
+				return &regex_devices[i];
+	}
+	return NULL;
+}
+
+static int
+regexdev_shared_data_prepare(void)
+{
+	const unsigned int flags = 0;
+	const struct rte_memzone *mz;
+
+	if (rte_regexdev_shared_data == NULL) {
+		/* Allocate port data and ownership shared memory. */
+		mz = rte_memzone_reserve(MZ_RTE_REGEXDEV_DATA,
+					 sizeof(*rte_regexdev_shared_data),
+					 rte_socket_id(), flags);
+		if (mz == NULL)
+			return -ENOMEM;
+
+		rte_regexdev_shared_data = mz->addr;
+		memset(rte_regexdev_shared_data->data, 0,
+		       sizeof(rte_regexdev_shared_data->data));
+	}
+	return 0;
+}
+
+struct rte_regexdev *
+rte_regexdev_register(const char *name)
+{
+	uint16_t dev_id;
+	size_t name_len;
+	struct rte_regexdev *dev;
+
+	name_len = strnlen(name, RTE_REGEXDEV_NAME_MAX_LEN);
+	if (name_len == 0) {
+		RTE_REGEXDEV_LOG(ERR, "Zero length RegEx device name\n");
+		return NULL;
+	}
+	if (name_len >= RTE_REGEXDEV_NAME_MAX_LEN) {
+		RTE_REGEXDEV_LOG(ERR, "RegEx device name is too long\n");
+		return NULL;
+	}
+	dev = regexdev_allocated(name);
+	if (dev != NULL) {
+		RTE_REGEXDEV_LOG(ERR, "RegEx device already allocated\n");
+		return NULL;
+	}
+	dev_id = regexdev_find_free_dev();
+	if (dev_id == RTE_MAX_REGEXDEV_DEVS) {
+		RTE_REGEXDEV_LOG
+			(ERR, "Reached maximum number of RegEx devices\n");
+		return NULL;
+	}
+	if (regexdev_shared_data_prepare() < 0) {
+		RTE_REGEXDEV_LOG(ERR, "Cannot allocate RegEx shared data\n");
+		return NULL;
+	}
+
+	dev = &regex_devices[dev_id];
+	dev->state = RTE_REGEXDEV_REGISTERED;
+	if (dev->data == NULL)
+		dev->data = &rte_regexdev_shared_data->data[dev_id];
+	else
+		memset(dev->data, 1, sizeof(*dev->data));
+	dev->data->dev_id = dev_id;
+	strlcpy(dev->data->dev_name, name, sizeof(dev->data->dev_name));
+	return dev;
+}
+
+void
+rte_regexdev_unregister(struct rte_regexdev *dev)
+{
+	dev->state = RTE_REGEXDEV_UNUSED;
+}
diff --git a/lib/librte_regexdev/rte_regexdev.h b/lib/librte_regexdev/rte_regexdev.h
index bbc56f9..1e1ba8b 100644
--- a/lib/librte_regexdev/rte_regexdev.h
+++ b/lib/librte_regexdev/rte_regexdev.h
@@ -206,6 +206,13 @@
 #include <rte_mbuf.h>
 #include <rte_memory.h>
 
+#define RTE_REGEXDEV_NAME_MAX_LEN RTE_DEV_NAME_MAX_LEN
+
+extern int rte_regexdev_logtype;
+
+#define RTE_REGEXDEV_LOG(level, ...) \
+	rte_log(RTE_LOG_ ## level, rte_regexdev_logtype, "" __VA_ARGS__)
+
 /**
  * @warning
  * @b EXPERIMENTAL: this API may change without prior notice.
diff --git a/lib/librte_regexdev/rte_regexdev_core.h b/lib/librte_regexdev/rte_regexdev_core.h
index fb7a27e..baded23 100644
--- a/lib/librte_regexdev/rte_regexdev_core.h
+++ b/lib/librte_regexdev/rte_regexdev_core.h
@@ -126,7 +126,18 @@ struct rte_regexdev_ops {
 	regexdev_dump_t dev_dump;
 };
 
-#define RTE_REGEXDEV_NAME_MAX_LEN
+/**
+ * @internal
+ * Possible states of a RegEx device.
+ */
+enum rte_regexdev_state {
+	RTE_REGEXDEV_UNUSED = 0, /**< Device is unused. */
+	RTE_REGEXDEV_REGISTERED,
+	/**< Device is registered, but not ready to be used. */
+	RTE_REGEXDEV_READY,
+	/**< Device is ready for use. This is set by the PMD. */
+};
+
 /**
  * @internal
  * The data part, with no function pointers, associated with each RegEx device.
@@ -136,6 +147,8 @@ struct rte_regexdev_ops {
  */
 struct rte_regexdev_data {
 	void *dev_private; /**< PMD-specific private data. */
+	char dev_name[RTE_REGEXDEV_NAME_MAX_LEN]; /**< Unique identifier name */
+	uint16_t dev_id; /**< Device [external]  identifier. */
 } __rte_cache_aligned;
 
 /**
@@ -154,6 +167,7 @@ struct rte_regexdev {
 	const struct rte_regexdev_ops *dev_ops;
 	/**< Functions exported by PMD */
 	struct rte_device *device; /**< Backing device */
+	enum rte_regexdev_state state; /**< The device state. */
 	struct rte_regexdev_data *data;  /**< Pointer to device data. */
 } __rte_cache_aligned;
 
diff --git a/lib/librte_regexdev/rte_regexdev_driver.h b/lib/librte_regexdev/rte_regexdev_driver.h
new file mode 100644
index 0000000..6a510d2
--- /dev/null
+++ b/lib/librte_regexdev/rte_regexdev_driver.h
@@ -0,0 +1,50 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2020 Mellanox Corporation
+ */
+
+#ifndef _RTE_REGEXDEV_DRIVER_H_
+#define _RTE_REGEXDEV_DRIVER_H_
+
+/**
+ * @file
+ *
+ * RTE RegEx Device PMD API
+ *
+ * APIs that are used by the RegEx drivers, to comunicate with the
+ * RegEx lib.
+ */
+
+#include "rte_regexdev.h"
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/**
+ * @internal
+ * Register a RegEx device slot for a RegEx device and return the
+ * pointer to that slot.
+ *
+ * @param name
+ *   RegEx device name.
+ *
+ * @return
+ *   A pointer to the RegEx device slot case of success,
+ *   NULL otherwise.
+ */
+struct rte_regexdev *rte_regexdev_register(const char *name);
+
+/**
+ * @internal
+ * Unregister the specified regexdev port.
+ *
+ * @param dev
+ *   Device to be released.
+ */
+void rte_regexdev_unregister(struct rte_regexdev *dev);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_REGEXDEV_DRIVER_H_ */
diff --git a/meson_options.txt b/meson_options.txt
index 9e4923a..7e54d8a 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -30,6 +30,8 @@ option('max_lcores', type: 'integer', value: 128,
 	description: 'maximum number of cores/threads supported by EAL')
 option('max_numa_nodes', type: 'integer', value: 4,
 	description: 'maximum number of NUMA nodes supported by EAL')
+option('max_regexdev_devs', type: 'integer', value: 32,
+	description: 'maximum number of RegEx devices')
 option('tests', type: 'boolean', value: true,
 	description: 'build unit tests')
 option('use_hpet', type: 'boolean', value: false,
-- 
1.8.3.1


^ permalink raw reply	[flat|nested] 96+ messages in thread

* [dpdk-dev] [PATCH v2 4/4] regexdev: implement regex rte level functions
  2020-04-17 12:43 ` [dpdk-dev] [PATCH v2 " Ori Kam
                     ` (2 preceding siblings ...)
  2020-04-17 12:43   ` [dpdk-dev] [PATCH v2 3/4] regexdev: add regexdev core functions Ori Kam
@ 2020-04-17 12:43   ` Ori Kam
  2020-04-21 11:12     ` Guy Kaneti
  2020-04-21 11:36     ` Guy Kaneti
  3 siblings, 2 replies; 96+ messages in thread
From: Ori Kam @ 2020-04-17 12:43 UTC (permalink / raw)
  To: jerinj, xiang.w.wang
  Cc: dev, pbhagavatula, shahafs, hemant.agrawal, opher, alexr, dovrat,
	pkapoor, nipun.gupta, bruce.richardson, yang.a.hong, harry.chang,
	gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai, yuyingxia,
	fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc, jim,
	hongjun.ni, j.bromhead, deri, fc, arthur.su, thomas, orika

This commit implements all the RegEx public API.

Signed-off-by: Ori Kam <orika@mellanox.com>
---
v2:
* Changes based on changes in previous patch.
* Add check to configuration function.
* Replace checks with macros.
* Move enqueue and dequeue to inline.
---
 config/common_base                      |   1 +
 lib/librte_regexdev/rte_regexdev.c      | 442 +++++++++++++++++++++++++++++++-
 lib/librte_regexdev/rte_regexdev.h      |  68 ++++-
 lib/librte_regexdev/rte_regexdev_core.h |   9 +
 4 files changed, 506 insertions(+), 14 deletions(-)

diff --git a/config/common_base b/config/common_base
index 005cb11..b4ab3a4 100644
--- a/config/common_base
+++ b/config/common_base
@@ -829,6 +829,7 @@ CONFIG_RTE_LIBRTE_PMD_NTB_RAWDEV=y
 # Compile RexEx device support
 #
 CONFIG_RTE_LIBRTE_REGEXDEV=y
+CONFIG_RTE_LIBRTE_REGEXDEV_DEBUG=n
 CONFIG_RTE_MAX_REGEXDEV_DEVS=32
 
 #
diff --git a/lib/librte_regexdev/rte_regexdev.c b/lib/librte_regexdev/rte_regexdev.c
index 10adc54..d469094 100644
--- a/lib/librte_regexdev/rte_regexdev.c
+++ b/lib/librte_regexdev/rte_regexdev.c
@@ -15,7 +15,7 @@
 #include "rte_regexdev_driver.h"
 
 static const char *MZ_RTE_REGEXDEV_DATA = "rte_regexdev_data";
-static struct rte_regexdev regex_devices[RTE_MAX_REGEXDEV_DEVS];
+struct rte_regexdev rte_regex_devices[RTE_MAX_REGEXDEV_DEVS];
 /* Shared memory between primary and secondary processes. */
 static struct {
 	struct rte_regexdev_data data[RTE_MAX_REGEXDEV_DEVS];
@@ -29,7 +29,7 @@
 	uint16_t i;
 
 	for (i = 0; i < RTE_MAX_REGEXDEV_DEVS; i++) {
-		if (regex_devices[i].state == RTE_REGEXDEV_UNUSED)
+		if (rte_regex_devices[i].state == RTE_REGEXDEV_UNUSED)
 			return i;
 	}
 	return RTE_MAX_REGEXDEV_DEVS;
@@ -41,9 +41,9 @@
 	uint16_t i;
 
 	for (i = 0; i < RTE_MAX_REGEXDEV_DEVS; i++) {
-		if (regex_devices[i].state != RTE_REGEXDEV_UNUSED)
-			if (!strcmp(name, regex_devices[i].data->dev_name))
-				return &regex_devices[i];
+		if (rte_regex_devices[i].state != RTE_REGEXDEV_UNUSED)
+			if (!strcmp(name, rte_regex_devices[i].data->dev_name))
+				return &rte_regex_devices[i];
 	}
 	return NULL;
 }
@@ -101,7 +101,7 @@ struct rte_regexdev *
 		return NULL;
 	}
 
-	dev = &regex_devices[dev_id];
+	dev = &rte_regex_devices[dev_id];
 	dev->state = RTE_REGEXDEV_REGISTERED;
 	if (dev->data == NULL)
 		dev->data = &rte_regexdev_shared_data->data[dev_id];
@@ -117,3 +117,433 @@ struct rte_regexdev *
 {
 	dev->state = RTE_REGEXDEV_UNUSED;
 }
+
+uint8_t
+rte_regexdev_count(void)
+{
+	int i;
+	int count = 0;
+
+	for (i = 0; i < RTE_MAX_REGEXDEV_DEVS; i++) {
+		if (rte_regex_devices[i].state != RTE_REGEXDEV_UNUSED)
+			count++;
+	}
+	return count;
+}
+
+int
+rte_regexdev_get_dev_id(const char *name)
+{
+	int i;
+	int id = -EINVAL;
+
+	if (name == NULL)
+		return -EINVAL;
+	for (i = 0; i < RTE_MAX_REGEXDEV_DEVS; i++) {
+		if (rte_regex_devices[i].state != RTE_REGEXDEV_UNUSED)
+			if (strcmp(name, rte_regex_devices[i].data->dev_name)) {
+				id = rte_regex_devices[i].data->dev_id;
+				break;
+			}
+	}
+	return id;
+}
+
+int
+rte_regexdev_is_valid_dev(uint16_t dev_id)
+{
+	if (dev_id >= RTE_MAX_REGEXDEV_DEVS ||
+	    rte_regex_devices[dev_id].state != RTE_REGEXDEV_READY)
+		return 0;
+	return 1;
+}
+
+static int
+regexdev_info_get(uint8_t dev_id, struct rte_regexdev_info *dev_info)
+{
+	struct rte_regexdev *dev;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	if (dev_info == NULL)
+		return -EINVAL;
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_info_get, -ENOTSUP);
+	return (*dev->dev_ops->dev_info_get)(dev, dev_info);
+
+}
+
+int
+rte_regexdev_info_get(uint8_t dev_id, struct rte_regexdev_info *dev_info)
+{
+	return regexdev_info_get(dev_id, dev_info);
+}
+
+int
+rte_regexdev_configure(uint8_t dev_id, const struct rte_regexdev_config *cfg)
+{
+	struct rte_regexdev *dev;
+	struct rte_regexdev_info dev_info;
+	int ret;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	if (cfg == NULL)
+		return -EINVAL;
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_configure, -ENOTSUP);
+	if (dev->data->dev_started) {
+		RTE_REGEXDEV_LOG
+			(ERR, "Dev %u must be stopped to allow configuration\n",
+			 dev_id);
+		return -EBUSY;
+	}
+	ret = regexdev_info_get(dev_id, &dev_info);
+	if (ret < 0)
+		return ret;
+	if ((cfg->dev_cfg_flags & RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F) &&
+	    !(dev_info.regexdev_capa & RTE_REGEXDEV_SUPP_CROSS_BUFFER_F)) {
+		RTE_REGEXDEV_LOG(ERR,
+				 "Dev %u doesn't support cross buffer scan\n",
+				 dev_id);
+		return -EINVAL;
+	}
+	if ((cfg->dev_cfg_flags & RTE_REGEXDEV_CFG_MATCH_AS_END_F) &&
+	    !(dev_info.regexdev_capa & RTE_REGEXDEV_SUPP_MATCH_AS_END_F)) {
+		RTE_REGEXDEV_LOG(ERR,
+				 "Dev %u doesn't support match as end\n",
+				 dev_id);
+		return -EINVAL;
+	}
+	if ((cfg->dev_cfg_flags & RTE_REGEXDEV_CFG_MATCH_ALL_F) &&
+	    !(dev_info.regexdev_capa & RTE_REGEXDEV_SUPP_MATCH_ALL_F)) {
+		RTE_REGEXDEV_LOG(ERR,
+				 "Dev %u doesn't support match all\n",
+				 dev_id);
+		return -EINVAL;
+	}
+	if (cfg->nb_groups == 0) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %u num of groups must be > 0\n",
+				 dev_id);
+		return -EINVAL;
+	}
+	if (cfg->nb_groups >= dev_info.max_groups) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %u num of groups %d > %d\n",
+				 dev_id, cfg->nb_groups, dev_info.max_groups);
+		return -EINVAL;
+	}
+	if (cfg->nb_max_matches == 0) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %u num of matches must be > 0\n",
+				 dev_id);
+		return -EINVAL;
+	}
+	if (cfg->nb_max_matches >= dev_info.max_matches) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %u num of matches %d > %d\n",
+				 dev_id, cfg->nb_max_matches,
+				 dev_info.max_matches);
+		return -EINVAL;
+	}
+	if (cfg->nb_queue_pairs == 0) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %u num of queues must be > 0\n",
+				 dev_id);
+		return -EINVAL;
+	}
+	if (cfg->nb_queue_pairs >= dev_info.max_queue_pairs) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %u num of queues %d > %d\n",
+				 dev_id, cfg->nb_queue_pairs,
+				 dev_info.max_queue_pairs);
+		return -EINVAL;
+	}
+	if (cfg->nb_rules_per_group == 0) {
+		RTE_REGEXDEV_LOG(ERR,
+				 "Dev %u num of rules per group must be > 0\n",
+				 dev_id);
+		return -EINVAL;
+	}
+	if (cfg->nb_rules_per_group >= dev_info.max_rules_per_group) {
+		RTE_REGEXDEV_LOG(ERR,
+				 "Dev %u num of rules per group %d > %d\n",
+				 dev_id, cfg->nb_rules_per_group,
+				 dev_info.max_rules_per_group);
+		return -EINVAL;
+	}
+	ret = (*dev->dev_ops->dev_configure)(dev, cfg);
+	if (ret == 0)
+		dev->data->dev_conf = *cfg;
+	return ret;
+}
+
+int
+rte_regexdev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
+			   const struct rte_regexdev_qp_conf *qp_conf)
+{
+	struct rte_regexdev *dev;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_qp_setup, -ENOTSUP);
+	if (dev->data->dev_started) {
+		RTE_REGEXDEV_LOG
+			(ERR, "Dev %u must be stopped to allow configuration\n",
+			 dev_id);
+		return -EBUSY;
+	}
+	if (queue_pair_id >= dev->data->dev_conf.nb_queue_pairs) {
+		RTE_REGEXDEV_LOG(ERR,
+				 "Dev %u invalid queue %d > %d\n",
+				 dev_id, queue_pair_id,
+				 dev->data->dev_conf.nb_queue_pairs);
+		return -EINVAL;
+	}
+	if (dev->data->dev_started) {
+		RTE_REGEXDEV_LOG
+			(ERR, "Dev %u must be stopped to allow configuration\n",
+			 dev_id);
+		return -EBUSY;
+	}
+	return (*dev->dev_ops->dev_qp_setup)(dev, queue_pair_id, qp_conf);
+}
+
+int
+rte_regexdev_start(uint8_t dev_id)
+{
+	struct rte_regexdev *dev;
+	int ret;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_start, -ENOTSUP);
+	ret = (*dev->dev_ops->dev_start)(dev);
+	if (ret == 0)
+		dev->data->dev_started = 1;
+	return ret;
+}
+
+int
+rte_regexdev_stop(uint8_t dev_id)
+{
+	struct rte_regexdev *dev;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_stop, -ENOTSUP);
+	(*dev->dev_ops->dev_stop)(dev);
+	dev->data->dev_started = 0;
+	return 0;
+}
+
+int
+rte_regexdev_close(uint8_t dev_id)
+{
+	struct rte_regexdev *dev;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_close, -ENOTSUP);
+	(*dev->dev_ops->dev_close)(dev);
+	dev->data->dev_started = 0;
+	dev->state = RTE_REGEXDEV_UNUSED;
+	return 0;
+}
+
+int
+rte_regexdev_attr_get(uint8_t dev_id, enum rte_regexdev_attr_id attr_id,
+		      void *attr_value)
+{
+	struct rte_regexdev *dev;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_attr_get, -ENOTSUP);
+	if (attr_value == NULL) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %d attribute value can't be NULL\n",
+				 dev_id);
+		return -EINVAL;
+	}
+	return (*dev->dev_ops->dev_attr_get)(dev, attr_id, attr_value);
+}
+
+int
+rte_regexdev_attr_set(uint8_t dev_id, enum rte_regexdev_attr_id attr_id,
+		      const void *attr_value)
+{
+	struct rte_regexdev *dev;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_attr_set, -ENOTSUP);
+	if (attr_value == NULL) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %d attribute value can't be NULL\n",
+				 dev_id);
+		return -EINVAL;
+	}
+	return (*dev->dev_ops->dev_attr_set)(dev, attr_id, attr_value);
+}
+
+int
+rte_regexdev_rule_db_update(uint8_t dev_id,
+			    const struct rte_regexdev_rule *rules,
+			    uint32_t nb_rules)
+{
+	struct rte_regexdev *dev;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_rule_db_update, -ENOTSUP);
+	if (rules == NULL) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %d rules can't be NULL\n",
+				 dev_id);
+		return -EINVAL;
+	}
+	return (*dev->dev_ops->dev_rule_db_update)(dev, rules, nb_rules);
+}
+
+int
+rte_regexdev_rule_db_compile_activate(uint8_t dev_id)
+{
+	struct rte_regexdev *dev;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_rule_db_compile_activate,
+				-ENOTSUP);
+	return (*dev->dev_ops->dev_rule_db_compile_activate)(dev);
+}
+
+int
+rte_regexdev_rule_db_import(uint8_t dev_id, const char *rule_db,
+			    uint32_t rule_db_len)
+{
+	struct rte_regexdev *dev;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_db_import,
+				-ENOTSUP);
+	if (rule_db == NULL) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %d rules can't be NULL\n",
+				 dev_id);
+		return -EINVAL;
+	}
+	return (*dev->dev_ops->dev_db_import)(dev, rule_db, rule_db_len);
+}
+
+int
+rte_regexdev_rule_db_export(uint8_t dev_id, char *rule_db)
+{
+	struct rte_regexdev *dev;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_db_export,
+				-ENOTSUP);
+	if (rule_db == NULL) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %d rules can't be NULL\n",
+				 dev_id);
+		return -EINVAL;
+	}
+	return (*dev->dev_ops->dev_db_export)(dev, rule_db);
+}
+
+int
+rte_regexdev_xstats_names_get(uint8_t dev_id,
+			      struct rte_regexdev_xstats_map *xstats_map)
+{
+	struct rte_regexdev *dev;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_xstats_names_get,
+				-ENOTSUP);
+	if (xstats_map == NULL) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %d xstats map can't be NULL\n",
+				 dev_id);
+		return -EINVAL;
+	}
+	return (*dev->dev_ops->dev_xstats_names_get)(dev, xstats_map);
+}
+
+int
+rte_regexdev_xstats_get(uint8_t dev_id, const uint16_t *ids,
+			uint64_t *values, uint16_t n)
+{
+	struct rte_regexdev *dev;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_xstats_get, -ENOTSUP);
+	if (ids == NULL) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %d ids can't be NULL\n", dev_id);
+		return -EINVAL;
+	}
+	if (values == NULL) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %d values can't be NULL\n", dev_id);
+		return -EINVAL;
+	}
+	return (*dev->dev_ops->dev_xstats_get)(dev, ids, values, n);
+}
+
+int
+rte_regexdev_xstats_by_name_get(uint8_t dev_id, const char *name,
+				uint16_t *id, uint64_t *value)
+{
+	struct rte_regexdev *dev;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_xstats_by_name_get,
+				-ENOTSUP);
+	if (name == NULL) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %d name can't be NULL\n", dev_id);
+		return -EINVAL;
+	}
+	if (id == NULL) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %d id can't be NULL\n", dev_id);
+		return -EINVAL;
+	}
+	if (value == NULL) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %d value can't be NULL\n", dev_id);
+		return -EINVAL;
+	}
+	return (*dev->dev_ops->dev_xstats_by_name_get)(dev, name, id, value);
+}
+
+int
+rte_regexdev_xstats_reset(uint8_t dev_id, const uint16_t *ids,
+			  uint16_t nb_ids)
+{
+	struct rte_regexdev *dev;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_xstats_reset, -ENOTSUP);
+	if (ids == NULL) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %d ids can't be NULL\n", dev_id);
+		return -EINVAL;
+	}
+	return (*dev->dev_ops->dev_xstats_reset)(dev, ids, nb_ids);
+}
+
+int
+rte_regexdev_selftest(uint8_t dev_id)
+{
+	struct rte_regexdev *dev;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_selftest, -ENOTSUP);
+	return (*dev->dev_ops->dev_selftest)(dev);
+}
+
+int
+rte_regexdev_dump(uint8_t dev_id, FILE *f)
+{
+	struct rte_regexdev *dev;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_dump, -ENOTSUP);
+	if (f == NULL) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %d file can't be NULL\n", dev_id);
+		return -EINVAL;
+	}
+	return (*dev->dev_ops->dev_dump)(dev, f);
+}
diff --git a/lib/librte_regexdev/rte_regexdev.h b/lib/librte_regexdev/rte_regexdev.h
index 1e1ba8b..f87b1f9 100644
--- a/lib/librte_regexdev/rte_regexdev.h
+++ b/lib/librte_regexdev/rte_regexdev.h
@@ -213,6 +213,33 @@
 #define RTE_REGEXDEV_LOG(level, ...) \
 	rte_log(RTE_LOG_ ## level, rte_regexdev_logtype, "" __VA_ARGS__)
 
+/* Macros to check for valid port */
+#define RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, retval) do { \
+	if (!rte_regexdev_is_valid_dev(dev_id)) { \
+		RTE_REGEXDEV_LOG(ERR, "Invalid dev_id=%u\n", dev_id); \
+		return retval; \
+	} \
+} while (0)
+
+#define RTE_REGEXDEV_VALID_DEV_ID_OR_RET(dev_id) do { \
+	if (!rte_regexdev_is_valid_dev(dev_id)) { \
+		RTE_REGEXDEV_LOG(ERR, "Invalid dev_id=%u\n", dev_id); \
+		return; \
+	} \
+} while (0)
+
+/**
+ * Check if dev_id is ready.
+ *
+ * @param dev_id
+ *   The dev identifier of the RegEx device.
+ *
+ * @return
+ *   - 0 if device state is not in ready state.
+ *   - 1 if device state is ready state.
+ */
+int rte_regexdev_is_valid_dev(uint16_t dev_id);
+
 /**
  * @warning
  * @b EXPERIMENTAL: this API may change without prior notice.
@@ -803,10 +830,11 @@ struct rte_regexdev_qp_conf {
  * @param dev_id
  *   RegEx device identifier.
  *
- * @see struct rte_regexdev_qp_conf::cb, rte_regexdev_queue_pair_setup()
+ * @return
+ *   0 on success. Otherwise negative errno is returned.
  */
 __rte_experimental
-void
+int
 rte_regexdev_stop(uint8_t dev_id);
 
 /**
@@ -1384,6 +1412,8 @@ struct rte_regex_ops {
 	 */
 };
 
+#include "rte_regexdev_core.h"
+
 /**
  * @warning
  * @b EXPERIMENTAL: this API may change without prior notice.
@@ -1422,9 +1452,21 @@ struct rte_regex_ops {
  *   to take care of them.
  */
 __rte_experimental
-uint16_t
+static inline uint16_t
 rte_regexdev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
-			   struct rte_regex_ops **ops, uint16_t nb_ops);
+			   struct rte_regex_ops **ops, uint16_t nb_ops)
+{
+	struct rte_regexdev *dev = &rte_regex_devices[dev_id];
+#ifdef RTE_LIBRTE_REGEXDEV_DEBUG
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->enqueue, -ENOTSUP);
+	if (qp_id >= dev->data->dev_conf.nb_queue_pairs) {
+		RTE_REGEXDEV_LOG(ERR, "Invalid queue %d\n", qp_id);
+		return -EINVAL;
+	}
+#endif
+	return (*dev->enqueue)(dev, qp_id, ops, nb_ops);
+}
 
 /**
  * @warning
@@ -1469,11 +1511,21 @@ struct rte_regex_ops {
  *   of them.
  */
 __rte_experimental
-uint16_t
+static inline uint16_t
 rte_regexdev_dequeue_burst(uint8_t dev_id, uint16_t qp_id,
-			   struct rte_regex_ops **ops, uint16_t nb_ops);
-
-#include "rte_regexdev_core.h"
+			   struct rte_regex_ops **ops, uint16_t nb_ops)
+{
+	struct rte_regexdev *dev = &rte_regex_devices[dev_id];
+#ifdef RTE_LIBRTE_REGEXDEV_DEBUG
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dequeue, -ENOTSUP);
+	if (qp_id >= dev->data->dev_conf.nb_queue_pairs) {
+		RTE_REGEXDEV_LOG(ERR, "Invalid queue %d\n", qp_id);
+		return -EINVAL;
+	}
+#endif
+	return (*dev->dequeue)(dev, qp_id, ops, nb_ops);
+}
 
 #ifdef __cplusplus
 }
diff --git a/lib/librte_regexdev/rte_regexdev_core.h b/lib/librte_regexdev/rte_regexdev_core.h
index baded23..c748de4 100644
--- a/lib/librte_regexdev/rte_regexdev_core.h
+++ b/lib/librte_regexdev/rte_regexdev_core.h
@@ -149,6 +149,8 @@ struct rte_regexdev_data {
 	void *dev_private; /**< PMD-specific private data. */
 	char dev_name[RTE_REGEXDEV_NAME_MAX_LEN]; /**< Unique identifier name */
 	uint16_t dev_id; /**< Device [external]  identifier. */
+	struct rte_regexdev_config dev_conf; /**< RegEx configuration. */
+	uint8_t dev_started : 1; /**< Device started to work. */
 } __rte_cache_aligned;
 
 /**
@@ -171,4 +173,11 @@ struct rte_regexdev {
 	struct rte_regexdev_data *data;  /**< Pointer to device data. */
 } __rte_cache_aligned;
 
+/**
+ * @internal
+ * The pool of *rte_regexdev* structures. The size of the pool
+ * is configured at compile-time in the <rte_regexdev.c> file.
+ */
+extern struct rte_regexdev rte_regex_devices[];
+
 #endif /* _RTE_REGEX_CORE_H_ */
-- 
1.8.3.1


^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core functions
  2020-04-08  8:39               ` Ori Kam
@ 2020-04-19 10:38                 ` Guy Kaneti
  2020-04-22 21:36                   ` Ori Kam
  0 siblings, 1 reply; 96+ messages in thread
From: Guy Kaneti @ 2020-04-19 10:38 UTC (permalink / raw)
  To: Ori Kam, Thomas Monjalon, Jerin Jacob Kollanukkaran,
	xiang.w.wang, Pavan Nikhilesh Bhagavatula
  Cc: dev, Shahaf Shuler, hemant.agrawal, Opher Reviv, Alex Rosenbaum,
	Dovrat Zifroni, Prasun Kapoor, nipun.gupta, bruce.richardson,
	yang.a.hong, harry.chang, gu.jian1, shanjiangh, zhangy.yun,
	lixingfu, wushuai, yuyingxia, fanchenggang, davidfgao, liuzhong1,
	zhaoyong11, oc, jim, hongjun.ni, j.bromhead, deri, fc, arthur.su,
	Parav Pandit



> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Ori Kam
> Sent: Wednesday, April 08, 2020 11:40 AM
> To: Thomas Monjalon <thomas@monjalon.net>; Jerin Jacob Kollanukkaran
> <jerinj@marvell.com>; xiang.w.wang@intel.com; Pavan Nikhilesh
> Bhagavatula <pbhagavatula@marvell.com>
> Cc: dev@dpdk.org; Shahaf Shuler <shahafs@mellanox.com>;
> hemant.agrawal@nxp.com; Opher Reviv <opher@mellanox.com>; Alex
> Rosenbaum <alexr@mellanox.com>; Dovrat Zifroni <dovrat@marvell.com>;
> Prasun Kapoor <pkapoor@marvell.com>; nipun.gupta@nxp.com;
> bruce.richardson@intel.com; yang.a.hong@intel.com;
> harry.chang@intel.com; gu.jian1@zte.com.cn; shanjiangh@chinatelecom.cn;
> zhangy.yun@chinatelecom.cn; lixingfu@huachentel.com;
> wushuai@inspur.com; yuyingxia@yxlink.com;
> fanchenggang@sunyainfo.com; davidfgao@tencent.com;
> liuzhong1@chinaunicom.cn; zhaoyong11@huawei.com; oc@yunify.com;
> jim@netgate.com; hongjun.ni@intel.com; j.bromhead@titan-ic.com;
> deri@ntop.org; fc@napatech.com; arthur.su@lionic.com; Parav Pandit
> <parav@mellanox.com>
> Subject: Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core
> functions
> 
> 
> 
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Thomas Monjalon
> > Sent: Monday, April 6, 2020 4:30 PM
> > To: Ori Kam <orika@mellanox.com>; Jerin Jacob Kollanukkaran
> > <jerinj@marvell.com>; xiang.w.wang@intel.com; Pavan Nikhilesh
> > Bhagavatula <pbhagavatula@marvell.com>
> > Cc: dev@dpdk.org; Shahaf Shuler <shahafs@mellanox.com>;
> > hemant.agrawal@nxp.com; Opher Reviv <opher@mellanox.com>; Alex
> > Rosenbaum <alexr@mellanox.com>; Dovrat Zifroni
> <dovrat@marvell.com>;
> > Prasun Kapoor <pkapoor@marvell.com>; nipun.gupta@nxp.com;
> > bruce.richardson@intel.com; yang.a.hong@intel.com;
> > harry.chang@intel.com; gu.jian1@zte.com.cn;
> > shanjiangh@chinatelecom.cn; zhangy.yun@chinatelecom.cn;
> > lixingfu@huachentel.com; wushuai@inspur.com; yuyingxia@yxlink.com;
> > fanchenggang@sunyainfo.com; davidfgao@tencent.com;
> > liuzhong1@chinaunicom.cn; zhaoyong11@huawei.com; oc@yunify.com;
> > jim@netgate.com; hongjun.ni@intel.com; j.bromhead@titan-ic.com;
> > deri@ntop.org; fc@napatech.com; arthur.su@lionic.com; Parav Pandit
> > <parav@mellanox.com>
> > Subject: Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev
> > core functions
> >
> > 06/04/2020 14:48, Pavan Nikhilesh Bhagavatula:
> > > > From: Pavan Nikhilesh Bhagavatula
> > > >> >> From: Pavan Nikhilesh Bhagavatula
> > > >> >>
> > > >> >> Looks like this implementation is incomplete?
> > > >> >> I don't see any pmd specific helper functions for @see
> > > >> >rte_cryptodev_pmd.c,
> > > >> >> rte_eventdev_pmd*
> > > >> >>
> > > >> >I think the current implementation includes all needed
> > > >> >functions, at least for the first stage.
> > > >> >You can find in rte_regexdev_driver.h the functions that should
> > > >> >be called by the PMD. We have the register / unregister which
> > > >> >acts the same
> > > >as
> > > >> >create
> > > >> >and destroy. For parsing argument the PMD may call
> > > >rte_kvargs_parse.
> > > >> >
> > > >>
> > > >> _driver.h should atleast include
> > > >> rte_regex_dev_pci_generic_probe/rte_regex_pmd_vdev_init
> > > >> else there would be a lot of code repetition and possibly
> > > >> udefined
> > > >behavior
> > > >> at the driver layer.
> > > >>
> > > >Why should they be included? At least in this stage, there is no
> > > >code to share ethdev why should we add code for the vdev?
> > >
> > > Ok I think I failed to communicate my concerns across.
> > > Let me retry
> > >
> > > 1. SW based regex devices such as PCRE/Hyperscan rely on vdev
> > > framework i.e. user needs to pass an EAL argument
> > > --vdev="regex_pcre" for the driver to initialize all the other EAL
> > > subsystems (ethdev, eventdev, cryptodev,
> > etc..)support this.
> >
> > vdev helpers do not have to be part of the first patches which define API.
> > It should be added when adding the first vdev driver.
> >
> > > 2. HW based independent regex devices that are exposed as PCI
> > > devices
> > would need
> > >  pci probe helpers.
> >
> > Same, PCI helpers can be added while adding the first PCI driver.
> >
> > We can synchronize about how to split the work, avoiding two
> > developers doing the same thing. But let's not mandate this work to be
> > done as part of this first series.
> >
> >
> I agree with Thomas, let's discuss this when adding the PMDs.

I am writing a now the Marvell OcteonTx2 PMD and I think that a PCI helper is missing.
When registering a PCI device, a .remove function is registered of type pci_remove_t *remove;

typedef int (pci_remove_t)(struct rte_pci_device *);
because this function receives struct rte_pci_device * as an argument 
It is required to have a helper function to retrieve struct rte_regexdev *dev based on the device name (or another way).
similar to rte_cryptodev_pmd_get_named_dev(const char *name)

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [PATCH v2 2/4] regexdev: add regex core h file
  2020-04-17 12:43   ` [dpdk-dev] [PATCH v2 2/4] regexdev: add regex core h file Ori Kam
@ 2020-04-20 10:48     ` Guy Kaneti
  2020-04-20 15:49       ` Ori Kam
  0 siblings, 1 reply; 96+ messages in thread
From: Guy Kaneti @ 2020-04-20 10:48 UTC (permalink / raw)
  To: Ori Kam, Jerin Jacob Kollanukkaran, xiang.w.wang
  Cc: dev, Pavan Nikhilesh Bhagavatula, shahafs, hemant.agrawal, opher,
	alexr, Dovrat Zifroni, Prasun Kapoor, nipun.gupta,
	bruce.richardson, yang.a.hong, harry.chang, gu.jian1, shanjiangh,
	zhangy.yun, lixingfu, wushuai, yuyingxia, fanchenggang,
	davidfgao, liuzhong1, zhaoyong11, oc, jim, hongjun.ni,
	j.bromhead, deri, fc, arthur.su, thomas

Hi,


> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Ori Kam
> Sent: Friday, April 17, 2020 3:44 PM
> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>;
> xiang.w.wang@intel.com
> Cc: dev@dpdk.org; Pavan Nikhilesh Bhagavatula
> <pbhagavatula@marvell.com>; shahafs@mellanox.com;
> hemant.agrawal@nxp.com; opher@mellanox.com; alexr@mellanox.com;
> Dovrat Zifroni <dovrat@marvell.com>; Prasun Kapoor
> <pkapoor@marvell.com>; nipun.gupta@nxp.com;
> bruce.richardson@intel.com; yang.a.hong@intel.com;
> harry.chang@intel.com; gu.jian1@zte.com.cn; shanjiangh@chinatelecom.cn;
> zhangy.yun@chinatelecom.cn; lixingfu@huachentel.com;
> wushuai@inspur.com; yuyingxia@yxlink.com;
> fanchenggang@sunyainfo.com; davidfgao@tencent.com;
> liuzhong1@chinaunicom.cn; zhaoyong11@huawei.com; oc@yunify.com;
> jim@netgate.com; hongjun.ni@intel.com; j.bromhead@titan-ic.com;
> deri@ntop.org; fc@napatech.com; arthur.su@lionic.com;
> thomas@monjalon.net; orika@mellanox.com
> Subject: [dpdk-dev] [PATCH v2 2/4] regexdev: add regex core h file
> 
> This commit introduce the rte_regexdev_core.h file.
> This file holds internal structures and API that are used by the regexdev.
> 
> Signed-off-by: Ori Kam <orika@mellanox.com>
> ---
> v2:
> * Move private data to rte_regexdev struct.
> ---
>  lib/librte_regexdev/Makefile            |   1 +
>  lib/librte_regexdev/meson.build         |   2 +-
>  lib/librte_regexdev/rte_regexdev.h      |   2 +
>  lib/librte_regexdev/rte_regexdev_core.h | 160
> ++++++++++++++++++++++++++++++++
>  4 files changed, 164 insertions(+), 1 deletion(-)  create mode 100644
> lib/librte_regexdev/rte_regexdev_core.h
> 
> diff --git a/lib/librte_regexdev/Makefile b/lib/librte_regexdev/Makefile
> index 6f4cc63..9012d29 100644
> --- a/lib/librte_regexdev/Makefile
> +++ b/lib/librte_regexdev/Makefile
> @@ -24,6 +24,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_REGEXDEV) :=
> rte_regexdev.c
> 
>  # export include files
>  SYMLINK-$(CONFIG_RTE_LIBRTE_REGEXDEV)-include += rte_regexdev.h
> +SYMLINK-$(CONFIG_RTE_LIBRTE_REGEXDEV)-include +=
> rte_regexdev_core.h
> 
>  # versioning export map
>  EXPORT_MAP := rte_regexdev_version.map
> diff --git a/lib/librte_regexdev/meson.build
> b/lib/librte_regexdev/meson.build index f4db748..1816754 100644
> --- a/lib/librte_regexdev/meson.build
> +++ b/lib/librte_regexdev/meson.build
> @@ -3,5 +3,5 @@
> 
>  allow_experimental_apis = true
>  sources = files('rte_regexdev.c')
> -headers = files('rte_regexdev.h')
> +headers = files('rte_regexdev.h', 'rte_regexdev_core.h')
>  deps += ['mbuf']
> diff --git a/lib/librte_regexdev/rte_regexdev.h
> b/lib/librte_regexdev/rte_regexdev.h
> index 7e688d9..bbc56f9 100644
> --- a/lib/librte_regexdev/rte_regexdev.h
> +++ b/lib/librte_regexdev/rte_regexdev.h
> @@ -1466,6 +1466,8 @@ struct rte_regex_ops {
> rte_regexdev_dequeue_burst(uint8_t dev_id, uint16_t qp_id,
>  			   struct rte_regex_ops **ops, uint16_t nb_ops);
> 
> +#include "rte_regexdev_core.h"
> +
>  #ifdef __cplusplus
>  }
>  #endif
> diff --git a/lib/librte_regexdev/rte_regexdev_core.h
> b/lib/librte_regexdev/rte_regexdev_core.h
> new file mode 100644
> index 0000000..fb7a27e
> --- /dev/null
> +++ b/lib/librte_regexdev/rte_regexdev_core.h
> @@ -0,0 +1,160 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(c) 2019 Mellanox Corporation  */
> +
> +#ifndef _RTE_REGEX_CORE_H_
> +#define _RTE_REGEX_CORE_H_
> +
> +/**
> + * @file
> + *
> + * RTE RegEx Device internal header.
> + *
> + * This header contains internal data types, that are used by the RegEx
> +devices
> + * in order to expose their ops to the class.
> + *
> + * Applications should not use these API directly.
> + *
> + */
> +
> +struct rte_regexdev;
> +
> +typedef int (*regexdev_info_get_t)(struct rte_regexdev *dev,
> +				   struct rte_regexdev_info *info); /**<
> @internal Get the RegEx
> +device info. */
> +
> +typedef int (*regexdev_configure_t)(struct rte_regexdev *dev,
> +				    const struct rte_regexdev_config *cfg);
> /**< @internal
> +Configure the RegEx device. */
> +
> +typedef int (*regexdev_qp_setup_t)(struct rte_regexdev *dev, uint8_t id,
> +				   const struct rte_regexdev_qp_conf
> *qp_conf); /**< @internal
> +Setup a queue pair.*/

The API is defined as:
int
rte_regexdev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
			      const struct rte_regexdev_qp_conf *qp_conf);

id is uint8_t opposed to uint16_t

> +
> +typedef int (*regexdev_start_t)(struct rte_regexdev *dev); /**<
> +@internal Start the RegEx device. */
> +
> +typedef int (*regexdev_stop_t)(struct rte_regexdev *dev); /**<
> +@internal Stop the RegEx device. */
> +
> +typedef int (*regexdev_close_t)(struct rte_regexdev *dev); /**<
> +@internal Close the RegEx device. */
> +
> +typedef int (*regexdev_attr_get_t)(struct rte_regexdev *dev,
> +				   enum rte_regexdev_attr_id id,
> +				   void *value);
> +/**< @internal Get selected attribute from RegEx device. */
> +
> +typedef int (*regexdev_attr_set_t)(struct rte_regexdev *dev,
> +				   enum rte_regexdev_attr_id id,
> +				   const void *value);
> +/**< @internal Set selected attribute to RegEx device. */
> +
> +typedef int (*regexdev_rule_db_update_t)(struct rte_regexdev *dev,
> +					 const struct rte_regexdev_rule
> *rules,
> +					 uint16_t nb_rules);
> +/**< @internal Update the rule database for the RegEx device. */
> +
> +typedef int (*regexdev_rule_db_compile_activate_t)(struct rte_regexdev
> +*dev); /**< @internal Compile the rule database and activate it. */
> +
> +typedef int (*regexdev_rule_db_import_t)(struct rte_regexdev *dev,
> +					 const char *rule_db,
> +					 uint32_t rule_db_len);
> +/**< @internal Upload a pre created rule database to the RegEx device.
> +*/
> +
> +typedef int (*regexdev_rule_db_export_t)(struct rte_regexdev *dev,
> +					 const char *rule_db);
> +/**< @internal Export the current rule database from the RegEx device.
> +*/
The API is defined as:
int
rte_regexdev_rule_db_export(uint8_t dev_id, char *rule_db);

char *rule_db is not const

> +
> +typedef int (*regexdev_xstats_names_get_t)(struct rte_regexdev *dev,
> +					   struct rte_regexdev_xstats_map
> +					   *xstats_map);
> +/**< @internal Get xstats name map for the RegEx device. */
> +
> +typedef int (*regexdev_xstats_get_t)(struct rte_regexdev *dev,
> +				     const uint16_t *ids, uint64_t *values,
> +				     uint16_t nb_values);
> +/**< @internal Get xstats values for the RegEx device. */
> +
> +typedef int (*regexdev_xstats_by_name_get_t)(struct rte_regexdev
> *dev,
> +					     const char *name, uint16_t *id,
> +					     uint64_t *value);
> +/**< @internal Get xstat value for the RegEx device based on the xstats
> +name. */
> +
> +typedef int (*regexdev_xstats_reset_t)(struct rte_regexdev *dev,
> +				       const uint16_t *ids,
> +				       uint16_t nb_ids);
> +/**< @internal Reset xstats values for the RegEx device. */
> +
> +typedef int (*regexdev_selftest_t)(struct rte_regexdev *dev); /**<
> +@internal Trigger RegEx self test. */
> +
> +typedef int (*regexdev_dump_t)(struct rte_regexdev *dev, FILE *f); /**<
> +@internal Dump internal information about the RegEx device. */
> +
> +typedef int (*regexdev_enqueue_t)(struct rte_regexdev *dev, uint16_t
> qp_id,
> +				  struct rte_regex_ops **ops, uint16_t
> nb_ops); /**< @internal
> +Enqueue a burst of scan requests to a queue on RegEx device. */
> +

rte_regexdev_enqueue_burst() returns uint16_t

> +typedef int (*regexdev_dequeue_t)(struct rte_regexdev *dev, uint16_t
> qp_id,
> +				  struct rte_regex_ops **ops,
> +				  uint16_t nb_ops);
> +/**< @internal Dequeue a burst of scan response from a queue on RegEx
> +device. */
> +

rte_regexdev_dequeue_burst() returns uint16_t

> +/**
> + * RegEx device operations
> + */
> +struct rte_regexdev_ops {
> +	regexdev_info_get_t dev_info_get;
> +	regexdev_configure_t dev_configure;
> +	regexdev_qp_setup_t dev_qp_setup;
> +	regexdev_start_t dev_start;
> +	regexdev_stop_t dev_stop;
> +	regexdev_close_t dev_close;
> +	regexdev_attr_get_t dev_attr_get;
> +	regexdev_attr_set_t dev_attr_set;
> +	regexdev_rule_db_update_t dev_rule_db_update;
> +	regexdev_rule_db_compile_activate_t
> dev_rule_db_compile_activate;
> +	regexdev_rule_db_import_t dev_db_import;
> +	regexdev_rule_db_export_t dev_db_export;
> +	regexdev_xstats_names_get_t dev_xstats_names_get;
> +	regexdev_xstats_get_t dev_xstats_get;
> +	regexdev_xstats_by_name_get_t dev_xstats_by_name_get;
> +	regexdev_xstats_reset_t dev_xstats_reset;
> +	regexdev_selftest_t dev_selftest;
> +	regexdev_dump_t dev_dump;
> +};
> +
> +#define RTE_REGEXDEV_NAME_MAX_LEN
> +/**
> + * @internal
> + * The data part, with no function pointers, associated with each RegEx
> device.
> + *
> + * This structure is safe to place in shared memory to be common among
> +different
> + * processes in a multi-process configuration.
> + */
> +struct rte_regexdev_data {
> +	void *dev_private; /**< PMD-specific private data. */ }
> +__rte_cache_aligned;
> +
> +/**
> + * @internal
> + * The generic data structure associated with each RegEx device.
> + *
> + * Pointers to burst-oriented packet receive and transmit functions are
> + * located at the beginning of the structure, along with the pointer to
> + * where all the data elements for the particular device are stored in
> +shared
> + * memory. This split allows the function pointer and driver data to be
> +per-
> + * process, while the actual configuration data for the device is shared.
> + */
> +struct rte_regexdev {
> +	regexdev_enqueue_t enqueue;
> +	regexdev_dequeue_t dequeue;
> +	const struct rte_regexdev_ops *dev_ops;
> +	/**< Functions exported by PMD */
> +	struct rte_device *device; /**< Backing device */
> +	struct rte_regexdev_data *data;  /**< Pointer to device data. */ }
> +__rte_cache_aligned;
> +
> +#endif /* _RTE_REGEX_CORE_H_ */
> --
> 1.8.3.1


^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [PATCH v2 2/4] regexdev: add regex core h file
  2020-04-20 10:48     ` Guy Kaneti
@ 2020-04-20 15:49       ` Ori Kam
  0 siblings, 0 replies; 96+ messages in thread
From: Ori Kam @ 2020-04-20 15:49 UTC (permalink / raw)
  To: Guy Kaneti, Jerin Jacob Kollanukkaran, xiang.w.wang
  Cc: dev, Pavan Nikhilesh Bhagavatula, Shahaf Shuler, hemant.agrawal,
	Opher Reviv, Alex Rosenbaum, Dovrat Zifroni, Prasun Kapoor,
	nipun.gupta, bruce.richardson, yang.a.hong, harry.chang,
	gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai, yuyingxia,
	fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc, jim,
	hongjun.ni, j.bromhead, deri, fc, arthur.su, Thomas Monjalon

Hi,

Nice catch.

Best,
Ori

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Guy Kaneti
> Sent: Monday, April 20, 2020 1:48 PM
> To: Ori Kam <orika@mellanox.com>; Jerin Jacob Kollanukkaran
> <jerinj@marvell.com>; xiang.w.wang@intel.com
> Cc: dev@dpdk.org; Pavan Nikhilesh Bhagavatula
> <pbhagavatula@marvell.com>; Shahaf Shuler <shahafs@mellanox.com>;
> hemant.agrawal@nxp.com; Opher Reviv <opher@mellanox.com>; Alex
> Rosenbaum <alexr@mellanox.com>; Dovrat Zifroni <dovrat@marvell.com>;
> Prasun Kapoor <pkapoor@marvell.com>; nipun.gupta@nxp.com;
> bruce.richardson@intel.com; yang.a.hong@intel.com; harry.chang@intel.com;
> gu.jian1@zte.com.cn; shanjiangh@chinatelecom.cn;
> zhangy.yun@chinatelecom.cn; lixingfu@huachentel.com; wushuai@inspur.com;
> yuyingxia@yxlink.com; fanchenggang@sunyainfo.com;
> davidfgao@tencent.com; liuzhong1@chinaunicom.cn;
> zhaoyong11@huawei.com; oc@yunify.com; jim@netgate.com;
> hongjun.ni@intel.com; j.bromhead@titan-ic.com; deri@ntop.org;
> fc@napatech.com; arthur.su@lionic.com; Thomas Monjalon
> <thomas@monjalon.net>
> Subject: Re: [dpdk-dev] [PATCH v2 2/4] regexdev: add regex core h file
> 
> Hi,
> 
> 
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Ori Kam
> > Sent: Friday, April 17, 2020 3:44 PM
> > To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>;
> > xiang.w.wang@intel.com
> > Cc: dev@dpdk.org; Pavan Nikhilesh Bhagavatula
> > <pbhagavatula@marvell.com>; shahafs@mellanox.com;
> > hemant.agrawal@nxp.com; opher@mellanox.com; alexr@mellanox.com;
> > Dovrat Zifroni <dovrat@marvell.com>; Prasun Kapoor
> > <pkapoor@marvell.com>; nipun.gupta@nxp.com;
> > bruce.richardson@intel.com; yang.a.hong@intel.com;
> > harry.chang@intel.com; gu.jian1@zte.com.cn; shanjiangh@chinatelecom.cn;
> > zhangy.yun@chinatelecom.cn; lixingfu@huachentel.com;
> > wushuai@inspur.com; yuyingxia@yxlink.com;
> > fanchenggang@sunyainfo.com; davidfgao@tencent.com;
> > liuzhong1@chinaunicom.cn; zhaoyong11@huawei.com; oc@yunify.com;
> > jim@netgate.com; hongjun.ni@intel.com; j.bromhead@titan-ic.com;
> > deri@ntop.org; fc@napatech.com; arthur.su@lionic.com;
> > thomas@monjalon.net; orika@mellanox.com
> > Subject: [dpdk-dev] [PATCH v2 2/4] regexdev: add regex core h file
> >
> > This commit introduce the rte_regexdev_core.h file.
> > This file holds internal structures and API that are used by the regexdev.
> >
> > Signed-off-by: Ori Kam <orika@mellanox.com>
> > ---
> > v2:
> > * Move private data to rte_regexdev struct.
> > ---
> >  lib/librte_regexdev/Makefile            |   1 +
> >  lib/librte_regexdev/meson.build         |   2 +-
> >  lib/librte_regexdev/rte_regexdev.h      |   2 +
> >  lib/librte_regexdev/rte_regexdev_core.h | 160
> > ++++++++++++++++++++++++++++++++
> >  4 files changed, 164 insertions(+), 1 deletion(-)  create mode 100644
> > lib/librte_regexdev/rte_regexdev_core.h
> >
> > diff --git a/lib/librte_regexdev/Makefile b/lib/librte_regexdev/Makefile
> > index 6f4cc63..9012d29 100644
> > --- a/lib/librte_regexdev/Makefile
> > +++ b/lib/librte_regexdev/Makefile
> > @@ -24,6 +24,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_REGEXDEV) :=
> > rte_regexdev.c
> >
> >  # export include files
> >  SYMLINK-$(CONFIG_RTE_LIBRTE_REGEXDEV)-include += rte_regexdev.h
> > +SYMLINK-$(CONFIG_RTE_LIBRTE_REGEXDEV)-include +=
> > rte_regexdev_core.h
> >
> >  # versioning export map
> >  EXPORT_MAP := rte_regexdev_version.map
> > diff --git a/lib/librte_regexdev/meson.build
> > b/lib/librte_regexdev/meson.build index f4db748..1816754 100644
> > --- a/lib/librte_regexdev/meson.build
> > +++ b/lib/librte_regexdev/meson.build
> > @@ -3,5 +3,5 @@
> >
> >  allow_experimental_apis = true
> >  sources = files('rte_regexdev.c')
> > -headers = files('rte_regexdev.h')
> > +headers = files('rte_regexdev.h', 'rte_regexdev_core.h')
> >  deps += ['mbuf']
> > diff --git a/lib/librte_regexdev/rte_regexdev.h
> > b/lib/librte_regexdev/rte_regexdev.h
> > index 7e688d9..bbc56f9 100644
> > --- a/lib/librte_regexdev/rte_regexdev.h
> > +++ b/lib/librte_regexdev/rte_regexdev.h
> > @@ -1466,6 +1466,8 @@ struct rte_regex_ops {
> > rte_regexdev_dequeue_burst(uint8_t dev_id, uint16_t qp_id,
> >  			   struct rte_regex_ops **ops, uint16_t nb_ops);
> >
> > +#include "rte_regexdev_core.h"
> > +
> >  #ifdef __cplusplus
> >  }
> >  #endif
> > diff --git a/lib/librte_regexdev/rte_regexdev_core.h
> > b/lib/librte_regexdev/rte_regexdev_core.h
> > new file mode 100644
> > index 0000000..fb7a27e
> > --- /dev/null
> > +++ b/lib/librte_regexdev/rte_regexdev_core.h
> > @@ -0,0 +1,160 @@
> > +/* SPDX-License-Identifier: BSD-3-Clause
> > + * Copyright(c) 2019 Mellanox Corporation  */
> > +
> > +#ifndef _RTE_REGEX_CORE_H_
> > +#define _RTE_REGEX_CORE_H_
> > +
> > +/**
> > + * @file
> > + *
> > + * RTE RegEx Device internal header.
> > + *
> > + * This header contains internal data types, that are used by the RegEx
> > +devices
> > + * in order to expose their ops to the class.
> > + *
> > + * Applications should not use these API directly.
> > + *
> > + */
> > +
> > +struct rte_regexdev;
> > +
> > +typedef int (*regexdev_info_get_t)(struct rte_regexdev *dev,
> > +				   struct rte_regexdev_info *info); /**<
> > @internal Get the RegEx
> > +device info. */
> > +
> > +typedef int (*regexdev_configure_t)(struct rte_regexdev *dev,
> > +				    const struct rte_regexdev_config *cfg);
> > /**< @internal
> > +Configure the RegEx device. */
> > +
> > +typedef int (*regexdev_qp_setup_t)(struct rte_regexdev *dev, uint8_t id,
> > +				   const struct rte_regexdev_qp_conf
> > *qp_conf); /**< @internal
> > +Setup a queue pair.*/
> 
> The API is defined as:
> int
> rte_regexdev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
> 			      const struct rte_regexdev_qp_conf *qp_conf);
> 
> id is uint8_t opposed to uint16_t

Will fix.

> 
> > +
> > +typedef int (*regexdev_start_t)(struct rte_regexdev *dev); /**<
> > +@internal Start the RegEx device. */
> > +
> > +typedef int (*regexdev_stop_t)(struct rte_regexdev *dev); /**<
> > +@internal Stop the RegEx device. */
> > +
> > +typedef int (*regexdev_close_t)(struct rte_regexdev *dev); /**<
> > +@internal Close the RegEx device. */
> > +
> > +typedef int (*regexdev_attr_get_t)(struct rte_regexdev *dev,
> > +				   enum rte_regexdev_attr_id id,
> > +				   void *value);
> > +/**< @internal Get selected attribute from RegEx device. */
> > +
> > +typedef int (*regexdev_attr_set_t)(struct rte_regexdev *dev,
> > +				   enum rte_regexdev_attr_id id,
> > +				   const void *value);
> > +/**< @internal Set selected attribute to RegEx device. */
> > +
> > +typedef int (*regexdev_rule_db_update_t)(struct rte_regexdev *dev,
> > +					 const struct rte_regexdev_rule
> > *rules,
> > +					 uint16_t nb_rules);
> > +/**< @internal Update the rule database for the RegEx device. */
> > +
> > +typedef int (*regexdev_rule_db_compile_activate_t)(struct rte_regexdev
> > +*dev); /**< @internal Compile the rule database and activate it. */
> > +
> > +typedef int (*regexdev_rule_db_import_t)(struct rte_regexdev *dev,
> > +					 const char *rule_db,
> > +					 uint32_t rule_db_len);
> > +/**< @internal Upload a pre created rule database to the RegEx device.
> > +*/
> > +
> > +typedef int (*regexdev_rule_db_export_t)(struct rte_regexdev *dev,
> > +					 const char *rule_db);
> > +/**< @internal Export the current rule database from the RegEx device.
> > +*/
> The API is defined as:
> int
> rte_regexdev_rule_db_export(uint8_t dev_id, char *rule_db);
> 
> char *rule_db is not const
> 

Will fix.

> > +
> > +typedef int (*regexdev_xstats_names_get_t)(struct rte_regexdev *dev,
> > +					   struct rte_regexdev_xstats_map
> > +					   *xstats_map);
> > +/**< @internal Get xstats name map for the RegEx device. */
> > +
> > +typedef int (*regexdev_xstats_get_t)(struct rte_regexdev *dev,
> > +				     const uint16_t *ids, uint64_t *values,
> > +				     uint16_t nb_values);
> > +/**< @internal Get xstats values for the RegEx device. */
> > +
> > +typedef int (*regexdev_xstats_by_name_get_t)(struct rte_regexdev
> > *dev,
> > +					     const char *name, uint16_t *id,
> > +					     uint64_t *value);
> > +/**< @internal Get xstat value for the RegEx device based on the xstats
> > +name. */
> > +
> > +typedef int (*regexdev_xstats_reset_t)(struct rte_regexdev *dev,
> > +				       const uint16_t *ids,
> > +				       uint16_t nb_ids);
> > +/**< @internal Reset xstats values for the RegEx device. */
> > +
> > +typedef int (*regexdev_selftest_t)(struct rte_regexdev *dev); /**<
> > +@internal Trigger RegEx self test. */
> > +
> > +typedef int (*regexdev_dump_t)(struct rte_regexdev *dev, FILE *f); /**<
> > +@internal Dump internal information about the RegEx device. */
> > +
> > +typedef int (*regexdev_enqueue_t)(struct rte_regexdev *dev, uint16_t
> > qp_id,
> > +				  struct rte_regex_ops **ops, uint16_t
> > nb_ops); /**< @internal
> > +Enqueue a burst of scan requests to a queue on RegEx device. */
> > +
> 
> rte_regexdev_enqueue_burst() returns uint16_t
> 

Will fix.

> > +typedef int (*regexdev_dequeue_t)(struct rte_regexdev *dev, uint16_t
> > qp_id,
> > +				  struct rte_regex_ops **ops,
> > +				  uint16_t nb_ops);
> > +/**< @internal Dequeue a burst of scan response from a queue on RegEx
> > +device. */
> > +
> 
> rte_regexdev_dequeue_burst() returns uint16_t
> 

Will fix.

> > +/**
> > + * RegEx device operations
> > + */
> > +struct rte_regexdev_ops {
> > +	regexdev_info_get_t dev_info_get;
> > +	regexdev_configure_t dev_configure;
> > +	regexdev_qp_setup_t dev_qp_setup;
> > +	regexdev_start_t dev_start;
> > +	regexdev_stop_t dev_stop;
> > +	regexdev_close_t dev_close;
> > +	regexdev_attr_get_t dev_attr_get;
> > +	regexdev_attr_set_t dev_attr_set;
> > +	regexdev_rule_db_update_t dev_rule_db_update;
> > +	regexdev_rule_db_compile_activate_t
> > dev_rule_db_compile_activate;
> > +	regexdev_rule_db_import_t dev_db_import;
> > +	regexdev_rule_db_export_t dev_db_export;
> > +	regexdev_xstats_names_get_t dev_xstats_names_get;
> > +	regexdev_xstats_get_t dev_xstats_get;
> > +	regexdev_xstats_by_name_get_t dev_xstats_by_name_get;
> > +	regexdev_xstats_reset_t dev_xstats_reset;
> > +	regexdev_selftest_t dev_selftest;
> > +	regexdev_dump_t dev_dump;
> > +};
> > +
> > +#define RTE_REGEXDEV_NAME_MAX_LEN
> > +/**
> > + * @internal
> > + * The data part, with no function pointers, associated with each RegEx
> > device.
> > + *
> > + * This structure is safe to place in shared memory to be common among
> > +different
> > + * processes in a multi-process configuration.
> > + */
> > +struct rte_regexdev_data {
> > +	void *dev_private; /**< PMD-specific private data. */ }
> > +__rte_cache_aligned;
> > +
> > +/**
> > + * @internal
> > + * The generic data structure associated with each RegEx device.
> > + *
> > + * Pointers to burst-oriented packet receive and transmit functions are
> > + * located at the beginning of the structure, along with the pointer to
> > + * where all the data elements for the particular device are stored in
> > +shared
> > + * memory. This split allows the function pointer and driver data to be
> > +per-
> > + * process, while the actual configuration data for the device is shared.
> > + */
> > +struct rte_regexdev {
> > +	regexdev_enqueue_t enqueue;
> > +	regexdev_dequeue_t dequeue;
> > +	const struct rte_regexdev_ops *dev_ops;
> > +	/**< Functions exported by PMD */
> > +	struct rte_device *device; /**< Backing device */
> > +	struct rte_regexdev_data *data;  /**< Pointer to device data. */ }
> > +__rte_cache_aligned;
> > +
> > +#endif /* _RTE_REGEX_CORE_H_ */
> > --
> > 1.8.3.1


^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [PATCH v2 4/4] regexdev: implement regex rte level functions
  2020-04-17 12:43   ` [dpdk-dev] [PATCH v2 4/4] regexdev: implement regex rte level functions Ori Kam
@ 2020-04-21 11:12     ` Guy Kaneti
  2020-04-21 11:20       ` Ori Kam
  2020-04-21 11:36     ` Guy Kaneti
  1 sibling, 1 reply; 96+ messages in thread
From: Guy Kaneti @ 2020-04-21 11:12 UTC (permalink / raw)
  To: Ori Kam, Jerin Jacob Kollanukkaran, xiang.w.wang
  Cc: dev, Pavan Nikhilesh Bhagavatula, shahafs, hemant.agrawal, opher,
	alexr, Dovrat Zifroni, Prasun Kapoor, nipun.gupta,
	bruce.richardson, yang.a.hong, harry.chang, gu.jian1, shanjiangh,
	zhangy.yun, lixingfu, wushuai, yuyingxia, fanchenggang,
	davidfgao, liuzhong1, zhaoyong11, oc, jim, hongjun.ni,
	j.bromhead, deri, fc, arthur.su, thomas

Hi,

> +int
> +rte_regexdev_is_valid_dev(uint16_t dev_id) {
> +	if (dev_id >= RTE_MAX_REGEXDEV_DEVS ||
> +	    rte_regex_devices[dev_id].state != RTE_REGEXDEV_READY)
> +		return 0;
> +	return 1;
> +}

When is the state changed to RTE_REGEXDEV_READY?
Should the PMD change it at the end of probing?

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [PATCH v2 4/4] regexdev: implement regex rte level functions
  2020-04-21 11:12     ` Guy Kaneti
@ 2020-04-21 11:20       ` Ori Kam
  0 siblings, 0 replies; 96+ messages in thread
From: Ori Kam @ 2020-04-21 11:20 UTC (permalink / raw)
  To: Guy Kaneti, Jerin Jacob Kollanukkaran, xiang.w.wang
  Cc: dev, Pavan Nikhilesh Bhagavatula, Shahaf Shuler, hemant.agrawal,
	Opher Reviv, Alex Rosenbaum, Dovrat Zifroni, Prasun Kapoor,
	nipun.gupta, bruce.richardson, yang.a.hong, harry.chang,
	gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai, yuyingxia,
	fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc, jim,
	hongjun.ni, j.bromhead, deri, fc, arthur.su, Thomas Monjalon



> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Guy Kaneti
> Sent: Tuesday, April 21, 2020 2:12 PM
> To: Ori Kam <orika@mellanox.com>; Jerin Jacob Kollanukkaran
> <jerinj@marvell.com>; xiang.w.wang@intel.com
> Cc: dev@dpdk.org; Pavan Nikhilesh Bhagavatula
> <pbhagavatula@marvell.com>; Shahaf Shuler <shahafs@mellanox.com>;
> hemant.agrawal@nxp.com; Opher Reviv <opher@mellanox.com>; Alex
> Rosenbaum <alexr@mellanox.com>; Dovrat Zifroni <dovrat@marvell.com>;
> Prasun Kapoor <pkapoor@marvell.com>; nipun.gupta@nxp.com;
> bruce.richardson@intel.com; yang.a.hong@intel.com; harry.chang@intel.com;
> gu.jian1@zte.com.cn; shanjiangh@chinatelecom.cn;
> zhangy.yun@chinatelecom.cn; lixingfu@huachentel.com; wushuai@inspur.com;
> yuyingxia@yxlink.com; fanchenggang@sunyainfo.com;
> davidfgao@tencent.com; liuzhong1@chinaunicom.cn;
> zhaoyong11@huawei.com; oc@yunify.com; jim@netgate.com;
> hongjun.ni@intel.com; j.bromhead@titan-ic.com; deri@ntop.org;
> fc@napatech.com; arthur.su@lionic.com; Thomas Monjalon
> <thomas@monjalon.net>
> Subject: Re: [dpdk-dev] [PATCH v2 4/4] regexdev: implement regex rte level
> functions
> 
> Hi,
> 
> > +int
> > +rte_regexdev_is_valid_dev(uint16_t dev_id) {
> > +	if (dev_id >= RTE_MAX_REGEXDEV_DEVS ||
> > +	    rte_regex_devices[dev_id].state != RTE_REGEXDEV_READY)
> > +		return 0;
> > +	return 1;
> > +}
> 
> When is the state changed to RTE_REGEXDEV_READY?
> Should the PMD change it at the end of probing?

Yes, 

Best,
Ori

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [PATCH v2 4/4] regexdev: implement regex rte level functions
  2020-04-17 12:43   ` [dpdk-dev] [PATCH v2 4/4] regexdev: implement regex rte level functions Ori Kam
  2020-04-21 11:12     ` Guy Kaneti
@ 2020-04-21 11:36     ` Guy Kaneti
  2020-04-22 20:33       ` Ori Kam
  1 sibling, 1 reply; 96+ messages in thread
From: Guy Kaneti @ 2020-04-21 11:36 UTC (permalink / raw)
  To: Ori Kam, Jerin Jacob Kollanukkaran, xiang.w.wang
  Cc: dev, Pavan Nikhilesh Bhagavatula, shahafs, hemant.agrawal, opher,
	alexr, Dovrat Zifroni, Prasun Kapoor, nipun.gupta,
	bruce.richardson, yang.a.hong, harry.chang, gu.jian1, shanjiangh,
	zhangy.yun, lixingfu, wushuai, yuyingxia, fanchenggang,
	davidfgao, liuzhong1, zhaoyong11, oc, jim, hongjun.ni,
	j.bromhead, deri, fc, arthur.su, thomas

Hi,

> +int
> +rte_regexdev_configure(uint8_t dev_id, const struct rte_regexdev_config
> +*cfg) {
> +	struct rte_regexdev *dev;
> +	struct rte_regexdev_info dev_info;
> +	int ret;
> +
> +	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
> +	if (cfg == NULL)
> +		return -EINVAL;
> +	dev = &rte_regex_devices[dev_id];
> +	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_configure, -
> ENOTSUP);
> +	if (dev->data->dev_started) {
> +		RTE_REGEXDEV_LOG
> +			(ERR, "Dev %u must be stopped to allow
> configuration\n",
> +			 dev_id);
> +		return -EBUSY;
> +	}
> +	ret = regexdev_info_get(dev_id, &dev_info);
> +	if (ret < 0)
> +		return ret;
> +	if ((cfg->dev_cfg_flags &
> RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F) &&
> +	    !(dev_info.regexdev_capa &
> RTE_REGEXDEV_SUPP_CROSS_BUFFER_F)) {
> +		RTE_REGEXDEV_LOG(ERR,
> +				 "Dev %u doesn't support cross buffer
> scan\n",
> +				 dev_id);
> +		return -EINVAL;
> +	}
> +	if ((cfg->dev_cfg_flags & RTE_REGEXDEV_CFG_MATCH_AS_END_F)
> &&
> +	    !(dev_info.regexdev_capa &
> RTE_REGEXDEV_SUPP_MATCH_AS_END_F)) {
> +		RTE_REGEXDEV_LOG(ERR,
> +				 "Dev %u doesn't support match as end\n",
> +				 dev_id);
> +		return -EINVAL;
> +	}
> +	if ((cfg->dev_cfg_flags & RTE_REGEXDEV_CFG_MATCH_ALL_F) &&
> +	    !(dev_info.regexdev_capa &
> RTE_REGEXDEV_SUPP_MATCH_ALL_F)) {
> +		RTE_REGEXDEV_LOG(ERR,
> +				 "Dev %u doesn't support match all\n",
> +				 dev_id);
> +		return -EINVAL;
> +	}
> +	if (cfg->nb_groups == 0) {
> +		RTE_REGEXDEV_LOG(ERR, "Dev %u num of groups must be >
> 0\n",
> +				 dev_id);
> +		return -EINVAL;
> +	}
> +	if (cfg->nb_groups >= dev_info.max_groups) {
> +		RTE_REGEXDEV_LOG(ERR, "Dev %u num of groups %d >
> %d\n",
> +				 dev_id, cfg->nb_groups,
> dev_info.max_groups);
> +		return -EINVAL;
> +	}

The comparison should be > and not >=

> +	if (cfg->nb_max_matches == 0) {
> +		RTE_REGEXDEV_LOG(ERR, "Dev %u num of matches must be
> > 0\n",
> +				 dev_id);
> +		return -EINVAL;
> +	}
> +	if (cfg->nb_max_matches >= dev_info.max_matches) {
> +		RTE_REGEXDEV_LOG(ERR, "Dev %u num of matches %d >
> %d\n",
> +				 dev_id, cfg->nb_max_matches,
> +				 dev_info.max_matches);
> +		return -EINVAL;
> +	}

The comparison should be > and not >=

> +	if (cfg->nb_queue_pairs == 0) {
> +		RTE_REGEXDEV_LOG(ERR, "Dev %u num of queues must be
> > 0\n",
> +				 dev_id);
> +		return -EINVAL;
> +	}
> +	if (cfg->nb_queue_pairs >= dev_info.max_queue_pairs) {
> +		RTE_REGEXDEV_LOG(ERR, "Dev %u num of queues %d >
> %d\n",
> +				 dev_id, cfg->nb_queue_pairs,
> +				 dev_info.max_queue_pairs);
> +		return -EINVAL;
> +	}

The comparison should be > and not >=

> +	if (cfg->nb_rules_per_group == 0) {
> +		RTE_REGEXDEV_LOG(ERR,
> +				 "Dev %u num of rules per group must be >
> 0\n",
> +				 dev_id);
> +		return -EINVAL;
> +	}
> +	if (cfg->nb_rules_per_group >= dev_info.max_rules_per_group) {
> +		RTE_REGEXDEV_LOG(ERR,
> +				 "Dev %u num of rules per group %d > %d\n",
> +				 dev_id, cfg->nb_rules_per_group,
> +				 dev_info.max_rules_per_group);
> +		return -EINVAL;
> +	}

The comparison should be > and not >=

> +	ret = (*dev->dev_ops->dev_configure)(dev, cfg);
> +	if (ret == 0)
> +		dev->data->dev_conf = *cfg;
> +	return ret;
> +}

In general I think that the validation of the cfg values should be done by the PMD


^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [PATCH v2 4/4] regexdev: implement regex rte level functions
  2020-04-21 11:36     ` Guy Kaneti
@ 2020-04-22 20:33       ` Ori Kam
  0 siblings, 0 replies; 96+ messages in thread
From: Ori Kam @ 2020-04-22 20:33 UTC (permalink / raw)
  To: Guy Kaneti, Jerin Jacob Kollanukkaran, xiang.w.wang
  Cc: dev, Pavan Nikhilesh Bhagavatula, Shahaf Shuler, hemant.agrawal,
	Opher Reviv, Alex Rosenbaum, Dovrat Zifroni, Prasun Kapoor,
	nipun.gupta, bruce.richardson, yang.a.hong, harry.chang,
	gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai, yuyingxia,
	fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc, jim,
	hongjun.ni, j.bromhead, deri, fc, arthur.su, Thomas Monjalon

Hi Guy,

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Guy Kaneti
> Sent: Tuesday, April 21, 2020 2:36 PM
> To: Ori Kam <orika@mellanox.com>; Jerin Jacob Kollanukkaran
> <jerinj@marvell.com>; xiang.w.wang@intel.com
> Cc: dev@dpdk.org; Pavan Nikhilesh Bhagavatula
> <pbhagavatula@marvell.com>; Shahaf Shuler <shahafs@mellanox.com>;
> hemant.agrawal@nxp.com; Opher Reviv <opher@mellanox.com>; Alex
> Rosenbaum <alexr@mellanox.com>; Dovrat Zifroni <dovrat@marvell.com>;
> Prasun Kapoor <pkapoor@marvell.com>; nipun.gupta@nxp.com;
> bruce.richardson@intel.com; yang.a.hong@intel.com; harry.chang@intel.com;
> gu.jian1@zte.com.cn; shanjiangh@chinatelecom.cn;
> zhangy.yun@chinatelecom.cn; lixingfu@huachentel.com; wushuai@inspur.com;
> yuyingxia@yxlink.com; fanchenggang@sunyainfo.com;
> davidfgao@tencent.com; liuzhong1@chinaunicom.cn;
> zhaoyong11@huawei.com; oc@yunify.com; jim@netgate.com;
> hongjun.ni@intel.com; j.bromhead@titan-ic.com; deri@ntop.org;
> fc@napatech.com; arthur.su@lionic.com; Thomas Monjalon
> <thomas@monjalon.net>
> Subject: Re: [dpdk-dev] [PATCH v2 4/4] regexdev: implement regex rte level
> functions
> 
> Hi,
> 
> > +int
> > +rte_regexdev_configure(uint8_t dev_id, const struct rte_regexdev_config
> > +*cfg) {
> > +	struct rte_regexdev *dev;
> > +	struct rte_regexdev_info dev_info;
> > +	int ret;
> > +
> > +	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
> > +	if (cfg == NULL)
> > +		return -EINVAL;
> > +	dev = &rte_regex_devices[dev_id];
> > +	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_configure, -
> > ENOTSUP);
> > +	if (dev->data->dev_started) {
> > +		RTE_REGEXDEV_LOG
> > +			(ERR, "Dev %u must be stopped to allow
> > configuration\n",
> > +			 dev_id);
> > +		return -EBUSY;
> > +	}
> > +	ret = regexdev_info_get(dev_id, &dev_info);
> > +	if (ret < 0)
> > +		return ret;
> > +	if ((cfg->dev_cfg_flags &
> > RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F) &&
> > +	    !(dev_info.regexdev_capa &
> > RTE_REGEXDEV_SUPP_CROSS_BUFFER_F)) {
> > +		RTE_REGEXDEV_LOG(ERR,
> > +				 "Dev %u doesn't support cross buffer
> > scan\n",
> > +				 dev_id);
> > +		return -EINVAL;
> > +	}
> > +	if ((cfg->dev_cfg_flags & RTE_REGEXDEV_CFG_MATCH_AS_END_F)
> > &&
> > +	    !(dev_info.regexdev_capa &
> > RTE_REGEXDEV_SUPP_MATCH_AS_END_F)) {
> > +		RTE_REGEXDEV_LOG(ERR,
> > +				 "Dev %u doesn't support match as end\n",
> > +				 dev_id);
> > +		return -EINVAL;
> > +	}
> > +	if ((cfg->dev_cfg_flags & RTE_REGEXDEV_CFG_MATCH_ALL_F) &&
> > +	    !(dev_info.regexdev_capa &
> > RTE_REGEXDEV_SUPP_MATCH_ALL_F)) {
> > +		RTE_REGEXDEV_LOG(ERR,
> > +				 "Dev %u doesn't support match all\n",
> > +				 dev_id);
> > +		return -EINVAL;
> > +	}
> > +	if (cfg->nb_groups == 0) {
> > +		RTE_REGEXDEV_LOG(ERR, "Dev %u num of groups must be >
> > 0\n",
> > +				 dev_id);
> > +		return -EINVAL;
> > +	}
> > +	if (cfg->nb_groups >= dev_info.max_groups) {
> > +		RTE_REGEXDEV_LOG(ERR, "Dev %u num of groups %d >
> > %d\n",
> > +				 dev_id, cfg->nb_groups,
> > dev_info.max_groups);
> > +		return -EINVAL;
> > +	}
> 
> The comparison should be > and not >=
> 

Yes, you are correct will fix.

> > +	if (cfg->nb_max_matches == 0) {
> > +		RTE_REGEXDEV_LOG(ERR, "Dev %u num of matches must be
> > > 0\n",
> > +				 dev_id);
> > +		return -EINVAL;
> > +	}
> > +	if (cfg->nb_max_matches >= dev_info.max_matches) {
> > +		RTE_REGEXDEV_LOG(ERR, "Dev %u num of matches %d >
> > %d\n",
> > +				 dev_id, cfg->nb_max_matches,
> > +				 dev_info.max_matches);
> > +		return -EINVAL;
> > +	}
> 
> The comparison should be > and not >=
> 

Yes, will fix.

> > +	if (cfg->nb_queue_pairs == 0) {
> > +		RTE_REGEXDEV_LOG(ERR, "Dev %u num of queues must be
> > > 0\n",
> > +				 dev_id);
> > +		return -EINVAL;
> > +	}
> > +	if (cfg->nb_queue_pairs >= dev_info.max_queue_pairs) {
> > +		RTE_REGEXDEV_LOG(ERR, "Dev %u num of queues %d >
> > %d\n",
> > +				 dev_id, cfg->nb_queue_pairs,
> > +				 dev_info.max_queue_pairs);
> > +		return -EINVAL;
> > +	}
> 
> The comparison should be > and not >=
> 

Will fix.

> > +	if (cfg->nb_rules_per_group == 0) {
> > +		RTE_REGEXDEV_LOG(ERR,
> > +				 "Dev %u num of rules per group must be >
> > 0\n",
> > +				 dev_id);
> > +		return -EINVAL;
> > +	}
> > +	if (cfg->nb_rules_per_group >= dev_info.max_rules_per_group) {
> > +		RTE_REGEXDEV_LOG(ERR,
> > +				 "Dev %u num of rules per group %d > %d\n",
> > +				 dev_id, cfg->nb_rules_per_group,
> > +				 dev_info.max_rules_per_group);
> > +		return -EINVAL;
> > +	}
> 
> The comparison should be > and not >=
> 

Will fix.

> > +	ret = (*dev->dev_ops->dev_configure)(dev, cfg);
> > +	if (ret == 0)
> > +		dev->data->dev_conf = *cfg;
> > +	return ret;
> > +}
> 
> In general I think that the validation of the cfg values should be done by the
> PMD

This was done in the first version.
after comments from the community, I changed it.
As much as I like the idea that PMD should handle everything by itself.
there is no point of code duplication, all PMD will require to do those test,
and there is no advantage of doing it inside the PMD.
Also it is common practice in DPDK to assume that the input was tested in the above 
layer. (you can see ethdev)


^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core functions
  2020-04-19 10:38                 ` Guy Kaneti
@ 2020-04-22 21:36                   ` Ori Kam
  0 siblings, 0 replies; 96+ messages in thread
From: Ori Kam @ 2020-04-22 21:36 UTC (permalink / raw)
  To: Guy Kaneti, Thomas Monjalon, Jerin Jacob Kollanukkaran,
	xiang.w.wang, Pavan Nikhilesh Bhagavatula
  Cc: dev, Shahaf Shuler, hemant.agrawal, Opher Reviv, Alex Rosenbaum,
	Dovrat Zifroni, Prasun Kapoor, nipun.gupta, bruce.richardson,
	yang.a.hong, harry.chang, gu.jian1, shanjiangh, zhangy.yun,
	lixingfu, wushuai, yuyingxia, fanchenggang, davidfgao, liuzhong1,
	zhaoyong11, oc, jim, hongjun.ni, j.bromhead, deri, fc, arthur.su,
	Parav Pandit

Hi Guy,


> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Guy Kaneti
> Sent: Sunday, April 19, 2020 1:39 PM
> To: Ori Kam <orika@mellanox.com>; Thomas Monjalon
> <thomas@monjalon.net>; Jerin Jacob Kollanukkaran <jerinj@marvell.com>;
> xiang.w.wang@intel.com; Pavan Nikhilesh Bhagavatula
> <pbhagavatula@marvell.com>
> Cc: dev@dpdk.org; Shahaf Shuler <shahafs@mellanox.com>;
> hemant.agrawal@nxp.com; Opher Reviv <opher@mellanox.com>; Alex
> Rosenbaum <alexr@mellanox.com>; Dovrat Zifroni <dovrat@marvell.com>;
> Prasun Kapoor <pkapoor@marvell.com>; nipun.gupta@nxp.com;
> bruce.richardson@intel.com; yang.a.hong@intel.com; harry.chang@intel.com;
> gu.jian1@zte.com.cn; shanjiangh@chinatelecom.cn;
> zhangy.yun@chinatelecom.cn; lixingfu@huachentel.com; wushuai@inspur.com;
> yuyingxia@yxlink.com; fanchenggang@sunyainfo.com;
> davidfgao@tencent.com; liuzhong1@chinaunicom.cn;
> zhaoyong11@huawei.com; oc@yunify.com; jim@netgate.com;
> hongjun.ni@intel.com; j.bromhead@titan-ic.com; deri@ntop.org;
> fc@napatech.com; arthur.su@lionic.com; Parav Pandit <parav@mellanox.com>
> Subject: Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core
> functions
> 
> 
> 
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Ori Kam
> > Sent: Wednesday, April 08, 2020 11:40 AM
> > To: Thomas Monjalon <thomas@monjalon.net>; Jerin Jacob Kollanukkaran
> > <jerinj@marvell.com>; xiang.w.wang@intel.com; Pavan Nikhilesh
> > Bhagavatula <pbhagavatula@marvell.com>
> > Cc: dev@dpdk.org; Shahaf Shuler <shahafs@mellanox.com>;
> > hemant.agrawal@nxp.com; Opher Reviv <opher@mellanox.com>; Alex
> > Rosenbaum <alexr@mellanox.com>; Dovrat Zifroni <dovrat@marvell.com>;
> > Prasun Kapoor <pkapoor@marvell.com>; nipun.gupta@nxp.com;
> > bruce.richardson@intel.com; yang.a.hong@intel.com;
> > harry.chang@intel.com; gu.jian1@zte.com.cn; shanjiangh@chinatelecom.cn;
> > zhangy.yun@chinatelecom.cn; lixingfu@huachentel.com;
> > wushuai@inspur.com; yuyingxia@yxlink.com;
> > fanchenggang@sunyainfo.com; davidfgao@tencent.com;
> > liuzhong1@chinaunicom.cn; zhaoyong11@huawei.com; oc@yunify.com;
> > jim@netgate.com; hongjun.ni@intel.com; j.bromhead@titan-ic.com;
> > deri@ntop.org; fc@napatech.com; arthur.su@lionic.com; Parav Pandit
> > <parav@mellanox.com>
> > Subject: Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core
> > functions
> >
> >
> >
> > > -----Original Message-----
> > > From: dev <dev-bounces@dpdk.org> On Behalf Of Thomas Monjalon
> > > Sent: Monday, April 6, 2020 4:30 PM
> > > To: Ori Kam <orika@mellanox.com>; Jerin Jacob Kollanukkaran
> > > <jerinj@marvell.com>; xiang.w.wang@intel.com; Pavan Nikhilesh
> > > Bhagavatula <pbhagavatula@marvell.com>
> > > Cc: dev@dpdk.org; Shahaf Shuler <shahafs@mellanox.com>;
> > > hemant.agrawal@nxp.com; Opher Reviv <opher@mellanox.com>; Alex
> > > Rosenbaum <alexr@mellanox.com>; Dovrat Zifroni
> > <dovrat@marvell.com>;
> > > Prasun Kapoor <pkapoor@marvell.com>; nipun.gupta@nxp.com;
> > > bruce.richardson@intel.com; yang.a.hong@intel.com;
> > > harry.chang@intel.com; gu.jian1@zte.com.cn;
> > > shanjiangh@chinatelecom.cn; zhangy.yun@chinatelecom.cn;
> > > lixingfu@huachentel.com; wushuai@inspur.com; yuyingxia@yxlink.com;
> > > fanchenggang@sunyainfo.com; davidfgao@tencent.com;
> > > liuzhong1@chinaunicom.cn; zhaoyong11@huawei.com; oc@yunify.com;
> > > jim@netgate.com; hongjun.ni@intel.com; j.bromhead@titan-ic.com;
> > > deri@ntop.org; fc@napatech.com; arthur.su@lionic.com; Parav Pandit
> > > <parav@mellanox.com>
> > > Subject: Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev
> > > core functions
> > >
> > > 06/04/2020 14:48, Pavan Nikhilesh Bhagavatula:
> > > > > From: Pavan Nikhilesh Bhagavatula
> > > > >> >> From: Pavan Nikhilesh Bhagavatula
> > > > >> >>
> > > > >> >> Looks like this implementation is incomplete?
> > > > >> >> I don't see any pmd specific helper functions for @see
> > > > >> >rte_cryptodev_pmd.c,
> > > > >> >> rte_eventdev_pmd*
> > > > >> >>
> > > > >> >I think the current implementation includes all needed
> > > > >> >functions, at least for the first stage.
> > > > >> >You can find in rte_regexdev_driver.h the functions that should
> > > > >> >be called by the PMD. We have the register / unregister which
> > > > >> >acts the same
> > > > >as
> > > > >> >create
> > > > >> >and destroy. For parsing argument the PMD may call
> > > > >rte_kvargs_parse.
> > > > >> >
> > > > >>
> > > > >> _driver.h should atleast include
> > > > >> rte_regex_dev_pci_generic_probe/rte_regex_pmd_vdev_init
> > > > >> else there would be a lot of code repetition and possibly
> > > > >> udefined
> > > > >behavior
> > > > >> at the driver layer.
> > > > >>
> > > > >Why should they be included? At least in this stage, there is no
> > > > >code to share ethdev why should we add code for the vdev?
> > > >
> > > > Ok I think I failed to communicate my concerns across.
> > > > Let me retry
> > > >
> > > > 1. SW based regex devices such as PCRE/Hyperscan rely on vdev
> > > > framework i.e. user needs to pass an EAL argument
> > > > --vdev="regex_pcre" for the driver to initialize all the other EAL
> > > > subsystems (ethdev, eventdev, cryptodev,
> > > etc..)support this.
> > >
> > > vdev helpers do not have to be part of the first patches which define API.
> > > It should be added when adding the first vdev driver.
> > >
> > > > 2. HW based independent regex devices that are exposed as PCI
> > > > devices
> > > would need
> > > >  pci probe helpers.
> > >
> > > Same, PCI helpers can be added while adding the first PCI driver.
> > >
> > > We can synchronize about how to split the work, avoiding two
> > > developers doing the same thing. But let's not mandate this work to be
> > > done as part of this first series.
> > >
> > >
> > I agree with Thomas, let's discuss this when adding the PMDs.
> 
> I am writing a now the Marvell OcteonTx2 PMD and I think that a PCI helper is
> missing.
> When registering a PCI device, a .remove function is registered of type
> pci_remove_t *remove;
> 
> typedef int (pci_remove_t)(struct rte_pci_device *);
> because this function receives struct rte_pci_device * as an argument
> It is required to have a helper function to retrieve struct rte_regexdev *dev
> based on the device name (or another way).
> similar to rte_cryptodev_pmd_get_named_dev(const char *name)i

Will add.

Thanks,
Ori



^ permalink raw reply	[flat|nested] 96+ messages in thread

* [dpdk-dev] [PATCH v3 0/4] add RegEx class
  2020-03-29  6:47 [dpdk-dev] [PATCH v1 0/4] add RegEx class Ori Kam
                   ` (5 preceding siblings ...)
  2020-04-17 12:43 ` [dpdk-dev] [PATCH v2 " Ori Kam
@ 2020-05-07  9:45 ` Ori Kam
  2020-05-07  9:45   ` [dpdk-dev] [PATCH v3 1/4] regexdev: introduce regexdev subsystem Ori Kam
                     ` (4 more replies)
  2020-07-02  7:45 ` [dpdk-dev] [PATCH v4 " Ori Kam
  2020-07-06 17:36 ` [dpdk-dev] [PATCH v5 " Ori Kam
  8 siblings, 5 replies; 96+ messages in thread
From: Ori Kam @ 2020-05-07  9:45 UTC (permalink / raw)
  To: jerinj, xiang.w.wang
  Cc: guyk, dev, pbhagavatula, shahafs, hemant.agrawal, opher, alexr,
	dovrat, pkapoor, nipun.gupta, bruce.richardson, yang.a.hong,
	harry.chang, gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai,
	yuyingxia, fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc,
	jim, hongjun.ni, j.bromhead, deri, fc, arthur.su, thomas, orika

This patch set adds the RegEx class, which enables RegEx pattern
matching, both on HW/SW PMDs.

Example for applications that will benefit from this class:
* Next Generation Firewalls (NGFW)
* Deep Packet and Flow Inspection (DPI)
* Intrusion Prevention Systems (IPS)
* DDoS Mitigation
* Network Monitoring
* Data Loss Prevention (DLP)
* Smart NICs
* Grammar based content processing
* URL, spam and adware filtering
* Advanced auditing and policing of user/application security policies
* Financial data mining - parsing of streamed financial feeds
* Application recognition.
* Dmemory introspection.
* Natural Language Processing (NLP)
* Sentiment Analysis.
* Big data databse acceleration.
* Computational storage. 

This patch set is based on RFC[1]

This class should be merged only after there is at least
one PMD that implements it. Also the test application will
be added when the first PMD is added.



[1] https://patches.dpdk.org/patch/66501/

v3:
* adress ML comments.

v2:
* address ML comments.


Jerin Jacob (1):
  regexdev: introduce regexdev subsystem

Ori Kam (3):
  regexdev: add regex core h file
  regexdev: add regexdev core functions
  regexdev: implement regex rte level functions

 config/common_base                           |    8 +
 config/meson.build                           |    1 +
 doc/api/doxy-api-index.md                    |    1 +
 doc/api/doxy-api.conf.in                     |    1 +
 doc/guides/prog_guide/index.rst              |    1 +
 doc/guides/prog_guide/regexdev_lib.rst       |  177 +++
 lib/Makefile                                 |    2 +
 lib/librte_regexdev/Makefile                 |   33 +
 lib/librte_regexdev/meson.build              |   10 +
 lib/librte_regexdev/rte_regexdev.c           |  573 ++++++++++
 lib/librte_regexdev/rte_regexdev.h           | 1534 ++++++++++++++++++++++++++
 lib/librte_regexdev/rte_regexdev_core.h      |  184 +++
 lib/librte_regexdev/rte_regexdev_driver.h    |   59 +
 lib/librte_regexdev/rte_regexdev_version.map |   26 +
 lib/meson.build                              |    2 +-
 meson_options.txt                            |    2 +
 16 files changed, 2613 insertions(+), 1 deletion(-)
 create mode 100644 doc/guides/prog_guide/regexdev_lib.rst
 create mode 100644 lib/librte_regexdev/Makefile
 create mode 100644 lib/librte_regexdev/meson.build
 create mode 100644 lib/librte_regexdev/rte_regexdev.c
 create mode 100644 lib/librte_regexdev/rte_regexdev.h
 create mode 100644 lib/librte_regexdev/rte_regexdev_core.h
 create mode 100644 lib/librte_regexdev/rte_regexdev_driver.h
 create mode 100644 lib/librte_regexdev/rte_regexdev_version.map

-- 
1.8.3.1


^ permalink raw reply	[flat|nested] 96+ messages in thread

* [dpdk-dev] [PATCH v3 1/4] regexdev: introduce regexdev subsystem
  2020-05-07  9:45 ` [dpdk-dev] [PATCH v3 0/4] add RegEx class Ori Kam
@ 2020-05-07  9:45   ` Ori Kam
  2020-06-21 11:18     ` Ori Kam
  2020-05-07  9:45   ` [dpdk-dev] [PATCH v3 2/4] regexdev: add regex core h file Ori Kam
                     ` (3 subsequent siblings)
  4 siblings, 1 reply; 96+ messages in thread
From: Ori Kam @ 2020-05-07  9:45 UTC (permalink / raw)
  To: jerinj, xiang.w.wang
  Cc: guyk, dev, pbhagavatula, shahafs, hemant.agrawal, opher, alexr,
	dovrat, pkapoor, nipun.gupta, bruce.richardson, yang.a.hong,
	harry.chang, gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai,
	yuyingxia, fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc,
	jim, hongjun.ni, j.bromhead, deri, fc, arthur.su, thomas, orika

From: Jerin Jacob <jerinj@marvell.com>

As RegEx usage become more used by DPDK applications, for example:
* Next Generation Firewalls (NGFW)
* Deep Packet and Flow Inspection (DPI)
* Intrusion Prevention Systems (IPS)
* DDoS Mitigation
* Network Monitoring
* Data Loss Prevention (DLP)
* Smart NICs
* Grammar based content processing
* URL, spam and adware filtering
* Advanced auditing and policing of user/application security policies
* Financial data mining - parsing of streamed financial feeds
* Application recognition.
* Dmemory introspection.
* Natural Language Processing (NLP)
* Sentiment Analysis.
* Big data databse acceleration.
* Computational storage.

Number of PMD providers started to work on HW implementation,
along side with SW implementations.

This lib adds the support for those kind of devices.

The RegEx Device API is composed of two parts:
- The application-oriented RegEx API that includes functions to setup
  a RegEx device (configure it, setup its queue pairs and start it),
  update the rule database and so on.

- The driver-oriented RegEx API that exports a function allowing
  a RegEx poll Mode Driver (PMD) to simultaneously register itself as
  a RegEx device driver.

RegEx device components and definitions:

    +-----------------+
    |                 |
    |                 o---------+    rte_regexdev_[en|de]queue_burst()
    |   PCRE based    o------+  |               |
    |  RegEx pattern  |      |  |  +--------+   |
    | matching engine o------+--+--o        |   |    +------+
    |                 |      |  |  | queue  |<==o===>|Core 0|
    |                 o----+ |  |  | pair 0 |        |      |
    |                 |    | |  |  +--------+        +------+
    +-----------------+    | |  |
           ^               | |  |  +--------+
           |               | |  |  |        |        +------+
           |               | +--+--o queue  |<======>|Core 1|
       Rule|Database       |    |  | pair 1 |        |      |
    +------+----------+    |    |  +--------+        +------+
    |     Group 0     |    |    |
    | +-------------+ |    |    |  +--------+        +------+
    | | Rules 0..n  | |    |    |  |        |        |Core 2|
    | +-------------+ |    |    +--o queue  |<======>|      |
    |     Group 1     |    |       | pair 2 |        +------+
    | +-------------+ |    |       +--------+
    | | Rules 0..n  | |    |
    | +-------------+ |    |       +--------+
    |     Group 2     |    |       |        |        +------+
    | +-------------+ |    |       | queue  |<======>|Core n|
    | | Rules 0..n  | |    +-------o pair n |        |      |
    | +-------------+ |            +--------+        +------+
    |     Group n     |
    | +-------------+ |<-------rte_regexdev_rule_db_update()
    | |             | |<-------rte_regexdev_rule_db_compile_activate()
    | | Rules 0..n  | |<-------rte_regexdev_rule_db_import()
    | +-------------+ |------->rte_regexdev_rule_db_export()
    +-----------------+

RegEx: A regular expression is a concise and flexible means for matching
strings of text, such as particular characters, words, or patterns of
characters. A common abbreviation for this is â~@~\RegExâ~@~].

RegEx device: A hardware or software-based implementation of RegEx
device API for PCRE based pattern matching syntax and semantics.

PCRE RegEx syntax and semantics specification:
http://regexkit.sourceforge.net/Documentation/pcre/pcrepattern.html

RegEx queue pair: Each RegEx device should have one or more queue pair to
transmit a burst of pattern matching request and receive a burst of
receive the pattern matching response. The pattern matching
request/response embedded in *rte_regex_ops* structure.

Rule: A pattern matching rule expressed in PCRE RegEx syntax along with
Match ID and Group ID to identify the rule upon the match.

Rule database: The RegEx device accepts regular expressions and converts
them into a compiled rule database that can then be used to scan data.
Compilation allows the device to analyze the given pattern(s) and
pre-determine how to scan for these patterns in an optimized fashion that
would be far too expensive to compute at run-time. A rule database
contains a set of rules that compiled in device specific binary form.

Match ID or Rule ID: A unique identifier provided at the time of rule
creation for the application to identify the rule upon match.

Group ID: Group of rules can be grouped under one group ID to enable
rule isolation and effective pattern matching. A unique group identifier
provided at the time of rule creation for the application to identify
the rule upon match.

Scan: A pattern matching request through *enqueue* API.

It may possible that a given RegEx device may not support all the
features
of PCRE. The application may probe unsupported features through
struct rte_regexdev_info::pcre_unsup_flags

By default, all the functions of the RegEx Device API exported by a PMD
are lock-free functions which assume to not be invoked in parallel on
different logical cores to work on the same target object. For instance,
the dequeue function of a PMD cannot be invoked in parallel on two logical
cores to operates on same RegEx queue pair. Of course, this function
can be invoked in parallel by different logical core on different queue
pair. It is the responsibility of the upper level application to
enforce this rule.

In all functions of the RegEx API, the RegEx device is
designated by an integer >= 0 named the device identifier *dev_id*

At the RegEx driver level, RegEx devices are represented by a generic
data structure of type *rte_regexdev*.
RegEx devices are dynamically registered during the PCI/SoC device
probing phase performed at EAL initialization time.
When a RegEx device is being probed, a *rte_regexdev* structure and
a new device identifier are allocated for that device. Then, the
regexdev_init() function supplied by the RegEx driver matching the
probed device is invoked to properly initialize the device.

The role of the device init function consists of resetting the hardware
or software RegEx driver implementations.

If the device init operation is successful, the correspondence between
the device identifier assigned to the new device and its associated
*rte_regexdev* structure is effectively registered.
Otherwise, both the *rte_regexdev* structure and the device identifier
are freed.

The functions exported by the application RegEx API to setup a device
designated by its device identifier must be invoked in the following
order:
    - rte_regexdev_configure()
    - rte_regexdev_queue_pair_setup()
    - rte_regexdev_start()

Then, the application can invoke, in any order, the functions
exported by the RegEx API to enqueue pattern matching job, dequeue
pattern matching response, get the stats, update the rule database,
get/set device attributes and so on

If the application wants to change the configuration (i.e. call
rte_regexdev_configure() or rte_regexdev_queue_pair_setup()), it must
call rte_regexdev_stop() first to stop the device and then do the
reconfiguration before calling rte_regexdev_start() again. The enqueue and
dequeue functions should not be invoked when the device is stopped.

Finally, an application can close a RegEx device by invoking the
rte_regexdev_close() function.

Each function of the application RegEx API invokes a specific function
of the PMD that controls the target device designated by its device
identifier.

For this purpose, all device-specific functions of a RegEx driver are
supplied through a set of pointers contained in a generic structure of
type *regexdev_ops*.
The address of the *regexdev_ops* structure is stored in the
*rte_regexdev* structure by the device init function of the RegEx driver,
which is invoked during the PCI/SoC device probing phase, as explained
earlier.

In other words, each function of the RegEx API simply retrieves the
*rte_regexdev* structure associated with the device identifier and
performs an indirect invocation of the corresponding driver function
supplied in the *regexdev_ops* structure of the *rte_regexdev*
structure.

For performance reasons, the address of the fast-path functions of the
RegEx driver is not contained in the *regexdev_ops* structure.
Instead, they are directly stored at the beginning of the *rte_regexdev*
structure to avoid an extra indirect memory access during their
invocation.

RTE RegEx device drivers do not use interrupts for enqueue or dequeue
operation. Instead, RegEx drivers export Poll-Mode enqueue and dequeue
functions to applications.

The *enqueue* operation submits a burst of RegEx pattern matching
request to the RegEx device and the *dequeue* operation gets a burst of
pattern matching response for the ones submitted through *enqueue*
operation.

Typical application utilisation of the RegEx device API will follow the
following programming flow.

- rte_regexdev_configure()
- rte_regexdev_queue_pair_setup()
- rte_regexdev_rule_db_update() Needs to invoke if precompiled rule
  database not
  provided in rte_regexdev_config::rule_db for rte_regexdev_configure()
  and/or application needs to update rule database.
- rte_regexdev_rule_db_compile_activate() Needs to invoke if
  rte_regexdev_rule_db_update function was used.
- Create or reuse exiting mempool for *rte_regex_ops* objects.
- rte_regexdev_start()
- rte_regexdev_enqueue_burst()
- rte_regexdev_dequeue_burst()

Signed-off-by: Jerin Jacob <jerinj@marvell.com>
Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
Signed-off-by: Ori Kam <orika@mellanox.com>
---
v3:
* No changes.

v2:
* Move unused define to other patch. 
---
 config/common_base                           |    6 +
 doc/api/doxy-api-index.md                    |    1 +
 doc/api/doxy-api.conf.in                     |    1 +
 doc/guides/prog_guide/index.rst              |    1 +
 doc/guides/prog_guide/regexdev_lib.rst       |  177 ++++
 lib/Makefile                                 |    2 +
 lib/librte_regexdev/Makefile                 |   31 +
 lib/librte_regexdev/meson.build              |    7 +
 lib/librte_regexdev/rte_regexdev.c           |    6 +
 lib/librte_regexdev/rte_regexdev.h           | 1473 ++++++++++++++++++++++++++
 lib/librte_regexdev/rte_regexdev_version.map |   26 +
 lib/meson.build                              |    2 +-
 12 files changed, 1732 insertions(+), 1 deletion(-)
 create mode 100644 doc/guides/prog_guide/regexdev_lib.rst
 create mode 100644 lib/librte_regexdev/Makefile
 create mode 100644 lib/librte_regexdev/meson.build
 create mode 100644 lib/librte_regexdev/rte_regexdev.c
 create mode 100644 lib/librte_regexdev/rte_regexdev.h
 create mode 100644 lib/librte_regexdev/rte_regexdev_version.map

diff --git a/config/common_base b/config/common_base
index 14000ba..27fcab1 100644
--- a/config/common_base
+++ b/config/common_base
@@ -832,6 +832,11 @@ CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_EP_RAWDEV=y
 CONFIG_RTE_LIBRTE_PMD_NTB_RAWDEV=y
 
 #
+# Compile regex device support
+#
+CONFIG_RTE_LIBRTE_REGEXDEV=y
+
+#
 # Compile librte_ring
 #
 CONFIG_RTE_LIBRTE_RING=y
@@ -1124,3 +1129,4 @@ CONFIG_RTE_APP_CRYPTO_PERF=y
 # Compile the eventdev application
 #
 CONFIG_RTE_APP_EVENTDEV=y
+
diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
index 845a534..702591b 100644
--- a/doc/api/doxy-api-index.md
+++ b/doc/api/doxy-api-index.md
@@ -26,6 +26,7 @@ The public API headers are grouped by topics:
   [event_timer_adapter]    (@ref rte_event_timer_adapter.h),
   [event_crypto_adapter]   (@ref rte_event_crypto_adapter.h),
   [rawdev]             (@ref rte_rawdev.h),
+  [regexdev]           (@ref rte_regexdev.h),
   [metrics]            (@ref rte_metrics.h),
   [bitrate]            (@ref rte_bitrate.h),
   [latency]            (@ref rte_latencystats.h),
diff --git a/doc/api/doxy-api.conf.in b/doc/api/doxy-api.conf.in
index 65e8146..84621ba 100644
--- a/doc/api/doxy-api.conf.in
+++ b/doc/api/doxy-api.conf.in
@@ -58,6 +58,7 @@ INPUT                   = @TOPDIR@/doc/api/doxy-api-index.md \
                           @TOPDIR@/lib/librte_rcu \
                           @TOPDIR@/lib/librte_reorder \
                           @TOPDIR@/lib/librte_rib \
+                          @TOPDIR@/lib/librte_regexdev \
                           @TOPDIR@/lib/librte_ring \
                           @TOPDIR@/lib/librte_sched \
                           @TOPDIR@/lib/librte_security \
diff --git a/doc/guides/prog_guide/index.rst b/doc/guides/prog_guide/index.rst
index 1d0cd49..fa8536c 100644
--- a/doc/guides/prog_guide/index.rst
+++ b/doc/guides/prog_guide/index.rst
@@ -71,3 +71,4 @@ Programmer's Guide
     lto
     profile_app
     glossary
+    regexdev_lib
diff --git a/doc/guides/prog_guide/regexdev_lib.rst b/doc/guides/prog_guide/regexdev_lib.rst
new file mode 100644
index 0000000..1ecbf1c
--- /dev/null
+++ b/doc/guides/prog_guide/regexdev_lib.rst
@@ -0,0 +1,177 @@
+..  SPDX-License-Identifier: BSD-3-Clause
+    Copyright(c) 2020 Mellanox Corporation.
+
+RegEx Device Library
+=====================
+
+The RegEx library provides a RegEx device framework for management and
+provisioning of hardware and software RegEx poll mode drivers, defining generic
+APIs which support a number of different RegEx operations.
+
+
+Design Principles
+-----------------
+
+The RegEx library follows the same basic principles as those used in DPDK's
+Ethernet Device framework and the Crypto framework. The RegEx framework provides
+a generic Crypto device framework which supports both physical (hardware)
+and virtual (software) RegEx devices as well as a generic RegEx API which allows
+RegEx devices to be managed and configured and supports RegEx operations to be
+provisioned on RegEx poll mode driver.
+
+
+Device Management
+-----------------
+
+Device Creation
+~~~~~~~~~~~~~~~
+
+Physical RegEx devices are discovered during the PCI probe/enumeration of the
+EAL function which is executed at DPDK initialization, based on
+their PCI device identifier, each unique PCI BDF (bus/bridge, device,
+function). Specific physical ReEx devices, like other physical devices in DPDK
+can be white-listed or black-listed using the EAL command line options.
+
+
+Device Identification
+~~~~~~~~~~~~~~~~~~~~~
+
+Each device, whether virtual or physical is uniquely designated by two
+identifiers:
+
+- A unique device index used to designate the RegEx device in all functions
+  exported by the regexdev API.
+
+- A device name used to designate the RegEx device in console messages, for
+  administration or debugging purposes.
+
+
+Device Configuration
+~~~~~~~~~~~~~~~~~~~~
+
+The configuration of each RegEx device includes the following operations:
+
+- Allocation of resources, including hardware resources if a physical device.
+- Resetting the device into a well-known default state.
+- Initialization of statistics counters.
+
+The rte_regexdev_configure API is used to configure a RegEx device.
+
+.. code-block:: c
+
+   int rte_regexdev_configure(uint8_t dev_id,
+                              const struct rte_regexdev_config *cfg);
+
+The ``rte_regexdev_config`` structure is used to pass the configuration
+parameters for the RegEx device for example  number of queue pairs, number of
+groups, max number of matches and so on.
+
+.. code-block:: c
+
+   struct rte_regexdev_config {
+        uint16_t nb_max_matches;
+        /**< Maximum matches per scan configured on this device.
+         * This value cannot exceed the *max_matches*
+         * which previously provided in rte_regexdev_info_get().
+         * The value 0 is allowed, in which case, value 1 used.
+         * @see struct rte_regexdev_info::max_matches
+         */
+        uint16_t nb_queue_pairs;
+        /**< Number of RegEx queue pairs to configure on this device.
+         * This value cannot exceed the *max_queue_pairs* which previously
+         * provided in rte_regexdev_info_get().
+         * @see struct rte_regexdev_info::max_queue_pairs
+         */
+        uint32_t nb_rules_per_group;
+        /**< Number of rules per group to configure on this device.
+         * This value cannot exceed the *max_rules_per_group*
+         * which previously provided in rte_regexdev_info_get().
+         * The value 0 is allowed, in which case,
+         * struct rte_regexdev_info::max_rules_per_group used.
+         * @see struct rte_regexdev_info::max_rules_per_group
+         */
+        uint16_t nb_groups;
+        /**< Number of groups to configure on this device.
+         * This value cannot exceed the *max_groups*
+         * which previously provided in rte_regexdev_info_get().
+         * @see struct rte_regexdev_info::max_groups
+         */
+        const char *rule_db;
+        /**< Import initial set of prebuilt rule database on this device.
+         * The value NULL is allowed, in which case, the device will not
+         * be configured prebuilt rule database. Application may use
+         * rte_regexdev_rule_db_update() or rte_regexdev_rule_db_import() API
+         * to update or import rule database after the
+         * rte_regexdev_configure().
+         * @see rte_regexdev_rule_db_update(), rte_regexdev_rule_db_import()
+         */
+        uint32_t rule_db_len;
+        /**< Length of *rule_db* buffer. */
+        uint32_t dev_cfg_flags;
+        /**< RegEx device configuration flags, See RTE_REGEXDEV_CFG_*  */
+    };
+
+
+Configuration of Rules Database
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Each Regex device should be configured with the rule database.
+There are two modes of setting the rule database, online or offline.
+The online mode means, that the rule database in being compiled by the
+RegEx PMD while in the offline mode the rule database is compiled by external
+compiler, and is being loaded to the PMD as a buffer.
+The configuration mode is depended on the PMD capabilities.
+
+Online rule configuration is done using the following API functions:
+``rte_regexdev_rule_db_update`` which add / remove rules from the rules
+precomplied list, and ``rte_regexdev_rule_db_compile_activate``
+which compile the rules and loads them to the RegEx HW.
+
+Offline rule configuration can be done by adding a pointer to the compiled
+rule database in the configuration step, or by using
+``rte_regexdev_rule_db_import`` API.
+
+
+Configuration of Queue Pairs
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Each RegEx device can be configured with number of queue pairs.
+Each queue pair is configured using ``rte_regexdev_queue_pair_setup``
+
+
+Logical Cores, Memory and Queues Pair Relationships
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Multiple logical cores should never share the same queue pair for enqueuing
+operations or dequeuing operations on the same RegEx device since this would
+require global locks and hinder performance.
+
+
+Device Features and Capabilities
+---------------------------------
+
+RegEx devices may support different feature set.
+In order to get the supported PMD feature ``rte_regexdev_info_get``
+API which return the info of the device and it's supported features.
+
+
+Enqueue / Dequeue Burst APIs
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The burst enqueue API uses a RegEx device identifier and a queue pair
+identifier to specify the device queue pair to schedule the processing on.
+The ``nb_ops`` parameter is the number of operations to process which are
+supplied in the ``ops`` array of ``rte_regex_ops`` structures.
+The enqueue function returns the number of operations it actually enqueued for
+processing, a return value equal to ``nb_ops`` means that all packets have been
+enqueued.
+
+Data pointed in each op, should not be released until the dequeue of for that
+op.
+
+The dequeue API uses the same format as the enqueue API of processed but
+the ``nb_ops`` and ``ops`` parameters are now used to specify the max processed
+operations the user wishes to retrieve and the location in which to store them.
+The API call returns the actual number of processed operations returned, this
+can never be larger than ``nb_ops``.
+
diff --git a/lib/Makefile b/lib/Makefile
index d0ec391..6a3d4e3 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -44,6 +44,8 @@ DEPDIRS-librte_eventdev := librte_eal librte_ring librte_ethdev librte_hash \
                            librte_mempool librte_timer librte_cryptodev
 DIRS-$(CONFIG_RTE_LIBRTE_RAWDEV) += librte_rawdev
 DEPDIRS-librte_rawdev := librte_eal librte_ethdev
+DIRS-$(CONFIG_RTE_LIBRTE_REGEXDEV) += librte_regexdev
+DEPDIRS-librte_regexdev := librte_eal librte_mbuf
 DIRS-$(CONFIG_RTE_LIBRTE_VHOST) += librte_vhost
 DEPDIRS-librte_vhost := librte_eal librte_mempool librte_mbuf librte_ethdev \
 			librte_net librte_hash librte_cryptodev
diff --git a/lib/librte_regexdev/Makefile b/lib/librte_regexdev/Makefile
new file mode 100644
index 0000000..6f4cc63
--- /dev/null
+++ b/lib/librte_regexdev/Makefile
@@ -0,0 +1,31 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(C) 2019 Marvell International Ltd.
+# Copyright(C) 2020 Mellanox International Ltd.
+#
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+# library name
+LIB = librte_regexdev.a
+
+EXPORT_MAP := rte_regex_version.map
+
+# library version
+LIBABIVER := 1
+
+# build flags
+CFLAGS += -O3
+CFLAGS += $(WERROR_FLAGS)
+LDLIBS += -lrte_eal -lrte_mbuf
+
+# library source files
+# all source are stored in SRCS-y
+SRCS-$(CONFIG_RTE_LIBRTE_REGEXDEV) := rte_regexdev.c
+
+# export include files
+SYMLINK-$(CONFIG_RTE_LIBRTE_REGEXDEV)-include += rte_regexdev.h
+
+# versioning export map
+EXPORT_MAP := rte_regexdev_version.map
+
+include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_regexdev/meson.build b/lib/librte_regexdev/meson.build
new file mode 100644
index 0000000..f4db748
--- /dev/null
+++ b/lib/librte_regexdev/meson.build
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2020 Mellanox Corporation
+
+allow_experimental_apis = true
+sources = files('rte_regexdev.c')
+headers = files('rte_regexdev.h')
+deps += ['mbuf']
diff --git a/lib/librte_regexdev/rte_regexdev.c b/lib/librte_regexdev/rte_regexdev.c
new file mode 100644
index 0000000..b901877
--- /dev/null
+++ b/lib/librte_regexdev/rte_regexdev.c
@@ -0,0 +1,6 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2019 Marvell International Ltd.
+ * Copyright(C) 2020 Mellanox International Ltd.
+ */
+
+#include <rte_regexdev.h>
diff --git a/lib/librte_regexdev/rte_regexdev.h b/lib/librte_regexdev/rte_regexdev.h
new file mode 100644
index 0000000..7e688d9
--- /dev/null
+++ b/lib/librte_regexdev/rte_regexdev.h
@@ -0,0 +1,1473 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2019 Marvell International Ltd.
+ * Copyright(C) 2020 Mellanox International Ltd.
+ * Copyright(C) 2020 Intel International Ltd.
+ */
+
+#ifndef _RTE_REGEXDEV_H_
+#define _RTE_REGEXDEV_H_
+
+/**
+ * @file
+ *
+ * RTE RegEx Device API
+ *
+ * Defines RTE RegEx Device APIs for RegEx operations and its provisioning.
+ *
+ * The RegEx Device API is composed of two parts:
+ *
+ * - The application-oriented RegEx API that includes functions to setup
+ *   a RegEx device (configure it, setup its queue pairs and start it),
+ *   update the rule database and so on.
+ *
+ * - The driver-oriented RegEx API that exports a function allowing
+ *   a RegEx poll Mode Driver (PMD) to simultaneously register itself as
+ *   a RegEx device driver.
+ *
+ * RegEx device components and definitions:
+ *
+ *     +-----------------+
+ *     |                 |
+ *     |                 o---------+    rte_regexdev_[en|de]queue_burst()
+ *     |   PCRE based    o------+  |               |
+ *     |  RegEx pattern  |      |  |  +--------+   |
+ *     | matching engine o------+--+--o        |   |    +------+
+ *     |                 |      |  |  | queue  |<==o===>|Core 0|
+ *     |                 o----+ |  |  | pair 0 |        |      |
+ *     |                 |    | |  |  +--------+        +------+
+ *     +-----------------+    | |  |
+ *            ^               | |  |  +--------+
+ *            |               | |  |  |        |        +------+
+ *            |               | +--+--o queue  |<======>|Core 1|
+ *        Rule|Database       |    |  | pair 1 |        |      |
+ *     +------+----------+    |    |  +--------+        +------+
+ *     |     Group 0     |    |    |
+ *     | +-------------+ |    |    |  +--------+        +------+
+ *     | | Rules 0..n  | |    |    |  |        |        |Core 2|
+ *     | +-------------+ |    |    +--o queue  |<======>|      |
+ *     |     Group 1     |    |       | pair 2 |        +------+
+ *     | +-------------+ |    |       +--------+
+ *     | | Rules 0..n  | |    |
+ *     | +-------------+ |    |       +--------+
+ *     |     Group 2     |    |       |        |        +------+
+ *     | +-------------+ |    |       | queue  |<======>|Core n|
+ *     | | Rules 0..n  | |    +-------o pair n |        |      |
+ *     | +-------------+ |            +--------+        +------+
+ *     |     Group n     |
+ *     | +-------------+ |<-------rte_regexdev_rule_db_update()
+ *     | |             | |<-------rte_regexdev_rule_db_compile_activate()
+ *     | | Rules 0..n  | |<-------rte_regexdev_rule_db_import()
+ *     | +-------------+ |------->rte_regexdev_rule_db_export()
+ *     +-----------------+
+ *
+ * RegEx: A regular expression is a concise and flexible means for matching
+ * strings of text, such as particular characters, words, or patterns of
+ * characters. A common abbreviation for this is “RegEx”.
+ *
+ * RegEx device: A hardware or software-based implementation of RegEx
+ * device API for PCRE based pattern matching syntax and semantics.
+ *
+ * PCRE RegEx syntax and semantics specification:
+ * http://regexkit.sourceforge.net/Documentation/pcre/pcrepattern.html
+ *
+ * RegEx queue pair: Each RegEx device should have one or more queue pair to
+ * transmit a burst of pattern matching request and receive a burst of
+ * receive the pattern matching response. The pattern matching request/response
+ * embedded in *rte_regex_ops* structure.
+ *
+ * Rule: A pattern matching rule expressed in PCRE RegEx syntax along with
+ * Match ID and Group ID to identify the rule upon the match.
+ *
+ * Rule database: The RegEx device accepts regular expressions and converts them
+ * into a compiled rule database that can then be used to scan data.
+ * Compilation allows the device to analyze the given pattern(s) and
+ * pre-determine how to scan for these patterns in an optimized fashion that
+ * would be far too expensive to compute at run-time. A rule database contains
+ * a set of rules that compiled in device specific binary form.
+ *
+ * Match ID or Rule ID: A unique identifier provided at the time of rule
+ * creation for the application to identify the rule upon match.
+ *
+ * Group ID: Group of rules can be grouped under one group ID to enable
+ * rule isolation and effective pattern matching. A unique group identifier
+ * provided at the time of rule creation for the application to identify the
+ * rule upon match.
+ *
+ * Scan: A pattern matching request through *enqueue* API.
+ *
+ * It may possible that a given RegEx device may not support all the features
+ * of PCRE. The application may probe unsupported features through
+ * struct rte_regexdev_info::pcre_unsup_flags
+ *
+ * By default, all the functions of the RegEx Device API exported by a PMD
+ * are lock-free functions which assume to not be invoked in parallel on
+ * different logical cores to work on the same target object. For instance,
+ * the dequeue function of a PMD cannot be invoked in parallel on two logical
+ * cores to operates on same RegEx queue pair. Of course, this function
+ * can be invoked in parallel by different logical core on different queue pair.
+ * It is the responsibility of the upper level application to enforce this rule.
+ *
+ * In all functions of the RegEx API, the RegEx device is
+ * designated by an integer >= 0 named the device identifier *dev_id*
+ *
+ * At the RegEx driver level, RegEx devices are represented by a generic
+ * data structure of type *rte_regexdev*.
+ *
+ * RegEx devices are dynamically registered during the PCI/SoC device probing
+ * phase performed at EAL initialization time.
+ * When a RegEx device is being probed, a *rte_regexdev* structure and
+ * a new device identifier are allocated for that device. Then, the
+ * regexdev_init() function supplied by the RegEx driver matching the probed
+ * device is invoked to properly initialize the device.
+ *
+ * The role of the device init function consists of resetting the hardware or
+ * software RegEx driver implementations.
+ *
+ * If the device init operation is successful, the correspondence between
+ * the device identifier assigned to the new device and its associated
+ * *rte_regexdev* structure is effectively registered.
+ * Otherwise, both the *rte_regexdev* structure and the device identifier are
+ * freed.
+ *
+ * The functions exported by the application RegEx API to setup a device
+ * designated by its device identifier must be invoked in the following order:
+ *     - rte_regexdev_configure()
+ *     - rte_regexdev_queue_pair_setup()
+ *     - rte_regexdev_start()
+ *
+ * Then, the application can invoke, in any order, the functions
+ * exported by the RegEx API to enqueue pattern matching job, dequeue pattern
+ * matching response, get the stats, update the rule database,
+ * get/set device attributes and so on
+ *
+ * If the application wants to change the configuration (i.e. call
+ * rte_regexdev_configure() or rte_regexdev_queue_pair_setup()), it must call
+ * rte_regexdev_stop() first to stop the device and then do the reconfiguration
+ * before calling rte_regexdev_start() again. The enqueue and dequeue
+ * functions should not be invoked when the device is stopped.
+ *
+ * Finally, an application can close a RegEx device by invoking the
+ * rte_regexdev_close() function.
+ *
+ * Each function of the application RegEx API invokes a specific function
+ * of the PMD that controls the target device designated by its device
+ * identifier.
+ *
+ * For this purpose, all device-specific functions of a RegEx driver are
+ * supplied through a set of pointers contained in a generic structure of type
+ * *regexdev_ops*.
+ * The address of the *regexdev_ops* structure is stored in the *rte_regexdev*
+ * structure by the device init function of the RegEx driver, which is
+ * invoked during the PCI/SoC device probing phase, as explained earlier.
+ *
+ * In other words, each function of the RegEx API simply retrieves the
+ * *rte_regexdev* structure associated with the device identifier and
+ * performs an indirect invocation of the corresponding driver function
+ * supplied in the *regexdev_ops* structure of the *rte_regexdev* structure.
+ *
+ * For performance reasons, the address of the fast-path functions of the
+ * RegEx driver is not contained in the *regexdev_ops* structure.
+ * Instead, they are directly stored at the beginning of the *rte_regexdev*
+ * structure to avoid an extra indirect memory access during their invocation.
+ *
+ * RTE RegEx device drivers do not use interrupts for enqueue or dequeue
+ * operation. Instead, RegEx drivers export Poll-Mode enqueue and dequeue
+ * functions to applications.
+ *
+ * The *enqueue* operation submits a burst of RegEx pattern matching request
+ * to the RegEx device and the *dequeue* operation gets a burst of pattern
+ * matching response for the ones submitted through *enqueue* operation.
+ *
+ * Typical application utilisation of the RegEx device API will follow the
+ * following programming flow.
+ *
+ * - rte_regexdev_configure()
+ * - rte_regexdev_queue_pair_setup()
+ * - rte_regexdev_rule_db_update() Needs to invoke if precompiled rule database
+ *   not provided in rte_regexdev_config::rule_db for rte_regexdev_configure()
+ *   and/or application needs to update rule database.
+ * - rte_regexdev_rule_db_compile_activate() Needs to invoke if
+ *   rte_regexdev_rule_db_update function was used.
+ * - Create or reuse exiting mempool for *rte_regex_ops* objects.
+ * - rte_regexdev_start()
+ * - rte_regexdev_enqueue_burst()
+ * - rte_regexdev_dequeue_burst()
+ *
+ */
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include <rte_common.h>
+#include <rte_config.h>
+#include <rte_dev.h>
+#include <rte_errno.h>
+#include <rte_mbuf.h>
+#include <rte_memory.h>
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Get the total number of RegEx devices that have been successfully
+ * initialised.
+ *
+ * @return
+ *   The total number of usable RegEx devices.
+ */
+__rte_experimental
+uint8_t
+rte_regexdev_count(void);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Get the device identifier for the named RegEx device.
+ *
+ * @param name
+ *   RegEx device name to select the RegEx device identifier.
+ *
+ * @return
+ *   Returns RegEx device identifier on success.
+ *   - <0: Failure to find named RegEx device.
+ */
+__rte_experimental
+int
+rte_regexdev_get_dev_id(const char *name);
+
+/* Enumerates RegEx device capabilities */
+#define RTE_REGEXDEV_CAPA_RUNTIME_COMPILATION_F (1ULL << 0)
+/**< RegEx device does support compiling the rules at runtime unlike
+ * loading only the pre-built rule database using
+ * struct rte_regexdev_config::rule_db in rte_regexdev_configure()
+ *
+ * @see struct rte_regexdev_config::rule_db, rte_regexdev_configure()
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_CAPA_SUPP_PCRE_START_ANCHOR_F (1ULL << 1)
+/**< RegEx device support PCRE Anchor to start of match flag.
+ * Example RegEx is '/\Gfoo\d/'. Here '\G' asserts position at the end of the
+ * previous match or the start of the string for the first match.
+ * This position will change each time the RegEx is applied to the subject
+ * string. If the RegEx is applied to 'foo1foo2Zfoo3' the first two matches will
+ * be successful for 'foo1foo2' and fail for 'Zfoo3'.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_CAPA_SUPP_PCRE_ATOMIC_GROUPING_F (1ULL << 2)
+/**< RegEx device support PCRE Atomic grouping.
+ * Atomic groups are represented by '(?>)'. An atomic group is a group that,
+ * when the RegEx engine exits from it, automatically throws away all
+ * backtracking positions remembered by any tokens inside the group.
+ * Example RegEx is 'a(?>bc|b)c' if the given patterns are 'abc' and 'abcc' then
+ * 'a(bc|b)c' matches both where as 'a(?>bc|b)c' matches only abcc because
+ * atomic groups don't allow backtracing back to 'b'.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_BACKTRACKING_CTRL_F (1ULL << 3)
+/**< RegEx device support PCRE backtracking control verbs.
+ * Some examples of backtracing verbs are (*COMMIT), (*ACCEPT), (*FAIL),
+ * (*SKIP), (*PRUNE).
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_CALLOUTS_F (1ULL << 4)
+/**< RegEx device support PCRE callouts.
+ * PCRE supports calling external function in between matches by using '(?C)'.
+ * Example RegEx 'ABC(?C)D' if a given patter is 'ABCD' then the RegEx engine
+ * will parse ABC perform a userdefined callout and return a successful match at
+ * D.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_BACKREFERENCE_F (1ULL << 5)
+/**< RegEx device support PCRE backreference.
+ * Example RegEx is '(\2ABC|(GHI))+' \2 matches the same text as most recently
+ * matched by the 2nd capturing group i.e. 'GHI'.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_GREEDY_F (1ULL << 6)
+/**< RegEx device support PCRE Greedy mode.
+ * For example if the RegEx is 'AB\d*?' then '*?' represents zero or unlimited
+ * matches. In greedy mode the pattern 'AB12345' will be matched completely
+ * where as the ungreedy mode 'AB' will be returned as the match.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_MATCH_ALL_F (1ULL << 7)
+/**< RegEx device support match all mode.
+ * For example if the RegEx is 'AB\d*?' then '*?' represents zero or unlimited
+ * matches. In match all mode the pattern 'AB12345' will return 6 matches.
+ * AB, AB1, AB12, AB123, AB1234, AB12345.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_LOOKAROUND_ASRT_F (1ULL << 8)
+/**< RegEx device support PCRE Lookaround assertions
+ * (Zero-width assertions). Example RegEx is '[a-z]+\d+(?=!{3,})' if
+ * the given pattern is 'dwad1234!' the RegEx engine doesn't report any matches
+ * because the assert '(?=!{3,})' fails. The pattern 'dwad123!!!' would return a
+ * successful match.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_MATCH_POINT_RST_F (1ULL << 9)
+/**< RegEx device doesn't support PCRE match point reset directive.
+ * Example RegEx is '[a-z]+\K\d+' if the pattern is 'dwad123'
+ * then even though the entire pattern matches only '123'
+ * is reported as a match.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_NEWLINE_CONVENTIONS_F (1ULL << 10)
+/**< RegEx support PCRE newline convention.
+ * Newline conventions are represented as follows:
+ * (*CR)        carriage return
+ * (*LF)        linefeed
+ * (*CRLF)      carriage return, followed by linefeed
+ * (*ANYCRLF)   any of the three above
+ * (*ANY)       all Unicode newline sequences
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_NEWLINE_SEQ_F (1ULL << 11)
+/**< RegEx device support PCRE newline sequence.
+ * The escape sequence '\R' will match any newline sequence.
+ * It is equivalent to: '(?>\r\n|\n|\x0b|\f|\r|\x85)'.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_POSSESSIVE_QUALIFIERS_F (1ULL << 12)
+/**< RegEx device support PCRE possessive qualifiers.
+ * Example RegEx possessive qualifiers '*+', '++', '?+', '{m,n}+'.
+ * Possessive quantifier repeats the token as many times as possible and it does
+ * not give up matches as the engine backtracks. With a possessive quantifier,
+ * the deal is all or nothing.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_SUBROUTINE_REFERENCES_F (1ULL << 13)
+/**< RegEx device support PCRE Subroutine references.
+ * PCRE Subroutine references allow for sub patterns to be assessed
+ * as part of the RegEx. Example RegEx is '(foo|fuzz)\g<1>+bar' matches the
+ * pattern 'foofoofuzzfoofuzzbar'.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_UTF_8_F (1ULL << 14)
+/**< RegEx device support UTF-8 character encoding.
+ *
+ * @see struct rte_regexdev_info::pcre_unsup_flags
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_UTF_16_F (1ULL << 15)
+/**< RegEx device support UTF-16 character encoding.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_UTF_32_F (1ULL << 16)
+/**< RegEx device support UTF-32 character encoding.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_WORD_BOUNDARY_F (1ULL << 17)
+/**< RegEx device support word boundaries.
+ * The meta character '\b' represents word boundary anchor.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_FORWARD_REFERENCES_F (1ULL << 18)
+/**< RegEx device support Forward references.
+ * Forward references allow you to use a back reference to a group that appears
+ * later in the RegEx. Example RegEx is '(\3ABC|(DEF|(GHI)))+' matches the
+ * following string 'GHIGHIABCDEF'.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_MATCH_AS_END_F (1ULL << 19)
+/**< RegEx device support match as end.
+ * Match as end means that the match result holds the end offset of the
+ * detected match. No len value is set.
+ * If the device doesn't support this feature it means the match
+ * result holds the starting position of match and the length of the match.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_CROSS_BUFFER_F (1ULL << 20)
+/**< RegEx device support cross buffer match.
+ * Cross buffer matching means that the match can be detected even if the
+ * string was started in previous buffer.
+ * In case the device is configured as RTE_REGEXDEV_CFG_MATCH_AS_END
+ * the end offset will be relative for the first packet.
+ * For example RegEx is ABC the first buffer is xxxx second buffer yyyA and
+ * the last buffer BCzz.
+ * In case the match as end is configured the end offset will be 10.
+ *
+ * @see RTE_REGEXDEV_CFG_MATCH_AS_END_F
+ * @see RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F
+ * @see RTE_REGEX_OPS_RSP_PMI_SOJ_F
+ * @see RTE_REGEX_OPS_RSP_PMI_EOJ_F
+ */
+
+#define RTE_REGEXDEV_SUPP_MATCH_ALL_F (1ULL << 21)
+/**< RegEx device support match all.
+ * Match all means that the RegEx engine will return all possible matches.
+ * For example, assume the RegEx is 'A+b', given the input AAAb the
+ * returned matches will be: Ab, AAb and AAAb.
+ *
+ * @see RTE_REGEXDEV_CFG_MATCH_ALL_F
+ */
+
+/* Enumerates PCRE rule flags */
+#define RTE_REGEX_PCRE_RULE_ALLOW_EMPTY_F (1ULL << 0)
+/**< When this flag is set, the pattern that can match against an empty string,
+ * such as '.*' are allowed.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_ANCHORED_F (1ULL << 1)
+/**< When this flag is set, the pattern is forced to be "anchored", that is, it
+ * is constrained to match only at the first matching point in the string that
+ * is being searched. Similar to '^' and represented by \A.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_CASELESS_F (1ULL << 2)
+/**< When this flag is set, letters in the pattern match both upper and lower
+ * case letters in the subject.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_DOTALL_F (1ULL << 3)
+/**< When this flag is set, a dot metacharacter in the pattern matches any
+ * character, including one that indicates a newline.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_DUPNAMES_F (1ULL << 4)
+/**< When this flag is set, names used to identify capture groups need not be
+ * unique.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_EXTENDED_F (1ULL << 5)
+/**< When this flag is set, most white space characters in the pattern are
+ * totally ignored except when escaped or inside a character class.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_MATCH_UNSET_BACKREF_F (1ULL << 6)
+/**< When this flag is set, a backreference to an unset capture group matches an
+ * empty string.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_MULTILINE_F (1ULL << 7)
+/**< When this flag  is set, the '^' and '$' constructs match immediately
+ * following or immediately before internal newlines in the subject string,
+ * respectively, as well as at the very start and end.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_NO_AUTO_CAPTURE_F (1ULL << 8)
+/**< When this Flag is set, it disables the use of numbered capturing
+ * parentheses in the pattern. References to capture groups (backreferences or
+ * recursion/subroutine calls) may only refer to named groups, though the
+ * reference can be by name or by number.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_UCP_F (1ULL << 9)
+/**< By default, only ASCII characters are recognized, When this flag is set,
+ * Unicode properties are used instead to classify characters.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_UNGREEDY_F (1ULL << 10)
+/**< When this flag is set, the "greediness" of the quantifiers is inverted
+ * so that they are not greedy by default, but become greedy if followed by
+ * '?'.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_UTF_F (1ULL << 11)
+/**< When this flag is set, RegEx engine has to regard both the pattern and the
+ * subject strings that are subsequently processed as strings of UTF characters
+ * instead of single-code-unit strings.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_NEVER_BACKSLASH_C_F (1ULL << 12)
+/**< This flag locks out the use of '\C' in the pattern that is being compiled.
+ * This escape matches one data unit, even in UTF mode which can cause
+ * unpredictable behavior in UTF-8 or UTF-16 modes, because it may leave the
+ * current matching point in the mi:set hlsearchddle of a multi-code-unit
+ * character.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+/**
+ * RegEx device information
+ */
+struct rte_regexdev_info {
+	const char *driver_name; /**< RegEx driver name. */
+	struct rte_device *dev;	/**< Device information. */
+	uint16_t max_matches;
+	/**< Maximum matches per scan supported by this device. */
+	uint16_t max_queue_pairs;
+	/**< Maximum queue pairs supported by this device. */
+	uint16_t max_payload_size;
+	/**< Maximum payload size for a pattern match request or scan.
+	 * @see RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F
+	 */
+	uint32_t max_rules_per_group;
+	/**< Maximum rules supported per group by this device. */
+	uint16_t max_groups;
+	/**< Maximum groups supported by this device. */
+	uint32_t regexdev_capa;
+	/**< RegEx device capabilities. @see RTE_REGEXDEV_CAPA_* */
+	uint64_t rule_flags;
+	/**< Supported compiler rule flags.
+	 * @see RTE_REGEX_PCRE_RULE_*, struct rte_regexdev_rule::rule_flags
+	 */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Retrieve the contextual information of a RegEx device.
+ *
+ * @param dev_id
+ *   The identifier of the device.
+ *
+ * @param[out] dev_info
+ *   A pointer to a structure of type *rte_regexdev_info* to be filled with the
+ *   contextual information of the device.
+ *
+ * @return
+ *   - 0: Success, driver updates the contextual information of the RegEx device
+ *   - <0: Error code returned by the driver info get function.
+ */
+__rte_experimental
+int
+rte_regexdev_info_get(uint8_t dev_id, struct rte_regexdev_info *dev_info);
+
+/* Enumerates RegEx device configuration flags */
+#define RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F (1ULL << 0)
+/**< Cross buffer scan refers to the ability to be able to detect
+ * matches that occur across buffer boundaries, where the buffers are related
+ * to each other in some way. Enable this flag when to scan payload size
+ * greater than struct rte_regexdev_info::max_payload_size and/or
+ * matches can present across scan buffer boundaries.
+ *
+ * @see struct rte_regexdev_info::max_payload_size
+ * @see struct rte_regexdev_config::dev_cfg_flags, rte_regexdev_configure()
+ * @see RTE_REGEX_OPS_RSP_PMI_SOJ_F
+ * @see RTE_REGEX_OPS_RSP_PMI_EOJ_F
+ */
+
+#define RTE_REGEXDEV_CFG_MATCH_AS_END_F (1ULL << 1)
+/**< Match as end is the ability to return the result as ending offset.
+ * When this flag is set, the result for each match will hold the ending
+ * offset of the match in end_offset.
+ * If this flag is not set, then the match result will hold the starting offset
+ * in start_offset, and the length of the match in len.
+ *
+ * @see RTE_REGEXDEV_SUPP_MATCH_AS_END_F
+ */
+
+#define RTE_REGEXDEV_CFG_MATCH_ALL_F (1ULL << 2)
+/**< Match all is the ability to return all possible results.
+ *
+ * @see RTE_REGEXDEV_SUPP_MATCH_ALL_F
+ */
+
+/** RegEx device configuration structure */
+struct rte_regexdev_config {
+	uint16_t nb_max_matches;
+	/**< Maximum matches per scan configured on this device.
+	 * This value cannot exceed the *max_matches*
+	 * which previously provided in rte_regexdev_info_get().
+	 * The value 0 is allowed, in which case, value 1 used.
+	 * @see struct rte_regexdev_info::max_matches
+	 */
+	uint16_t nb_queue_pairs;
+	/**< Number of RegEx queue pairs to configure on this device.
+	 * This value cannot exceed the *max_queue_pairs* which previously
+	 * provided in rte_regexdev_info_get().
+	 * @see struct rte_regexdev_info::max_queue_pairs
+	 */
+	uint32_t nb_rules_per_group;
+	/**< Number of rules per group to configure on this device.
+	 * This value cannot exceed the *max_rules_per_group*
+	 * which previously provided in rte_regexdev_info_get().
+	 * The value 0 is allowed, in which case,
+	 * struct rte_regexdev_info::max_rules_per_group used.
+	 * @see struct rte_regexdev_info::max_rules_per_group
+	 */
+	uint16_t nb_groups;
+	/**< Number of groups to configure on this device.
+	 * This value cannot exceed the *max_groups*
+	 * which previously provided in rte_regexdev_info_get().
+	 * @see struct rte_regexdev_info::max_groups
+	 */
+	const char *rule_db;
+	/**< Import initial set of prebuilt rule database on this device.
+	 * The value NULL is allowed, in which case, the device will not
+	 * be configured prebuilt rule database. Application may use
+	 * rte_regexdev_rule_db_update() or rte_regexdev_rule_db_import() API
+	 * to update or import rule database after the
+	 * rte_regexdev_configure().
+	 * @see rte_regexdev_rule_db_update(), rte_regexdev_rule_db_import()
+	 */
+	uint32_t rule_db_len;
+	/**< Length of *rule_db* buffer. */
+	uint32_t dev_cfg_flags;
+	/**< RegEx device configuration flags, See RTE_REGEXDEV_CFG_*  */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Configure a RegEx device.
+ *
+ * This function must be invoked first before any other function in the
+ * API. This function can also be re-invoked when a device is in the
+ * stopped state.
+ *
+ * The caller may use rte_regexdev_info_get() to get the capability of each
+ * resources available for this regex device.
+ *
+ * @param dev_id
+ *   The identifier of the device to configure.
+ * @param cfg
+ *   The RegEx device configuration structure.
+ *
+ * @return
+ *   - 0: Success, device configured. Otherwise negative errno is returned.
+ */
+__rte_experimental
+int
+rte_regexdev_configure(uint8_t dev_id, const struct rte_regexdev_config *cfg);
+
+/* Enumerates RegEx queue pair configuration flags */
+#define RTE_REGEX_QUEUE_PAIR_CFG_OOS_F (1ULL << 0)
+/**< Out of order scan, If not set, a scan must retire after previously issued
+ * in-order scans to this queue pair. If set, this scan can be retired as soon
+ * as device returns completion. Application should not set out of order scan
+ * flag if it needs to maintain the ingress order of scan request.
+ *
+ * @see struct rte_regexdev_qp_conf::qp_conf_flags
+ * @see rte_regexdev_queue_pair_setup()
+ */
+
+struct rte_regex_ops;
+typedef void (*regexdev_stop_flush_t)(uint8_t dev_id, uint16_t qp_id,
+				      struct rte_regex_ops *op);
+/**< Callback function called during rte_regexdev_stop(), invoked once per
+ * flushed RegEx op.
+ */
+
+/** RegEx queue pair configuration structure */
+struct rte_regexdev_qp_conf {
+	uint32_t qp_conf_flags;
+	/**< Queue pair config flags, See RTE_REGEX_QUEUE_PAIR_CFG_* */
+	uint16_t nb_desc;
+	/**< The number of descriptors to allocate for this queue pair. */
+	regexdev_stop_flush_t cb;
+	/**< Callback function called during rte_regexdev_stop(), invoked
+	 * once per flushed regex op. Value NULL is allowed, in which case
+	 * callback will not be invoked. This function can be used to properly
+	 * dispose of outstanding regex ops from response queue,
+	 * for example ops containing memory pointers.
+	 * @see rte_regexdev_stop()
+	 */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Allocate and set up a RegEx queue pair for a RegEx device.
+ *
+ * @param dev_id
+ *   The identifier of the device.
+ * @param queue_pair_id
+ *   The index of the RegEx queue pair to setup. The value must be in the range
+ *   [0, nb_queue_pairs - 1] previously supplied to rte_regexdev_configure().
+ * @param qp_conf
+ *   The pointer to the configuration data to be used for the RegEx queue pair.
+ *   NULL value is allowed, in which case default configuration	used.
+ *
+ * @return
+ *   0 on success. Otherwise negative errno is returned.
+ */
+__rte_experimental
+int
+rte_regexdev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
+			      const struct rte_regexdev_qp_conf *qp_conf);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Start a RegEx device.
+ *
+ * The device start step is the last one and consists of setting the RegEx
+ * queues to start accepting the pattern matching scan requests.
+ *
+ * On success, all basic functions exported by the API (RegEx enqueue,
+ * RegEx dequeue and so on) can be invoked.
+ *
+ * @param dev_id
+ *   RegEx device identifier.
+ *
+ * @return
+ *   0 on success. Otherwise negative errno is returned.
+ */
+__rte_experimental
+int
+rte_regexdev_start(uint8_t dev_id);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Stop a RegEx device.
+ *
+ * Stop a RegEx device. The device can be restarted with a call to
+ * rte_regexdev_start().
+ *
+ * This function causes all queued response regex ops to be drained in the
+ * response queue. While draining ops out of the device,
+ * struct rte_regexdev_qp_conf::cb will be invoked for each ops.
+ *
+ * @param dev_id
+ *   RegEx device identifier.
+ *
+ * @see struct rte_regexdev_qp_conf::cb, rte_regexdev_queue_pair_setup()
+ */
+__rte_experimental
+void
+rte_regexdev_stop(uint8_t dev_id);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Close a RegEx device. The device cannot be restarted!
+ *
+ * @param dev_id
+ *   RegEx device identifier
+ *
+ * @return
+ *   0 on success. Otherwise negative errno is returned.
+ */
+__rte_experimental
+int
+rte_regexdev_close(uint8_t dev_id);
+
+/* Device get/set attributes */
+
+/** Enumerates RegEx device attribute identifier */
+enum rte_regexdev_attr_id {
+	RTE_REGEXDEV_ATTR_SOCKET_ID,
+	/**< The NUMA socket id to which the device is connected or
+	 * a default of zero if the socket could not be determined.
+	 * datatype: *int*
+	 * operation: *get*
+	 */
+	RTE_REGEXDEV_ATTR_MAX_MATCHES,
+	/**< Maximum number of matches per scan.
+	 * datatype: *uint8_t*
+	 * operation: *get* and *set*
+	 * @see RTE_REGEX_OPS_RSP_MAX_MATCH_F
+	 */
+	RTE_REGEXDEV_ATTR_MAX_SCAN_TIMEOUT,
+	/**< Upper bound scan time in ns.
+	 * datatype: *uint16_t*
+	 * operation: *get* and *set*
+	 * @see RTE_REGEX_OPS_RSP_MAX_SCAN_TIMEOUT_F
+	 */
+	RTE_REGEXDEV_ATTR_MAX_PREFIX,
+	/**< Maximum number of prefix detected per scan.
+	 * This would be useful for denial of service detection.
+	 * datatype: *uint16_t*
+	 * operation: *get* and *set*
+	 * @see RTE_REGEX_OPS_RSP_MAX_PREFIX_F
+	 */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Get an attribute from a RegEx device.
+ *
+ * @param dev_id
+ *   RegEx device identifier.
+ * @param attr_id
+ *   The attribute ID to retrieve.
+ * @param attr_value
+ *   A pointer that will be filled in with the attribute
+ *   value if successful.
+ *
+ * @return
+ *   - 0: Successfully retrieved attribute value.
+ *   - -EINVAL: Invalid device or  *attr_id* provided, or *attr_value* is NULL.
+ *   - -ENOTSUP: if the device doesn't support specific *attr_id*.
+ */
+__rte_experimental
+int
+rte_regexdev_attr_get(uint8_t dev_id, enum rte_regexdev_attr_id attr_id,
+		      void *attr_value);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Set an attribute to a RegEx device.
+ *
+ * @param dev_id
+ *   RegEx device identifier.
+ * @param attr_id
+ *   The attribute ID to retrieve.
+ * @param attr_value
+ *   Pointer that will be filled in with the attribute value
+ *   by the application.
+ *
+ * @return
+ *   - 0: Successfully applied the attribute value.
+ *   - -EINVAL: Invalid device or  *attr_id* provided, or *attr_value* is NULL.
+ *   - -ENOTSUP: if the device doesn't support specific *attr_id*.
+ */
+__rte_experimental
+int
+rte_regexdev_attr_set(uint8_t dev_id, enum rte_regexdev_attr_id attr_id,
+		      const void *attr_value);
+
+/* Rule related APIs */
+/** Enumerates RegEx rule operation. */
+enum rte_regexdev_rule_op {
+	RTE_REGEX_RULE_OP_ADD,
+	/**< Add RegEx rule to rule database. */
+	RTE_REGEX_RULE_OP_REMOVE
+	/**< Remove RegEx rule from rule database. */
+};
+
+/** Structure to hold a RegEx rule attributes. */
+struct rte_regexdev_rule {
+	enum rte_regexdev_rule_op op;
+	/**< OP type of the rule either a OP_ADD or OP_DELETE. */
+	uint16_t group_id;
+	/**< Group identifier to which the rule belongs to. */
+	uint32_t rule_id;
+	/**< Rule identifier which is returned on successful match. */
+	const char *pcre_rule;
+	/**< Buffer to hold the PCRE rule. */
+	uint16_t pcre_rule_len;
+	/**< Length of the PCRE rule. */
+	uint64_t rule_flags;
+	/* PCRE rule flags. Supported device specific PCRE rules enumerated
+	 * in struct rte_regexdev_info::rule_flags. For successful rule
+	 * database update, application needs to provide only supported
+	 * rule flags.
+	 * @See RTE_REGEX_PCRE_RULE_*, struct rte_regexdev_info::rule_flags
+	 */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Update the local rule set.
+ * This functions only modify the rule set in memory.
+ * In order for the changes to take effect, the function
+ * rte_regexdev_rule_db_compile_active must be called.
+ *
+ * @param dev_id
+ *   RegEx device identifier.
+ * @param rules
+ *   Points to an array of *nb_rules* objects of type *rte_regexdev_rule*
+ *   structure which contain the regex rules attributes to be updated
+ *   in rule database.
+ * @param nb_rules
+ *   The number of PCRE rules to update the rule database.
+ *
+ * @return
+ *   The number of regex rules actually updated on the regex device's rule
+ *   database. The return value can be less than the value of the *nb_rules*
+ *   parameter when the regex devices fails to update the rule database or
+ *   if invalid parameters are specified in a *rte_regexdev_rule*.
+ *   If the return value is less than *nb_rules*, the remaining PCRE rules
+ *   at the end of *rules* are not consumed and the caller has to take
+ *   care of them and rte_errno is set accordingly.
+ *   Possible errno values include:
+ *   - -EINVAL:  Invalid device ID or rules is NULL
+ *   - -ENOTSUP: The last processed rule is not supported on this device.
+ *   - -ENOSPC: No space available in rule database.
+ *
+ * @see rte_regexdev_rule_db_import(), rte_regexdev_rule_db_export(),
+ *   rte_regexdev_rule_db_compile_activate()
+ */
+__rte_experimental
+int
+rte_regexdev_rule_db_update(uint8_t dev_id,
+			    const struct rte_regexdev_rule *rules,
+			    uint32_t nb_rules);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Compile local rule set and burn the complied result to the
+ * RegEx deive.
+ *
+ * @param dev_id
+ *   RegEx device identifier.
+ *
+ * @return
+ *   0 on success, otherwise negative errno.
+ *
+ * @see rte_regexdev_rule_db_import(), rte_regexdev_rule_db_export(),
+ *   rte_regexdev_rule_db_update()
+ */
+__rte_experimental
+int
+rte_regexdev_rule_db_compile_activate(uint8_t dev_id);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Import a prebuilt rule database from a buffer to a RegEx device.
+ *
+ * @param dev_id
+ *   RegEx device identifier.
+ * @param rule_db
+ *   Points to prebuilt rule database.
+ * @param rule_db_len
+ *   Length of the rule database.
+ *
+ * @return
+ *   - 0: Successfully updated the prebuilt rule database.
+ *   - -EINVAL:  Invalid device ID or rule_db is NULL
+ *   - -ENOTSUP: Rule database import is not supported on this device.
+ *   - -ENOSPC: No space available in rule database.
+ *
+ * @see rte_regexdev_rule_db_update(), rte_regexdev_rule_db_export()
+ */
+__rte_experimental
+int
+rte_regexdev_rule_db_import(uint8_t dev_id, const char *rule_db,
+			    uint32_t rule_db_len);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Export the prebuilt rule database from a RegEx device to the buffer.
+ *
+ * @param dev_id
+ *   RegEx device identifier.
+ * @param[out] rule_db
+ *   Block of memory to insert the rule database. Must be at least size in
+ *   capacity. If set to NULL, function returns required capacity.
+ *
+ * @return
+ *   - 0: Successfully exported the prebuilt rule database.
+ *   - size: If rule_db set to NULL then required capacity for *rule_db*
+ *   - -EINVAL:  Invalid device ID
+ *   - -ENOTSUP: Rule database export is not supported on this device.
+ *
+ * @see rte_regexdev_rule_db_update(), rte_regexdev_rule_db_import()
+ */
+__rte_experimental
+int
+rte_regexdev_rule_db_export(uint8_t dev_id, char *rule_db);
+
+/* Extended statistics */
+/** Maximum name length for extended statistics counters */
+#define RTE_REGEXDEV_XSTATS_NAME_SIZE 64
+
+/**
+ * A name-key lookup element for extended statistics.
+ *
+ * This structure is used to map between names and ID numbers
+ * for extended RegEx device statistics.
+ */
+struct rte_regexdev_xstats_map {
+	uint16_t id;
+	/**< xstat identifier */
+	char name[RTE_REGEXDEV_XSTATS_NAME_SIZE];
+	/**< xstat name */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Retrieve names of extended statistics of a regex device.
+ *
+ * @param dev_id
+ *   The identifier of the regex device.
+ * @param[out] xstats_map
+ *   Block of memory to insert id and names into. Must be at least size in
+ *   capacity. If set to NULL, function returns required capacity.
+ * @return
+ *   - Positive value on success:
+ *        -The return value is the number of entries filled in the stats map.
+ *        -If xstats_map set to NULL then required capacity for xstats_map.
+ *   - Negative value on error:
+ *      -ENODEV for invalid *dev_id*
+ *      -ENOTSUP if the device doesn't support this function.
+ */
+__rte_experimental
+int
+rte_regexdev_xstats_names_get(uint8_t dev_id,
+			      struct rte_regexdev_xstats_map *xstats_map);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Retrieve extended statistics of an regex device.
+ *
+ * @param dev_id
+ *   The identifier of the device.
+ * @param ids
+ *   The id numbers of the stats to get. The ids can be got from the stat
+ *   position in the stat list from rte_regexdev_xstats_names_get(), or
+ *   by using rte_regexdev_xstats_by_name_get().
+ * @param values
+ *   The values for each stats request by ID.
+ * @param nb_values
+ *   The number of stats requested.
+ * @return
+ *   - Positive value: number of stat entries filled into the values array
+ *   - Negative value on error:
+ *      -ENODEV for invalid *dev_id*
+ *      -ENOTSUP if the device doesn't support this function.
+ */
+__rte_experimental
+int
+rte_regexdev_xstats_get(uint8_t dev_id, const uint16_t *ids,
+			uint64_t *values, uint16_t nb_values);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Retrieve the value of a single stat by requesting it by name.
+ *
+ * @param dev_id
+ *   The identifier of the device.
+ * @param name
+ *   The stat name to retrieve.
+ * @param id
+ *   If non-NULL, the numerical id of the stat will be returned, so that further
+ *   requests for the stat can be got using rte_regexdev_xstats_get, which will
+ *   be faster as it doesn't need to scan a list of names for the stat.
+ * @param[out] value
+ *   Must be non-NULL, retrieved xstat value will be stored in this address.
+ *
+ * @return
+ *   - 0: Successfully retrieved xstat value.
+ *   - -EINVAL: invalid parameters
+ *   - -ENOTSUP: if not supported.
+ */
+__rte_experimental
+int
+rte_regexdev_xstats_by_name_get(uint8_t dev_id, const char *name,
+				uint16_t *id, uint64_t *value);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Reset the values of the xstats of the selected component in the device.
+ *
+ * @param dev_id
+ *   The identifier of the device.
+ * @param ids
+ *   Selects specific statistics to be reset. When NULL, all statistics will be
+ *   reset. If non-NULL, must point to array of at least *nb_ids* size.
+ * @param nb_ids
+ *   The number of ids available from the *ids* array. Ignored when ids is NULL.
+ *
+ * @return
+ *   - 0: Successfully reset the statistics to zero.
+ *   - -EINVAL: invalid parameters.
+ *   - -ENOTSUP: if not supported.
+ */
+__rte_experimental
+int
+rte_regexdev_xstats_reset(uint8_t dev_id, const uint16_t *ids,
+			  uint16_t nb_ids);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Trigger the RegEx device self test.
+ *
+ * @param dev_id
+ *   The identifier of the device.
+ * @return
+ *   - 0: Selftest successful.
+ *   - -ENOTSUP if the device doesn't support selftest.
+ *   - other values < 0 on failure.
+ */
+__rte_experimental
+int
+rte_regexdev_selftest(uint8_t dev_id);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Dump internal information about *dev_id* to the FILE* provided in *f*.
+ *
+ * @param dev_id
+ *   The identifier of the device.
+ * @param f
+ *   A pointer to a file for output.
+ *
+ * @return
+ *   0 on success, negative errno on failure.
+ */
+__rte_experimental
+int
+rte_regexdev_dump(uint8_t dev_id, FILE *f);
+
+/* Fast path APIs */
+
+/**
+ * The generic *rte_regexdev_match* structure to hold the RegEx match
+ * attributes.
+ * @see struct rte_regex_ops::matches
+ */
+struct rte_regexdev_match {
+	RTE_STD_C11
+	union {
+		uint64_t u64;
+		struct {
+			uint32_t rule_id:20;
+			/**< Rule identifier to which the pattern matched.
+			 * @see struct rte_regexdev_rule::rule_id
+			 */
+			uint32_t group_id:12;
+			/**< Group identifier of the rule which the pattern
+			 * matched. @see struct rte_regexdev_rule::group_id
+			 */
+			uint16_t start_offset;
+			/**< Starting Byte Position for matched rule. */
+			RTE_STD_C11
+			union {
+				uint16_t len;
+				/**< Length of match in bytes */
+				uint16_t end_offset;
+				/**< The end offset of the match. In case
+				 * MATCH_AS_END configuration is enabled.
+				 * @see RTE_REGEXDEV_CFG_MATCH_AS_END
+				 */
+			};
+		};
+	};
+};
+
+/* Enumerates RegEx request flags. */
+#define RTE_REGEX_OPS_REQ_GROUP_ID0_VALID_F (1 << 0)
+/**< Set when struct rte_regexdev_rule::group_id0 is valid. */
+
+#define RTE_REGEX_OPS_REQ_GROUP_ID1_VALID_F (1 << 1)
+/**< Set when struct rte_regexdev_rule::group_id1 is valid. */
+
+#define RTE_REGEX_OPS_REQ_GROUP_ID2_VALID_F (1 << 2)
+/**< Set when struct rte_regexdev_rule::group_id2 is valid. */
+
+#define RTE_REGEX_OPS_REQ_GROUP_ID3_VALID_F (1 << 3)
+/**< Set when struct rte_regexdev_rule::group_id3 is valid. */
+
+#define RTE_REGEX_OPS_REQ_STOP_ON_MATCH_F (1 << 4)
+/**< The RegEx engine will stop scanning and return the first match. */
+
+#define RTE_REGEX_OPS_REQ_MATCH_HIGH_PRIORITY_F (1 << 5)
+/**< In High Priority mode a maximum of one match will be returned per scan to
+ * reduce the post-processing required by the application. The match with the
+ * lowest Rule id, lowest start pointer and lowest match length will be
+ * returned.
+ *
+ * @see struct rte_regex_ops::nb_actual_matches
+ * @see struct rte_regex_ops::nb_matches
+ */
+
+
+/* Enumerates RegEx response flags. */
+#define RTE_REGEX_OPS_RSP_PMI_SOJ_F (1 << 0)
+/**< Indicates that the RegEx device has encountered a partial match at the
+ * start of scan in the given buffer.
+ *
+ * @see RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F
+ */
+
+#define RTE_REGEX_OPS_RSP_PMI_EOJ_F (1 << 1)
+/**< Indicates that the RegEx device has encountered a partial match at the
+ * end of scan in the given buffer.
+ *
+ * @see RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F
+ */
+
+#define RTE_REGEX_OPS_RSP_MAX_SCAN_TIMEOUT_F (1 << 2)
+/**< Indicates that the RegEx device has exceeded the max timeout while
+ * scanning the given buffer.
+ *
+ * @see RTE_REGEXDEV_ATTR_MAX_SCAN_TIMEOUT
+ */
+
+#define RTE_REGEX_OPS_RSP_MAX_MATCH_F (1 << 3)
+/**< Indicates that the RegEx device has exceeded the max matches while
+ * scanning the given buffer.
+ *
+ * @see RTE_REGEXDEV_ATTR_MAX_MATCHES
+ */
+
+#define RTE_REGEX_OPS_RSP_MAX_PREFIX_F (1 << 4)
+/**< Indicates that the RegEx device has reached the max allowed prefix length
+ * while scanning the given buffer.
+ *
+ * @see RTE_REGEXDEV_ATTR_MAX_PREFIX
+ */
+
+/**
+ * The generic *rte_regex_ops* structure to hold the RegEx attributes
+ * for enqueue and dequeue operation.
+ */
+struct rte_regex_ops {
+	/* W0 */
+	uint16_t req_flags;
+	/**< Request flags for the RegEx ops.
+	 * @see RTE_REGEX_OPS_REQ_*
+	 */
+	uint16_t rsp_flags;
+	/**< Response flags for the RegEx ops.
+	 * @see RTE_REGEX_OPS_RSP_*
+	 */
+	uint16_t nb_actual_matches;
+	/**< The total number of actual matches detected by the Regex device.*/
+	uint16_t nb_matches;
+	/**< The total number of matches returned by the RegEx device for this
+	 * scan. The size of *rte_regex_ops::matches* zero length array will be
+	 * this value.
+	 *
+	 * @see struct rte_regex_ops::matches, struct rte_regexdev_match
+	 */
+
+	/* W1 */
+	struct rte_mbuf *mbuf; /**< source mbuf, to search in. */
+
+	/* W2 */
+	uint16_t group_id0;
+	/**< First group_id to match the rule against. At minimum one group
+	 * should be valid. Behaviour is undefined non of the groups are valid.
+	 *
+	 * @see RTE_REGEX_OPS_REQ_GROUP_ID0_VALID_F
+	 */
+	uint16_t group_id1;
+	/**< Second group_id to match the rule against.
+	 *
+	 * @see RTE_REGEX_OPS_REQ_GROUP_ID1_VALID_F
+	 */
+	uint16_t group_id2;
+	/**< Third group_id to match the rule against.
+	 *
+	 * @see RTE_REGEX_OPS_REQ_GROUP_ID2_VALID_F
+	 */
+	uint16_t group_id3;
+	/**< Forth group_id to match the rule against.
+	 *
+	 * @see RTE_REGEX_OPS_REQ_GROUP_ID3_VALID_F
+	 */
+
+	/* W3 */
+	RTE_STD_C11
+	union {
+		uint64_t user_id;
+		/**< Application specific opaque value. An application may use
+		 * this field to hold application specific value to share
+		 * between dequeue and enqueue operation.
+		 * Implementation should not modify this field.
+		 */
+		void *user_ptr;
+		/**< Pointer representation of *user_id* */
+	};
+
+	/* W4 */
+	RTE_STD_C11
+	union {
+		uint64_t cross_buf_id;
+		/**< ID used by the RegEx device in order to support cross
+		 * packet detection.
+		 * This ID is returned from the RegEx device on the dequeue
+		 * function. The application must send it back when calling
+		 * enqueue with the following packet.
+		 */
+		void *cross_buf_ptr;
+		/**< Pointer representation of *corss_buf_id* */
+	};
+
+	/* W5 */
+	struct rte_regexdev_match matches[];
+	/**< Zero length array to hold the match tuples.
+	 * The struct rte_regex_ops::nb_matches value holds the number of
+	 * elements in this array.
+	 *
+	 * @see struct rte_regex_ops::nb_matches
+	 */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Enqueue a burst of scan request on a RegEx device.
+ *
+ * The rte_regexdev_enqueue_burst() function is invoked to place
+ * regex operations on the queue *qp_id* of the device designated by
+ * its *dev_id*.
+ *
+ * The *nb_ops* parameter is the number of operations to process which are
+ * supplied in the *ops* array of *rte_regexdev_op* structures.
+ *
+ * The rte_regexdev_enqueue_burst() function returns the number of
+ * operations it actually enqueued for processing. A return value equal to
+ * *nb_ops* means that all packets have been enqueued.
+ *
+ * @param dev_id
+ *   The identifier of the device.
+ * @param qp_id
+ *   The index of the queue pair which packets are to be enqueued for
+ *   processing. The value must be in the range [0, nb_queue_pairs - 1]
+ *   previously supplied to rte_regexdev_configure().
+ * @param ops
+ *   The address of an array of *nb_ops* pointers to *rte_regexdev_op*
+ *   structures which contain the regex operations to be processed.
+ * @param nb_ops
+ *   The number of operations to process.
+ *
+ * @return
+ *   The number of operations actually enqueued on the regex device. The return
+ *   value can be less than the value of the *nb_ops* parameter when the
+ *   regex devices queue is full or if invalid parameters are specified in
+ *   a *rte_regexdev_op*. If the return value is less than *nb_ops*, the
+ *   remaining ops at the end of *ops* are not consumed and the caller has
+ *   to take care of them.
+ */
+__rte_experimental
+uint16_t
+rte_regexdev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
+			   struct rte_regex_ops **ops, uint16_t nb_ops);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Dequeue a burst of scan response from a queue on the RegEx device.
+ * The dequeued operation are stored in *rte_regexdev_op* structures
+ * whose pointers are supplied in the *ops* array.
+ *
+ * The rte_regexdev_dequeue_burst() function returns the number of ops
+ * actually dequeued, which is the number of *rte_regexdev_op* data structures
+ * effectively supplied into the *ops* array.
+ *
+ * A return value equal to *nb_ops* indicates that the queue contained
+ * at least *nb_ops* operations, and this is likely to signify that other
+ * processed operations remain in the devices output queue. Applications
+ * implementing a "retrieve as many processed operations as possible" policy
+ * can check this specific case and keep invoking the
+ * rte_regexdev_dequeue_burst() function until a value less than
+ * *nb_ops* is returned.
+ *
+ * The rte_regexdev_dequeue_burst() function does not provide any error
+ * notification to avoid the corresponding overhead.
+ *
+ * @param dev_id
+ *   The RegEx device identifier
+ * @param qp_id
+ *   The index of the queue pair from which to retrieve processed packets.
+ *   The value must be in the range [0, nb_queue_pairs - 1] previously
+ *   supplied to rte_regexdev_configure().
+ * @param ops
+ *   The address of an array of pointers to *rte_regexdev_op* structures
+ *   that must be large enough to store *nb_ops* pointers in it.
+ * @param nb_ops
+ *   The maximum number of operations to dequeue.
+ *
+ * @return
+ *   The number of operations actually dequeued, which is the number
+ *   of pointers to *rte_regexdev_op* structures effectively supplied to the
+ *   *ops* array. If the return value is less than *nb_ops*, the remaining
+ *   ops at the end of *ops* are not consumed and the caller has to take care
+ *   of them.
+ */
+__rte_experimental
+uint16_t
+rte_regexdev_dequeue_burst(uint8_t dev_id, uint16_t qp_id,
+			   struct rte_regex_ops **ops, uint16_t nb_ops);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_REGEXDEV_H_ */
diff --git a/lib/librte_regexdev/rte_regexdev_version.map b/lib/librte_regexdev/rte_regexdev_version.map
new file mode 100644
index 0000000..d400624
--- /dev/null
+++ b/lib/librte_regexdev/rte_regexdev_version.map
@@ -0,0 +1,26 @@
+EXPERIMENTAL {
+	global:
+
+	rte_regexdev_count;
+	rte_regexdev_get_dev_id;
+	rte_regexdev_info_get;
+	rte_regexdev_configure;
+	rte_regexdev_queue_pair_setup;
+	rte_regexdev_start;
+	rte_regexdev_stop;
+	rte_regexdev_close;
+	rte_regexdev_attr_get;
+	rte_regexdev_attr_set;
+	rte_regexdev_rule_db_update;
+	rte_regexdev_rule_db_compile_activate;
+	rte_regexdev_rule_db_import;
+	rte_regexdev_rule_db_export;
+	rte_regexdev_xstats_names_get;
+	rte_regexdev_xstats_get;
+	rte_regexdev_xstats_by_name_get;
+	rte_regexdev_xstats_reset;
+	rte_regexdev_selftest;
+	rte_regexdev_dump;
+	rte_regexdev_enqueue_burst;
+	rte_regexdev_dequeue_burst;
+};
diff --git a/lib/meson.build b/lib/meson.build
index 07a65a6..79ae5cb 100644
--- a/lib/meson.build
+++ b/lib/meson.build
@@ -24,7 +24,7 @@ libraries = [
 	'gro', 'gso', 'ip_frag', 'jobstats',
 	'kni', 'latencystats', 'lpm', 'member',
 	'power', 'pdump', 'rawdev',
-	'rib', 'reorder', 'sched', 'security', 'stack', 'vhost',
+	'regexdev', 'rib', 'reorder', 'sched', 'security', 'stack', 'vhost',
 	# ipsec lib depends on net, crypto and security
 	'ipsec',
 	#fib lib depends on rib
-- 
1.8.3.1


^ permalink raw reply	[flat|nested] 96+ messages in thread

* [dpdk-dev] [PATCH v3 2/4] regexdev: add regex core h file
  2020-05-07  9:45 ` [dpdk-dev] [PATCH v3 0/4] add RegEx class Ori Kam
  2020-05-07  9:45   ` [dpdk-dev] [PATCH v3 1/4] regexdev: introduce regexdev subsystem Ori Kam
@ 2020-05-07  9:45   ` Ori Kam
  2020-06-03  6:47     ` [dpdk-dev] [EXT] " Guy Kaneti
  2020-05-07  9:45   ` [dpdk-dev] [PATCH v3 3/4] regexdev: add regexdev core functions Ori Kam
                     ` (2 subsequent siblings)
  4 siblings, 1 reply; 96+ messages in thread
From: Ori Kam @ 2020-05-07  9:45 UTC (permalink / raw)
  To: jerinj, xiang.w.wang
  Cc: guyk, dev, pbhagavatula, shahafs, hemant.agrawal, opher, alexr,
	dovrat, pkapoor, nipun.gupta, bruce.richardson, yang.a.hong,
	harry.chang, gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai,
	yuyingxia, fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc,
	jim, hongjun.ni, j.bromhead, deri, fc, arthur.su, thomas, orika

This commit introduce the rte_regexdev_core.h file.
This file holds internal structures and API that are used by
the regexdev.

Signed-off-by: Ori Kam <orika@mellanox.com>
---
v3:
* Align internal function pointers API to the RTE level API.
 
v2:
* Move private data to rte_regexdev struct.
---
 lib/librte_regexdev/Makefile            |   1 +
 lib/librte_regexdev/meson.build         |   2 +-
 lib/librte_regexdev/rte_regexdev.h      |   2 +
 lib/librte_regexdev/rte_regexdev_core.h | 161 ++++++++++++++++++++++++++++++++
 4 files changed, 165 insertions(+), 1 deletion(-)
 create mode 100644 lib/librte_regexdev/rte_regexdev_core.h

diff --git a/lib/librte_regexdev/Makefile b/lib/librte_regexdev/Makefile
index 6f4cc63..9012d29 100644
--- a/lib/librte_regexdev/Makefile
+++ b/lib/librte_regexdev/Makefile
@@ -24,6 +24,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_REGEXDEV) := rte_regexdev.c
 
 # export include files
 SYMLINK-$(CONFIG_RTE_LIBRTE_REGEXDEV)-include += rte_regexdev.h
+SYMLINK-$(CONFIG_RTE_LIBRTE_REGEXDEV)-include += rte_regexdev_core.h
 
 # versioning export map
 EXPORT_MAP := rte_regexdev_version.map
diff --git a/lib/librte_regexdev/meson.build b/lib/librte_regexdev/meson.build
index f4db748..1816754 100644
--- a/lib/librte_regexdev/meson.build
+++ b/lib/librte_regexdev/meson.build
@@ -3,5 +3,5 @@
 
 allow_experimental_apis = true
 sources = files('rte_regexdev.c')
-headers = files('rte_regexdev.h')
+headers = files('rte_regexdev.h', 'rte_regexdev_core.h')
 deps += ['mbuf']
diff --git a/lib/librte_regexdev/rte_regexdev.h b/lib/librte_regexdev/rte_regexdev.h
index 7e688d9..bbc56f9 100644
--- a/lib/librte_regexdev/rte_regexdev.h
+++ b/lib/librte_regexdev/rte_regexdev.h
@@ -1466,6 +1466,8 @@ struct rte_regex_ops {
 rte_regexdev_dequeue_burst(uint8_t dev_id, uint16_t qp_id,
 			   struct rte_regex_ops **ops, uint16_t nb_ops);
 
+#include "rte_regexdev_core.h"
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/lib/librte_regexdev/rte_regexdev_core.h b/lib/librte_regexdev/rte_regexdev_core.h
new file mode 100644
index 0000000..fa6d297
--- /dev/null
+++ b/lib/librte_regexdev/rte_regexdev_core.h
@@ -0,0 +1,161 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2019 Mellanox Corporation
+ */
+
+#ifndef _RTE_REGEX_CORE_H_
+#define _RTE_REGEX_CORE_H_
+
+/**
+ * @file
+ *
+ * RTE RegEx Device internal header.
+ *
+ * This header contains internal data types, that are used by the RegEx devices
+ * in order to expose their ops to the class.
+ *
+ * Applications should not use these API directly.
+ *
+ */
+
+struct rte_regexdev;
+
+typedef int (*regexdev_info_get_t)(struct rte_regexdev *dev,
+				   struct rte_regexdev_info *info);
+/**< @internal Get the RegEx device info. */
+
+typedef int (*regexdev_configure_t)(struct rte_regexdev *dev,
+				    const struct rte_regexdev_config *cfg);
+/**< @internal Configure the RegEx device. */
+
+typedef int (*regexdev_qp_setup_t)(struct rte_regexdev *dev, uint16_t id,
+				   const struct rte_regexdev_qp_conf *qp_conf);
+/**< @internal Setup a queue pair.*/
+
+typedef int (*regexdev_start_t)(struct rte_regexdev *dev);
+/**< @internal Start the RegEx device. */
+
+typedef int (*regexdev_stop_t)(struct rte_regexdev *dev);
+/**< @internal Stop the RegEx device. */
+
+typedef int (*regexdev_close_t)(struct rte_regexdev *dev);
+/**< @internal Close the RegEx device. */
+
+typedef int (*regexdev_attr_get_t)(struct rte_regexdev *dev,
+				   enum rte_regexdev_attr_id id,
+				   void *value);
+/**< @internal Get selected attribute from RegEx device. */
+
+typedef int (*regexdev_attr_set_t)(struct rte_regexdev *dev,
+				   enum rte_regexdev_attr_id id,
+				   const void *value);
+/**< @internal Set selected attribute to RegEx device. */
+
+typedef int (*regexdev_rule_db_update_t)(struct rte_regexdev *dev,
+					 const struct rte_regexdev_rule *rules,
+					 uint16_t nb_rules);
+/**< @internal Update the rule database for the RegEx device. */
+
+typedef int (*regexdev_rule_db_compile_activate_t)(struct rte_regexdev *dev);
+/**< @internal Compile the rule database and activate it. */
+
+typedef int (*regexdev_rule_db_import_t)(struct rte_regexdev *dev,
+					 const  char *rule_db,
+					 uint32_t rule_db_len);
+/**< @internal Upload a pre created rule database to the RegEx device. */
+
+typedef int (*regexdev_rule_db_export_t)(struct rte_regexdev *dev,
+					 char *rule_db);
+/**< @internal Export the current rule database from the RegEx device. */
+
+typedef int (*regexdev_xstats_names_get_t)(struct rte_regexdev *dev,
+					   struct rte_regexdev_xstats_map
+					   *xstats_map);
+/**< @internal Get xstats name map for the RegEx device. */
+
+typedef int (*regexdev_xstats_get_t)(struct rte_regexdev *dev,
+				     const uint16_t *ids, uint64_t *values,
+				     uint16_t nb_values);
+/**< @internal Get xstats values for the RegEx device. */
+
+typedef int (*regexdev_xstats_by_name_get_t)(struct rte_regexdev *dev,
+					     const char *name, uint16_t *id,
+					     uint64_t *value);
+/**< @internal Get xstat value for the RegEx device based on the xstats name. */
+
+typedef int (*regexdev_xstats_reset_t)(struct rte_regexdev *dev,
+				       const uint16_t *ids,
+				       uint16_t nb_ids);
+/**< @internal Reset xstats values for the RegEx device. */
+
+typedef int (*regexdev_selftest_t)(struct rte_regexdev *dev);
+/**< @internal Trigger RegEx self test. */
+
+typedef int (*regexdev_dump_t)(struct rte_regexdev *dev, FILE *f);
+/**< @internal Dump internal information about the RegEx device. */
+
+typedef uint16_t (*regexdev_enqueue_t)(struct rte_regexdev *dev, uint16_t qp_id,
+				       struct rte_regex_ops **ops,
+				       uint16_t nb_ops);
+/**< @internal Enqueue a burst of scan requests to a queue on RegEx device. */
+
+typedef uint16_t (*regexdev_dequeue_t)(struct rte_regexdev *dev, uint16_t qp_id,
+				       struct rte_regex_ops **ops,
+				       uint16_t nb_ops);
+/**< @internal Dequeue a burst of scan response from a queue on RegEx device. */
+
+/**
+ * RegEx device operations
+ */
+struct rte_regexdev_ops {
+	regexdev_info_get_t dev_info_get;
+	regexdev_configure_t dev_configure;
+	regexdev_qp_setup_t dev_qp_setup;
+	regexdev_start_t dev_start;
+	regexdev_stop_t dev_stop;
+	regexdev_close_t dev_close;
+	regexdev_attr_get_t dev_attr_get;
+	regexdev_attr_set_t dev_attr_set;
+	regexdev_rule_db_update_t dev_rule_db_update;
+	regexdev_rule_db_compile_activate_t dev_rule_db_compile_activate;
+	regexdev_rule_db_import_t dev_db_import;
+	regexdev_rule_db_export_t dev_db_export;
+	regexdev_xstats_names_get_t dev_xstats_names_get;
+	regexdev_xstats_get_t dev_xstats_get;
+	regexdev_xstats_by_name_get_t dev_xstats_by_name_get;
+	regexdev_xstats_reset_t dev_xstats_reset;
+	regexdev_selftest_t dev_selftest;
+	regexdev_dump_t dev_dump;
+};
+
+#define RTE_REGEXDEV_NAME_MAX_LEN
+/**
+ * @internal
+ * The data part, with no function pointers, associated with each RegEx device.
+ *
+ * This structure is safe to place in shared memory to be common among different
+ * processes in a multi-process configuration.
+ */
+struct rte_regexdev_data {
+	void *dev_private; /**< PMD-specific private data. */
+} __rte_cache_aligned;
+
+/**
+ * @internal
+ * The generic data structure associated with each RegEx device.
+ *
+ * Pointers to burst-oriented packet receive and transmit functions are
+ * located at the beginning of the structure, along with the pointer to
+ * where all the data elements for the particular device are stored in shared
+ * memory. This split allows the function pointer and driver data to be per-
+ * process, while the actual configuration data for the device is shared.
+ */
+struct rte_regexdev {
+	regexdev_enqueue_t enqueue;
+	regexdev_dequeue_t dequeue;
+	const struct rte_regexdev_ops *dev_ops;
+	/**< Functions exported by PMD */
+	struct rte_device *device; /**< Backing device */
+	struct rte_regexdev_data *data;  /**< Pointer to device data. */
+} __rte_cache_aligned;
+
+#endif /* _RTE_REGEX_CORE_H_ */
-- 
1.8.3.1


^ permalink raw reply	[flat|nested] 96+ messages in thread

* [dpdk-dev] [PATCH v3 3/4] regexdev: add regexdev core functions
  2020-05-07  9:45 ` [dpdk-dev] [PATCH v3 0/4] add RegEx class Ori Kam
  2020-05-07  9:45   ` [dpdk-dev] [PATCH v3 1/4] regexdev: introduce regexdev subsystem Ori Kam
  2020-05-07  9:45   ` [dpdk-dev] [PATCH v3 2/4] regexdev: add regex core h file Ori Kam
@ 2020-05-07  9:45   ` Ori Kam
  2020-06-03  6:57     ` [dpdk-dev] [EXT] " Guy Kaneti
  2020-05-07  9:45   ` [dpdk-dev] [PATCH v3 4/4] regexdev: implement regex rte level functions Ori Kam
  2020-05-24 20:24   ` [dpdk-dev] [PATCH v3 0/4] add RegEx class Ori Kam
  4 siblings, 1 reply; 96+ messages in thread
From: Ori Kam @ 2020-05-07  9:45 UTC (permalink / raw)
  To: jerinj, xiang.w.wang
  Cc: guyk, dev, pbhagavatula, shahafs, hemant.agrawal, opher, alexr,
	dovrat, pkapoor, nipun.gupta, bruce.richardson, yang.a.hong,
	harry.chang, gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai,
	yuyingxia, fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc,
	jim, hongjun.ni, j.bromhead, deri, fc, arthur.su, thomas, orika,
	Parav Pandit

This commit introduce the API that is needed by the RegEx devices in
order to work with the RegEX lib.

During the probe of a RegEx device, the device should configure itself,
and allocate the resources it requires.
On completion of the device init, it should call the
rte_regex_dev_register in order to register itself as a RegEx device.

Signed-off-by: Ori Kam <orika@mellanox.com>
Signed-off-by: Parav Pandit <parav@mellanox.com>
---
v3:
* Add function to get device by name.

v2:
* Changes resulted from previous patch update.
---
 config/common_base                        |   3 +-
 config/meson.build                        |   1 +
 lib/librte_regexdev/Makefile              |   1 +
 lib/librte_regexdev/meson.build           |   5 +-
 lib/librte_regexdev/rte_regexdev.c        | 139 +++++++++++++++++++++++++++++-
 lib/librte_regexdev/rte_regexdev.h        |   7 ++
 lib/librte_regexdev/rte_regexdev_core.h   |  16 +++-
 lib/librte_regexdev/rte_regexdev_driver.h |  59 +++++++++++++
 meson_options.txt                         |   2 +
 9 files changed, 229 insertions(+), 4 deletions(-)
 create mode 100644 lib/librte_regexdev/rte_regexdev_driver.h

diff --git a/config/common_base b/config/common_base
index 27fcab1..359fd3c 100644
--- a/config/common_base
+++ b/config/common_base
@@ -832,9 +832,10 @@ CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_EP_RAWDEV=y
 CONFIG_RTE_LIBRTE_PMD_NTB_RAWDEV=y
 
 #
-# Compile regex device support
+# Compile RexEx device support
 #
 CONFIG_RTE_LIBRTE_REGEXDEV=y
+CONFIG_RTE_MAX_REGEXDEV_DEVS=32
 
 #
 # Compile librte_ring
diff --git a/config/meson.build b/config/meson.build
index e851b40..16fec24 100644
--- a/config/meson.build
+++ b/config/meson.build
@@ -228,6 +228,7 @@ endforeach
 dpdk_conf.set('RTE_MAX_LCORE', get_option('max_lcores'))
 dpdk_conf.set('RTE_MAX_NUMA_NODES', get_option('max_numa_nodes'))
 dpdk_conf.set('RTE_MAX_ETHPORTS', get_option('max_ethports'))
+dpdk_conf.set('RTE_MAX_REGEXDEV_DEVS', get_option('max_regexdev_devs'))
 dpdk_conf.set('RTE_LIBEAL_USE_HPET', get_option('use_hpet'))
 dpdk_conf.set('RTE_ENABLE_TRACE_FP', get_option('enable_trace_fp'))
 # values which have defaults which may be overridden
diff --git a/lib/librte_regexdev/Makefile b/lib/librte_regexdev/Makefile
index 9012d29..6ba09f0 100644
--- a/lib/librte_regexdev/Makefile
+++ b/lib/librte_regexdev/Makefile
@@ -25,6 +25,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_REGEXDEV) := rte_regexdev.c
 # export include files
 SYMLINK-$(CONFIG_RTE_LIBRTE_REGEXDEV)-include += rte_regexdev.h
 SYMLINK-$(CONFIG_RTE_LIBRTE_REGEXDEV)-include += rte_regexdev_core.h
+SYMLINK-$(CONFIG_RTE_LIBRTE_REGEXDEV)-include += rte_regexdev_driver.h
 
 # versioning export map
 EXPORT_MAP := rte_regexdev_version.map
diff --git a/lib/librte_regexdev/meson.build b/lib/librte_regexdev/meson.build
index 1816754..719ee82 100644
--- a/lib/librte_regexdev/meson.build
+++ b/lib/librte_regexdev/meson.build
@@ -1,7 +1,10 @@
 # SPDX-License-Identifier: BSD-3-Clause
 # Copyright(c) 2020 Mellanox Corporation
 
+name = 'regexdev'
 allow_experimental_apis = true
 sources = files('rte_regexdev.c')
-headers = files('rte_regexdev.h', 'rte_regexdev_core.h')
+headers = files('rte_regexdev.h',
+	'rte_regexdev_core.h',
+	'rte_regexdev_driver.h')
 deps += ['mbuf']
diff --git a/lib/librte_regexdev/rte_regexdev.c b/lib/librte_regexdev/rte_regexdev.c
index b901877..2014b22 100644
--- a/lib/librte_regexdev/rte_regexdev.c
+++ b/lib/librte_regexdev/rte_regexdev.c
@@ -3,4 +3,141 @@
  * Copyright(C) 2020 Mellanox International Ltd.
  */
 
-#include <rte_regexdev.h>
+#include <string.h>
+
+#include <rte_memory.h>
+#include <rte_memcpy.h>
+#include <rte_memzone.h>
+#include <rte_string_fns.h>
+
+#include "rte_regexdev.h"
+#include "rte_regexdev_core.h"
+#include "rte_regexdev_driver.h"
+
+static const char *MZ_RTE_REGEXDEV_DATA = "rte_regexdev_data";
+static struct rte_regexdev regex_devices[RTE_MAX_REGEXDEV_DEVS];
+/* Shared memory between primary and secondary processes. */
+static struct {
+	struct rte_regexdev_data data[RTE_MAX_REGEXDEV_DEVS];
+} *rte_regexdev_shared_data;
+
+int rte_regexdev_logtype;
+
+static uint16_t
+regexdev_find_free_dev(void)
+{
+	uint16_t i;
+
+	for (i = 0; i < RTE_MAX_REGEXDEV_DEVS; i++) {
+		if (regex_devices[i].state == RTE_REGEXDEV_UNUSED)
+			return i;
+	}
+	return RTE_MAX_REGEXDEV_DEVS;
+}
+
+static struct rte_regexdev*
+regexdev_allocated(const char *name)
+{
+	uint16_t i;
+
+	for (i = 0; i < RTE_MAX_REGEXDEV_DEVS; i++) {
+		if (regex_devices[i].state != RTE_REGEXDEV_UNUSED)
+			if (!strcmp(name, regex_devices[i].data->dev_name))
+				return &regex_devices[i];
+	}
+	return NULL;
+}
+
+static int
+regexdev_shared_data_prepare(void)
+{
+	const unsigned int flags = 0;
+	const struct rte_memzone *mz;
+
+	if (rte_regexdev_shared_data == NULL) {
+		/* Allocate port data and ownership shared memory. */
+		mz = rte_memzone_reserve(MZ_RTE_REGEXDEV_DATA,
+					 sizeof(*rte_regexdev_shared_data),
+					 rte_socket_id(), flags);
+		if (mz == NULL)
+			return -ENOMEM;
+
+		rte_regexdev_shared_data = mz->addr;
+		memset(rte_regexdev_shared_data->data, 0,
+		       sizeof(rte_regexdev_shared_data->data));
+	}
+	return 0;
+}
+
+static int
+regexdev_check_name(const char *name)
+{
+	size_t name_len;
+
+	if (name == NULL) {
+		RTE_REGEXDEV_LOG(ERR, "Name can't be NULL\n");
+		return -EINVAL;
+	}
+	name_len = strnlen(name, RTE_REGEXDEV_NAME_MAX_LEN);
+	if (name_len == 0) {
+		RTE_REGEXDEV_LOG(ERR, "Zero length RegEx device name\n");
+		return -EINVAL;
+	}
+	if (name_len >= RTE_REGEXDEV_NAME_MAX_LEN) {
+		RTE_REGEXDEV_LOG(ERR, "RegEx device name is too long\n");
+		return -EINVAL;
+	}
+	return (int)name_len;
+
+}
+
+struct rte_regexdev *
+rte_regexdev_register(const char *name)
+{
+	uint16_t dev_id;
+	int name_len;
+	struct rte_regexdev *dev;
+
+	name_len = regexdev_check_name(name);
+	if (name_len < 0)
+		return NULL;
+	dev = regexdev_allocated(name);
+	if (dev != NULL) {
+		RTE_REGEXDEV_LOG(ERR, "RegEx device already allocated\n");
+		return NULL;
+	}
+	dev_id = regexdev_find_free_dev();
+	if (dev_id == RTE_MAX_REGEXDEV_DEVS) {
+		RTE_REGEXDEV_LOG
+			(ERR, "Reached maximum number of RegEx devices\n");
+		return NULL;
+	}
+	if (regexdev_shared_data_prepare() < 0) {
+		RTE_REGEXDEV_LOG(ERR, "Cannot allocate RegEx shared data\n");
+		return NULL;
+	}
+
+	dev = &regex_devices[dev_id];
+	dev->state = RTE_REGEXDEV_REGISTERED;
+	if (dev->data == NULL)
+		dev->data = &rte_regexdev_shared_data->data[dev_id];
+	else
+		memset(dev->data, 1, sizeof(*dev->data));
+	dev->data->dev_id = dev_id;
+	strlcpy(dev->data->dev_name, name, sizeof(dev->data->dev_name));
+	return dev;
+}
+
+void
+rte_regexdev_unregister(struct rte_regexdev *dev)
+{
+	dev->state = RTE_REGEXDEV_UNUSED;
+}
+
+struct rte_regexdev *
+rte_regexdev_get_device_by_name(const char *name)
+{
+	if (regexdev_check_name(name) < 0)
+		return NULL;
+	return regexdev_allocated(name);
+}
diff --git a/lib/librte_regexdev/rte_regexdev.h b/lib/librte_regexdev/rte_regexdev.h
index bbc56f9..1e1ba8b 100644
--- a/lib/librte_regexdev/rte_regexdev.h
+++ b/lib/librte_regexdev/rte_regexdev.h
@@ -206,6 +206,13 @@
 #include <rte_mbuf.h>
 #include <rte_memory.h>
 
+#define RTE_REGEXDEV_NAME_MAX_LEN RTE_DEV_NAME_MAX_LEN
+
+extern int rte_regexdev_logtype;
+
+#define RTE_REGEXDEV_LOG(level, ...) \
+	rte_log(RTE_LOG_ ## level, rte_regexdev_logtype, "" __VA_ARGS__)
+
 /**
  * @warning
  * @b EXPERIMENTAL: this API may change without prior notice.
diff --git a/lib/librte_regexdev/rte_regexdev_core.h b/lib/librte_regexdev/rte_regexdev_core.h
index fa6d297..cbf054e 100644
--- a/lib/librte_regexdev/rte_regexdev_core.h
+++ b/lib/librte_regexdev/rte_regexdev_core.h
@@ -127,7 +127,18 @@ struct rte_regexdev_ops {
 	regexdev_dump_t dev_dump;
 };
 
-#define RTE_REGEXDEV_NAME_MAX_LEN
+/**
+ * @internal
+ * Possible states of a RegEx device.
+ */
+enum rte_regexdev_state {
+	RTE_REGEXDEV_UNUSED = 0, /**< Device is unused. */
+	RTE_REGEXDEV_REGISTERED,
+	/**< Device is registered, but not ready to be used. */
+	RTE_REGEXDEV_READY,
+	/**< Device is ready for use. This is set by the PMD. */
+};
+
 /**
  * @internal
  * The data part, with no function pointers, associated with each RegEx device.
@@ -137,6 +148,8 @@ struct rte_regexdev_ops {
  */
 struct rte_regexdev_data {
 	void *dev_private; /**< PMD-specific private data. */
+	char dev_name[RTE_REGEXDEV_NAME_MAX_LEN]; /**< Unique identifier name */
+	uint16_t dev_id; /**< Device [external]  identifier. */
 } __rte_cache_aligned;
 
 /**
@@ -155,6 +168,7 @@ struct rte_regexdev {
 	const struct rte_regexdev_ops *dev_ops;
 	/**< Functions exported by PMD */
 	struct rte_device *device; /**< Backing device */
+	enum rte_regexdev_state state; /**< The device state. */
 	struct rte_regexdev_data *data;  /**< Pointer to device data. */
 } __rte_cache_aligned;
 
diff --git a/lib/librte_regexdev/rte_regexdev_driver.h b/lib/librte_regexdev/rte_regexdev_driver.h
new file mode 100644
index 0000000..1477c59
--- /dev/null
+++ b/lib/librte_regexdev/rte_regexdev_driver.h
@@ -0,0 +1,59 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2020 Mellanox Corporation
+ */
+
+#ifndef _RTE_REGEXDEV_DRIVER_H_
+#define _RTE_REGEXDEV_DRIVER_H_
+
+/**
+ * @file
+ *
+ * RTE RegEx Device PMD API
+ *
+ * APIs that are used by the RegEx drivers, to comunicate with the
+ * RegEx lib.
+ */
+
+#include "rte_regexdev.h"
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/**
+ * @internal
+ * Register a RegEx device slot for a RegEx device and return the
+ * pointer to that slot.
+ *
+ * @param name
+ *   RegEx device name.
+ *
+ * @return
+ *   A pointer to the RegEx device slot case of success,
+ *   NULL otherwise.
+ */
+struct rte_regexdev *rte_regexdev_register(const char *name);
+
+/**
+ * @internal
+ * Unregister the specified regexdev port.
+ *
+ * @param dev
+ *   Device to be released.
+ */
+void rte_regexdev_unregister(struct rte_regexdev *dev);
+
+/**
+ * @internal
+ * Return the RegEx device based on the device name.
+ *
+ * @param name
+ *   The device name.
+ */
+struct rte_regexdev *rte_regexdev_get_device_by_name(const char *name);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_REGEXDEV_DRIVER_H_ */
diff --git a/meson_options.txt b/meson_options.txt
index 9bf18ab..2a04cd6 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -30,6 +30,8 @@ option('max_lcores', type: 'integer', value: 128,
 	description: 'maximum number of cores/threads supported by EAL')
 option('max_numa_nodes', type: 'integer', value: 4,
 	description: 'maximum number of NUMA nodes supported by EAL')
+option('max_regexdev_devs', type: 'integer', value: 32,
+	description: 'maximum number of RegEx devices')
 option('enable_trace_fp', type: 'boolean', value: false,
 	description: 'enable fast path trace points.')
 option('tests', type: 'boolean', value: true,
-- 
1.8.3.1


^ permalink raw reply	[flat|nested] 96+ messages in thread

* [dpdk-dev] [PATCH v3 4/4] regexdev: implement regex rte level functions
  2020-05-07  9:45 ` [dpdk-dev] [PATCH v3 0/4] add RegEx class Ori Kam
                     ` (2 preceding siblings ...)
  2020-05-07  9:45   ` [dpdk-dev] [PATCH v3 3/4] regexdev: add regexdev core functions Ori Kam
@ 2020-05-07  9:45   ` Ori Kam
  2020-06-03  6:59     ` [dpdk-dev] [EXT] " Guy Kaneti
  2020-06-28 13:45     ` Guy Kaneti
  2020-05-24 20:24   ` [dpdk-dev] [PATCH v3 0/4] add RegEx class Ori Kam
  4 siblings, 2 replies; 96+ messages in thread
From: Ori Kam @ 2020-05-07  9:45 UTC (permalink / raw)
  To: jerinj, xiang.w.wang
  Cc: guyk, dev, pbhagavatula, shahafs, hemant.agrawal, opher, alexr,
	dovrat, pkapoor, nipun.gupta, bruce.richardson, yang.a.hong,
	harry.chang, gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai,
	yuyingxia, fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc,
	jim, hongjun.ni, j.bromhead, deri, fc, arthur.su, thomas, orika

This commit implements all the RegEx public API.

Signed-off-by: Ori Kam <orika@mellanox.com>
---
v3:
* Fix validation conditions.

v2:
* Changes based on changes in previous patch.
* Add check to configuration function.
* Replace checks with macros.
* Move enqueue and dequeue to inline.
---
 config/common_base                      |   1 +
 lib/librte_regexdev/rte_regexdev.c      | 442 +++++++++++++++++++++++++++++++-
 lib/librte_regexdev/rte_regexdev.h      |  68 ++++-
 lib/librte_regexdev/rte_regexdev_core.h |   9 +
 4 files changed, 506 insertions(+), 14 deletions(-)

diff --git a/config/common_base b/config/common_base
index 359fd3c..ff96a82 100644
--- a/config/common_base
+++ b/config/common_base
@@ -835,6 +835,7 @@ CONFIG_RTE_LIBRTE_PMD_NTB_RAWDEV=y
 # Compile RexEx device support
 #
 CONFIG_RTE_LIBRTE_REGEXDEV=y
+CONFIG_RTE_LIBRTE_REGEXDEV_DEBUG=n
 CONFIG_RTE_MAX_REGEXDEV_DEVS=32
 
 #
diff --git a/lib/librte_regexdev/rte_regexdev.c b/lib/librte_regexdev/rte_regexdev.c
index 2014b22..a93c9fe 100644
--- a/lib/librte_regexdev/rte_regexdev.c
+++ b/lib/librte_regexdev/rte_regexdev.c
@@ -15,7 +15,7 @@
 #include "rte_regexdev_driver.h"
 
 static const char *MZ_RTE_REGEXDEV_DATA = "rte_regexdev_data";
-static struct rte_regexdev regex_devices[RTE_MAX_REGEXDEV_DEVS];
+struct rte_regexdev rte_regex_devices[RTE_MAX_REGEXDEV_DEVS];
 /* Shared memory between primary and secondary processes. */
 static struct {
 	struct rte_regexdev_data data[RTE_MAX_REGEXDEV_DEVS];
@@ -29,7 +29,7 @@
 	uint16_t i;
 
 	for (i = 0; i < RTE_MAX_REGEXDEV_DEVS; i++) {
-		if (regex_devices[i].state == RTE_REGEXDEV_UNUSED)
+		if (rte_regex_devices[i].state == RTE_REGEXDEV_UNUSED)
 			return i;
 	}
 	return RTE_MAX_REGEXDEV_DEVS;
@@ -41,9 +41,9 @@
 	uint16_t i;
 
 	for (i = 0; i < RTE_MAX_REGEXDEV_DEVS; i++) {
-		if (regex_devices[i].state != RTE_REGEXDEV_UNUSED)
-			if (!strcmp(name, regex_devices[i].data->dev_name))
-				return &regex_devices[i];
+		if (rte_regex_devices[i].state != RTE_REGEXDEV_UNUSED)
+			if (!strcmp(name, rte_regex_devices[i].data->dev_name))
+				return &rte_regex_devices[i];
 	}
 	return NULL;
 }
@@ -117,7 +117,7 @@ struct rte_regexdev *
 		return NULL;
 	}
 
-	dev = &regex_devices[dev_id];
+	dev = &rte_regex_devices[dev_id];
 	dev->state = RTE_REGEXDEV_REGISTERED;
 	if (dev->data == NULL)
 		dev->data = &rte_regexdev_shared_data->data[dev_id];
@@ -141,3 +141,433 @@ struct rte_regexdev *
 		return NULL;
 	return regexdev_allocated(name);
 }
+
+uint8_t
+rte_regexdev_count(void)
+{
+	int i;
+	int count = 0;
+
+	for (i = 0; i < RTE_MAX_REGEXDEV_DEVS; i++) {
+		if (rte_regex_devices[i].state != RTE_REGEXDEV_UNUSED)
+			count++;
+	}
+	return count;
+}
+
+int
+rte_regexdev_get_dev_id(const char *name)
+{
+	int i;
+	int id = -EINVAL;
+
+	if (name == NULL)
+		return -EINVAL;
+	for (i = 0; i < RTE_MAX_REGEXDEV_DEVS; i++) {
+		if (rte_regex_devices[i].state != RTE_REGEXDEV_UNUSED)
+			if (strcmp(name, rte_regex_devices[i].data->dev_name)) {
+				id = rte_regex_devices[i].data->dev_id;
+				break;
+			}
+	}
+	return id;
+}
+
+int
+rte_regexdev_is_valid_dev(uint16_t dev_id)
+{
+	if (dev_id >= RTE_MAX_REGEXDEV_DEVS ||
+	    rte_regex_devices[dev_id].state != RTE_REGEXDEV_READY)
+		return 0;
+	return 1;
+}
+
+static int
+regexdev_info_get(uint8_t dev_id, struct rte_regexdev_info *dev_info)
+{
+	struct rte_regexdev *dev;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	if (dev_info == NULL)
+		return -EINVAL;
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_info_get, -ENOTSUP);
+	return (*dev->dev_ops->dev_info_get)(dev, dev_info);
+
+}
+
+int
+rte_regexdev_info_get(uint8_t dev_id, struct rte_regexdev_info *dev_info)
+{
+	return regexdev_info_get(dev_id, dev_info);
+}
+
+int
+rte_regexdev_configure(uint8_t dev_id, const struct rte_regexdev_config *cfg)
+{
+	struct rte_regexdev *dev;
+	struct rte_regexdev_info dev_info;
+	int ret;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	if (cfg == NULL)
+		return -EINVAL;
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_configure, -ENOTSUP);
+	if (dev->data->dev_started) {
+		RTE_REGEXDEV_LOG
+			(ERR, "Dev %u must be stopped to allow configuration\n",
+			 dev_id);
+		return -EBUSY;
+	}
+	ret = regexdev_info_get(dev_id, &dev_info);
+	if (ret < 0)
+		return ret;
+	if ((cfg->dev_cfg_flags & RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F) &&
+	    !(dev_info.regexdev_capa & RTE_REGEXDEV_SUPP_CROSS_BUFFER_F)) {
+		RTE_REGEXDEV_LOG(ERR,
+				 "Dev %u doesn't support cross buffer scan\n",
+				 dev_id);
+		return -EINVAL;
+	}
+	if ((cfg->dev_cfg_flags & RTE_REGEXDEV_CFG_MATCH_AS_END_F) &&
+	    !(dev_info.regexdev_capa & RTE_REGEXDEV_SUPP_MATCH_AS_END_F)) {
+		RTE_REGEXDEV_LOG(ERR,
+				 "Dev %u doesn't support match as end\n",
+				 dev_id);
+		return -EINVAL;
+	}
+	if ((cfg->dev_cfg_flags & RTE_REGEXDEV_CFG_MATCH_ALL_F) &&
+	    !(dev_info.regexdev_capa & RTE_REGEXDEV_SUPP_MATCH_ALL_F)) {
+		RTE_REGEXDEV_LOG(ERR,
+				 "Dev %u doesn't support match all\n",
+				 dev_id);
+		return -EINVAL;
+	}
+	if (cfg->nb_groups == 0) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %u num of groups must be > 0\n",
+				 dev_id);
+		return -EINVAL;
+	}
+	if (cfg->nb_groups > dev_info.max_groups) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %u num of groups %d > %d\n",
+				 dev_id, cfg->nb_groups, dev_info.max_groups);
+		return -EINVAL;
+	}
+	if (cfg->nb_max_matches == 0) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %u num of matches must be > 0\n",
+				 dev_id);
+		return -EINVAL;
+	}
+	if (cfg->nb_max_matches > dev_info.max_matches) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %u num of matches %d > %d\n",
+				 dev_id, cfg->nb_max_matches,
+				 dev_info.max_matches);
+		return -EINVAL;
+	}
+	if (cfg->nb_queue_pairs == 0) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %u num of queues must be > 0\n",
+				 dev_id);
+		return -EINVAL;
+	}
+	if (cfg->nb_queue_pairs > dev_info.max_queue_pairs) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %u num of queues %d > %d\n",
+				 dev_id, cfg->nb_queue_pairs,
+				 dev_info.max_queue_pairs);
+		return -EINVAL;
+	}
+	if (cfg->nb_rules_per_group == 0) {
+		RTE_REGEXDEV_LOG(ERR,
+				 "Dev %u num of rules per group must be > 0\n",
+				 dev_id);
+		return -EINVAL;
+	}
+	if (cfg->nb_rules_per_group > dev_info.max_rules_per_group) {
+		RTE_REGEXDEV_LOG(ERR,
+				 "Dev %u num of rules per group %d > %d\n",
+				 dev_id, cfg->nb_rules_per_group,
+				 dev_info.max_rules_per_group);
+		return -EINVAL;
+	}
+	ret = (*dev->dev_ops->dev_configure)(dev, cfg);
+	if (ret == 0)
+		dev->data->dev_conf = *cfg;
+	return ret;
+}
+
+int
+rte_regexdev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
+			   const struct rte_regexdev_qp_conf *qp_conf)
+{
+	struct rte_regexdev *dev;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_qp_setup, -ENOTSUP);
+	if (dev->data->dev_started) {
+		RTE_REGEXDEV_LOG
+			(ERR, "Dev %u must be stopped to allow configuration\n",
+			 dev_id);
+		return -EBUSY;
+	}
+	if (queue_pair_id >= dev->data->dev_conf.nb_queue_pairs) {
+		RTE_REGEXDEV_LOG(ERR,
+				 "Dev %u invalid queue %d > %d\n",
+				 dev_id, queue_pair_id,
+				 dev->data->dev_conf.nb_queue_pairs);
+		return -EINVAL;
+	}
+	if (dev->data->dev_started) {
+		RTE_REGEXDEV_LOG
+			(ERR, "Dev %u must be stopped to allow configuration\n",
+			 dev_id);
+		return -EBUSY;
+	}
+	return (*dev->dev_ops->dev_qp_setup)(dev, queue_pair_id, qp_conf);
+}
+
+int
+rte_regexdev_start(uint8_t dev_id)
+{
+	struct rte_regexdev *dev;
+	int ret;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_start, -ENOTSUP);
+	ret = (*dev->dev_ops->dev_start)(dev);
+	if (ret == 0)
+		dev->data->dev_started = 1;
+	return ret;
+}
+
+int
+rte_regexdev_stop(uint8_t dev_id)
+{
+	struct rte_regexdev *dev;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_stop, -ENOTSUP);
+	(*dev->dev_ops->dev_stop)(dev);
+	dev->data->dev_started = 0;
+	return 0;
+}
+
+int
+rte_regexdev_close(uint8_t dev_id)
+{
+	struct rte_regexdev *dev;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_close, -ENOTSUP);
+	(*dev->dev_ops->dev_close)(dev);
+	dev->data->dev_started = 0;
+	dev->state = RTE_REGEXDEV_UNUSED;
+	return 0;
+}
+
+int
+rte_regexdev_attr_get(uint8_t dev_id, enum rte_regexdev_attr_id attr_id,
+		      void *attr_value)
+{
+	struct rte_regexdev *dev;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_attr_get, -ENOTSUP);
+	if (attr_value == NULL) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %d attribute value can't be NULL\n",
+				 dev_id);
+		return -EINVAL;
+	}
+	return (*dev->dev_ops->dev_attr_get)(dev, attr_id, attr_value);
+}
+
+int
+rte_regexdev_attr_set(uint8_t dev_id, enum rte_regexdev_attr_id attr_id,
+		      const void *attr_value)
+{
+	struct rte_regexdev *dev;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_attr_set, -ENOTSUP);
+	if (attr_value == NULL) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %d attribute value can't be NULL\n",
+				 dev_id);
+		return -EINVAL;
+	}
+	return (*dev->dev_ops->dev_attr_set)(dev, attr_id, attr_value);
+}
+
+int
+rte_regexdev_rule_db_update(uint8_t dev_id,
+			    const struct rte_regexdev_rule *rules,
+			    uint32_t nb_rules)
+{
+	struct rte_regexdev *dev;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_rule_db_update, -ENOTSUP);
+	if (rules == NULL) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %d rules can't be NULL\n",
+				 dev_id);
+		return -EINVAL;
+	}
+	return (*dev->dev_ops->dev_rule_db_update)(dev, rules, nb_rules);
+}
+
+int
+rte_regexdev_rule_db_compile_activate(uint8_t dev_id)
+{
+	struct rte_regexdev *dev;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_rule_db_compile_activate,
+				-ENOTSUP);
+	return (*dev->dev_ops->dev_rule_db_compile_activate)(dev);
+}
+
+int
+rte_regexdev_rule_db_import(uint8_t dev_id, const char *rule_db,
+			    uint32_t rule_db_len)
+{
+	struct rte_regexdev *dev;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_db_import,
+				-ENOTSUP);
+	if (rule_db == NULL) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %d rules can't be NULL\n",
+				 dev_id);
+		return -EINVAL;
+	}
+	return (*dev->dev_ops->dev_db_import)(dev, rule_db, rule_db_len);
+}
+
+int
+rte_regexdev_rule_db_export(uint8_t dev_id, char *rule_db)
+{
+	struct rte_regexdev *dev;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_db_export,
+				-ENOTSUP);
+	if (rule_db == NULL) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %d rules can't be NULL\n",
+				 dev_id);
+		return -EINVAL;
+	}
+	return (*dev->dev_ops->dev_db_export)(dev, rule_db);
+}
+
+int
+rte_regexdev_xstats_names_get(uint8_t dev_id,
+			      struct rte_regexdev_xstats_map *xstats_map)
+{
+	struct rte_regexdev *dev;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_xstats_names_get,
+				-ENOTSUP);
+	if (xstats_map == NULL) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %d xstats map can't be NULL\n",
+				 dev_id);
+		return -EINVAL;
+	}
+	return (*dev->dev_ops->dev_xstats_names_get)(dev, xstats_map);
+}
+
+int
+rte_regexdev_xstats_get(uint8_t dev_id, const uint16_t *ids,
+			uint64_t *values, uint16_t n)
+{
+	struct rte_regexdev *dev;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_xstats_get, -ENOTSUP);
+	if (ids == NULL) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %d ids can't be NULL\n", dev_id);
+		return -EINVAL;
+	}
+	if (values == NULL) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %d values can't be NULL\n", dev_id);
+		return -EINVAL;
+	}
+	return (*dev->dev_ops->dev_xstats_get)(dev, ids, values, n);
+}
+
+int
+rte_regexdev_xstats_by_name_get(uint8_t dev_id, const char *name,
+				uint16_t *id, uint64_t *value)
+{
+	struct rte_regexdev *dev;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_xstats_by_name_get,
+				-ENOTSUP);
+	if (name == NULL) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %d name can't be NULL\n", dev_id);
+		return -EINVAL;
+	}
+	if (id == NULL) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %d id can't be NULL\n", dev_id);
+		return -EINVAL;
+	}
+	if (value == NULL) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %d value can't be NULL\n", dev_id);
+		return -EINVAL;
+	}
+	return (*dev->dev_ops->dev_xstats_by_name_get)(dev, name, id, value);
+}
+
+int
+rte_regexdev_xstats_reset(uint8_t dev_id, const uint16_t *ids,
+			  uint16_t nb_ids)
+{
+	struct rte_regexdev *dev;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_xstats_reset, -ENOTSUP);
+	if (ids == NULL) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %d ids can't be NULL\n", dev_id);
+		return -EINVAL;
+	}
+	return (*dev->dev_ops->dev_xstats_reset)(dev, ids, nb_ids);
+}
+
+int
+rte_regexdev_selftest(uint8_t dev_id)
+{
+	struct rte_regexdev *dev;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_selftest, -ENOTSUP);
+	return (*dev->dev_ops->dev_selftest)(dev);
+}
+
+int
+rte_regexdev_dump(uint8_t dev_id, FILE *f)
+{
+	struct rte_regexdev *dev;
+
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	dev = &rte_regex_devices[dev_id];
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_dump, -ENOTSUP);
+	if (f == NULL) {
+		RTE_REGEXDEV_LOG(ERR, "Dev %d file can't be NULL\n", dev_id);
+		return -EINVAL;
+	}
+	return (*dev->dev_ops->dev_dump)(dev, f);
+}
diff --git a/lib/librte_regexdev/rte_regexdev.h b/lib/librte_regexdev/rte_regexdev.h
index 1e1ba8b..f87b1f9 100644
--- a/lib/librte_regexdev/rte_regexdev.h
+++ b/lib/librte_regexdev/rte_regexdev.h
@@ -213,6 +213,33 @@
 #define RTE_REGEXDEV_LOG(level, ...) \
 	rte_log(RTE_LOG_ ## level, rte_regexdev_logtype, "" __VA_ARGS__)
 
+/* Macros to check for valid port */
+#define RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, retval) do { \
+	if (!rte_regexdev_is_valid_dev(dev_id)) { \
+		RTE_REGEXDEV_LOG(ERR, "Invalid dev_id=%u\n", dev_id); \
+		return retval; \
+	} \
+} while (0)
+
+#define RTE_REGEXDEV_VALID_DEV_ID_OR_RET(dev_id) do { \
+	if (!rte_regexdev_is_valid_dev(dev_id)) { \
+		RTE_REGEXDEV_LOG(ERR, "Invalid dev_id=%u\n", dev_id); \
+		return; \
+	} \
+} while (0)
+
+/**
+ * Check if dev_id is ready.
+ *
+ * @param dev_id
+ *   The dev identifier of the RegEx device.
+ *
+ * @return
+ *   - 0 if device state is not in ready state.
+ *   - 1 if device state is ready state.
+ */
+int rte_regexdev_is_valid_dev(uint16_t dev_id);
+
 /**
  * @warning
  * @b EXPERIMENTAL: this API may change without prior notice.
@@ -803,10 +830,11 @@ struct rte_regexdev_qp_conf {
  * @param dev_id
  *   RegEx device identifier.
  *
- * @see struct rte_regexdev_qp_conf::cb, rte_regexdev_queue_pair_setup()
+ * @return
+ *   0 on success. Otherwise negative errno is returned.
  */
 __rte_experimental
-void
+int
 rte_regexdev_stop(uint8_t dev_id);
 
 /**
@@ -1384,6 +1412,8 @@ struct rte_regex_ops {
 	 */
 };
 
+#include "rte_regexdev_core.h"
+
 /**
  * @warning
  * @b EXPERIMENTAL: this API may change without prior notice.
@@ -1422,9 +1452,21 @@ struct rte_regex_ops {
  *   to take care of them.
  */
 __rte_experimental
-uint16_t
+static inline uint16_t
 rte_regexdev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
-			   struct rte_regex_ops **ops, uint16_t nb_ops);
+			   struct rte_regex_ops **ops, uint16_t nb_ops)
+{
+	struct rte_regexdev *dev = &rte_regex_devices[dev_id];
+#ifdef RTE_LIBRTE_REGEXDEV_DEBUG
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->enqueue, -ENOTSUP);
+	if (qp_id >= dev->data->dev_conf.nb_queue_pairs) {
+		RTE_REGEXDEV_LOG(ERR, "Invalid queue %d\n", qp_id);
+		return -EINVAL;
+	}
+#endif
+	return (*dev->enqueue)(dev, qp_id, ops, nb_ops);
+}
 
 /**
  * @warning
@@ -1469,11 +1511,21 @@ struct rte_regex_ops {
  *   of them.
  */
 __rte_experimental
-uint16_t
+static inline uint16_t
 rte_regexdev_dequeue_burst(uint8_t dev_id, uint16_t qp_id,
-			   struct rte_regex_ops **ops, uint16_t nb_ops);
-
-#include "rte_regexdev_core.h"
+			   struct rte_regex_ops **ops, uint16_t nb_ops)
+{
+	struct rte_regexdev *dev = &rte_regex_devices[dev_id];
+#ifdef RTE_LIBRTE_REGEXDEV_DEBUG
+	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dequeue, -ENOTSUP);
+	if (qp_id >= dev->data->dev_conf.nb_queue_pairs) {
+		RTE_REGEXDEV_LOG(ERR, "Invalid queue %d\n", qp_id);
+		return -EINVAL;
+	}
+#endif
+	return (*dev->dequeue)(dev, qp_id, ops, nb_ops);
+}
 
 #ifdef __cplusplus
 }
diff --git a/lib/librte_regexdev/rte_regexdev_core.h b/lib/librte_regexdev/rte_regexdev_core.h
index cbf054e..f817e65 100644
--- a/lib/librte_regexdev/rte_regexdev_core.h
+++ b/lib/librte_regexdev/rte_regexdev_core.h
@@ -150,6 +150,8 @@ struct rte_regexdev_data {
 	void *dev_private; /**< PMD-specific private data. */
 	char dev_name[RTE_REGEXDEV_NAME_MAX_LEN]; /**< Unique identifier name */
 	uint16_t dev_id; /**< Device [external]  identifier. */
+	struct rte_regexdev_config dev_conf; /**< RegEx configuration. */
+	uint8_t dev_started : 1; /**< Device started to work. */
 } __rte_cache_aligned;
 
 /**
@@ -172,4 +174,11 @@ struct rte_regexdev {
 	struct rte_regexdev_data *data;  /**< Pointer to device data. */
 } __rte_cache_aligned;
 
+/**
+ * @internal
+ * The pool of *rte_regexdev* structures. The size of the pool
+ * is configured at compile-time in the <rte_regexdev.c> file.
+ */
+extern struct rte_regexdev rte_regex_devices[];
+
 #endif /* _RTE_REGEX_CORE_H_ */
-- 
1.8.3.1


^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [PATCH v3 0/4] add RegEx class
  2020-05-07  9:45 ` [dpdk-dev] [PATCH v3 0/4] add RegEx class Ori Kam
                     ` (3 preceding siblings ...)
  2020-05-07  9:45   ` [dpdk-dev] [PATCH v3 4/4] regexdev: implement regex rte level functions Ori Kam
@ 2020-05-24 20:24   ` Ori Kam
  4 siblings, 0 replies; 96+ messages in thread
From: Ori Kam @ 2020-05-24 20:24 UTC (permalink / raw)
  To: Ori Kam, jerinj, xiang.w.wang, Guy Kaneti
  Cc: guyk, dev, pbhagavatula, Shahaf Shuler, hemant.agrawal,
	Opher Reviv, Alex Rosenbaum, dovrat, pkapoor, nipun.gupta,
	bruce.richardson, yang.a.hong, harry.chang, gu.jian1, shanjiangh,
	zhangy.yun, lixingfu, wushuai, yuyingxia, fanchenggang,
	davidfgao, liuzhong1, zhaoyong11, oc, jim, hongjun.ni,
	j.bromhead, deri, fc, arthur.su, Thomas Monjalon, Ori Kam

Hi,

Can you please review the latest changes and ack this patchset?
This is the base for the PMD code.

Thanks,
Ori

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Ori Kam
> Sent: Thursday, May 7, 2020 12:46 PM
> To: jerinj@marvell.com; xiang.w.wang@intel.com
> Cc: guyk@marvell.com; dev@dpdk.org; pbhagavatula@marvell.com; Shahaf
> Shuler <shahafs@mellanox.com>; hemant.agrawal@nxp.com; Opher Reviv
> <opher@mellanox.com>; Alex Rosenbaum <alexr@mellanox.com>;
> dovrat@marvell.com; pkapoor@marvell.com; nipun.gupta@nxp.com;
> bruce.richardson@intel.com; yang.a.hong@intel.com; harry.chang@intel.com;
> gu.jian1@zte.com.cn; shanjiangh@chinatelecom.cn;
> zhangy.yun@chinatelecom.cn; lixingfu@huachentel.com; wushuai@inspur.com;
> yuyingxia@yxlink.com; fanchenggang@sunyainfo.com;
> davidfgao@tencent.com; liuzhong1@chinaunicom.cn;
> zhaoyong11@huawei.com; oc@yunify.com; jim@netgate.com;
> hongjun.ni@intel.com; j.bromhead@titan-ic.com; deri@ntop.org;
> fc@napatech.com; arthur.su@lionic.com; Thomas Monjalon
> <thomas@monjalon.net>; Ori Kam <orika@mellanox.com>
> Subject: [dpdk-dev] [PATCH v3 0/4] add RegEx class
> 
> This patch set adds the RegEx class, which enables RegEx pattern
> matching, both on HW/SW PMDs.
> 
> Example for applications that will benefit from this class:
> * Next Generation Firewalls (NGFW)
> * Deep Packet and Flow Inspection (DPI)
> * Intrusion Prevention Systems (IPS)
> * DDoS Mitigation
> * Network Monitoring
> * Data Loss Prevention (DLP)
> * Smart NICs
> * Grammar based content processing
> * URL, spam and adware filtering
> * Advanced auditing and policing of user/application security policies
> * Financial data mining - parsing of streamed financial feeds
> * Application recognition.
> * Dmemory introspection.
> * Natural Language Processing (NLP)
> * Sentiment Analysis.
> * Big data databse acceleration.
> * Computational storage.
> 
> This patch set is based on RFC[1]
> 
> This class should be merged only after there is at least
> one PMD that implements it. Also the test application will
> be added when the first PMD is added.
> 
> 
> 
> [1]
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatches.d
> pdk.org%2Fpatch%2F66501%2F&amp;data=02%7C01%7Corika%40mellanox.co
> m%7C04fde98a87b44220935c08d7f26b7e9a%7Ca652971c7d2e4d9ba6a4d1492
> 56f461b%7C0%7C0%7C637244415831631650&amp;sdata=ZN1czuSz1c1xiKtvan
> xHS7oG9xxvPVE3keE2%2F4vPpwA%3D&amp;reserved=0
> 
> v3:
> * adress ML comments.
> 
> v2:
> * address ML comments.
> 
> 
> Jerin Jacob (1):
>   regexdev: introduce regexdev subsystem
> 
> Ori Kam (3):
>   regexdev: add regex core h file
>   regexdev: add regexdev core functions
>   regexdev: implement regex rte level functions
> 
>  config/common_base                           |    8 +
>  config/meson.build                           |    1 +
>  doc/api/doxy-api-index.md                    |    1 +
>  doc/api/doxy-api.conf.in                     |    1 +
>  doc/guides/prog_guide/index.rst              |    1 +
>  doc/guides/prog_guide/regexdev_lib.rst       |  177 +++
>  lib/Makefile                                 |    2 +
>  lib/librte_regexdev/Makefile                 |   33 +
>  lib/librte_regexdev/meson.build              |   10 +
>  lib/librte_regexdev/rte_regexdev.c           |  573 ++++++++++
>  lib/librte_regexdev/rte_regexdev.h           | 1534
> ++++++++++++++++++++++++++
>  lib/librte_regexdev/rte_regexdev_core.h      |  184 +++
>  lib/librte_regexdev/rte_regexdev_driver.h    |   59 +
>  lib/librte_regexdev/rte_regexdev_version.map |   26 +
>  lib/meson.build                              |    2 +-
>  meson_options.txt                            |    2 +
>  16 files changed, 2613 insertions(+), 1 deletion(-)
>  create mode 100644 doc/guides/prog_guide/regexdev_lib.rst
>  create mode 100644 lib/librte_regexdev/Makefile
>  create mode 100644 lib/librte_regexdev/meson.build
>  create mode 100644 lib/librte_regexdev/rte_regexdev.c
>  create mode 100644 lib/librte_regexdev/rte_regexdev.h
>  create mode 100644 lib/librte_regexdev/rte_regexdev_core.h
>  create mode 100644 lib/librte_regexdev/rte_regexdev_driver.h
>  create mode 100644 lib/librte_regexdev/rte_regexdev_version.map
> 
> --
> 1.8.3.1


^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v3 2/4] regexdev: add regex core h file
  2020-05-07  9:45   ` [dpdk-dev] [PATCH v3 2/4] regexdev: add regex core h file Ori Kam
@ 2020-06-03  6:47     ` Guy Kaneti
  0 siblings, 0 replies; 96+ messages in thread
From: Guy Kaneti @ 2020-06-03  6:47 UTC (permalink / raw)
  To: Ori Kam, Jerin Kollanukkaran, xiang.w.wang
  Cc: dev, Pavan Nikhilesh Bhagavatula, shahafs, hemant.agrawal, opher,
	alexr, Dovrat Zifroni, Prasun Kapoor, nipun.gupta,
	bruce.richardson, yang.a.hong, harry.chang, gu.jian1, shanjiangh,
	zhangy.yun, lixingfu, wushuai, yuyingxia, fanchenggang,
	davidfgao, liuzhong1, zhaoyong11, oc, jim, hongjun.ni,
	j.bromhead, deri, fc, arthur.su, thomas

Acked-by: Guy Kaneti <guyk@marvell.com>

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v3 3/4] regexdev: add regexdev core functions
  2020-05-07  9:45   ` [dpdk-dev] [PATCH v3 3/4] regexdev: add regexdev core functions Ori Kam
@ 2020-06-03  6:57     ` Guy Kaneti
  0 siblings, 0 replies; 96+ messages in thread
From: Guy Kaneti @ 2020-06-03  6:57 UTC (permalink / raw)
  To: Ori Kam, Jerin Kollanukkaran, xiang.w.wang
  Cc: dev, Pavan Nikhilesh Bhagavatula, shahafs, hemant.agrawal, opher,
	alexr, Dovrat Zifroni, Prasun Kapoor, nipun.gupta,
	bruce.richardson, yang.a.hong, harry.chang, gu.jian1, shanjiangh,
	zhangy.yun, lixingfu, wushuai, yuyingxia, fanchenggang,
	davidfgao, liuzhong1, zhaoyong11, oc, jim, hongjun.ni,
	j.bromhead, deri, fc, arthur.su, thomas, Parav Pandit



> -----Original Message-----
> From: Ori Kam <orika@mellanox.com>
> Sent: Thursday, May 07, 2020 12:46 PM
> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>;
> xiang.w.wang@intel.com
> Cc: Guy Kaneti <guyk@marvell.com>; dev@dpdk.org; Pavan Nikhilesh
> Bhagavatula <pbhagavatula@marvell.com>; shahafs@mellanox.com;
> hemant.agrawal@nxp.com; opher@mellanox.com; alexr@mellanox.com;
> Dovrat Zifroni <dovrat@marvell.com>; Prasun Kapoor
> <pkapoor@marvell.com>; nipun.gupta@nxp.com;
> bruce.richardson@intel.com; yang.a.hong@intel.com;
> harry.chang@intel.com; gu.jian1@zte.com.cn; shanjiangh@chinatelecom.cn;
> zhangy.yun@chinatelecom.cn; lixingfu@huachentel.com;
> wushuai@inspur.com; yuyingxia@yxlink.com;
> fanchenggang@sunyainfo.com; davidfgao@tencent.com;
> liuzhong1@chinaunicom.cn; zhaoyong11@huawei.com; oc@yunify.com;
> jim@netgate.com; hongjun.ni@intel.com; j.bromhead@titan-ic.com;
> deri@ntop.org; fc@napatech.com; arthur.su@lionic.com;
> thomas@monjalon.net; orika@mellanox.com; Parav Pandit
> <parav@mellanox.com>
> Subject: [EXT] [PATCH v3 3/4] regexdev: add regexdev core functions
> 
> External Email
> 
> ----------------------------------------------------------------------
> This commit introduce the API that is needed by the RegEx devices in order
> to work with the RegEX lib.
> 
> During the probe of a RegEx device, the device should configure itself, and
> allocate the resources it requires.
> On completion of the device init, it should call the rte_regex_dev_register in
> order to register itself as a RegEx device.
> 
> Signed-off-by: Ori Kam <orika@mellanox.com>
> Signed-off-by: Parav Pandit <parav@mellanox.com>

Acked-by: Guy Kaneti <guyk@marvell.com>

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v3 4/4] regexdev: implement regex rte level functions
  2020-05-07  9:45   ` [dpdk-dev] [PATCH v3 4/4] regexdev: implement regex rte level functions Ori Kam
@ 2020-06-03  6:59     ` Guy Kaneti
  2020-06-28 13:45     ` Guy Kaneti
  1 sibling, 0 replies; 96+ messages in thread
From: Guy Kaneti @ 2020-06-03  6:59 UTC (permalink / raw)
  To: Ori Kam, Jerin Kollanukkaran, xiang.w.wang
  Cc: dev, Pavan Nikhilesh Bhagavatula, shahafs, hemant.agrawal, opher,
	alexr, Dovrat Zifroni, Prasun Kapoor, nipun.gupta,
	bruce.richardson, yang.a.hong, harry.chang, gu.jian1, shanjiangh,
	zhangy.yun, lixingfu, wushuai, yuyingxia, fanchenggang,
	davidfgao, liuzhong1, zhaoyong11, oc, jim, hongjun.ni,
	j.bromhead, deri, fc, arthur.su, thomas



> -----Original Message-----
> From: Ori Kam <orika@mellanox.com>
> Sent: Thursday, May 07, 2020 12:46 PM
> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>;
> xiang.w.wang@intel.com
> Cc: Guy Kaneti <guyk@marvell.com>; dev@dpdk.org; Pavan Nikhilesh
> Bhagavatula <pbhagavatula@marvell.com>; shahafs@mellanox.com;
> hemant.agrawal@nxp.com; opher@mellanox.com; alexr@mellanox.com;
> Dovrat Zifroni <dovrat@marvell.com>; Prasun Kapoor
> <pkapoor@marvell.com>; nipun.gupta@nxp.com;
> bruce.richardson@intel.com; yang.a.hong@intel.com;
> harry.chang@intel.com; gu.jian1@zte.com.cn; shanjiangh@chinatelecom.cn;
> zhangy.yun@chinatelecom.cn; lixingfu@huachentel.com;
> wushuai@inspur.com; yuyingxia@yxlink.com;
> fanchenggang@sunyainfo.com; davidfgao@tencent.com;
> liuzhong1@chinaunicom.cn; zhaoyong11@huawei.com; oc@yunify.com;
> jim@netgate.com; hongjun.ni@intel.com; j.bromhead@titan-ic.com;
> deri@ntop.org; fc@napatech.com; arthur.su@lionic.com;
> thomas@monjalon.net; orika@mellanox.com
> Subject: [EXT] [PATCH v3 4/4] regexdev: implement regex rte level functions
> 
> External Email
> 
> ----------------------------------------------------------------------
> This commit implements all the RegEx public API.
> 
> Signed-off-by: Ori Kam <orika@mellanox.com>

Acked-by: Guy Kaneti <guyk@marvell.com>

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [PATCH v3 1/4] regexdev: introduce regexdev subsystem
  2020-05-07  9:45   ` [dpdk-dev] [PATCH v3 1/4] regexdev: introduce regexdev subsystem Ori Kam
@ 2020-06-21 11:18     ` Ori Kam
  2020-06-30 19:57       ` Ori Kam
  0 siblings, 1 reply; 96+ messages in thread
From: Ori Kam @ 2020-06-21 11:18 UTC (permalink / raw)
  To: Ori Kam, jerinj, xiang.w.wang
  Cc: guyk, dev, pbhagavatula, Shahaf Shuler, hemant.agrawal,
	Opher Reviv, Alex Rosenbaum, dovrat, pkapoor, nipun.gupta,
	bruce.richardson, yang.a.hong, harry.chang, gu.jian1, shanjiangh,
	zhangy.yun, lixingfu, wushuai, yuyingxia, fanchenggang,
	davidfgao, liuzhong1, zhaoyong11, oc, jim, hongjun.ni,
	j.bromhead, deri, fc, arthur.su, Thomas Monjalon

Hi All,

This is the only patch that is missing an ack,

I plan to submit the PMD code next week, so please review and ack this patch.

Thanks,
Ori

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Ori Kam
> Sent: Thursday, May 7, 2020 12:46 PM
> To: jerinj@marvell.com; xiang.w.wang@intel.com
> Cc: guyk@marvell.com; dev@dpdk.org; pbhagavatula@marvell.com; Shahaf
> Shuler <shahafs@mellanox.com>; hemant.agrawal@nxp.com; Opher Reviv
> <opher@mellanox.com>; Alex Rosenbaum <alexr@mellanox.com>;
> dovrat@marvell.com; pkapoor@marvell.com; nipun.gupta@nxp.com;
> bruce.richardson@intel.com; yang.a.hong@intel.com; harry.chang@intel.com;
> gu.jian1@zte.com.cn; shanjiangh@chinatelecom.cn;
> zhangy.yun@chinatelecom.cn; lixingfu@huachentel.com; wushuai@inspur.com;
> yuyingxia@yxlink.com; fanchenggang@sunyainfo.com;
> davidfgao@tencent.com; liuzhong1@chinaunicom.cn;
> zhaoyong11@huawei.com; oc@yunify.com; jim@netgate.com;
> hongjun.ni@intel.com; j.bromhead@titan-ic.com; deri@ntop.org;
> fc@napatech.com; arthur.su@lionic.com; Thomas Monjalon
> <thomas@monjalon.net>; Ori Kam <orika@mellanox.com>
> Subject: [dpdk-dev] [PATCH v3 1/4] regexdev: introduce regexdev subsystem
> 
> From: Jerin Jacob <jerinj@marvell.com>
> 
> As RegEx usage become more used by DPDK applications, for example:
> * Next Generation Firewalls (NGFW)
> * Deep Packet and Flow Inspection (DPI)
> * Intrusion Prevention Systems (IPS)
> * DDoS Mitigation
> * Network Monitoring
> * Data Loss Prevention (DLP)
> * Smart NICs
> * Grammar based content processing
> * URL, spam and adware filtering
> * Advanced auditing and policing of user/application security policies
> * Financial data mining - parsing of streamed financial feeds
> * Application recognition.
> * Dmemory introspection.
> * Natural Language Processing (NLP)
> * Sentiment Analysis.
> * Big data databse acceleration.
> * Computational storage.
> 
> Number of PMD providers started to work on HW implementation,
> along side with SW implementations.
> 
> This lib adds the support for those kind of devices.
> 
> The RegEx Device API is composed of two parts:
> - The application-oriented RegEx API that includes functions to setup
>   a RegEx device (configure it, setup its queue pairs and start it),
>   update the rule database and so on.
> 
> - The driver-oriented RegEx API that exports a function allowing
>   a RegEx poll Mode Driver (PMD) to simultaneously register itself as
>   a RegEx device driver.
> 
> RegEx device components and definitions:
> 
>     +-----------------+
>     |                 |
>     |                 o---------+    rte_regexdev_[en|de]queue_burst()
>     |   PCRE based    o------+  |               |
>     |  RegEx pattern  |      |  |  +--------+   |
>     | matching engine o------+--+--o        |   |    +------+
>     |                 |      |  |  | queue  |<==o===>|Core 0|
>     |                 o----+ |  |  | pair 0 |        |      |
>     |                 |    | |  |  +--------+        +------+
>     +-----------------+    | |  |
>            ^               | |  |  +--------+
>            |               | |  |  |        |        +------+
>            |               | +--+--o queue  |<======>|Core 1|
>        Rule|Database       |    |  | pair 1 |        |      |
>     +------+----------+    |    |  +--------+        +------+
>     |     Group 0     |    |    |
>     | +-------------+ |    |    |  +--------+        +------+
>     | | Rules 0..n  | |    |    |  |        |        |Core 2|
>     | +-------------+ |    |    +--o queue  |<======>|      |
>     |     Group 1     |    |       | pair 2 |        +------+
>     | +-------------+ |    |       +--------+
>     | | Rules 0..n  | |    |
>     | +-------------+ |    |       +--------+
>     |     Group 2     |    |       |        |        +------+
>     | +-------------+ |    |       | queue  |<======>|Core n|
>     | | Rules 0..n  | |    +-------o pair n |        |      |
>     | +-------------+ |            +--------+        +------+
>     |     Group n     |
>     | +-------------+ |<-------rte_regexdev_rule_db_update()
>     | |             | |<-------rte_regexdev_rule_db_compile_activate()
>     | | Rules 0..n  | |<-------rte_regexdev_rule_db_import()
>     | +-------------+ |------->rte_regexdev_rule_db_export()
>     +-----------------+
> 
> RegEx: A regular expression is a concise and flexible means for matching
> strings of text, such as particular characters, words, or patterns of
> characters. A common abbreviation for this is â~@~\RegExâ~@~].
> 
> RegEx device: A hardware or software-based implementation of RegEx
> device API for PCRE based pattern matching syntax and semantics.
> 
> PCRE RegEx syntax and semantics specification:
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fregexkit.so
> urceforge.net%2FDocumentation%2Fpcre%2Fpcrepattern.html&amp;data=02%
> 7C01%7Corika%40mellanox.com%7C39f5765e405c46b18ba308d7f26b8480%7C
> a652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C637244415961144968&a
> mp;sdata=NWYja3g5nTerSe8vIFSHpTeK8ipKOhMnXmmNBuJtWqY%3D&amp;res
> erved=0
> 
> RegEx queue pair: Each RegEx device should have one or more queue pair to
> transmit a burst of pattern matching request and receive a burst of
> receive the pattern matching response. The pattern matching
> request/response embedded in *rte_regex_ops* structure.
> 
> Rule: A pattern matching rule expressed in PCRE RegEx syntax along with
> Match ID and Group ID to identify the rule upon the match.
> 
> Rule database: The RegEx device accepts regular expressions and converts
> them into a compiled rule database that can then be used to scan data.
> Compilation allows the device to analyze the given pattern(s) and
> pre-determine how to scan for these patterns in an optimized fashion that
> would be far too expensive to compute at run-time. A rule database
> contains a set of rules that compiled in device specific binary form.
> 
> Match ID or Rule ID: A unique identifier provided at the time of rule
> creation for the application to identify the rule upon match.
> 
> Group ID: Group of rules can be grouped under one group ID to enable
> rule isolation and effective pattern matching. A unique group identifier
> provided at the time of rule creation for the application to identify
> the rule upon match.
> 
> Scan: A pattern matching request through *enqueue* API.
> 
> It may possible that a given RegEx device may not support all the
> features
> of PCRE. The application may probe unsupported features through
> struct rte_regexdev_info::pcre_unsup_flags
> 
> By default, all the functions of the RegEx Device API exported by a PMD
> are lock-free functions which assume to not be invoked in parallel on
> different logical cores to work on the same target object. For instance,
> the dequeue function of a PMD cannot be invoked in parallel on two logical
> cores to operates on same RegEx queue pair. Of course, this function
> can be invoked in parallel by different logical core on different queue
> pair. It is the responsibility of the upper level application to
> enforce this rule.
> 
> In all functions of the RegEx API, the RegEx device is
> designated by an integer >= 0 named the device identifier *dev_id*
> 
> At the RegEx driver level, RegEx devices are represented by a generic
> data structure of type *rte_regexdev*.
> RegEx devices are dynamically registered during the PCI/SoC device
> probing phase performed at EAL initialization time.
> When a RegEx device is being probed, a *rte_regexdev* structure and
> a new device identifier are allocated for that device. Then, the
> regexdev_init() function supplied by the RegEx driver matching the
> probed device is invoked to properly initialize the device.
> 
> The role of the device init function consists of resetting the hardware
> or software RegEx driver implementations.
> 
> If the device init operation is successful, the correspondence between
> the device identifier assigned to the new device and its associated
> *rte_regexdev* structure is effectively registered.
> Otherwise, both the *rte_regexdev* structure and the device identifier
> are freed.
> 
> The functions exported by the application RegEx API to setup a device
> designated by its device identifier must be invoked in the following
> order:
>     - rte_regexdev_configure()
>     - rte_regexdev_queue_pair_setup()
>     - rte_regexdev_start()
> 
> Then, the application can invoke, in any order, the functions
> exported by the RegEx API to enqueue pattern matching job, dequeue
> pattern matching response, get the stats, update the rule database,
> get/set device attributes and so on
> 
> If the application wants to change the configuration (i.e. call
> rte_regexdev_configure() or rte_regexdev_queue_pair_setup()), it must
> call rte_regexdev_stop() first to stop the device and then do the
> reconfiguration before calling rte_regexdev_start() again. The enqueue and
> dequeue functions should not be invoked when the device is stopped.
> 
> Finally, an application can close a RegEx device by invoking the
> rte_regexdev_close() function.
> 
> Each function of the application RegEx API invokes a specific function
> of the PMD that controls the target device designated by its device
> identifier.
> 
> For this purpose, all device-specific functions of a RegEx driver are
> supplied through a set of pointers contained in a generic structure of
> type *regexdev_ops*.
> The address of the *regexdev_ops* structure is stored in the
> *rte_regexdev* structure by the device init function of the RegEx driver,
> which is invoked during the PCI/SoC device probing phase, as explained
> earlier.
> 
> In other words, each function of the RegEx API simply retrieves the
> *rte_regexdev* structure associated with the device identifier and
> performs an indirect invocation of the corresponding driver function
> supplied in the *regexdev_ops* structure of the *rte_regexdev*
> structure.
> 
> For performance reasons, the address of the fast-path functions of the
> RegEx driver is not contained in the *regexdev_ops* structure.
> Instead, they are directly stored at the beginning of the *rte_regexdev*
> structure to avoid an extra indirect memory access during their
> invocation.
> 
> RTE RegEx device drivers do not use interrupts for enqueue or dequeue
> operation. Instead, RegEx drivers export Poll-Mode enqueue and dequeue
> functions to applications.
> 
> The *enqueue* operation submits a burst of RegEx pattern matching
> request to the RegEx device and the *dequeue* operation gets a burst of
> pattern matching response for the ones submitted through *enqueue*
> operation.
> 
> Typical application utilisation of the RegEx device API will follow the
> following programming flow.
> 
> - rte_regexdev_configure()
> - rte_regexdev_queue_pair_setup()
> - rte_regexdev_rule_db_update() Needs to invoke if precompiled rule
>   database not
>   provided in rte_regexdev_config::rule_db for rte_regexdev_configure()
>   and/or application needs to update rule database.
> - rte_regexdev_rule_db_compile_activate() Needs to invoke if
>   rte_regexdev_rule_db_update function was used.
> - Create or reuse exiting mempool for *rte_regex_ops* objects.
> - rte_regexdev_start()
> - rte_regexdev_enqueue_burst()
> - rte_regexdev_dequeue_burst()
> 
> Signed-off-by: Jerin Jacob <jerinj@marvell.com>
> Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
> Signed-off-by: Ori Kam <orika@mellanox.com>
> ---
> v3:
> * No changes.
> 
> v2:
> * Move unused define to other patch.
> ---
>  config/common_base                           |    6 +
>  doc/api/doxy-api-index.md                    |    1 +
>  doc/api/doxy-api.conf.in                     |    1 +
>  doc/guides/prog_guide/index.rst              |    1 +
>  doc/guides/prog_guide/regexdev_lib.rst       |  177 ++++
>  lib/Makefile                                 |    2 +
>  lib/librte_regexdev/Makefile                 |   31 +
>  lib/librte_regexdev/meson.build              |    7 +
>  lib/librte_regexdev/rte_regexdev.c           |    6 +
>  lib/librte_regexdev/rte_regexdev.h           | 1473
> ++++++++++++++++++++++++++
>  lib/librte_regexdev/rte_regexdev_version.map |   26 +
>  lib/meson.build                              |    2 +-
>  12 files changed, 1732 insertions(+), 1 deletion(-)
>  create mode 100644 doc/guides/prog_guide/regexdev_lib.rst
>  create mode 100644 lib/librte_regexdev/Makefile
>  create mode 100644 lib/librte_regexdev/meson.build
>  create mode 100644 lib/librte_regexdev/rte_regexdev.c
>  create mode 100644 lib/librte_regexdev/rte_regexdev.h
>  create mode 100644 lib/librte_regexdev/rte_regexdev_version.map
> 
> diff --git a/config/common_base b/config/common_base
> index 14000ba..27fcab1 100644
> --- a/config/common_base
> +++ b/config/common_base
> @@ -832,6 +832,11 @@
> CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_EP_RAWDEV=y
>  CONFIG_RTE_LIBRTE_PMD_NTB_RAWDEV=y
> 
>  #
> +# Compile regex device support
> +#
> +CONFIG_RTE_LIBRTE_REGEXDEV=y
> +
> +#
>  # Compile librte_ring
>  #
>  CONFIG_RTE_LIBRTE_RING=y
> @@ -1124,3 +1129,4 @@ CONFIG_RTE_APP_CRYPTO_PERF=y
>  # Compile the eventdev application
>  #
>  CONFIG_RTE_APP_EVENTDEV=y
> +
> diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
> index 845a534..702591b 100644
> --- a/doc/api/doxy-api-index.md
> +++ b/doc/api/doxy-api-index.md
> @@ -26,6 +26,7 @@ The public API headers are grouped by topics:
>    [event_timer_adapter]    (@ref rte_event_timer_adapter.h),
>    [event_crypto_adapter]   (@ref rte_event_crypto_adapter.h),
>    [rawdev]             (@ref rte_rawdev.h),
> +  [regexdev]           (@ref rte_regexdev.h),
>    [metrics]            (@ref rte_metrics.h),
>    [bitrate]            (@ref rte_bitrate.h),
>    [latency]            (@ref rte_latencystats.h),
> diff --git a/doc/api/doxy-api.conf.in b/doc/api/doxy-api.conf.in
> index 65e8146..84621ba 100644
> --- a/doc/api/doxy-api.conf.in
> +++ b/doc/api/doxy-api.conf.in
> @@ -58,6 +58,7 @@ INPUT                   = @TOPDIR@/doc/api/doxy-api-
> index.md \
>                            @TOPDIR@/lib/librte_rcu \
>                            @TOPDIR@/lib/librte_reorder \
>                            @TOPDIR@/lib/librte_rib \
> +                          @TOPDIR@/lib/librte_regexdev \
>                            @TOPDIR@/lib/librte_ring \
>                            @TOPDIR@/lib/librte_sched \
>                            @TOPDIR@/lib/librte_security \
> diff --git a/doc/guides/prog_guide/index.rst b/doc/guides/prog_guide/index.rst
> index 1d0cd49..fa8536c 100644
> --- a/doc/guides/prog_guide/index.rst
> +++ b/doc/guides/prog_guide/index.rst
> @@ -71,3 +71,4 @@ Programmer's Guide
>      lto
>      profile_app
>      glossary
> +    regexdev_lib
> diff --git a/doc/guides/prog_guide/regexdev_lib.rst
> b/doc/guides/prog_guide/regexdev_lib.rst
> new file mode 100644
> index 0000000..1ecbf1c
> --- /dev/null
> +++ b/doc/guides/prog_guide/regexdev_lib.rst
> @@ -0,0 +1,177 @@
> +..  SPDX-License-Identifier: BSD-3-Clause
> +    Copyright(c) 2020 Mellanox Corporation.
> +
> +RegEx Device Library
> +=====================
> +
> +The RegEx library provides a RegEx device framework for management and
> +provisioning of hardware and software RegEx poll mode drivers, defining
> generic
> +APIs which support a number of different RegEx operations.
> +
> +
> +Design Principles
> +-----------------
> +
> +The RegEx library follows the same basic principles as those used in DPDK's
> +Ethernet Device framework and the Crypto framework. The RegEx framework
> provides
> +a generic Crypto device framework which supports both physical (hardware)
> +and virtual (software) RegEx devices as well as a generic RegEx API which
> allows
> +RegEx devices to be managed and configured and supports RegEx operations
> to be
> +provisioned on RegEx poll mode driver.
> +
> +
> +Device Management
> +-----------------
> +
> +Device Creation
> +~~~~~~~~~~~~~~~
> +
> +Physical RegEx devices are discovered during the PCI probe/enumeration of
> the
> +EAL function which is executed at DPDK initialization, based on
> +their PCI device identifier, each unique PCI BDF (bus/bridge, device,
> +function). Specific physical ReEx devices, like other physical devices in DPDK
> +can be white-listed or black-listed using the EAL command line options.
> +
> +
> +Device Identification
> +~~~~~~~~~~~~~~~~~~~~~
> +
> +Each device, whether virtual or physical is uniquely designated by two
> +identifiers:
> +
> +- A unique device index used to designate the RegEx device in all functions
> +  exported by the regexdev API.
> +
> +- A device name used to designate the RegEx device in console messages, for
> +  administration or debugging purposes.
> +
> +
> +Device Configuration
> +~~~~~~~~~~~~~~~~~~~~
> +
> +The configuration of each RegEx device includes the following operations:
> +
> +- Allocation of resources, including hardware resources if a physical device.
> +- Resetting the device into a well-known default state.
> +- Initialization of statistics counters.
> +
> +The rte_regexdev_configure API is used to configure a RegEx device.
> +
> +.. code-block:: c
> +
> +   int rte_regexdev_configure(uint8_t dev_id,
> +                              const struct rte_regexdev_config *cfg);
> +
> +The ``rte_regexdev_config`` structure is used to pass the configuration
> +parameters for the RegEx device for example  number of queue pairs,
> number of
> +groups, max number of matches and so on.
> +
> +.. code-block:: c
> +
> +   struct rte_regexdev_config {
> +        uint16_t nb_max_matches;
> +        /**< Maximum matches per scan configured on this device.
> +         * This value cannot exceed the *max_matches*
> +         * which previously provided in rte_regexdev_info_get().
> +         * The value 0 is allowed, in which case, value 1 used.
> +         * @see struct rte_regexdev_info::max_matches
> +         */
> +        uint16_t nb_queue_pairs;
> +        /**< Number of RegEx queue pairs to configure on this device.
> +         * This value cannot exceed the *max_queue_pairs* which previously
> +         * provided in rte_regexdev_info_get().
> +         * @see struct rte_regexdev_info::max_queue_pairs
> +         */
> +        uint32_t nb_rules_per_group;
> +        /**< Number of rules per group to configure on this device.
> +         * This value cannot exceed the *max_rules_per_group*
> +         * which previously provided in rte_regexdev_info_get().
> +         * The value 0 is allowed, in which case,
> +         * struct rte_regexdev_info::max_rules_per_group used.
> +         * @see struct rte_regexdev_info::max_rules_per_group
> +         */
> +        uint16_t nb_groups;
> +        /**< Number of groups to configure on this device.
> +         * This value cannot exceed the *max_groups*
> +         * which previously provided in rte_regexdev_info_get().
> +         * @see struct rte_regexdev_info::max_groups
> +         */
> +        const char *rule_db;
> +        /**< Import initial set of prebuilt rule database on this device.
> +         * The value NULL is allowed, in which case, the device will not
> +         * be configured prebuilt rule database. Application may use
> +         * rte_regexdev_rule_db_update() or rte_regexdev_rule_db_import() API
> +         * to update or import rule database after the
> +         * rte_regexdev_configure().
> +         * @see rte_regexdev_rule_db_update(), rte_regexdev_rule_db_import()
> +         */
> +        uint32_t rule_db_len;
> +        /**< Length of *rule_db* buffer. */
> +        uint32_t dev_cfg_flags;
> +        /**< RegEx device configuration flags, See RTE_REGEXDEV_CFG_*  */
> +    };
> +
> +
> +Configuration of Rules Database
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +Each Regex device should be configured with the rule database.
> +There are two modes of setting the rule database, online or offline.
> +The online mode means, that the rule database in being compiled by the
> +RegEx PMD while in the offline mode the rule database is compiled by
> external
> +compiler, and is being loaded to the PMD as a buffer.
> +The configuration mode is depended on the PMD capabilities.
> +
> +Online rule configuration is done using the following API functions:
> +``rte_regexdev_rule_db_update`` which add / remove rules from the rules
> +precomplied list, and ``rte_regexdev_rule_db_compile_activate``
> +which compile the rules and loads them to the RegEx HW.
> +
> +Offline rule configuration can be done by adding a pointer to the compiled
> +rule database in the configuration step, or by using
> +``rte_regexdev_rule_db_import`` API.
> +
> +
> +Configuration of Queue Pairs
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +Each RegEx device can be configured with number of queue pairs.
> +Each queue pair is configured using ``rte_regexdev_queue_pair_setup``
> +
> +
> +Logical Cores, Memory and Queues Pair Relationships
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +Multiple logical cores should never share the same queue pair for enqueuing
> +operations or dequeuing operations on the same RegEx device since this
> would
> +require global locks and hinder performance.
> +
> +
> +Device Features and Capabilities
> +---------------------------------
> +
> +RegEx devices may support different feature set.
> +In order to get the supported PMD feature ``rte_regexdev_info_get``
> +API which return the info of the device and it's supported features.
> +
> +
> +Enqueue / Dequeue Burst APIs
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +The burst enqueue API uses a RegEx device identifier and a queue pair
> +identifier to specify the device queue pair to schedule the processing on.
> +The ``nb_ops`` parameter is the number of operations to process which are
> +supplied in the ``ops`` array of ``rte_regex_ops`` structures.
> +The enqueue function returns the number of operations it actually enqueued
> for
> +processing, a return value equal to ``nb_ops`` means that all packets have
> been
> +enqueued.
> +
> +Data pointed in each op, should not be released until the dequeue of for that
> +op.
> +
> +The dequeue API uses the same format as the enqueue API of processed but
> +the ``nb_ops`` and ``ops`` parameters are now used to specify the max
> processed
> +operations the user wishes to retrieve and the location in which to store them.
> +The API call returns the actual number of processed operations returned, this
> +can never be larger than ``nb_ops``.
> +
> diff --git a/lib/Makefile b/lib/Makefile
> index d0ec391..6a3d4e3 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -44,6 +44,8 @@ DEPDIRS-librte_eventdev := librte_eal librte_ring
> librte_ethdev librte_hash \
>                             librte_mempool librte_timer librte_cryptodev
>  DIRS-$(CONFIG_RTE_LIBRTE_RAWDEV) += librte_rawdev
>  DEPDIRS-librte_rawdev := librte_eal librte_ethdev
> +DIRS-$(CONFIG_RTE_LIBRTE_REGEXDEV) += librte_regexdev
> +DEPDIRS-librte_regexdev := librte_eal librte_mbuf
>  DIRS-$(CONFIG_RTE_LIBRTE_VHOST) += librte_vhost
>  DEPDIRS-librte_vhost := librte_eal librte_mempool librte_mbuf librte_ethdev \
>  			librte_net librte_hash librte_cryptodev
> diff --git a/lib/librte_regexdev/Makefile b/lib/librte_regexdev/Makefile
> new file mode 100644
> index 0000000..6f4cc63
> --- /dev/null
> +++ b/lib/librte_regexdev/Makefile
> @@ -0,0 +1,31 @@
> +# SPDX-License-Identifier: BSD-3-Clause
> +# Copyright(C) 2019 Marvell International Ltd.
> +# Copyright(C) 2020 Mellanox International Ltd.
> +#
> +
> +include $(RTE_SDK)/mk/rte.vars.mk
> +
> +# library name
> +LIB = librte_regexdev.a
> +
> +EXPORT_MAP := rte_regex_version.map
> +
> +# library version
> +LIBABIVER := 1
> +
> +# build flags
> +CFLAGS += -O3
> +CFLAGS += $(WERROR_FLAGS)
> +LDLIBS += -lrte_eal -lrte_mbuf
> +
> +# library source files
> +# all source are stored in SRCS-y
> +SRCS-$(CONFIG_RTE_LIBRTE_REGEXDEV) := rte_regexdev.c
> +
> +# export include files
> +SYMLINK-$(CONFIG_RTE_LIBRTE_REGEXDEV)-include += rte_regexdev.h
> +
> +# versioning export map
> +EXPORT_MAP := rte_regexdev_version.map
> +
> +include $(RTE_SDK)/mk/rte.lib.mk
> diff --git a/lib/librte_regexdev/meson.build b/lib/librte_regexdev/meson.build
> new file mode 100644
> index 0000000..f4db748
> --- /dev/null
> +++ b/lib/librte_regexdev/meson.build
> @@ -0,0 +1,7 @@
> +# SPDX-License-Identifier: BSD-3-Clause
> +# Copyright(c) 2020 Mellanox Corporation
> +
> +allow_experimental_apis = true
> +sources = files('rte_regexdev.c')
> +headers = files('rte_regexdev.h')
> +deps += ['mbuf']
> diff --git a/lib/librte_regexdev/rte_regexdev.c
> b/lib/librte_regexdev/rte_regexdev.c
> new file mode 100644
> index 0000000..b901877
> --- /dev/null
> +++ b/lib/librte_regexdev/rte_regexdev.c
> @@ -0,0 +1,6 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(C) 2019 Marvell International Ltd.
> + * Copyright(C) 2020 Mellanox International Ltd.
> + */
> +
> +#include <rte_regexdev.h>
> diff --git a/lib/librte_regexdev/rte_regexdev.h
> b/lib/librte_regexdev/rte_regexdev.h
> new file mode 100644
> index 0000000..7e688d9
> --- /dev/null
> +++ b/lib/librte_regexdev/rte_regexdev.h
> @@ -0,0 +1,1473 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(C) 2019 Marvell International Ltd.
> + * Copyright(C) 2020 Mellanox International Ltd.
> + * Copyright(C) 2020 Intel International Ltd.
> + */
> +
> +#ifndef _RTE_REGEXDEV_H_
> +#define _RTE_REGEXDEV_H_
> +
> +/**
> + * @file
> + *
> + * RTE RegEx Device API
> + *
> + * Defines RTE RegEx Device APIs for RegEx operations and its provisioning.
> + *
> + * The RegEx Device API is composed of two parts:
> + *
> + * - The application-oriented RegEx API that includes functions to setup
> + *   a RegEx device (configure it, setup its queue pairs and start it),
> + *   update the rule database and so on.
> + *
> + * - The driver-oriented RegEx API that exports a function allowing
> + *   a RegEx poll Mode Driver (PMD) to simultaneously register itself as
> + *   a RegEx device driver.
> + *
> + * RegEx device components and definitions:
> + *
> + *     +-----------------+
> + *     |                 |
> + *     |                 o---------+    rte_regexdev_[en|de]queue_burst()
> + *     |   PCRE based    o------+  |               |
> + *     |  RegEx pattern  |      |  |  +--------+   |
> + *     | matching engine o------+--+--o        |   |    +------+
> + *     |                 |      |  |  | queue  |<==o===>|Core 0|
> + *     |                 o----+ |  |  | pair 0 |        |      |
> + *     |                 |    | |  |  +--------+        +------+
> + *     +-----------------+    | |  |
> + *            ^               | |  |  +--------+
> + *            |               | |  |  |        |        +------+
> + *            |               | +--+--o queue  |<======>|Core 1|
> + *        Rule|Database       |    |  | pair 1 |        |      |
> + *     +------+----------+    |    |  +--------+        +------+
> + *     |     Group 0     |    |    |
> + *     | +-------------+ |    |    |  +--------+        +------+
> + *     | | Rules 0..n  | |    |    |  |        |        |Core 2|
> + *     | +-------------+ |    |    +--o queue  |<======>|      |
> + *     |     Group 1     |    |       | pair 2 |        +------+
> + *     | +-------------+ |    |       +--------+
> + *     | | Rules 0..n  | |    |
> + *     | +-------------+ |    |       +--------+
> + *     |     Group 2     |    |       |        |        +------+
> + *     | +-------------+ |    |       | queue  |<======>|Core n|
> + *     | | Rules 0..n  | |    +-------o pair n |        |      |
> + *     | +-------------+ |            +--------+        +------+
> + *     |     Group n     |
> + *     | +-------------+ |<-------rte_regexdev_rule_db_update()
> + *     | |             | |<-------rte_regexdev_rule_db_compile_activate()
> + *     | | Rules 0..n  | |<-------rte_regexdev_rule_db_import()
> + *     | +-------------+ |------->rte_regexdev_rule_db_export()
> + *     +-----------------+
> + *
> + * RegEx: A regular expression is a concise and flexible means for matching
> + * strings of text, such as particular characters, words, or patterns of
> + * characters. A common abbreviation for this is “RegEx”.
> + *
> + * RegEx device: A hardware or software-based implementation of RegEx
> + * device API for PCRE based pattern matching syntax and semantics.
> + *
> + * PCRE RegEx syntax and semantics specification:
> + *
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fregexkit.so
> urceforge.net%2FDocumentation%2Fpcre%2Fpcrepattern.html&amp;data=02%
> 7C01%7Corika%40mellanox.com%7C39f5765e405c46b18ba308d7f26b8480%7C
> a652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C637244415961144968&a
> mp;sdata=NWYja3g5nTerSe8vIFSHpTeK8ipKOhMnXmmNBuJtWqY%3D&amp;res
> erved=0
> + *
> + * RegEx queue pair: Each RegEx device should have one or more queue pair
> to
> + * transmit a burst of pattern matching request and receive a burst of
> + * receive the pattern matching response. The pattern matching
> request/response
> + * embedded in *rte_regex_ops* structure.
> + *
> + * Rule: A pattern matching rule expressed in PCRE RegEx syntax along with
> + * Match ID and Group ID to identify the rule upon the match.
> + *
> + * Rule database: The RegEx device accepts regular expressions and converts
> them
> + * into a compiled rule database that can then be used to scan data.
> + * Compilation allows the device to analyze the given pattern(s) and
> + * pre-determine how to scan for these patterns in an optimized fashion that
> + * would be far too expensive to compute at run-time. A rule database
> contains
> + * a set of rules that compiled in device specific binary form.
> + *
> + * Match ID or Rule ID: A unique identifier provided at the time of rule
> + * creation for the application to identify the rule upon match.
> + *
> + * Group ID: Group of rules can be grouped under one group ID to enable
> + * rule isolation and effective pattern matching. A unique group identifier
> + * provided at the time of rule creation for the application to identify the
> + * rule upon match.
> + *
> + * Scan: A pattern matching request through *enqueue* API.
> + *
> + * It may possible that a given RegEx device may not support all the features
> + * of PCRE. The application may probe unsupported features through
> + * struct rte_regexdev_info::pcre_unsup_flags
> + *
> + * By default, all the functions of the RegEx Device API exported by a PMD
> + * are lock-free functions which assume to not be invoked in parallel on
> + * different logical cores to work on the same target object. For instance,
> + * the dequeue function of a PMD cannot be invoked in parallel on two logical
> + * cores to operates on same RegEx queue pair. Of course, this function
> + * can be invoked in parallel by different logical core on different queue pair.
> + * It is the responsibility of the upper level application to enforce this rule.
> + *
> + * In all functions of the RegEx API, the RegEx device is
> + * designated by an integer >= 0 named the device identifier *dev_id*
> + *
> + * At the RegEx driver level, RegEx devices are represented by a generic
> + * data structure of type *rte_regexdev*.
> + *
> + * RegEx devices are dynamically registered during the PCI/SoC device
> probing
> + * phase performed at EAL initialization time.
> + * When a RegEx device is being probed, a *rte_regexdev* structure and
> + * a new device identifier are allocated for that device. Then, the
> + * regexdev_init() function supplied by the RegEx driver matching the probed
> + * device is invoked to properly initialize the device.
> + *
> + * The role of the device init function consists of resetting the hardware or
> + * software RegEx driver implementations.
> + *
> + * If the device init operation is successful, the correspondence between
> + * the device identifier assigned to the new device and its associated
> + * *rte_regexdev* structure is effectively registered.
> + * Otherwise, both the *rte_regexdev* structure and the device identifier are
> + * freed.
> + *
> + * The functions exported by the application RegEx API to setup a device
> + * designated by its device identifier must be invoked in the following order:
> + *     - rte_regexdev_configure()
> + *     - rte_regexdev_queue_pair_setup()
> + *     - rte_regexdev_start()
> + *
> + * Then, the application can invoke, in any order, the functions
> + * exported by the RegEx API to enqueue pattern matching job, dequeue
> pattern
> + * matching response, get the stats, update the rule database,
> + * get/set device attributes and so on
> + *
> + * If the application wants to change the configuration (i.e. call
> + * rte_regexdev_configure() or rte_regexdev_queue_pair_setup()), it must
> call
> + * rte_regexdev_stop() first to stop the device and then do the reconfiguration
> + * before calling rte_regexdev_start() again. The enqueue and dequeue
> + * functions should not be invoked when the device is stopped.
> + *
> + * Finally, an application can close a RegEx device by invoking the
> + * rte_regexdev_close() function.
> + *
> + * Each function of the application RegEx API invokes a specific function
> + * of the PMD that controls the target device designated by its device
> + * identifier.
> + *
> + * For this purpose, all device-specific functions of a RegEx driver are
> + * supplied through a set of pointers contained in a generic structure of type
> + * *regexdev_ops*.
> + * The address of the *regexdev_ops* structure is stored in the
> *rte_regexdev*
> + * structure by the device init function of the RegEx driver, which is
> + * invoked during the PCI/SoC device probing phase, as explained earlier.
> + *
> + * In other words, each function of the RegEx API simply retrieves the
> + * *rte_regexdev* structure associated with the device identifier and
> + * performs an indirect invocation of the corresponding driver function
> + * supplied in the *regexdev_ops* structure of the *rte_regexdev* structure.
> + *
> + * For performance reasons, the address of the fast-path functions of the
> + * RegEx driver is not contained in the *regexdev_ops* structure.
> + * Instead, they are directly stored at the beginning of the *rte_regexdev*
> + * structure to avoid an extra indirect memory access during their invocation.
> + *
> + * RTE RegEx device drivers do not use interrupts for enqueue or dequeue
> + * operation. Instead, RegEx drivers export Poll-Mode enqueue and dequeue
> + * functions to applications.
> + *
> + * The *enqueue* operation submits a burst of RegEx pattern matching
> request
> + * to the RegEx device and the *dequeue* operation gets a burst of pattern
> + * matching response for the ones submitted through *enqueue* operation.
> + *
> + * Typical application utilisation of the RegEx device API will follow the
> + * following programming flow.
> + *
> + * - rte_regexdev_configure()
> + * - rte_regexdev_queue_pair_setup()
> + * - rte_regexdev_rule_db_update() Needs to invoke if precompiled rule
> database
> + *   not provided in rte_regexdev_config::rule_db for
> rte_regexdev_configure()
> + *   and/or application needs to update rule database.
> + * - rte_regexdev_rule_db_compile_activate() Needs to invoke if
> + *   rte_regexdev_rule_db_update function was used.
> + * - Create or reuse exiting mempool for *rte_regex_ops* objects.
> + * - rte_regexdev_start()
> + * - rte_regexdev_enqueue_burst()
> + * - rte_regexdev_dequeue_burst()
> + *
> + */
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +#include <rte_common.h>
> +#include <rte_config.h>
> +#include <rte_dev.h>
> +#include <rte_errno.h>
> +#include <rte_mbuf.h>
> +#include <rte_memory.h>
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Get the total number of RegEx devices that have been successfully
> + * initialised.
> + *
> + * @return
> + *   The total number of usable RegEx devices.
> + */
> +__rte_experimental
> +uint8_t
> +rte_regexdev_count(void);
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Get the device identifier for the named RegEx device.
> + *
> + * @param name
> + *   RegEx device name to select the RegEx device identifier.
> + *
> + * @return
> + *   Returns RegEx device identifier on success.
> + *   - <0: Failure to find named RegEx device.
> + */
> +__rte_experimental
> +int
> +rte_regexdev_get_dev_id(const char *name);
> +
> +/* Enumerates RegEx device capabilities */
> +#define RTE_REGEXDEV_CAPA_RUNTIME_COMPILATION_F (1ULL << 0)
> +/**< RegEx device does support compiling the rules at runtime unlike
> + * loading only the pre-built rule database using
> + * struct rte_regexdev_config::rule_db in rte_regexdev_configure()
> + *
> + * @see struct rte_regexdev_config::rule_db, rte_regexdev_configure()
> + * @see struct rte_regexdev_info::regexdev_capa
> + */
> +
> +#define RTE_REGEXDEV_CAPA_SUPP_PCRE_START_ANCHOR_F (1ULL << 1)
> +/**< RegEx device support PCRE Anchor to start of match flag.
> + * Example RegEx is '/\Gfoo\d/'. Here '\G' asserts position at the end of the
> + * previous match or the start of the string for the first match.
> + * This position will change each time the RegEx is applied to the subject
> + * string. If the RegEx is applied to 'foo1foo2Zfoo3' the first two matches will
> + * be successful for 'foo1foo2' and fail for 'Zfoo3'.
> + *
> + * @see struct rte_regexdev_info::regexdev_capa
> + */
> +
> +#define RTE_REGEXDEV_CAPA_SUPP_PCRE_ATOMIC_GROUPING_F (1ULL <<
> 2)
> +/**< RegEx device support PCRE Atomic grouping.
> + * Atomic groups are represented by '(?>)'. An atomic group is a group that,
> + * when the RegEx engine exits from it, automatically throws away all
> + * backtracking positions remembered by any tokens inside the group.
> + * Example RegEx is 'a(?>bc|b)c' if the given patterns are 'abc' and 'abcc' then
> + * 'a(bc|b)c' matches both where as 'a(?>bc|b)c' matches only abcc because
> + * atomic groups don't allow backtracing back to 'b'.
> + *
> + * @see struct rte_regexdev_info::regexdev_capa
> + */
> +
> +#define RTE_REGEXDEV_SUPP_PCRE_BACKTRACKING_CTRL_F (1ULL << 3)
> +/**< RegEx device support PCRE backtracking control verbs.
> + * Some examples of backtracing verbs are (*COMMIT), (*ACCEPT), (*FAIL),
> + * (*SKIP), (*PRUNE).
> + *
> + * @see struct rte_regexdev_info::regexdev_capa
> + */
> +
> +#define RTE_REGEXDEV_SUPP_PCRE_CALLOUTS_F (1ULL << 4)
> +/**< RegEx device support PCRE callouts.
> + * PCRE supports calling external function in between matches by using '(?C)'.
> + * Example RegEx 'ABC(?C)D' if a given patter is 'ABCD' then the RegEx
> engine
> + * will parse ABC perform a userdefined callout and return a successful match
> at
> + * D.
> + *
> + * @see struct rte_regexdev_info::regexdev_capa
> + */
> +
> +#define RTE_REGEXDEV_SUPP_PCRE_BACKREFERENCE_F (1ULL << 5)
> +/**< RegEx device support PCRE backreference.
> + * Example RegEx is '(\2ABC|(GHI))+' \2 matches the same text as most
> recently
> + * matched by the 2nd capturing group i.e. 'GHI'.
> + *
> + * @see struct rte_regexdev_info::regexdev_capa
> + */
> +
> +#define RTE_REGEXDEV_SUPP_PCRE_GREEDY_F (1ULL << 6)
> +/**< RegEx device support PCRE Greedy mode.
> + * For example if the RegEx is 'AB\d*?' then '*?' represents zero or unlimited
> + * matches. In greedy mode the pattern 'AB12345' will be matched
> completely
> + * where as the ungreedy mode 'AB' will be returned as the match.
> + *
> + * @see struct rte_regexdev_info::regexdev_capa
> + */
> +
> +#define RTE_REGEXDEV_SUPP_PCRE_MATCH_ALL_F (1ULL << 7)
> +/**< RegEx device support match all mode.
> + * For example if the RegEx is 'AB\d*?' then '*?' represents zero or unlimited
> + * matches. In match all mode the pattern 'AB12345' will return 6 matches.
> + * AB, AB1, AB12, AB123, AB1234, AB12345.
> + *
> + * @see struct rte_regexdev_info::regexdev_capa
> + */
> +
> +#define RTE_REGEXDEV_SUPP_PCRE_LOOKAROUND_ASRT_F (1ULL << 8)
> +/**< RegEx device support PCRE Lookaround assertions
> + * (Zero-width assertions). Example RegEx is '[a-z]+\d+(?=!{3,})' if
> + * the given pattern is 'dwad1234!' the RegEx engine doesn't report any
> matches
> + * because the assert '(?=!{3,})' fails. The pattern 'dwad123!!!' would return a
> + * successful match.
> + *
> + * @see struct rte_regexdev_info::regexdev_capa
> + */
> +
> +#define RTE_REGEXDEV_SUPP_PCRE_MATCH_POINT_RST_F (1ULL << 9)
> +/**< RegEx device doesn't support PCRE match point reset directive.
> + * Example RegEx is '[a-z]+\K\d+' if the pattern is 'dwad123'
> + * then even though the entire pattern matches only '123'
> + * is reported as a match.
> + *
> + * @see struct rte_regexdev_info::regexdev_capa
> + */
> +
> +#define RTE_REGEXDEV_SUPP_NEWLINE_CONVENTIONS_F (1ULL << 10)
> +/**< RegEx support PCRE newline convention.
> + * Newline conventions are represented as follows:
> + * (*CR)        carriage return
> + * (*LF)        linefeed
> + * (*CRLF)      carriage return, followed by linefeed
> + * (*ANYCRLF)   any of the three above
> + * (*ANY)       all Unicode newline sequences
> + *
> + * @see struct rte_regexdev_info::regexdev_capa
> + */
> +
> +#define RTE_REGEXDEV_SUPP_PCRE_NEWLINE_SEQ_F (1ULL << 11)
> +/**< RegEx device support PCRE newline sequence.
> + * The escape sequence '\R' will match any newline sequence.
> + * It is equivalent to: '(?>\r\n|\n|\x0b|\f|\r|\x85)'.
> + *
> + * @see struct rte_regexdev_info::regexdev_capa
> + */
> +
> +#define RTE_REGEXDEV_SUPP_PCRE_POSSESSIVE_QUALIFIERS_F (1ULL << 12)
> +/**< RegEx device support PCRE possessive qualifiers.
> + * Example RegEx possessive qualifiers '*+', '++', '?+', '{m,n}+'.
> + * Possessive quantifier repeats the token as many times as possible and it
> does
> + * not give up matches as the engine backtracks. With a possessive quantifier,
> + * the deal is all or nothing.
> + *
> + * @see struct rte_regexdev_info::regexdev_capa
> + */
> +
> +#define RTE_REGEXDEV_SUPP_PCRE_SUBROUTINE_REFERENCES_F (1ULL <<
> 13)
> +/**< RegEx device support PCRE Subroutine references.
> + * PCRE Subroutine references allow for sub patterns to be assessed
> + * as part of the RegEx. Example RegEx is '(foo|fuzz)\g<1>+bar' matches the
> + * pattern 'foofoofuzzfoofuzzbar'.
> + *
> + * @see struct rte_regexdev_info::regexdev_capa
> + */
> +
> +#define RTE_REGEXDEV_SUPP_PCRE_UTF_8_F (1ULL << 14)
> +/**< RegEx device support UTF-8 character encoding.
> + *
> + * @see struct rte_regexdev_info::pcre_unsup_flags
> + */
> +
> +#define RTE_REGEXDEV_SUPP_PCRE_UTF_16_F (1ULL << 15)
> +/**< RegEx device support UTF-16 character encoding.
> + *
> + * @see struct rte_regexdev_info::regexdev_capa
> + */
> +
> +#define RTE_REGEXDEV_SUPP_PCRE_UTF_32_F (1ULL << 16)
> +/**< RegEx device support UTF-32 character encoding.
> + *
> + * @see struct rte_regexdev_info::regexdev_capa
> + */
> +
> +#define RTE_REGEXDEV_SUPP_PCRE_WORD_BOUNDARY_F (1ULL << 17)
> +/**< RegEx device support word boundaries.
> + * The meta character '\b' represents word boundary anchor.
> + *
> + * @see struct rte_regexdev_info::regexdev_capa
> + */
> +
> +#define RTE_REGEXDEV_SUPP_PCRE_FORWARD_REFERENCES_F (1ULL << 18)
> +/**< RegEx device support Forward references.
> + * Forward references allow you to use a back reference to a group that
> appears
> + * later in the RegEx. Example RegEx is '(\3ABC|(DEF|(GHI)))+' matches the
> + * following string 'GHIGHIABCDEF'.
> + *
> + * @see struct rte_regexdev_info::regexdev_capa
> + */
> +
> +#define RTE_REGEXDEV_SUPP_MATCH_AS_END_F (1ULL << 19)
> +/**< RegEx device support match as end.
> + * Match as end means that the match result holds the end offset of the
> + * detected match. No len value is set.
> + * If the device doesn't support this feature it means the match
> + * result holds the starting position of match and the length of the match.
> + *
> + * @see struct rte_regexdev_info::regexdev_capa
> + */
> +
> +#define RTE_REGEXDEV_SUPP_CROSS_BUFFER_F (1ULL << 20)
> +/**< RegEx device support cross buffer match.
> + * Cross buffer matching means that the match can be detected even if the
> + * string was started in previous buffer.
> + * In case the device is configured as RTE_REGEXDEV_CFG_MATCH_AS_END
> + * the end offset will be relative for the first packet.
> + * For example RegEx is ABC the first buffer is xxxx second buffer yyyA and
> + * the last buffer BCzz.
> + * In case the match as end is configured the end offset will be 10.
> + *
> + * @see RTE_REGEXDEV_CFG_MATCH_AS_END_F
> + * @see RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F
> + * @see RTE_REGEX_OPS_RSP_PMI_SOJ_F
> + * @see RTE_REGEX_OPS_RSP_PMI_EOJ_F
> + */
> +
> +#define RTE_REGEXDEV_SUPP_MATCH_ALL_F (1ULL << 21)
> +/**< RegEx device support match all.
> + * Match all means that the RegEx engine will return all possible matches.
> + * For example, assume the RegEx is 'A+b', given the input AAAb the
> + * returned matches will be: Ab, AAb and AAAb.
> + *
> + * @see RTE_REGEXDEV_CFG_MATCH_ALL_F
> + */
> +
> +/* Enumerates PCRE rule flags */
> +#define RTE_REGEX_PCRE_RULE_ALLOW_EMPTY_F (1ULL << 0)
> +/**< When this flag is set, the pattern that can match against an empty string,
> + * such as '.*' are allowed.
> + *
> + * @see struct rte_regexdev_info::rule_flags
> + * @see struct rte_regexdev_rule::rule_flags
> + */
> +
> +#define RTE_REGEX_PCRE_RULE_ANCHORED_F (1ULL << 1)
> +/**< When this flag is set, the pattern is forced to be "anchored", that is, it
> + * is constrained to match only at the first matching point in the string that
> + * is being searched. Similar to '^' and represented by \A.
> + *
> + * @see struct rte_regexdev_info::rule_flags
> + * @see struct rte_regexdev_rule::rule_flags
> + */
> +
> +#define RTE_REGEX_PCRE_RULE_CASELESS_F (1ULL << 2)
> +/**< When this flag is set, letters in the pattern match both upper and lower
> + * case letters in the subject.
> + *
> + * @see struct rte_regexdev_info::rule_flags
> + * @see struct rte_regexdev_rule::rule_flags
> + */
> +
> +#define RTE_REGEX_PCRE_RULE_DOTALL_F (1ULL << 3)
> +/**< When this flag is set, a dot metacharacter in the pattern matches any
> + * character, including one that indicates a newline.
> + *
> + * @see struct rte_regexdev_info::rule_flags
> + * @see struct rte_regexdev_rule::rule_flags
> + */
> +
> +#define RTE_REGEX_PCRE_RULE_DUPNAMES_F (1ULL << 4)
> +/**< When this flag is set, names used to identify capture groups need not be
> + * unique.
> + *
> + * @see struct rte_regexdev_info::rule_flags
> + * @see struct rte_regexdev_rule::rule_flags
> + */
> +
> +#define RTE_REGEX_PCRE_RULE_EXTENDED_F (1ULL << 5)
> +/**< When this flag is set, most white space characters in the pattern are
> + * totally ignored except when escaped or inside a character class.
> + *
> + * @see struct rte_regexdev_info::rule_flags
> + * @see struct rte_regexdev_rule::rule_flags
> + */
> +
> +#define RTE_REGEX_PCRE_RULE_MATCH_UNSET_BACKREF_F (1ULL << 6)
> +/**< When this flag is set, a backreference to an unset capture group matches
> an
> + * empty string.
> + *
> + * @see struct rte_regexdev_info::rule_flags
> + * @see struct rte_regexdev_rule::rule_flags
> + */
> +
> +#define RTE_REGEX_PCRE_RULE_MULTILINE_F (1ULL << 7)
> +/**< When this flag  is set, the '^' and '$' constructs match immediately
> + * following or immediately before internal newlines in the subject string,
> + * respectively, as well as at the very start and end.
> + *
> + * @see struct rte_regexdev_info::rule_flags
> + * @see struct rte_regexdev_rule::rule_flags
> + */
> +
> +#define RTE_REGEX_PCRE_RULE_NO_AUTO_CAPTURE_F (1ULL << 8)
> +/**< When this Flag is set, it disables the use of numbered capturing
> + * parentheses in the pattern. References to capture groups (backreferences
> or
> + * recursion/subroutine calls) may only refer to named groups, though the
> + * reference can be by name or by number.
> + *
> + * @see struct rte_regexdev_info::rule_flags
> + * @see struct rte_regexdev_rule::rule_flags
> + */
> +
> +#define RTE_REGEX_PCRE_RULE_UCP_F (1ULL << 9)
> +/**< By default, only ASCII characters are recognized, When this flag is set,
> + * Unicode properties are used instead to classify characters.
> + *
> + * @see struct rte_regexdev_info::rule_flags
> + * @see struct rte_regexdev_rule::rule_flags
> + */
> +
> +#define RTE_REGEX_PCRE_RULE_UNGREEDY_F (1ULL << 10)
> +/**< When this flag is set, the "greediness" of the quantifiers is inverted
> + * so that they are not greedy by default, but become greedy if followed by
> + * '?'.
> + *
> + * @see struct rte_regexdev_info::rule_flags
> + * @see struct rte_regexdev_rule::rule_flags
> + */
> +
> +#define RTE_REGEX_PCRE_RULE_UTF_F (1ULL << 11)
> +/**< When this flag is set, RegEx engine has to regard both the pattern and
> the
> + * subject strings that are subsequently processed as strings of UTF characters
> + * instead of single-code-unit strings.
> + *
> + * @see struct rte_regexdev_info::rule_flags
> + * @see struct rte_regexdev_rule::rule_flags
> + */
> +
> +#define RTE_REGEX_PCRE_RULE_NEVER_BACKSLASH_C_F (1ULL << 12)
> +/**< This flag locks out the use of '\C' in the pattern that is being compiled.
> + * This escape matches one data unit, even in UTF mode which can cause
> + * unpredictable behavior in UTF-8 or UTF-16 modes, because it may leave the
> + * current matching point in the mi:set hlsearchddle of a multi-code-unit
> + * character.
> + *
> + * @see struct rte_regexdev_info::rule_flags
> + * @see struct rte_regexdev_rule::rule_flags
> + */
> +
> +/**
> + * RegEx device information
> + */
> +struct rte_regexdev_info {
> +	const char *driver_name; /**< RegEx driver name. */
> +	struct rte_device *dev;	/**< Device information. */
> +	uint16_t max_matches;
> +	/**< Maximum matches per scan supported by this device. */
> +	uint16_t max_queue_pairs;
> +	/**< Maximum queue pairs supported by this device. */
> +	uint16_t max_payload_size;
> +	/**< Maximum payload size for a pattern match request or scan.
> +	 * @see RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F
> +	 */
> +	uint32_t max_rules_per_group;
> +	/**< Maximum rules supported per group by this device. */
> +	uint16_t max_groups;
> +	/**< Maximum groups supported by this device. */
> +	uint32_t regexdev_capa;
> +	/**< RegEx device capabilities. @see RTE_REGEXDEV_CAPA_* */
> +	uint64_t rule_flags;
> +	/**< Supported compiler rule flags.
> +	 * @see RTE_REGEX_PCRE_RULE_*, struct
> rte_regexdev_rule::rule_flags
> +	 */
> +};
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Retrieve the contextual information of a RegEx device.
> + *
> + * @param dev_id
> + *   The identifier of the device.
> + *
> + * @param[out] dev_info
> + *   A pointer to a structure of type *rte_regexdev_info* to be filled with the
> + *   contextual information of the device.
> + *
> + * @return
> + *   - 0: Success, driver updates the contextual information of the RegEx device
> + *   - <0: Error code returned by the driver info get function.
> + */
> +__rte_experimental
> +int
> +rte_regexdev_info_get(uint8_t dev_id, struct rte_regexdev_info *dev_info);
> +
> +/* Enumerates RegEx device configuration flags */
> +#define RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F (1ULL << 0)
> +/**< Cross buffer scan refers to the ability to be able to detect
> + * matches that occur across buffer boundaries, where the buffers are related
> + * to each other in some way. Enable this flag when to scan payload size
> + * greater than struct rte_regexdev_info::max_payload_size and/or
> + * matches can present across scan buffer boundaries.
> + *
> + * @see struct rte_regexdev_info::max_payload_size
> + * @see struct rte_regexdev_config::dev_cfg_flags, rte_regexdev_configure()
> + * @see RTE_REGEX_OPS_RSP_PMI_SOJ_F
> + * @see RTE_REGEX_OPS_RSP_PMI_EOJ_F
> + */
> +
> +#define RTE_REGEXDEV_CFG_MATCH_AS_END_F (1ULL << 1)
> +/**< Match as end is the ability to return the result as ending offset.
> + * When this flag is set, the result for each match will hold the ending
> + * offset of the match in end_offset.
> + * If this flag is not set, then the match result will hold the starting offset
> + * in start_offset, and the length of the match in len.
> + *
> + * @see RTE_REGEXDEV_SUPP_MATCH_AS_END_F
> + */
> +
> +#define RTE_REGEXDEV_CFG_MATCH_ALL_F (1ULL << 2)
> +/**< Match all is the ability to return all possible results.
> + *
> + * @see RTE_REGEXDEV_SUPP_MATCH_ALL_F
> + */
> +
> +/** RegEx device configuration structure */
> +struct rte_regexdev_config {
> +	uint16_t nb_max_matches;
> +	/**< Maximum matches per scan configured on this device.
> +	 * This value cannot exceed the *max_matches*
> +	 * which previously provided in rte_regexdev_info_get().
> +	 * The value 0 is allowed, in which case, value 1 used.
> +	 * @see struct rte_regexdev_info::max_matches
> +	 */
> +	uint16_t nb_queue_pairs;
> +	/**< Number of RegEx queue pairs to configure on this device.
> +	 * This value cannot exceed the *max_queue_pairs* which previously
> +	 * provided in rte_regexdev_info_get().
> +	 * @see struct rte_regexdev_info::max_queue_pairs
> +	 */
> +	uint32_t nb_rules_per_group;
> +	/**< Number of rules per group to configure on this device.
> +	 * This value cannot exceed the *max_rules_per_group*
> +	 * which previously provided in rte_regexdev_info_get().
> +	 * The value 0 is allowed, in which case,
> +	 * struct rte_regexdev_info::max_rules_per_group used.
> +	 * @see struct rte_regexdev_info::max_rules_per_group
> +	 */
> +	uint16_t nb_groups;
> +	/**< Number of groups to configure on this device.
> +	 * This value cannot exceed the *max_groups*
> +	 * which previously provided in rte_regexdev_info_get().
> +	 * @see struct rte_regexdev_info::max_groups
> +	 */
> +	const char *rule_db;
> +	/**< Import initial set of prebuilt rule database on this device.
> +	 * The value NULL is allowed, in which case, the device will not
> +	 * be configured prebuilt rule database. Application may use
> +	 * rte_regexdev_rule_db_update() or rte_regexdev_rule_db_import()
> API
> +	 * to update or import rule database after the
> +	 * rte_regexdev_configure().
> +	 * @see rte_regexdev_rule_db_update(),
> rte_regexdev_rule_db_import()
> +	 */
> +	uint32_t rule_db_len;
> +	/**< Length of *rule_db* buffer. */
> +	uint32_t dev_cfg_flags;
> +	/**< RegEx device configuration flags, See RTE_REGEXDEV_CFG_*  */
> +};
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Configure a RegEx device.
> + *
> + * This function must be invoked first before any other function in the
> + * API. This function can also be re-invoked when a device is in the
> + * stopped state.
> + *
> + * The caller may use rte_regexdev_info_get() to get the capability of each
> + * resources available for this regex device.
> + *
> + * @param dev_id
> + *   The identifier of the device to configure.
> + * @param cfg
> + *   The RegEx device configuration structure.
> + *
> + * @return
> + *   - 0: Success, device configured. Otherwise negative errno is returned.
> + */
> +__rte_experimental
> +int
> +rte_regexdev_configure(uint8_t dev_id, const struct rte_regexdev_config
> *cfg);
> +
> +/* Enumerates RegEx queue pair configuration flags */
> +#define RTE_REGEX_QUEUE_PAIR_CFG_OOS_F (1ULL << 0)
> +/**< Out of order scan, If not set, a scan must retire after previously issued
> + * in-order scans to this queue pair. If set, this scan can be retired as soon
> + * as device returns completion. Application should not set out of order scan
> + * flag if it needs to maintain the ingress order of scan request.
> + *
> + * @see struct rte_regexdev_qp_conf::qp_conf_flags
> + * @see rte_regexdev_queue_pair_setup()
> + */
> +
> +struct rte_regex_ops;
> +typedef void (*regexdev_stop_flush_t)(uint8_t dev_id, uint16_t qp_id,
> +				      struct rte_regex_ops *op);
> +/**< Callback function called during rte_regexdev_stop(), invoked once per
> + * flushed RegEx op.
> + */
> +
> +/** RegEx queue pair configuration structure */
> +struct rte_regexdev_qp_conf {
> +	uint32_t qp_conf_flags;
> +	/**< Queue pair config flags, See RTE_REGEX_QUEUE_PAIR_CFG_* */
> +	uint16_t nb_desc;
> +	/**< The number of descriptors to allocate for this queue pair. */
> +	regexdev_stop_flush_t cb;
> +	/**< Callback function called during rte_regexdev_stop(), invoked
> +	 * once per flushed regex op. Value NULL is allowed, in which case
> +	 * callback will not be invoked. This function can be used to properly
> +	 * dispose of outstanding regex ops from response queue,
> +	 * for example ops containing memory pointers.
> +	 * @see rte_regexdev_stop()
> +	 */
> +};
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Allocate and set up a RegEx queue pair for a RegEx device.
> + *
> + * @param dev_id
> + *   The identifier of the device.
> + * @param queue_pair_id
> + *   The index of the RegEx queue pair to setup. The value must be in the
> range
> + *   [0, nb_queue_pairs - 1] previously supplied to rte_regexdev_configure().
> + * @param qp_conf
> + *   The pointer to the configuration data to be used for the RegEx queue pair.
> + *   NULL value is allowed, in which case default configuration	used.
> + *
> + * @return
> + *   0 on success. Otherwise negative errno is returned.
> + */
> +__rte_experimental
> +int
> +rte_regexdev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
> +			      const struct rte_regexdev_qp_conf *qp_conf);
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Start a RegEx device.
> + *
> + * The device start step is the last one and consists of setting the RegEx
> + * queues to start accepting the pattern matching scan requests.
> + *
> + * On success, all basic functions exported by the API (RegEx enqueue,
> + * RegEx dequeue and so on) can be invoked.
> + *
> + * @param dev_id
> + *   RegEx device identifier.
> + *
> + * @return
> + *   0 on success. Otherwise negative errno is returned.
> + */
> +__rte_experimental
> +int
> +rte_regexdev_start(uint8_t dev_id);
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Stop a RegEx device.
> + *
> + * Stop a RegEx device. The device can be restarted with a call to
> + * rte_regexdev_start().
> + *
> + * This function causes all queued response regex ops to be drained in the
> + * response queue. While draining ops out of the device,
> + * struct rte_regexdev_qp_conf::cb will be invoked for each ops.
> + *
> + * @param dev_id
> + *   RegEx device identifier.
> + *
> + * @see struct rte_regexdev_qp_conf::cb, rte_regexdev_queue_pair_setup()
> + */
> +__rte_experimental
> +void
> +rte_regexdev_stop(uint8_t dev_id);
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Close a RegEx device. The device cannot be restarted!
> + *
> + * @param dev_id
> + *   RegEx device identifier
> + *
> + * @return
> + *   0 on success. Otherwise negative errno is returned.
> + */
> +__rte_experimental
> +int
> +rte_regexdev_close(uint8_t dev_id);
> +
> +/* Device get/set attributes */
> +
> +/** Enumerates RegEx device attribute identifier */
> +enum rte_regexdev_attr_id {
> +	RTE_REGEXDEV_ATTR_SOCKET_ID,
> +	/**< The NUMA socket id to which the device is connected or
> +	 * a default of zero if the socket could not be determined.
> +	 * datatype: *int*
> +	 * operation: *get*
> +	 */
> +	RTE_REGEXDEV_ATTR_MAX_MATCHES,
> +	/**< Maximum number of matches per scan.
> +	 * datatype: *uint8_t*
> +	 * operation: *get* and *set*
> +	 * @see RTE_REGEX_OPS_RSP_MAX_MATCH_F
> +	 */
> +	RTE_REGEXDEV_ATTR_MAX_SCAN_TIMEOUT,
> +	/**< Upper bound scan time in ns.
> +	 * datatype: *uint16_t*
> +	 * operation: *get* and *set*
> +	 * @see RTE_REGEX_OPS_RSP_MAX_SCAN_TIMEOUT_F
> +	 */
> +	RTE_REGEXDEV_ATTR_MAX_PREFIX,
> +	/**< Maximum number of prefix detected per scan.
> +	 * This would be useful for denial of service detection.
> +	 * datatype: *uint16_t*
> +	 * operation: *get* and *set*
> +	 * @see RTE_REGEX_OPS_RSP_MAX_PREFIX_F
> +	 */
> +};
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Get an attribute from a RegEx device.
> + *
> + * @param dev_id
> + *   RegEx device identifier.
> + * @param attr_id
> + *   The attribute ID to retrieve.
> + * @param attr_value
> + *   A pointer that will be filled in with the attribute
> + *   value if successful.
> + *
> + * @return
> + *   - 0: Successfully retrieved attribute value.
> + *   - -EINVAL: Invalid device or  *attr_id* provided, or *attr_value* is NULL.
> + *   - -ENOTSUP: if the device doesn't support specific *attr_id*.
> + */
> +__rte_experimental
> +int
> +rte_regexdev_attr_get(uint8_t dev_id, enum rte_regexdev_attr_id attr_id,
> +		      void *attr_value);
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Set an attribute to a RegEx device.
> + *
> + * @param dev_id
> + *   RegEx device identifier.
> + * @param attr_id
> + *   The attribute ID to retrieve.
> + * @param attr_value
> + *   Pointer that will be filled in with the attribute value
> + *   by the application.
> + *
> + * @return
> + *   - 0: Successfully applied the attribute value.
> + *   - -EINVAL: Invalid device or  *attr_id* provided, or *attr_value* is NULL.
> + *   - -ENOTSUP: if the device doesn't support specific *attr_id*.
> + */
> +__rte_experimental
> +int
> +rte_regexdev_attr_set(uint8_t dev_id, enum rte_regexdev_attr_id attr_id,
> +		      const void *attr_value);
> +
> +/* Rule related APIs */
> +/** Enumerates RegEx rule operation. */
> +enum rte_regexdev_rule_op {
> +	RTE_REGEX_RULE_OP_ADD,
> +	/**< Add RegEx rule to rule database. */
> +	RTE_REGEX_RULE_OP_REMOVE
> +	/**< Remove RegEx rule from rule database. */
> +};
> +
> +/** Structure to hold a RegEx rule attributes. */
> +struct rte_regexdev_rule {
> +	enum rte_regexdev_rule_op op;
> +	/**< OP type of the rule either a OP_ADD or OP_DELETE. */
> +	uint16_t group_id;
> +	/**< Group identifier to which the rule belongs to. */
> +	uint32_t rule_id;
> +	/**< Rule identifier which is returned on successful match. */
> +	const char *pcre_rule;
> +	/**< Buffer to hold the PCRE rule. */
> +	uint16_t pcre_rule_len;
> +	/**< Length of the PCRE rule. */
> +	uint64_t rule_flags;
> +	/* PCRE rule flags. Supported device specific PCRE rules enumerated
> +	 * in struct rte_regexdev_info::rule_flags. For successful rule
> +	 * database update, application needs to provide only supported
> +	 * rule flags.
> +	 * @See RTE_REGEX_PCRE_RULE_*, struct
> rte_regexdev_info::rule_flags
> +	 */
> +};
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Update the local rule set.
> + * This functions only modify the rule set in memory.
> + * In order for the changes to take effect, the function
> + * rte_regexdev_rule_db_compile_active must be called.
> + *
> + * @param dev_id
> + *   RegEx device identifier.
> + * @param rules
> + *   Points to an array of *nb_rules* objects of type *rte_regexdev_rule*
> + *   structure which contain the regex rules attributes to be updated
> + *   in rule database.
> + * @param nb_rules
> + *   The number of PCRE rules to update the rule database.
> + *
> + * @return
> + *   The number of regex rules actually updated on the regex device's rule
> + *   database. The return value can be less than the value of the *nb_rules*
> + *   parameter when the regex devices fails to update the rule database or
> + *   if invalid parameters are specified in a *rte_regexdev_rule*.
> + *   If the return value is less than *nb_rules*, the remaining PCRE rules
> + *   at the end of *rules* are not consumed and the caller has to take
> + *   care of them and rte_errno is set accordingly.
> + *   Possible errno values include:
> + *   - -EINVAL:  Invalid device ID or rules is NULL
> + *   - -ENOTSUP: The last processed rule is not supported on this device.
> + *   - -ENOSPC: No space available in rule database.
> + *
> + * @see rte_regexdev_rule_db_import(), rte_regexdev_rule_db_export(),
> + *   rte_regexdev_rule_db_compile_activate()
> + */
> +__rte_experimental
> +int
> +rte_regexdev_rule_db_update(uint8_t dev_id,
> +			    const struct rte_regexdev_rule *rules,
> +			    uint32_t nb_rules);
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Compile local rule set and burn the complied result to the
> + * RegEx deive.
> + *
> + * @param dev_id
> + *   RegEx device identifier.
> + *
> + * @return
> + *   0 on success, otherwise negative errno.
> + *
> + * @see rte_regexdev_rule_db_import(), rte_regexdev_rule_db_export(),
> + *   rte_regexdev_rule_db_update()
> + */
> +__rte_experimental
> +int
> +rte_regexdev_rule_db_compile_activate(uint8_t dev_id);
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Import a prebuilt rule database from a buffer to a RegEx device.
> + *
> + * @param dev_id
> + *   RegEx device identifier.
> + * @param rule_db
> + *   Points to prebuilt rule database.
> + * @param rule_db_len
> + *   Length of the rule database.
> + *
> + * @return
> + *   - 0: Successfully updated the prebuilt rule database.
> + *   - -EINVAL:  Invalid device ID or rule_db is NULL
> + *   - -ENOTSUP: Rule database import is not supported on this device.
> + *   - -ENOSPC: No space available in rule database.
> + *
> + * @see rte_regexdev_rule_db_update(), rte_regexdev_rule_db_export()
> + */
> +__rte_experimental
> +int
> +rte_regexdev_rule_db_import(uint8_t dev_id, const char *rule_db,
> +			    uint32_t rule_db_len);
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Export the prebuilt rule database from a RegEx device to the buffer.
> + *
> + * @param dev_id
> + *   RegEx device identifier.
> + * @param[out] rule_db
> + *   Block of memory to insert the rule database. Must be at least size in
> + *   capacity. If set to NULL, function returns required capacity.
> + *
> + * @return
> + *   - 0: Successfully exported the prebuilt rule database.
> + *   - size: If rule_db set to NULL then required capacity for *rule_db*
> + *   - -EINVAL:  Invalid device ID
> + *   - -ENOTSUP: Rule database export is not supported on this device.
> + *
> + * @see rte_regexdev_rule_db_update(), rte_regexdev_rule_db_import()
> + */
> +__rte_experimental
> +int
> +rte_regexdev_rule_db_export(uint8_t dev_id, char *rule_db);
> +
> +/* Extended statistics */
> +/** Maximum name length for extended statistics counters */
> +#define RTE_REGEXDEV_XSTATS_NAME_SIZE 64
> +
> +/**
> + * A name-key lookup element for extended statistics.
> + *
> + * This structure is used to map between names and ID numbers
> + * for extended RegEx device statistics.
> + */
> +struct rte_regexdev_xstats_map {
> +	uint16_t id;
> +	/**< xstat identifier */
> +	char name[RTE_REGEXDEV_XSTATS_NAME_SIZE];
> +	/**< xstat name */
> +};
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Retrieve names of extended statistics of a regex device.
> + *
> + * @param dev_id
> + *   The identifier of the regex device.
> + * @param[out] xstats_map
> + *   Block of memory to insert id and names into. Must be at least size in
> + *   capacity. If set to NULL, function returns required capacity.
> + * @return
> + *   - Positive value on success:
> + *        -The return value is the number of entries filled in the stats map.
> + *        -If xstats_map set to NULL then required capacity for xstats_map.
> + *   - Negative value on error:
> + *      -ENODEV for invalid *dev_id*
> + *      -ENOTSUP if the device doesn't support this function.
> + */
> +__rte_experimental
> +int
> +rte_regexdev_xstats_names_get(uint8_t dev_id,
> +			      struct rte_regexdev_xstats_map *xstats_map);
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Retrieve extended statistics of an regex device.
> + *
> + * @param dev_id
> + *   The identifier of the device.
> + * @param ids
> + *   The id numbers of the stats to get. The ids can be got from the stat
> + *   position in the stat list from rte_regexdev_xstats_names_get(), or
> + *   by using rte_regexdev_xstats_by_name_get().
> + * @param values
> + *   The values for each stats request by ID.
> + * @param nb_values
> + *   The number of stats requested.
> + * @return
> + *   - Positive value: number of stat entries filled into the values array
> + *   - Negative value on error:
> + *      -ENODEV for invalid *dev_id*
> + *      -ENOTSUP if the device doesn't support this function.
> + */
> +__rte_experimental
> +int
> +rte_regexdev_xstats_get(uint8_t dev_id, const uint16_t *ids,
> +			uint64_t *values, uint16_t nb_values);
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Retrieve the value of a single stat by requesting it by name.
> + *
> + * @param dev_id
> + *   The identifier of the device.
> + * @param name
> + *   The stat name to retrieve.
> + * @param id
> + *   If non-NULL, the numerical id of the stat will be returned, so that further
> + *   requests for the stat can be got using rte_regexdev_xstats_get, which will
> + *   be faster as it doesn't need to scan a list of names for the stat.
> + * @param[out] value
> + *   Must be non-NULL, retrieved xstat value will be stored in this address.
> + *
> + * @return
> + *   - 0: Successfully retrieved xstat value.
> + *   - -EINVAL: invalid parameters
> + *   - -ENOTSUP: if not supported.
> + */
> +__rte_experimental
> +int
> +rte_regexdev_xstats_by_name_get(uint8_t dev_id, const char *name,
> +				uint16_t *id, uint64_t *value);
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Reset the values of the xstats of the selected component in the device.
> + *
> + * @param dev_id
> + *   The identifier of the device.
> + * @param ids
> + *   Selects specific statistics to be reset. When NULL, all statistics will be
> + *   reset. If non-NULL, must point to array of at least *nb_ids* size.
> + * @param nb_ids
> + *   The number of ids available from the *ids* array. Ignored when ids is
> NULL.
> + *
> + * @return
> + *   - 0: Successfully reset the statistics to zero.
> + *   - -EINVAL: invalid parameters.
> + *   - -ENOTSUP: if not supported.
> + */
> +__rte_experimental
> +int
> +rte_regexdev_xstats_reset(uint8_t dev_id, const uint16_t *ids,
> +			  uint16_t nb_ids);
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Trigger the RegEx device self test.
> + *
> + * @param dev_id
> + *   The identifier of the device.
> + * @return
> + *   - 0: Selftest successful.
> + *   - -ENOTSUP if the device doesn't support selftest.
> + *   - other values < 0 on failure.
> + */
> +__rte_experimental
> +int
> +rte_regexdev_selftest(uint8_t dev_id);
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Dump internal information about *dev_id* to the FILE* provided in *f*.
> + *
> + * @param dev_id
> + *   The identifier of the device.
> + * @param f
> + *   A pointer to a file for output.
> + *
> + * @return
> + *   0 on success, negative errno on failure.
> + */
> +__rte_experimental
> +int
> +rte_regexdev_dump(uint8_t dev_id, FILE *f);
> +
> +/* Fast path APIs */
> +
> +/**
> + * The generic *rte_regexdev_match* structure to hold the RegEx match
> + * attributes.
> + * @see struct rte_regex_ops::matches
> + */
> +struct rte_regexdev_match {
> +	RTE_STD_C11
> +	union {
> +		uint64_t u64;
> +		struct {
> +			uint32_t rule_id:20;
> +			/**< Rule identifier to which the pattern matched.
> +			 * @see struct rte_regexdev_rule::rule_id
> +			 */
> +			uint32_t group_id:12;
> +			/**< Group identifier of the rule which the pattern
> +			 * matched. @see struct rte_regexdev_rule::group_id
> +			 */
> +			uint16_t start_offset;
> +			/**< Starting Byte Position for matched rule. */
> +			RTE_STD_C11
> +			union {
> +				uint16_t len;
> +				/**< Length of match in bytes */
> +				uint16_t end_offset;
> +				/**< The end offset of the match. In case
> +				 * MATCH_AS_END configuration is enabled.
> +				 * @see
> RTE_REGEXDEV_CFG_MATCH_AS_END
> +				 */
> +			};
> +		};
> +	};
> +};
> +
> +/* Enumerates RegEx request flags. */
> +#define RTE_REGEX_OPS_REQ_GROUP_ID0_VALID_F (1 << 0)
> +/**< Set when struct rte_regexdev_rule::group_id0 is valid. */
> +
> +#define RTE_REGEX_OPS_REQ_GROUP_ID1_VALID_F (1 << 1)
> +/**< Set when struct rte_regexdev_rule::group_id1 is valid. */
> +
> +#define RTE_REGEX_OPS_REQ_GROUP_ID2_VALID_F (1 << 2)
> +/**< Set when struct rte_regexdev_rule::group_id2 is valid. */
> +
> +#define RTE_REGEX_OPS_REQ_GROUP_ID3_VALID_F (1 << 3)
> +/**< Set when struct rte_regexdev_rule::group_id3 is valid. */
> +
> +#define RTE_REGEX_OPS_REQ_STOP_ON_MATCH_F (1 << 4)
> +/**< The RegEx engine will stop scanning and return the first match. */
> +
> +#define RTE_REGEX_OPS_REQ_MATCH_HIGH_PRIORITY_F (1 << 5)
> +/**< In High Priority mode a maximum of one match will be returned per
> scan to
> + * reduce the post-processing required by the application. The match with the
> + * lowest Rule id, lowest start pointer and lowest match length will be
> + * returned.
> + *
> + * @see struct rte_regex_ops::nb_actual_matches
> + * @see struct rte_regex_ops::nb_matches
> + */
> +
> +
> +/* Enumerates RegEx response flags. */
> +#define RTE_REGEX_OPS_RSP_PMI_SOJ_F (1 << 0)
> +/**< Indicates that the RegEx device has encountered a partial match at the
> + * start of scan in the given buffer.
> + *
> + * @see RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F
> + */
> +
> +#define RTE_REGEX_OPS_RSP_PMI_EOJ_F (1 << 1)
> +/**< Indicates that the RegEx device has encountered a partial match at the
> + * end of scan in the given buffer.
> + *
> + * @see RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F
> + */
> +
> +#define RTE_REGEX_OPS_RSP_MAX_SCAN_TIMEOUT_F (1 << 2)
> +/**< Indicates that the RegEx device has exceeded the max timeout while
> + * scanning the given buffer.
> + *
> + * @see RTE_REGEXDEV_ATTR_MAX_SCAN_TIMEOUT
> + */
> +
> +#define RTE_REGEX_OPS_RSP_MAX_MATCH_F (1 << 3)
> +/**< Indicates that the RegEx device has exceeded the max matches while
> + * scanning the given buffer.
> + *
> + * @see RTE_REGEXDEV_ATTR_MAX_MATCHES
> + */
> +
> +#define RTE_REGEX_OPS_RSP_MAX_PREFIX_F (1 << 4)
> +/**< Indicates that the RegEx device has reached the max allowed prefix
> length
> + * while scanning the given buffer.
> + *
> + * @see RTE_REGEXDEV_ATTR_MAX_PREFIX
> + */
> +
> +/**
> + * The generic *rte_regex_ops* structure to hold the RegEx attributes
> + * for enqueue and dequeue operation.
> + */
> +struct rte_regex_ops {
> +	/* W0 */
> +	uint16_t req_flags;
> +	/**< Request flags for the RegEx ops.
> +	 * @see RTE_REGEX_OPS_REQ_*
> +	 */
> +	uint16_t rsp_flags;
> +	/**< Response flags for the RegEx ops.
> +	 * @see RTE_REGEX_OPS_RSP_*
> +	 */
> +	uint16_t nb_actual_matches;
> +	/**< The total number of actual matches detected by the Regex
> device.*/
> +	uint16_t nb_matches;
> +	/**< The total number of matches returned by the RegEx device for
> this
> +	 * scan. The size of *rte_regex_ops::matches* zero length array will be
> +	 * this value.
> +	 *
> +	 * @see struct rte_regex_ops::matches, struct rte_regexdev_match
> +	 */
> +
> +	/* W1 */
> +	struct rte_mbuf *mbuf; /**< source mbuf, to search in. */
> +
> +	/* W2 */
> +	uint16_t group_id0;
> +	/**< First group_id to match the rule against. At minimum one group
> +	 * should be valid. Behaviour is undefined non of the groups are valid.
> +	 *
> +	 * @see RTE_REGEX_OPS_REQ_GROUP_ID0_VALID_F
> +	 */
> +	uint16_t group_id1;
> +	/**< Second group_id to match the rule against.
> +	 *
> +	 * @see RTE_REGEX_OPS_REQ_GROUP_ID1_VALID_F
> +	 */
> +	uint16_t group_id2;
> +	/**< Third group_id to match the rule against.
> +	 *
> +	 * @see RTE_REGEX_OPS_REQ_GROUP_ID2_VALID_F
> +	 */
> +	uint16_t group_id3;
> +	/**< Forth group_id to match the rule against.
> +	 *
> +	 * @see RTE_REGEX_OPS_REQ_GROUP_ID3_VALID_F
> +	 */
> +
> +	/* W3 */
> +	RTE_STD_C11
> +	union {
> +		uint64_t user_id;
> +		/**< Application specific opaque value. An application may use
> +		 * this field to hold application specific value to share
> +		 * between dequeue and enqueue operation.
> +		 * Implementation should not modify this field.
> +		 */
> +		void *user_ptr;
> +		/**< Pointer representation of *user_id* */
> +	};
> +
> +	/* W4 */
> +	RTE_STD_C11
> +	union {
> +		uint64_t cross_buf_id;
> +		/**< ID used by the RegEx device in order to support cross
> +		 * packet detection.
> +		 * This ID is returned from the RegEx device on the dequeue
> +		 * function. The application must send it back when calling
> +		 * enqueue with the following packet.
> +		 */
> +		void *cross_buf_ptr;
> +		/**< Pointer representation of *corss_buf_id* */
> +	};
> +
> +	/* W5 */
> +	struct rte_regexdev_match matches[];
> +	/**< Zero length array to hold the match tuples.
> +	 * The struct rte_regex_ops::nb_matches value holds the number of
> +	 * elements in this array.
> +	 *
> +	 * @see struct rte_regex_ops::nb_matches
> +	 */
> +};
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Enqueue a burst of scan request on a RegEx device.
> + *
> + * The rte_regexdev_enqueue_burst() function is invoked to place
> + * regex operations on the queue *qp_id* of the device designated by
> + * its *dev_id*.
> + *
> + * The *nb_ops* parameter is the number of operations to process which are
> + * supplied in the *ops* array of *rte_regexdev_op* structures.
> + *
> + * The rte_regexdev_enqueue_burst() function returns the number of
> + * operations it actually enqueued for processing. A return value equal to
> + * *nb_ops* means that all packets have been enqueued.
> + *
> + * @param dev_id
> + *   The identifier of the device.
> + * @param qp_id
> + *   The index of the queue pair which packets are to be enqueued for
> + *   processing. The value must be in the range [0, nb_queue_pairs - 1]
> + *   previously supplied to rte_regexdev_configure().
> + * @param ops
> + *   The address of an array of *nb_ops* pointers to *rte_regexdev_op*
> + *   structures which contain the regex operations to be processed.
> + * @param nb_ops
> + *   The number of operations to process.
> + *
> + * @return
> + *   The number of operations actually enqueued on the regex device. The
> return
> + *   value can be less than the value of the *nb_ops* parameter when the
> + *   regex devices queue is full or if invalid parameters are specified in
> + *   a *rte_regexdev_op*. If the return value is less than *nb_ops*, the
> + *   remaining ops at the end of *ops* are not consumed and the caller has
> + *   to take care of them.
> + */
> +__rte_experimental
> +uint16_t
> +rte_regexdev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
> +			   struct rte_regex_ops **ops, uint16_t nb_ops);
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Dequeue a burst of scan response from a queue on the RegEx device.
> + * The dequeued operation are stored in *rte_regexdev_op* structures
> + * whose pointers are supplied in the *ops* array.
> + *
> + * The rte_regexdev_dequeue_burst() function returns the number of ops
> + * actually dequeued, which is the number of *rte_regexdev_op* data
> structures
> + * effectively supplied into the *ops* array.
> + *
> + * A return value equal to *nb_ops* indicates that the queue contained
> + * at least *nb_ops* operations, and this is likely to signify that other
> + * processed operations remain in the devices output queue. Applications
> + * implementing a "retrieve as many processed operations as possible" policy
> + * can check this specific case and keep invoking the
> + * rte_regexdev_dequeue_burst() function until a value less than
> + * *nb_ops* is returned.
> + *
> + * The rte_regexdev_dequeue_burst() function does not provide any error
> + * notification to avoid the corresponding overhead.
> + *
> + * @param dev_id
> + *   The RegEx device identifier
> + * @param qp_id
> + *   The index of the queue pair from which to retrieve processed packets.
> + *   The value must be in the range [0, nb_queue_pairs - 1] previously
> + *   supplied to rte_regexdev_configure().
> + * @param ops
> + *   The address of an array of pointers to *rte_regexdev_op* structures
> + *   that must be large enough to store *nb_ops* pointers in it.
> + * @param nb_ops
> + *   The maximum number of operations to dequeue.
> + *
> + * @return
> + *   The number of operations actually dequeued, which is the number
> + *   of pointers to *rte_regexdev_op* structures effectively supplied to the
> + *   *ops* array. If the return value is less than *nb_ops*, the remaining
> + *   ops at the end of *ops* are not consumed and the caller has to take care
> + *   of them.
> + */
> +__rte_experimental
> +uint16_t
> +rte_regexdev_dequeue_burst(uint8_t dev_id, uint16_t qp_id,
> +			   struct rte_regex_ops **ops, uint16_t nb_ops);
> +
> +#ifdef __cplusplus
> +}
> +#endif
> +
> +#endif /* _RTE_REGEXDEV_H_ */
> diff --git a/lib/librte_regexdev/rte_regexdev_version.map
> b/lib/librte_regexdev/rte_regexdev_version.map
> new file mode 100644
> index 0000000..d400624
> --- /dev/null
> +++ b/lib/librte_regexdev/rte_regexdev_version.map
> @@ -0,0 +1,26 @@
> +EXPERIMENTAL {
> +	global:
> +
> +	rte_regexdev_count;
> +	rte_regexdev_get_dev_id;
> +	rte_regexdev_info_get;
> +	rte_regexdev_configure;
> +	rte_regexdev_queue_pair_setup;
> +	rte_regexdev_start;
> +	rte_regexdev_stop;
> +	rte_regexdev_close;
> +	rte_regexdev_attr_get;
> +	rte_regexdev_attr_set;
> +	rte_regexdev_rule_db_update;
> +	rte_regexdev_rule_db_compile_activate;
> +	rte_regexdev_rule_db_import;
> +	rte_regexdev_rule_db_export;
> +	rte_regexdev_xstats_names_get;
> +	rte_regexdev_xstats_get;
> +	rte_regexdev_xstats_by_name_get;
> +	rte_regexdev_xstats_reset;
> +	rte_regexdev_selftest;
> +	rte_regexdev_dump;
> +	rte_regexdev_enqueue_burst;
> +	rte_regexdev_dequeue_burst;
> +};
> diff --git a/lib/meson.build b/lib/meson.build
> index 07a65a6..79ae5cb 100644
> --- a/lib/meson.build
> +++ b/lib/meson.build
> @@ -24,7 +24,7 @@ libraries = [
>  	'gro', 'gso', 'ip_frag', 'jobstats',
>  	'kni', 'latencystats', 'lpm', 'member',
>  	'power', 'pdump', 'rawdev',
> -	'rib', 'reorder', 'sched', 'security', 'stack', 'vhost',
> +	'regexdev', 'rib', 'reorder', 'sched', 'security', 'stack', 'vhost',
>  	# ipsec lib depends on net, crypto and security
>  	'ipsec',
>  	#fib lib depends on rib
> --
> 1.8.3.1


^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v3 4/4] regexdev: implement regex rte level functions
  2020-05-07  9:45   ` [dpdk-dev] [PATCH v3 4/4] regexdev: implement regex rte level functions Ori Kam
  2020-06-03  6:59     ` [dpdk-dev] [EXT] " Guy Kaneti
@ 2020-06-28 13:45     ` Guy Kaneti
  2020-06-28 14:10       ` Ori Kam
  1 sibling, 1 reply; 96+ messages in thread
From: Guy Kaneti @ 2020-06-28 13:45 UTC (permalink / raw)
  To: Ori Kam, Jerin Jacob Kollanukkaran, xiang.w.wang
  Cc: dev, Pavan Nikhilesh Bhagavatula, shahafs, hemant.agrawal, opher,
	alexr, Dovrat Zifroni, Prasun Kapoor, nipun.gupta,
	bruce.richardson, yang.a.hong, harry.chang, gu.jian1, shanjiangh,
	zhangy.yun, lixingfu, wushuai, yuyingxia, fanchenggang,
	davidfgao, liuzhong1, zhaoyong11, oc, jim, hongjun.ni,
	j.bromhead, deri, fc, arthur.su, thomas


> +int
> +rte_regexdev_rule_db_export(uint8_t dev_id, char *rule_db) {
> +	struct rte_regexdev *dev;
> +
> +	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
> +	dev = &rte_regex_devices[dev_id];
> +	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_db_export,
> +				-ENOTSUP);
> +	if (rule_db == NULL) {
> +		RTE_REGEXDEV_LOG(ERR, "Dev %d rules can't be NULL\n",
> +				 dev_id);
> +		return -EINVAL;
> +	}
> +	return (*dev->dev_ops->dev_db_export)(dev, rule_db); }

The test if (rule_db == NULL) is not according to the description of the API
It is needed to be NULL in order to retrieve rule_db length 

* @param[out] rule_db
 *   Block of memory to insert the rule database. Must be at least size in
 *   capacity. If set to NULL, function returns required capacity.

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [EXT] [PATCH v3 4/4] regexdev: implement regex rte level functions
  2020-06-28 13:45     ` Guy Kaneti
@ 2020-06-28 14:10       ` Ori Kam
  0 siblings, 0 replies; 96+ messages in thread
From: Ori Kam @ 2020-06-28 14:10 UTC (permalink / raw)
  To: Guy Kaneti, Jerin Jacob Kollanukkaran, xiang.w.wang
  Cc: dev, Pavan Nikhilesh Bhagavatula, Shahaf Shuler, hemant.agrawal,
	Opher Reviv, Alex Rosenbaum, Dovrat Zifroni, Prasun Kapoor,
	nipun.gupta, bruce.richardson, yang.a.hong, harry.chang,
	gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai, yuyingxia,
	fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc, jim,
	hongjun.ni, j.bromhead, deri, fc, arthur.su, Thomas Monjalon



> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Guy Kaneti
> Sent: Sunday, June 28, 2020 4:45 PM
> To: Ori Kam <orika@mellanox.com>; Jerin Jacob Kollanukkaran
> <jerinj@marvell.com>; xiang.w.wang@intel.com
> Cc: dev@dpdk.org; Pavan Nikhilesh Bhagavatula
> <pbhagavatula@marvell.com>; Shahaf Shuler <shahafs@mellanox.com>;
> hemant.agrawal@nxp.com; Opher Reviv <opher@mellanox.com>; Alex
> Rosenbaum <alexr@mellanox.com>; Dovrat Zifroni <dovrat@marvell.com>;
> Prasun Kapoor <pkapoor@marvell.com>; nipun.gupta@nxp.com;
> bruce.richardson@intel.com; yang.a.hong@intel.com; harry.chang@intel.com;
> gu.jian1@zte.com.cn; shanjiangh@chinatelecom.cn;
> zhangy.yun@chinatelecom.cn; lixingfu@huachentel.com; wushuai@inspur.com;
> yuyingxia@yxlink.com; fanchenggang@sunyainfo.com;
> davidfgao@tencent.com; liuzhong1@chinaunicom.cn;
> zhaoyong11@huawei.com; oc@yunify.com; jim@netgate.com;
> hongjun.ni@intel.com; j.bromhead@titan-ic.com; deri@ntop.org;
> fc@napatech.com; arthur.su@lionic.com; Thomas Monjalon
> <thomas@monjalon.net>
> Subject: Re: [dpdk-dev] [EXT] [PATCH v3 4/4] regexdev: implement regex rte
> level functions
> 
> 
> > +int
> > +rte_regexdev_rule_db_export(uint8_t dev_id, char *rule_db) {
> > +	struct rte_regexdev *dev;
> > +
> > +	RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
> > +	dev = &rte_regex_devices[dev_id];
> > +	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_db_export,
> > +				-ENOTSUP);
> > +	if (rule_db == NULL) {
> > +		RTE_REGEXDEV_LOG(ERR, "Dev %d rules can't be NULL\n",
> > +				 dev_id);
> > +		return -EINVAL;
> > +	}
> > +	return (*dev->dev_ops->dev_db_export)(dev, rule_db); }
> 
> The test if (rule_db == NULL) is not according to the description of the API
> It is needed to be NULL in order to retrieve rule_db length
> 

Correct will fix.

> * @param[out] rule_db
>  *   Block of memory to insert the rule database. Must be at least size in
>  *   capacity. If set to NULL, function returns required capacity.

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [dpdk-dev] [PATCH v3 1/4] regexdev: introduce regexdev subsystem
  2020-06-21 11:18     ` Ori Kam
@ 2020-06-30 19:57       ` Ori Kam
  0 siblings, 0 replies; 96+ messages in thread
From: Ori Kam @ 2020-06-30 19:57 UTC (permalink / raw)
  To: jerinj, xiang.w.wang
  Cc: guyk, dev, pbhagavatula, Shahaf Shuler, hemant.agrawal,
	Opher Reviv, Alex Rosenbaum, dovrat, pkapoor, nipun.gupta,
	bruce.richardson, yang.a.hong, harry.chang, gu.jian1, shanjiangh,
	zhangy.yun, lixingfu, wushuai, yuyingxia, fanchenggang,
	davidfgao, liuzhong1, zhaoyong11, oc, jim, hongjun.ni,
	j.bromhead, deri, fc, arthur.su, Thomas Monjalon

Hi all,

Just a reminder for ack,

Thanks,
Ori

> -----Original Message-----
> From: Ori Kam <orika@mellanox.com>
> Sent: Sunday, June 21, 2020 2:19 PM
> To: Ori Kam <orika@mellanox.com>; jerinj@marvell.com;
> xiang.w.wang@intel.com
> Cc: guyk@marvell.com; dev@dpdk.org; pbhagavatula@marvell.com; Shahaf
> Shuler <shahafs@mellanox.com>; hemant.agrawal@nxp.com; Opher Reviv
> <opher@mellanox.com>; Alex Rosenbaum <alexr@mellanox.com>;
> dovrat@marvell.com; pkapoor@marvell.com; nipun.gupta@nxp.com;
> bruce.richardson@intel.com; yang.a.hong@intel.com; harry.chang@intel.com;
> gu.jian1@zte.com.cn; shanjiangh@chinatelecom.cn;
> zhangy.yun@chinatelecom.cn; lixingfu@huachentel.com; wushuai@inspur.com;
> yuyingxia@yxlink.com; fanchenggang@sunyainfo.com;
> davidfgao@tencent.com; liuzhong1@chinaunicom.cn;
> zhaoyong11@huawei.com; oc@yunify.com; jim@netgate.com;
> hongjun.ni@intel.com; j.bromhead@titan-ic.com; deri@ntop.org;
> fc@napatech.com; arthur.su@lionic.com; Thomas Monjalon
> <thomas@monjalon.net>
> Subject: RE: [dpdk-dev] [PATCH v3 1/4] regexdev: introduce regexdev
> subsystem
> 
> Hi All,
> 
> This is the only patch that is missing an ack,
> 
> I plan to submit the PMD code next week, so please review and ack this patch.
> 
> Thanks,
> Ori
> 
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Ori Kam
> > Sent: Thursday, May 7, 2020 12:46 PM
> > To: jerinj@marvell.com; xiang.w.wang@intel.com
> > Cc: guyk@marvell.com; dev@dpdk.org; pbhagavatula@marvell.com; Shahaf
> > Shuler <shahafs@mellanox.com>; hemant.agrawal@nxp.com; Opher Reviv
> > <opher@mellanox.com>; Alex Rosenbaum <alexr@mellanox.com>;
> > dovrat@marvell.com; pkapoor@marvell.com; nipun.gupta@nxp.com;
> > bruce.richardson@intel.com; yang.a.hong@intel.com;
> harry.chang@intel.com;
> > gu.jian1@zte.com.cn; shanjiangh@chinatelecom.cn;
> > zhangy.yun@chinatelecom.cn; lixingfu@huachentel.com;
> wushuai@inspur.com;
> > yuyingxia@yxlink.com; fanchenggang@sunyainfo.com;
> > davidfgao@tencent.com; liuzhong1@chinaunicom.cn;
> > zhaoyong11@huawei.com; oc@yunify.com; jim@netgate.com;
> > hongjun.ni@intel.com; j.bromhead@titan-ic.com; deri@ntop.org;
> > fc@napatech.com; arthur.su@lionic.com; Thomas Monjalon
> > <thomas@monjalon.net>; Ori Kam <orika@mellanox.com>
> > Subject: [dpdk-dev] [PATCH v3 1/4] regexdev: introduce regexdev subsystem
> >
> > From: Jerin Jacob <jerinj@marvell.com>
> >
> > As RegEx usage become more used by DPDK applications, for example:
> > * Next Generation Firewalls (NGFW)
> > * Deep Packet and Flow Inspection (DPI)
> > * Intrusion Prevention Systems (IPS)
> > * DDoS Mitigation
> > * Network Monitoring
> > * Data Loss Prevention (DLP)
> > * Smart NICs
> > * Grammar based content processing
> > * URL, spam and adware filtering
> > * Advanced auditing and policing of user/application security policies
> > * Financial data mining - parsing of streamed financial feeds
> > * Application recognition.
> > * Dmemory introspection.
> > * Natural Language Processing (NLP)
> > * Sentiment Analysis.
> > * Big data databse acceleration.
> > * Computational storage.
> >
> > Number of PMD providers started to work on HW implementation,
> > along side with SW implementations.
> >
> > This lib adds the support for those kind of devices.
> >
> > The RegEx Device API is composed of two parts:
> > - The application-oriented RegEx API that includes functions to setup
> >   a RegEx device (configure it, setup its queue pairs and start it),
> >   update the rule database and so on.
> >
> > - The driver-oriented RegEx API that exports a function allowing
> >   a RegEx poll Mode Driver (PMD) to simultaneously register itself as
> >   a RegEx device driver.
> >
> > RegEx device components and definitions:
> >
> >     +-----------------+
> >     |                 |
> >     |                 o---------+    rte_regexdev_[en|de]queue_burst()
> >     |   PCRE based    o------+  |               |
> >     |  RegEx pattern  |      |  |  +--------+   |
> >     | matching engine o------+--+--o        |   |    +------+
> >     |                 |      |  |  | queue  |<==o===>|Core 0|
> >     |                 o----+ |  |  | pair 0 |        |      |
> >     |                 |    | |  |  +--------+        +------+
> >     +-----------------+    | |  |
> >            ^               | |  |  +--------+
> >            |               | |  |  |        |        +------+
> >            |               | +--+--o queue  |<======>|Core 1|
> >        Rule|Database       |    |  | pair 1 |        |      |
> >     +------+----------+    |    |  +--------+        +------+
> >     |     Group 0     |    |    |
> >     | +-------------+ |    |    |  +--------+        +------+
> >     | | Rules 0..n  | |    |    |  |        |        |Core 2|
> >     | +-------------+ |    |    +--o queue  |<======>|      |
> >     |     Group 1     |    |       | pair 2 |        +------+
> >     | +-------------+ |    |       +--------+
> >     | | Rules 0..n  | |    |
> >     | +-------------+ |    |       +--------+
> >     |     Group 2     |    |       |        |        +------+
> >     | +-------------+ |    |       | queue  |<======>|Core n|
> >     | | Rules 0..n  | |    +-------o pair n |        |      |
> >     | +-------------+ |            +--------+        +------+
> >     |     Group n     |
> >     | +-------------+ |<-------rte_regexdev_rule_db_update()
> >     | |             | |<-------rte_regexdev_rule_db_compile_activate()
> >     | | Rules 0..n  | |<-------rte_regexdev_rule_db_import()
> >     | +-------------+ |------->rte_regexdev_rule_db_export()
> >     +-----------------+
> >
> > RegEx: A regular expression is a concise and flexible means for matching
> > strings of text, such as particular characters, words, or patterns of
> > characters. A common abbreviation for this is â~@~\RegExâ~@~].
> >
> > RegEx device: A hardware or software-based implementation of RegEx
> > device API for PCRE based pattern matching syntax and semantics.
> >
> > PCRE RegEx syntax and semantics specification:
> >
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fregexkit.so
> >
> urceforge.net%2FDocumentation%2Fpcre%2Fpcrepattern.html&amp;data=02%
> >
> 7C01%7Corika%40mellanox.com%7C39f5765e405c46b18ba308d7f26b8480%7C
> >
> a652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C637244415961144968&a
> >
> mp;sdata=NWYja3g5nTerSe8vIFSHpTeK8ipKOhMnXmmNBuJtWqY%3D&amp;res
> > erved=0
> >
> > RegEx queue pair: Each RegEx device should have one or more queue pair to
> > transmit a burst of pattern matching request and receive a burst of
> > receive the pattern matching response. The pattern matching
> > request/response embedded in *rte_regex_ops* structure.
> >
> > Rule: A pattern matching rule expressed in PCRE RegEx syntax along with
> > Match ID and Group ID to identify the rule upon the match.
> >
> > Rule database: The RegEx device accepts regular expressions and converts
> > them into a compiled rule database that can then be used to scan data.
> > Compilation allows the device to analyze the given pattern(s) and
> > pre-determine how to scan for these patterns in an optimized fashion that
> > would be far too expensive to compute at run-time. A rule database
> > contains a set of rules that compiled in device specific binary form.
> >
> > Match ID or Rule ID: A unique identifier provided at the time of rule
> > creation for the application to identify the rule upon match.
> >
> > Group ID: Group of rules can be grouped under one group ID to enable
> > rule isolation and effective pattern matching. A unique group identifier
> > provided at the time of rule creation for the application to identify
> > the rule upon match.
> >
> > Scan: A pattern matching request through *enqueue* API.
> >
> > It may possible that a given RegEx device may not support all the
> > features
> > of PCRE. The application may probe unsupported features through
> > struct rte_regexdev_info::pcre_unsup_flags
> >
> > By default, all the functions of the RegEx Device API exported by a PMD
> > are lock-free functions which assume to not be invoked in parallel on
> > different logical cores to work on the same target object. For instance,
> > the dequeue function of a PMD cannot be invoked in parallel on two logical
> > cores to operates on same RegEx queue pair. Of course, this function
> > can be invoked in parallel by different logical core on different queue
> > pair. It is the responsibility of the upper level application to
> > enforce this rule.
> >
> > In all functions of the RegEx API, the RegEx device is
> > designated by an integer >= 0 named the device identifier *dev_id*
> >
> > At the RegEx driver level, RegEx devices are represented by a generic
> > data structure of type *rte_regexdev*.
> > RegEx devices are dynamically registered during the PCI/SoC device
> > probing phase performed at EAL initialization time.
> > When a RegEx device is being probed, a *rte_regexdev* structure and
> > a new device identifier are allocated for that device. Then, the
> > regexdev_init() function supplied by the RegEx driver matching the
> > probed device is invoked to properly initialize the device.
> >
> > The role of the device init function consists of resetting the hardware
> > or software RegEx driver implementations.
> >
> > If the device init operation is successful, the correspondence between
> > the device identifier assigned to the new device and its associated
> > *rte_regexdev* structure is effectively registered.
> > Otherwise, both the *rte_regexdev* structure and the device identifier
> > are freed.
> >
> > The functions exported by the application RegEx API to setup a device
> > designated by its device identifier must be invoked in the following
> > order:
> >     - rte_regexdev_configure()
> >     - rte_regexdev_queue_pair_setup()
> >     - rte_regexdev_start()
> >
> > Then, the application can invoke, in any order, the functions
> > exported by the RegEx API to enqueue pattern matching job, dequeue
> > pattern matching response, get the stats, update the rule database,
> > get/set device attributes and so on
> >
> > If the application wants to change the configuration (i.e. call
> > rte_regexdev_configure() or rte_regexdev_queue_pair_setup()), it must
> > call rte_regexdev_stop() first to stop the device and then do the
> > reconfiguration before calling rte_regexdev_start() again. The enqueue and
> > dequeue functions should not be invoked when the device is stopped.
> >
> > Finally, an application can close a RegEx device by invoking the
> > rte_regexdev_close() function.
> >
> > Each function of the application RegEx API invokes a specific function
> > of the PMD that controls the target device designated by its device
> > identifier.
> >
> > For this purpose, all device-specific functions of a RegEx driver are
> > supplied through a set of pointers contained in a generic structure of
> > type *regexdev_ops*.
> > The address of the *regexdev_ops* structure is stored in the
> > *rte_regexdev* structure by the device init function of the RegEx driver,
> > which is invoked during the PCI/SoC device probing phase, as explained
> > earlier.
> >
> > In other words, each function of the RegEx API simply retrieves the
> > *rte_regexdev* structure associated with the device identifier and
> > performs an indirect invocation of the corresponding driver function
> > supplied in the *regexdev_ops* structure of the *rte_regexdev*
> > structure.
> >
> > For performance reasons, the address of the fast-path functions of the
> > RegEx driver is not contained in the *regexdev_ops* structure.
> > Instead, they are directly stored at the beginning of the *rte_regexdev*
> > structure to avoid an extra indirect memory access during their
> > invocation.
> >
> > RTE RegEx device drivers do not use interrupts for enqueue or dequeue
> > operation. Instead, RegEx drivers export Poll-Mode enqueue and dequeue
> > functions to applications.
> >
> > The *enqueue* operation submits a burst of RegEx pattern matching
> > request to the RegEx device and the *dequeue* operation gets a burst of
> > pattern matching response for the ones submitted through *enqueue*
> > operation.
> >
> > Typical application utilisation of the RegEx device API will follow the
> > following programming flow.
> >
> > - rte_regexdev_configure()
> > - rte_regexdev_queue_pair_setup()
> > - rte_regexdev_rule_db_update() Needs to invoke if precompiled rule
> >   database not
> >   provided in rte_regexdev_config::rule_db for rte_regexdev_configure()
> >   and/or application needs to update rule database.
> > - rte_regexdev_rule_db_compile_activate() Needs to invoke if
> >   rte_regexdev_rule_db_update function was used.
> > - Create or reuse exiting mempool for *rte_regex_ops* objects.
> > - rte_regexdev_start()
> > - rte_regexdev_enqueue_burst()
> > - rte_regexdev_dequeue_burst()
> >
> > Signed-off-by: Jerin Jacob <jerinj@marvell.com>
> > Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
> > Signed-off-by: Ori Kam <orika@mellanox.com>
> > ---
> > v3:
> > * No changes.
> >
> > v2:
> > * Move unused define to other patch.
> > ---
> >  config/common_base                           |    6 +
> >  doc/api/doxy-api-index.md                    |    1 +
> >  doc/api/doxy-api.conf.in                     |    1 +
> >  doc/guides/prog_guide/index.rst              |    1 +
> >  doc/guides/prog_guide/regexdev_lib.rst       |  177 ++++
> >  lib/Makefile                                 |    2 +
> >  lib/librte_regexdev/Makefile                 |   31 +
> >  lib/librte_regexdev/meson.build              |    7 +
> >  lib/librte_regexdev/rte_regexdev.c           |    6 +
> >  lib/librte_regexdev/rte_regexdev.h           | 1473
> > ++++++++++++++++++++++++++
> >  lib/librte_regexdev/rte_regexdev_version.map |   26 +
> >  lib/meson.build                              |    2 +-
> >  12 files changed, 1732 insertions(+), 1 deletion(-)
> >  create mode 100644 doc/guides/prog_guide/regexdev_lib.rst
> >  create mode 100644 lib/librte_regexdev/Makefile
> >  create mode 100644 lib/librte_regexdev/meson.build
> >  create mode 100644 lib/librte_regexdev/rte_regexdev.c
> >  create mode 100644 lib/librte_regexdev/rte_regexdev.h
> >  create mode 100644 lib/librte_regexdev/rte_regexdev_version.map
> >
> > diff --git a/config/common_base b/config/common_base
> > index 14000ba..27fcab1 100644
> > --- a/config/common_base
> > +++ b/config/common_base
> > @@ -832,6 +832,11 @@
> > CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_EP_RAWDEV=y
> >  CONFIG_RTE_LIBRTE_PMD_NTB_RAWDEV=y
> >
> >  #
> > +# Compile regex device support
> > +#
> > +CONFIG_RTE_LIBRTE_REGEXDEV=y
> > +
> > +#
> >  # Compile librte_ring
> >  #
> >  CONFIG_RTE_LIBRTE_RING=y
> > @@ -1124,3 +1129,4 @@ CONFIG_RTE_APP_CRYPTO_PERF=y
> >  # Compile the eventdev application
> >  #
> >  CONFIG_RTE_APP_EVENTDEV=y
> > +
> > diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
> > index 845a534..702591b 100644
> > --- a/doc/api/doxy-api-index.md
> > +++ b/doc/api/doxy-api-index.md
> > @@ -26,6 +26,7 @@ The public API headers are grouped by topics:
> >    [event_timer_adapter]    (@ref rte_event_timer_adapter.h),
> >    [event_crypto_adapter]   (@ref rte_event_crypto_adapter.h),
> >    [rawdev]             (@ref rte_rawdev.h),
> > +  [regexdev]           (@ref rte_regexdev.h),
> >    [metrics]            (@ref rte_metrics.h),
> >    [bitrate]            (@ref rte_bitrate.h),
> >    [latency]            (@ref rte_latencystats.h),
> > diff --git a/doc/api/doxy-api.conf.in b/doc/api/doxy-api.conf.in
> > index 65e8146..84621ba 100644
> > --- a/doc/api/doxy-api.conf.in
> > +++ b/doc/api/doxy-api.conf.in
> > @@ -58,6 +58,7 @@ INPUT                   = @TOPDIR@/doc/api/doxy-api-
> > index.md \
> >                            @TOPDIR@/lib/librte_rcu \
> >                            @TOPDIR@/lib/librte_reorder \
> >                            @TOPDIR@/lib/librte_rib \
> > +                          @TOPDIR@/lib/librte_regexdev \
> >                            @TOPDIR@/lib/librte_ring \
> >                            @TOPDIR@/lib/librte_sched \
> >                            @TOPDIR@/lib/librte_security \
> > diff --git a/doc/guides/prog_guide/index.rst
> b/doc/guides/prog_guide/index.rst
> > index 1d0cd49..fa8536c 100644
> > --- a/doc/guides/prog_guide/index.rst
> > +++ b/doc/guides/prog_guide/index.rst
> > @@ -71,3 +71,4 @@ Programmer's Guide
> >      lto
> >      profile_app
> >      glossary
> > +    regexdev_lib
> > diff --git a/doc/guides/prog_guide/regexdev_lib.rst
> > b/doc/guides/prog_guide/regexdev_lib.rst
> > new file mode 100644
> > index 0000000..1ecbf1c
> > --- /dev/null
> > +++ b/doc/guides/prog_guide/regexdev_lib.rst
> > @@ -0,0 +1,177 @@
> > +..  SPDX-License-Identifier: BSD-3-Clause
> > +    Copyright(c) 2020 Mellanox Corporation.
> > +
> > +RegEx Device Library
> > +=====================
> > +
> > +The RegEx library provides a RegEx device framework for management and
> > +provisioning of hardware and software RegEx poll mode drivers, defining
> > generic
> > +APIs which support a number of different RegEx operations.
> > +
> > +
> > +Design Principles
> > +-----------------
> > +
> > +The RegEx library follows the same basic principles as those used in DPDK's
> > +Ethernet Device framework and the Crypto framework. The RegEx
> framework
> > provides
> > +a generic Crypto device framework which supports both physical (hardware)
> > +and virtual (software) RegEx devices as well as a generic RegEx API which
> > allows
> > +RegEx devices to be managed and configured and supports RegEx
> operations
> > to be
> > +provisioned on RegEx poll mode driver.
> > +
> > +
> > +Device Management
> > +-----------------
> > +
> > +Device Creation
> > +~~~~~~~~~~~~~~~
> > +
> > +Physical RegEx devices are discovered during the PCI probe/enumeration of
> > the
> > +EAL function which is executed at DPDK initialization, based on
> > +their PCI device identifier, each unique PCI BDF (bus/bridge, device,
> > +function). Specific physical ReEx devices, like other physical devices in DPDK
> > +can be white-listed or black-listed using the EAL command line options.
> > +
> > +
> > +Device Identification
> > +~~~~~~~~~~~~~~~~~~~~~
> > +
> > +Each device, whether virtual or physical is uniquely designated by two
> > +identifiers:
> > +
> > +- A unique device index used to designate the RegEx device in all functions
> > +  exported by the regexdev API.
> > +
> > +- A device name used to designate the RegEx device in console messages,
> for
> > +  administration or debugging purposes.
> > +
> > +
> > +Device Configuration
> > +~~~~~~~~~~~~~~~~~~~~
> > +
> > +The configuration of each RegEx device includes the following operations:
> > +
> > +- Allocation of resources, including hardware resources if a physical device.
> > +- Resetting the device into a well-known default state.
> > +- Initialization of statistics counters.
> > +
> > +The rte_regexdev_configure API is used to configure a RegEx device.
> > +
> > +.. code-block:: c
> > +
> > +   int rte_regexdev_configure(uint8_t dev_id,
> > +                              const struct rte_regexdev_config *cfg);
> > +
> > +The ``rte_regexdev_config`` structure is used to pass the configuration
> > +parameters for the RegEx device for example  number of queue pairs,
> > number of
> > +groups, max number of matches and so on.
> > +
> > +.. code-block:: c
> > +
> > +   struct rte_regexdev_config {
> > +        uint16_t nb_max_matches;
> > +        /**< Maximum matches per scan configured on this device.
> > +         * This value cannot exceed the *max_matches*
> > +         * which previously provided in rte_regexdev_info_get().
> > +         * The value 0 is allowed, in which case, value 1 used.
> > +         * @see struct rte_regexdev_info::max_matches
> > +         */
> > +        uint16_t nb_queue_pairs;
> > +        /**< Number of RegEx queue pairs to configure on this device.
> > +         * This value cannot exceed the *max_queue_pairs* which previously
> > +         * provided in rte_regexdev_info_get().
> > +         * @see struct rte_regexdev_info::max_queue_pairs
> > +         */
> > +        uint32_t nb_rules_per_group;
> > +        /**< Number of rules per group to configure on this device.
> > +         * This value cannot exceed the *max_rules_per_group*
> > +         * which previously provided in rte_regexdev_info_get().
> > +         * The value 0 is allowed, in which case,
> > +         * struct rte_regexdev_info::max_rules_per_group used.
> > +         * @see struct rte_regexdev_info::max_rules_per_group
> > +         */
> > +        uint16_t nb_groups;
> > +        /**< Number of groups to configure on this device.
> > +         * This value cannot exceed the *max_groups*
> > +         * which previously provided in rte_regexdev_info_get().
> > +         * @see struct rte_regexdev_info::max_groups
> > +         */
> > +        const char *rule_db;
> > +        /**< Import initial set of prebuilt rule database on this device.
> > +         * The value NULL is allowed, in which case, the device will not
> > +         * be configured prebuilt rule database. Application may use
> > +         * rte_regexdev_rule_db_update() or rte_regexdev_rule_db_import()
> API
> > +         * to update or import rule database after the
> > +         * rte_regexdev_configure().
> > +         * @see rte_regexdev_rule_db_update(),
> rte_regexdev_rule_db_import()
> > +         */
> > +        uint32_t rule_db_len;
> > +        /**< Length of *rule_db* buffer. */
> > +        uint32_t dev_cfg_flags;
> > +        /**< RegEx device configuration flags, See RTE_REGEXDEV_CFG_*  */
> > +    };
> > +
> > +
> > +Configuration of Rules Database
> > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > +
> > +Each Regex device should be configured with the rule database.
> > +There are two modes of setting the rule database, online or offline.
> > +The online mode means, that the rule database in being compiled by the
> > +RegEx PMD while in the offline mode the rule database is compiled by
> > external
> > +compiler, and is being loaded to the PMD as a buffer.
> > +The configuration mode is depended on the PMD capabilities.
> > +
> > +Online rule configuration is done using the following API functions:
> > +``rte_regexdev_rule_db_update`` which add / remove rules from the rules
> > +precomplied list, and ``rte_regexdev_rule_db_compile_activate``
> > +which compile the rules and loads them to the RegEx HW.
> > +
> > +Offline rule configuration can be done by adding a pointer to the compiled
> > +rule database in the configuration step, or by using
> > +``rte_regexdev_rule_db_import`` API.
> > +
> > +
> > +Configuration of Queue Pairs
> > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > +
> > +Each RegEx device can be configured with number of queue pairs.
> > +Each queue pair is configured using ``rte_regexdev_queue_pair_setup``
> > +
> > +
> > +Logical Cores, Memory and Queues Pair Relationships
> > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > +
> > +Multiple logical cores should never share the same queue pair for
> enqueuing
> > +operations or dequeuing operations on the same RegEx device since this
> > would
> > +require global locks and hinder performance.
> > +
> > +
> > +Device Features and Capabilities
> > +---------------------------------
> > +
> > +RegEx devices may support different feature set.
> > +In order to get the supported PMD feature ``rte_regexdev_info_get``
> > +API which return the info of the device and it's supported features.
> > +
> > +
> > +Enqueue / Dequeue Burst APIs
> > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > +
> > +The burst enqueue API uses a RegEx device identifier and a queue pair
> > +identifier to specify the device queue pair to schedule the processing on.
> > +The ``nb_ops`` parameter is the number of operations to process which are
> > +supplied in the ``ops`` array of ``rte_regex_ops`` structures.
> > +The enqueue function returns the number of operations it actually enqueued
> > for
> > +processing, a return value equal to ``nb_ops`` means that all packets have
> > been
> > +enqueued.
> > +
> > +Data pointed in each op, should not be released until the dequeue of for that
> > +op.
> > +
> > +The dequeue API uses the same format as the enqueue API of processed but
> > +the ``nb_ops`` and ``ops`` parameters are now used to specify the max
> > processed
> > +operations the user wishes to retrieve and the location in which to store
> them.
> > +The API call returns the actual number of processed operations returned,
> this
> > +can never be larger than ``nb_ops``.
> > +
> > diff --git a/lib/Makefile b/lib/Makefile
> > index d0ec391..6a3d4e3 100644
> > --- a/lib/Makefile
> > +++ b/lib/Makefile
> > @@ -44,6 +44,8 @@ DEPDIRS-librte_eventdev := librte_eal librte_ring
> > librte_ethdev librte_hash \
> >                             librte_mempool librte_timer librte_cryptodev
> >  DIRS-$(CONFIG_RTE_LIBRTE_RAWDEV) += librte_rawdev
> >  DEPDIRS-librte_rawdev := librte_eal librte_ethdev
> > +DIRS-$(CONFIG_RTE_LIBRTE_REGEXDEV) += librte_regexdev
> > +DEPDIRS-librte_regexdev := librte_eal librte_mbuf
> >  DIRS-$(CONFIG_RTE_LIBRTE_VHOST) += librte_vhost
> >  DEPDIRS-librte_vhost := librte_eal librte_mempool librte_mbuf librte_ethdev
> \
> >  			librte_net librte_hash librte_cryptodev
> > diff --git a/lib/librte_regexdev/Makefile b/lib/librte_regexdev/Makefile
> > new file mode 100644
> > index 0000000..6f4cc63
> > --- /dev/null
> > +++ b/lib/librte_regexdev/Makefile
> > @@ -0,0 +1,31 @@
> > +# SPDX-License-Identifier: BSD-3-Clause
> > +# Copyright(C) 2019 Marvell International Ltd.
> > +# Copyright(C) 2020 Mellanox International Ltd.
> > +#
> > +
> > +include $(RTE_SDK)/mk/rte.vars.mk
> > +
> > +# library name
> > +LIB = librte_regexdev.a
> > +
> > +EXPORT_MAP := rte_regex_version.map
> > +
> > +# library version
> > +LIBABIVER := 1
> > +
> > +# build flags
> > +CFLAGS += -O3
> > +CFLAGS += $(WERROR_FLAGS)
> > +LDLIBS += -lrte_eal -lrte_mbuf
> > +
> > +# library source files
> > +# all source are stored in SRCS-y
> > +SRCS-$(CONFIG_RTE_LIBRTE_REGEXDEV) := rte_regexdev.c
> > +
> > +# export include files
> > +SYMLINK-$(CONFIG_RTE_LIBRTE_REGEXDEV)-include += rte_regexdev.h
> > +
> > +# versioning export map
> > +EXPORT_MAP := rte_regexdev_version.map
> > +
> > +include $(RTE_SDK)/mk/rte.lib.mk
> > diff --git a/lib/librte_regexdev/meson.build
> b/lib/librte_regexdev/meson.build
> > new file mode 100644
> > index 0000000..f4db748
> > --- /dev/null
> > +++ b/lib/librte_regexdev/meson.build
> > @@ -0,0 +1,7 @@
> > +# SPDX-License-Identifier: BSD-3-Clause
> > +# Copyright(c) 2020 Mellanox Corporation
> > +
> > +allow_experimental_apis = true
> > +sources = files('rte_regexdev.c')
> > +headers = files('rte_regexdev.h')
> > +deps += ['mbuf']
> > diff --git a/lib/librte_regexdev/rte_regexdev.c
> > b/lib/librte_regexdev/rte_regexdev.c
> > new file mode 100644
> > index 0000000..b901877
> > --- /dev/null
> > +++ b/lib/librte_regexdev/rte_regexdev.c
> > @@ -0,0 +1,6 @@
> > +/* SPDX-License-Identifier: BSD-3-Clause
> > + * Copyright(C) 2019 Marvell International Ltd.
> > + * Copyright(C) 2020 Mellanox International Ltd.
> > + */
> > +
> > +#include <rte_regexdev.h>
> > diff --git a/lib/librte_regexdev/rte_regexdev.h
> > b/lib/librte_regexdev/rte_regexdev.h
> > new file mode 100644
> > index 0000000..7e688d9
> > --- /dev/null
> > +++ b/lib/librte_regexdev/rte_regexdev.h
> > @@ -0,0 +1,1473 @@
> > +/* SPDX-License-Identifier: BSD-3-Clause
> > + * Copyright(C) 2019 Marvell International Ltd.
> > + * Copyright(C) 2020 Mellanox International Ltd.
> > + * Copyright(C) 2020 Intel International Ltd.
> > + */
> > +
> > +#ifndef _RTE_REGEXDEV_H_
> > +#define _RTE_REGEXDEV_H_
> > +
> > +/**
> > + * @file
> > + *
> > + * RTE RegEx Device API
> > + *
> > + * Defines RTE RegEx Device APIs for RegEx operations and its provisioning.
> > + *
> > + * The RegEx Device API is composed of two parts:
> > + *
> > + * - The application-oriented RegEx API that includes functions to setup
> > + *   a RegEx device (configure it, setup its queue pairs and start it),
> > + *   update the rule database and so on.
> > + *
> > + * - The driver-oriented RegEx API that exports a function allowing
> > + *   a RegEx poll Mode Driver (PMD) to simultaneously register itself as
> > + *   a RegEx device driver.
> > + *
> > + * RegEx device components and definitions:
> > + *
> > + *     +-----------------+
> > + *     |                 |
> > + *     |                 o---------+    rte_regexdev_[en|de]queue_burst()
> > + *     |   PCRE based    o------+  |               |
> > + *     |  RegEx pattern  |      |  |  +--------+   |
> > + *     | matching engine o------+--+--o        |   |    +------+
> > + *     |                 |      |  |  | queue  |<==o===>|Core 0|
> > + *     |                 o----+ |  |  | pair 0 |        |      |
> > + *     |                 |    | |  |  +--------+        +------+
> > + *     +-----------------+    | |  |
> > + *            ^               | |  |  +--------+
> > + *            |               | |  |  |        |        +------+
> > + *            |               | +--+--o queue  |<======>|Core 1|
> > + *        Rule|Database       |    |  | pair 1 |        |      |
> > + *     +------+----------+    |    |  +--------+        +------+
> > + *     |     Group 0     |    |    |
> > + *     | +-------------+ |    |    |  +--------+        +------+
> > + *     | | Rules 0..n  | |    |    |  |        |        |Core 2|
> > + *     | +-------------+ |    |    +--o queue  |<======>|      |
> > + *     |     Group 1     |    |       | pair 2 |        +------+
> > + *     | +-------------+ |    |       +--------+
> > + *     | | Rules 0..n  | |    |
> > + *     | +-------------+ |    |       +--------+
> > + *     |     Group 2     |    |       |        |        +------+
> > + *     | +-------------+ |    |       | queue  |<======>|Core n|
> > + *     | | Rules 0..n  | |    +-------o pair n |        |      |
> > + *     | +-------------+ |            +--------+        +------+
> > + *     |     Group n     |
> > + *     | +-------------+ |<-------rte_regexdev_rule_db_update()
> > + *     | |             | |<-------rte_regexdev_rule_db_compile_activate()
> > + *     | | Rules 0..n  | |<-------rte_regexdev_rule_db_import()
> > + *     | +-------------+ |------->rte_regexdev_rule_db_export()
> > + *     +-----------------+
> > + *
> > + * RegEx: A regular expression is a concise and flexible means for matching
> > + * strings of text, such as particular characters, words, or patterns of
> > + * characters. A common abbreviation for this is “RegEx”.
> > + *
> > + * RegEx device: A hardware or software-based implementation of RegEx
> > + * device API for PCRE based pattern matching syntax and semantics.
> > + *
> > + * PCRE RegEx syntax and semantics specification:
> > + *
> >
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fregexkit.so
> >
> urceforge.net%2FDocumentation%2Fpcre%2Fpcrepattern.html&amp;data=02%
> >
> 7C01%7Corika%40mellanox.com%7C39f5765e405c46b18ba308d7f26b8480%7C
> >
> a652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C637244415961144968&a
> >
> mp;sdata=NWYja3g5nTerSe8vIFSHpTeK8ipKOhMnXmmNBuJtWqY%3D&amp;res
> > erved=0
> > + *
> > + * RegEx queue pair: Each RegEx device should have one or more queue pair
> > to
> > + * transmit a burst of pattern matching request and receive a burst of
> > + * receive the pattern matching response. The pattern matching
> > request/response
> > + * embedded in *rte_regex_ops* structure.
> > + *
> > + * Rule: A pattern matching rule expressed in PCRE RegEx syntax along with
> > + * Match ID and Group ID to identify the rule upon the match.
> > + *
> > + * Rule database: The RegEx device accepts regular expressions and
> converts
> > them
> > + * into a compiled rule database that can then be used to scan data.
> > + * Compilation allows the device to analyze the given pattern(s) and
> > + * pre-determine how to scan for these patterns in an optimized fashion that
> > + * would be far too expensive to compute at run-time. A rule database
> > contains
> > + * a set of rules that compiled in device specific binary form.
> > + *
> > + * Match ID or Rule ID: A unique identifier provided at the time of rule
> > + * creation for the application to identify the rule upon match.
> > + *
> > + * Group ID: Group of rules can be grouped under one group ID to enable
> > + * rule isolation and effective pattern matching. A unique group identifier
> > + * provided at the time of rule creation for the application to identify the
> > + * rule upon match.
> > + *
> > + * Scan: A pattern matching request through *enqueue* API.
> > + *
> > + * It may possible that a given RegEx device may not support all the features
> > + * of PCRE. The application may probe unsupported features through
> > + * struct rte_regexdev_info::pcre_unsup_flags
> > + *
> > + * By default, all the functions of the RegEx Device API exported by a PMD
> > + * are lock-free functions which assume to not be invoked in parallel on
> > + * different logical cores to work on the same target object. For instance,
> > + * the dequeue function of a PMD cannot be invoked in parallel on two
> logical
> > + * cores to operates on same RegEx queue pair. Of course, this function
> > + * can be invoked in parallel by different logical core on different queue
> pair.
> > + * It is the responsibility of the upper level application to enforce this rule.
> > + *
> > + * In all functions of the RegEx API, the RegEx device is
> > + * designated by an integer >= 0 named the device identifier *dev_id*
> > + *
> > + * At the RegEx driver level, RegEx devices are represented by a generic
> > + * data structure of type *rte_regexdev*.
> > + *
> > + * RegEx devices are dynamically registered during the PCI/SoC device
> > probing
> > + * phase performed at EAL initialization time.
> > + * When a RegEx device is being probed, a *rte_regexdev* structure and
> > + * a new device identifier are allocated for that device. Then, the
> > + * regexdev_init() function supplied by the RegEx driver matching the
> probed
> > + * device is invoked to properly initialize the device.
> > + *
> > + * The role of the device init function consists of resetting the hardware or
> > + * software RegEx driver implementations.
> > + *
> > + * If the device init operation is successful, the correspondence between
> > + * the device identifier assigned to the new device and its associated
> > + * *rte_regexdev* structure is effectively registered.
> > + * Otherwise, both the *rte_regexdev* structure and the device identifier
> are
> > + * freed.
> > + *
> > + * The functions exported by the application RegEx API to setup a device
> > + * designated by its device identifier must be invoked in the following order:
> > + *     - rte_regexdev_configure()
> > + *     - rte_regexdev_queue_pair_setup()
> > + *     - rte_regexdev_start()
> > + *
> > + * Then, the application can invoke, in any order, the functions
> > + * exported by the RegEx API to enqueue pattern matching job, dequeue
> > pattern
> > + * matching response, get the stats, update the rule database,
> > + * get/set device attributes and so on
> > + *
> > + * If the application wants to change the configuration (i.e. call
> > + * rte_regexdev_configure() or rte_regexdev_queue_pair_setup()), it must
> > call
> > + * rte_regexdev_stop() first to stop the device and then do the
> reconfiguration
> > + * before calling rte_regexdev_start() again. The enqueue and dequeue
> > + * functions should not be invoked when the device is stopped.
> > + *
> > + * Finally, an application can close a RegEx device by invoking the
> > + * rte_regexdev_close() function.
> > + *
> > + * Each function of the application RegEx API invokes a specific function
> > + * of the PMD that controls the target device designated by its device
> > + * identifier.
> > + *
> > + * For this purpose, all device-specific functions of a RegEx driver are
> > + * supplied through a set of pointers contained in a generic structure of type
> > + * *regexdev_ops*.
> > + * The address of the *regexdev_ops* structure is stored in the
> > *rte_regexdev*
> > + * structure by the device init function of the RegEx driver, which is
> > + * invoked during the PCI/SoC device probing phase, as explained earlier.
> > + *
> > + * In other words, each function of the RegEx API simply retrieves the
> > + * *rte_regexdev* structure associated with the device identifier and
> > + * performs an indirect invocation of the corresponding driver function
> > + * supplied in the *regexdev_ops* structure of the *rte_regexdev*
> structure.
> > + *
> > + * For performance reasons, the address of the fast-path functions of the
> > + * RegEx driver is not contained in the *regexdev_ops* structure.
> > + * Instead, they are directly stored at the beginning of the *rte_regexdev*
> > + * structure to avoid an extra indirect memory access during their
> invocation.
> > + *
> > + * RTE RegEx device drivers do not use interrupts for enqueue or dequeue
> > + * operation. Instead, RegEx drivers export Poll-Mode enqueue and dequeue
> > + * functions to applications.
> > + *
> > + * The *enqueue* operation submits a burst of RegEx pattern matching
> > request
> > + * to the RegEx device and the *dequeue* operation gets a burst of pattern
> > + * matching response for the ones submitted through *enqueue* operation.
> > + *
> > + * Typical application utilisation of the RegEx device API will follow the
> > + * following programming flow.
> > + *
> > + * - rte_regexdev_configure()
> > + * - rte_regexdev_queue_pair_setup()
> > + * - rte_regexdev_rule_db_update() Needs to invoke if precompiled rule
> > database
> > + *   not provided in rte_regexdev_config::rule_db for
> > rte_regexdev_configure()
> > + *   and/or application needs to update rule database.
> > + * - rte_regexdev_rule_db_compile_activate() Needs to invoke if
> > + *   rte_regexdev_rule_db_update function was used.
> > + * - Create or reuse exiting mempool for *rte_regex_ops* objects.
> > + * - rte_regexdev_start()
> > + * - rte_regexdev_enqueue_burst()
> > + * - rte_regexdev_dequeue_burst()
> > + *
> > + */
> > +
> > +#ifdef __cplusplus
> > +extern "C" {
> > +#endif
> > +
> > +#include <rte_common.h>
> > +#include <rte_config.h>
> > +#include <rte_dev.h>
> > +#include <rte_errno.h>
> > +#include <rte_mbuf.h>
> > +#include <rte_memory.h>
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice.
> > + *
> > + * Get the total number of RegEx devices that have been successfully
> > + * initialised.
> > + *
> > + * @return
> > + *   The total number of usable RegEx devices.
> > + */
> > +__rte_experimental
> > +uint8_t
> > +rte_regexdev_count(void);
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice.
> > + *
> > + * Get the device identifier for the named RegEx device.
> > + *
> > + * @param name
> > + *   RegEx device name to select the RegEx device identifier.
> > + *
> > + * @return
> > + *   Returns RegEx device identifier on success.
> > + *   - <0: Failure to find named RegEx device.
> > + */
> > +__rte_experimental
> > +int
> > +rte_regexdev_get_dev_id(const char *name);
> > +
> > +/* Enumerates RegEx device capabilities */
> > +#define RTE_REGEXDEV_CAPA_RUNTIME_COMPILATION_F (1ULL << 0)
> > +/**< RegEx device does support compiling the rules at runtime unlike
> > + * loading only the pre-built rule database using
> > + * struct rte_regexdev_config::rule_db in rte_regexdev_configure()
> > + *
> > + * @see struct rte_regexdev_config::rule_db, rte_regexdev_configure()
> > + * @see struct rte_regexdev_info::regexdev_capa
> > + */
> > +
> > +#define RTE_REGEXDEV_CAPA_SUPP_PCRE_START_ANCHOR_F (1ULL << 1)
> > +/**< RegEx device support PCRE Anchor to start of match flag.
> > + * Example RegEx is '/\Gfoo\d/'. Here '\G' asserts position at the end of the
> > + * previous match or the start of the string for the first match.
> > + * This position will change each time the RegEx is applied to the subject
> > + * string. If the RegEx is applied to 'foo1foo2Zfoo3' the first two matches will
> > + * be successful for 'foo1foo2' and fail for 'Zfoo3'.
> > + *
> > + * @see struct rte_regexdev_info::regexdev_capa
> > + */
> > +
> > +#define RTE_REGEXDEV_CAPA_SUPP_PCRE_ATOMIC_GROUPING_F (1ULL
> <<
> > 2)
> > +/**< RegEx device support PCRE Atomic grouping.
> > + * Atomic groups are represented by '(?>)'. An atomic group is a group that,
> > + * when the RegEx engine exits from it, automatically throws away all
> > + * backtracking positions remembered by any tokens inside the group.
> > + * Example RegEx is 'a(?>bc|b)c' if the given patterns are 'abc' and 'abcc'
> then
> > + * 'a(bc|b)c' matches both where as 'a(?>bc|b)c' matches only abcc because
> > + * atomic groups don't allow backtracing back to 'b'.
> > + *
> > + * @see struct rte_regexdev_info::regexdev_capa
> > + */
> > +
> > +#define RTE_REGEXDEV_SUPP_PCRE_BACKTRACKING_CTRL_F (1ULL << 3)
> > +/**< RegEx device support PCRE backtracking control verbs.
> > + * Some examples of backtracing verbs are (*COMMIT), (*ACCEPT), (*FAIL),
> > + * (*SKIP), (*PRUNE).
> > + *
> > + * @see struct rte_regexdev_info::regexdev_capa
> > + */
> > +
> > +#define RTE_REGEXDEV_SUPP_PCRE_CALLOUTS_F (1ULL << 4)
> > +/**< RegEx device support PCRE callouts.
> > + * PCRE supports calling external function in between matches by using
> '(?C)'.
> > + * Example RegEx 'ABC(?C)D' if a given patter is 'ABCD' then the RegEx
> > engine
> > + * will parse ABC perform a userdefined callout and return a successful
> match
> > at
> > + * D.
> > + *
> > + * @see struct rte_regexdev_info::regexdev_capa
> > + */
> > +
> > +#define RTE_REGEXDEV_SUPP_PCRE_BACKREFERENCE_F (1ULL << 5)
> > +/**< RegEx device support PCRE backreference.
> > + * Example RegEx is '(\2ABC|(GHI))+' \2 matches the same text as most
> > recently
> > + * matched by the 2nd capturing group i.e. 'GHI'.
> > + *
> > + * @see struct rte_regexdev_info::regexdev_capa
> > + */
> > +
> > +#define RTE_REGEXDEV_SUPP_PCRE_GREEDY_F (1ULL << 6)
> > +/**< RegEx device support PCRE Greedy mode.
> > + * For example if the RegEx is 'AB\d*?' then '*?' represents zero or
> unlimited
> > + * matches. In greedy mode the pattern 'AB12345' will be matched
> > completely
> > + * where as the ungreedy mode 'AB' will be returned as the match.
> > + *
> > + * @see struct rte_regexdev_info::regexdev_capa
> > + */
> > +
> > +#define RTE_REGEXDEV_SUPP_PCRE_MATCH_ALL_F (1ULL << 7)
> > +/**< RegEx device support match all mode.
> > + * For example if the RegEx is 'AB\d*?' then '*?' represents zero or
> unlimited
> > + * matches. In match all mode the pattern 'AB12345' will return 6 matches.
> > + * AB, AB1, AB12, AB123, AB1234, AB12345.
> > + *
> > + * @see struct rte_regexdev_info::regexdev_capa
> > + */
> > +
> > +#define RTE_REGEXDEV_SUPP_PCRE_LOOKAROUND_ASRT_F (1ULL << 8)
> > +/**< RegEx device support PCRE Lookaround assertions
> > + * (Zero-width assertions). Example RegEx is '[a-z]+\d+(?=!{3,})' if
> > + * the given pattern is 'dwad1234!' the RegEx engine doesn't report any
> > matches
> > + * because the assert '(?=!{3,})' fails. The pattern 'dwad123!!!' would return
> a
> > + * successful match.
> > + *
> > + * @see struct rte_regexdev_info::regexdev_capa
> > + */
> > +
> > +#define RTE_REGEXDEV_SUPP_PCRE_MATCH_POINT_RST_F (1ULL << 9)
> > +/**< RegEx device doesn't support PCRE match point reset directive.
> > + * Example RegEx is '[a-z]+\K\d+' if the pattern is 'dwad123'
> > + * then even though the entire pattern matches only '123'
> > + * is reported as a match.
> > + *
> > + * @see struct rte_regexdev_info::regexdev_capa
> > + */
> > +
> > +#define RTE_REGEXDEV_SUPP_NEWLINE_CONVENTIONS_F (1ULL << 10)
> > +/**< RegEx support PCRE newline convention.
> > + * Newline conventions are represented as follows:
> > + * (*CR)        carriage return
> > + * (*LF)        linefeed
> > + * (*CRLF)      carriage return, followed by linefeed
> > + * (*ANYCRLF)   any of the three above
> > + * (*ANY)       all Unicode newline sequences
> > + *
> > + * @see struct rte_regexdev_info::regexdev_capa
> > + */
> > +
> > +#define RTE_REGEXDEV_SUPP_PCRE_NEWLINE_SEQ_F (1ULL << 11)
> > +/**< RegEx device support PCRE newline sequence.
> > + * The escape sequence '\R' will match any newline sequence.
> > + * It is equivalent to: '(?>\r\n|\n|\x0b|\f|\r|\x85)'.
> > + *
> > + * @see struct rte_regexdev_info::regexdev_capa
> > + */
> > +
> > +#define RTE_REGEXDEV_SUPP_PCRE_POSSESSIVE_QUALIFIERS_F (1ULL <<
> 12)
> > +/**< RegEx device support PCRE possessive qualifiers.
> > + * Example RegEx possessive qualifiers '*+', '++', '?+', '{m,n}+'.
> > + * Possessive quantifier repeats the token as many times as possible and it
> > does
> > + * not give up matches as the engine backtracks. With a possessive
> quantifier,
> > + * the deal is all or nothing.
> > + *
> > + * @see struct rte_regexdev_info::regexdev_capa
> > + */
> > +
> > +#define RTE_REGEXDEV_SUPP_PCRE_SUBROUTINE_REFERENCES_F (1ULL
> <<
> > 13)
> > +/**< RegEx device support PCRE Subroutine references.
> > + * PCRE Subroutine references allow for sub patterns to be assessed
> > + * as part of the RegEx. Example RegEx is '(foo|fuzz)\g<1>+bar' matches the
> > + * pattern 'foofoofuzzfoofuzzbar'.
> > + *
> > + * @see struct rte_regexdev_info::regexdev_capa
> > + */
> > +
> > +#define RTE_REGEXDEV_SUPP_PCRE_UTF_8_F (1ULL << 14)
> > +/**< RegEx device support UTF-8 character encoding.
> > + *
> > + * @see struct rte_regexdev_info::pcre_unsup_flags
> > + */
> > +
> > +#define RTE_REGEXDEV_SUPP_PCRE_UTF_16_F (1ULL << 15)
> > +/**< RegEx device support UTF-16 character encoding.
> > + *
> > + * @see struct rte_regexdev_info::regexdev_capa
> > + */
> > +
> > +#define RTE_REGEXDEV_SUPP_PCRE_UTF_32_F (1ULL << 16)
> > +/**< RegEx device support UTF-32 character encoding.
> > + *
> > + * @see struct rte_regexdev_info::regexdev_capa
> > + */
> > +
> > +#define RTE_REGEXDEV_SUPP_PCRE_WORD_BOUNDARY_F (1ULL << 17)
> > +/**< RegEx device support word boundaries.
> > + * The meta character '\b' represents word boundary anchor.
> > + *
> > + * @see struct rte_regexdev_info::regexdev_capa
> > + */
> > +
> > +#define RTE_REGEXDEV_SUPP_PCRE_FORWARD_REFERENCES_F (1ULL <<
> 18)
> > +/**< RegEx device support Forward references.
> > + * Forward references allow you to use a back reference to a group that
> > appears
> > + * later in the RegEx. Example RegEx is '(\3ABC|(DEF|(GHI)))+' matches the
> > + * following string 'GHIGHIABCDEF'.
> > + *
> > + * @see struct rte_regexdev_info::regexdev_capa
> > + */
> > +
> > +#define RTE_REGEXDEV_SUPP_MATCH_AS_END_F (1ULL << 19)
> > +/**< RegEx device support match as end.
> > + * Match as end means that the match result holds the end offset of the
> > + * detected match. No len value is set.
> > + * If the device doesn't support this feature it means the match
> > + * result holds the starting position of match and the length of the match.
> > + *
> > + * @see struct rte_regexdev_info::regexdev_capa
> > + */
> > +
> > +#define RTE_REGEXDEV_SUPP_CROSS_BUFFER_F (1ULL << 20)
> > +/**< RegEx device support cross buffer match.
> > + * Cross buffer matching means that the match can be detected even if the
> > + * string was started in previous buffer.
> > + * In case the device is configured as RTE_REGEXDEV_CFG_MATCH_AS_END
> > + * the end offset will be relative for the first packet.
> > + * For example RegEx is ABC the first buffer is xxxx second buffer yyyA and
> > + * the last buffer BCzz.
> > + * In case the match as end is configured the end offset will be 10.
> > + *
> > + * @see RTE_REGEXDEV_CFG_MATCH_AS_END_F
> > + * @see RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F
> > + * @see RTE_REGEX_OPS_RSP_PMI_SOJ_F
> > + * @see RTE_REGEX_OPS_RSP_PMI_EOJ_F
> > + */
> > +
> > +#define RTE_REGEXDEV_SUPP_MATCH_ALL_F (1ULL << 21)
> > +/**< RegEx device support match all.
> > + * Match all means that the RegEx engine will return all possible matches.
> > + * For example, assume the RegEx is 'A+b', given the input AAAb the
> > + * returned matches will be: Ab, AAb and AAAb.
> > + *
> > + * @see RTE_REGEXDEV_CFG_MATCH_ALL_F
> > + */
> > +
> > +/* Enumerates PCRE rule flags */
> > +#define RTE_REGEX_PCRE_RULE_ALLOW_EMPTY_F (1ULL << 0)
> > +/**< When this flag is set, the pattern that can match against an empty
> string,
> > + * such as '.*' are allowed.
> > + *
> > + * @see struct rte_regexdev_info::rule_flags
> > + * @see struct rte_regexdev_rule::rule_flags
> > + */
> > +
> > +#define RTE_REGEX_PCRE_RULE_ANCHORED_F (1ULL << 1)
> > +/**< When this flag is set, the pattern is forced to be "anchored", that is, it
> > + * is constrained to match only at the first matching point in the string that
> > + * is being searched. Similar to '^' and represented by \A.
> > + *
> > + * @see struct rte_regexdev_info::rule_flags
> > + * @see struct rte_regexdev_rule::rule_flags
> > + */
> > +
> > +#define RTE_REGEX_PCRE_RULE_CASELESS_F (1ULL << 2)
> > +/**< When this flag is set, letters in the pattern match both upper and lower
> > + * case letters in the subject.
> > + *
> > + * @see struct rte_regexdev_info::rule_flags
> > + * @see struct rte_regexdev_rule::rule_flags
> > + */
> > +
> > +#define RTE_REGEX_PCRE_RULE_DOTALL_F (1ULL << 3)
> > +/**< When this flag is set, a dot metacharacter in the pattern matches any
> > + * character, including one that indicates a newline.
> > + *
> > + * @see struct rte_regexdev_info::rule_flags
> > + * @see struct rte_regexdev_rule::rule_flags
> > + */
> > +
> > +#define RTE_REGEX_PCRE_RULE_DUPNAMES_F (1ULL << 4)
> > +/**< When this flag is set, names used to identify capture groups need not
> be
> > + * unique.
> > + *
> > + * @see struct rte_regexdev_info::rule_flags
> > + * @see struct rte_regexdev_rule::rule_flags
> > + */
> > +
> > +#define RTE_REGEX_PCRE_RULE_EXTENDED_F (1ULL << 5)
> > +/**< When this flag is set, most white space characters in the pattern are
> > + * totally ignored except when escaped or inside a character class.
> > + *
> > + * @see struct rte_regexdev_info::rule_flags
> > + * @see struct rte_regexdev_rule::rule_flags
> > + */
> > +
> > +#define RTE_REGEX_PCRE_RULE_MATCH_UNSET_BACKREF_F (1ULL << 6)
> > +/**< When this flag is set, a backreference to an unset capture group
> matches
> > an
> > + * empty string.
> > + *
> > + * @see struct rte_regexdev_info::rule_flags
> > + * @see struct rte_regexdev_rule::rule_flags
> > + */
> > +
> > +#define RTE_REGEX_PCRE_RULE_MULTILINE_F (1ULL << 7)
> > +/**< When this flag  is set, the '^' and '$' constructs match immediately
> > + * following or immediately before internal newlines in the subject string,
> > + * respectively, as well as at the very start and end.
> > + *
> > + * @see struct rte_regexdev_info::rule_flags
> > + * @see struct rte_regexdev_rule::rule_flags
> > + */
> > +
> > +#define RTE_REGEX_PCRE_RULE_NO_AUTO_CAPTURE_F (1ULL << 8)
> > +/**< When this Flag is set, it disables the use of numbered capturing
> > + * parentheses in the pattern. References to capture groups (backreferences
> > or
> > + * recursion/subroutine calls) may only refer to named groups, though the
> > + * reference can be by name or by number.
> > + *
> > + * @see struct rte_regexdev_info::rule_flags
> > + * @see struct rte_regexdev_rule::rule_flags
> > + */
> > +
> > +#define RTE_REGEX_PCRE_RULE_UCP_F (1ULL << 9)
> > +/**< By default, only ASCII characters are recognized, When this flag is set,
> > + * Unicode properties are used instead to classify characters.
> > + *
> > + * @see struct rte_regexdev_info::rule_flags
> > + * @see struct rte_regexdev_rule::rule_flags
> > + */
> > +
> > +#define RTE_REGEX_PCRE_RULE_UNGREEDY_F (1ULL << 10)
> > +/**< When this flag is set, the "greediness" of the quantifiers is inverted
> > + * so that they are not greedy by default, but become greedy if followed by
> > + * '?'.
> > + *
> > + * @see struct rte_regexdev_info::rule_flags
> > + * @see struct rte_regexdev_rule::rule_flags
> > + */
> > +
> > +#define RTE_REGEX_PCRE_RULE_UTF_F (1ULL << 11)
> > +/**< When this flag is set, RegEx engine has to regard both the pattern and
> > the
> > + * subject strings that are subsequently processed as strings of UTF
> characters
> > + * instead of single-code-unit strings.
> > + *
> > + * @see struct rte_regexdev_info::rule_flags
> > + * @see struct rte_regexdev_rule::rule_flags
> > + */
> > +
> > +#define RTE_REGEX_PCRE_RULE_NEVER_BACKSLASH_C_F (1ULL << 12)
> > +/**< This flag locks out the use of '\C' in the pattern that is being compiled.
> > + * This escape matches one data unit, even in UTF mode which can cause
> > + * unpredictable behavior in UTF-8 or UTF-16 modes, because it may leave
> the
> > + * current matching point in the mi:set hlsearchddle of a multi-code-unit
> > + * character.
> > + *
> > + * @see struct rte_regexdev_info::rule_flags
> > + * @see struct rte_regexdev_rule::rule_flags
> > + */
> > +
> > +/**
> > + * RegEx device information
> > + */
> > +struct rte_regexdev_info {
> > +	const char *driver_name; /**< RegEx driver name. */
> > +	struct rte_device *dev;	/**< Device information. */
> > +	uint16_t max_matches;
> > +	/**< Maximum matches per scan supported by this device. */
> > +	uint16_t max_queue_pairs;
> > +	/**< Maximum queue pairs supported by this device. */
> > +	uint16_t max_payload_size;
> > +	/**< Maximum payload size for a pattern match request or scan.
> > +	 * @see RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F
> > +	 */
> > +	uint32_t max_rules_per_group;
> > +	/**< Maximum rules supported per group by this device. */
> > +	uint16_t max_groups;
> > +	/**< Maximum groups supported by this device. */
> > +	uint32_t regexdev_capa;
> > +	/**< RegEx device capabilities. @see RTE_REGEXDEV_CAPA_* */
> > +	uint64_t rule_flags;
> > +	/**< Supported compiler rule flags.
> > +	 * @see RTE_REGEX_PCRE_RULE_*, struct
> > rte_regexdev_rule::rule_flags
> > +	 */
> > +};
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice.
> > + *
> > + * Retrieve the contextual information of a RegEx device.
> > + *
> > + * @param dev_id
> > + *   The identifier of the device.
> > + *
> > + * @param[out] dev_info
> > + *   A pointer to a structure of type *rte_regexdev_info* to be filled with the
> > + *   contextual information of the device.
> > + *
> > + * @return
> > + *   - 0: Success, driver updates the contextual information of the RegEx
> device
> > + *   - <0: Error code returned by the driver info get function.
> > + */
> > +__rte_experimental
> > +int
> > +rte_regexdev_info_get(uint8_t dev_id, struct rte_regexdev_info *dev_info);
> > +
> > +/* Enumerates RegEx device configuration flags */
> > +#define RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F (1ULL << 0)
> > +/**< Cross buffer scan refers to the ability to be able to detect
> > + * matches that occur across buffer boundaries, where the buffers are
> related
> > + * to each other in some way. Enable this flag when to scan payload size
> > + * greater than struct rte_regexdev_info::max_payload_size and/or
> > + * matches can present across scan buffer boundaries.
> > + *
> > + * @see struct rte_regexdev_info::max_payload_size
> > + * @see struct rte_regexdev_config::dev_cfg_flags,
> rte_regexdev_configure()
> > + * @see RTE_REGEX_OPS_RSP_PMI_SOJ_F
> > + * @see RTE_REGEX_OPS_RSP_PMI_EOJ_F
> > + */
> > +
> > +#define RTE_REGEXDEV_CFG_MATCH_AS_END_F (1ULL << 1)
> > +/**< Match as end is the ability to return the result as ending offset.
> > + * When this flag is set, the result for each match will hold the ending
> > + * offset of the match in end_offset.
> > + * If this flag is not set, then the match result will hold the starting offset
> > + * in start_offset, and the length of the match in len.
> > + *
> > + * @see RTE_REGEXDEV_SUPP_MATCH_AS_END_F
> > + */
> > +
> > +#define RTE_REGEXDEV_CFG_MATCH_ALL_F (1ULL << 2)
> > +/**< Match all is the ability to return all possible results.
> > + *
> > + * @see RTE_REGEXDEV_SUPP_MATCH_ALL_F
> > + */
> > +
> > +/** RegEx device configuration structure */
> > +struct rte_regexdev_config {
> > +	uint16_t nb_max_matches;
> > +	/**< Maximum matches per scan configured on this device.
> > +	 * This value cannot exceed the *max_matches*
> > +	 * which previously provided in rte_regexdev_info_get().
> > +	 * The value 0 is allowed, in which case, value 1 used.
> > +	 * @see struct rte_regexdev_info::max_matches
> > +	 */
> > +	uint16_t nb_queue_pairs;
> > +	/**< Number of RegEx queue pairs to configure on this device.
> > +	 * This value cannot exceed the *max_queue_pairs* which previously
> > +	 * provided in rte_regexdev_info_get().
> > +	 * @see struct rte_regexdev_info::max_queue_pairs
> > +	 */
> > +	uint32_t nb_rules_per_group;
> > +	/**< Number of rules per group to configure on this device.
> > +	 * This value cannot exceed the *max_rules_per_group*
> > +	 * which previously provided in rte_regexdev_info_get().
> > +	 * The value 0 is allowed, in which case,
> > +	 * struct rte_regexdev_info::max_rules_per_group used.
> > +	 * @see struct rte_regexdev_info::max_rules_per_group
> > +	 */
> > +	uint16_t nb_groups;
> > +	/**< Number of groups to configure on this device.
> > +	 * This value cannot exceed the *max_groups*
> > +	 * which previously provided in rte_regexdev_info_get().
> > +	 * @see struct rte_regexdev_info::max_groups
> > +	 */
> > +	const char *rule_db;
> > +	/**< Import initial set of prebuilt rule database on this device.
> > +	 * The value NULL is allowed, in which case, the device will not
> > +	 * be configured prebuilt rule database. Application may use
> > +	 * rte_regexdev_rule_db_update() or rte_regexdev_rule_db_import()
> > API
> > +	 * to update or import rule database after the
> > +	 * rte_regexdev_configure().
> > +	 * @see rte_regexdev_rule_db_update(),
> > rte_regexdev_rule_db_import()
> > +	 */
> > +	uint32_t rule_db_len;
> > +	/**< Length of *rule_db* buffer. */
> > +	uint32_t dev_cfg_flags;
> > +	/**< RegEx device configuration flags, See RTE_REGEXDEV_CFG_*  */
> > +};
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice.
> > + *
> > + * Configure a RegEx device.
> > + *
> > + * This function must be invoked first before any other function in the
> > + * API. This function can also be re-invoked when a device is in the
> > + * stopped state.
> > + *
> > + * The caller may use rte_regexdev_info_get() to get the capability of each
> > + * resources available for this regex device.
> > + *
> > + * @param dev_id
> > + *   The identifier of the device to configure.
> > + * @param cfg
> > + *   The RegEx device configuration structure.
> > + *
> > + * @return
> > + *   - 0: Success, device configured. Otherwise negative errno is returned.
> > + */
> > +__rte_experimental
> > +int
> > +rte_regexdev_configure(uint8_t dev_id, const struct rte_regexdev_config
> > *cfg);
> > +
> > +/* Enumerates RegEx queue pair configuration flags */
> > +#define RTE_REGEX_QUEUE_PAIR_CFG_OOS_F (1ULL << 0)
> > +/**< Out of order scan, If not set, a scan must retire after previously issued
> > + * in-order scans to this queue pair. If set, this scan can be retired as soon
> > + * as device returns completion. Application should not set out of order scan
> > + * flag if it needs to maintain the ingress order of scan request.
> > + *
> > + * @see struct rte_regexdev_qp_conf::qp_conf_flags
> > + * @see rte_regexdev_queue_pair_setup()
> > + */
> > +
> > +struct rte_regex_ops;
> > +typedef void (*regexdev_stop_flush_t)(uint8_t dev_id, uint16_t qp_id,
> > +				      struct rte_regex_ops *op);
> > +/**< Callback function called during rte_regexdev_stop(), invoked once per
> > + * flushed RegEx op.
> > + */
> > +
> > +/** RegEx queue pair configuration structure */
> > +struct rte_regexdev_qp_conf {
> > +	uint32_t qp_conf_flags;
> > +	/**< Queue pair config flags, See RTE_REGEX_QUEUE_PAIR_CFG_* */
> > +	uint16_t nb_desc;
> > +	/**< The number of descriptors to allocate for this queue pair. */
> > +	regexdev_stop_flush_t cb;
> > +	/**< Callback function called during rte_regexdev_stop(), invoked
> > +	 * once per flushed regex op. Value NULL is allowed, in which case
> > +	 * callback will not be invoked. This function can be used to properly
> > +	 * dispose of outstanding regex ops from response queue,
> > +	 * for example ops containing memory pointers.
> > +	 * @see rte_regexdev_stop()
> > +	 */
> > +};
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice.
> > + *
> > + * Allocate and set up a RegEx queue pair for a RegEx device.
> > + *
> > + * @param dev_id
> > + *   The identifier of the device.
> > + * @param queue_pair_id
> > + *   The index of the RegEx queue pair to setup. The value must be in the
> > range
> > + *   [0, nb_queue_pairs - 1] previously supplied to rte_regexdev_configure().
> > + * @param qp_conf
> > + *   The pointer to the configuration data to be used for the RegEx queue
> pair.
> > + *   NULL value is allowed, in which case default configuration	used.
> > + *
> > + * @return
> > + *   0 on success. Otherwise negative errno is returned.
> > + */
> > +__rte_experimental
> > +int
> > +rte_regexdev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
> > +			      const struct rte_regexdev_qp_conf *qp_conf);
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice.
> > + *
> > + * Start a RegEx device.
> > + *
> > + * The device start step is the last one and consists of setting the RegEx
> > + * queues to start accepting the pattern matching scan requests.
> > + *
> > + * On success, all basic functions exported by the API (RegEx enqueue,
> > + * RegEx dequeue and so on) can be invoked.
> > + *
> > + * @param dev_id
> > + *   RegEx device identifier.
> > + *
> > + * @return
> > + *   0 on success. Otherwise negative errno is returned.
> > + */
> > +__rte_experimental
> > +int
> > +rte_regexdev_start(uint8_t dev_id);
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice.
> > + *
> > + * Stop a RegEx device.
> > + *
> > + * Stop a RegEx device. The device can be restarted with a call to
> > + * rte_regexdev_start().
> > + *
> > + * This function causes all queued response regex ops to be drained in the
> > + * response queue. While draining ops out of the device,
> > + * struct rte_regexdev_qp_conf::cb will be invoked for each ops.
> > + *
> > + * @param dev_id
> > + *   RegEx device identifier.
> > + *
> > + * @see struct rte_regexdev_qp_conf::cb, rte_regexdev_queue_pair_setup()
> > + */
> > +__rte_experimental
> > +void
> > +rte_regexdev_stop(uint8_t dev_id);
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice.
> > + *
> > + * Close a RegEx device. The device cannot be restarted!
> > + *
> > + * @param dev_id
> > + *   RegEx device identifier
> > + *
> > + * @return
> > + *   0 on success. Otherwise negative errno is returned.
> > + */
> > +__rte_experimental
> > +int
> > +rte_regexdev_close(uint8_t dev_id);
> > +
> > +/* Device get/set attributes */
> > +
> > +/** Enumerates RegEx device attribute identifier */
> > +enum rte_regexdev_attr_id {
> > +	RTE_REGEXDEV_ATTR_SOCKET_ID,
> > +	/**< The NUMA socket id to which the device is connected or
> > +	 * a default of zero if the socket could not be determined.
> > +	 * datatype: *int*
> > +	 * operation: *get*
> > +	 */
> > +	RTE_REGEXDEV_ATTR_MAX_MATCHES,
> > +	/**< Maximum number of matches per scan.
> > +	 * datatype: *uint8_t*
> > +	 * operation: *get* and *set*
> > +	 * @see RTE_REGEX_OPS_RSP_MAX_MATCH_F
> > +	 */
> > +	RTE_REGEXDEV_ATTR_MAX_SCAN_TIMEOUT,
> > +	/**< Upper bound scan time in ns.
> > +	 * datatype: *uint16_t*
> > +	 * operation: *get* and *set*
> > +	 * @see RTE_REGEX_OPS_RSP_MAX_SCAN_TIMEOUT_F
> > +	 */
> > +	RTE_REGEXDEV_ATTR_MAX_PREFIX,
> > +	/**< Maximum number of prefix detected per scan.
> > +	 * This would be useful for denial of service detection.
> > +	 * datatype: *uint16_t*
> > +	 * operation: *get* and *set*
> > +	 * @see RTE_REGEX_OPS_RSP_MAX_PREFIX_F
> > +	 */
> > +};
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice.
> > + *
> > + * Get an attribute from a RegEx device.
> > + *
> > + * @param dev_id
> > + *   RegEx device identifier.
> > + * @param attr_id
> > + *   The attribute ID to retrieve.
> > + * @param attr_value
> > + *   A pointer that will be filled in with the attribute
> > + *   value if successful.
> > + *
> > + * @return
> > + *   - 0: Successfully retrieved attribute value.
> > + *   - -EINVAL: Invalid device or  *attr_id* provided, or *attr_value* is NULL.
> > + *   - -ENOTSUP: if the device doesn't support specific *attr_id*.
> > + */
> > +__rte_experimental
> > +int
> > +rte_regexdev_attr_get(uint8_t dev_id, enum rte_regexdev_attr_id attr_id,
> > +		      void *attr_value);
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice.
> > + *
> > + * Set an attribute to a RegEx device.
> > + *
> > + * @param dev_id
> > + *   RegEx device identifier.
> > + * @param attr_id
> > + *   The attribute ID to retrieve.
> > + * @param attr_value
> > + *   Pointer that will be filled in with the attribute value
> > + *   by the application.
> > + *
> > + * @return
> > + *   - 0: Successfully applied the attribute value.
> > + *   - -EINVAL: Invalid device or  *attr_id* provided, or *attr_value* is NULL.
> > + *   - -ENOTSUP: if the device doesn't support specific *attr_id*.
> > + */
> > +__rte_experimental
> > +int
> > +rte_regexdev_attr_set(uint8_t dev_id, enum rte_regexdev_attr_id attr_id,
> > +		      const void *attr_value);
> > +
> > +/* Rule related APIs */
> > +/** Enumerates RegEx rule operation. */
> > +enum rte_regexdev_rule_op {
> > +	RTE_REGEX_RULE_OP_ADD,
> > +	/**< Add RegEx rule to rule database. */
> > +	RTE_REGEX_RULE_OP_REMOVE
> > +	/**< Remove RegEx rule from rule database. */
> > +};
> > +
> > +/** Structure to hold a RegEx rule attributes. */
> > +struct rte_regexdev_rule {
> > +	enum rte_regexdev_rule_op op;
> > +	/**< OP type of the rule either a OP_ADD or OP_DELETE. */
> > +	uint16_t group_id;
> > +	/**< Group identifier to which the rule belongs to. */
> > +	uint32_t rule_id;
> > +	/**< Rule identifier which is returned on successful match. */
> > +	const char *pcre_rule;
> > +	/**< Buffer to hold the PCRE rule. */
> > +	uint16_t pcre_rule_len;
> > +	/**< Length of the PCRE rule. */
> > +	uint64_t rule_flags;
> > +	/* PCRE rule flags. Supported device specific PCRE rules enumerated
> > +	 * in struct rte_regexdev_info::rule_flags. For successful rule
> > +	 * database update, application needs to provide only supported
> > +	 * rule flags.
> > +	 * @See RTE_REGEX_PCRE_RULE_*, struct
> > rte_regexdev_info::rule_flags
> > +	 */
> > +};
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice.
> > + *
> > + * Update the local rule set.
> > + * This functions only modify the rule set in memory.
> > + * In order for the changes to take effect, the function
> > + * rte_regexdev_rule_db_compile_active must be called.
> > + *
> > + * @param dev_id
> > + *   RegEx device identifier.
> > + * @param rules
> > + *   Points to an array of *nb_rules* objects of type *rte_regexdev_rule*
> > + *   structure which contain the regex rules attributes to be updated
> > + *   in rule database.
> > + * @param nb_rules
> > + *   The number of PCRE rules to update the rule database.
> > + *
> > + * @return
> > + *   The number of regex rules actually updated on the regex device's rule
> > + *   database. The return value can be less than the value of the *nb_rules*
> > + *   parameter when the regex devices fails to update the rule database or
> > + *   if invalid parameters are specified in a *rte_regexdev_rule*.
> > + *   If the return value is less than *nb_rules*, the remaining PCRE rules
> > + *   at the end of *rules* are not consumed and the caller has to take
> > + *   care of them and rte_errno is set accordingly.
> > + *   Possible errno values include:
> > + *   - -EINVAL:  Invalid device ID or rules is NULL
> > + *   - -ENOTSUP: The last processed rule is not supported on this device.
> > + *   - -ENOSPC: No space available in rule database.
> > + *
> > + * @see rte_regexdev_rule_db_import(), rte_regexdev_rule_db_export(),
> > + *   rte_regexdev_rule_db_compile_activate()
> > + */
> > +__rte_experimental
> > +int
> > +rte_regexdev_rule_db_update(uint8_t dev_id,
> > +			    const struct rte_regexdev_rule *rules,
> > +			    uint32_t nb_rules);
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice.
> > + *
> > + * Compile local rule set and burn the complied result to the
> > + * RegEx deive.
> > + *
> > + * @param dev_id
> > + *   RegEx device identifier.
> > + *
> > + * @return
> > + *   0 on success, otherwise negative errno.
> > + *
> > + * @see rte_regexdev_rule_db_import(), rte_regexdev_rule_db_export(),
> > + *   rte_regexdev_rule_db_update()
> > + */
> > +__rte_experimental
> > +int
> > +rte_regexdev_rule_db_compile_activate(uint8_t dev_id);
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice.
> > + *
> > + * Import a prebuilt rule database from a buffer to a RegEx device.
> > + *
> > + * @param dev_id
> > + *   RegEx device identifier.
> > + * @param rule_db
> > + *   Points to prebuilt rule database.
> > + * @param rule_db_len
> > + *   Length of the rule database.
> > + *
> > + * @return
> > + *   - 0: Successfully updated the prebuilt rule database.
> > + *   - -EINVAL:  Invalid device ID or rule_db is NULL
> > + *   - -ENOTSUP: Rule database import is not supported on this device.
> > + *   - -ENOSPC: No space available in rule database.
> > + *
> > + * @see rte_regexdev_rule_db_update(), rte_regexdev_rule_db_export()
> > + */
> > +__rte_experimental
> > +int
> > +rte_regexdev_rule_db_import(uint8_t dev_id, const char *rule_db,
> > +			    uint32_t rule_db_len);
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice.
> > + *
> > + * Export the prebuilt rule database from a RegEx device to the buffer.
> > + *
> > + * @param dev_id
> > + *   RegEx device identifier.
> > + * @param[out] rule_db
> > + *   Block of memory to insert the rule database. Must be at least size in
> > + *   capacity. If set to NULL, function returns required capacity.
> > + *
> > + * @return
> > + *   - 0: Successfully exported the prebuilt rule database.
> > + *   - size: If rule_db set to NULL then required capacity for *rule_db*
> > + *   - -EINVAL:  Invalid device ID
> > + *   - -ENOTSUP: Rule database export is not supported on this device.
> > + *
> > + * @see rte_regexdev_rule_db_update(), rte_regexdev_rule_db_import()
> > + */
> > +__rte_experimental
> > +int
> > +rte_regexdev_rule_db_export(uint8_t dev_id, char *rule_db);
> > +
> > +/* Extended statistics */
> > +/** Maximum name length for extended statistics counters */
> > +#define RTE_REGEXDEV_XSTATS_NAME_SIZE 64
> > +
> > +/**
> > + * A name-key lookup element for extended statistics.
> > + *
> > + * This structure is used to map between names and ID numbers
> > + * for extended RegEx device statistics.
> > + */
> > +struct rte_regexdev_xstats_map {
> > +	uint16_t id;
> > +	/**< xstat identifier */
> > +	char name[RTE_REGEXDEV_XSTATS_NAME_SIZE];
> > +	/**< xstat name */
> > +};
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice.
> > + *
> > + * Retrieve names of extended statistics of a regex device.
> > + *
> > + * @param dev_id
> > + *   The identifier of the regex device.
> > + * @param[out] xstats_map
> > + *   Block of memory to insert id and names into. Must be at least size in
> > + *   capacity. If set to NULL, function returns required capacity.
> > + * @return
> > + *   - Positive value on success:
> > + *        -The return value is the number of entries filled in the stats map.
> > + *        -If xstats_map set to NULL then required capacity for xstats_map.
> > + *   - Negative value on error:
> > + *      -ENODEV for invalid *dev_id*
> > + *      -ENOTSUP if the device doesn't support this function.
> > + */
> > +__rte_experimental
> > +int
> > +rte_regexdev_xstats_names_get(uint8_t dev_id,
> > +			      struct rte_regexdev_xstats_map *xstats_map);
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice.
> > + *
> > + * Retrieve extended statistics of an regex device.
> > + *
> > + * @param dev_id
> > + *   The identifier of the device.
> > + * @param ids
> > + *   The id numbers of the stats to get. The ids can be got from the stat
> > + *   position in the stat list from rte_regexdev_xstats_names_get(), or
> > + *   by using rte_regexdev_xstats_by_name_get().
> > + * @param values
> > + *   The values for each stats request by ID.
> > + * @param nb_values
> > + *   The number of stats requested.
> > + * @return
> > + *   - Positive value: number of stat entries filled into the values array
> > + *   - Negative value on error:
> > + *      -ENODEV for invalid *dev_id*
> > + *      -ENOTSUP if the device doesn't support this function.
> > + */
> > +__rte_experimental
> > +int
> > +rte_regexdev_xstats_get(uint8_t dev_id, const uint16_t *ids,
> > +			uint64_t *values, uint16_t nb_values);
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice.
> > + *
> > + * Retrieve the value of a single stat by requesting it by name.
> > + *
> > + * @param dev_id
> > + *   The identifier of the device.
> > + * @param name
> > + *   The stat name to retrieve.
> > + * @param id
> > + *   If non-NULL, the numerical id of the stat will be returned, so that further
> > + *   requests for the stat can be got using rte_regexdev_xstats_get, which
> will
> > + *   be faster as it doesn't need to scan a list of names for the stat.
> > + * @param[out] value
> > + *   Must be non-NULL, retrieved xstat value will be stored in this address.
> > + *
> > + * @return
> > + *   - 0: Successfully retrieved xstat value.
> > + *   - -EINVAL: invalid parameters
> > + *   - -ENOTSUP: if not supported.
> > + */
> > +__rte_experimental
> > +int
> > +rte_regexdev_xstats_by_name_get(uint8_t dev_id, const char *name,
> > +				uint16_t *id, uint64_t *value);
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice.
> > + *
> > + * Reset the values of the xstats of the selected component in the device.
> > + *
> > + * @param dev_id
> > + *   The identifier of the device.
> > + * @param ids
> > + *   Selects specific statistics to be reset. When NULL, all statistics will be
> > + *   reset. If non-NULL, must point to array of at least *nb_ids* size.
> > + * @param nb_ids
> > + *   The number of ids available from the *ids* array. Ignored when ids is
> > NULL.
> > + *
> > + * @return
> > + *   - 0: Successfully reset the statistics to zero.
> > + *   - -EINVAL: invalid parameters.
> > + *   - -ENOTSUP: if not supported.
> > + */
> > +__rte_experimental
> > +int
> > +rte_regexdev_xstats_reset(uint8_t dev_id, const uint16_t *ids,
> > +			  uint16_t nb_ids);
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice.
> > + *
> > + * Trigger the RegEx device self test.
> > + *
> > + * @param dev_id
> > + *   The identifier of the device.
> > + * @return
> > + *   - 0: Selftest successful.
> > + *   - -ENOTSUP if the device doesn't support selftest.
> > + *   - other values < 0 on failure.
> > + */
> > +__rte_experimental
> > +int
> > +rte_regexdev_selftest(uint8_t dev_id);
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice.
> > + *
> > + * Dump internal information about *dev_id* to the FILE* provided in *f*.
> > + *
> > + * @param dev_id
> > + *   The identifier of the device.
> > + * @param f
> > + *   A pointer to a file for output.
> > + *
> > + * @return
> > + *   0 on success, negative errno on failure.
> > + */
> > +__rte_experimental
> > +int
> > +rte_regexdev_dump(uint8_t dev_id, FILE *f);
> > +
> > +/* Fast path APIs */
> > +
> > +/**
> > + * The generic *rte_regexdev_match* structure to hold the RegEx match
> > + * attributes.
> > + * @see struct rte_regex_ops::matches
> > + */
> > +struct rte_regexdev_match {
> > +	RTE_STD_C11
> > +	union {
> > +		uint64_t u64;
> > +		struct {
> > +			uint32_t rule_id:20;
> > +			/**< Rule identifier to which the pattern matched.
> > +			 * @see struct rte_regexdev_rule::rule_id
> > +			 */
> > +			uint32_t group_id:12;
> > +			/**< Group identifier of the rule which the pattern
> > +			 * matched. @see struct rte_regexdev_rule::group_id
> > +			 */
> > +			uint16_t start_offset;
> > +			/**< Starting Byte Position for matched rule. */
> > +			RTE_STD_C11
> > +			union {
> > +				uint16_t len;
> > +				/**< Length of match in bytes */
> > +				uint16_t end_offset;
> > +				/**< The end offset of the match. In case
> > +				 * MATCH_AS_END configuration is enabled.
> > +				 * @see
> > RTE_REGEXDEV_CFG_MATCH_AS_END
> > +				 */
> > +			};
> > +		};
> > +	};
> > +};
> > +
> > +/* Enumerates RegEx request flags. */
> > +#define RTE_REGEX_OPS_REQ_GROUP_ID0_VALID_F (1 << 0)
> > +/**< Set when struct rte_regexdev_rule::group_id0 is valid. */
> > +
> > +#define RTE_REGEX_OPS_REQ_GROUP_ID1_VALID_F (1 << 1)
> > +/**< Set when struct rte_regexdev_rule::group_id1 is valid. */
> > +
> > +#define RTE_REGEX_OPS_REQ_GROUP_ID2_VALID_F (1 << 2)
> > +/**< Set when struct rte_regexdev_rule::group_id2 is valid. */
> > +
> > +#define RTE_REGEX_OPS_REQ_GROUP_ID3_VALID_F (1 << 3)
> > +/**< Set when struct rte_regexdev_rule::group_id3 is valid. */
> > +
> > +#define RTE_REGEX_OPS_REQ_STOP_ON_MATCH_F (1 << 4)
> > +/**< The RegEx engine will stop scanning and return the first match. */
> > +
> > +#define RTE_REGEX_OPS_REQ_MATCH_HIGH_PRIORITY_F (1 << 5)
> > +/**< In High Priority mode a maximum of one match will be returned per
> > scan to
> > + * reduce the post-processing required by the application. The match with
> the
> > + * lowest Rule id, lowest start pointer and lowest match length will be
> > + * returned.
> > + *
> > + * @see struct rte_regex_ops::nb_actual_matches
> > + * @see struct rte_regex_ops::nb_matches
> > + */
> > +
> > +
> > +/* Enumerates RegEx response flags. */
> > +#define RTE_REGEX_OPS_RSP_PMI_SOJ_F (1 << 0)
> > +/**< Indicates that the RegEx device has encountered a partial match at the
> > + * start of scan in the given buffer.
> > + *
> > + * @see RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F
> > + */
> > +
> > +#define RTE_REGEX_OPS_RSP_PMI_EOJ_F (1 << 1)
> > +/**< Indicates that the RegEx device has encountered a partial match at the
> > + * end of scan in the given buffer.
> > + *
> > + * @see RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F
> > + */
> > +
> > +#define RTE_REGEX_OPS_RSP_MAX_SCAN_TIMEOUT_F (1 << 2)
> > +/**< Indicates that the RegEx device has exceeded the max timeout while
> > + * scanning the given buffer.
> > + *
> > + * @see RTE_REGEXDEV_ATTR_MAX_SCAN_TIMEOUT
> > + */
> > +
> > +#define RTE_REGEX_OPS_RSP_MAX_MATCH_F (1 << 3)
> > +/**< Indicates that the RegEx device has exceeded the max matches while
> > + * scanning the given buffer.
> > + *
> > + * @see RTE_REGEXDEV_ATTR_MAX_MATCHES
> > + */
> > +
> > +#define RTE_REGEX_OPS_RSP_MAX_PREFIX_F (1 << 4)
> > +/**< Indicates that the RegEx device has reached the max allowed prefix
> > length
> > + * while scanning the given buffer.
> > + *
> > + * @see RTE_REGEXDEV_ATTR_MAX_PREFIX
> > + */
> > +
> > +/**
> > + * The generic *rte_regex_ops* structure to hold the RegEx attributes
> > + * for enqueue and dequeue operation.
> > + */
> > +struct rte_regex_ops {
> > +	/* W0 */
> > +	uint16_t req_flags;
> > +	/**< Request flags for the RegEx ops.
> > +	 * @see RTE_REGEX_OPS_REQ_*
> > +	 */
> > +	uint16_t rsp_flags;
> > +	/**< Response flags for the RegEx ops.
> > +	 * @see RTE_REGEX_OPS_RSP_*
> > +	 */
> > +	uint16_t nb_actual_matches;
> > +	/**< The total number of actual matches detected by the Regex
> > device.*/
> > +	uint16_t nb_matches;
> > +	/**< The total number of matches returned by the RegEx device for
> > this
> > +	 * scan. The size of *rte_regex_ops::matches* zero length array will be
> > +	 * this value.
> > +	 *
> > +	 * @see struct rte_regex_ops::matches, struct rte_regexdev_match
> > +	 */
> > +
> > +	/* W1 */
> > +	struct rte_mbuf *mbuf; /**< source mbuf, to search in. */
> > +
> > +	/* W2 */
> > +	uint16_t group_id0;
> > +	/**< First group_id to match the rule against. At minimum one group
> > +	 * should be valid. Behaviour is undefined non of the groups are valid.
> > +	 *
> > +	 * @see RTE_REGEX_OPS_REQ_GROUP_ID0_VALID_F
> > +	 */
> > +	uint16_t group_id1;
> > +	/**< Second group_id to match the rule against.
> > +	 *
> > +	 * @see RTE_REGEX_OPS_REQ_GROUP_ID1_VALID_F
> > +	 */
> > +	uint16_t group_id2;
> > +	/**< Third group_id to match the rule against.
> > +	 *
> > +	 * @see RTE_REGEX_OPS_REQ_GROUP_ID2_VALID_F
> > +	 */
> > +	uint16_t group_id3;
> > +	/**< Forth group_id to match the rule against.
> > +	 *
> > +	 * @see RTE_REGEX_OPS_REQ_GROUP_ID3_VALID_F
> > +	 */
> > +
> > +	/* W3 */
> > +	RTE_STD_C11
> > +	union {
> > +		uint64_t user_id;
> > +		/**< Application specific opaque value. An application may use
> > +		 * this field to hold application specific value to share
> > +		 * between dequeue and enqueue operation.
> > +		 * Implementation should not modify this field.
> > +		 */
> > +		void *user_ptr;
> > +		/**< Pointer representation of *user_id* */
> > +	};
> > +
> > +	/* W4 */
> > +	RTE_STD_C11
> > +	union {
> > +		uint64_t cross_buf_id;
> > +		/**< ID used by the RegEx device in order to support cross
> > +		 * packet detection.
> > +		 * This ID is returned from the RegEx device on the dequeue
> > +		 * function. The application must send it back when calling
> > +		 * enqueue with the following packet.
> > +		 */
> > +		void *cross_buf_ptr;
> > +		/**< Pointer representation of *corss_buf_id* */
> > +	};
> > +
> > +	/* W5 */
> > +	struct rte_regexdev_match matches[];
> > +	/**< Zero length array to hold the match tuples.
> > +	 * The struct rte_regex_ops::nb_matches value holds the number of
> > +	 * elements in this array.
> > +	 *
> > +	 * @see struct rte_regex_ops::nb_matches
> > +	 */
> > +};
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice.
> > + *
> > + * Enqueue a burst of scan request on a RegEx device.
> > + *
> > + * The rte_regexdev_enqueue_burst() function is invoked to place
> > + * regex operations on the queue *qp_id* of the device designated by
> > + * its *dev_id*.
> > + *
> > + * The *nb_ops* parameter is the number of operations to process which
> are
> > + * supplied in the *ops* array of *rte_regexdev_op* structures.
> > + *
> > + * The rte_regexdev_enqueue_burst() function returns the number of
> > + * operations it actually enqueued for processing. A return value equal to
> > + * *nb_ops* means that all packets have been enqueued.
> > + *
> > + * @param dev_id
> > + *   The identifier of the device.
> > + * @param qp_id
> > + *   The index of the queue pair which packets are to be enqueued for
> > + *   processing. The value must be in the range [0, nb_queue_pairs - 1]
> > + *   previously supplied to rte_regexdev_configure().
> > + * @param ops
> > + *   The address of an array of *nb_ops* pointers to *rte_regexdev_op*
> > + *   structures which contain the regex operations to be processed.
> > + * @param nb_ops
> > + *   The number of operations to process.
> > + *
> > + * @return
> > + *   The number of operations actually enqueued on the regex device. The
> > return
> > + *   value can be less than the value of the *nb_ops* parameter when the
> > + *   regex devices queue is full or if invalid parameters are specified in
> > + *   a *rte_regexdev_op*. If the return value is less than *nb_ops*, the
> > + *   remaining ops at the end of *ops* are not consumed and the caller has
> > + *   to take care of them.
> > + */
> > +__rte_experimental
> > +uint16_t
> > +rte_regexdev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
> > +			   struct rte_regex_ops **ops, uint16_t nb_ops);
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice.
> > + *
> > + * Dequeue a burst of scan response from a queue on the RegEx device.
> > + * The dequeued operation are stored in *rte_regexdev_op* structures
> > + * whose pointers are supplied in the *ops* array.
> > + *
> > + * The rte_regexdev_dequeue_burst() function returns the number of ops
> > + * actually dequeued, which is the number of *rte_regexdev_op* data
> > structures
> > + * effectively supplied into the *ops* array.
> > + *
> > + * A return value equal to *nb_ops* indicates that the queue contained
> > + * at least *nb_ops* operations, and this is likely to signify that other
> > + * processed operations remain in the devices output queue. Applications
> > + * implementing a "retrieve as many processed operations as possible"
> policy
> > + * can check this specific case and keep invoking the
> > + * rte_regexdev_dequeue_burst() function until a value less than
> > + * *nb_ops* is returned.
> > + *
> > + * The rte_regexdev_dequeue_burst() function does not provide any error
> > + * notification to avoid the corresponding overhead.
> > + *
> > + * @param dev_id
> > + *   The RegEx device identifier
> > + * @param qp_id
> > + *   The index of the queue pair from which to retrieve processed packets.
> > + *   The value must be in the range [0, nb_queue_pairs - 1] previously
> > + *   supplied to rte_regexdev_configure().
> > + * @param ops
> > + *   The address of an array of pointers to *rte_regexdev_op* structures
> > + *   that must be large enough to store *nb_ops* pointers in it.
> > + * @param nb_ops
> > + *   The maximum number of operations to dequeue.
> > + *
> > + * @return
> > + *   The number of operations actually dequeued, which is the number
> > + *   of pointers to *rte_regexdev_op* structures effectively supplied to the
> > + *   *ops* array. If the return value is less than *nb_ops*, the remaining
> > + *   ops at the end of *ops* are not consumed and the caller has to take care
> > + *   of them.
> > + */
> > +__rte_experimental
> > +uint16_t
> > +rte_regexdev_dequeue_burst(uint8_t dev_id, uint16_t qp_id,
> > +			   struct rte_regex_ops **ops, uint16_t nb_ops);
> > +
> > +#ifdef __cplusplus
> > +}
> > +#endif
> > +
> > +#endif /* _RTE_REGEXDEV_H_ */
> > diff --git a/lib/librte_regexdev/rte_regexdev_version.map
> > b/lib/librte_regexdev/rte_regexdev_version.map
> > new file mode 100644
> > index 0000000..d400624
> > --- /dev/null
> > +++ b/lib/librte_regexdev/rte_regexdev_version.map
> > @@ -0,0 +1,26 @@
> > +EXPERIMENTAL {
> > +	global:
> > +
> > +	rte_regexdev_count;
> > +	rte_regexdev_get_dev_id;
> > +	rte_regexdev_info_get;
> > +	rte_regexdev_configure;
> > +	rte_regexdev_queue_pair_setup;
> > +	rte_regexdev_start;
> > +	rte_regexdev_stop;
> > +	rte_regexdev_close;
> > +	rte_regexdev_attr_get;
> > +	rte_regexdev_attr_set;
> > +	rte_regexdev_rule_db_update;
> > +	rte_regexdev_rule_db_compile_activate;
> > +	rte_regexdev_rule_db_import;
> > +	rte_regexdev_rule_db_export;
> > +	rte_regexdev_xstats_names_get;
> > +	rte_regexdev_xstats_get;
> > +	rte_regexdev_xstats_by_name_get;
> > +	rte_regexdev_xstats_reset;
> > +	rte_regexdev_selftest;
> > +	rte_regexdev_dump;
> > +	rte_regexdev_enqueue_burst;
> > +	rte_regexdev_dequeue_burst;
> > +};
> > diff --git a/lib/meson.build b/lib/meson.build
> > index 07a65a6..79ae5cb 100644
> > --- a/lib/meson.build
> > +++ b/lib/meson.build
> > @@ -24,7 +24,7 @@ libraries = [
> >  	'gro', 'gso', 'ip_frag', 'jobstats',
> >  	'kni', 'latencystats', 'lpm', 'member',
> >  	'power', 'pdump', 'rawdev',
> > -	'rib', 'reorder', 'sched', 'security', 'stack', 'vhost',
> > +	'regexdev', 'rib', 'reorder', 'sched', 'security', 'stack', 'vhost',
> >  	# ipsec lib depends on net, crypto and security
> >  	'ipsec',
> >  	#fib lib depends on rib
> > --
> > 1.8.3.1


^ permalink raw reply	[flat|nested] 96+ messages in thread

* [dpdk-dev] [PATCH v4 0/4] add RegEx class
  2020-03-29  6:47 [dpdk-dev] [PATCH v1 0/4] add RegEx class Ori Kam
                   ` (6 preceding siblings ...)
  2020-05-07  9:45 ` [dpdk-dev] [PATCH v3 0/4] add RegEx class Ori Kam
@ 2020-07-02  7:45 ` Ori Kam
  2020-07-02  7:46   ` [dpdk-dev] [PATCH v4 1/4] regexdev: introduce regexdev subsystem Ori Kam
                     ` (4 more replies)
  2020-07-06 17:36 ` [dpdk-dev] [PATCH v5 " Ori Kam
  8 siblings, 5 replies; 96+ messages in thread
From: Ori Kam @ 2020-07-02  7:45 UTC (permalink / raw)
  To: jerinj, xiang.w.wang
  Cc: guyk, dev, pbhagavatula, shahafs, hemant.agrawal, opher, alexr,
	dovrat, pkapoor, nipun.gupta, bruce.richardson, yang.a.hong,
	harry.chang, gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai,
	yuyingxia, fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc,
	jim, hongjun.ni, deri, fc, arthur.su, thomas, orika

This patch set adds the RegEx class, which enables RegEx pattern
matching, both on HW/SW PMDs.

Example for applications that will benefit from this class:
* Next Generation Firewalls (NGFW)
* Deep Packet and Flow Inspection (DPI)
* Intrusion Prevention Systems (IPS)
* DDoS Mitigation
* Network Monitoring
* Data Loss Prevention (DLP)
* Smart NICs
* Grammar based content processing
* URL, spam and adware filtering
* Advanced auditing and policing of user/application security policies
* Financial data mining - parsing of streamed financial feeds
* Application recognition.
* Dmemory introspection.
* Natural Language Processing (NLP)
* Sentiment Analysis.
* Big data databse acceleration.
* Computational storage. 

This patch set is based on RFC[1]

This class should be merged only after there is at least
one PMD that implements it. Also the test application will
be added when the first PMD is added.



[1] https://patches.dpdk.org/patch/66501/

v4:
* fix issue in patch 4 "implement regex rte level functions"

v3:
* adress ML comments.

v2:
* address ML comments.


Jerin Jacob (1):
  regexdev: introduce regexdev subsystem

Ori Kam (3):
  regexdev: add regex core h file
  regexdev: add regexdev core functions
  regexdev: implement regex rte level functions

 config/common_base                           |    8 +
 config/meson.build                           |    1 +
 doc/api/doxy-api-index.md                    |    1 +
 doc/api/doxy-api.conf.in                     |    1 +
 doc/guides/prog_guide/index.rst              |    1 +
 doc/guides/prog_guide/regexdev_lib.rst       |  177 +++
 lib/Makefile                                 |    2 +
 lib/librte_regexdev/Makefile                 |   33 +
 lib/librte_regexdev/meson.build              |   10 +
 lib/librte_regexdev/rte_regexdev.c           |  568 ++++++++++
 lib/librte_regexdev/rte_regexdev.h           | 1534 ++++++++++++++++++++++++++
 lib/librte_regexdev/rte_regexdev_core.h      |  184 +++
 lib/librte_regexdev/rte_regexdev_driver.h    |   59 +
 lib/librte_regexdev/rte_regexdev_version.map |   26 +
 lib/meson.build                              |    2 +-
 meson_options.txt                            |    2 +
 16 files changed, 2608 insertions(+), 1 deletion(-)
 create mode 100644 doc/guides/prog_guide/regexdev_lib.rst
 create mode 100644 lib/librte_regexdev/Makefile
 create mode 100644 lib/librte_regexdev/meson.build
 create mode 100644 lib/librte_regexdev/rte_regexdev.c
 create mode 100644 lib/librte_regexdev/rte_regexdev.h
 create mode 100644 lib/librte_regexdev/rte_regexdev_core.h
 create mode 100644 lib/librte_regexdev/rte_regexdev_driver.h
 create mode 100644 lib/librte_regexdev/rte_regexdev_version.map

-- 
1.8.3.1


^ permalink raw reply	[flat|nested] 96+ messages in thread

* [dpdk-dev] [PATCH v4 1/4] regexdev: introduce regexdev subsystem
  2020-07-02  7:45 ` [dpdk-dev] [PATCH v4 " Ori Kam
@ 2020-07-02  7:46   ` Ori Kam
  2020-07-05 21:18     ` Thomas Monjalon
  2020-07-02  7:46   ` [dpdk-dev] [PATCH v4 2/4] regexdev: add regex core h file Ori Kam
                     ` (3 subsequent siblings)
  4 siblings, 1 reply; 96+ messages in thread
From: Ori Kam @ 2020-07-02  7:46 UTC (permalink / raw)
  To: jerinj, xiang.w.wang
  Cc: guyk, dev, pbhagavatula, shahafs, hemant.agrawal, opher, alexr,
	dovrat, pkapoor, nipun.gupta, bruce.richardson, yang.a.hong,
	harry.chang, gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai,
	yuyingxia, fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc,
	jim, hongjun.ni, deri, fc, arthur.su, thomas, orika

From: Jerin Jacob <jerinj@marvell.com>

As RegEx usage become more used by DPDK applications, for example:
* Next Generation Firewalls (NGFW)
* Deep Packet and Flow Inspection (DPI)
* Intrusion Prevention Systems (IPS)
* DDoS Mitigation
* Network Monitoring
* Data Loss Prevention (DLP)
* Smart NICs
* Grammar based content processing
* URL, spam and adware filtering
* Advanced auditing and policing of user/application security policies
* Financial data mining - parsing of streamed financial feeds
* Application recognition.
* Dmemory introspection.
* Natural Language Processing (NLP)
* Sentiment Analysis.
* Big data databse acceleration.
* Computational storage.

Number of PMD providers started to work on HW implementation,
along side with SW implementations.

This lib adds the support for those kind of devices.

The RegEx Device API is composed of two parts:
- The application-oriented RegEx API that includes functions to setup
  a RegEx device (configure it, setup its queue pairs and start it),
  update the rule database and so on.

- The driver-oriented RegEx API that exports a function allowing
  a RegEx poll Mode Driver (PMD) to simultaneously register itself as
  a RegEx device driver.

RegEx device components and definitions:

    +-----------------+
    |                 |
    |                 o---------+    rte_regexdev_[en|de]queue_burst()
    |   PCRE based    o------+  |               |
    |  RegEx pattern  |      |  |  +--------+   |
    | matching engine o------+--+--o        |   |    +------+
    |                 |      |  |  | queue  |<==o===>|Core 0|
    |                 o----+ |  |  | pair 0 |        |      |
    |                 |    | |  |  +--------+        +------+
    +-----------------+    | |  |
           ^               | |  |  +--------+
           |               | |  |  |        |        +------+
           |               | +--+--o queue  |<======>|Core 1|
       Rule|Database       |    |  | pair 1 |        |      |
    +------+----------+    |    |  +--------+        +------+
    |     Group 0     |    |    |
    | +-------------+ |    |    |  +--------+        +------+
    | | Rules 0..n  | |    |    |  |        |        |Core 2|
    | +-------------+ |    |    +--o queue  |<======>|      |
    |     Group 1     |    |       | pair 2 |        +------+
    | +-------------+ |    |       +--------+
    | | Rules 0..n  | |    |
    | +-------------+ |    |       +--------+
    |     Group 2     |    |       |        |        +------+
    | +-------------+ |    |       | queue  |<======>|Core n|
    | | Rules 0..n  | |    +-------o pair n |        |      |
    | +-------------+ |            +--------+        +------+
    |     Group n     |
    | +-------------+ |<-------rte_regexdev_rule_db_update()
    | |             | |<-------rte_regexdev_rule_db_compile_activate()
    | | Rules 0..n  | |<-------rte_regexdev_rule_db_import()
    | +-------------+ |------->rte_regexdev_rule_db_export()
    +-----------------+

RegEx: A regular expression is a concise and flexible means for matching
strings of text, such as particular characters, words, or patterns of
characters. A common abbreviation for this is â~@~\RegExâ~@~].

RegEx device: A hardware or software-based implementation of RegEx
device API for PCRE based pattern matching syntax and semantics.

PCRE RegEx syntax and semantics specification:
http://regexkit.sourceforge.net/Documentation/pcre/pcrepattern.html

RegEx queue pair: Each RegEx device should have one or more queue pair to
transmit a burst of pattern matching request and receive a burst of
receive the pattern matching response. The pattern matching
request/response embedded in *rte_regex_ops* structure.

Rule: A pattern matching rule expressed in PCRE RegEx syntax along with
Match ID and Group ID to identify the rule upon the match.

Rule database: The RegEx device accepts regular expressions and converts
them into a compiled rule database that can then be used to scan data.
Compilation allows the device to analyze the given pattern(s) and
pre-determine how to scan for these patterns in an optimized fashion that
would be far too expensive to compute at run-time. A rule database
contains a set of rules that compiled in device specific binary form.

Match ID or Rule ID: A unique identifier provided at the time of rule
creation for the application to identify the rule upon match.

Group ID: Group of rules can be grouped under one group ID to enable
rule isolation and effective pattern matching. A unique group identifier
provided at the time of rule creation for the application to identify
the rule upon match.

Scan: A pattern matching request through *enqueue* API.

It may possible that a given RegEx device may not support all the
features
of PCRE. The application may probe unsupported features through
struct rte_regexdev_info::pcre_unsup_flags

By default, all the functions of the RegEx Device API exported by a PMD
are lock-free functions which assume to not be invoked in parallel on
different logical cores to work on the same target object. For instance,
the dequeue function of a PMD cannot be invoked in parallel on two logical
cores to operates on same RegEx queue pair. Of course, this function
can be invoked in parallel by different logical core on different queue
pair. It is the responsibility of the upper level application to
enforce this rule.

In all functions of the RegEx API, the RegEx device is
designated by an integer >= 0 named the device identifier *dev_id*

At the RegEx driver level, RegEx devices are represented by a generic
data structure of type *rte_regexdev*.
RegEx devices are dynamically registered during the PCI/SoC device
probing phase performed at EAL initialization time.
When a RegEx device is being probed, a *rte_regexdev* structure and
a new device identifier are allocated for that device. Then, the
regexdev_init() function supplied by the RegEx driver matching the
probed device is invoked to properly initialize the device.

The role of the device init function consists of resetting the hardware
or software RegEx driver implementations.

If the device init operation is successful, the correspondence between
the device identifier assigned to the new device and its associated
*rte_regexdev* structure is effectively registered.
Otherwise, both the *rte_regexdev* structure and the device identifier
are freed.

The functions exported by the application RegEx API to setup a device
designated by its device identifier must be invoked in the following
order:
    - rte_regexdev_configure()
    - rte_regexdev_queue_pair_setup()
    - rte_regexdev_start()

Then, the application can invoke, in any order, the functions
exported by the RegEx API to enqueue pattern matching job, dequeue
pattern matching response, get the stats, update the rule database,
get/set device attributes and so on

If the application wants to change the configuration (i.e. call
rte_regexdev_configure() or rte_regexdev_queue_pair_setup()), it must
call rte_regexdev_stop() first to stop the device and then do the
reconfiguration before calling rte_regexdev_start() again. The enqueue and
dequeue functions should not be invoked when the device is stopped.

Finally, an application can close a RegEx device by invoking the
rte_regexdev_close() function.

Each function of the application RegEx API invokes a specific function
of the PMD that controls the target device designated by its device
identifier.

For this purpose, all device-specific functions of a RegEx driver are
supplied through a set of pointers contained in a generic structure of
type *regexdev_ops*.
The address of the *regexdev_ops* structure is stored in the
*rte_regexdev* structure by the device init function of the RegEx driver,
which is invoked during the PCI/SoC device probing phase, as explained
earlier.

In other words, each function of the RegEx API simply retrieves the
*rte_regexdev* structure associated with the device identifier and
performs an indirect invocation of the corresponding driver function
supplied in the *regexdev_ops* structure of the *rte_regexdev*
structure.

For performance reasons, the address of the fast-path functions of the
RegEx driver is not contained in the *regexdev_ops* structure.
Instead, they are directly stored at the beginning of the *rte_regexdev*
structure to avoid an extra indirect memory access during their
invocation.

RTE RegEx device drivers do not use interrupts for enqueue or dequeue
operation. Instead, RegEx drivers export Poll-Mode enqueue and dequeue
functions to applications.

The *enqueue* operation submits a burst of RegEx pattern matching
request to the RegEx device and the *dequeue* operation gets a burst of
pattern matching response for the ones submitted through *enqueue*
operation.

Typical application utilisation of the RegEx device API will follow the
following programming flow.

- rte_regexdev_configure()
- rte_regexdev_queue_pair_setup()
- rte_regexdev_rule_db_update() Needs to invoke if precompiled rule
  database not
  provided in rte_regexdev_config::rule_db for rte_regexdev_configure()
  and/or application needs to update rule database.
- rte_regexdev_rule_db_compile_activate() Needs to invoke if
  rte_regexdev_rule_db_update function was used.
- Create or reuse exiting mempool for *rte_regex_ops* objects.
- rte_regexdev_start()
- rte_regexdev_enqueue_burst()
- rte_regexdev_dequeue_burst()

Signed-off-by: Jerin Jacob <jerinj@marvell.com>
Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
Signed-off-by: Ori Kam <orika@mellanox.com>
---
v4:
* No changes.

v3:
* No changes.

v2:
* Move unused define to other patch. 
---
 config/common_base                           |    6 +
 doc/api/doxy-api-index.md                    |    1 +
 doc/api/doxy-api.conf.in                     |    1 +
 doc/guides/prog_guide/index.rst              |    1 +
 doc/guides/prog_guide/regexdev_lib.rst       |  177 ++++
 lib/Makefile                                 |    2 +
 lib/librte_regexdev/Makefile                 |   31 +
 lib/librte_regexdev/meson.build              |    7 +
 lib/librte_regexdev/rte_regexdev.c           |    6 +
 lib/librte_regexdev/rte_regexdev.h           | 1473 ++++++++++++++++++++++++++
 lib/librte_regexdev/rte_regexdev_version.map |   26 +
 lib/meson.build                              |    2 +-
 12 files changed, 1732 insertions(+), 1 deletion(-)
 create mode 100644 doc/guides/prog_guide/regexdev_lib.rst
 create mode 100644 lib/librte_regexdev/Makefile
 create mode 100644 lib/librte_regexdev/meson.build
 create mode 100644 lib/librte_regexdev/rte_regexdev.c
 create mode 100644 lib/librte_regexdev/rte_regexdev.h
 create mode 100644 lib/librte_regexdev/rte_regexdev_version.map

diff --git a/config/common_base b/config/common_base
index fe30c51..d7f07b9 100644
--- a/config/common_base
+++ b/config/common_base
@@ -832,6 +832,11 @@ CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_EP_RAWDEV=y
 CONFIG_RTE_LIBRTE_PMD_NTB_RAWDEV=y
 
 #
+# Compile regex device support
+#
+CONFIG_RTE_LIBRTE_REGEXDEV=y
+
+#
 # Compile librte_ring
 #
 CONFIG_RTE_LIBRTE_RING=y
@@ -1141,3 +1146,4 @@ CONFIG_RTE_APP_CRYPTO_PERF=y
 # Compile the eventdev application
 #
 CONFIG_RTE_APP_EVENTDEV=y
+
diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
index 5a48789..ba3443c 100644
--- a/doc/api/doxy-api-index.md
+++ b/doc/api/doxy-api-index.md
@@ -26,6 +26,7 @@ The public API headers are grouped by topics:
   [event_timer_adapter]    (@ref rte_event_timer_adapter.h),
   [event_crypto_adapter]   (@ref rte_event_crypto_adapter.h),
   [rawdev]             (@ref rte_rawdev.h),
+  [regexdev]           (@ref rte_regexdev.h),
   [metrics]            (@ref rte_metrics.h),
   [bitrate]            (@ref rte_bitrate.h),
   [latency]            (@ref rte_latencystats.h),
diff --git a/doc/api/doxy-api.conf.in b/doc/api/doxy-api.conf.in
index 9b55b75..39c202e 100644
--- a/doc/api/doxy-api.conf.in
+++ b/doc/api/doxy-api.conf.in
@@ -61,6 +61,7 @@ INPUT                   = @TOPDIR@/doc/api/doxy-api-index.md \
                           @TOPDIR@/lib/librte_rcu \
                           @TOPDIR@/lib/librte_reorder \
                           @TOPDIR@/lib/librte_rib \
+                          @TOPDIR@/lib/librte_regexdev \
                           @TOPDIR@/lib/librte_ring \
                           @TOPDIR@/lib/librte_sched \
                           @TOPDIR@/lib/librte_security \
diff --git a/doc/guides/prog_guide/index.rst b/doc/guides/prog_guide/index.rst
index 8838ffb..f0528db 100644
--- a/doc/guides/prog_guide/index.rst
+++ b/doc/guides/prog_guide/index.rst
@@ -72,3 +72,4 @@ Programmer's Guide
     lto
     profile_app
     glossary
+    regexdev_lib
diff --git a/doc/guides/prog_guide/regexdev_lib.rst b/doc/guides/prog_guide/regexdev_lib.rst
new file mode 100644
index 0000000..1ecbf1c
--- /dev/null
+++ b/doc/guides/prog_guide/regexdev_lib.rst
@@ -0,0 +1,177 @@
+..  SPDX-License-Identifier: BSD-3-Clause
+    Copyright(c) 2020 Mellanox Corporation.
+
+RegEx Device Library
+=====================
+
+The RegEx library provides a RegEx device framework for management and
+provisioning of hardware and software RegEx poll mode drivers, defining generic
+APIs which support a number of different RegEx operations.
+
+
+Design Principles
+-----------------
+
+The RegEx library follows the same basic principles as those used in DPDK's
+Ethernet Device framework and the Crypto framework. The RegEx framework provides
+a generic Crypto device framework which supports both physical (hardware)
+and virtual (software) RegEx devices as well as a generic RegEx API which allows
+RegEx devices to be managed and configured and supports RegEx operations to be
+provisioned on RegEx poll mode driver.
+
+
+Device Management
+-----------------
+
+Device Creation
+~~~~~~~~~~~~~~~
+
+Physical RegEx devices are discovered during the PCI probe/enumeration of the
+EAL function which is executed at DPDK initialization, based on
+their PCI device identifier, each unique PCI BDF (bus/bridge, device,
+function). Specific physical ReEx devices, like other physical devices in DPDK
+can be white-listed or black-listed using the EAL command line options.
+
+
+Device Identification
+~~~~~~~~~~~~~~~~~~~~~
+
+Each device, whether virtual or physical is uniquely designated by two
+identifiers:
+
+- A unique device index used to designate the RegEx device in all functions
+  exported by the regexdev API.
+
+- A device name used to designate the RegEx device in console messages, for
+  administration or debugging purposes.
+
+
+Device Configuration
+~~~~~~~~~~~~~~~~~~~~
+
+The configuration of each RegEx device includes the following operations:
+
+- Allocation of resources, including hardware resources if a physical device.
+- Resetting the device into a well-known default state.
+- Initialization of statistics counters.
+
+The rte_regexdev_configure API is used to configure a RegEx device.
+
+.. code-block:: c
+
+   int rte_regexdev_configure(uint8_t dev_id,
+                              const struct rte_regexdev_config *cfg);
+
+The ``rte_regexdev_config`` structure is used to pass the configuration
+parameters for the RegEx device for example  number of queue pairs, number of
+groups, max number of matches and so on.
+
+.. code-block:: c
+
+   struct rte_regexdev_config {
+        uint16_t nb_max_matches;
+        /**< Maximum matches per scan configured on this device.
+         * This value cannot exceed the *max_matches*
+         * which previously provided in rte_regexdev_info_get().
+         * The value 0 is allowed, in which case, value 1 used.
+         * @see struct rte_regexdev_info::max_matches
+         */
+        uint16_t nb_queue_pairs;
+        /**< Number of RegEx queue pairs to configure on this device.
+         * This value cannot exceed the *max_queue_pairs* which previously
+         * provided in rte_regexdev_info_get().
+         * @see struct rte_regexdev_info::max_queue_pairs
+         */
+        uint32_t nb_rules_per_group;
+        /**< Number of rules per group to configure on this device.
+         * This value cannot exceed the *max_rules_per_group*
+         * which previously provided in rte_regexdev_info_get().
+         * The value 0 is allowed, in which case,
+         * struct rte_regexdev_info::max_rules_per_group used.
+         * @see struct rte_regexdev_info::max_rules_per_group
+         */
+        uint16_t nb_groups;
+        /**< Number of groups to configure on this device.
+         * This value cannot exceed the *max_groups*
+         * which previously provided in rte_regexdev_info_get().
+         * @see struct rte_regexdev_info::max_groups
+         */
+        const char *rule_db;
+        /**< Import initial set of prebuilt rule database on this device.
+         * The value NULL is allowed, in which case, the device will not
+         * be configured prebuilt rule database. Application may use
+         * rte_regexdev_rule_db_update() or rte_regexdev_rule_db_import() API
+         * to update or import rule database after the
+         * rte_regexdev_configure().
+         * @see rte_regexdev_rule_db_update(), rte_regexdev_rule_db_import()
+         */
+        uint32_t rule_db_len;
+        /**< Length of *rule_db* buffer. */
+        uint32_t dev_cfg_flags;
+        /**< RegEx device configuration flags, See RTE_REGEXDEV_CFG_*  */
+    };
+
+
+Configuration of Rules Database
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Each Regex device should be configured with the rule database.
+There are two modes of setting the rule database, online or offline.
+The online mode means, that the rule database in being compiled by the
+RegEx PMD while in the offline mode the rule database is compiled by external
+compiler, and is being loaded to the PMD as a buffer.
+The configuration mode is depended on the PMD capabilities.
+
+Online rule configuration is done using the following API functions:
+``rte_regexdev_rule_db_update`` which add / remove rules from the rules
+precomplied list, and ``rte_regexdev_rule_db_compile_activate``
+which compile the rules and loads them to the RegEx HW.
+
+Offline rule configuration can be done by adding a pointer to the compiled
+rule database in the configuration step, or by using
+``rte_regexdev_rule_db_import`` API.
+
+
+Configuration of Queue Pairs
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Each RegEx device can be configured with number of queue pairs.
+Each queue pair is configured using ``rte_regexdev_queue_pair_setup``
+
+
+Logical Cores, Memory and Queues Pair Relationships
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Multiple logical cores should never share the same queue pair for enqueuing
+operations or dequeuing operations on the same RegEx device since this would
+require global locks and hinder performance.
+
+
+Device Features and Capabilities
+---------------------------------
+
+RegEx devices may support different feature set.
+In order to get the supported PMD feature ``rte_regexdev_info_get``
+API which return the info of the device and it's supported features.
+
+
+Enqueue / Dequeue Burst APIs
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The burst enqueue API uses a RegEx device identifier and a queue pair
+identifier to specify the device queue pair to schedule the processing on.
+The ``nb_ops`` parameter is the number of operations to process which are
+supplied in the ``ops`` array of ``rte_regex_ops`` structures.
+The enqueue function returns the number of operations it actually enqueued for
+processing, a return value equal to ``nb_ops`` means that all packets have been
+enqueued.
+
+Data pointed in each op, should not be released until the dequeue of for that
+op.
+
+The dequeue API uses the same format as the enqueue API of processed but
+the ``nb_ops`` and ``ops`` parameters are now used to specify the max processed
+operations the user wishes to retrieve and the location in which to store them.
+The API call returns the actual number of processed operations returned, this
+can never be larger than ``nb_ops``.
+
diff --git a/lib/Makefile b/lib/Makefile
index e0e5eb4..dada18c 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -45,6 +45,8 @@ DEPDIRS-librte_eventdev := librte_eal librte_ring librte_ethdev librte_hash \
                            librte_mempool librte_timer librte_cryptodev
 DIRS-$(CONFIG_RTE_LIBRTE_RAWDEV) += librte_rawdev
 DEPDIRS-librte_rawdev := librte_eal librte_ethdev
+DIRS-$(CONFIG_RTE_LIBRTE_REGEXDEV) += librte_regexdev
+DEPDIRS-librte_regexdev := librte_eal librte_mbuf
 DIRS-$(CONFIG_RTE_LIBRTE_VHOST) += librte_vhost
 DEPDIRS-librte_vhost := librte_eal librte_mempool librte_mbuf librte_ethdev \
 			librte_net librte_hash librte_cryptodev
diff --git a/lib/librte_regexdev/Makefile b/lib/librte_regexdev/Makefile
new file mode 100644
index 0000000..6f4cc63
--- /dev/null
+++ b/lib/librte_regexdev/Makefile
@@ -0,0 +1,31 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(C) 2019 Marvell International Ltd.
+# Copyright(C) 2020 Mellanox International Ltd.
+#
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+# library name
+LIB = librte_regexdev.a
+
+EXPORT_MAP := rte_regex_version.map
+
+# library version
+LIBABIVER := 1
+
+# build flags
+CFLAGS += -O3
+CFLAGS += $(WERROR_FLAGS)
+LDLIBS += -lrte_eal -lrte_mbuf
+
+# library source files
+# all source are stored in SRCS-y
+SRCS-$(CONFIG_RTE_LIBRTE_REGEXDEV) := rte_regexdev.c
+
+# export include files
+SYMLINK-$(CONFIG_RTE_LIBRTE_REGEXDEV)-include += rte_regexdev.h
+
+# versioning export map
+EXPORT_MAP := rte_regexdev_version.map
+
+include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_regexdev/meson.build b/lib/librte_regexdev/meson.build
new file mode 100644
index 0000000..f4db748
--- /dev/null
+++ b/lib/librte_regexdev/meson.build
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2020 Mellanox Corporation
+
+allow_experimental_apis = true
+sources = files('rte_regexdev.c')
+headers = files('rte_regexdev.h')
+deps += ['mbuf']
diff --git a/lib/librte_regexdev/rte_regexdev.c b/lib/librte_regexdev/rte_regexdev.c
new file mode 100644
index 0000000..b901877
--- /dev/null
+++ b/lib/librte_regexdev/rte_regexdev.c
@@ -0,0 +1,6 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2019 Marvell International Ltd.
+ * Copyright(C) 2020 Mellanox International Ltd.
+ */
+
+#include <rte_regexdev.h>
diff --git a/lib/librte_regexdev/rte_regexdev.h b/lib/librte_regexdev/rte_regexdev.h
new file mode 100644
index 0000000..7e688d9
--- /dev/null
+++ b/lib/librte_regexdev/rte_regexdev.h
@@ -0,0 +1,1473 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2019 Marvell International Ltd.
+ * Copyright(C) 2020 Mellanox International Ltd.
+ * Copyright(C) 2020 Intel International Ltd.
+ */
+
+#ifndef _RTE_REGEXDEV_H_
+#define _RTE_REGEXDEV_H_
+
+/**
+ * @file
+ *
+ * RTE RegEx Device API
+ *
+ * Defines RTE RegEx Device APIs for RegEx operations and its provisioning.
+ *
+ * The RegEx Device API is composed of two parts:
+ *
+ * - The application-oriented RegEx API that includes functions to setup
+ *   a RegEx device (configure it, setup its queue pairs and start it),
+ *   update the rule database and so on.
+ *
+ * - The driver-oriented RegEx API that exports a function allowing
+ *   a RegEx poll Mode Driver (PMD) to simultaneously register itself as
+ *   a RegEx device driver.
+ *
+ * RegEx device components and definitions:
+ *
+ *     +-----------------+
+ *     |                 |
+ *     |                 o---------+    rte_regexdev_[en|de]queue_burst()
+ *     |   PCRE based    o------+  |               |
+ *     |  RegEx pattern  |      |  |  +--------+   |
+ *     | matching engine o------+--+--o        |   |    +------+
+ *     |                 |      |  |  | queue  |<==o===>|Core 0|
+ *     |                 o----+ |  |  | pair 0 |        |      |
+ *     |                 |    | |  |  +--------+        +------+
+ *     +-----------------+    | |  |
+ *            ^               | |  |  +--------+
+ *            |               | |  |  |        |        +------+
+ *            |               | +--+--o queue  |<======>|Core 1|
+ *        Rule|Database       |    |  | pair 1 |        |      |
+ *     +------+----------+    |    |  +--------+        +------+
+ *     |     Group 0     |    |    |
+ *     | +-------------+ |    |    |  +--------+        +------+
+ *     | | Rules 0..n  | |    |    |  |        |        |Core 2|
+ *     | +-------------+ |    |    +--o queue  |<======>|      |
+ *     |     Group 1     |    |       | pair 2 |        +------+
+ *     | +-------------+ |    |       +--------+
+ *     | | Rules 0..n  | |    |
+ *     | +-------------+ |    |       +--------+
+ *     |     Group 2     |    |       |        |        +------+
+ *     | +-------------+ |    |       | queue  |<======>|Core n|
+ *     | | Rules 0..n  | |    +-------o pair n |        |      |
+ *     | +-------------+ |            +--------+        +------+
+ *     |     Group n     |
+ *     | +-------------+ |<-------rte_regexdev_rule_db_update()
+ *     | |             | |<-------rte_regexdev_rule_db_compile_activate()
+ *     | | Rules 0..n  | |<-------rte_regexdev_rule_db_import()
+ *     | +-------------+ |------->rte_regexdev_rule_db_export()
+ *     +-----------------+
+ *
+ * RegEx: A regular expression is a concise and flexible means for matching
+ * strings of text, such as particular characters, words, or patterns of
+ * characters. A common abbreviation for this is “RegEx”.
+ *
+ * RegEx device: A hardware or software-based implementation of RegEx
+ * device API for PCRE based pattern matching syntax and semantics.
+ *
+ * PCRE RegEx syntax and semantics specification:
+ * http://regexkit.sourceforge.net/Documentation/pcre/pcrepattern.html
+ *
+ * RegEx queue pair: Each RegEx device should have one or more queue pair to
+ * transmit a burst of pattern matching request and receive a burst of
+ * receive the pattern matching response. The pattern matching request/response
+ * embedded in *rte_regex_ops* structure.
+ *
+ * Rule: A pattern matching rule expressed in PCRE RegEx syntax along with
+ * Match ID and Group ID to identify the rule upon the match.
+ *
+ * Rule database: The RegEx device accepts regular expressions and converts them
+ * into a compiled rule database that can then be used to scan data.
+ * Compilation allows the device to analyze the given pattern(s) and
+ * pre-determine how to scan for these patterns in an optimized fashion that
+ * would be far too expensive to compute at run-time. A rule database contains
+ * a set of rules that compiled in device specific binary form.
+ *
+ * Match ID or Rule ID: A unique identifier provided at the time of rule
+ * creation for the application to identify the rule upon match.
+ *
+ * Group ID: Group of rules can be grouped under one group ID to enable
+ * rule isolation and effective pattern matching. A unique group identifier
+ * provided at the time of rule creation for the application to identify the
+ * rule upon match.
+ *
+ * Scan: A pattern matching request through *enqueue* API.
+ *
+ * It may possible that a given RegEx device may not support all the features
+ * of PCRE. The application may probe unsupported features through
+ * struct rte_regexdev_info::pcre_unsup_flags
+ *
+ * By default, all the functions of the RegEx Device API exported by a PMD
+ * are lock-free functions which assume to not be invoked in parallel on
+ * different logical cores to work on the same target object. For instance,
+ * the dequeue function of a PMD cannot be invoked in parallel on two logical
+ * cores to operates on same RegEx queue pair. Of course, this function
+ * can be invoked in parallel by different logical core on different queue pair.
+ * It is the responsibility of the upper level application to enforce this rule.
+ *
+ * In all functions of the RegEx API, the RegEx device is
+ * designated by an integer >= 0 named the device identifier *dev_id*
+ *
+ * At the RegEx driver level, RegEx devices are represented by a generic
+ * data structure of type *rte_regexdev*.
+ *
+ * RegEx devices are dynamically registered during the PCI/SoC device probing
+ * phase performed at EAL initialization time.
+ * When a RegEx device is being probed, a *rte_regexdev* structure and
+ * a new device identifier are allocated for that device. Then, the
+ * regexdev_init() function supplied by the RegEx driver matching the probed
+ * device is invoked to properly initialize the device.
+ *
+ * The role of the device init function consists of resetting the hardware or
+ * software RegEx driver implementations.
+ *
+ * If the device init operation is successful, the correspondence between
+ * the device identifier assigned to the new device and its associated
+ * *rte_regexdev* structure is effectively registered.
+ * Otherwise, both the *rte_regexdev* structure and the device identifier are
+ * freed.
+ *
+ * The functions exported by the application RegEx API to setup a device
+ * designated by its device identifier must be invoked in the following order:
+ *     - rte_regexdev_configure()
+ *     - rte_regexdev_queue_pair_setup()
+ *     - rte_regexdev_start()
+ *
+ * Then, the application can invoke, in any order, the functions
+ * exported by the RegEx API to enqueue pattern matching job, dequeue pattern
+ * matching response, get the stats, update the rule database,
+ * get/set device attributes and so on
+ *
+ * If the application wants to change the configuration (i.e. call
+ * rte_regexdev_configure() or rte_regexdev_queue_pair_setup()), it must call
+ * rte_regexdev_stop() first to stop the device and then do the reconfiguration
+ * before calling rte_regexdev_start() again. The enqueue and dequeue
+ * functions should not be invoked when the device is stopped.
+ *
+ * Finally, an application can close a RegEx device by invoking the
+ * rte_regexdev_close() function.
+ *
+ * Each function of the application RegEx API invokes a specific function
+ * of the PMD that controls the target device designated by its device
+ * identifier.
+ *
+ * For this purpose, all device-specific functions of a RegEx driver are
+ * supplied through a set of pointers contained in a generic structure of type
+ * *regexdev_ops*.
+ * The address of the *regexdev_ops* structure is stored in the *rte_regexdev*
+ * structure by the device init function of the RegEx driver, which is
+ * invoked during the PCI/SoC device probing phase, as explained earlier.
+ *
+ * In other words, each function of the RegEx API simply retrieves the
+ * *rte_regexdev* structure associated with the device identifier and
+ * performs an indirect invocation of the corresponding driver function
+ * supplied in the *regexdev_ops* structure of the *rte_regexdev* structure.
+ *
+ * For performance reasons, the address of the fast-path functions of the
+ * RegEx driver is not contained in the *regexdev_ops* structure.
+ * Instead, they are directly stored at the beginning of the *rte_regexdev*
+ * structure to avoid an extra indirect memory access during their invocation.
+ *
+ * RTE RegEx device drivers do not use interrupts for enqueue or dequeue
+ * operation. Instead, RegEx drivers export Poll-Mode enqueue and dequeue
+ * functions to applications.
+ *
+ * The *enqueue* operation submits a burst of RegEx pattern matching request
+ * to the RegEx device and the *dequeue* operation gets a burst of pattern
+ * matching response for the ones submitted through *enqueue* operation.
+ *
+ * Typical application utilisation of the RegEx device API will follow the
+ * following programming flow.
+ *
+ * - rte_regexdev_configure()
+ * - rte_regexdev_queue_pair_setup()
+ * - rte_regexdev_rule_db_update() Needs to invoke if precompiled rule database
+ *   not provided in rte_regexdev_config::rule_db for rte_regexdev_configure()
+ *   and/or application needs to update rule database.
+ * - rte_regexdev_rule_db_compile_activate() Needs to invoke if
+ *   rte_regexdev_rule_db_update function was used.
+ * - Create or reuse exiting mempool for *rte_regex_ops* objects.
+ * - rte_regexdev_start()
+ * - rte_regexdev_enqueue_burst()
+ * - rte_regexdev_dequeue_burst()
+ *
+ */
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include <rte_common.h>
+#include <rte_config.h>
+#include <rte_dev.h>
+#include <rte_errno.h>
+#include <rte_mbuf.h>
+#include <rte_memory.h>
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Get the total number of RegEx devices that have been successfully
+ * initialised.
+ *
+ * @return
+ *   The total number of usable RegEx devices.
+ */
+__rte_experimental
+uint8_t
+rte_regexdev_count(void);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Get the device identifier for the named RegEx device.
+ *
+ * @param name
+ *   RegEx device name to select the RegEx device identifier.
+ *
+ * @return
+ *   Returns RegEx device identifier on success.
+ *   - <0: Failure to find named RegEx device.
+ */
+__rte_experimental
+int
+rte_regexdev_get_dev_id(const char *name);
+
+/* Enumerates RegEx device capabilities */
+#define RTE_REGEXDEV_CAPA_RUNTIME_COMPILATION_F (1ULL << 0)
+/**< RegEx device does support compiling the rules at runtime unlike
+ * loading only the pre-built rule database using
+ * struct rte_regexdev_config::rule_db in rte_regexdev_configure()
+ *
+ * @see struct rte_regexdev_config::rule_db, rte_regexdev_configure()
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_CAPA_SUPP_PCRE_START_ANCHOR_F (1ULL << 1)
+/**< RegEx device support PCRE Anchor to start of match flag.
+ * Example RegEx is '/\Gfoo\d/'. Here '\G' asserts position at the end of the
+ * previous match or the start of the string for the first match.
+ * This position will change each time the RegEx is applied to the subject
+ * string. If the RegEx is applied to 'foo1foo2Zfoo3' the first two matches will
+ * be successful for 'foo1foo2' and fail for 'Zfoo3'.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_CAPA_SUPP_PCRE_ATOMIC_GROUPING_F (1ULL << 2)
+/**< RegEx device support PCRE Atomic grouping.
+ * Atomic groups are represented by '(?>)'. An atomic group is a group that,
+ * when the RegEx engine exits from it, automatically throws away all
+ * backtracking positions remembered by any tokens inside the group.
+ * Example RegEx is 'a(?>bc|b)c' if the given patterns are 'abc' and 'abcc' then
+ * 'a(bc|b)c' matches both where as 'a(?>bc|b)c' matches only abcc because
+ * atomic groups don't allow backtracing back to 'b'.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_BACKTRACKING_CTRL_F (1ULL << 3)
+/**< RegEx device support PCRE backtracking control verbs.
+ * Some examples of backtracing verbs are (*COMMIT), (*ACCEPT), (*FAIL),
+ * (*SKIP), (*PRUNE).
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_CALLOUTS_F (1ULL << 4)
+/**< RegEx device support PCRE callouts.
+ * PCRE supports calling external function in between matches by using '(?C)'.
+ * Example RegEx 'ABC(?C)D' if a given patter is 'ABCD' then the RegEx engine
+ * will parse ABC perform a userdefined callout and return a successful match at
+ * D.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_BACKREFERENCE_F (1ULL << 5)
+/**< RegEx device support PCRE backreference.
+ * Example RegEx is '(\2ABC|(GHI))+' \2 matches the same text as most recently
+ * matched by the 2nd capturing group i.e. 'GHI'.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_GREEDY_F (1ULL << 6)
+/**< RegEx device support PCRE Greedy mode.
+ * For example if the RegEx is 'AB\d*?' then '*?' represents zero or unlimited
+ * matches. In greedy mode the pattern 'AB12345' will be matched completely
+ * where as the ungreedy mode 'AB' will be returned as the match.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_MATCH_ALL_F (1ULL << 7)
+/**< RegEx device support match all mode.
+ * For example if the RegEx is 'AB\d*?' then '*?' represents zero or unlimited
+ * matches. In match all mode the pattern 'AB12345' will return 6 matches.
+ * AB, AB1, AB12, AB123, AB1234, AB12345.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_LOOKAROUND_ASRT_F (1ULL << 8)
+/**< RegEx device support PCRE Lookaround assertions
+ * (Zero-width assertions). Example RegEx is '[a-z]+\d+(?=!{3,})' if
+ * the given pattern is 'dwad1234!' the RegEx engine doesn't report any matches
+ * because the assert '(?=!{3,})' fails. The pattern 'dwad123!!!' would return a
+ * successful match.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_MATCH_POINT_RST_F (1ULL << 9)
+/**< RegEx device doesn't support PCRE match point reset directive.
+ * Example RegEx is '[a-z]+\K\d+' if the pattern is 'dwad123'
+ * then even though the entire pattern matches only '123'
+ * is reported as a match.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_NEWLINE_CONVENTIONS_F (1ULL << 10)
+/**< RegEx support PCRE newline convention.
+ * Newline conventions are represented as follows:
+ * (*CR)        carriage return
+ * (*LF)        linefeed
+ * (*CRLF)      carriage return, followed by linefeed
+ * (*ANYCRLF)   any of the three above
+ * (*ANY)       all Unicode newline sequences
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_NEWLINE_SEQ_F (1ULL << 11)
+/**< RegEx device support PCRE newline sequence.
+ * The escape sequence '\R' will match any newline sequence.
+ * It is equivalent to: '(?>\r\n|\n|\x0b|\f|\r|\x85)'.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_POSSESSIVE_QUALIFIERS_F (1ULL << 12)
+/**< RegEx device support PCRE possessive qualifiers.
+ * Example RegEx possessive qualifiers '*+', '++', '?+', '{m,n}+'.
+ * Possessive quantifier repeats the token as many times as possible and it does
+ * not give up matches as the engine backtracks. With a possessive quantifier,
+ * the deal is all or nothing.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_SUBROUTINE_REFERENCES_F (1ULL << 13)
+/**< RegEx device support PCRE Subroutine references.
+ * PCRE Subroutine references allow for sub patterns to be assessed
+ * as part of the RegEx. Example RegEx is '(foo|fuzz)\g<1>+bar' matches the
+ * pattern 'foofoofuzzfoofuzzbar'.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_UTF_8_F (1ULL << 14)
+/**< RegEx device support UTF-8 character encoding.
+ *
+ * @see struct rte_regexdev_info::pcre_unsup_flags
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_UTF_16_F (1ULL << 15)
+/**< RegEx device support UTF-16 character encoding.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_UTF_32_F (1ULL << 16)
+/**< RegEx device support UTF-32 character encoding.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_WORD_BOUNDARY_F (1ULL << 17)
+/**< RegEx device support word boundaries.
+ * The meta character '\b' represents word boundary anchor.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_PCRE_FORWARD_REFERENCES_F (1ULL << 18)
+/**< RegEx device support Forward references.
+ * Forward references allow you to use a back reference to a group that appears
+ * later in the RegEx. Example RegEx is '(\3ABC|(DEF|(GHI)))+' matches the
+ * following string 'GHIGHIABCDEF'.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_MATCH_AS_END_F (1ULL << 19)
+/**< RegEx device support match as end.
+ * Match as end means that the match result holds the end offset of the
+ * detected match. No len value is set.
+ * If the device doesn't support this feature it means the match
+ * result holds the starting position of match and the length of the match.
+ *
+ * @see struct rte_regexdev_info::regexdev_capa
+ */
+
+#define RTE_REGEXDEV_SUPP_CROSS_BUFFER_F (1ULL << 20)
+/**< RegEx device support cross buffer match.
+ * Cross buffer matching means that the match can be detected even if the
+ * string was started in previous buffer.
+ * In case the device is configured as RTE_REGEXDEV_CFG_MATCH_AS_END
+ * the end offset will be relative for the first packet.
+ * For example RegEx is ABC the first buffer is xxxx second buffer yyyA and
+ * the last buffer BCzz.
+ * In case the match as end is configured the end offset will be 10.
+ *
+ * @see RTE_REGEXDEV_CFG_MATCH_AS_END_F
+ * @see RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F
+ * @see RTE_REGEX_OPS_RSP_PMI_SOJ_F
+ * @see RTE_REGEX_OPS_RSP_PMI_EOJ_F
+ */
+
+#define RTE_REGEXDEV_SUPP_MATCH_ALL_F (1ULL << 21)
+/**< RegEx device support match all.
+ * Match all means that the RegEx engine will return all possible matches.
+ * For example, assume the RegEx is 'A+b', given the input AAAb the
+ * returned matches will be: Ab, AAb and AAAb.
+ *
+ * @see RTE_REGEXDEV_CFG_MATCH_ALL_F
+ */
+
+/* Enumerates PCRE rule flags */
+#define RTE_REGEX_PCRE_RULE_ALLOW_EMPTY_F (1ULL << 0)
+/**< When this flag is set, the pattern that can match against an empty string,
+ * such as '.*' are allowed.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_ANCHORED_F (1ULL << 1)
+/**< When this flag is set, the pattern is forced to be "anchored", that is, it
+ * is constrained to match only at the first matching point in the string that
+ * is being searched. Similar to '^' and represented by \A.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_CASELESS_F (1ULL << 2)
+/**< When this flag is set, letters in the pattern match both upper and lower
+ * case letters in the subject.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_DOTALL_F (1ULL << 3)
+/**< When this flag is set, a dot metacharacter in the pattern matches any
+ * character, including one that indicates a newline.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_DUPNAMES_F (1ULL << 4)
+/**< When this flag is set, names used to identify capture groups need not be
+ * unique.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_EXTENDED_F (1ULL << 5)
+/**< When this flag is set, most white space characters in the pattern are
+ * totally ignored except when escaped or inside a character class.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_MATCH_UNSET_BACKREF_F (1ULL << 6)
+/**< When this flag is set, a backreference to an unset capture group matches an
+ * empty string.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_MULTILINE_F (1ULL << 7)
+/**< When this flag  is set, the '^' and '$' constructs match immediately
+ * following or immediately before internal newlines in the subject string,
+ * respectively, as well as at the very start and end.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_NO_AUTO_CAPTURE_F (1ULL << 8)
+/**< When this Flag is set, it disables the use of numbered capturing
+ * parentheses in the pattern. References to capture groups (backreferences or
+ * recursion/subroutine calls) may only refer to named groups, though the
+ * reference can be by name or by number.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_UCP_F (1ULL << 9)
+/**< By default, only ASCII characters are recognized, When this flag is set,
+ * Unicode properties are used instead to classify characters.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_UNGREEDY_F (1ULL << 10)
+/**< When this flag is set, the "greediness" of the quantifiers is inverted
+ * so that they are not greedy by default, but become greedy if followed by
+ * '?'.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_UTF_F (1ULL << 11)
+/**< When this flag is set, RegEx engine has to regard both the pattern and the
+ * subject strings that are subsequently processed as strings of UTF characters
+ * instead of single-code-unit strings.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+#define RTE_REGEX_PCRE_RULE_NEVER_BACKSLASH_C_F (1ULL << 12)
+/**< This flag locks out the use of '\C' in the pattern that is being compiled.
+ * This escape matches one data unit, even in UTF mode which can cause
+ * unpredictable behavior in UTF-8 or UTF-16 modes, because it may leave the
+ * current matching point in the mi:set hlsearchddle of a multi-code-unit
+ * character.
+ *
+ * @see struct rte_regexdev_info::rule_flags
+ * @see struct rte_regexdev_rule::rule_flags
+ */
+
+/**
+ * RegEx device information
+ */
+struct rte_regexdev_info {
+	const char *driver_name; /**< RegEx driver name. */
+	struct rte_device *dev;	/**< Device information. */
+	uint16_t max_matches;
+	/**< Maximum matches per scan supported by this device. */
+	uint16_t max_queue_pairs;
+	/**< Maximum queue pairs supported by this device. */
+	uint16_t max_payload_size;
+	/**< Maximum payload size for a pattern match request or scan.
+	 * @see RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F
+	 */
+	uint32_t max_rules_per_group;
+	/**< Maximum rules supported per group by this device. */
+	uint16_t max_groups;
+	/**< Maximum groups supported by this device. */
+	uint32_t regexdev_capa;
+	/**< RegEx device capabilities. @see RTE_REGEXDEV_CAPA_* */
+	uint64_t rule_flags;
+	/**< Supported compiler rule flags.
+	 * @see RTE_REGEX_PCRE_RULE_*, struct rte_regexdev_rule::rule_flags
+	 */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Retrieve the contextual information of a RegEx device.
+ *
+ * @param dev_id
+ *   The identifier of the device.
+ *
+ * @param[out] dev_info
+ *   A pointer to a structure of type *rte_regexdev_info* to be filled with the
+ *   contextual information of the device.
+ *
+ * @return
+ *   - 0: Success, driver updates the contextual information of the RegEx device
+ *   - <0: Error code returned by the driver info get function.
+ */
+__rte_experimental
+int
+rte_regexdev_info_get(uint8_t dev_id, struct rte_regexdev_info *dev_info);
+
+/* Enumerates RegEx device configuration flags */
+#define RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F (1ULL << 0)
+/**< Cross buffer scan refers to the ability to be able to detect
+ * matches that occur across buffer boundaries, where the buffers are related
+ * to each other in some way. Enable this flag when to scan payload size
+ * greater than struct rte_regexdev_info::max_payload_size and/or
+ * matches can present across scan buffer boundaries.
+ *
+ * @see struct rte_regexdev_info::max_payload_size
+ * @see struct rte_regexdev_config::dev_cfg_flags, rte_regexdev_configure()
+ * @see RTE_REGEX_OPS_RSP_PMI_SOJ_F
+ * @see RTE_REGEX_OPS_RSP_PMI_EOJ_F
+ */
+
+#define RTE_REGEXDEV_CFG_MATCH_AS_END_F (1ULL << 1)
+/**< Match as end is the ability to return the result as ending offset.
+ * When this flag is set, the result for each match will hold the ending
+ * offset of the match in end_offset.
+ * If this flag is not set, then the match result will hold the starting offset
+ * in start_offset, and the length of the match in len.
+ *
+ * @see RTE_REGEXDEV_SUPP_MATCH_AS_END_F
+ */
+
+#define RTE_REGEXDEV_CFG_MATCH_ALL_F (1ULL << 2)
+/**< Match all is the ability to return all possible results.
+ *
+ * @see RTE_REGEXDEV_SUPP_MATCH_ALL_F
+ */
+
+/** RegEx device configuration structure */
+struct rte_regexdev_config {
+	uint16_t nb_max_matches;
+	/**< Maximum matches per scan configured on this device.
+	 * This value cannot exceed the *max_matches*
+	 * which previously provided in rte_regexdev_info_get().
+	 * The value 0 is allowed, in which case, value 1 used.
+	 * @see struct rte_regexdev_info::max_matches
+	 */
+	uint16_t nb_queue_pairs;
+	/**< Number of RegEx queue pairs to configure on this device.
+	 * This value cannot exceed the *max_queue_pairs* which previously
+	 * provided in rte_regexdev_info_get().
+	 * @see struct rte_regexdev_info::max_queue_pairs
+	 */
+	uint32_t nb_rules_per_group;
+	/**< Number of rules per group to configure on this device.
+	 * This value cannot exceed the *max_rules_per_group*
+	 * which previously provided in rte_regexdev_info_get().
+	 * The value 0 is allowed, in which case,
+	 * struct rte_regexdev_info::max_rules_per_group used.
+	 * @see struct rte_regexdev_info::max_rules_per_group
+	 */
+	uint16_t nb_groups;
+	/**< Number of groups to configure on this device.
+	 * This value cannot exceed the *max_groups*
+	 * which previously provided in rte_regexdev_info_get().
+	 * @see struct rte_regexdev_info::max_groups
+	 */
+	const char *rule_db;
+	/**< Import initial set of prebuilt rule database on this device.
+	 * The value NULL is allowed, in which case, the device will not
+	 * be configured prebuilt rule database. Application may use
+	 * rte_regexdev_rule_db_update() or rte_regexdev_rule_db_import() API
+	 * to update or import rule database after the
+	 * rte_regexdev_configure().
+	 * @see rte_regexdev_rule_db_update(), rte_regexdev_rule_db_import()
+	 */
+	uint32_t rule_db_len;
+	/**< Length of *rule_db* buffer. */
+	uint32_t dev_cfg_flags;
+	/**< RegEx device configuration flags, See RTE_REGEXDEV_CFG_*  */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Configure a RegEx device.
+ *
+ * This function must be invoked first before any other function in the
+ * API. This function can also be re-invoked when a device is in the
+ * stopped state.
+ *
+ * The caller may use rte_regexdev_info_get() to get the capability of each
+ * resources available for this regex device.
+ *
+ * @param dev_id
+ *   The identifier of the device to configure.
+ * @param cfg
+ *   The RegEx device configuration structure.
+ *
+ * @return
+ *   - 0: Success, device configured. Otherwise negative errno is returned.
+ */
+__rte_experimental
+int
+rte_regexdev_configure(uint8_t dev_id, const struct rte_regexdev_config *cfg);
+
+/* Enumerates RegEx queue pair configuration flags */
+#define RTE_REGEX_QUEUE_PAIR_CFG_OOS_F (1ULL << 0)
+/**< Out of order scan, If not set, a scan must retire after previously issued
+ * in-order scans to this queue pair. If set, this scan can be retired as soon
+ * as device returns completion. Application should not set out of order scan
+ * flag if it needs to maintain the ingress order of scan request.
+ *
+ * @see struct rte_regexdev_qp_conf::qp_conf_flags
+ * @see rte_regexdev_queue_pair_setup()
+ */
+
+struct rte_regex_ops;
+typedef void (*regexdev_stop_flush_t)(uint8_t dev_id, uint16_t qp_id,
+				      struct rte_regex_ops *op);
+/**< Callback function called during rte_regexdev_stop(), invoked once per
+ * flushed RegEx op.
+ */
+
+/** RegEx queue pair configuration structure */
+struct rte_regexdev_qp_conf {
+	uint32_t qp_conf_flags;
+	/**< Queue pair config flags, See RTE_REGEX_QUEUE_PAIR_CFG_* */
+	uint16_t nb_desc;
+	/**< The number of descriptors to allocate for this queue pair. */
+	regexdev_stop_flush_t cb;
+	/**< Callback function called during rte_regexdev_stop(), invoked
+	 * once per flushed regex op. Value NULL is allowed, in which case
+	 * callback will not be invoked. This function can be used to properly
+	 * dispose of outstanding regex ops from response queue,
+	 * for example ops containing memory pointers.
+	 * @see rte_regexdev_stop()
+	 */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Allocate and set up a RegEx queue pair for a RegEx device.
+ *
+ * @param dev_id
+ *   The identifier of the device.
+ * @param queue_pair_id
+ *   The index of the RegEx queue pair to setup. The value must be in the range
+ *   [0, nb_queue_pairs - 1] previously supplied to rte_regexdev_configure().
+ * @param qp_conf
+ *   The pointer to the configuration data to be used for the RegEx queue pair.
+ *   NULL value is allowed, in which case default configuration	used.
+ *
+ * @return
+ *   0 on success. Otherwise negative errno is returned.
+ */
+__rte_experimental
+int
+rte_regexdev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
+			      const struct rte_regexdev_qp_conf *qp_conf);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Start a RegEx device.
+ *
+ * The device start step is the last one and consists of setting the RegEx
+ * queues to start accepting the pattern matching scan requests.
+ *
+ * On success, all basic functions exported by the API (RegEx enqueue,
+ * RegEx dequeue and so on) can be invoked.
+ *
+ * @param dev_id
+ *   RegEx device identifier.
+ *
+ * @return
+ *   0 on success. Otherwise negative errno is returned.
+ */
+__rte_experimental
+int
+rte_regexdev_start(uint8_t dev_id);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Stop a RegEx device.
+ *
+ * Stop a RegEx device. The device can be restarted with a call to
+ * rte_regexdev_start().
+ *
+ * This function causes all queued response regex ops to be drained in the
+ * response queue. While draining ops out of the device,
+ * struct rte_regexdev_qp_conf::cb will be invoked for each ops.
+ *
+ * @param dev_id
+ *   RegEx device identifier.
+ *
+ * @see struct rte_regexdev_qp_conf::cb, rte_regexdev_queue_pair_setup()
+ */
+__rte_experimental
+void
+rte_regexdev_stop(uint8_t dev_id);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Close a RegEx device. The device cannot be restarted!
+ *
+ * @param dev_id
+ *   RegEx device identifier
+ *
+ * @return
+ *   0 on success. Otherwise negative errno is returned.
+ */
+__rte_experimental
+int
+rte_regexdev_close(uint8_t dev_id);
+
+/* Device get/set attributes */
+
+/** Enumerates RegEx device attribute identifier */
+enum rte_regexdev_attr_id {
+	RTE_REGEXDEV_ATTR_SOCKET_ID,
+	/**< The NUMA socket id to which the device is connected or
+	 * a default of zero if the socket could not be determined.
+	 * datatype: *int*
+	 * operation: *get*
+	 */
+	RTE_REGEXDEV_ATTR_MAX_MATCHES,
+	/**< Maximum number of matches per scan.
+	 * datatype: *uint8_t*
+	 * operation: *get* and *set*
+	 * @see RTE_REGEX_OPS_RSP_MAX_MATCH_F
+	 */
+	RTE_REGEXDEV_ATTR_MAX_SCAN_TIMEOUT,
+	/**< Upper bound scan time in ns.
+	 * datatype: *uint16_t*
+	 * operation: *get* and *set*
+	 * @see RTE_REGEX_OPS_RSP_MAX_SCAN_TIMEOUT_F
+	 */
+	RTE_REGEXDEV_ATTR_MAX_PREFIX,
+	/**< Maximum number of prefix detected per scan.
+	 * This would be useful for denial of service detection.
+	 * datatype: *uint16_t*
+	 * operation: *get* and *set*
+	 * @see RTE_REGEX_OPS_RSP_MAX_PREFIX_F
+	 */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Get an attribute from a RegEx device.
+ *
+ * @param dev_id
+ *   RegEx device identifier.
+ * @param attr_id
+ *   The attribute ID to retrieve.
+ * @param attr_value
+ *   A pointer that will be filled in with the attribute
+ *   value if successful.
+ *
+ * @return
+ *   - 0: Successfully retrieved attribute value.
+ *   - -EINVAL: Invalid device or  *attr_id* provided, or *attr_value* is NULL.
+ *   - -ENOTSUP: if the device doesn't support specific *attr_id*.
+ */
+__rte_experimental
+int
+rte_regexdev_attr_get(uint8_t dev_id, enum rte_regexdev_attr_id attr_id,
+		      void *attr_value);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Set an attribute to a RegEx device.
+ *
+ * @param dev_id
+ *   RegEx device identifier.
+ * @param attr_id
+ *   The attribute ID to retrieve.
+ * @param attr_value
+ *   Pointer that will be filled in with the attribute value
+ *   by the application.
+ *
+ * @return
+ *   - 0: Successfully applied the attribute value.
+ *   - -EINVAL: Invalid device or  *attr_id* provided, or *attr_value* is NULL.
+ *   - -ENOTSUP: if the device doesn't support specific *attr_id*.
+ */
+__rte_experimental
+int
+rte_regexdev_attr_set(uint8_t dev_id, enum rte_regexdev_attr_id attr_id,
+		      const void *attr_value);
+
+/* Rule related APIs */
+/** Enumerates RegEx rule operation. */
+enum rte_regexdev_rule_op {
+	RTE_REGEX_RULE_OP_ADD,
+	/**< Add RegEx rule to rule database. */
+	RTE_REGEX_RULE_OP_REMOVE
+	/**< Remove RegEx rule from rule database. */
+};
+
+/** Structure to hold a RegEx rule attributes. */
+struct rte_regexdev_rule {
+	enum rte_regexdev_rule_op op;
+	/**< OP type of the rule either a OP_ADD or OP_DELETE. */
+	uint16_t group_id;
+	/**< Group identifier to which the rule belongs to. */
+	uint32_t rule_id;
+	/**< Rule identifier which is returned on successful match. */
+	const char *pcre_rule;
+	/**< Buffer to hold the PCRE rule. */
+	uint16_t pcre_rule_len;
+	/**< Length of the PCRE rule. */
+	uint64_t rule_flags;
+	/* PCRE rule flags. Supported device specific PCRE rules enumerated
+	 * in struct rte_regexdev_info::rule_flags. For successful rule
+	 * database update, application needs to provide only supported
+	 * rule flags.
+	 * @See RTE_REGEX_PCRE_RULE_*, struct rte_regexdev_info::rule_flags
+	 */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Update the local rule set.
+ * This functions only modify the rule set in memory.
+ * In order for the changes to take effect, the function
+ * rte_regexdev_rule_db_compile_active must be called.
+ *
+ * @param dev_id
+ *   RegEx device identifier.
+ * @param rules
+ *   Points to an array of *nb_rules* objects of type *rte_regexdev_rule*
+ *   structure which contain the regex rules attributes to be updated
+ *   in rule database.
+ * @param nb_rules
+ *   The number of PCRE rules to update the rule database.
+ *
+ * @return
+ *   The number of regex rules actually updated on the regex device's rule
+ *   database. The return value can be less than the value of the *nb_rules*
+ *   parameter when the regex devices fails to update the rule database or
+ *   if invalid parameters are specified in a *rte_regexdev_rule*.
+ *   If the return value is less than *nb_rules*, the remaining PCRE rules
+ *   at the end of *rules* are not consumed and the caller has to take
+ *   care of them and rte_errno is set accordingly.
+ *   Possible errno values include:
+ *   - -EINVAL:  Invalid device ID or rules is NULL
+ *   - -ENOTSUP: The last processed rule is not supported on this device.
+ *   - -ENOSPC: No space available in rule database.
+ *
+ * @see rte_regexdev_rule_db_import(), rte_regexdev_rule_db_export(),
+ *   rte_regexdev_rule_db_compile_activate()
+ */
+__rte_experimental
+int
+rte_regexdev_rule_db_update(uint8_t dev_id,
+			    const struct rte_regexdev_rule *rules,
+			    uint32_t nb_rules);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Compile local rule set and burn the complied result to the
+ * RegEx deive.
+ *
+ * @param dev_id
+ *   RegEx device identifier.
+ *
+ * @return
+ *   0 on success, otherwise negative errno.
+ *
+ * @see rte_regexdev_rule_db_import(), rte_regexdev_rule_db_export(),
+ *   rte_regexdev_rule_db_update()
+ */
+__rte_experimental
+int
+rte_regexdev_rule_db_compile_activate(uint8_t dev_id);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Import a prebuilt rule database from a buffer to a RegEx device.
+ *
+ * @param dev_id
+ *   RegEx device identifier.
+ * @param rule_db
+ *   Points to prebuilt rule database.
+ * @param rule_db_len
+ *   Length of the rule database.
+ *
+ * @return
+ *   - 0: Successfully updated the prebuilt rule database.
+ *   - -EINVAL:  Invalid device ID or rule_db is NULL
+ *   - -ENOTSUP: Rule database import is not supported on this device.
+ *   - -ENOSPC: No space available in rule database.
+ *
+ * @see rte_regexdev_rule_db_update(), rte_regexdev_rule_db_export()
+ */
+__rte_experimental
+int
+rte_regexdev_rule_db_import(uint8_t dev_id, const char *rule_db,
+			    uint32_t rule_db_len);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Export the prebuilt rule database from a RegEx device to the buffer.
+ *
+ * @param dev_id
+ *   RegEx device identifier.
+ * @param[out] rule_db
+ *   Block of memory to insert the rule database. Must be at least size in
+ *   capacity. If set to NULL, function returns required capacity.
+ *
+ * @return
+ *   - 0: Successfully exported the prebuilt rule database.
+ *   - size: If rule_db set to NULL then required capacity for *rule_db*
+ *   - -EINVAL:  Invalid device ID
+ *   - -ENOTSUP: Rule database export is not supported on this device.
+ *
+ * @see rte_regexdev_rule_db_update(), rte_regexdev_rule_db_import()
+ */
+__rte_experimental
+int
+rte_regexdev_rule_db_export(uint8_t dev_id, char *rule_db);
+
+/* Extended statistics */
+/** Maximum name length for extended statistics counters */
+#define RTE_REGEXDEV_XSTATS_NAME_SIZE 64
+
+/**
+ * A name-key lookup element for extended statistics.
+ *
+ * This structure is used to map between names and ID numbers
+ * for extended RegEx device statistics.
+ */
+struct rte_regexdev_xstats_map {
+	uint16_t id;
+	/**< xstat identifier */
+	char name[RTE_REGEXDEV_XSTATS_NAME_SIZE];
+	/**< xstat name */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Retrieve names of extended statistics of a regex device.
+ *
+ * @param dev_id
+ *   The identifier of the regex device.
+ * @param[out] xstats_map
+ *   Block of memory to insert id and names into. Must be at least size in
+ *   capacity. If set to NULL, function returns required capacity.
+ * @return
+ *   - Positive value on success:
+ *        -The return value is the number of entries filled in the stats map.
+ *        -If xstats_map set to NULL then required capacity for xstats_map.
+ *   - Negative value on error:
+ *      -ENODEV for invalid *dev_id*
+ *      -ENOTSUP if the device doesn't support this function.
+ */
+__rte_experimental
+int
+rte_regexdev_xstats_names_get(uint8_t dev_id,
+			      struct rte_regexdev_xstats_map *xstats_map);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Retrieve extended statistics of an regex device.
+ *
+ * @param dev_id
+ *   The identifier of the device.
+ * @param ids
+ *   The id numbers of the stats to get. The ids can be got from the stat
+ *   position in the stat list from rte_regexdev_xstats_names_get(), or
+ *   by using rte_regexdev_xstats_by_name_get().
+ * @param values
+ *   The values for each stats request by ID.
+ * @param nb_values
+ *   The number of stats requested.
+ * @return
+ *   - Positive value: number of stat entries filled into the values array
+ *   - Negative value on error:
+ *      -ENODEV for invalid *dev_id*
+ *      -ENOTSUP if the device doesn't support this function.
+ */
+__rte_experimental
+int
+rte_regexdev_xstats_get(uint8_t dev_id, const uint16_t *ids,
+			uint64_t *values, uint16_t nb_values);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Retrieve the value of a single stat by requesting it by name.
+ *
+ * @param dev_id
+ *   The identifier of the device.
+ * @param name
+ *   The stat name to retrieve.
+ * @param id
+ *   If non-NULL, the numerical id of the stat will be returned, so that further
+ *   requests for the stat can be got using rte_regexdev_xstats_get, which will
+ *   be faster as it doesn't need to scan a list of names for the stat.
+ * @param[out] value
+ *   Must be non-NULL, retrieved xstat value will be stored in this address.
+ *
+ * @return
+ *   - 0: Successfully retrieved xstat value.
+ *   - -EINVAL: invalid parameters
+ *   - -ENOTSUP: if not supported.
+ */
+__rte_experimental
+int
+rte_regexdev_xstats_by_name_get(uint8_t dev_id, const char *name,
+				uint16_t *id, uint64_t *value);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Reset the values of the xstats of the selected component in the device.
+ *
+ * @param dev_id
+ *   The identifier of the device.
+ * @param ids
+ *   Selects specific statistics to be reset. When NULL, all statistics will be
+ *   reset. If non-NULL, must point to array of at least *nb_ids* size.
+ * @param nb_ids
+ *   The number of ids available from the *ids* array. Ignored when ids is NULL.
+ *
+ * @return
+ *   - 0: Successfully reset the statistics to zero.
+ *   - -EINVAL: invalid parameters.
+ *   - -ENOTSUP: if not supported.
+ */
+__rte_experimental
+int
+rte_regexdev_xstats_reset(uint8_t dev_id, const uint16_t *ids,
+			  uint16_t nb_ids);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Trigger the RegEx device self test.
+ *
+ * @param dev_id
+ *   The identifier of the device.
+ * @return
+ *   - 0: Selftest successful.
+ *   - -ENOTSUP if the device doesn't support selftest.
+ *   - other values < 0 on failure.
+ */
+__rte_experimental
+int
+rte_regexdev_selftest(uint8_t dev_id);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Dump internal information about *dev_id* to the FILE* provided in *f*.
+ *
+ * @param dev_id
+ *   The identifier of the device.
+ * @param f
+ *   A pointer to a file for output.
+ *
+ * @return
+ *   0 on success, negative errno on failure.
+ */
+__rte_experimental
+int
+rte_regexdev_dump(uint8_t dev_id, FILE *f);
+
+/* Fast path APIs */
+
+/**
+ * The generic *rte_regexdev_match* structure to hold the RegEx match
+ * attributes.
+ * @see struct rte_regex_ops::matches
+ */
+struct rte_regexdev_match {
+	RTE_STD_C11
+	union {
+		uint64_t u64;
+		struct {
+			uint32_t rule_id:20;
+			/**< Rule identifier to which the pattern matched.
+			 * @see struct rte_regexdev_rule::rule_id
+			 */
+			uint32_t group_id:12;
+			/**< Group identifier of the rule which the pattern
+			 * matched. @see struct rte_regexdev_rule::group_id
+			 */
+			uint16_t start_offset;
+			/**< Starting Byte Position for matched rule. */
+			RTE_STD_C11
+			union {
+				uint16_t len;
+				/**< Length of match in bytes */
+				uint16_t end_offset;
+				/**< The end offset of the match. In case
+				 * MATCH_AS_END configuration is enabled.
+				 * @see RTE_REGEXDEV_CFG_MATCH_AS_END
+				 */
+			};
+		};
+	};
+};
+
+/* Enumerates RegEx request flags. */
+#define RTE_REGEX_OPS_REQ_GROUP_ID0_VALID_F (1 << 0)
+/**< Set when struct rte_regexdev_rule::group_id0 is valid. */
+
+#define RTE_REGEX_OPS_REQ_GROUP_ID1_VALID_F (1 << 1)
+/**< Set when struct rte_regexdev_rule::group_id1 is valid. */
+
+#define RTE_REGEX_OPS_REQ_GROUP_ID2_VALID_F (1 << 2)
+/**< Set when struct rte_regexdev_rule::group_id2 is valid. */
+
+#define RTE_REGEX_OPS_REQ_GROUP_ID3_VALID_F (1 << 3)
+/**< Set when struct rte_regexdev_rule::group_id3 is valid. */
+
+#define RTE_REGEX_OPS_REQ_STOP_ON_MATCH_F (1 << 4)
+/**< The RegEx engine will stop scanning and return the first match. */
+
+#define RTE_REGEX_OPS_REQ_MATCH_HIGH_PRIORITY_F (1 << 5)
+/**< In High Priority mode a maximum of one match will be returned per scan to
+ * reduce the post-processing required by the application. The match with the
+ * lowest Rule id, lowest start pointer and lowest match length will be
+ * returned.
+ *
+ * @see struct rte_regex_ops::nb_actual_matches
+ * @see struct rte_regex_ops::nb_matches
+ */
+
+
+/* Enumerates RegEx response flags. */
+#define RTE_REGEX_OPS_RSP_PMI_SOJ_F (1 << 0)
+/**< Indicates that the RegEx device has encountered a partial match at the
+ * start of scan in the given buffer.
+ *
+ * @see RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F
+ */
+
+#define RTE_REGEX_OPS_RSP_PMI_EOJ_F (1 << 1)
+/**< Indicates that the RegEx device has encountered a partial match at the
+ * end of scan in the given buffer.
+ *
+ * @see RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F
+ */
+
+#define RTE_REGEX_OPS_RSP_MAX_SCAN_TIMEOUT_F (1 << 2)
+/**< Indicates that the RegEx device has exceeded the max timeout while
+ * scanning the given buffer.
+ *
+ * @see RTE_REGEXDEV_ATTR_MAX_SCAN_TIMEOUT
+ */
+
+#define RTE_REGEX_OPS_RSP_MAX_MATCH_F (1 << 3)
+/**< Indicates that the RegEx device has exceeded the max matches while
+ * scanning the given buffer.
+ *
+ * @see RTE_REGEXDEV_ATTR_MAX_MATCHES
+ */
+
+#define RTE_REGEX_OPS_RSP_MAX_PREFIX_F (1 << 4)
+/**< Indicates that the RegEx device has reached the max allowed prefix length
+ * while scanning the given buffer.
+ *
+ * @see RTE_REGEXDEV_ATTR_MAX_PREFIX
+ */
+
+/**
+ * The generic *rte_regex_ops* structure to hold the RegEx attributes
+ * for enqueue and dequeue operation.
+ */
+struct rte_regex_ops {
+	/* W0 */
+	uint16_t req_flags;
+	/**< Request flags for the RegEx ops.
+	 * @see RTE_REGEX_OPS_REQ_*
+	 */
+	uint16_t rsp_flags;
+	/**< Response flags for the RegEx ops.
+	 * @see RTE_REGEX_OPS_RSP_*
+	 */
+	uint16_t nb_actual_matches;
+	/**< The total number of actual matches detected by the Regex device.*/
+	uint16_t nb_matches;
+	/**< The total number of matches returned by the RegEx device for this
+	 * scan. The size of *rte_regex_ops::matches* zero length array will be
+	 * this value.
+	 *
+	 * @see struct rte_regex_ops::matches, struct rte_regexdev_match
+	 */
+
+	/* W1 */
+	struct rte_mbuf *mbuf; /**< source mbuf, to search in. */
+
+	/* W2 */
+	uint16_t group_id0;
+	/**< First group_id to match the rule against. At minimum one group
+	 * should be valid. Behaviour is undefined non of the groups are valid.
+	 *
+	 * @see RTE_REGEX_OPS_REQ_GROUP_ID0_VALID_F
+	 */
+	uint16_t group_id1;
+	/**< Second group_id to match the rule against.
+	 *
+	 * @see RTE_REGEX_OPS_REQ_GROUP_ID1_VALID_F
+	 */
+	uint16_t group_id2;
+	/**< Third group_id to match the rule against.
+	 *
+	 * @see RTE_REGEX_OPS_REQ_GROUP_ID2_VALID_F
+	 */
+	uint16_t group_id3;
+	/**< Forth group_id to match the rule against.
+	 *
+	 * @see RTE_REGEX_OPS_REQ_GROUP_ID3_VALID_F
+	 */
+
+	/* W3 */
+	RTE_STD_C11
+	union {
+		uint64_t user_id;
+		/**< Application specific opaque value. An application may use
+		 * this field to hold application specific value to share
+		 * between dequeue and enqueue operation.
+		 * Implementation should not modify this field.
+		 */
+		void *user_ptr;
+		/**< Pointer representation of *user_id* */
+	};
+
+	/* W4 */
+	RTE_STD_C11
+	union {
+		uint64_t cross_buf_id;
+		/**< ID used by the RegEx device in order to support cross
+		 * packet detection.
+		 * This ID is returned from the RegEx device on the dequeue
+		 * function. The application must send it back when calling
+		 * enqueue with the following packet.
+		 */
+		void *cross_buf_ptr;
+		/**< Pointer representation of *corss_buf_id* */
+	};
+
+	/* W5 */
+	struct rte_regexdev_match matches[];
+	/**< Zero length array to hold the match tuples.
+	 * The struct rte_regex_ops::nb_matches value holds the number of
+	 * elements in this array.
+	 *
+	 * @see struct rte_regex_ops::nb_matches
+	 */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Enqueue a burst of scan request on a RegEx device.
+ *
+ * The rte_regexdev_enqueue_burst() function is invoked to place
+ * regex operations on the queue *qp_id* of the device designated by
+ * its *dev_id*.
+ *
+ * The *nb_ops* parameter is the number of operations to process which are
+ * supplied in the *ops* array of *rte_regexdev_op* structures.
+ *
+ * The rte_regexdev_enqueue_burst() function returns the number of
+ * operations it actually enqueued for processing. A return value equal to
+ * *nb_ops* means that all packets have been enqueued.
+ *
+ * @param dev_id
+ *   The identifier of the device.
+ * @param qp_id
+ *   The index of the queue pair which packets are to be enqueued for
+ *   processing. The value must be in the range [0, nb_queue_pairs - 1]
+ *   previously supplied to rte_regexdev_configure().
+ * @param ops
+ *   The address of an array of *nb_ops* pointers to *rte_regexdev_op*
+ *   structures which contain the regex operations to be processed.
+ * @param nb_ops
+ *   The number of operations to process.
+ *
+ * @return
+ *   The number of operations actually enqueued on the regex device. The return
+ *   value can be less than the value of the *nb_ops* parameter when the
+ *   regex devices queue is full or if invalid parameters are specified in
+ *   a *rte_regexdev_op*. If the return value is less than *nb_ops*, the
+ *   remaining ops at the end of *ops* are not consumed and the caller has
+ *   to take care of them.
+ */
+__rte_experimental
+uint16_t
+rte_regexdev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
+			   struct rte_regex_ops **ops, uint16_t nb_ops);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Dequeue a burst of scan response from a queue on the RegEx device.
+ * The dequeued operation are stored in *rte_regexdev_op* structures
+ * whose pointers are supplied in the *ops* array.
+ *
+ * The rte_regexdev_dequeue_burst() function returns the number of ops
+ * actually dequeued, which is the number of *rte_regexdev_op* data structures
+ * effectively supplied into the *ops* array.
+ *
+ * A return value equal to *nb_ops* indicates that the queue contained
+ * at least *nb_ops* operations, and this is likely to signify that other
+ * processed operations remain in the devices output queue. Applications
+ * implementing a "retrieve as many processed operations as possible" policy
+ * can check this specific case and keep invoking the
+ * rte_regexdev_dequeue_burst() function until a value less than
+ * *nb_ops* is returned.
+ *
+ * The rte_regexdev_dequeue_burst() function does not provide any error
+ * notification to avoid the corresponding overhead.
+ *
+ * @param dev_id
+ *   The RegEx device identifier
+ * @param qp_id
+ *   The index of the queue pair from which to retrieve processed packets.
+ *   The value must be in the range [0, nb_queue_pairs - 1] previously
+ *   supplied to rte_regexdev_configure().
+ * @param ops
+ *   The address of an array of pointers to *rte_regexdev_op* structures
+ *   that must be large enough to store *nb_ops* pointers in it.
+ * @param nb_ops
+ *   The maximum number of operations to dequeue.
+ *
+ * @return
+ *   The number of operations actually dequeued, which is the number
+ *   of pointers to *rte_regexdev_op* structures effectively supplied to the
+ *   *ops* array. If the return value is less than *nb_ops*, the remaining
+ *   ops at the end of *ops* are not consumed and the caller has to take care
+ *   of them.
+ */
+__rte_experimental
+uint16_t
+rte_regexdev_dequeue_burst(uint8_t dev_id, uint16_t qp_id,
+			   struct rte_regex_ops **ops, uint16_t nb_ops);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_REGEXDEV_H_ */
diff --git a/lib/librte_regexdev/rte_regexdev_version.map b/lib/librte_regexdev/rte_regexdev_version.map
new file mode 100644
index 0000000..d400624
--- /dev/null
+++ b/lib/librte_regexdev/rte_regexdev_version.map
@@ -0,0 +1,26 @@
+EXPERIMENTAL {
+	global:
+
+	rte_regexdev_count;
+	rte_regexdev_get_dev_id;
+	rte_regexdev_info_get;
+	rte_regexdev_configure;
+	rte_regexdev_queue_pair_setup;
+	rte_regexdev_start;
+	rte_regexdev_stop;
+	rte_regexdev_close;
+	rte_regexdev_attr_get;
+	rte_regexdev_attr_set;
+	rte_regexdev_rule_db_update;
+	rte_regexdev_rule_db_compile_activate;
+	rte_regexdev_rule_db_import;
+	rte_regexdev_rule_db_export;
+	rte_regexdev_xstats_names_get;
+	rte_regexdev_xstats_get;
+	rte_regexdev_xstats_by_name_get;
+	rte_regexdev_xstats_reset;
+	rte_regexdev_selftest;
+	rte_regexdev_dump;
+	rte_regexdev_enqueue_burst;
+	rte_regexdev_dequeue_burst;
+};
diff --git a/lib/meson.build b/lib/meson.build
index 4cbbca0..1086582 100644
--- a/lib/meson.build
+++ b/lib/meson.build
@@ -25,7 +25,7 @@ libraries = [
 	'gro', 'gso', 'ip_frag', 'jobstats',
 	'kni', 'latencystats', 'lpm', 'member',
 	'power', 'pdump', 'rawdev',
-	'rib', 'reorder', 'sched', 'security', 'stack', 'vhost',
+	'regexdev', 'rib', 'reorder', 'sched', 'security', 'stack', 'vhost',
 	# ipsec lib depends on net, crypto and security
 	'ipsec',
 	#fib lib depends on rib
-- 
1.8.3.1


^ permalink raw reply	[flat|nested] 96+ messages in thread

* [dpdk-dev] [PATCH v4 2/4] regexdev: add regex core h file
  2020-07-02  7:45 ` [dpdk-dev] [PATCH v4 " Ori Kam
  2020-07-02  7:46   ` [dpdk-dev] [PATCH v4 1/4] regexdev: introduce regexdev subsystem Ori Kam
@ 2020-07-02  7:46   ` Ori Kam
  2020-07-02  7:46   ` [dpdk-dev] [PATCH v4 3/4] regexdev: add regexdev core functions Ori Kam
                     ` (2 subsequent siblings)
  4 siblings, 0 replies; 96+ messages in thread
From: Ori Kam @ 2020-07-02  7:46 UTC (permalink / raw)
  To: jerinj, xiang.w.wang
  Cc: guyk, dev, pbhagavatula, shahafs, hemant.agrawal, opher, alexr,
	dovrat, pkapoor, nipun.gupta, bruce.richardson, yang.a.hong,
	harry.chang, gu.jian1, shanjiangh, zhangy.yun, lixingfu, wushuai,
	yuyingxia, fanchenggang, davidfgao, liuzhong1, zhaoyong11, oc,
	jim, hongjun.ni, deri, fc, arthur.su, thomas, orika

This commit introduce the rte_regexdev_core.h file.
This file holds internal structures and API that are used by
the regexdev.

Signed-off-by: Ori Kam <orika@mellanox.com>
Acked-by: Guy Kaneti <guyk@marvell.com>
---
v4:
* No changes.

v3:
* Align internal function pointers API to the RTE level API.
 
v2:
* Move private data to rte_regexdev struct.
---
 lib/librte_regexdev/Makefile            |   1 +
 lib/librte_regexdev/meson.build         |   2 +-
 lib/librte_regexdev/rte_regexdev.h      |   2 +
 lib/librte_regexdev/rte_regexdev_core.h | 161 ++++++++++++++++++++++++++++++++
 4 files changed, 165 insertions(+), 1 deletion(-)
 create mode 100644 lib/librte_regexdev/rte_regexdev_core.h

diff --git a/lib/librte_regexdev/Makefile b/lib/librte_regexdev/Makefile
index 6f4cc63..9012d29 100644
--- a/lib/librte_regexdev/Makefile
+++ b/lib/librte_regexdev/Makefile
@@ -24,6 +24,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_REGEXDEV) := rte_regexdev.c
 
 # export include files
 SYMLINK-$(CONFIG_RTE_LIBRTE_REGEXDEV)-include += rte_regexdev.h
+SYMLINK-$(CONFIG_RTE_LIBRTE_REGEXDEV)-include += rte_regexdev_core.h
 
 # versioning export map
 EXPORT_MAP := rte_regexdev_version.map
diff --git a/lib/librte_regexdev/meson.build b/lib/librte_regexdev/meson.build
index f4db748..1816754 100644
--- a/lib/librte_regexdev/meson.build
+++ b/lib/librte_regexdev/meson.build
@@ -3,5 +3,5 @@
 
 allow_experimental_apis = true
 sources = files('rte_regexdev.c')
-headers = files('rte_regexdev.h')
+headers = files('rte_regexdev.h', 'rte_regexdev_core.h')
 deps += ['mbuf']
diff --git a/lib/librte_regexdev/rte_regexdev.h b/lib/librte_regexdev/rte_regexdev.h
index 7e688d9..bbc56f9 100644
--- a/lib/librte_regexdev/rte_regexdev.h
+++ b/lib/librte_regexdev/rte_regexdev.h
@@ -1466,6 +1466,8 @@ struct rte_regex_ops {
 rte_regexdev_dequeue_burst(uint8_t dev_id, uint16_t qp_id,
 			   struct rte_regex_ops **ops, uint16_t nb_ops);
 
+#include "rte_regexdev_core.h"
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/lib/librte_regexdev/rte_regexdev_core.h b/lib/librte_regexdev/rte_regexdev_core.h
new file mode 100644
index 0000000..fa6d297
--- /dev/null
+++ b/lib/librte_regexdev/rte_regexdev_core.h
@@ -0,0 +1,161 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2019 Mellanox Corporation
+ */
+
+#ifndef _RTE_REGEX_CORE_H_
+#define _RTE_REGEX_CORE_H_
+
+/**
+ * @file
+ *
+ * RTE RegEx Device internal header.
+ *
+ * This header contains internal data types, that are used by the RegEx devices
+ * in order to expose their ops to the class.
+ *
+ * Applications should not use these API directly.
+ *
+ */
+
+struct rte_regexdev;
+
+typedef int (*regexdev_info_get_t)(struct rte_regexdev *dev,
+				   struct rte_regexdev_info *info);
+/**< @internal Get the RegEx device info. */
+
+typedef int (*regexdev_configure_t)(struct rte_regexdev *dev,
+				    const struct rte_regexdev_config *cfg);
+/**< @internal Configure the RegEx device. */
+
+typedef int (*regexdev_qp_setup_t)(struct rte_regexdev *dev,