-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
