[mpiwg-tools] Tools topics meeting reminder: Jan 19, 2017

[Marc-Andre Hermanns]

Hi Jeff,

yes, that is good news.

If implemented, I would recommend that the MPI Forum would get a CID
as well. This would enable us to define specific variables and events
across implementations (if they choose to provide them).

Then, we can start thinking about standardizing some variable and
events that are available in multiple implementations anyway.

Cheers,
Marc-Andre

On 03.02.2017 15:05, Jeff Squyres (jsquyres) wrote:
> I have confirmed with the IEEE Registration authority that an open source software project can purchase a CID.
> 
> Hence, the scheme listed below would seem to work well -- our (logical) vendor ID can be an IEEE OUI or CID, because they hold the desired properties:
> 
> - they are both 24 bits long
> - OUIs and CIDs are guaranteed to be unique (both within their respective classes and from each other)
>   - hence, a single 24-bit parameter is suitable for holding either value
> - IEEE maintains a world-wide registry of both OUIs and CIDs
> - purchasing a CID is not cost-prohibitive
> - purchasing a CID for use in this case is appropriate for software vendors (including open source projects)
> 
> 
> 
>> On Feb 2, 2017, at 10:59 AM, Jeff Squyres (jsquyres) <jsquyres at cisco.com> wrote:
>>
>> The more I look into this, the more it looks like we should use a CID and/or an OUI.
>>
>> The CID and OUI are both 24-bit IEEE-maintained numbers.
>>
>> CID = Company ID.  Used for no particular purpose.
>> OUI = Organization Unique ID.  Used for Ethernet MAC address space reservation.
>>
>> While all networking vendors in the HPC space have OUIs, researchers and software tool vendors probably do not.  We do not want researchers/software vendors to buy an OUI -- that would be a mis-use of global MAC address space.
>>
>> It looks like the CID was created for exactly this purpose: you need a globally unique number, but you do not need to reserve a range in in the MAC address space.
>>
>> The IEEE was clever enough to reserve 1 bit to tell the difference between an OUI and a CID.  Hence:
>>
>> - all OUIs are distinct from all CIDs, and vice versa
>> - if you care, you can tell if a given 24 bit value is a CID or OUI
>>
>> It looks like the purchase of a CID is $685 USD: http://standards.ieee.org/develop/regauth/cid/index.html
>>
>> http://standards.ieee.org/develop/regauth/tut/eui.pdf
>>
>> What I don't know yet is whether an open source software project can buy a CID or not.  I have an email in to IEEE asking this question.
>>
>>
>>
>>> On Feb 2, 2017, at 8:21 AM, Jeff Squyres (jsquyres) <jsquyres at cisco.com> wrote:
>>>
>>> On Feb 2, 2017, at 7:02 AM, Marc-Andre Hermanns <hermanns at jara.rwth-aachen.de> wrote:
>>>>
>>>> I did not want to mandate a specific length. The way I understand it
>>>> is that the ID is an integer of some length, where parts can be masked
>>>> and queried for information.
>>>
>>> I think what I was trying to say (poorly) was that I am proposing a *logical* tuple.  How long each item is in the tuple, and how we map that to C types are different questions.
>>>
>>> Your proposed prototype had a single uint64_t parameter; I just wanted to make sure we were still talking about a tuple, not a single (logical) value.
>>>
>>>> In my last mail, yes, but I do acknowledge that additional fields are
>>>> necessary. I just asked about the vendor ID, as that is the one mostly
>>>> regulated, right? The vendors are free to use the remaining bits as
>>>> they see fit, right?
>>>
>>> I would think so.
>>>
>>>> Yes, I read about the OUI. As far as I know, these are _bought_ from
>>>> and controlled by IEEE. How would an MPI vendor obtain one of those to
>>>> use for software events from inside the MPI?
>>>
>>> Buy one.
>>>
>>> -- 
>>> Jeff Squyres
>>> jsquyres at cisco.com
>>>
>>
>>
>> -- 
>> Jeff Squyres
>> jsquyres at cisco.com
>>
>> _______________________________________________
>> mpiwg-tools mailing list
>> mpiwg-tools at lists.mpi-forum.org
>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools
> 
> 

-- 
Marc-Andre Hermanns
Jülich Aachen Research Alliance,
High Performance Computing (JARA-HPC)
Jülich Supercomputing Centre (JSC)

Wilhelm-Johnen-Str.
52425 Jülich
Germany

Phone: +49 2461 61 2509 | +49 241 80 24381
Fax: +49 2461 80 6 99753
www.jara.org/jara-hpc
email: hermanns at jara.rwth-aachen.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4899 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20170203/f9d25325/attachment.bin>