On Fri, May 19, 2017 at 6:11 AM, Miroslav Lichvar <mlich...@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 <mlich...@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.
