[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140304173804.GA4279@netboy>
Date: Tue, 4 Mar 2014 18:38:05 +0100
From: Richard Cochran <richardcochran@...il.com>
To: Andy Lutomirski <luto@...capital.net>
Cc: Network Development <netdev@...r.kernel.org>
Subject: Re: What is SOF_TIMESTAMPING_RX_HARDWARE?
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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists