Re: [OMPI devel] Rename "vader" BTL to "xpmem"
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
>>>
>>> --
>>>
>>> Terry D. Dontje | Principal Software Engineer
>>> Developer Tools
Re: [OMPI devel] Rename "vader" BTL to "xpmem"
Maybe he is -10!'ing, which is worst than -10'ing!
On Nov 23, 2011, at 7:52 PM, 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/
>>
>>
>>
>> __
Re: [OMPI devel] Rename "vader" BTL to "xpmem"
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
Re: [OMPI devel] Rename "vader" BTL to "xpmem"
But __way__ better than -10!'ing!
george.
On Nov 24, 2011, at 07:14 , Leonardo Fialho wrote:
> Maybe he is -10!'ing, which is worst than -10'ing!
>
> On Nov 23, 2011, at 7:52 PM, 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...@c
Re: [OMPI devel] Rename "vader" BTL to "xpmem"
I would agree (quick - defibrillator for George!). This is like rolling out a
howitzer to remove a dust spec from your floor.
Nathan gave a perfectly reasonable explanation for his choice of name. I know
some of us can be really anal-retentive, but this is going beyond reason. Just
leave the name alone and move on.
On Nov 24, 2011, at 4:19 PM, George Bosilca wrote:
> 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.
>>>
>>
