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/
