Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2006-12-07 11:12:23

On Dec 6, 2006, at 9:59 AM, Adrian Knoth wrote:

>> The concern is that we want to leave open the possibility of
>> putting this
>> revision into 1.2 since it will have a major performance impact on
>> both
>> startup time and the max cluster size we can support. The IP6 code is
>> scheduled for 1.3 and we don't know what the performance impact
>> will look
>> like - hence the hesitation.
> I agree not to include IPv6 in the v1.2 (you might remove the
> configure
> patch from the v1.2 line, or leave it there without really using it)
> If one considers the current v1.2 branch as stable, the trunk could
> be used for the new v1.3 line.

That's the plan -- once we fork off a branch for a release series,
the trunk assumes the identity of the next release series. Hence,
there's branches for 1.0, 1.1, and 1.2, and therefore the trunk is
currently the 1.3 series. Once we branch for 1.3, the trunk will
become 1.4. And so on.

> I therefore suggest to move the OPAL changes into the trunk,
> also the small hostfile code (lex code for IPv6) and the btl code.

Can you describe the changes in opal that were made for IPv6?

> When you've completed all changes to the OOB, we can have a look
> and do the necessary IPv6 changes afterwards. Though I feel the oob/
> tcp
> is the hardest part of all (it got the most modifications), I hope
> that it's possible to copy a lot of the existing patch. Perhaps
> your rewrite simplifies something.

I don't think that it'll change much in your code (a total guess, but
based on what I think needs changing in the oob tcp). The main
things we'll be changing is *when* socket connections are made and
how the tcp component gets the contact info for the other procs.

> I'm currently not developing new code, so at least the IPv6 codebase
> isn't a moving target.

Excellent. Thanks for being diligent about this!

Jeff Squyres
Server Virtualization Business Unit
Cisco Systems