On Tue, 16 Jul 2019 11:39:50 +0200
Olivier Matz <olivier.m...@6wind.com> wrote:
> On Fri, Jul 12, 2019 at 12:23:19PM +0000, Jerin Jacob Kollanukkaran wrote:
> > > -----Original Message-----
> > > From: dev <dev-boun...@dpdk.org> On Behalf Of Olivier Matz
> > > Sent: Thursday, July 11, 2019 1:07 PM
> > > To: Stephen Hemminger <step...@networkplumber.org>
> > > Cc: dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags
> > >
> > > On Wed, Jul 10, 2019 at 10:49:17AM -0700, Stephen Hemminger wrote:
> > > > On Wed, 10 Jul 2019 11:29:07 +0200
> > > > Olivier Matz <olivier.m...@6wind.com> wrote:
> > > >
> > > > > /**
> > > > > * Indicate that the metadata field in the mbuf is in use.
> > > > > @@ -738,6 +741,8 @@ struct rte_mbuf {
> > > > > */
> > > > > struct rte_mbuf_ext_shared_info *shinfo;
> > > > >
> > > > > + uint64_t dynfield1; /**< Reserved for dynamic fields. */
> > > > > + uint64_t dynfield2; /**< Reserved for dynamic fields. */
> >
> > Since the mbuf size is fixed, What is the downside of union scheme[1] vs
> > upside of proposed scheme
> >
> > [1] Example like:
> > RTE_STD_C11
> > union {
> > void *userdata; /**< Can be used for external metadata */
> > uint64_t udata64; /**< Allow 8-byte userdata on 32-bit */
> > };
>
> In the particular case of userdata, the union is not an issue, it
> just means that there are several ways to represent the same data.
> If needed, it is possible to register a union as a dynamic field.
>
> In other case, like m->hash, having a union makes it impossible to
> use several features of the union at the same time. This would be
> solved by dynamic fields.
>
> > # The fields like mbuf: hash.usr, used in variety of use case together
> > Like libraries like distributor() and Eventdev using it. If we switch
> > to dynamic mbuf scheme, We wil take those field using
> > rte_mbuf_dynfield_register()
> > on library init?
>
> If we decide that these fields must be converted to a dynamic field,
> yes, each library/application will call rte_mbuf_dynfield_register().
>
> > # I see an upside of dynamic mbuf if we can add
> > rte_mbuf_dynfield_unregister API.
> > But can we ever do that? Because it will be complex if we need introduce
> > notification mechanism etc.
>
> An unregister mechanism seems hard to implement, or we can leave the
> hard part to the user: either ensure that no mbuf is in use anywhere, or
> that removing the dynamic field won't have any impact. But I'd prefer
> not introducing an unregistration function until we have a real use-case
> for it.
>
> > # In the real world use case, if with union scheme, fastpath API can simply
> > deference
> > specific element (say mbuf->fieldx). With dynamic scheme, the offset need
> > to store
> > in some other data structure and de reference in fastpath before assessing
> > the interested field.
> > Right?
>
> Yes, with dynamic fields, the offset is stored in a variable. A global
> variable (static to the file or module using it) does the job. This may
> have a small performance impact.
>
Applications are already using userdata reusing that in a driver
would cause a worse disaster than breaking ABI.
