On Fri, Oct 13, 2023 at 10:46:06AM -0700, Jakub Kicinski wrote: > On Fri, 13 Oct 2023 20:09:03 +0300 Vladimir Oltean wrote: > > > > Translation between the UAPI-visible PHC index and MAC, DMA, phylib > > > > PHY, other PHY etc can then be done by the kernel as needed. > > > > > > Translation by the kernel at which point? > > > > The gist of what I'm proposing is for the core ethtool netlink message > > handler to get just the phc_index as an attribute. No other information > > as to what it represents. Not that it's netdev, DMA, phylib PHY or whatnot. > > > > The ethtool kernel code would iterate through the stuff registered in > > the system for the netdev, calling get_ts_info() or phy_ts_info() on it, > > until it finds something which populates struct ethtool_ts_info :: > > phc_index with the phc_index retrieved from netlink. > > > > Then, ethtool just talks with the timestamper that matched that phc_index. > > > > Same idea would be applied for the command that lists all timestamping > > layers for a netdev. Check get_ts_info(), phy_ts_info(dev->phydev), and > > can be extended in the future. > > I see, that could work. The user would then dig around sysfs to figure > out which PHC has what characteristics? Yup. /sys/class/ptp/ptp<N>/ gives you everything else you need to know about the PHC index that's configured as the active timestamper for this netdev. It's just that (and I need to stress this again) the timestamping-capable DMA blocks that you're talking about, but I've never seen, should be able to fully implement a ptp_clock, with their own clock operations and friends. > > > IMHO it'd indeed be clearer for the user to have an ability to read > > > the PHC for SOF_..._DMA via ETHTOOL_MSG_TS_LIST_GET_REPLY as a separate > > > entry, rather than e.g. assume that DMA uses the same PHC as MAC. > > > > I'm not really sure what you're referring to, with SOF_..._DMA. > > The DMA, if presented as a PHC as I am proposing, would play the role of > > the hardware timestamp provider (think SOF_TIMESTAMPING_TX_HARDWARE | > > SOF_TIMESTAMPING_RX_HARDWARE), so there will be no driver-visible > > special socket option flags for DMA timestamping. > > Each packet may want different timestamp tho, especially on Tx it > should be fairly easy for socket to request to get "real" MAC stamps, > while most get cheaper DMA stamps. Currently some drivers run flow > matching to find PTP packets and automatically give them better quality > timestamps :( > > Even if at the config level we use PHCs we need to translate that into > some SKBTX_* bit, don't we? I think Richard had something to say about that being wishful thinking: https://lore.kernel.org/netdev/ZGw46hrpiqCVNeXS@xxxxxxxxxxxxxxxxxx/ On RX I'm not sure how you'd know in advance if the packet is going to be routed to a socket that wants DMA or MAC timestamps. And having a socket with hardware timestamps from one provider in one direction, and another provider in the other direction, is.... not sane as a kernel API?
