I was expressing my support to the name-aliasing idea. I can't imagine a more
confusing experience from a user perspective.
george.
On Nov 23, 2011, at 14:52 , Jeff Squyres wrote:
> Can you explain that a little more? Are you -10'ing the whole concept? Or
> just renaming xpmem? Or ...?
>
> On Nov 22, 2011, at 11:37 AM, George Bosilca wrote:
>
>> -10!
>>
>> george.
>>
>> On Nov 22, 2011, at 08:38 , Jeff Squyres wrote:
>>
>>> 1. Personally, I would love to rename the openib BTL to something that
>>> makes sense and is a current name. By "rename", I include "rename the
>>> directory" -- so it would be ompi/mca/btl/ofrc, or something like that.
>>>
>>> 2. Good point about error reporting. I would think that the component
>>> (e.g., ofrc/openib BTL) should report the name that was specified by the
>>> user. But this could be a PITA to implement -- you couldn't just hard-code
>>> your component name in error messages anymore; there would have to be some
>>> level of indirection, such as a global variable that the MCA base fills in
>>> with the name that your component was referred to by.
>>>
>>>
>>> On Nov 22, 2011, at 9:34 AM, TERRY DONTJE wrote:
>>>
>>>> So with the aliasing scheme the code for openib would still under
>>>> ompi/mca/btl/openib but you could access it with -mca btl ofrc? Ok, so
>>>> when an error happens in the openib btl how does it identify itself? Does
>>>> it use openib or ofrc? This seems like there could be some user confusion
>>>> by adopting the aliasing scheme.
>>>>
>>>> --td
>>>>
>>>> On 11/22/2011 9:22 AM, Jeff Squyres wrote:
>>>>> Here's what Nathan and I discussed / decided:
>>>>>
>>>>> 1. Nathan shied away from the name "xpmem" in case some other shared
>>>>> memory scheme basically did the same thing as XPMEM (i.e., single copy
>>>>> techniques). (just FYI: xpmem's setup is a little different from KNEM,
>>>>> though, so they didn't merge in KNEM support to vader) Hence, he wanted
>>>>> a neutral name that could apply to xpmem and others. He and Sam have
>>>>> some possible names that could be suitable ("single copy
>>>>> ...something..."; I don't remember offhand).
>>>>>
>>>>> 2. We've long talked about having an MCA component aliasing scheme.
>>>>> Perhaps now is the time to do it. Such a scheme would do two things:
>>>>>
>>>>> - provide alias names for components. For example, both of the following
>>>>> would be equivalent:
>>>>>
>>>>> mpirun --mca btl openib,self ...
>>>>> mpirun --mca btl ofrc,self ...
>>>>>
>>>>> - automatically register alias MCA parameters. For example, both of the
>>>>> following would be equivalent:
>>>>>
>>>>> mpirun --mca btl_openib_param 1 ...
>>>>> mpirun --mca btl_ofrc_param 1 ...
>>>>>
>>>>> This would solve two problems:
>>>>>
>>>>> 2a. Finally be able to rename the "openib" module to something more
>>>>> sensical; "ofrc", perhaps? ("ofrc" = OpenFabrics reliable connected
>>>>> transport, as opposed to the existing "ofud" = OpenFabrics unreliable
>>>>> datagram transport BTL).
>>>>>
>>>>> 2b. Rename vader to be xpmem, because it only supports xpmem at the
>>>>> moment. If that component is expanded in the future to support other
>>>>> similar single-copy schemes, it can be renamed to some neutral name and
>>>>> have "xpmem" as an alias.
>>>>>
>>>>> Nathan agreed to look into a module aliasing scheme / vader->xpmem rename
>>>>> after he works the hide-OB1/BTL-descriptor-lengths issue that was
>>>>> previously discussed on the list. This will likely be in early/mid
>>>>> December.
>>>>>
>>>>>
>>>>>
>>>>> On Nov 17, 2011, at 8:11 AM, Jeff Squyres wrote:
>>>>>
>>>>>
>>>>>> After having to explain to someone at SC for the umpteenth time this
>>>>>> week that the "vader" BTL uses the XPMEM transport under the covers, I'd
>>>>>> like to put forth an appeal to rename the "vader" BTL to be "xpmem."
>>>>>>
>>>>>> Here's my rationale for why:
>>>>>>
>>>>>> 1. Although we have a history of Star Wars-related names, the "ob1" and
>>>>>> "r2" components got their names because they're mainly algorithms that
>>>>>> have no obvious name that describes what they do.
>>>>>>
>>>>>> 2. All other components that tie into some back-end system are named
>>>>>> reflecting the back-end system (e.g., tcp, mx, portals, ...etc.).
>>>>>> "openib" is the weakest example, but we all know that it was named way
>>>>>> back when OFED was named "OpenIB", and the name has kinda stuck.
>>>>>>
>>>>>> 3. The BTL name "xpmem" follows the law of least astonishment from the
>>>>>> user's perspective.
>>>>>>
>>>>>> 4. Cute names rarely seem so after 6 months.
>>>>>>
>>>>>> I'll even volunteer to do the work to rename it (a bunch of file moves
>>>>>> and global search-and-replaces).
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>
>>>>
>>>> --
>>>> <Mail Attachment.gif>
>>>> Terry D. Dontje | Principal Software Engineer
>>>> Developer Tools Engineering | +1.781.442.2631
>>>> Oracle - Performance Technologies
>>>> 95 Network Drive, Burlington, MA 01803
>>>> Email terry.don...@oracle.com
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> devel mailing list
>>>> de...@open-mpi.org
>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>
>>>
>>> --
>>> 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
>
>
> --
> 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
