Sean Hefty wrote:
Note that since the HCA validates the pkey in the in coming packet, no
matter what the IB SW would do, partial members of a partition can't
talk to each other. So the approach taken by the core/ipoib code was
to just ignore the MSb in places where the code looks for the pkey
Quoting Scott Weitzenkamp (sweitzen) [EMAIL PROTECTED]:
Subject: anyone have OFED 1.2 alpha1 compiling on ppc64
I tried both RHEL4 and SLES10 usinstall.sh, and get this. I filed bug 379,
anyone else tried ppc64?
Scott, could pls you upload the kernel sources and .config files to staging?
Emailin english :
Si vous avez des difficultees pour visualiser cette page , cliquezici
:
Build failed on ia64 with linux-2.6.16.21-0.8-default
Log:
/home/vlad/tmp/ofa_1_2_kernel-20070222-0200_linux-2.6.16.21-0.8-default_ia64_check/include/rdma/ib_verbs.h:1590:
error: implicit declaration of function âsg_dma_lenâ
/home/vlad/tmp/ofa_1_2_kernel-20070222-0200_linux-2.6.16.21-0.8
:
Build failed on ia64 with linux-2.6.16.21-0.8-default
Log:
/home/vlad/tmp/ofa_1_2_kernel-20070222-0251_linux-2.6.16.21-0.8-default_ia64_check/include/rdma/ib_verbs.h:1590:
error: implicit declaration of function 'sg_dma_len'
/home/vlad/tmp/ofa_1_2_kernel-20070222-0251_linux-2.6.16.21-0.8
On Thu, 2007-02-15 at 13:59 -0600, Steve Wise wrote:
Fix copyrights in the cxgb3 driver.
Remove the Open Grid Computing copyright. It shouldn't be there.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
Applied.
--
Vladimir Sokolovsky [EMAIL PROTECTED]
Mellanox Technologies Ltd.
On Thu, 2007-02-15 at 14:00 -0600, Steve Wise wrote:
Fix copyrights in the iw_cxgb3 driver.
Remove the Open Grid Computing copyright. It shouldn't be there.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
Applied.
--
Vladimir Sokolovsky [EMAIL PROTECTED]
Mellanox Technologies Ltd.
On Thu, 2007-02-22 at 02:11, Scott Weitzenkamp (sweitzen) wrote:
I tried both RHEL4 and SLES10 usinstall.sh, and get this. I filed bug
379, anyone else tried ppc64?
gcc -DHAVE_CONFIG_H -I. -I. -I. -I./include/infiniband
-I./../libibcommon/incl\
ude/infiniband -Wall -m64 -g -O2 -MT
On Wed, 2007-02-21 at 14:46 -0600, Steve Wise wrote:
Stop the ep timer in ec_status() if the status indicates a
bad close.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/iwch_cm.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git
The code below was just added to libibverbs/Makefile.am
install-data-hook:
cd $(DESTDIR)$(mandir)/man3 \
$(LN_S) ibv_get_async_event.3 ibv_ack_async_event.3 \
This creates a problem when re-compiling/re-installing libibverbs --
the ln -s ( = $(LN_S) ) fails because
Is there a reason not to use
man_MANS = ibv_get_async_event.3
?
On Feb 22, 2007, at 7:32 AM, Jack Morgenstein wrote:
The code below was just added to libibverbs/Makefile.am
install-data-hook:
cd $(DESTDIR)$(mandir)/man3 \
$(LN_S) ibv_get_async_event.3
Quoting Jack Morgenstein [EMAIL PROTECTED]:
Subject: libibverbs: can't compile more than once due to man3 symbolic links
The code below was just added to libibverbs/Makefile.am
install-data-hook:
cd $(DESTDIR)$(mandir)/man3 \
$(LN_S) ibv_get_async_event.3
Blah -- disregard; I read the mail too quickly and didn't look at the
actual Makefile.am to see what you were really asking.
FWIW, the install app, by default, removes things before copying in
the new target. So putting a manual rm -f in here, while klunky,
has precedent and will make it
The following patch removes manpage symbolic links so that
they may be relinked in the install.
Suggested by Michael Tsirkin.
Signed-off-by: Jack Morgenstein [EMAIL PROTECTED]
diff --git a/Makefile.am b/Makefile.am
index 5d2383e..455041e 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -70,6
Divy,
Do these need to be pulled into OFED 1.2 as well?
Steve.
On Thu, 2007-02-22 at 03:58 -0800, Divy Le Ray wrote:
Jeff,
I'm sending a series of incremental patches updating
the cxgb3 driver. These patches are built against Linus'git tree.
Cheers,
Divy
-
To unsubscribe from this
On Thu, 2007-02-22 at 02:28, Or Gerlitz wrote:
Hal Rosenstock wrote:
On Wed, 2007-02-21 at 15:45, Or Gerlitz wrote:
On 21 Feb 2007 08:20:23 -0500, Hal Rosenstock [EMAIL PROTECTED] wrote:
If the IPoIB spec does not allow both partial and full members of a
partition to share a broadcast
On Thu, 2007-02-22 at 03:04, Or Gerlitz wrote:
Sean Hefty wrote:
Note that since the HCA validates the pkey in the in coming packet, no
matter what the IB SW would do, partial members of a partition can't
talk to each other. So the approach taken by the core/ipoib code was
to just ignore
I have tested RH4 U4 and to some extent also RH5 beta and see the following:
under RH4 U4
- rping: addr and route resolution passing, client getting reject on conn req
- udaddy: working fine on both UDP and IPOIB port spaces
- mckey: not applicable on RH4 U4 till my patch with
What device?
On Thu, 2007-02-22 at 17:07 +0200, Or Gerlitz wrote:
I have tested RH4 U4 and to some extent also RH5 beta and see the following:
under RH4 U4
- rping: addr and route resolution passing, client getting reject on conn req
- udaddy: working fine on both UDP and
Steve Wise wrote:
What device?
mthca
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
librdmacm: couldn't read ABI version.
librdmacm: assuming: 4
I think there was a kernel patch from Woody to address this.
Woody?
--
MST
___
openib-general mailing list
openib-general@openib.org
On Wed, 2007-02-21 at 16:40 -0600, Tom Tucker wrote:
Bug: 355 (problems building modules that depend on OFED 1.2 modules)
In order to build kernel modules depending on OFED's modules you need to
take Modules.symvers file from prefix/src/openib/Modules.symvers (part
of kernel-ib-devel
The list will now be migrated on Wednesday, 2/28/2007.
List address: [EMAIL PROTECTED]
Updated change-date: Wednesday, 2/28/2007
Michael
-Original Message-
From: Jeff Squyres [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 21, 2007 8:09 AM
To: Michael S. Tsirkin
Cc:
That missing header (common.h) is in libibcommon. Somehow, libibcommon
is not installed. libibumad depends on libibcommon. Is this a
build/install script issue with OFED 1.2 ? Vlad ?
-- Hal
I tried install.sh again, this time telling it to build libibcommon
instead of relying on
My understanding is that when an IPoIB broadcast domain contains both
partial and full members (*) attempts to communicate between two partial
members would silently fail, does this silence is something you think we
should work to change?
I'm looking at this from a different view than just ipoib
An IB multicast group _cannot_ have partial members so this never should
get far enough to where two limited members would be unable to
communicate.
Can someone help my understanding here? Is ipoib joining a multicast group
using the full membership PKey, even if the node that it joins from only
Missed 2 lines in the patch.
Below is the correct patch:
---
The following patch removes manpage symbolic links so that
they may be relinked in the install.
Suggested by Michael Tsirkin.
Signed-off-by: Jack Morgenstein [EMAIL PROTECTED]
diff --git a/Makefile.am b/Makefile.am
index
Could anyone tell me why this routine in mthca is necessary? There
aren't any comments to explain it; I'm wondering if this is a workaround
for Sinai of some kind?
static inline u32 adjust_key(struct mthca_dev *dev, u32 key)
{
if (dev-mthca_flags MTHCA_FLAG_SINAI_OPT)
return
Thanks, I applied this and pushed it out.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
A first-cut at a patch was sent out, some very reasonable
objections were raised, and the thread fizzled out.
Sorry, I meant to respond again, but I never got around to it.
The biggest concern with the earlier patch seemed to be
backward compatibility. There was a stab at addressing
Could anyone tell me why this routine in mthca is necessary? There
aren't any comments to explain it; I'm wondering if this is a workaround
for Sinai of some kind?
static inline u32 adjust_key(struct mthca_dev *dev, u32 key)
{
if (dev-mthca_flags MTHCA_FLAG_SINAI_OPT)
On Thu, Feb 22, 2007 at 10:34:16AM -0800, Roland Dreier wrote:
I actually have a vague plan for a somewhat cleaner way to get this
fix. For a variety of reasons, I am planning on changing the way the
kernel handles memory registration so that low-level drivers have more
control over what
Assuming that something along the lines of the previous patch
is used, we need to address userspace/kernel compatibility.
The existing abi versioning doesn't seem to be exactly what
we want to use, though, because we want to change a verb's
semantics to work around a bug. (Changing
https://bugs.openfabrics.org/show_bug.cgi?id=384
Summary: OFED 1.2 alpha1 ib-bonding won't compile on RHEL4 U3
ppc64
Product: OpenFabrics Linux
Version: 1.2alpha1
Platform: PPC64
OS/Version: RHEL 4
Status: NEW
We found this accidentally, running a normal MPI job, on a
normally sized machine (i.e., tens, not hundreds of
processors.) It appears to be more easily produced that
we'd expected, and we consider it to be a severe problem.
Hmm, OK. Then I will do my best to make sure we get a fix
Hi Scott,
Try OFED-1.2-20070221-1741. This issue was fixed in this package.
Regards,
Vladimir
-Original Message-
From: Scott Weitzenkamp (sweitzen) [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 22, 2007 7:36 PM
To: Hal Rosenstock
Cc: [EMAIL PROTECTED]; OPENIB; Vladimir Sokolovsky
On 2/22/07, Sean Hefty [EMAIL PROTECTED] wrote:
An IB multicast group _cannot_ have partial members so this never should
get far enough to where two limited members would be unable to
communicate.
Can someone help my understanding here? Is ipoib joining a multicast group
using the full
On 2/22/07, Sean Hefty [EMAIL PROTECTED] wrote:
My understanding is that when an IPoIB broadcast domain contains both
partial and full members (*) attempts to communicate between two partial
members would silently fail, does this silence is something you think we
should work to change?
I'm
Quoting Roland Dreier [EMAIL PROTECTED]:
Subject: Re: [PATCH for-2.6.21] IPoIB/cm: improve small message bandwidth
Thanks, queued for 2.6.21. With this patch I see small-packet latency
down almost all the way back to what datagram mode gives -- on a pair
of fast woodcrest systems I see
1. Is there something special you do when you run the benchmark (msi,
taskset, ...)?
Yes, I am using MSI-X, and I pin the interrupt handler to one CPU
(CPU#0 in my particular case). Then I use taskset to pin the NPtcp
process to a CPU in a different package (CPU#2 in my system).
BTW with
How do I upload sources?
-Original Message-
From: Michael S. Tsirkin [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 22, 2007 1:00 AM
To: Scott Weitzenkamp (sweitzen)
Cc: [EMAIL PROTECTED]; OPENIB
Subject: Re: anyone have OFED 1.2 alpha1 compiling on ppc64
Quoting Scott
OK, I applied the following patch (I had to change one line of your
patch to get it to apply because the small-message changed the context
so one chunk didn't apply).
Anyway I don't see any difference in small message latency or large
message throughput. (Actually latency seems slightly worse
Don't you have an account at ssh.openfabrics.org?
If yes, just put kernel sources and the .config under your home directory
Quoting r. Scott Weitzenkamp (sweitzen) [EMAIL PROTECTED]:
Subject: Re: anyone have OFED 1.2 alpha1 compiling on ppc64
How do I upload sources?
-Original Message-
Quoting Roland Dreier [EMAIL PROTECTED]:
Subject: Re: [PATCH for-2.6.21] IPoIB/cm: improve small message bandwidth
OK, I applied the following patch (I had to change one line of your
patch to get it to apply because the small-message changed the context
so one chunk didn't apply).
Anyway
Don't you have an account at ssh.openfabrics.org?
Can an admin please give me an account?
Scott
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit
Quoting Scott Weitzenkamp (sweitzen) [EMAIL PROTECTED]:
Subject: RE: anyone have OFED 1.2 alpha1 compiling on ppc64
Don't you have an account at ssh.openfabrics.org?
Can an admin please give me an account?
I'm not an admin but I think you want to post your ssh
public key.
--
MST
Can someone help my understanding here? Is ipoib joining a multicast group
using the full membership PKey, even if the node that it joins from only has
the
limited membership PKey configured? And the code in ib_find_cached_pkey helps
enable this?
Yep. The ipoib create_child function Or-s
An API idea:
how about instead testing missed_events, we add a flag:
IB_CQ_TEST (or a longer name IB_CQ_REPORT_MISSED_EVENTS?)
and change ib_req_notify_cq to return int which will keep
the missed_events value, only if this flag is set?
This has 2 advatages
- Less churn
By the way, how about extending the userspace API in a similiar
fashion?
missed_events = ibv_req_notify_cq(priv-cq, IBV_CQ_NEXT_COMP |
IBV_CQ_REPORT_MISSED_EVENTS)
It would require a kernel-user ABI bump. Is it worth it?
- R.
Doesn't this allow ipoib to join a multicast group for which it may not be able
to communicate with all members? For the broadcast group, this seems like an
error to me. Can ipoib work in such a configuration? If all nodes were
assigned a partial membership PKey, none of them could communicate,
Quoting Roland Dreier [EMAIL PROTECTED]:
Subject: Re: IPOIB NAPI
By the way, how about extending the userspace API in a similiar
fashion?
missed_events = ibv_req_notify_cq(priv-cq, IBV_CQ_NEXT_COMP |
IBV_CQ_REPORT_MISSED_EVENTS)
It would require
GCC seems to be unable to propogate constants across calls to htonl.
So it turns out to be worth the while to replace htonl with
a hand-written macro in case of constant parameter.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
Signed-off-by: Ishai Rabinovitz [EMAIL PROTECTED]
---
Roland,
Steve Wise wrote:
Divy,
Do these need to be pulled into OFED 1.2 as well?
Hi Steve,
Yes, I believe so.
Cheers,
Divy
Steve.
On Thu, 2007-02-22 at 03:58 -0800, Divy Le Ray wrote:
Jeff,
I'm sending a series of incremental patches updating
the cxgb3 driver. These patches are
Roland,
Please consider the following minor fixes for 2.6.21:
rdma_cm: remove unused node_guid from cma_device structure.
ib_cm: remove ca_guid from cm_device structure.
rdma_cm: request reversible paths only.
ib_core: Set hop limit in ib_init_ah_from_wc correctly.
The patches are in
These all look fine, I'll queue them up.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
I notice that the actual patches you committed don't have your
sign-off in the git changelog. I assume this is a mistake so I'll add
it back in...
___
I notice that the actual patches you committed don't have your
sign-off in the git changelog. I assume this is a mistake so I'll add
it back in...
which means I can't just pull your branch. But that's OK, still doing
git format-patch, edit patches, git am is pretty easy.
The patches are in git.openfabrics.org/~shefty/rdma-dev.git,
for-roland branch, which is based on 2.6.21-rc1.
One other request: please include a URL that I can just copy and
paste, so I don't actually have to read and parse complete sentences.
Something like:
the patches are in
Anyway, all 4 queued up in my for-2.6.21 branch
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
the patches are in
git://git.openfabrics.org/~shefty/rdma-dev.git for-roland
I will do that in the future.
And yes, the sign off line was just a mistake. Thanks for fixing that.
- Sean
___
openib-general mailing list
openib-general@openib.org
GCC seems to be unable to propogate constants across calls to htonl.
So it turns out to be worth the while to replace htonl with
a hand-written macro in case of constant parameter.
I'm wondering why this helps you. On my system (which has Debian's
old glibc 2.3.6, certainly nothing
On Thu, Feb 22, 2007 at 10:09:28PM -0800, Roland Dreier wrote:
(BTW, one thing I did notice while looking at the i386 assembly is
that one micro-optimization that might make sense to use something
like __attribute__((regparm(3))) for internal function calls within
libibverbs and libmthca on
61 matches
Mail list logo
