On Wed, 2008-02-06 at 16:22 -0600, frank zago wrote: > Fab Tillier wrote: > > The RKey is always an opaque value - it only has meaning to the HCA > > hardware, and is used in combination with the PD of the QP on which the > > RETH is received to do the address translation. It's a token, and should > > be treated as such. It cannot be interpreted by anything other than the > > HW/driver that generated it. The value really should never be manipulated > > outside of the HCA hardware domain (which includes the HW and the > > HW-specific driver). > > > > -Fab > The rkey cannot be opaque. You register a memory region on windows, get > a rkey, send it to a big endian linux and a little endian linux host. > Both try to use it, and one of them will fail.
I don't think this is true. The RKEY are interpreted locally, i.e. by the issuing host. The remote peer does nothing with it but stuff it an SGE. Fab's point is that the byte swapping on Linux is unnecessary and unless I'm missing something I think he's correct. > > I think the application must know what format is this rkey, so they can > pass it along while keeping its byte order property. If all IB stacks > return the rkey in network order, and accept rkey also in network > order, then there is no interop problem anymore. > I think this is an API issue, not a wire issue. > Frank. _______________________________________________ ofw mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
