linux-kernel - RE: [ofa-general] InfiniBand/RDMA merge plans for 2.6.24

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <000601c80525$0b661f30$ff0da8c0@amr.corp.intel.com>
Date:	Tue, 2 Oct 2007 11:50:04 -0700
From:	"Sean Hefty" <sean.hefty@...el.com>
To:	"'Roland Dreier'" <rdreier@...co.com>
Cc:	<general@...ts.openfabrics.org>, <linux-kernel@...r.kernel.org>,
	<netdev@...r.kernel.org>
Subject: RE: [ofa-general] InfiniBand/RDMA merge plans for 2.6.24

>Umm... this is a difficult situation for me to merge the changes then.
>We're changing the CM retry behavior blind here.  How do we know that
>the MRA changes don't make the scalability issue worse?

What's currently upstream doesn't work for Intel MPI on our larger clusters.
The connection requests time out on the active side before the passive side can
respond.

The OFED release works because it provides a kernel patch to make the timeout a
module parameter.  I'm trying to avoid adding a module parameter, and the MRA is
designed for this situation.

I tested this by simulating a slow passive side responder, and it worked as
expected for those tests.  Using an MRA does add another MAD to the CM exchange,
which is why it is sent only after seeing a duplicate request.  Alternatively,
we can take the OFED module parameter patch.

- Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/