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  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]
Date:	Fri, 22 May 2009 09:39:28 -0700
From:	Caitlin Bestler <>
To:	Rémi Denis-Courmont 
Cc:	ext Arnaldo Carvalho de Melo <>,
	David Miller <>,
	"" <>,
	Chris Van Hoof <>,
	Clark Williams <>
Subject: Re: [RFC 1/2] net: Introduce recvmmsg socket syscall

2009/5/22 Rémi Denis-Courmont <>:
> 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
More majordomo info at

Powered by blists - more mailing lists