[PATCH][TRIVIAL] infiniband-diags/perfquery.8: Add some missing counters to description

2010-06-16 Thread Hal Rosenstock
Also, updated email address Signed-off-by: Hal Rosenstock hal.rosenst...@gmail.com --- diff --git a/infiniband-diags/man/perfquery.8 b/infiniband-diags/man/perfquery.8 index 7e9636e..e01dc2f 100644 --- a/infiniband-diags/man/perfquery.8 +++ b/infiniband-diags/man/perfquery.8 @@ -1,4 +1,4 @@ -.TH

Re: [PATCH v2] ofa_kernel/infiniband node description patch

2010-06-16 Thread Jack Morgenstein
On Tuesday 15 June 2010 23:20, Mike Heinz wrote: Well, the feedback from you was about making sure the description was null terminated. Actually, that feedback was from me :). This *is* settable through sysfs, and still is even when the patch is applied. The problem is that the current

RE: [PATCH v2] ofa_kernel/infiniband node description patch

2010-06-16 Thread Mike Heinz
Jack Morgerstein wrote: Actually, that feedback was from me :). Oops. Well, that explains why Jason was confused. Sorry Jason. Actually, you will still need the install-script setting. If you have several HCA's of the same type installed on a single host, they will all get the same node

[PATCH] pkey fix for ipoib - resubmission

2010-06-16 Thread Mike Heinz
I never got a response to this patch, so I'm sending it again. - IPoIB is coded to use the 1st PKey in the PKey table as its ib0 interface. Additional ib0.pkey interfaces may be created using the /sys/class/... add_child interface. However, there is a race. During normal

Re: [ewg] [PATCH v4] IB Core: RAW ETH support

2010-06-16 Thread Steve Wise
Roland Dreier wrote: I tested it before on the Roland tree ( iboe branch ) and it fails, because it writen in the way suitable for OFED. If adapt the patch to the Roland tree, then appling Mellanox OFED patches will fail, because it changes the same functions in the code. Here is one

[PATCH v3 08/17] opensm: Add new torus routing engine: torus-2QoS, part 2.

2010-06-16 Thread Jim Schutt
Signed-off-by: Jim Schutt jasc...@sandia.gov --- Hmmm, I tried to break up the addition of osm_torus.c into mailing-list-size hunks, but evidently failed on this one; it doesn't seem to have made it to the list. I've attached the patch as a compressed file. Sorry. -- Jim

Re: [ewg] [PATCH v4] IB Core: RAW ETH support

2010-06-16 Thread Moni Shoua
Hi Roland, What the hell is the thinking behind introducing IB_QPT_RAW_ETH? You're inserting an enum value before IB_QPT_RAW_ETY, so any old userspace passing in IB_QPT_RAW_ETY will silently get different behavior depending on the kernel version. And you're creating two constands that

RE: [PATCH] librdmacm/mcraw: Add a new test application for user-space IBV_QPT_RAW_ETH QP type

2010-06-16 Thread Walukiewicz, Miroslaw
No, no more changes are necessary. It is a standalone application. Mirek -Original Message- From: Hefty, Sean Sent: Monday, June 14, 2010 6:33 PM To: Walukiewicz, Miroslaw Cc: linux-rdma@vger.kernel.org Subject: RE: [PATCH] librdmacm/mcraw: Add a new test application for user-space

Re: [ewg] [PATCH v4] IB Core: RAW ETH support

2010-06-16 Thread Moni Shoua
It doesn't even look like this patch and the mlx4 patch were ever posted to linux-rdma. Only to the EWG list. Not 100% correct. See thread from April 30. Patches to core, libibverbs and NES driver were presented there. Granted our dev process may not be documented, but I always assumed

Re: [ewg] [PATCH v4] IB Core: RAW ETH support

2010-06-16 Thread Steve Wise
Moni Shoua wrote: It doesn't even look like this patch and the mlx4 patch were ever posted to linux-rdma. Only to the EWG list. Not 100% correct. See thread from April 30. Patches to core, libibverbs and NES driver were presented there. I'll go look, but I thought the NES stuff

RE: [ewg] [PATCH v4] IB Core: RAW ETH support

2010-06-16 Thread Tung, Chien Tin
It doesn't even look like this patch and the mlx4 patch were ever posted to linux-rdma. Only to the EWG list. Not 100% correct. See thread from April 30. Patches to core, libibverbs and NES driver were presented there. I'll go look, but I thought the NES stuff was for RAW_ETY qp

Re: Mellanox implementation for atomic operations

2010-06-16 Thread Ralph Campbell
The ib_qib driver supports atomic IB operations and they are global since it does it in the host software instead of PCIe bus transactions which don't have global atomic support (yet). On Tue, 2010-06-15 at 13:50 -0700, Dotan Barak wrote: Hi. On 10/05/2010 08:42, lihaidong wrote: Hi, I

