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

Ori Kam orika at mellanox.com
Wed Apr 8 09:37:40 CEST 2020



> -----Original Message-----
> From: dev <dev-bounces at 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 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
> > > > +
> > > > +/**
> > > > + * @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.
> >
> >
> >


More information about the dev mailing list