[ofa-general] [PATCH RFC v3 1/2] RDMA/Core: MEM_MGT_EXTENSIONS support

[Talpey, Thomas]

At 02:58 PM 5/27/2008, Tom Tucker wrote:
>
>On Tue, 2008-05-27 at 12:39 -0400, Talpey, Thomas wrote:
>> At 11:33 AM 5/27/2008, Tom Tucker wrote:
>> >So I think from an NFSRDMA coding perspective it's a wash...
>> 
>> Just to be clear, you're talking about the NFS/RDMA server. However, it's
>> pretty much a wash on the client, for different reasons.
>> 
>Tom:
>
>What client side memory registration strategy do you recommend if the
>default on the server side is fastreg?

"Whatever is fastest and safest". Given that the client and server won't
necessarily be using the same hardware, nor the same kernel for that
matter, I don't think we can or should legislate it.

That said, I am hopeful that "fastreg" does turn out to be "fast" and
therefore will become the only logical choice for the NFS/RDMA Linux
client. But the future Linux client is only one such system. I cannot
speak for others.

Tom.

>
>On the performance side we are limited by the min size of the
>read/write-chunk element. If the client still gives the server a 4k
>chunk, the performance benefit (fewer PDU on the wire) goes away.