On Nov 26, 2012, at 12:56 AM, Cheng Cheng <ccheng....@gmail.com> wrote:
> In order to get the accurate receiving timestamp of a packet on the NIC
> device not supporting hardware timestamping, can I modify the NIC device
> driver code to update skb_shared_hwtstamp struct by using TSC in RX routine?
Well, that's arguably an abuse of skb_shared_hwtstamp, as it's *not* the NIC
that's time-stamping the packet. If the NIC timestamps the packet, the time
stamp can be applied either at the time it detects the first bit of the packet
or at the time it detects the last bit of the packet (depending on how it
decides to time-stamp the packet); if the driver timestamps the packet, the
time stamp cannot be applied before the driver is called, so there is, at
minimum, a delay due to the time it takes to respond to the interrupt and call
the driver. You would also want to disable any form of "interrupt batching",
including polling, so that there isn't a delay between the point at which the
NIC receives the packet and when the driver is called.
It would probably be not be considered A Good Idea to put a change such as that
into the official kernel source; if you tried to get a patch for that accepted,
it might not be accepted.
But, in theory, you could do that. The TSC wouldn't be sufficient by itself,
as it just counts processor ticks, and you'd have to convert those to
seconds-since-the-Epoch, that being what pcap and applications using pcap
expect. You probably want to use something such as do_gettimeofday(), which
returns seconds-since-the-Epoch and, as far as I know, uses the TSC on x86
processors, if the TSC is available (but you're probably not running on an
80386 or 80486, so it should be available), to provide higher-resolution times.
> Will pcap support to retrieve such timestamp from skb_shared_hwtstamp?
Recent versions of pcap (I forget whether that was added in 1.2.0 or 1.3.0)
support:
pcap_list_tstamp_types(), which lists all the time stamp types
supported by an interface;
pcap_set_tstamp_type(), which sets the time stamp type to use.
The default time stamp type is PCAP_TSTAMP_HOST, which is "whatever the capture
mechanism gives you by default", which would be the software time stamp on
Linux (and most other platforms). The other options available on Linux, if
your kernel supports hardware timestamping, are:
PCAP_TSTAMP_ADAPTER - hardware time stamp, shifted to synchronize it
with the system time stamp;
PCAP_TSTAMP_ADAPTER_UNSYNCED - hardware time stamp, *not* shifted;
both of which are seconds-since-the-Epoch (well, actually,
PCAP_TSTAMP_ADAPTER_UNSYNCED might be a count of seconds that have elapsed
since the Epoch, rather than seconds-since-the-Epoch, but you *really* don't
want me to start ranting about POSIX and leap seconds...).
If the program doing the capture supports those two APIs, as recent versions of
tcpdump do, you can get the hardware time stamp or, in your case, the
pretends-to-be-hardware time stamp. With tcpdump, you'd use the −j flag to set
it, with the argument "adapter" or "adapter_unsynced". Wireshark doesn't
currently support it; I don't know whether any programs other than tcpdump do.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
