A little bit of history:
1. r25305: added 2 atomic operations to OPAL. However, they only exists on
amd64 and are only used in the vader BTL, which I assume only supports amd64.
2. r25334: The seg_key union got a new member ptr. This member is solely used
in the vader BTL, as all other BTL use a compiler trick to convert a pointer to
a 64 bits.
3. r25445: All members of the seg_key union got friends, because Cray dare to
set their keys at 128 bits long. However a quick
find . -name "*.[ch]" -exec grep -Hn seg_key {} \; | grep "\[1\]"
indicates that no BTL is using 128 bits keys. Code has been added to all PMLs,
but I guess they just copy empty data.
What I see is a pattern of commits that can have been dealt with differently.
None had an RFC, and most of them are not even used.
george.
On Nov 7, 2011, at 10:37 , Jeff Squyres wrote:
> On Nov 7, 2011, at 10:16 AM, Nathan T. Hjelm wrote:
>
>> Yes, and I completely agree. I was simply trying to keep it consistent in
>> case there is something I don't know about the heterogeneous case.
>>
>> I increased the size of the 64 bit member because there is no uint128 type.
>
> Ah, I see.
>
> I would put the other sizes back, at a minimum. There should be no need to
> increase those.
>
> George -- comments? Should this be a new key fields (128, with 2
> uint64_t's)? If this is only for large messages, is the extra 8 bytes a
> concern?
>
> --
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
>
>
> _______________________________________________
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
