On Tue, Mar 4, 2014 at 2:10 AM, Richard Cochran <richardcochran@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html