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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <469958e00905220939w69b401aeq47903d48977166c7@mail.gmail.com>
Date:	Fri, 22 May 2009 09:39:28 -0700
From:	Caitlin Bestler <caitlin.bestler@...il.com>
To:	Rémi Denis-Courmont 
	<remi.denis-courmont@...ia.com>
Cc:	ext Arnaldo Carvalho de Melo <acme@...hat.com>,
	David Miller <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Chris Van Hoof <vanhoof@...hat.com>,
	Clark Williams <williams@...hat.com>
Subject: Re: [RFC 1/2] net: Introduce recvmmsg socket syscall

2009/5/22 Rémi Denis-Courmont <remi.denis-courmont@...ia.com>:
> On Thursday 21 May 2009 02:06:52 ext Arnaldo Carvalho de Melo wrote:
>> +       /*
>> +        * We may return less entries than requested (vlen) if the
>> +        * sock is non block and there aren't enough datagrams.
>> +        */
>> +       if (err == 0 || (err == -EAGAIN && (flags & MSG_DONTWAIT)))
>> +               return datagrams;
>>         return err;
>>  }
>
> Could there be a situation whereby we receive one or more datagrams, then get
> an error? How does userland get the datagrams then?
>

This is exactly how a server using SOCK_DGRAM or SOCK_SEQPACKET would
want to work -- give me up to N messages received over time X (waiting at most
time Y after the first message is received).

The server application then:
+ wakes up with at most Y delay on delivery of any single message.
+ but wakes up only once during that period (unless N or more messages
are received)
+ wakes up at least every X to deal with idle processing.

It could simply wake up every y msecs, then use recvmmsg to receive
everything that is there,
but that would mean a lot of idle wake-ups when the number of clients is low.

These are all less relevant for SOCK_STREAM since statistical
averaging of incoming
messages is rarely feasible for a single connection.

As commented earlier, however, it would make sense for each transport
to be able to
declare a given message to be "urgent" (by whatever means appropriate
to that transport)
and thereby trigger an earlier delivery. RDMA interfaces use a
"solicited event" bit for
these purposes.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html