From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Cochran Subject: Re: What is SOF_TIMESTAMPING_RX_HARDWARE? Date: Tue, 4 Mar 2014 18:38:05 +0100 Message-ID: <20140304173804.GA4279@netboy> References: <20140304101030.GA8532@netboy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Network Development To: Andy Lutomirski Return-path: Received: from mail-ee0-f48.google.com ([74.125.83.48]:65196 "EHLO mail-ee0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751780AbaCDRiR (ORCPT ); Tue, 4 Mar 2014 12:38:17 -0500 Received: by mail-ee0-f48.google.com with SMTP id e51so3813016eek.35 for ; Tue, 04 Mar 2014 09:38:16 -0800 (PST) Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: 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