> -----Original Message-----
> From: dev <[email protected]> On Behalf Of Olivier Matz
> Sent: Thursday, July 11, 2019 1:07 PM
> To: Stephen Hemminger <[email protected]>
> Cc: [email protected]
> 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 <[email protected]> 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 */
};
# 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?
# 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.
# 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?
