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
