On Tue, May 01, 2007 at 07:39:07AM -0700, Jeff Squyres wrote:
> > (b) that
> > IPv6 was correctly operating...which were the two issues in this
> > discussion.
> We currently do not have any IPv6 setup in our MPI testing equipment
We automatically check every trunk commit against our IPv6 tes
On May 1, 2007, at 7:23 AM, Ralph Castain wrote:
I'm not entirely sure that the MTT testing would (a) detect whether
or not
multiple TCP BTL paths were working (as opposed to only one); or
They should...?
I'll have to check our Cisco rig to ensure that we're again testing
multi-TCP BTL (w
On 5/1/07 7:43 AM, "Jeff Squyres" wrote:
> On Apr 29, 2007, at 9:07 AM, Adrian Knoth wrote:
>
>>> BTL). It's not that I don't care about IPv6, it's just that I care
>>> more about multi TCP BTL working in the way it is supposed to work.
>>
>> There'd be less trouble if we all had automatic t
On Apr 29, 2007, at 9:07 AM, Adrian Knoth wrote:
BTL). It's not that I don't care about IPv6, it's just that I care
more about multi TCP BTL working in the way it is supposed to work.
There'd be less trouble if we all had automatic testing, so nobody
breaks stuff somebody else relies on.
We
Hi Adrian,
On 4/29/07, Adrian Knoth wrote:
On Sun, Apr 29, 2007 at 10:18:01AM -0400, George Bosilca wrote:
[snip]
BTW: How does multi TCP BTL works? I see num_links, but I wonder if
kernel channel bonding would achieve the same results...
Unfortunately, kernel channel bonding is very unlik
On Sun, Apr 29, 2007 at 06:07:03PM +0200, Adrian Knoth wrote:
> > I have to ask you to remove r14549 quickly as it bring back the trunk
> > to the stage it was before r14544 (only random support for multiple
> I'll have a look how to accomplish both: IPv6 and a reverted r14549.
Does r14550 sa
On Sun, Apr 29, 2007 at 10:18:01AM -0400, George Bosilca wrote:
> I have to ask you to remove r14549 quickly as it bring back the trunk
> to the stage it was before r14544 (only random support for multiple
I'll have a look how to accomplish both: IPv6 and a reverted r14549.
> BTL). It's not
It's against my "religion" to back off someone else commit. First I
try to understand why and how to fix it. After the IPv6 commit, it
took me 2 days to bring the trunk back to the stage where it was
before (i.e. restore the lost functionality).
I have to ask you to remove r14549 quickly as
Hi, especially bosilca (George?)
r14544 broke the IPv6 support (see Ticket #1008). I've committed a quick
patch, but I guess we (George and me?) will have to look closer in order
to provide the desired functionality.
There's another question concerning r14544: why did you change
sockaddr_storage*
