Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r25445
From: George Bosilca (bosilca_at_[hidden])
Date: 2011-11-08 18:36:57


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 <bosilca_at_[hidden]>
> 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 <jsquyres_at_[hidden]>
>> 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
>>>> jsquyres_at_[hidden]
>>>> For corporate legal information go to:
>>>> http://www.cisco.com/web/about/doing_business/legal/cri/
>>>>
>>>>
>>>> _______________________________________________
>>>> devel mailing list
>>>> devel_at_[hidden]
>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>
>>> _______________________________________________
>>> devel mailing list
>>> devel_at_[hidden]
>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>
>>
>> _______________________________________________
>> devel mailing list
>> devel_at_[hidden]
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel