Re: [PATCH 0/4] implement vectored registered buffers for sendzc

[Pavel Begunkov <asml.silence@gmail.com>]

On 10/23/24 14:52, Jens Axboe wrote:
> On 10/22/24 8:38 PM, Pavel Begunkov wrote:
>> Allow registered buffers to be used with zerocopy sendmsg, where the
>> passed iovec becomes a scatter list into the registered buffer
>> specified by sqe->buf_index. See patches 3 and 4 for more details.
>>
>> To get performance out of it, it'll need a bit more work on top for
>> optimising allocations and cleaning up send setups. We can also
>> implement it for non zerocopy variants and reads/writes in the future.
>>
>> Tested by enabling it in test/send-zerocopy.c, which checks payloads,
>> and exercises lots of corner cases, especially around send sizes,
>> offsets and non aligned registered buffers.
> 
> Just for the edification of the list readers, Pavel and I discussed this
> a bit last night. There's a decent amount of overlap with the send zc
> provided + registered buffers work that I did last week, but haven't
> posted yet. It's here;
> 
> https://git.kernel.dk/cgit/linux/log/?h=io_uring-sendzc-provided
> 
> in terms of needing and using both bvec and iovec in the array, and
> having the suitable caching for the arrays rather than needing a full
> alloc + free every time.

And as I mentioned, that can be well done in-place (in the same
array) as one option.

> The send zc part can map into bvecs upfront and hence don't need the
> iovec array storage at the same time, which this one does as the sendmsg
> zc opcode needs to import an iovec. But perhaps there's a way to still
> unify the storage and retain the caching, without needing to come up
> with something new.

I looked through. The first problem is that your thing consuming
entries from the ring, with iovecs it'd need to be reading it
from the user one by one. Considering allocations in your helpers,
that would turn it into a bunch of copy_from_user, and it might
just easier and cleaner to copy the entire iovec.

And you just made one towards delaying the imu resolution, which
is conceptually the right thing to do because of the mess with
links, just like it is with fixed files. That's why it need to
copy the iovec at the prep stage and resolve at the issue time.

> Just a brief summary of the out-of-band discussion.

-- 
Pavel Begunkov