io-uring.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Pavel Begunkov <asml.silence@gmail.com>,
	io-uring <io-uring@vger.kernel.org>
Subject: Re: [RFC] fixed files
Date: Sun, 9 Feb 2020 10:04:29 -0700	[thread overview]
Message-ID: <f4956223-0aa0-5157-6964-28e934595d20@kernel.dk> (raw)
In-Reply-To: <8ac7e520-c94e-22e1-3518-db8432debb6b@gmail.com>

On 2/9/20 5:18 AM, Pavel Begunkov wrote:
> On 2/8/2020 11:15 PM, Jens Axboe wrote:
>> On 2/8/20 6:28 AM, Pavel Begunkov wrote:
>>> Hi,
>>>
>>> As you remember, splice(2) needs two fds, and it's a bit of a pain
>>> finding a place for the second REQ_F_FIXED_FILE flag. So, I was
>>> thinking, can we use the last (i.e. sign) bit to mark an fd as fixed? A
>>> lot of userspace programs consider any negative result of open() as an
>>> error, so it's more or less safe to reuse it.
>>>
>>> e.g.
>>> fill_sqe(fd) // is not fixed
>>> fill_sqe(buf_idx | LAST_BIT) // fixed file
>>
>> Right now we only support 1024 fixed buffers anyway, so we do have some
>> space there. If we steal a bit, it'll still allow us to expand to 32K of
>> fixed buffers in the future.
>>
>> It's a bit iffy, but like you, I don't immediately see a better way to
>> do this that doesn't include stealing an IOSQE bit or adding a special
>> splice flag for it. Might still prefer the latter, to be honest...
> 
> "fixed" is clearly a per-{fd,buffer} attribute. If I'd now design it
> from the scratch, I would store fixed-resource index in the same field
> as fds and addr (but not separate @buf_index), and have per-resource
> switch-flag somewhere. And then I see 2 convenient ways:
> 
> 1. encode the fixed bit into addr and fd, as supposed above.
> 
> 2. Add N generic IOSQE_FIXED bits (i.e. IOSQE_FIXED_RESOURSE{1,2,...}),
> which correspond to resources (fd, buffer, etc) in order of occurrence
> in an sqe. I wouldn't expect having more than 3-4 flags.
> 
> And then IORING_OP_{READ,WRITE}_FIXED would have been the same opcode as
> the corresponding non-fixed version. But backward-compatibility is a pain.

It's always much easier looking back, hindsight is much clearer. I'd also
expand the sqe flags bits to 16 at least, but oh well.

I do think that for this particular case we add a SPLICE_F_FD1_FIXED and
ditto for fd2, and just have the direct splice/vmsplice syscalls reject
them as invalid. Both splice and vmsplice -EINVAL for unknown flags,
which makes this possible.

That seems cleaner to me than trying to shoe-horn this information into
the sqe itself, and it can easily be done as a prep patch to adding
splice support.

-- 
Jens Axboe


  reply	other threads:[~2020-02-09 17:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-08 13:28 [RFC] fixed files Pavel Begunkov
2020-02-08 20:15 ` Jens Axboe
2020-02-09 12:18   ` Pavel Begunkov
2020-02-09 17:04     ` Jens Axboe [this message]
2020-02-09 17:53       ` Pavel Begunkov

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 \
    --in-reply-to=f4956223-0aa0-5157-6964-28e934595d20@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=asml.silence@gmail.com \
    --cc=io-uring@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).