[ofa-general] Question about exchanging DAT_RMR_TRIPLET

[Caitlin Bestler]

DAT does not specify how a DAT_RMR_TRIPLET should be encoded in
application messages. However, there are some heavy hints in the
semantics of the fields.

Both the virtual address and the length have integer semantics. They
are not opaque. It is meaningful to divide a buffer in half by doing integer
arithmetic on the address and lengths to form two new DAT_RMR_TRIPLETs
referring to the first and second half of the original region.

Therefore the virtual address should be passed in some way that will convey
its 64-bit unsigned integer value correctly to the destinastion, and the length
needs a method of conveying a 32-bit unsigned integer. It's up to the
application
to decide between standard wire ordering, "sender makes right", "receiver
makes right", RPC, text encoding or even XML encoding.

A DAT_RMR_CONTEXT any method that could encode an IB R-Key or
RDMAC STag would be valid.


On Feb 1, 2008 7:31 AM, Chuck Hartley <hartlch14 at gmail.com> wrote:
> Hello,
>
> We are doing RDMA transfers using UDAPL and just added a machine with a
> different endianness than the rest of the current machines.  We register a
> memory region and get a DAT_RMR_TRIPLET that we then send to the remote
> machine. On the receiving end, are you supposed to use the triplet as is, or
> do you have to byte swap it to the native order or some specific endianness?
> I couldn't find anything in the UDAPL document addressing this.
>
> On a related issue, we register a single large memory region that we are
> doing transfers from.  However, we are doing small transfers at varying
> offsets within that region.  We are currently doing this by modifying the
> address field of the DAT_RMR_TRIPLET we received. Is this an ok thing to do,
> or is there some other way to do RDMA transfers of varying size/offset from
> within a single registered memory region?
>
> Thanks,
> Chuck
>
> _______________________________________________
> general mailing list
> general at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
>
> To unsubscribe, please visit
> http://openib.org/mailman/listinfo/openib-general
>