Re: [RFC PATCH 0/2]: hw timestamp support

[Guy Harris <guy () alum mit edu>]

On May 24, 2010, at 7:26 AM, Mcmillan, Scott A wrote:

> This patch adds the capability to select the packet timestamp source.  It also adds support for the PACKET_TIMESTAMP 
> Linux kernel setting to specify the source of packet timestamps.  The corresponding Linux kernel patch is being 
> submitted concurrently.

I've checked in a change, based on that one.  It adds a pcap_set_tstamp_type(), to be used between pcap_create() and 
pcap_activate(), to set the time stamp type.  The time stamp types are defined by libpcap; not all will necessarily be 
supported by a given device on a given platform.  This provides a more general mechanism, not tied to the details of 
the Linux time stamp mechanism, and potentially usable on other platforms; the purpose of libpcap is to provide 
interfaces that are as platform-independent as possible for using the very different packet capture and injection 
mechanisms on various platforms.

The ones supported when capturing with Linux PF_PACKET sockets are:

            PCAP_TSTAMP_HOST
                 Time stamp provided by the host on which the capture is being
                 done.  The precision of this time stamp  is  unspecified;  it
                 might  or  might  not be synchronized with the host operating
                 system’s clock.

            PCAP_TSTAMP_ADAPTER
                 Time stamp provided by the network adapter on which the  cap‐
                 ture  is  being  done.   This is a high‐precision time stamp,
                 synchronized with the host operating system’s clock.

            PCAP_TSTAMP_ADAPTER_UNSYNC
                 Time stamp provided by the network adapter on which the  cap‐
                 ture  is being done.  This is a high‐precision time stamp; it
                 is not synchronized with the host operating system’s clock.

PCAP_TSTAMP_HOST just uses the standard software time stamp mechanism.  PCAP_TSTAMP_ADAPTER and 
PCAP_TSTAMP_ADAPTER_UNSYNC use the hardware time stamp; the former is SOF_TIMESTAMPING_SYS_HARDWARE, the latter is 
SOF_TIMESTAMPING_RAW_HARDWARE.

Some additional time stamp types are

            PCAP_TSTAMP_HOST_LOWPREC
                 Time stamp provided by the host on which the capture is being
                 done.   This is a low‐precision time stamp, synchronized with
                 the host operating system’s clock.

            PCAP_TSTAMP_HOST_HIPREC
                 Time stamp provided by the host on which the capture is being
                 done.  This is a high‐precision time stamp; it might or might
                 not be synchronized with the host operating  system’s  clock.
                 It    might    be    more    expensive    to    fetch    than
                 PCAP_TSTAMP_HOST_LOWPREC.

These could be used, for example, with:

        the new time stamp mechanisms in FreeBSD ("fast" vs. "non-fast");

        WinPcap (it currently uses a Registry field to control whether to use KeQuerySystemTime() - low-precision, but 
doesn't have issues with MP machines or with the OS adjusting the CPU clock rate - or KeQueryPerformanceCounter() - 
high-precision, but...)

        WinPcap's support for the TurboCap card (low-precision without polling by the CPU, high-precision with polling 
by the CPU)

A given device on a given platform would not offer both PCAP_TSTAMP_HOST and the two PCAP_TSTAMP_HOST_ values; 
PCAP_TSTAMP_HOST is for use on platforms where you can't choose between low-precision and high-precision host-supplied 
time stamps.

There is a pcap_list_tstamp_types() call to get the supported time stamp types (which could be an empty list if you 
can't specify a time stamp type), and a corresponding pcap_free_tstamp_types() (forpcap_tstamp_type_val_to_name the 
benefit of Windows, where you have problems calling free() on something malloc()ated in a library if the program and 
the library were built with different versions of MSVC++), and:

        pcap_tstamp_type_name_to_val() - maps a short name for a time stamp type to the corresponding value:

                "host" -> PCAP_TSTAMP_HOST
                "host_lowprec" -> PCAP_TSTAMP_HOST_LOWPREC
                "host_hiprec" -> PCAP_TSTAMP_HOST_HIPREC
                "adapter" -> PCAP_TSTAMP_ADAPTER
                "adapter_unsynced" -> PCAP_TSTAMP_ADAPTER_UNSYNCED

        pcap_tstamp_type_val_to_name() - maps a time stamp type value to the corresponding short name

        pcap_tstamp_type_val_to_description() - maps a time stamp type value to a descriptive string, for use in, for 
example, a user interface:

                PCAP_TSTAMP_HOST -> "Host"
                PCAP_TSTAMP_HOST_LOWPREC -> "Host, low precision"
                PCAP_TSTAMP_HOST_HIPREC -> "Host, high precision"
                PCAP_TSTAMP_ADAPTER -> "Adapter"
                PCAP_TSTAMP_ADAPTER_UNSYNCED -> "Adapter, not synced with system time"

> A new command line option was added to tcpdump, -j, to specify the source of the packet timestamp.  Valid options are 
> 'raw' to use the raw NIC HW timestamp and 'nic' to use the NIC HW timestamp transformed into the system clock basis.  
> If the option is not specified, or OS or the NIC do not support HW timestamping, a software timestamp is used 
> (identical to the current behavior.)

I've kept that, but the values specified for "-j" are the short names as interpreted by pcap_tstamp_type_name_to_val(). 
 I've added a "-J" flag to request the list returned by pcap_list_tstamp_types().

If the new APIs aren't present, tcpdump won't support "-j" or "-J".  If they are, it will support them, to the extent 
that they do anything - on most platforms, "-J" will say that you can't change the time stamp type, and "-j" will 
reject all time stamp types.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.