On Mon, Nov 20, 2023 at 09:37:23AM -0800, Jakub Kicinski wrote: > On Mon, 20 Nov 2023 16:23:16 +0200 Vladimir Oltean wrote: > > In previous email discussions, I was proposing to Jakub and you "what if > > we didn't let user space select a specific layer like PHY_TIMESTAMPING > > or MAC_TIMESTAMPING at all, but just select a specific phc_index as the > > provider of hardware timestamps"? > > What about my use case of having a NIC which can stamp at a low rate > at the PHY (for PTP) and high rate at the DMA block (for congestion > control)? Both stamp points have the same PHC index. Well, first of all, given my understanding of the "laws of physics", I think something has to give in your use case description. I can't see how on RX, the NIC can decide in advance whether to provide low rate MAC timestamps for packets going to a socket and high rate DMA timestamps for packets going to another socket. It can either provide MAC timestamps, or DMA timestamps, or an unreliable, unpresentable to user space, mix. But maybe I'm wrong and there are NICs which can do that filtering. If such NIC exists, then I guess a SOF_TIMESTAMPING_RX_DMA flag should be added to the socket layer, and the NIC driver provides timestamps according to the skb->sk->sk_tsflags, and that problem is completely out of scope for Köry's patch set - and implicitly compatible with it, since as you say, the device-wide timestamping layer - PHC index - does not really change. If I'm not wrong and the MAC-or-DMA timestamp selection is NIC-wide (which diverges from your problem description), then neither Köry's work nor my "everything is a phc_index" proposal will bring your use case to fruition without further work. Here I would avoid speculating, because a lot will depend upon the details which you haven't really given. One question will be whether, in the case of "NIC-wide DMA timestamps", DMA timestamps should be presented as hardware timestamps - struct scm_timestamping[2] from CMSG_DATA() - or as their own thing, that user space needs explicit support for - by parsing a new cmsg level/type. If DMA timestamps won't look to user space like hardware timestamps, then the use case is again out of scope for Köry's work, as far as I see it. Another simple question is - if NICs do this today - probably by giving the "unrepresentable mix" to user space in an implicit, hardcoded and very fine tuned way such that nobody bats an eye - then what is there more to support? Are you looking at extra UAPI as a way to legitimize hacks, or do you feel there is extra control that applications can gain?
