On 5/1/22 14:28, Jens Axboe wrote:
On 5/1/22 7:14 AM, Pavel Begunkov wrote:
On 4/29/22 18:56, Jens Axboe wrote:
Hi,
This series builds to adding support for a different way of doing
provided buffers. The interesting bits here are patch 11, which also has
some performance numbers an an explanation of it.
Jens, would be great if you can CC me for large changes, you know
how it's with mailing lists nowadays...
You bet, I can just add you to anything posted. Starting to lose faith
in email ever becoming reliable again...
thanks
1) reading "io_uring: abstract out provided buffer list selection"
Let's move io_ring_submit_unlock() to where the lock call is.
In the end, it's only confusing and duplicates unlock in
io_ring_buffer_select() and io_provided_buffer_select().
Sure, I can clean that up.
2) As it's a new API, let's do bucket selection right, I quite
don't like io_buffer_get_list(). We can replace "bgid" with
indexes into an array and let the userspace to handle indexing.
Most likely it knows the index right away or can implement indexes
lookup with as many tricks and caching it needs.
Maybe we can just use xarray here rather than a hashed list? It's really
just a sparse array. The downside is that xarray locking isn't always
very convenient, eg using it with your own locking...
Any other suggestions?
I'd suggest for mapped pbuffers to have an old plain array with
sequential indexing, just how we do it for fixed buffers. Do normal
and mapped pbuffers share something that would prevent it?
--
Pavel Begunkov
