On Thu, Dec 13, 2007 at 10:49:45AM +0200, Pavel Shamis (Pasha) wrote:
>> Because we want to support mixed setups and create XRC between nodes that
>> support it and RC between all other nodes.
>>
> Ok, sounds reasonable for me. Just need make sure that the parameters name
> will be user friendl
Gleb Natapov wrote:
On Wed, Dec 12, 2007 at 04:08:31PM +0200, Pavel Shamis (Pasha) wrote:
Gleb Natapov wrote:
On Wed, Dec 12, 2007 at 03:37:26PM +0200, Pavel Shamis (Pasha) wrote:
Gleb Natapov wrote:
On Tue, Dec 11, 2007 at 08:16:07PM -0500, Jeff Squyres wrote:
On Wed, Dec 12, 2007 at 01:35:33PM -0500, Jeff Squyres wrote:
> I agree with Gleb's idea. More below.
>
> On Dec 12, 2007, at 12:24 PM, Jon Mason wrote:
>
> > Ok, glad I got this conversation started :)
> >
> > So, we need a slight redesign to determine the cm method (unless
> > forced
> > via
I agree with Gleb's idea. More below.
On Dec 12, 2007, at 12:24 PM, Jon Mason wrote:
Ok, glad I got this conversation started :)
So, we need a slight redesign to determine the cm method (unless
forced
via commandline arg). This can be determined by calling all the
individual open routines
Ok, glad I got this conversation started :)
So, we need a slight redesign to determine the cm method (unless forced
via commandline arg). This can be determined by calling all the
individual open routines, and having them return a priority based on
their ability to function. For example, the xoo
On Wed, Dec 12, 2007 at 04:08:31PM +0200, Pavel Shamis (Pasha) wrote:
> Gleb Natapov wrote:
>> On Wed, Dec 12, 2007 at 03:37:26PM +0200, Pavel Shamis (Pasha) wrote:
>>
>>> Gleb Natapov wrote:
>>>
On Tue, Dec 11, 2007 at 08:16:07PM -0500, Jeff Squyres wrote:
> Isn't th
Gleb Natapov wrote:
On Wed, Dec 12, 2007 at 03:37:26PM +0200, Pavel Shamis (Pasha) wrote:
Gleb Natapov wrote:
On Tue, Dec 11, 2007 at 08:16:07PM -0500, Jeff Squyres wrote:
Isn't there a better way somehow? Perhaps we should have "select"
call *all* the functions and accept
On Wed, Dec 12, 2007 at 03:37:26PM +0200, Pavel Shamis (Pasha) wrote:
> Gleb Natapov wrote:
> > On Tue, Dec 11, 2007 at 08:16:07PM -0500, Jeff Squyres wrote:
> >
> >> Isn't there a better way somehow? Perhaps we should have "select"
> >> call *all* the functions and accept back a priority. T
Gleb Natapov wrote:
On Tue, Dec 11, 2007 at 08:16:07PM -0500, Jeff Squyres wrote:
Isn't there a better way somehow? Perhaps we should have "select"
call *all* the functions and accept back a priority. The one with the
highest priority then wins. This is quite similar to much of the
ot
On Tue, Dec 11, 2007 at 08:16:07PM -0500, Jeff Squyres wrote:
> Isn't there a better way somehow? Perhaps we should have "select"
> call *all* the functions and accept back a priority. The one with the
> highest priority then wins. This is quite similar to much of the
> other selection log
On Dec 12, 2007, at 5:13 AM, Pavel Shamis (Pasha) wrote:
Hmm. I don't think that we want to put knowledge of XRC in the OOB
CPC (and vice versa). That seems like an abstraction violation.
I didn't like that XRC knowledge was put in the connect base either,
but I was too busy to argue with it.
Jeff Squyres wrote:
Hmm. I don't think that we want to put knowledge of XRC in the OOB
CPC (and vice versa). That seems like an abstraction violation.
I didn't like that XRC knowledge was put in the connect base either,
but I was too busy to argue with it. :-)
Isn't there a better way s
Hmm. I don't think that we want to put knowledge of XRC in the OOB
CPC (and vice versa). That seems like an abstraction violation.
I didn't like that XRC knowledge was put in the connect base either,
but I was too busy to argue with it. :-)
Isn't there a better way somehow? Perhaps we s
Currently, alternate CMs cannot be called because
ompi_btl_openib_connect_base_open forces a choice of either oob or xoob
(and goes into an erroneous error path if you pick something else).
This patch reorganizes ompi_btl_openib_connect_base_open so that new
functions can easily be added. New Open
14 matches
Mail list logo
