[Openframeworkwg] source code for proof of concept framework available

[Hefty, Sean]

Just arguing against myself here...

> Having immediate data be host order can force byte swapping in the provider
> on both the sending and receiving side.  This may be a wash in terms of
> performance, unless the app is using immediate data to exchange one of
> several constant values.

It turns out that the current API defines immediate data as uintXX_t (host order).  From an application's perspective, this probably makes the most sense.  I can't justify to myself that there's a performance advantage for forcing it to be big endian.
 
> For the tag matching interface, I followed the same principal as the rkey,
> though tags aren't usually exchanged like rkeys are.  I'd need to look into
> an implementation to see if an app using host order or network order would
> be more efficient, or if it would matter at all.

And I can agree that tags should just be kept in host order, since they aren't usually exchanged.

This just leaves us with rkeys as the only non-address item that is in big endian format.  libibverbs exposes the rkey in host order, so maybe we just match that for backwards consistency..?

I also want the API to support the application being able to specify the rkey that it wants, which makes more sense being done in host order.  (Yeah, no implementation supports this ability, but it seems like a nice feature.)

- Sean