Re: [PATCH 4/5] io_uring: bpf: add buffer support for IORING_OP_BPF

[Caleb Sander Mateos <csander@purestorage.com>]

On Wed, Dec 31, 2025 at 3:02 AM Ming Lei <ming.lei@redhat.com> wrote:
>
> On Tue, Dec 30, 2025 at 08:42:11PM -0500, Caleb Sander Mateos wrote:
> > On Tue, Nov 4, 2025 at 8:22 AM Ming Lei <ming.lei@redhat.com> wrote:
> > >
> > > Add support for passing 0-2 buffers to BPF operations through
> > > IORING_OP_BPF. Buffer types are encoded in sqe->bpf_op_flags
> > > using dedicated 3-bit fields for each buffer.
> >
> > I agree the 2 buffer limit seems a bit restrictive, and it would make
> > more sense to expose kfuncs to import plain and fixed buffers. Then
> > the BPF program could decide what buffers to import based on the SQE,
> > BPF maps, etc. This would be analogous to how uring_cmd
> > implementations import buffers.
>
> Yes, this way is too restrictive.
>
> I think there are at least two approaches:
>
> - define public buffer descriptor, which can describe plain, fixed, vector,
> fixed vector buffer, ...
>
> - user can pass this buffer descriptor array from sqe->addr & sqe->len (buf descriptor
>   need to be defined in UAPI)
>
> OR
>
> - user can pass this buffer array from arena map (buf descriptor is just
> API between bpf prog and userspace)
>
> The former could be better, because `buf descriptor` is part of UAPI, and
> user still can choose to use bpf map to pass buffer. But defining 'buf
> descriptor' may take a while...
>
> The latter way could be easier to start...

I think the latter approach (buffer interface specific to io_uring BPF
program) probably makes more sense. Different programs may have
different buffer needs (e.g. 1 buffer, 2 buffers, an arbitrary number
of buffers). Programs that need an arbitrary number of buffers will
probably have to specify the address and length of a struct iovec
array in the SQE, or communicate via some BPF map. But this additional
indirection would add unnecessary overhead for programs that only
accept 1 or 2 buffers. Leaving it up to the io_uring BPF program how
to interpret the SQE fields makes a lot of sense to me, as
->uring_cmd() implementations already have that responsibility.

>
> >
> > >
> > > Buffer 1 can be:
> > > - None (no buffer)
> > > - Plain user buffer (addr=sqe->addr, len=sqe->len)
> > > - Fixed/registered buffer (index=sqe->buf_index, offset=sqe->addr,
> >
> > Should this say "addr=" instead of "offset="? It's passed as buf_addr
> > to io_bpf_import_buffer(), so it's an absolute userspace address. The
> > offset into the fixed buffer depends on the starting address of the
> > fixed buffer.
>
> For user fixed buffer, offset is the buff addr.
>
> For kernel fixed buffer, it is offset.

Yes, good point. I think fixed buffers are usually described in terms
of user registered buffers (probably since those were the only kind of
registered buffers until recently). It wouldn't hurt to be explicit
that addr vs. offset depends on the type of registered buffer. I think
it would also be fine to just say that this is an addr for both kinds
of buffers, as you can think of kernel registered buffers as
implicitly having a starting address of 0.

Best,
Caleb