On Wed, Nov 22, 2023 at 08:54:59AM -0800, Jakub Kicinski wrote: > On Wed, 22 Nov 2023 16:36:18 +0200 Vladimir Oltean wrote: > > @Jakub, for your long-term "MAC timestamps for PTP, DMA for everything else". > > How do you see this? I guess we need some sort of priority function in > > the UAPI between hwtstamp providers. > > > > And even with that, I think the enums that we currently have for filters > > are not specific enough. The most we could expose is: > > > > MAC provider DMA provider > > > > hwtstamp_rx_filters HWTSTAMP_FILTER_PTP_V2_EVENT HWTSTAMP_FILTER_ALL > > tx_type HWTSTAMP_TX_ON HWTSTAMP_TX_ON > > > > but it isn't clear: for PTP, does the DMA provider give you an RX > > timestamp too? > > If we phrase it as "precise / approximate" rather than "MAC / DMA" - it > seems fairly intuitive to give the best timestamp available for a given > packet, no? I wouldn't be so sure. The alternative interpretation "for PTP, give me timestamps from both sources" also sounds reasonable for the distant future where that will be possible (with proper cmsg identification). But I don't see how to distinguish the two - the filters, expressed in these terms, would be the same. > > What about a TX timestamp? > > I was thinking - socket flag to make packets for a given socket request > precise timestamps. So the ptp4l source code would have to be modified to still work with the same precision as before? I'm not seeing this through.
