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

Reply via email to