Re: [PATCH v2] Enable retrieving of RTNET network packet timestamp OOB using recvmsg()

["François Legal" <devel@thom.fr.eu.org>]

Le Mardi, Juillet 27, 2021 18:44 CEST, Jan Kiszka <jan.kiszka@siemens.com> a écrit:

> On 27.07.21 14:13, François Legal wrote:
> > Le Lundi, Juillet 26, 2021 14:01 CEST, Jan Kiszka <jan.kiszka@siemens.com> a écrit:
> >
> >> On 17.05.21 11:44, François Legal via Xenomai wrote:
> >>> This patch enables retrieving, in realtime application, of RTNET enabled adapters packet timestamps.
> >>> It uses the linux semantic SO_TIMESTAMPNS, and the linux code to put the timestamp in the control_msg structure.
> >>>
> >>> I tested this patch with af_packet sockets only. UDP  & TCP might be a little bit trickier as many fragment/segments get reassembled in a single recvmsg. I believe the linux code I used to put the timestamps in the control structure should be OK though.
> >>
> >> One of my question on v1 is still open: How does Linux handle stamping
> >> the context of fragmented UDP and TCP packets? And given that you enable
> >> it for those protocols as well, we should likely test that too.
> >
> > I thought I already gave an answer to this. Sorry.
> > Linux does not handle time stamping of UDP and TCP as far as I understand.
>
> Does Linux return an error when you try to enable this for UDP or TCP
> sockets?

Alright so I rechecked everything again. Linux does not return an error when requesting timestamping for UDP or TCP (or any other kind of socket it seems).

Despite my previous assertion, timestamping is supported for UDP  and if I understood the code correctly, only one timestamp is returned in any case (the time stamp of the last received datagram). This is done in reassembly queues, where the queue always keep the timestamp of the last received datagram, and when doing the reassembly, this last timestamp is reported to the re created skb.

For TCP it is definitely not supported.

So I should modify the patch to make it comply with what linux does I guess ?

>
> > I certainly plan to use the UDP timestamping feature at some point in the future, but maybe I can exclude UDP and TCP for the moment, and stick to af_packet which has be tested by myself. I'll resubmit another patch with (at least) udp support whenever I need it and have time to test it.
> >
> > What do you think ?
>
> We need at least a plan how to evolve that interface. Actually doing
> that can then happen in steps, yes.
>
> Jan
>
> --
> Siemens AG, T RDA IOT
> Corporate Competence Center Embedded Linux