03/11/2020 18:42, Stephen Hemminger:
> On Tue, 03 Nov 2020 17:20:20 +0100
> Thomas Monjalon <tho...@monjalon.net> wrote:
> > 03/11/2020 17:08, Stephen Hemminger:
> > > On Tue, 3 Nov 2020 15:09:15 +0100
> > > Thomas Monjalon <tho...@monjalon.net> wrote:
> > >
> > > > The mbuf field timestamp was announced to be removed for three reasons:
> > > > - a dynamic field already exist, used for Tx only
> > > > - this field always used 8 bytes even if unneeded
> > > > - this field is in the first half (cacheline) of mbuf
> > > >
> > > > After this series, the dynamic field timestamp is used for both Rx and
> > > > Tx
> > > > with separate dynamic flags to distinguish when the value is meaningful
> > > > without resetting the field during forwarding.
> > >
> > > There should be a place in documentation which describes all the
> > > dynamic fields and their meaning. For example, which drivers/features
> > > set the field and the exact meaning.
> >
> > A dynamic field can be registered by anyone, including the apps.
> > So you will never get a full list.
> > The meaning of each field should be defined in its context
> > (driver, lib or app).
> >
> > > Is the timestamp in HW units, UTC units, or TSC ticks?
> >
> > The timestamp unit is driver-specific.
> > It is explained in ethdev API:
> > http://doc.dpdk.org/api/rte__ethdev_8h.html#a4346bf07a0d302c9ba4fe06baffd3196
>
>
> Are there are any conventions we should use in this area?
> There could be overlapping usage between subsystems?
The name of the field should be prefixed with the right context
to avoid overlapping of different usages.
It is documented here:
http://doc.dpdk.org/api/rte__mbuf__dyn_8h.html
