[v1,2/4] regexdev: add regex core h file
Checks
Commit Message
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
Comments
> +
> +/**
> + * @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 */
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.
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.
>
>
>
> -----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.
> >
> >
> >
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.
> > >
> > >
> > >
>
>
> 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.
> > >
> > >
> > >
>
>
> > > 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).
> >
> > 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.
> > > >
> > > >
> > > >
> >
@@ -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
@@ -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']
@@ -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
new file mode 100644
@@ -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_ */