| Message ID | 20170518140738.19617-6-mlichvar@redhat.com |
|---|---|
| State | Superseded, archived |
| Delegated to: | David Miller |
| Headers | show |
On Thu, May 18, 2017 at 10:07 AM, Miroslav Lichvar <mlichvar@redhat.com> wrote: > The scm_timestamping struct may return multiple non-zero fields, e.g. > when both software and hardware RX timestamping is enabled, or when the > SO_TIMESTAMP(NS) option is combined with SCM_TIMESTAMPING and a false > software timestamp is generated in the recvmsg() call in order to always > return a SCM_TIMESTAMP(NS) message. > > CC: Richard Cochran <richardcochran@gmail.com> > CC: Willem de Bruijn <willemb@google.com> > Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com> Thanks for adding this! > +Note that if the SO_TIMESTAMP or SO_TIMESTAMPNS option is enabled > +together with SO_TIMESTAMPING using SOF_TIMESTAMPING_SOFTWARE, a false > +software timestamp will be generated in the recvmsg() call and passed > +in ts[0] when a real software timestamp is missing. With receive software timestamping this is expected behavior? I would make explicit that this happens even on tx timestamps. > For this reason it > +is not recommended to combine SO_TIMESTAMP(NS) with SO_TIMESTAMPING. And I'd remove this. The extra timestamp is harmless, and we may be missing other reasons why someone would want to enable both on the same socket.
On Thu, May 18, 2017 at 03:38:30PM -0400, Willem de Bruijn wrote: > On Thu, May 18, 2017 at 10:07 AM, Miroslav Lichvar <mlichvar@redhat.com> wrote: > > +Note that if the SO_TIMESTAMP or SO_TIMESTAMPNS option is enabled > > +together with SO_TIMESTAMPING using SOF_TIMESTAMPING_SOFTWARE, a false > > +software timestamp will be generated in the recvmsg() call and passed > > +in ts[0] when a real software timestamp is missing. > > With receive software timestamping this is expected behavior? I would make > explicit that this happens even on tx timestamps. How about adding ", e.g. when receive timestamping is enabled between receiving the message and the recvmsg() call, or it is a message with a hardware transmit timestamp." ? > > For this reason it > > +is not recommended to combine SO_TIMESTAMP(NS) with SO_TIMESTAMPING. > > And I'd remove this. The extra timestamp is harmless, and we may be missing > other reasons why someone would want to enable both on the same socket. Ok. I'm just concerned people will inadvertently use the timestamp as a real timestamp and then wonder why SW TX timestamping is so bad. I have fallen into this trap.
On Fri, May 19, 2017 at 6:11 AM, Miroslav Lichvar <mlichvar@redhat.com> wrote: > On Thu, May 18, 2017 at 03:38:30PM -0400, Willem de Bruijn wrote: >> On Thu, May 18, 2017 at 10:07 AM, Miroslav Lichvar <mlichvar@redhat.com> wrote: >> > +Note that if the SO_TIMESTAMP or SO_TIMESTAMPNS option is enabled >> > +together with SO_TIMESTAMPING using SOF_TIMESTAMPING_SOFTWARE, a false >> > +software timestamp will be generated in the recvmsg() call and passed >> > +in ts[0] when a real software timestamp is missing. >> >> With receive software timestamping this is expected behavior? I would make >> explicit that this happens even on tx timestamps. > > How about adding ", e.g. when receive timestamping is enabled > between receiving the message and the recvmsg() call, or it is a > message with a hardware transmit timestamp." ? Perhaps even more brief "This happens also on hardware tx timestamps." >> > For this reason it >> > +is not recommended to combine SO_TIMESTAMP(NS) with SO_TIMESTAMPING. >> >> And I'd remove this. The extra timestamp is harmless, and we may be missing >> other reasons why someone would want to enable both on the same socket. > > Ok. I'm just concerned people will inadvertently use the timestamp as > a real timestamp and then wonder why SW TX timestamping is so bad. I > have fallen into this trap. So have I. It is equally surprising when only enabling SO_TIMESTAMP and observing out of order timestamps. It is certainly worth calling out.
diff --git a/Documentation/networking/timestamping.txt b/Documentation/networking/timestamping.txt index 600c6bf..74b7c61 100644 --- a/Documentation/networking/timestamping.txt +++ b/Documentation/networking/timestamping.txt @@ -321,7 +321,7 @@ struct scm_timestamping { }; The structure can return up to three timestamps. This is a legacy -feature. Only one field is non-zero at any time. Most timestamps +feature. At least one field is non-zero at any time. Most timestamps are passed in ts[0]. Hardware timestamps are passed in ts[2]. ts[1] used to hold hardware timestamps converted to system time. @@ -330,6 +330,12 @@ a HW PTP clock source, to allow time conversion in userspace and optionally synchronize system time with a userspace PTP stack such as linuxptp. For the PTP clock API, see Documentation/ptp/ptp.txt. +Note that if the SO_TIMESTAMP or SO_TIMESTAMPNS option is enabled +together with SO_TIMESTAMPING using SOF_TIMESTAMPING_SOFTWARE, a false +software timestamp will be generated in the recvmsg() call and passed +in ts[0] when a real software timestamp is missing. For this reason it +is not recommended to combine SO_TIMESTAMP(NS) with SO_TIMESTAMPING. + 2.1.1 Transmit timestamps with MSG_ERRQUEUE For transmit timestamps the outgoing packet is looped back to the
The scm_timestamping struct may return multiple non-zero fields, e.g. when both software and hardware RX timestamping is enabled, or when the SO_TIMESTAMP(NS) option is combined with SCM_TIMESTAMPING and a false software timestamp is generated in the recvmsg() call in order to always return a SCM_TIMESTAMP(NS) message. CC: Richard Cochran <richardcochran@gmail.com> CC: Willem de Bruijn <willemb@google.com> Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com> --- Documentation/networking/timestamping.txt | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)