Netdev Archive on
help / color / mirror / Atom feed
From: Jens Axboe <>
To: Josh Triplett <>
Cc: Pavel Begunkov <>,,
	"David S . Miller" <>,
	Jakub Kicinski <>,,,
	Stefan Metzmacher <>
Subject: Re: [PATCH v2 0/4] open/accept directly into io_uring fixed file table
Date: Sun, 15 Aug 2021 09:05:55 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <YRiNGTL2Dp/7vNzt@localhost>

On 8/14/21 9:42 PM, Josh Triplett wrote:
> On Sat, Aug 14, 2021 at 05:03:44PM -0600, Jens Axboe wrote:
>> What's the plan in terms of limiting the amount of direct descriptors
>> (for lack of a better word)? That seems like an important aspect that
>> should get sorted out upfront.
> [...]
>> Maybe we have a way to size the direct table, which will consume entries
>> from the same pool that the regular file table does? That would then
>> work both ways, and could potentially just be done dynamically similarly
>> to how we expand the regular file table when we exceed its current size.
> I think we'll want a way to size the direct table regardless, so that
> it's pre-allocated and doesn't need to be resized when an index is used.

But how do you size it then? I can see this being used into the hundreds
of thousands of fds easily, and right now the table is just an array
(though split into segments, avoiding huge allocs).

> Then, we could do one of two equally easy things, depending on what
> policy we want to set:
> - Deduct the full size of the fixed-file table from the allowed number
>   of files the process can have open. So, if RLIMIT_NOFILE is 1048576,
>   and you pre-allocate 1000000 entries in the fixed-file table, you can
>   have no more than 48576 file descriptors open. Stricter, but
>   potentially problematic: a program *might* expect that it can
>   dup2(some_fd, nofile - 1) successfully.
> - Use RLIMIT_NOFILE as the maximum size of the fixed-file table. There's
>   precedent for this: we already use RLIMIT_NOFILE as the maximum number
>   of file descriptors you can have in flight over UNIX sockets.
> I personally would favor the latter; it seems simple and
> straightforward.

I strongly prefer the latter too, and hopefully that's palatable since
the default limits are quite low anyway. And, as you say, it already is
done for inflight fds as well.

Jens Axboe

  reply	other threads:[~2021-08-15 15:06 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-13 16:43 Pavel Begunkov
2021-08-13 16:43 ` [PATCH v2 1/4] net: add accept helper not installing fd Pavel Begunkov
2021-08-13 16:43 ` [PATCH v2 2/4] io_uring: openat directly into fixed fd table Pavel Begunkov
2021-08-13 16:43 ` [PATCH v2 3/4] io_uring: hand code io_accept() fd installing Pavel Begunkov
2021-08-13 16:43 ` [PATCH v2 4/4] io_uring: accept directly into fixed file table Pavel Begunkov
2021-08-13 19:00 ` [PATCH v2 0/4] open/accept directly into io_uring " Josh Triplett
2021-08-14 12:50   ` Pavel Begunkov
2021-08-14 23:03     ` Jens Axboe
2021-08-15  3:42       ` Josh Triplett
2021-08-15 15:05         ` Jens Axboe [this message]
2021-08-15 15:12           ` Jens Axboe
2021-08-15 13:00       ` Pavel Begunkov
2021-08-15  3:31     ` Josh Triplett
2021-08-15 10:48       ` Pavel Begunkov
2021-08-15 14:23         ` Pavel Begunkov
2021-08-16 15:45 ` Stefan Metzmacher
2021-08-17  9:33   ` Pavel Begunkov
2021-08-17 14:57     ` Jens Axboe

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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH v2 0/4] open/accept directly into io_uring fixed file table' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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