From: Bijan Mottahedeh <[email protected]>
To: Pavel Begunkov <[email protected]>,
io-uring <[email protected]>
Subject: Re: [PATCH 7/8] io_uring: support readv/writev with fixed buffers
Date: Thu, 19 Nov 2020 11:27:38 -0800 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
On 11/19/2020 9:35 AM, Pavel Begunkov wrote:
> On 19/11/2020 02:34, Bijan Mottahedeh wrote:
>>
>>> Ok, there are 2 new patches in 5.10, you may wait for Jens to propagate it to
>>> 5.11 or just cherry-pick (no conflicts expected) them. On top apply ("io_uring:
>>> share fixed_file_refs b/w multiple rsrcs") to which I CC'ed you. It's
>>> simple enough so shouldn't be much problems with it.
>>>
>>> With that you need to call io_set_resource_node() every time you take
>>> a resource. That's it, _no_ extra ref_put for you to add in puts/free/etc.
>>
>> Thanks for the patches.
>>
>>> Also, consider that all ref_nodes of all types should be hooked into a
>>> single ->ref_list (e.g. file_data->ref_list).
>>
>> Just so I understand, would this common ref_list create any dependency between resource types when unregistering a given resource type?
>>
>> For example in
>>
>> io_sqe_files_unregister()
>> {
>>
>> ...
>> if (ref_node)
>> percpu_ref_kill(&ref_node->refs);
>>
>> percpu_ref_kill(&data->refs);
>> ...
>> }
>>
>> with the "order refnode recycling" patch, would files_unregister block until all requests using either fixed files or fixed buffers complete?
>
> Yes, IORING_UNREGISTER_FILES will block even if there is a fixed
> buffer request, but IORING_REGISTER_FILES_UPDATE would not.
>
> The latter follows RCU idea, it removes resources without blocking
> a syscall, so these resources are not accessible for new requests,
> but actual close(file), etc. happens sometime later after all previous
> requests with fixed resources (of any kind) complete.
>
> IORING_OP_FILES_UPDATE works similarly but I need to look it up
> to be sure.
>
> Does it answer you question?
>
I think so, we want to treat fixed resources as uniformly as possible.
The fact that the unregister dependency is intentional might not be
immediately obvious so some comments would be needed.
next prev parent reply other threads:[~2020-11-19 19:27 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 [this message]
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
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] \
/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