I do not recall, and from the code there is no obvious reason. However, being
able to store multiple smaller members might be a good enough reason.
Btw, we don't use the key8 at all. I guess we can clean that code up to only
keep key32 and key64, eventually with the count to match up the right size ;)
george.
On Nov 8, 2011, at 18:11 , Nathan T. Hjelm wrote:
> Ok, that makes sense. Is there a reason why the members were all set the be
> the same size?
>
> Maybe seg_key should be:
>
> union {
> uint8_t key8;
> uint16_t key16;
> uint32_t key32;
> uint64_t key64;
> struct { uint64_t value[2] } key128;
> };
>
> -Nathan
>
> On Tue, 8 Nov 2011 17:22:48 -0500, George Bosilca <bosi...@eecs.utk.edu>
> wrote:
>> Elements in an array are always stored in the expected [increasing]
> order,
>> regardless of the endianess of the architecture. Moreover, due to the
>> alignment rules, all members in a union will start at the same address.
>>
>> It turns out there is no endianess conversion on the keys, so I suppose
>> both peers have to somehow reach a consensus outside the PML.
>>
>> george.
>>
>> On Nov 8, 2011, at 08:57 , Nathan T. Hjelm wrote:
>>
>>> Sure, I can do that. My only concern is with sending between hosts of
>>> different endianness.
>>>
>>> For example, if seg_key is 128 bits wide and the key32 is 64 bits then
>> we
>>> might run into this:
>>>
>>> Host 1: (big endian)
>>> Set seg_key.key32[0] = 0x11111111
>>>
>>> would result in seg_key: 0x00000000 0x00000000 0x11111111 0x00000000
>>>
>>> Host 2: (little endian)
>>> Set seg_key.key32[0] = 0x111111111
>>>
>>> would result in seg_key: 0x11111111 0x00000000 0x00000000 0x00000000
>>>
>>> If either host were to send the other one its seg_key and try to use the
>>> key32 they would get garbage. I haven't tested this case yet but I can
>> test
>>> on a PPE of RR later today.
>>>
>>> -Nathan
>>>
>>> On Tue, 8 Nov 2011 08:26:04 -0500, Jeff Squyres <jsquy...@cisco.com>
>> wrote:
>>>> On Nov 7, 2011, at 9:48 PM, Nathan T. Hjelm wrote:
>>>>
>>>>> In retrospect I should have done a RFC for the 3rd change with a short
>>>>> timeout. At the time (operating on little sleep) it seemed like the
>>>> commits
>>>>> would have minimal impact. Please let me know if the commits have any
>>>>> negative impact.
>>>>
>>>> FWIW, I think I'd like to see a rollback of the increase of array sizes
>>> in
>>>> the seg_key union. They weren't necessary and might be slightly
>>>> misleading.
>>>>
>>>> --
>>>> 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
>>>
>>> _______________________________________________
>>> devel mailing list
>>> de...@open-mpi.org
>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>
>>
>> _______________________________________________
>> devel mailing list
>> de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
> _______________________________________________
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
