possible rkey byteswap (was Re: [ofw] what's up with the OFAWindows project?)

[Tom Tucker]

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.