Re: [RFC 1/2] net: Introduce recvmmsg socket syscall

[Arnaldo Carvalho de Melo <acme@redhat.com>]

Em Thu, May 21, 2009 at 10:26:58AM -0700, Caitlin Bestler escreveu:
> On Thu, May 21, 2009 at 9:55 AM, Arnaldo Carvalho de Melo
> <acme@ghostprotocols.net> wrote:
> 
> >
> > I.e. recvmmsg would save the value of sk->sk_rcvtimeo at entry and
> > restore at exit, and would somehow go on subtracting the time
> > sock_recvmsg() took from it so that the following call finds a reduced
> > sk->sk_rcvtimeo iif it was configured in the first place and the socket
> > is in blocking mode.
> >
> > How does that sound?
> >
> 
> I suspect that an additional timeout value will be needed ultimately.

So you mean we need a timeout to wait for a datagram, that remains being
sk->sk_rcvtimeo (SO_RCVTIMEO), and one that is passed as a parameter to
recvmmsg?
 
> Essentially there is the existing timeout (how long will I wait before I
> want to be told that there have been no messages) and an additional
> "delivery pending" timeout (how long can the delivery of a message
> be delayed to attempt to coalesce it with other messages).

I gather this is an yes for the question I asked above :)
 
> There is also one sticky compliance issue with SCTP, delivery of an
> UNORDERED message MUST NOT be delayed waiting for other traffic.
> There is no guarantee that the local client will be scheduled immediately,
> just a prohibition on delaying delivery for the purpose of bundling.
> 
> That might mean a specific transport would have to support multiple
> conditional timeouts: maximum delay after an SCTP Event, after an
> UNORDERED message, after a message with PPID X, etc. Or for
> TCP after a PUSH FLAG, or after certain flags have been set, etc.
> 
> Those could probably be reduced to delivering immediately after
> any message that the transport flags as "urgent", and *all* error
> completions are urgent (which is what the code first shown does).

checking if MSG_OOB is set in the last datagram returned by the
unlocked_recvmsg call, that would make recvmmsg return imediately even
if in blocking mode and not having filled the array, ok.
 
> The specific transport could then use setsockopt to control what
> messages qualified as "urgent" in a transport specific manner.

OK

- Arnaldo