io_uring_pre...ovide_buffers(3)
π io_uring_prep_provide_buffers β bestie edition π
okay so this is part of the liburing Manual, and we're talking about io_uring_prep_provide_buffers(3). buckle up, it's giving "here's how you hand the kernel a lil pile of buffers" π
β¨ NAME β¨
io_uring_prep_provide_buffers β prepare a provide buffers request
πΈ SYNOPSIS πΈ
#include <liburing.h>
void io_uring_prep_provide_buffers(struct io_uring_sqe *sqe,
void *addr,
int len,
int nr,
int bgid,
int bid);
π¦ DESCRIPTION π¦
so bestie, io_uring_prep_provide_buffers(3) gets a request all ready to hand the kernel some buffers. the submission queue entry sqe gets set up to consume nr buffers, each one len in size, starting at addr, tagged with the buffer group ID bgid, and numbered sequentially starting from bid. slay. π
this function sets up a request to provide buffers to the io_uring context that can then be used by read or receive operations. it does this by filling in the SQE buf_group field and setting IOSQE_BUFFER_SELECT in the SQE flags member. and here's the tea π« β if buffer selection is used for a request, you should not put a buffer in the address field. instead, you set the group ID to match one that was previously provided to the kernel. then the kernel picks a buffer from that group for the IO operation. when the IO request completes successfully, the CQE flags field will have IORING_CQE_F_BUFFER set, and the selected buffer ID gets indicated by the upper 16-bits of the flags field. iconic behaviour, honestly.
different buffer group IDs can be used by the application so you can have different sizes or types of buffers available at the same time. no cap, very flexible. but listen β once a buffer has been consumed for an operation, it is no longer known to io_uring. it must be re-provided if you want it back, or freed by the application if you don't need it anymore. it's giving "use it and lose it" π
the buffer IDs are internally tracked from bid and go sequentially ascending from that value. so if 16 buffers are provided and they start with an initial bid of 0, then the buffer IDs will range from 0..15. the application must be aware of this to make sense of the buffer ID passed back in the CQE. main character energy = knowing your own IDs π
buffer IDs always range from 0 to 65535, because there are only 16-bits available in the CQE to pass them back. this range is independent of how the buffer group initially got created. attempting to add buffer IDs larger than that, or buffer IDs that will wrap when cast to a 16-bit value, will cause the request to fail with -E2BIG or -EINVAL. so don't try it, bestie, that's a red flag π©
not all requests support buffer selection, because it only really makes sense for requests that receive data from the kernel rather than write or provide data. currently, this mode of operation is supported for any file read or socket receive request. attempting to use IOSQE_BUFFER_SELECT with a command that doesn't support it will result in a CQE res error of -EINVAL. also: buffer selection will work with operations that take a struct iovec as its data destination, but only if 1 iovec is provided. one. uno. that's it. π
π RETURN VALUE π
None
π ERRORS π
these are the errors that get reported in the CQE res field. on success, res will contain 0 or the number of successfully provided buffers. cute!
-ENOMEMβ the kernel was unable to allocate memory for the request. broke behaviour, not the vibe. π-EINVALβ one of the fields set in the SQE was invalid. check ur fields bestie.-E2BIGβ the number of buffers provided was too big, or thebidwas too big. a max value ofUSHRT_MAXbuffers can be specified.-EFAULTβ some of the user memory given was invalid for the application.-EOVERFLOWβ the product oflenandnrexceed the valid amount or overflowed, or the sum ofaddrand the length of buffers overflowed.-EBUSYβ attempt to update a slot that is already used. occupied. taken. sorry babe. π
π SEE ALSO π
io_uring_get_sqe(3), io_uring_submit(3), io_uring_register(2), io_uring_prep_remove_buffers(3)
and that's the whole page, bestie!! this was liburing-2.2, dated March 13, 2022 β go forth and provide those buffers, you absolute icon π§β¨π
π¦ where this page comes from
- alpine 3.22: liburing-doc 2.9-r0 Β· LGPL-2.1-or-later OR MIT
- alpine 3.23: liburing-doc 2.12-r0 Β· LGPL-2.1-or-later OR MIT
- alpine 3.24: liburing-doc 2.14-r0 Β· LGPL-2.1-or-later OR MIT
- arch rolling: liburing 2.15-1 Β· GPL-2.0-only WITH Linux-syscall-note OR MIT AND LGPL-2.0-or-later AND MIT
- centos-stream 10: liburing-devel 2.12-1.el10 Β· (GPLv2 with exceptions and LGPLv2+) or MIT
- centos-stream 9: liburing-devel 2.12-1.el9 Β· (GPLv2 with exceptions and LGPLv2+) or MIT
- centos-stream 9: liburing-devel 2.12-1.el9 Β· (GPLv2 with exceptions and LGPLv2+) or MIT
- debian trixie: liburing-dev 2.9-1
- fedora 43: liburing-devel 2.9-2.fc43 Β· (GPL-2.0-only WITH Linux-syscall-note OR MIT) AND (LGPL-2.0-or-later OR MIT)
- fedora 43: liburing-devel 2.9-2.fc43 Β· (GPL-2.0-only WITH Linux-syscall-note OR MIT) AND (LGPL-2.0-or-later OR MIT)
- fedora 44: liburing-devel 2.13-2.fc44 Β· (GPL-2.0-only WITH Linux-syscall-note OR MIT) AND (LGPL-2.0-or-later OR MIT)
- fedora 44: liburing-devel 2.13-2.fc44 Β· (GPL-2.0-only WITH Linux-syscall-note OR MIT) AND (LGPL-2.0-or-later OR MIT)
- nixpkgs unstable: liburing 2.14
- opensuse-leap 16.0: liburing-devel 2.8-160000.3.1 Β· (GPL-2.0-only AND LGPL-2.1-or-later) OR MIT
- opensuse-leap 16.0: liburing-devel 2.8-160000.3.1 Β· (GPL-2.0-only AND LGPL-2.1-or-later) OR MIT
- opensuse-leap 16.0: liburing-devel 2.8-160000.3.1 Β· (GPL-2.0-only AND LGPL-2.1-or-later) OR MIT
- opensuse-leap 16.0: liburing-devel 2.8-160000.3.1 Β· (GPL-2.0-only AND LGPL-2.1-or-later) OR MIT
- ubuntu noble: liburing-dev 2.5-1build1
- ubuntu questing: liburing-dev 2.11-1
- ubuntu resolute: liburing-dev 2.14-1
- ubuntu stonking: liburing-dev 2.15-1
- π the page's license: LGPL-2.0-or-later
- Copyright (C) 2022 Jens Axboe <axboe@kernel.dk>
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms