netdev - Re: [PATCH v2 for-next 3/3] io_uring: support multishot in recvmsg

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] [day] [month] [year] [list]

Message-ID: <bd096fecad204c2ecf831cf96ac84b1f82b853ce.camel@fb.com>
Date:   Thu, 14 Jul 2022 09:20:24 +0000
From:   Dylan Yudaken <dylany@...com>
To:     "io-uring@...r.kernel.org" <io-uring@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "David.Laight@...LAB.COM" <David.Laight@...LAB.COM>,
        "axboe@...nel.dk" <axboe@...nel.dk>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "asml.silence@...il.com" <asml.silence@...il.com>
CC:     Kernel Team <Kernel-team@...com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH v2 for-next 3/3] io_uring: support multishot in recvmsg

On Thu, 2022-07-14 at 07:46 +0000, David Laight wrote:
> From: Dylan Yudaken
> > Sent: 13 July 2022 09:23
> > 
> > Similar to multishot recv, this will require provided buffers to be
> > used. However recvmsg is much more complex than recv as it has
> > multiple
> > outputs. Specifically flags, name, and control messages.
> ...
> 
> Why is this any different from adding several 'recvmsg' requests
> into the request ring?
> 
> IIUC the requests are all processed sequentially by a single thread.
> 

In practice it is mostly the same for UDP (apart from userspace having
to predict how many recvmsg requests it should add).  That approach
would also have a slight ordering race, which probably is not a problem
for protocols that don't guarantee ordering, but might be annoying.

For stream like TCP it would not be possible due to the ordering issues
(completions of separate SQEs have no guaranteed ordering). You would
have to link the SQE's to preserve ordering, but then you would still
have to wait for a batch to complete before submitting a new batch.

Apart from those practical reasons, performance wise it is better for a
few reasons
 * userspace doesn't have to submit new requests
 * the io_uring knows it's multishot, so doesn't teardown the poll each
time
 * io_uring can allocate the request and associated async data only
once and reuse it

Regards,
Dylan

>         David
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes,
> MK1 1PT, UK
> Registration No: 1397386 (Wales)
>