Re: [PATCH net-next RFC v4 2/5] net: Expose available time stamping layers to user space.

Vladimir Oltean
2023-05-19T13:28:11Z

On Fri, May 12, 2023 at 10:38:52AM -0700, Jakub Kicinski wrote:
> On Fri, 12 May 2023 13:29:11 +0300 Vladimir Oltean wrote:
> > On Thu, May 11, 2023 at 04:16:25PM -0700, Jakub Kicinski wrote:
> > > > I mean, I can't ignore the fact that there are NICs that can provide
> > > > 2-step TX timestamps at line rate for all packets (not just PTP) for
> > > > line rates exceeding 10G, in band with the descriptor in its TX
> > > > completion queue. I don't want to give any names, just to point out
> > > > that there isn't any inherent limitation in the technology.
> > >
> > > Oh, you should tell me, maybe off-list then. 'Cause I don't know any.
> >
> > I hope the examples given in private will make you reconsider the
> > validity of my argument about DMA timestamps.
>
> I may have lost track of what the argument is. There are devices
> which will provide a DMA stamp for Tx and Rx. We need an API that'll
> inform the user about it.
>
> To be clear I'm talking about drivers which are already in the tree,
> not opening the door for some shoddy new HW in.

So this is circling back to my original question (with emphasis on the
last part):

| Which drivers provide DMA timestamps, and how do they currently signal
| that they do this? Do they do this for all packets that get timestamped,
| or for "some"?

https://lore.kernel.org/netdev/20230511203646.ihljeknxni77uu5j@skbuf/

If only "some" packets (unpredictable which) get DMA timestamps when
a MAC timestamp isn't available, what UAPI can satisfactorily describe
that? And who would want that?