.\" Copyright (C) 2022 Jens Axboe <axboe@kernel.dk>
.\"
.\" SPDX-License-Identifier: LGPL-2.0-or-later
.\"
.TH io_uring_buf_ring_add 3 "May 18, 2022" "liburing-2.2" "liburing Manual"
.SH NAME
io_uring_buf_ring_add \- add buffers to a shared buffer ring
.SH SYNOPSIS
.nf
.B #include <liburing.h>
.PP
.BI "void io_uring_buf_ring_add(struct io_uring_buf_ring *" br ",
.BI "                           void *" addr ",
.BI "                           unsigned int " len ",
.BI "                           unsigned short " bid ",
.BI "                           int " mask ",
.BI "                           int " buf_offset ");"
.fi
.SH DESCRIPTION
.PP
The
.BR io_uring_buf_ring_add (3)
adds a new buffer to the shared buffer ring
.IR br .
The buffer address is indicated by
.I addr
and is of
.I len
bytes of length.
.I bid
is the buffer ID, which will be returned in the CQE.
.I mask
is the size mask of the ring, available from
.BR io_uring_buf_ring_mask (3) .
.I buf_offset
is the offset to insert at from the current tail. If just one buffer is provided
before the ring tail is committed with
.BR io_uring_buf_ring_advance (3)
or
.BR io_uring_buf_ring_cq_advance (3),
then
.I buf_offset
should be 0. If buffers are provided in a loop before being committed, the
.I buf_offset
must be incremented by one for each buffer added.

.SH RETURN VALUE
None
.SH NOTES
liburing (or the kernel, for that matter) doesn't care about what buffer ID maps
to what buffer, and in fact when recycling buffers after use, the application is
free to add a different buffer into the same buffer ID location. All that
matters is that the application knows what a given buffer ID in time corresponds
to in terms of virtual memory. There's no liburing or kernel assumption that
these mappings are persistent over time, they can very well be different every
time a given buffer ID is added to the provided buffer ring.
.SH SEE ALSO
.BR io_uring_register_buf_ring (3),
.BR io_uring_buf_ring_mask (3),
.BR io_uring_buf_ring_advance (3),
.BR io_uring_buf_ring_cq_advance (3)