Re: hardware timestamping of packets

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

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?
-- 
Matt