Linux io-uring development
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Bernd Schubert <bernd.schubert@fastmail.fm>, io-uring@vger.kernel.org
Cc: Pavel Begunkov <asml.silence@gmail.com>,
	Miklos Szeredi <miklos@szeredi.hu>,
	Joanne Koong <joannelkoong@gmail.com>,
	Josef Bacik <josef@toxicpanda.com>
Subject: Re: Large CQE for fuse headers
Date: Fri, 11 Oct 2024 11:57:33 -0600	[thread overview]
Message-ID: <f83d5370-f026-4654-810a-199fb3e01038@kernel.dk> (raw)
In-Reply-To: <d66377d6-9353-4a86-92cf-ccf2ea6c6a9d@fastmail.fm>

On 10/10/24 2:56 PM, Bernd Schubert wrote:
> Hello,
> 
> as discussed during LPC, we would like to have large CQE sizes, at least
> 256B. Ideally 256B for fuse, but CQE512 might be a bit too much...
> 
> Pavel said that this should be ok, but it would be better to have the CQE
> size as function argument. 
> Could you give me some hints how this should look like and especially how
> we are going to communicate the CQE size to the kernel? I guess just adding
> IORING_SETUP_CQE256 / IORING_SETUP_CQE512 would be much easier.

Not Pavel and unfortunately I could not be at that LPC discussion, but
yeah I don't see why not just adding the necessary SETUP arg for this
would not be the way to go. As long as they are power-of-2, then all
it'll impact on both the kernel and liburing side is what size shift to
use when iterating CQEs.

Since this obviously means larger CQ rings, one nice side effect is that
since 6.10 we don't need contig pages to map any of the rings. So should
work just fine regardless of memory fragmentation, where previously that
would've been a concern.

-- 
Jens Axboe

  reply	other threads:[~2024-10-11 17:57 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-10 20:56 Large CQE for fuse headers Bernd Schubert
2024-10-11 17:57 ` Jens Axboe [this message]
2024-10-11 18:35   ` Bernd Schubert
2024-10-11 18:39     ` Jens Axboe
2024-10-11 19:03       ` Bernd Schubert
2024-10-11 19:24         ` Jens Axboe
2024-10-11 21:38 ` Pavel Begunkov
2024-10-12  1:55 ` Ming Lei
2024-10-12 14:38   ` Jens Axboe
2024-10-13 21:20     ` Bernd Schubert
2024-10-14  2:44       ` Ming Lei
2024-10-14 11:10         ` Miklos Szeredi
2024-10-14 12:47           ` Bernd Schubert
2024-10-14 13:34             ` Pavel Begunkov
2024-10-14 15:21               ` Bernd Schubert
2024-10-14 17:48                 ` Pavel Begunkov
2024-10-14 21:27                   ` Bernd Schubert
2024-10-16 10:54                     ` Miklos Szeredi
2024-10-16 11:53                       ` Bernd Schubert
2024-10-16 12:24                         ` Miklos Szeredi
2024-10-17  0:59                         ` Ming Lei
2024-10-14 13:20           ` Bernd Schubert
2024-10-14 10:31       ` Miklos Szeredi

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=f83d5370-f026-4654-810a-199fb3e01038@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=asml.silence@gmail.com \
    --cc=bernd.schubert@fastmail.fm \
    --cc=io-uring@vger.kernel.org \
    --cc=joannelkoong@gmail.com \
    --cc=josef@toxicpanda.com \
    --cc=miklos@szeredi.hu \
    /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