Re: hardware timestamping of packets

[Vlad Balan <hbalan%usc.edu@localhost>]

Hi Darren,

On Tue, Jun 12, 2012 at 7:36 PM, Darren Reed <darrenr%netbsd.org@localhost> 
wrote:
> On 13/06/2012 8:44 AM, Vlad Balan wrote:
> ...
>> First of all, most hardware cards that claim to do timestamping can
>> only timestamp a limited number of packets and use filters in order to
>> determine which packets to stamp.
> ...
>> When the filter is disabled and all packets are
>> timestamped, the registers are no longer locked and the timestamp
>> always corresponds to the latest received packet. Therefore if you
>> have multiple packets in one interrupt, you only get the hardware
>> timestamp of the last one. The only way to go around this (at least
>> for the Intel card) is to set a filter that makes most packet arrivals
>> create an interrupt, but then capturing at line speed would probably
>> not be feasible.
>
> What is the resolution of the time stamp?
> Microseconds? Nanoseconds? Picoseconds?
> Or is it in some other measure, such as ticks?
>

The Intel card that I looked at returns values in 16ns increments. I
think the natural resolution would be nanoseconds.

>> Another issue has to do with the interface when timestamping TX
>> packets. Timestamps are returned over the socket as ancillary data,
>> which means that they come with the associated packet. Of course, on
>> the transmit side there is no incoming packet, so what Linux does is
>> to copy the outgoing packet into a third queue associated with each
>> socket (the error queue, this seems Linux specific) and attach the
>> timestamp as ancillary data to that. This extension is not impossible
>> to add to NetBSD, however I wanted to check with you before adding a
>> third queue to the sockets. Linux uses a specific flag in recvmsg to
>> indicate that it wants a packet from the error queue.
>
> Why wouldn't it be appropriate to use SCM_TIMESTAMP or
> something similar to that?
>

That works on the receive path, however on the send path we still want
in some scenarios to know, on the sender machine, when the packet was
sent. sendmsg does not return information, so we must call recvmsg to
get the ancillary data. The data is obtained by calling recvmsg on the
error queue, where the copy of the sent packet, together with the
ancillary data that tells us when the packet was sent, is waiting to
be read.

>> The third issue has to do with transmitting timestamps associated with
>> packets from the driver level to the socket level, where they can be
>> transformed into ancillary information to be returned to the users.
>
> I would recommend investigating use of m_tag.

This is a good idea. That's what I get for using Stevens as my only
reference :) I should look at all the newer additions to the kernel,
but this definitely seems like a good way to go.
>
> Darren