From: Pavel Begunkov <asml.silence@gmail.com>
To: io-uring@vger.kernel.org
Cc: asml.silence@gmail.com, bpf@vger.kernel.org
Subject: [PATCH v4 0/6] BPF controlled io_uring
Date: Tue, 27 Jan 2026 10:14:04 +0000 [thread overview]
Message-ID: <cover.1769470552.git.asml.silence@gmail.com> (raw)
Note: I'll be targeting 7.1 as it's rc7 and it can use some
time to settle down.
This series introduces a way to override the standard io_uring_enter
syscall execution with an extendible event loop, which can be controlled
by BPF via new io_uring struct_ops or from within the kernel.
There are multiple use cases I want to cover with this:
- Syscall avoidance. Instead of returning to the userspace for
CQE processing, a part of the logic can be moved into BPF to
avoid excessive number of syscalls.
- Access to in-kernel io_uring resources. For example, there are
registered buffers that can't be directly accessed by the userspace,
however we can give BPF the ability to peek at them. It can be used
to take a look at in-buffer app level headers to decide what to do
with data next and issuing IO using it.
- Smarter request ordering and linking. Request links are pretty
limited and inflexible as they can't pass information from one
request to another. With BPF we can peek at CQEs and memory and
compile a subsequent request.
- Feature semi-deprecation. It can be used to simplify handling
of deprecated features by moving it into the callback out core
io_uring. For example, it should be trivial to simulate
IOSQE_IO_DRAIN. Another target could be request linking logic.
- It can serve as a base for custom algorithms and fine tuning.
Often, it'd be impractical to introduce a generic feature because
it's either niche or requires a lot of configuration. For example,
there is support min-wait, however BPF can help to further fine tune
it by doing it in multiple steps with different number of CQEs /
timeouts. Another feature people were asking about is allowing
to over queue SQEs but make the kernel to maintain a given QD.
- Smarter polling. Napi polling is performed only once per syscall
and then it switches to waiting. We can do smarter and intermix
polling with waiting using the hook.
It might need more specialised kfuncs in the future, but the core
functionality is implemented with just two simple functions. One
returns region memory, which gives BPF access to CQ/SQ/etc. And
the second is for submitting requests. It's also given a structure
as an argument, which is used to pass waiting parameters.
It showed good numbers in a test that sequentially executes N nop
requests, where BPF was more than twice as fast than a 2-nop
request link implementation.
Pavel Begunkov (6):
io_uring: introduce callback driven main loop
io_uring/bpf-ops: add basic bpf struct_ops boilerplate
io_uring/bpf-ops: add loop_step struct_ops callback
io_uring/bpf-ops: add kfunc helpers
io_uring/bpf-ops: add bpf struct ops registration
selftests/io_uring: add a bpf io_uring selftest
include/linux/io_uring_types.h | 10 +
io_uring/Kconfig | 5 +
io_uring/Makefile | 3 +-
io_uring/bpf-ops.c | 265 +++++++++++++++++++
io_uring/bpf-ops.h | 28 ++
io_uring/io_uring.c | 8 +
io_uring/loop.c | 88 ++++++
io_uring/loop.h | 27 ++
tools/testing/selftests/Makefile | 3 +-
tools/testing/selftests/io_uring/Makefile | 143 ++++++++++
tools/testing/selftests/io_uring/basic.bpf.c | 116 ++++++++
tools/testing/selftests/io_uring/common.h | 6 +
tools/testing/selftests/io_uring/runner.c | 107 ++++++++
tools/testing/selftests/io_uring/types.bpf.h | 131 +++++++++
14 files changed, 938 insertions(+), 2 deletions(-)
create mode 100644 io_uring/bpf-ops.c
create mode 100644 io_uring/bpf-ops.h
create mode 100644 io_uring/loop.c
create mode 100644 io_uring/loop.h
create mode 100644 tools/testing/selftests/io_uring/Makefile
create mode 100644 tools/testing/selftests/io_uring/basic.bpf.c
create mode 100644 tools/testing/selftests/io_uring/common.h
create mode 100644 tools/testing/selftests/io_uring/runner.c
create mode 100644 tools/testing/selftests/io_uring/types.bpf.h
--
2.52.0
next reply other threads:[~2026-01-27 10:14 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-27 10:14 Pavel Begunkov [this message]
2026-01-27 10:14 ` [PATCH v4 1/6] io_uring: introduce callback driven main loop Pavel Begunkov
2026-01-27 10:14 ` [PATCH v4 2/6] io_uring/bpf-ops: add basic bpf struct_ops boilerplate Pavel Begunkov
2026-01-27 10:14 ` [PATCH v4 3/6] io_uring/bpf-ops: add loop_step struct_ops callback Pavel Begunkov
2026-01-27 10:14 ` [PATCH v4 4/6] io_uring/bpf-ops: add kfunc helpers Pavel Begunkov
2026-01-27 10:14 ` [PATCH v4 5/6] io_uring/bpf-ops: add bpf struct ops registration Pavel Begunkov
2026-01-27 10:14 ` [PATCH v4 6/6] selftests/io_uring: add a bpf io_uring selftest Pavel Begunkov
2026-01-27 17:32 ` Alexei Starovoitov
2026-01-27 18:42 ` Pavel Begunkov
2026-01-27 18:53 ` Alexei Starovoitov
2026-01-27 19:20 ` 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=cover.1769470552.git.asml.silence@gmail.com \
--to=asml.silence@gmail.com \
--cc=bpf@vger.kernel.org \
--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