On 14/06/2012 5:42 AM, Matthew Mondor wrote:
> On Thu, 14 Jun 2012 02:12:06 +1000
> Darren Reed <
darrenr@...> 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
