Re: hardware timestamping of packets

[Darren Reed <darrenr%netbsd.org@localhost>]

On 14/06/2012 5:42 AM, Matthew Mondor wrote:
> On Thu, 14 Jun 2012 02:12:06 +1000
> Darren Reed <darrenr%netbsd.org@localhost> wrote:
> 
>>> 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.
>>
>> And how do you tie something received with recvmsg() with something sent
>> via sendmsg()?
> 
> I was wondering the same: should one then recvmsg(2) from the error
> queue every packet after sendmsg(2) to ensure synchronization?  What
> happens if the application doesn't, will those accumulate in the "error
> queue", or is there room for a single packet there?  Another common
> idiom would be getsockopt(2) to obtain status, but this has the same
> difficulties...
> 
> It also makes the protocol synchronous, with two syscalls required per
> sent packet.  I wonder if there's precedent on some other OSs for a
> sendmsg(2) variant which can accept a  struct msghdr *?  If so, would
> this be realistic using our current network+device stack to have the
> status filled before the syscall returns?

That I don't know - it may be a good question to go back to
Intel with as they may have some exposure to what folks are
doing software wise in order to take advantage of their hardware.

Darren