Re: [PATCH v2] xprtrdma: Provide a buffer to pad Write chunks of unaligned length

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On Sep 22, 2021, at 1:15 PM, Tom Talpey <tom@xxxxxxxxxx> wrote:
> 
> On 9/21/2021 1:21 PM, Chuck Lever III wrote:
>>> On Sep 21, 2021, at 12:58 PM, Tom Talpey <tom@xxxxxxxxxx> wrote:
>>> 
>>> On 9/18/2021 12:26 PM, Chuck Lever wrote:
>>>> This is a buffer to be left persistently registered while a
>>>> connection is up. Connection tear-down will automatically DMA-unmap,
>>>> invalidate, and dereg the MR. A persistently registered buffer has
>>>> no-cost to provide, and it can never be elided into the RDMA segment
>>>> that backs the data payload.
>>> 
>>> I'm confused by this last sentence. Why is "no-cost" important?
>> Today, the client turns off this XDR pad when it can because it
>> is registered and invalidated for every Write chunk with non-
>> aligned length. That adds a cost to providing it.
>> No-cost means we don't need to worry about optimizing it away;
>> it can be provided all the time, if we like, because there's no
>> additional per-RPC registration/invalidation cost.
> 
> Sure, I get that, but it's not actually zero. The MR is allocated and
> therefore consumes a handle. It's a way-better approach than registering a few bytes for each rpc of course. I guess I'm simply suggesting to delete the sentence. The other sentences cover the issue without the possible confusion.

There is a bug now where SG_GAPS support is coalescing the Write
pad MR into the data payload, and for various reasons, that's
not safe to do all the time.

So this patch addresses that, and this sentence calls out that
specific part of the fix.


--
Chuck Lever







[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux