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: <469958e00905211026q468de6fbh2b5932d177b7c7a9@mail.gmail.com>
Date:	Thu, 21 May 2009 10:26:58 -0700
From:	Caitlin Bestler <caitlin.bestler@...il.com>
To:	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
Cc:	David Miller <davem@...emloft.net>, 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

On Thu, May 21, 2009 at 9:55 AM, Arnaldo Carvalho de Melo
<acme@...stprotocols.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.

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).

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).

The specific transport could then use setsockopt to control what
messages qualified as "urgent" in a transport specific manner.
--
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