On Mon, 20 Nov 2023 23:17:59 +0200 Vladimir Oltean wrote: > Forget the concept of an active hwtstamp provider, just open up the > knobs of _all_ possible hwtstamp providers for a NIC. Simultaneously! > To make one active and all the others inactive, just use > HWTSTAMP_FILTER_NONE/HWTSTAMP_TX_OFF for all except one, and the desired > enum hwtstamp_rx_filters / enum hwtstamp_tx_types for the active one. > Live with this expanded configuration model for a while, just restricted > for a single active timestamping layer, and then, once user space is > ready for an enhanced struct scm_timestamping which supports potentially > multiple cmsgs with distinct hwtstamps, remove the restriction and let > it all rip! Everybody gets their pony! > > Additionally, SIOCSHWTSTAMP is kinda rusty, has a fixed binary format, > and is not extensible to target a specific hwtstamp provider. So a > netlink conversion of that, as a first step, would of course be great. > > Is it an accurate summary? Yes. For now we can impose the requirement that only one can be active easily at the kernel level. But the uAPI should allow expressing more. > You've partially answered above. The mix of timestamps coming from the > PHY/MAC and those coming from the DMA is unrepresentable in today's > UAPI, and is just fine-tuned to work for the existing use case of "PTP > gets PHY/MAC, everything else gets DMA". > > Still not 100% clear what would the proper UAPI (separate user-controllable > RX filters for PHY, MAC and DMA) gain, in addition to what exists in mlx5. Too late for mlx5 but I'm anticipating that more vendors will start needing such configuration in the future. At which point it will be good to have an API in place.