Re: [ewg] [PATCH v4] IB Core: RAW ETH support

2010-06-16 Thread Jason Gunthorpe
On Wed, Jun 16, 2010 at 09:09:59AM -0500, Steve Wise wrote: Granted our dev process may not be documented, but I always assumed the general idea was to get changes accepted upstream, then pull into ofed. OFED is just a mechanism to make top-of-tree linux work on distro kernels. There are

Re: [ewg] [PATCH v4] IB Core: RAW ETH support

2010-06-16 Thread Steve Wise
Jason Gunthorpe wrote: On Wed, Jun 16, 2010 at 09:09:59AM -0500, Steve Wise wrote: Granted our dev process may not be documented, but I always assumed the general idea was to get changes accepted upstream, then pull into ofed. OFED is just a mechanism to make top-of-tree linux work on

[PATCH 1/5] dapl-2.0 - ucm: modify debug CM output for consistency, all ports, qpn in hex

2010-06-16 Thread Davis, Arlin R
Patch set for 2.0.29 release - bug fixes, PKEY/SL enhancement. Signed-off-by: Arlin Davis arlin.r.da...@intel.com --- dapl/openib_ucm/cm.c | 121 + 1 files changed, 81 insertions(+), 40 deletions(-) diff --git a/dapl/openib_ucm/cm.c

[PATCH 2/5] dapl-2.0 - ucm: incorrectly freeing port on passive side after reject

2010-06-16 Thread Davis, Arlin R
cm_release was incorrectly freeing a client port assuming it was the server listening port. Move the listening port cleanup to remove_conn_listner and only cleanup client ports in cm_release. Error Messages indicating problem: CM_REQ retry 1 [lid, port, qpn]: 9 ff9a 340085 - 9 6fa 34004e

[PATCH 3/5] dapl-2.0 - configure: need a false conditional for verbs attr.link_layer member check

2010-06-16 Thread Davis, Arlin R
Signed-off-by: Arlin Davis arlin.r.da...@intel.com --- configure.in | 14 +- 1 files changed, 5 insertions(+), 9 deletions(-) diff --git a/configure.in b/configure.in index c36304d..4110024 100644 --- a/configure.in +++ b/configure.in @@ -23,20 +23,16 @@ if test $disable_libcheck

[PATCH 4/5] dapl-2.0 - cma: remove dependency on rdma_cma_abi.h

2010-06-16 Thread Davis, Arlin R
Signed-off-by: Arlin Davis arlin.r.da...@intel.com --- dapl/openib_cma/dapl_ib_util.h |8 dapl/openib_cma/linux/openib_osd.h |1 - 2 files changed, 8 insertions(+), 1 deletions(-) diff --git a/dapl/openib_cma/dapl_ib_util.h b/dapl/openib_cma/dapl_ib_util.h index

[PATCH 5/5] dapl-2.0 - scm, ucm: add pkey, pkey_index, sl override for QP's

2010-06-16 Thread Davis, Arlin R
On a per open basis, add environment variables DAPL_IB_SL, DAPL_IB_PKEY, DAPL_IB_PKEY_INDEX and use on connection setup (QP modify) to override default values of 0 for SL and PKEY index. If pkey is provided then find the pkey index with ibv_query_pkey for dev_attr.max_pkeys. Will be used for RC

RE: [PATCH 5/5] dapl-2.0 - scm, ucm: add pkey, pkey_index, sl override for QP's

2010-06-16 Thread Davis, Arlin R
-Original Message- From: Hefty, Sean Sent: Wednesday, June 16, 2010 10:27 AM To: Davis, Arlin R; linux-rdma@vger.kernel.org; ofw_list Subject: RE: [PATCH 5/5] dapl-2.0 - scm, ucm: add pkey, pkey_index, sl override for QP's On a per open basis, add environment variables DAPL_IB_SL,

RE: [PATCH 5/5] dapl-2.0 - scm, ucm: add pkey, pkey_index, sl override for QP's

2010-06-16 Thread Hefty, Sean
You don't need both, it's just a matter of convenience for consumers. I vote that it's a matter of confusion for consumers. The index isn't guaranteed to be the same across all nodes. If a consumer is going to manually control this, they should really be forced to use the actual pkey. -- To

RE: Handling busy responses from the SA

2010-06-16 Thread Mike Heinz
Hal, But if the original trap had retries 0, wouldn't resending the trap be what the issuer intended? I guess I'm confused why treating BUSY as similar to simply never getting a response at all is a bad thing. In my mind, receiving a BUSY response is like getting a busy signal when you call