At 02:04 AM 5/15/2008, Talpey, Thomas wrote:
quoted text
>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.

_______________________________________________
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general