SEGERS Koen wrote:
Hi,
My answers below refer only to the ib-bonding package that comes with OFED-1.2
Hi all!
We are trying to bond two ports on 1 HCA so that we are able aggregate
the throughput. We are also interested in bonding ports of different HCA's.
ib-bonding currently supports
Are you talking about a kernel patch when you refer to the bonding kernel
driver? I can't find a specific bonding command that allows bonding two or
more ports.
So if I understand it correct, with SDP you can't have redundancy
(active/passive) or aggregation (active/active) with the current
This email was generated automatically, please do not reply
Passed:
Passed on i686 with 2.6.15-23-server
Passed on i686 with linux-2.6.19
Passed on i686 with linux-2.6.17
Passed on i686 with linux-2.6.18
Passed on i686 with linux-2.6.15
Passed on i686 with linux-2.6.16
Passed on i686 with
On Mar 8, 2007, at 6:58 AM, Jeff Squyres wrote:
Developers: the server IP address is 146.246.248.81.
Wrong address, sorry; it should be: 69.55.231.195.
--
Jeff Squyres
Server Virtualization Business Unit
Cisco Systems
___
general mailing list
Mostly it implements the switch only optimization idea and affects
the min hops matrices building phase (for both up/down and default
builders).
The main trick is to keep the min hop tables _ONLY_ for switches base
LIDs and don't bother with CAs, routers LIDs and any secondary LIDs in
case when
Use only switch base LIDs min hop vectors in the best port lookup
routines - osm_switch_recommend*_path().
Signed-off-by: Sasha Khapyorsky [EMAIL PROTECTED]
---
osm/include/opensm/osm_switch.h | 11 ++--
osm/opensm/osm_mcast_mgr.c | 11 +++
osm/opensm/osm_switch.c | 53
Instead of the direct accessing min hop tables mcast_mgr uses function
osm_switch_get_port_least_hops() which will evaluate only switches' base
LID min hop vectors.
Signed-off-by: Sasha Khapyorsky [EMAIL PROTECTED]
---
osm/include/opensm/osm_switch.h | 33 +
up/down and default min hop builder will calculate min hop matrices
only for switches base LIDs - don't bother with CA or router ports and
LMC.
Signed-off-by: Sasha Khapyorsky [EMAIL PROTECTED]
---
osm/opensm/osm_ucast_mgr.c | 280 ++
This adopts routing dump functions to work properly with reduced min hop
tables.
Signed-off-by: Sasha Khapyorsky [EMAIL PROTECTED]
---
osm/opensm/osm_ucast_mgr.c | 34 ++
1 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/osm/opensm/osm_ucast_mgr.c
Quoting Sean Hefty [EMAIL PROTECTED]:
Subject: Re: OFED 1.2 beta blocking bugs
Sean there's a critical bug related to multicast module,
and a blocker bug related to ucma module assigned to you.
Not sure who assigned me the bugs,
I did.
but I did look at them and added comments.
Yes.
Jeff Squyres wrote:
On Mar 8, 2007, at 6:58 AM, Jeff Squyres wrote:
Developers: the server IP address is 146.246.248.81.
Wrong address, sorry; it should be: 69.55.231.195.
Jeff,
Can you add git.openfabrics.org to /etc/hosts on openfabrics server -
OFED-1.2 daily build fails...
Thanks,
Done. Try now.
On Mar 8, 2007, at 9:44 AM, Vladimir Sokolovsky wrote:
Jeff Squyres wrote:
On Mar 8, 2007, at 6:58 AM, Jeff Squyres wrote:
Developers: the server IP address is 146.246.248.81.
Wrong address, sorry; it should be: 69.55.231.195.
Jeff,
Can you add git.openfabrics.org to
Jeff Squyres wrote:
Done. Try now.
Thanks,
OFED-1.2-20070308-0708.tgz is ready.
Regards,
Vladimir
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit
Has anyone besides me been stupid enough to try and put a mellanox
infiniband card in a Cray XD1?
It looks like I get a similar problem that the XT3 used to have where
the large PCI memory footprint makes stuff not work. Except the node
is not even booting ;)
It looks like the 'real' xd1
On Sat, 2007-03-03 at 08:59, Sasha Khapyorsky wrote:
The idea of this optimization is to perform all time consuming up/down
min hops calculation cycles only for switches, and when this is ready
just to populate (in one pass) calculated min hops values for CAs and
routers as its neighbour
Ah yes, there are mulitple IP's involved, sorry:
69.55.231.195 lists.openfabrics.org www.openfabrics.org
www2.openfabrics.org git.openfabrics.org
69.55.231.178 bugs.openfabrics.org
69.55.231.179 wiki.openfabrics.org
69.55.231.180 svn.openfabrics.org
On Mar 8, 2007, at 12:22 PM,
Sean, can you please take a look?
Scott Weitzenkamp
SQA and Release Manager
Server Virtualization Business Unit
Cisco Systems
-Original Message-
From: Michael S. Tsirkin [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 08, 2007 6:07 AM
To: Sean Hefty
Cc: Scott Weitzenkamp
ipoibcfg merge only handles IPoIB, not SDP, and it's active/passive.
From: SEGERS Koen [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 08, 2007 1:03 AM
To: Scott Weitzenkamp (sweitzen); general@lists.openfabrics.org
Subject: RE:
I looked at the code, and didn't see anything obviously
wrong. Can you tell me
how to reproduce the issue? (I'm running 2.6.21-rc3.)
Use a recent OFED 1.2 build, say OFED-1.2-20070308-0708.
Configure IPoIB HA to use ib0 and ib1, for example. Make sure your
openibd.conf has these lines
Can the bonding driver load balance IPoIB traffic across multiple
interfaces at the same time?
Scott Weitzenkamp
SQA and Release Manager
Server Virtualization Business Unit
Cisco Systems
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Moni Shoua
On Mar 8, 2007, at 10:18 AM, Vladimir Sokolovsky wrote:
OFED-1.2-20070308-0708.tgz is ready.
Since the 32/64 bit builds have been enabled, OMPI has been unable to
compile because of wonkyness in our configure script (see https://
bugs.openfabrics.org/show_bug.cgi?id=421 for details
Hi,
Anyone know who setup or who the contact is for the mail-archive.com
OpenFabrics mail archive ? We should get this to point to the new
mailing list (general@lists.openfabrics.org).
Thanks.
-- Hal
___
general mailing list
OK, I pushed out the patch below. Please let me know if you see any
problems caused by it, or if you think there may be a problem handling
rereg MR and/or MWs with this ABI.
Dotan, do you have any further comments about the completion channel
closing issue? I would really like to freeze the
How do I get to bugzilla?
Scott
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jeff
Squyres (jsquyres)
Sent: Thursday, March 08, 2007 3:58 AM
To: OpenFabrics General; OpenFabrics EWG
Subject: [ewg] openfabrics.org DNS problems
build, say OFED-1.2-20070308-0708.
Configure IPoIB HA to use ib0 and ib1, for example. Make sure your
openibd.conf has these lines:
IPOIB_LOAD=yes
SET_IPOIB_CM=yes
IPOIBHA_ENABLE=yes
PRIMARY_IPOIB_DEV=ib0
SECONDARY_IPOIB_DEV=ib1
After running /etc/init.d/openibd restart, start some IPoIB traffic
Is there a way to reproduce this with the standard linux
build? (I didn't
closely follow the original IPOIB HA threads, so I will look
back over those.)
Possibly, but perhaps it requires the OFED ipoibtools code to reproduce.
Please try OFED 1.2, it is not hard to compile with
, and didn't see anything obviously
wrong. Can you tell me
how to reproduce the issue? (I'm running 2.6.21-rc3.)
Use a recent OFED 1.2 build, say OFED-1.2-20070308-0708.
Configure IPoIB HA to use ib0 and ib1, for example. Make sure your
openibd.conf has these lines:
IPOIB_LOAD=yes
Is there a way to reproduce this with the standard linux build? (I
didn't closely follow the original IPOIB HA threads, so I will look
back over those.)
Not sure what you're asking, but just to be clear, this IPoIB HA is
entirely in userspace (it's a crazy perl script that ups and downs
No standalone script, sorry. But it's simple to automate with expect or
autoexpect using the switch CLI.
Or you can use SNMP to set the interface admin status. Something like
this one-liner for example (using snmpset from the NET SNMP package):
snmpset -v2c -cprivate switch IP
Not sure what you're asking, but just to be clear, this IPoIB HA is
entirely in userspace (it's a crazy perl script that ups and downs
ports in response to various events).
Thanks - this helps.
From a quick look at the code, it does look like there are some races
in ipoib_multicast.c. The place
Then we received wrong information. The command allready gave a clue, but our
cisco contact assured this is bonding and nog HA with active/passive.
Thx for the information!
-Oorspronkelijk bericht-
Van: Scott Weitzenkamp (sweitzen) [mailto:[EMAIL PROTECTED]
Verzonden: do 8-3-2007
Please feel free to take over and replace this patch with whatever you find
fit.
Reverting the misc update patch should work fine. (I can't get to bugzilla
atm
to see the error.) But there were also backport patches for the umca in OFED
1.1.
That code was different: it was
you capture the transaction with tcpdump and use a perl script
provided with xplot to convert it into something xplot can
graph.
megabits of course. so yeah, its pretty awful. and indeed the recv end
of the tcp connection has saturated the cpu at 100%. apparently, this
issue is further
Post a replacement to 2_misc_device_to_2_6_19.patch, we'll test.
I did not test this patch, but you can try replacing the contents of
the 2_misc_device_to_2_6_19.patch with the changes below. (It's
possible that this may lead to some conflict further down in the patch
chain...) The function
There are also IPoIB CM IP multicast problems, see bug 418.
Bug 418 looks different than bug 400.
From the bug report, it sounds like this error is limited to IPoIB CM mode. Is
this correct?
If you try to multicast packets 2KB, you see:
I'm not sure if your hardware supports a max MTU of 2K,
Scott Weitzenkamp (sweitzen) wrote:
Yes, it's limited to IPoIB CM.
I'm talking about IP multicast not IB multicast, so the hardware MTU
should be transparent.
I'll reopen bug 418, who shall I assign it to?
I think Michael owns the IPoIB CM code, so it should probable be assigned to
him. I
On Thu, 2007-03-08 at 17:19, Scott Weitzenkamp (sweitzen) wrote:
Yes, it's limited to IPoIB CM.
I'm talking about IP multicast not IB multicast, so the hardware MTU
should be transparent.
Doesn't IPoIB CM only support IP unicast ? IP multicast should fall back
to using normal IPoIB (UD)
Doesn't IPoIB CM only support IP unicast ? IP multicast
should fall back
to using normal IPoIB (UD) rather than CM (RC).
And that's the problem, it does not fallback.
Scott
___
general mailing list
general@lists.openfabrics.org
Don't get me wrong, I think your patch is ultimately the right way to
go, but it needs another part to address the problem IPv6 has - or at
least a plan on how to address it. I don't think ignoring
the synchronizing problem is the way to go.
OK, I think I've convinced myself that the gain
It is common practice to put a pointer/index to a per-QP
structure inside the wrid. This data is available after poll_cq
returns, when cq lock is not taken. If this pointer is used
directly inside the event handler, the ULP that is moving QP to
reset has no way to
I believe this is a simple fix for the detach before attach race that
Roland pointed out.
I only did some limited testing on my systems, so I can't say that it
will fully fix bug report 400.
Roland, if this looks good to you, let me know and I can push it out to
my git tree.
Signed-off-by: Sean
41 matches
Mail list logo
