Hi,
su, 2025-02-09 kello 22:29 -0500, Willem de Bruijn kirjoitti:
> Pauli Virtanen wrote:
>
> > 1.3.2 Timestamp Reporting
> > ^^^^^^^^^^^^^^^^^^^^^^^^^
> > diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> > index bb2b751d274a..3707c9075ae9 100644
> > --- a/include/linux/skbuff.h
> > +++ b/include/linux/skbuff.h
> > @@ -489,10 +489,14 @@ enum {
> >
> > /* generate software time stamp when entering packet scheduling */
> > SKBTX_SCHED_TSTAMP = 1 << 6,
> > +
> > + /* generate software time stamp on packet tx completion */
> > + SKBTX_COMPLETION_TSTAMP = 1 << 7,
> > };
> >
> > #define SKBTX_ANY_SW_TSTAMP (SKBTX_SW_TSTAMP | \
> > - SKBTX_SCHED_TSTAMP)
> > + SKBTX_SCHED_TSTAMP | \
> > + SKBTX_COMPLETION_TSTAMP)
>
> These fields are used in the skb_shared_info tx_flags field.
> Which is a very scarce resource. This takes the last available bit.
> That is my only possible concern: the opportunity cost.
One alternative here could be:
Make SOF_TIMESTAMPING_TX_COMPLETION available only as a socket option,
and make it emit COMPLETION tstamp exactly for those packets that also
have SOF_TIMESTAMPING_TX_SOFTWARE enabled. User apps can then still
timestamp only selected packets via CMSG, however the choice between
SND and SND+COMPLETION is socket-wide. The API is then less uniform,
but probably usable in practice, although some use cases may not be
interested in the extra SND tstamps.
IIUC, sizeof skb_shared_info cannot be easily changed and I'm not sure
if there is room left there. So if the option of putting it into
protocol-specific skb cb is also out, then I'm not sure what the plan
here should be.
--
Pauli Virtanen
