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

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

On 10/24/24 19:00, Jens Axboe wrote:
> On 10/24/24 11:56 AM, Pavel Begunkov wrote:
>> On 10/24/24 18:19, Jens Axboe wrote:
>>> On 10/24/24 10:06 AM, Pavel Begunkov wrote:
>>>> On 10/24/24 16:45, Jens Axboe wrote:
...>>>> Seems like you're agreeing but then stating the opposite, there
>>>> is some confusion. I'm saying that IMHO the right API wise way
>>>> is resolving an imu at issue time, just like it's done for fixed
>>>> files, and what your recent series did for send zc.
>>>
>>> Yeah early morning confusion I guess. And I do agree in principle,
>>> though for registered buffers, those have to be registered upfront
>>> anyway, so no confusion possible with prep vs issue there. For provided
>>> buffers, it only matters for the legacy ones, which generally should not
>>> be used. Doesn't change the fact that you're technically correct, the
>>> right time to resolve them would be at issue time.
>>
>> I'm talking about sendmsg with iovec. Registered buffers should
>> be registered upfront, that's right, but iovec should be copied
>> at prep, and finally resolved into bvecs incl the imu/buffer lookup
>> at the issue time. And those are two different points in time,
>> maybe because of links, draining or anything else. And if they
>> should be at different moments, there is no way to do it while
>> copying iovec.
> 
> Oh I totally follow, the incremental approach would only work if it can
> be done at prep time. If at issue time, then it has to turn an existing
> iovec array into the appropriate bvec array. And that's where you'd have
> to do some clever bits to avoid holding both a full bvec and iovec array
> in memory, which would be pretty wasteful/inefficient. If done at issue

Why would it be wasteful and inefficient? No more than jumping
though that incremental infra for each chunk, doubling the size
of the array / reallocating / memcpy'ing it, instead of a tight
loop doing the entire conversion.

> time, then there's no way around a second iteration :/
> 

-- 
Pavel Begunkov