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/
