> They're basically the same concept, it's a subtle difference.
> FRMR = Fast Register Memory Region
> FRWR = Fast Register Work Request
> The memory region is the mr itself, this is created early on.
> The work request is built when actually binding the physical
> pages to the region,
>> I just tested that setting:
>> mr->iova &= (PAGE_SIZE - 1);
>> mr->iova |= 0x;
>> after the ib_map_mr_sg() and before doing the IB_WR_REG_MR, seems to
> Good! As you know, we were concerned about it after seeing that
> the ib_dma_map_sg() code was
>> + req->Channel = SMB2_CHANNEL_RDMA_V1_INVALIDATE;
>> + if (need_invalidate)
>> + req->Channel = SMB2_CHANNEL_RDMA_V1;
>> + req->ReadChannelInfoOffset =
>> + offsetof(struct smb2_read_plain_req, Buffer);
>> + req->ReadChannelInfoLength =
Am 19.12.2017 um 22:21 schrieb Long Li via samba-technical:
>> depends on CIFS && INFINIBAND
>> +depends on CIFS=m || INFINIBAND=y
> How about we change them to
> depends on CIFS=m && INFINIBAND || CIFS=y && INFINIBAND=y
> This makes it easy to read.
I like it :-)
Am 19.12.2017 um 11:56 schrieb Arnd Bergmann via samba-technical:
> On Tue, Dec 19, 2017 at 11:33 AM, Stefan Metzmacher <me...@samba.org> wrote:
>> Hi Arnd,
>>> diff --git a/fs/cifs/Kconfig b/fs/cifs/Kconfig
>>> index 500fd69fb58b..3bfc55c08bef 100644
> diff --git a/fs/cifs/Kconfig b/fs/cifs/Kconfig
> index 500fd69fb58b..3bfc55c08bef 100644
> --- a/fs/cifs/Kconfig
> +++ b/fs/cifs/Kconfig
> @@ -199,6 +199,7 @@ config CIFS_SMB311
> config CIFS_SMB_DIRECT
> bool "SMB Direct support (Experimental)"
> depends on CIFS &&
>> This is great to see. Is there a Linux implementation of the server side (in
>> Samba?) so that the client can be tested without needing a Windows server?
> I'm not aware of a Linux implementation on server side.
Here's a very early work in progress branch:
>> It seems that the new transport is tied to it's caller regarding structures
>> naming conventions.
>> I think it would be better to strictly separate them, as I'd like to use the
>> SMBDirect transport also from the userspace for the client side e.g. in
thanks for providing this patchset, I guess it will be a huge win to
have SMBDirect support for the kernel client!
> Define a new structure for SMBD transport. This stucture will have all the
> information on the transport, and it will be stored in the current SMB
Mail list logo