On Thursday 07 September 2006 18:42, George Bosilca wrote:
> I still wonder why we need any configuration "magic". We don't want
> to be the only one around supporting IPv4 OR IPv6. Supporting both of
> them simultaneously can be interesting, and it does not require huge
> changes. In fact, w
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.
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 t
On Thu, Sep 07, 2006 at 07:51:28PM +0200, Adrian Knoth wrote:
> No problem, just two hours ago, Christian and me decided to drop
> the idea of oob/tcp6 and go on with only one oob-tcp-component.
> It shouldn't be that hard and I'll try it tonight or tomorrow.
Looks quite promising:
adi@ipc654:~/
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 corr
On Thu, Sep 07, 2006 at 11:46:28AM -0400, Jeff Squyres wrote:
> > On Fri, Sep 01, 2006 at 07:01:25AM -0600, Ralph Castain wrote:
> >
> >>> Do you agree to go on with two oob components, tcp and tcp6?
> >> Yes, I think that's the right approach
> >
> > It's a deal. ;)
> Actually, I would disagree
On 9/7/06 12:42 PM, "George Bosilca" wrote:
> I still wonder why we need any configuration "magic". We don't want
> to be the only one around supporting IPv4 OR IPv6. Supporting both of
> them simultaneously can be interesting, and it does not require huge
> changes. In fact, we have a problem on
That would be great with me! And much appreciated. A design would really
help.
On 9/7/06 10:42 AM, "George Bosilca" wrote:
> I still wonder why we need any configuration "magic". We don't want
> to be the only one around supporting IPv4 OR IPv6. Supporting both of
> them simultaneously can be i
I still wonder why we need any configuration "magic". We don't want
to be the only one around supporting IPv4 OR IPv6. Supporting both of
them simultaneously can be interesting, and it does not require huge
changes. In fact, we have a problem only at the connection step,
everything else wil
Jeff and I talked about this for awhile this morning, and we both agree
(yes, I did change my mind after we discussed all the ramifications). It
appears that we should be able to consolidate the code into a single
component with the right configuration system "magic" - and that would
definitely be
On 9/1/06 12:21 PM, "Adrian Knoth" wrote:
> On Fri, Sep 01, 2006 at 07:01:25AM -0600, Ralph Castain wrote:
>
>>> Do you agree to go on with two oob components, tcp and tcp6?
>> Yes, I think that's the right approach
>
> It's a deal. ;)
Actually, I would disagree here (sorry for jumping in late
On 9/6/06 9:44 AM, "Christian Kauhaus" wrote:
> Bogdan Costescu :
>> I don't know why you think that this (talking to different nodes via
>> different channels) is unusual - I think that it's quite probable,
>> especially in a heterogenous environment.
>
> I think the first goal should be to
On Wed, Sep 06, 2006 at 05:44:23PM +0200, Christian Kauhaus wrote:
> Our current plan is to look into the hostfile and see if there are
>
> (1a) just IPv4 addresses
> (1b) IPv4 addresses and hostnames for which 'A' queries can be resolved
> (2a) just IPv6 addresses
> (2b) IPv6 addresses and host
Bogdan Costescu :
>I don't know why you think that this (talking to different nodes via
>different channels) is unusual - I think that it's quite probable,
>especially in a heterogenous environment.
I think the first goal should be to get IPv6 working -- and this is much
more easier when we rest
Actually, I was a part of that thread - see my comments beginning with
http://www.open-mpi.org/community/lists/devel/2006/03/0797.php.
Perhaps I communicated poorly here. The issue in the prior thread was that
few systems nowadays don't offer at least some level of IPv6 compatibility,
even if noth
On Fri, 1 Sep 2006, Ralph Castain wrote:
> The only use case I am really concerned about is that of a Head Node
> Process (HNP) that needs to talk to both IPv6 and IPv4 systems. I
> admit this will be unusual,
This and other aspects were discussed or at least mentioned in a
thread starting at:
On Fri, Sep 01, 2006 at 07:01:25AM -0600, Ralph Castain wrote:
> > Do you agree to go on with two oob components, tcp and tcp6?
> Yes, I think that's the right approach
It's a deal. ;)
> I think this can be supported nicely in the framework system. All we
> have to do is set the IPv6 component's
On 9/1/06 6:17 AM, "Adrian Knoth" wrote:
> Hi,
>
> yesterday I felt impelled to create a new ORTE oob component: tcp6.
>
> I was able to either compile the library with IPv4 or IPv6 support,
> but not with both (so to say: two different ompi installations or
> at least two different DSO vers
Hi,
yesterday I felt impelled to create a new ORTE oob component: tcp6.
I was able to either compile the library with IPv4 or IPv6 support,
but not with both (so to say: two different ompi installations or
at least two different DSO versions).
As far as I can see, many functions use mca_oob_tcp_
19 matches
Mail list logo
