On Fri, May 19, 2017 at 6:11 AM, Miroslav Lichvar [off-list ref] wrote:

On Thu, May 18, 2017 at 03:38:30PM -0400, Willem de Bruijn wrote:

quoted

On Thu, May 18, 2017 at 10:07 AM, Miroslav Lichvar [off-list ref] wrote:

quoted

+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."

quoted

quoted

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.