What is SOF_TIMESTAMPING_RX_HARDWARE?

What is SOF_TIMESTAMPING_RX_HARDWARE?

[Andy Lutomirski]

AFAICT is sets SOCK_TIMESTAMPING_RX_HARDWARE, which appears to do
exactly nothing.  If I'm right, should I submit a patch documenting
that fact and removing the getsockopt/setsockopt implementations?

On the other hand, SOCK_TIMESTAMPING_SYS_HARDWARE and
SOCK_TIMESTAMPING_RAW_HARDWARE actually work.

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: What is SOF_TIMESTAMPING_RX_HARDWARE?

[Richard Cochran]

On Mon, Mar 03, 2014 at 06:20:33PM -0800, Andy Lutomirski wrote:
> AFAICT is sets SOCK_TIMESTAMPING_RX_HARDWARE, which appears to do
> exactly nothing.  If I'm right, should I submit a patch documenting
> that fact and removing the getsockopt/setsockopt implementations?

Have you seen Documentation/networking/timestamping.txt?

  SOF_TIMESTAMPING_TX/RX determine how time stamps are generated.
  SOF_TIMESTAMPING_RAW/SYS determine how they are reported in the
  following control message:

This is the API that was invented (not by me) to support HW time stamp
reporting. I agree that it is confusing and complicated, but I don't
think you can remove the flag as it is a firmly established API.
Drivers do use this to advertise whether they support receive time
stamps in hardware.

AFAICT, the reason why setting this socket option is a noop is
this. Once receive time stamping is enabled at the driver level,
eligible skbs will get the information whether they want it or not.
It would be more work to hide this from sockets which haven't enabled
the option, and so we don't do it.

HTH,
Richard

Re: What is SOF_TIMESTAMPING_RX_HARDWARE?

[Andy Lutomirski]

On Tue, Mar 4, 2014 at 2:10 AM, Richard Cochran
<richardcochran@gmail.com> wrote:
> On Mon, Mar 03, 2014 at 06:20:33PM -0800, Andy Lutomirski wrote:
>> AFAICT is sets SOCK_TIMESTAMPING_RX_HARDWARE, which appears to do
>> exactly nothing.  If I'm right, should I submit a patch documenting
>> that fact and removing the getsockopt/setsockopt implementations?
>
> Have you seen Documentation/networking/timestamping.txt?
>
>   SOF_TIMESTAMPING_TX/RX determine how time stamps are generated.
>   SOF_TIMESTAMPING_RAW/SYS determine how they are reported in the
>   following control message:

I read it and focused on this part:

SOF_TIMESTAMPING_RX_HARDWARE:  return the original, unmodified time stamp
                               as generated by the hardware
SOF_TIMESTAMPING_RX_SOFTWARE:  if SOF_TIMESTAMPING_RX_HARDWARE is off or
                               fails, then do it in software
SOF_TIMESTAMPING_RAW_HARDWARE: return original raw hardware time stamp
SOF_TIMESTAMPING_SYS_HARDWARE: return hardware time stamp transformed to
                               the system time base

which is somewhere between useless and incorrect.

>
> This is the API that was invented (not by me) to support HW time stamp
> reporting. I agree that it is confusing and complicated, but I don't
> think you can remove the flag as it is a firmly established API.
> Drivers do use this to advertise whether they support receive time
> stamps in hardware.

Huh?  It may well be firmly established that
SOF_TIMESTAMPING_RX_HARDWARE exists as a flag and gets returned by
getsockopt after being set by setsockopt.  But I can't find any
evidence at all that drivers indicate *via getsockopt* anything
whatsoever.

So maybe the documentation should change to:

SOF_TIMESTAMPING_RX_HARDWARE and SOF_TIMESTAMPING_RX_SOFTWARE do
nothing at all when set using setsockopt.  (setsockopt will allow them
to be set for backwards compatibility.)  Theese are only used by
ETHTOOL_GET_TS_INFO.

or something like that.

I'd write a patch to get rid of SOCK_TIMESTAMPING_RX_HARDWARE, etc,
but that might break a program that sets the flag in setsockopt and
expects it to be returned by getsockopt.

