Re: [OMPI devel] [IPv6] new component oob/tcp6

2006-09-08 Thread Ralph H Castain
It occurred to me last night that this solves the homogeneous case, but
still leaves us with the problem of hetero systems. What we really need to
know is not only "what do I support", but "what does the recipient support".

Then it hit me that we may already have the solution for that problem in the
OOB, though we don't use it currently. If you check the OOB code, you will
find that we store the OOB contact info on the registry during startup, and
in return we obtain ALL of the OOB contact info for our peers. In that code,
we allow for multiple contact points to be passed for each peer process -
including what protocol is to be used for each contact point.

In other words, if we have an IPv6 socket, that information gets passed to
our peers (including the fact that it is an IPv6 address). Ditto if we have
an IPv4 socket. And we are covered even if we have both types.

What is missing in the code is the selection of which contact point to use
to communicate a given message, and the decision logic that uses the "right"
addressing protocol as specified for that recipient (current code assumes
only one is given).

So I think we can actually build a lot of the hetero support into the
existing OOB component. We just may need to add a little to take full
advantage of what is already there. For example, on a send, we may just need
to use the proper call that matches the specified protocol. The "if"
statement approach should be adequate for that level of separation.

Ralph



On 9/7/06 4:15 PM, "Jeff Squyres"  wrote:

> On 9/7/06 1:51 PM, "Adrian Knoth"  wrote:
> 
>>> (I'm willing to help with the configure.m4 mojo -- the
>> 
>> That's good. Just check for struct sockaddr_in6 and add
>> -DIPV6 to the CFLAGS. This flag is currently needed by
>> opal/util/if.* and orte/mca/oob/tcp/*, so one might limit
>> it to the two corresponding makefiles.
>> 
>> We can also set/define IPV6 in something_config.h.
>> It'd also be a good idea to have a --disable-ipv6 configure flag.
> 
> Done.  See the attached patch (apply it, then re-run autogen.sh and
> configure).  It does three things:
> 
> 1. Check if --disable-ipv6 was passed to configure.
> 2. Check to see if struct sockaddr_in6 exists.
> 3. Sets a macro OMPI_WANT_IPV6 to either 0 or 1 (i.e., it's always defined
> and is therefore suitable for #if, not #ifdef):
>- Set to 1 if --disable-ipv6 was not passed to configure *AND* struct
> sockaddr_in6 exists
>- Set to 0 otherwise
> 
> So surround your code with:
> 
> #if OMPI_WANT_IPV6
> ...ipv6 stuff...
> #endif
> 
> All you have to do to get this define is #include "ompi_config.h", which all
> of the files should be doing already, anyway.
> 
> Let me know if this works for you.




Re: [OMPI devel] [IPv6] new component oob/tcp6

2006-09-08 Thread Jeff Squyres
On 9/7/06 6:15 PM, "Jeff Squyres"  wrote:

> All you have to do to get this define is #include "ompi_config.h", which all
> of the files should be doing already, anyway.

Oops!  Ralph pointed out to me that this is not quite correct.

In the OOB TCP component, you should *NOT* include "ompi_config.h" -- you
should include "orte_config.h" (and it should already be included, anyway).

Short version: 
--

both orte_config.h and ompi_config.h should have the appropriate #define's
in place.  I goofed in my original patch; see new version (attached) where
the macro has been renamed to OPAL_WANT_IPV6 (vs. OMPI_WANT_IPV6).  The new
patch wholly replaces the prior patch.

Longer version:
---

The stack has 3 layers:

- opal: Open Portable Access Layer
- orte: Open Run Time Environment
- ompi: Open Message Passing Interface

These are strictly layered on each other, so ORTE, for example, has zero
knowledge of OMPI.  We used to have one big tree and only informal layering
of these 3 sections of code, but now they're actually 3 different trees.
Hence, the code division is strict and absolute (e.g., by default, we make 3
libraries: libopal, liborte, libompi).  Abstractions violations are swiftly
punished by the linker.

However, there are still a bunch of top-level names that are "OMPI" (mainly
stemming from configure), even though they're intended for OPAL and/or ORTE.
But that's no reason to continue the bad names.  The macro that I added
yesterday was OMPI_WANT_IPV6, but I really should have named it
OPAL_WANT_IPV (since OPAL is where most of the portability machinery is
supposed to go).  I've amended my previous patch -- see attached.  So
surround your code with:

#if OPAL_WANT_IPV6
...
#endif

I can't commit this to the trunk until tonight -- we have an informal policy
in the project to not make changes to configure and friends during the
Euro/US work day so as not to force developers to re-run autogen.sh during
the day.

-- 
Jeff Squyres
Server Virtualization Business Unit
Cisco Systems



ipv6-2.patch
Description: Binary data