Re: [PATCH V3 4/4] RDMA/isert: Support iWARP transport

[Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>]

On 7/2/2015 1:28 AM, Sagi Grimberg wrote:
> On 7/2/2015 12:03 AM, Or Gerlitz wrote:
>> On Wed, Jul 1, 2015 at 11:53 PM, Steve Wise 
>> <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org> wrote:
>>>> From: Or Gerlitz [mailto:gerlitz.or-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
>>
>>> Yes, the MR is a local MR, but it is used for REMOTE access for 
>>> iWARP, but not IB.  It think the reason is that in iWARP there is no 
>>> distinction between local and remote keys.  For iwarp you get 1 key 
>>> called a Steering Tag or STAG that is used both locally and 
>>> advertised to the peer (if to be used for REMOTE IO).  Further, that 
>>> STAG is sent to the peer in the RDMA READ REQUEST and the peer iWARP 
>>> stack uses it to generate READ RESPONSE messages with the advertised 
>>> STAG as the READ DESTINATION.  And thus these STAGs require 
>>> REMOTE_WRITE access flags.  In IB, I believe the "key" sent in the 
>>> READ REQUEST is not the MR lkey or rkey at all, but a one-shot 
>>> transaction key, valid for that READ operation only, and the local 
>>> IB stack uses this key to map to the destination MR/lkey when 
>>> processing the RDMA READ RESPONSE. This difference in the protocols 
>>> is what drives the access flag difference.
>>
>>
>> Since in IB/RoCE the key sent on the wire isn't actually something
>> that can be used as rkey by the peer, we can safely do the extra
>> access flags Oring always and not worry which transport is used.
>>
>>
>>> Regardless, I'm not sure what you propose I do differently?  The 
>>> code in this patch does OR the needed access flag if the device is 
>>> iWARP when creating the DMA_MR.
>>
>> So always OR and don't branch
>
> Or has a good point.
> The DMA mkey in target mode is discrete and not sent to any peer.
>

Yup.  I agree.

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html