lkml.org 
[lkml]   [2023]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH net-next v7 15/16] net: ethtool: ts: Let the active time stamping layer be selectable
    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.

    \
     
     \ /
      Last update: 2023-11-22 18:00    [W:4.569 / U:0.000 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site