public inbox for [email protected]
 help / color / mirror / Atom feed
From: Bijan Mottahedeh <[email protected]>
To: Pavel Begunkov <[email protected]>, [email protected]
Cc: [email protected]
Subject: Re: [PATCH 0/8] io_uring: buffer registration enhancements
Date: Mon, 16 Nov 2020 16:21:49 -0800	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>


>> This patchset is the follow-on to my previous RFC which implements a
>> set of enhancements to buffer registration consistent with existing file
>> registration functionality:
> 
> I like the idea of generic resource handling
> 
>>
>> - buffer registration updates		IORING_REGISTER_BUFFERS_UPDATE
>> 					IORING_OP_BUFFERS_UPDATE
> 
> Do you need it for something specific?

Incremental buffer registration, see below.

> 
>>
>> - readv/writev with fixed buffers	IOSQE_FIXED_BUFFER
> 
> Why do we need it?

It makes fixed files/buffers APIs more consistent, and once the initial 
work of generic resource handling is done, the additional work for this 
support is not much I think.

> 
>>
>> - buffer registration sharing		IORING_SETUP_SHARE_BUF
>> 					IORING_SETUP_ATTACH_BUF
> 
> I haven't looked it up. What's the overhead on that?
> And again, do you really need it?

For our use case, a DB instance may have a shared memory size of TB 
order and very large number of processes (1000+) using that memory.  The 
cost of each process registering that memory could become prohibitive.

We need to allow for incremental buffer registration given the 
potentially large size of the shared memory.  It also makes the API 
between files/buffers more consistent.

I had a chat with Jens a while back and he also felt that the static 
nature of buffer registrations and the requirement to reload the full 
set in case of changes was problematic.

> 
> The set is +600 lines, so just want to know that there is
> a real benefit from having it.

Sure, understood.


      reply	other threads:[~2020-11-17  0:24 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-12 23:00 [PATCH 0/8] io_uring: buffer registration enhancements Bijan Mottahedeh
2020-11-12 23:00 ` [PATCH 1/8] io_uring: modularize io_sqe_buffer_register Bijan Mottahedeh
2020-11-12 23:00 ` [PATCH 2/8] io_uring: modularize io_sqe_buffers_register Bijan Mottahedeh
2020-11-12 23:00 ` [PATCH 3/8] io_uring: generalize fixed file functionality Bijan Mottahedeh
2020-11-12 23:00 ` [PATCH 4/8] io_uring: implement fixed buffers registration similar to fixed files Bijan Mottahedeh
2020-11-15 13:33   ` Pavel Begunkov
2020-11-16 21:24     ` Bijan Mottahedeh
2020-11-16 23:09       ` Pavel Begunkov
2020-11-17  0:41         ` Bijan Mottahedeh
2020-11-12 23:00 ` [PATCH 5/8] io_uring: generalize files_update functionlity to rsrc_update Bijan Mottahedeh
2020-11-12 23:00 ` [PATCH 6/8] io_uring: support buffer registration updates Bijan Mottahedeh
2020-11-18 20:17   ` Pavel Begunkov
2020-12-09  0:42     ` Bijan Mottahedeh
2020-11-12 23:00 ` [PATCH 7/8] io_uring: support readv/writev with fixed buffers Bijan Mottahedeh
2020-11-17 11:04   ` Pavel Begunkov
2020-11-17 22:59     ` Bijan Mottahedeh
2020-11-18  9:14       ` Pavel Begunkov
2020-11-18 20:12       ` Pavel Begunkov
     [not found]         ` <[email protected]>
     [not found]           ` <[email protected]>
2020-11-19 19:27             ` Bijan Mottahedeh
2020-11-12 23:00 ` [PATCH 8/8] io_uring: support buffer registration sharing Bijan Mottahedeh
2020-11-16 23:28 ` [PATCH 0/8] io_uring: buffer registration enhancements Pavel Begunkov
2020-11-17  0:21   ` Bijan Mottahedeh [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox