On May 14, 2016, at 12:30 AM, Richard Cochran <richardcoch...@gmail.com> wrote:
> On Fri, May 13, 2016 at 04:12:52PM -0700, Guy Harris wrote:
>> The Linux implementation currently implements the inquiry by doing a
>> ETHTOOL_GET_TS_INFO SIOETHTOOL ioctl and looking at the
>> so_timestamping bits, if the linux/ethtool.h header defines
>> ETHTOOL_GET_TS_INFO and the ioctl succeeds on the device.
>
> So far, so good.
>
>> This is inadequate - as libpcap requests hardware time stamping for
>> all packets, it should also check whether HWTSTAMP_FILTER_ALL is set
>> in rx_filters, and only offer hardware time stamping if it's set.
>
> The SO_TIMESTAMPING and SIOCSHWTSTAMP interfaces predate
> ETHTOOL_GET_TS_INFO, and they work fine without it. Applications
> should simply use SIOCSHWTSTAMP to request the mode that they need and
> check the result.
So if you have a GUI application for packet capture, with a combo box to select
the type of time stamping, should it:
1) regardless of whether ETHTOOL_GET_TS_INFO is available, open the
adapter, try each of the time stamp types to see whether it works, and show a
combo box based on that;
2) use ETHTOOL_GET_TS_INFO if available;
3) offer all possibilities regardless of whether they work with the
adapter or not, and just report an error for possibilities that don't work?
My preference is 2) - which is the main reason why libpcap offers "what
possibilities are available?" APIs, not just "request this possibility" APIs.
