[RFC v2 0/5] BPF controlled io_uring

Pavel Begunkov posted 5 patches 6 months, 2 weeks ago
include/linux/io_uring_types.h |   4 +
io_uring/Kconfig               |   5 +
io_uring/Makefile              |   1 +
io_uring/bpf.c                 | 277 +++++++++++++++++++++++++++++++++
io_uring/bpf.h                 |  45 ++++++
io_uring/io_uring.c            |  45 ++++--
io_uring/io_uring.h            |  11 +-
io_uring/napi.c                |   4 +-
8 files changed, 376 insertions(+), 16 deletions(-)
create mode 100644 io_uring/bpf.c
create mode 100644 io_uring/bpf.h
[RFC v2 0/5] BPF controlled io_uring
Posted by Pavel Begunkov 6 months, 2 weeks ago
This series adds io_uring BPF struct_ops, which allows processing
events and submitting requests from BPF without returning to user.
There is only one callback for now, it's called from the io_uring
CQ waiting loop when there is an event to be processed. It also
has access to waiting parameters like batching and timeouts.

It's tested with a program that queues a nop request, waits for
its completion and then queues another request, repeating it N
times. The baseline to compare with is traditional io_uring
application doing same without BPF and using 2 requests links,
with the same total number of requests.

# ./link 0 100000000
type 2-LINK, requests to run 100000000
sec 20, total (ms) 20374
# ./link 1 100000000
type BPF, requests to run 100000000
sec 13, total (ms) 13700

The BPF version works ~50% faster on a mitigated kernel, while it's
not even a completely fair comparison as links are restrictive and
can't always be used. Without links the speedup reaches ~80%.

This allows arbitrary relations between requests including using
a result from one request to configure the following one. There are
other use cases in mind that need access to in-kernel resources and
can't be implemented from userspace. On top, it can be extended with
more callbacks to get finer control over task work batching.

It's a prototype, I intend to remake the kfunc helpers, enchance
program verification, and fix some mild io_uring waiting edge
cases.

Kernel branch:
https://github.com/isilence/linux/tree/io-uring-bpf/v2
git https://github.com/isilence/linux.git io-uring-bpf/v2

Liburing + bpf bootsrap examples:
https://github.com/isilence/liburing/tree/bpf-struct-ops-examples
git git@github.com:isilence/liburing.git bpf-struct-ops-examples

Pavel Begunkov (5):
  io_uring: add struct for state controlling cqwait
  io_uring/bpf: add stubs for bpf struct_ops
  io_uring/bpf: implement struct_ops registration
  io_uring/bpf: add handle events callback
  io_uring/bpf: add basic kfunc helpers

 include/linux/io_uring_types.h |   4 +
 io_uring/Kconfig               |   5 +
 io_uring/Makefile              |   1 +
 io_uring/bpf.c                 | 277 +++++++++++++++++++++++++++++++++
 io_uring/bpf.h                 |  45 ++++++
 io_uring/io_uring.c            |  45 ++++--
 io_uring/io_uring.h            |  11 +-
 io_uring/napi.c                |   4 +-
 8 files changed, 376 insertions(+), 16 deletions(-)
 create mode 100644 io_uring/bpf.c
 create mode 100644 io_uring/bpf.h

-- 
2.49.0
Re: [RFC v2 0/5] BPF controlled io_uring
Posted by Jens Axboe 6 months, 2 weeks ago
On 6/6/25 7:57 AM, Pavel Begunkov wrote:
> This series adds io_uring BPF struct_ops, which allows processing
> events and submitting requests from BPF without returning to user.
> There is only one callback for now, it's called from the io_uring
> CQ waiting loop when there is an event to be processed. It also
> has access to waiting parameters like batching and timeouts.
> 
> It's tested with a program that queues a nop request, waits for
> its completion and then queues another request, repeating it N
> times. The baseline to compare with is traditional io_uring
> application doing same without BPF and using 2 requests links,
> with the same total number of requests.
> 
> # ./link 0 100000000
> type 2-LINK, requests to run 100000000
> sec 20, total (ms) 20374
> # ./link 1 100000000
> type BPF, requests to run 100000000
> sec 13, total (ms) 13700
> 
> The BPF version works ~50% faster on a mitigated kernel, while it's
> not even a completely fair comparison as links are restrictive and
> can't always be used. Without links the speedup reaches ~80%.

Nifty! Great to see the BPF side taking shape, I can think of many cool
things we could do with that. Out of curiosity, tested this on my usual
arm64 vm on the laptop:

axboe@m2max-kvm ~/g/l/examples-bpf (bpf) [1]> ./link 0 100000000
type 2-LINK, requests to run 100000000
sec 13, total (ms) 13868

axboe@m2max-kvm ~/g/l/examples-bpf (bpf)> sudo ./link 1 100000000
type BPF, requests to run 100000000
sec 4, total (ms) 4929

No mitigations or anything configured in this kernel.

I'll take a closer look at the patches.

-- 
Jens Axboe