[ofa-general] [PATCH RFC] RDMA: New Memory Extensions.

[Ralph Campbell]

On Thu, 2008-05-15 at 02:11 -0400, Talpey, Thomas wrote:
> At 02:04 AM 5/15/2008, Talpey, Thomas wrote:
> >At 07:54 PM 5/14/2008, Roland Dreier wrote:
> >>Second question -- IB BMME and iWARP talk about a key portion (least
> >>significant byte) of STag/L_Key/R_Key as being under consumer control.
> >>Do we want to expose that as part of this API?  Basically it means we
> >>need to add a way for the consumer to pass in a new L_Key/STag as part
> >>of a lot of calls.
> >
> >I think the Key portion is a quite useful way for the upper layer to
> >salt the actual R_Keys as a protection mechanism, and having it would
> >simplify a bunch of defensive code in the NFS/RDMA client. Currently,
> >because the keys are provider-chosen and potentially recycled, there
> >is a latent risk.
> >
> >But, I only want it if ALL future providers support it in some way. If a
> >subset does not, it's not worth coding around the differences.
> 
> I forgot to mention that the provider portion of the R_Key is reduced
> to 24 bits as a result of exposing/requiring the key. This may cause an
> issue at large scale, if the R_Keys have global scope. If they are limited
> to use on specific connections as in iWARP, then this is less of an issue.
> 
> Tom.

For IB, the R_Keys are global and the spec. says that the user portion
always has to be the lower 8 bits (ch 10.6.3.4) so it should be the
same for all HCAs.