->
> AFAICT, the reason why setting this socket option is a noop is
> this. Once receive time stamping is enabled at the driver level,
> eligible skbs will get the information whether they want it or not.
> It would be more work to hide this from sockets which haven't enabled
> the option, and so we don't do it.

In theory, the driver could stop reporting timestamps if
SOF_TIMESTAMPING_RAW_HARDWARE: and SOF_TIMESTAMPING_SYS_HARDWARE
aren't set.  I don't see why SOF_TIMESTAMPING_RX_HARDWARE would make
any sense in this context.

--Andy

Re: What is SOF_TIMESTAMPING_RX_HARDWARE?

[Richard Cochran]

On Tue, Mar 04, 2014 at 09:21:47AM -0800, Andy Lutomirski wrote:
> SOF_TIMESTAMPING_RX_HARDWARE:  return the original, unmodified time stamp
>                                as generated by the hardware
> SOF_TIMESTAMPING_RX_SOFTWARE:  if SOF_TIMESTAMPING_RX_HARDWARE is off or
>                                fails, then do it in software
> SOF_TIMESTAMPING_RAW_HARDWARE: return original raw hardware time stamp
> SOF_TIMESTAMPING_SYS_HARDWARE: return hardware time stamp transformed to
>                                the system time base
> 
> which is somewhere between useless and incorrect.

Right, especially since there is no fallback to SW time stamping on
receive. Every incoming skb gets a SW time stamp.

> I'd write a patch to get rid of SOCK_TIMESTAMPING_RX_HARDWARE, etc,
> but that might break a program that sets the flag in setsockopt and
> expects it to be returned by getsockopt.

There are programs setting this socket option. I am afraid that you
will not be able to remove this, otherwise you will break them.

> In theory, the driver could stop reporting timestamps if
> SOF_TIMESTAMPING_RAW_HARDWARE: and SOF_TIMESTAMPING_SYS_HARDWARE
> aren't set.  I don't see why SOF_TIMESTAMPING_RX_HARDWARE would make
> any sense in this context.

The lack of SOF_TIMESTAMPING_RX_HARDWARE would prevent the driver from
taking the HW time stamps, but the driver knows nothing about the
awaiting sockets. Possibly the kernel could tell drivers when this
flag is present on any socket that might be associated with a
particular interface, but I doubt that would buy us anything. So the
API makes some kind of sense in theory, but it practice the networking
stack just ignores this option.

Thanks,
Richard

Re: What is SOF_TIMESTAMPING_RX_HARDWARE?

[Richard Cochran]

On Tue, Mar 04, 2014 at 09:21:47AM -0800, Andy Lutomirski wrote:
> 
> In theory, the driver could stop reporting timestamps if
> SOF_TIMESTAMPING_RAW_HARDWARE: and SOF_TIMESTAMPING_SYS_HARDWARE
> aren't set.  I don't see why SOF_TIMESTAMPING_RX_HARDWARE would make
> any sense in this context.

AFAICT, the intent was that the former are handled by the stack, while
the latter is handled by the driver.

Thanks,
Richard

Re: What is SOF_TIMESTAMPING_RX_HARDWARE?

[Andy Lutomirski]

On Tue, Mar 4, 2014 at 9:42 AM, Richard Cochran
<richardcochran@gmail.com> wrote:
> On Tue, Mar 04, 2014 at 09:21:47AM -0800, Andy Lutomirski wrote:
>>
>> In theory, the driver could stop reporting timestamps if
>> SOF_TIMESTAMPING_RAW_HARDWARE: and SOF_TIMESTAMPING_SYS_HARDWARE
>> aren't set.  I don't see why SOF_TIMESTAMPING_RX_HARDWARE would make
>> any sense in this context.
>
> AFAICT, the intent was that the former are handled by the stack, while
> the latter is handled by the driver.

I suspect that any attempt to implement this will break userspace --
there must be programs my now (like mine!) that set
SOF_TIMESTAMPING_SYS_HARDWARE but not SOF_TIMESTAMPING_RX_HARDWARE.

I'll write a documentation patch.

--Andy