[dpdk-dev] [PATCH v1 2/4] regexdev: add regex core h file

Jerin Jacob jerinjacobk at gmail.com
Tue Apr 7 18:27:27 CEST 2020


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

> Hi Guy,
>
> > -----Original Message-----
> > From: dev <dev-bounces at dpdk.org> On Behalf Of Guy Kaneti
> > Sent: Tuesday, April 7, 2020 11:54 AM
> > To: Ori Kam <orika at mellanox.com>; Jerin Jacob Kollanukkaran
> > <jerinj at marvell.com>; xiang.w.wang at intel.com
> > Cc: dev at dpdk.org; Pavan Nikhilesh Bhagavatula
> > <pbhagavatula at marvell.com>; Shahaf Shuler <shahafs at mellanox.com>;
> > hemant.agrawal at nxp.com; Opher Reviv <opher at mellanox.com>; Alex
> > Rosenbaum <alexr at mellanox.com>; Dovrat Zifroni <dovrat at marvell.com>;
> > Prasun Kapoor <pkapoor at marvell.com>; nipun.gupta at nxp.com;
> > bruce.richardson at intel.com; yang.a.hong at intel.com; harry.chang at intel.com
> ;
> > gu.jian1 at zte.com.cn; shanjiangh at chinatelecom.cn;
> > zhangy.yun at chinatelecom.cn; lixingfu at huachentel.com; wushuai at inspur.com;
> > yuyingxia at yxlink.com; fanchenggang at sunyainfo.com;
> > davidfgao at tencent.com; liuzhong1 at chinaunicom.cn;
> > zhaoyong11 at huawei.com; oc at yunify.com; jim at netgate.com;
> > hongjun.ni at intel.com; j.bromhead at titan-ic.com; deri at ntop.org;
> > fc at napatech.com; arthur.su at lionic.com; Thomas Monjalon
> > <thomas at monjalon.net>; Parav Pandit <parav at 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.
>
>
>


More information about the dev mailing list