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
