[patch] RDMA/nes: silence compiler warning
drivers/infiniband/hw/nes/nes_cm.c:3190:2: warning: format ‘%zu’ expects argument of type ‘size_t’, but argument 11 has type ‘int’ [-Wformat] The warning says the type is int but actually it's unsigned short. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com diff --git a/drivers/infiniband/hw/nes/nes_cm.c b/drivers/infiniband/hw/nes/nes_cm.c index 16667c7..b96ec43 100644 --- a/drivers/infiniband/hw/nes/nes_cm.c +++ b/drivers/infiniband/hw/nes/nes_cm.c @@ -3189,7 +3189,7 @@ int nes_accept(struct iw_cm_id *cm_id, struct iw_cm_conn_param *conn_param) nes_debug(NES_DBG_CM, QP%u, Destination IP = 0x%08X:0x%04X, local = 0x%08X:0x%04X, rcv_nxt=0x%08X, snd_nxt=0x%08X, mpa + - private data length=%zu.\n, nesqp-hwqp.qp_id, + private data length=%d.\n, nesqp-hwqp.qp_id, ntohl(cm_id-remote_addr.sin_addr.s_addr), ntohs(cm_id-remote_addr.sin_port), ntohl(cm_id-local_addr.sin_addr.s_addr), -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch] RDMA/nes: silence compiler warning
Dan Carpenter Wrote:
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/infiniband/hw/nes/nes_cm.c
b/drivers/infiniband/hw/nes/nes_cm.c
index 16667c7..b96ec43 100644
--- a/drivers/infiniband/hw/nes/nes_cm.c
+++ b/drivers/infiniband/hw/nes/nes_cm.c
@@ -3189,7 +3189,7 @@ int nes_accept(struct iw_cm_id *cm_id, struct
iw_cm_conn_param *conn_param)
nes_debug(NES_DBG_CM, QP%u, Destination IP = 0x%08X:0x%04X,
local =
0x%08X:0x%04X, rcv_nxt=0x%08X, snd_nxt=0x%08X, mpa +
- private data length=%zu.\n, nesqp-hwqp.qp_id,
+ private data length=%d.\n, nesqp-hwqp.qp_id,
ntohl(cm_id-remote_addr.sin_addr.s_addr),
ntohs(cm_id-remote_addr.sin_port),
ntohl(cm_id-local_addr.sin_addr.s_addr),
Acked-by: Faisal Latif faisal.la...@intel.com
N�r��yb�X��ǧv�^�){.n�+{��ٚ�{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
Re: Building 3.1-rc9 in kernel infiniband support with OFED libraries
On Fri, Oct 14, 2011 at 2:22 PM, Doug Ledford dledf...@redhat.com wrote: - Original Message - On Wed, Oct 12, 2011 at 9:32 AM, Wendy Cheng s.wendy.ch...@gmail.com wrote: The OFED package itself does include XRC support. The issue here (my guess) is that its build script needs to understand the running system's kernel version to decide what should be pulled (from the source). Linux 3.1 could be too new for OFED build script to make a correct decision. Nevertheless, mix-matching OFED modules/libraries is a *bad* idea. No. The same userspace build should work with all kernel versions. Wendy's referring to something other than what you are thinking. The same libibverbs user space build should work on all kernels going back a long way, except when you are talking about OFED their libibverbs is hard coded to assume XRC support and fail if it isn't present, so an OFED libibverbs won't really work without also the OFED kernel module stack. The script Wendy referred to is the script that checks the running kernel's version in order to determine which backport patches need applied to the ofa_kernel source tree in order to build the OFED kernel modules for your running kernel. Without that ofa_kernel build, the OFED libibverbs will indeed fail to run on the running kernel. And that script hasn't been updated to support version 3.x kernels last I checked, so she's right, the script itself doesn't recognize the running kernel version, so ofa_kernel modules don't get built, so OFED libibverbs won't work anyway. So, she's absolutely right, unless you want to start ripping hard coded assumptions about the existence of XRC support out of things like OFED's libibverbs, then out of qperf and a number of their other various packages, then you have to pair the OFED kernel modules and user space packages, they can not be separated. Yes, that (above) is exactly what I was referring to . The conversations in this thread remind me of the tire-swing cartoon that has been passing around for years: http://bibiananunes.com/user-requirements-the-tire-swing-cartoon ) -- Wendy -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] rdma/core: Really export ib_open_qp() to user space
So what else would you suggest for further testing, is that pulling
the xrc branch of your ofa hosted librdmacm/libibverbs/libmlx4 trees
and run librdmacm's rdma_{xclient,xserver} example? I was a bit confused
since I see this example both in the master and the xrc brach.
I wanted to keep the rdma_client / rdma_server tests as simple as possible, but
I still wanted a more complete client / server test where I could add RDMA
reads / writes / etc. The rdma_xclient / rdma_xserver tests are a place for
those. They support RC and XRC, so they're in the master branch for the RC
support. I have extensions for them in a private branch which aren't quite
ready yet.
For my testing, I pulled mvapich2 and run with and without xrc support, plus
the normal verbs tests. For the xrc support I have to build with the OFED
compatibility APIs added into verbs.
BTW the master branch misses a tag for v1.0.15...
thanks - I'll add.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] opensm/main.c: Change size parameter in setvbuf call from 0 to BUFSIZ
to eliminate Win8 assert as this is shared code Signed-off-by: Hal Rosenstock h...@mellanox.com --- opensm/main.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/opensm/main.c b/opensm/main.c index 51c8291..f7a6d83 100644 --- a/opensm/main.c +++ b/opensm/main.c @@ -645,7 +645,7 @@ int main(int argc, char *argv[]) }; /* force stdout to be line-buffered */ - setvbuf(stdout, NULL, _IOLBF, 0); + setvbuf(stdout, NULL, _IOLBF, BUFSIZ); /* Make sure that the opensm and complib were compiled using same modes (debug/free) */ -- 1.7.6.1 -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH][TRIVIAL] opensm/osm_sa_mcmember_record.c: Commentary changes relating to SA assigned MGIDs
Update one comment to be more accurate
and remove comment which appears to no longer apply
Signed-off-by: Hal Rosenstock h...@mellanox.com
---
opensm/osm_sa_mcmember_record.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/opensm/osm_sa_mcmember_record.c b/opensm/osm_sa_mcmember_record.c
index ad48d00..43323ca 100644
--- a/opensm/osm_sa_mcmember_record.c
+++ b/opensm/osm_sa_mcmember_record.c
@@ -615,7 +615,7 @@ static ib_api_status_t validate_requested_mgid(IN osm_sa_t
* sa,
/*
* For SA assigned MGIDs (signature 0xA01B):
-* There is no real way to make sure the Unique MGID Prefix is really
unique.
+* There is no real way to make sure the GID Prefix is really unique.
* If we could enforce using the Subnet Prefix for that purpose it would
* have been nice. But the spec does not require it.
*/
@@ -776,7 +776,6 @@ static unsigned build_new_mgid(osm_sa_t * sa, ib_net64_t
comp_mask,
mgid-raw[2] = 0xa0;
mgid-raw[3] = 0x1b;
- /* HACK: use the SA port gid to make it globally unique */
memcpy(mgid-raw[4], sa-p_subn-opt.subnet_prefix, sizeof(uint64_t));
for (i = 0; i 1000; i++) {
--
1.7.6.1
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] RDMA/nes: silence compiler warning
Thanks, I rolled this into the patch (which was still pending) that introduced this into my tree. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] RDMA/nes: silence compiler warning
On Mon, Oct 17, 2011 at 12:28 AM, Dan Carpenter dan.carpen...@oracle.com wrote: nes_debug(NES_DBG_CM, QP%u, Destination IP = 0x%08X:0x%04X, local = 0x%08X:0x%04X, rcv_nxt=0x%08X, snd_nxt=0x%08X, mpa + - private data length=%zu.\n, nesqp-hwqp.qp_id, + private data length=%d.\n, nesqp-hwqp.qp_id, ntohl(cm_id-remote_addr.sin_addr.s_addr), ntohs(cm_id-remote_addr.sin_port), ntohl(cm_id-local_addr.sin_addr.s_addr), By the way, could this debug message be using %pI4 instead of %08X to print IP addresses? - R. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch] RDMA/nes: silence compiler warning
-Original Message- From: rol...@purestorage.com [mailto:rol...@purestorage.com] On Behalf Of Roland Dreier Sent: Monday, October 17, 2011 1:15 PM To: Dan Carpenter Cc: Latif, Faisal; Hefty, Sean; Hal Rosenstock; linux- r...@vger.kernel.org; kernel-janit...@vger.kernel.org Subject: Re: [patch] RDMA/nes: silence compiler warning On Mon, Oct 17, 2011 at 12:28 AM, Dan Carpenter dan.carpen...@oracle.com wrote: nes_debug(NES_DBG_CM, QP%u, Destination IP = 0x%08X:0x%04X, local = 0x%08X:0x%04X, rcv_nxt=0x%08X, snd_nxt=0x%08X, mpa + - private data length=%zu.\n, nesqp-hwqp.qp_id, + private data length=%d.\n, nesqp-hwqp.qp_id, ntohl(cm_id-remote_addr.sin_addr.s_addr), ntohs(cm_id-remote_addr.sin_port), ntohl(cm_id-local_addr.sin_addr.s_addr), By the way, could this debug message be using %pI4 instead of %08X to print IP addresses? - R. Yes, We should have used %pI4 for this also. Thanks Faisal -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rdma/core: Really export ib_open_qp() to user space
Hefty, Sean sean.he...@intel.com wrote:
The rdma_xclient / rdma_xserver tests are a place for those. They support RC
and
XRC, so they're in the master branch for the RC support. I have extensions
for them in
a private branch which aren't quite ready yet.
again, and just to make sure I got it - for basic XRC testing which
doesn't go to MPI nor to the OFED compatability APIs, what env/test
would you recommend - is that the xrc branch on the three libraries
and rdma_x{client, server}?
Or.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] rdma/core: Really export ib_open_qp() to user space
again, and just to make sure I got it - for basic XRC testing which doesn't go
to MPI nor to
the OFED compatability APIs, what env/test would you recommend - is that the
xrc branch on the three libraries and rdma_x{client, server}?
Yes - please make sure you have pulled those branches recently (since last
Friday). The rdma_cm tests are fairly simple and just transfer one direction.
The ibv_xsrq_pingpong tests will connect and transfer data both ways.
- Sean
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rdma: 3.1.0-rc9 breaks UD
On Fri, Oct 14, 2011 at 4:02 PM, Christoph Lameter c...@gentwo.org wrote: Running ibv_ud_pingpong and ibc_uc_pingpong between two hosts. One with OFED 1.5.3.1 (Ubuntu LTS 10.04) and another on linux 3.1.0-rc9 (Same ubuntu version uderlying) with the upstream libraries. ibv_ud_pingpong OFED: # ibv_ud_pingpong local address: LID 0x000a, QPN 0x50004d, PSN 0x8b572b: GID :: remote address: LID 0x000b, QPN 0x02004c, PSN 0x2117ef, GID :: 3.1.0-rc9: # ibv_ud_pingpong 10.2.35.21 local address: LID 0x000b, QPN 0x02004c, PSN 0x2117ef: GID :: remote address: LID 0x000a, QPN 0x50004d, PSN 0x8b572b, GID :: No traffic flows. Could you try that again with small msg size e.g use -s 100, if that doesn't help can you send the output of ibv_devinfo from both nodes. Also please specify the exact top commit of the two libraries (libibverbs and I assume libmlx4 if you use Mellanox ConnectX) in case you built them from the git trees, or the library version if you're using official release, thanks, Or. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -next] infiniband: fix printk format in hw/nes_cm.c
Thanks, rolled this into the offending commit. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OpenSM plugin patch request
Thanks for explaining the enum convention - quite logical indeed. Also, thanks for some of the off-list discussion where we tried to see if any of the current event callbacks could be used to achieve the desired support. As it stands, it still sounds like including light sweep events is the simplest solution and I'm attaching an updated patch for consideration which honors the MAX convention. Thanks, Karl On Oct 13, 2011, at 7:50 AM, Yevgeny Kliteynik wrote: Hi Karl, The idea in that if the received event is = OSM_EVENT_ID_MAX, then the plug-in knows that something went wrong (wrong version, something changed in API, etc). Also, you might want to know about more stuff if you're pulling topology/routing info from SM, such as when SM became stand-by and when it became master, and when re-route was done. Please see this patch for reference: http://www.mail-archive.com/linux-rdma@vger.kernel.org/msg02206.html It wasn't applied as is back then, but you might want it now. -- YK On 13-Oct-11 4:50 AM, Karl Schulz wrote: Thanks Ira, My apologies for not following the conventional standard. Should I generate a new patch? -k On Oct 12, 2011, at 5:13 PM, Ira Weiny wrote: I think this is a reasonable idea. Comment on the patch. - OSM_EVENT_ID_MAX + OSM_EVENT_ID_MAX, + OSM_EVENT_ID_LIGHT_SWEEP_START, + OSM_EVENT_ID_LIGHT_SWEEP_DONE, Traditionally the MAX value in the enum is kept at the end. Ira On Wed, 12 Oct 2011 14:31:07 -0700 Karl Schulzk...@tacc.utexas.edu wrote: Hello, Would it be possible to consider exposing light-sweep events to the current OpenSM plugin interface? Something along the lines of the attached patch is what we are using locally against opensm-3.3.9. The motivation is to support a plugin module we have written to expose topology information to a query service which can be used by MPI stacks (in user-space) for topology-aware optimization and for topology-aware scheduling via batch systems. Thanks for the consideration, Karl -- Ira Weiny Member of Technical Staff Lawrence Livermore National Lab 925-423-8008 wei...@llnl.gov -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html opensm.patch Description: opensm.patch
Re: OpenSM plugin patch request
Hi Karl, On 10/17/2011 5:43 PM, Karl Schulz wrote: Thanks for explaining the enum convention - quite logical indeed. Also, thanks for some of the off-list discussion where we tried to see if any of the current event callbacks could be used to achieve the desired support. As it stands, it still sounds like including light sweep events is the simplest solution and I'm attaching an updated patch for consideration which honors the MAX convention. A couple of minor comments: 1. Why not move the OSM_EVENT_ID_LIGHT_SWEEP_DONE event to where LIGHT SWEEP COMPLETE is indicated in osm_state_mgr.c ? That's actually more accurate as all the transactions have completed. 2. The new events should be added to osmeventplugin/src/osmeventplugin.c example. Thanks. -- Hal Thanks, Karl On Oct 13, 2011, at 7:50 AM, Yevgeny Kliteynik wrote: Hi Karl, The idea in that if the received event is = OSM_EVENT_ID_MAX, then the plug-in knows that something went wrong (wrong version, something changed in API, etc). Also, you might want to know about more stuff if you're pulling topology/routing info from SM, such as when SM became stand-by and when it became master, and when re-route was done. Please see this patch for reference: http://www.mail-archive.com/linux-rdma@vger.kernel.org/msg02206.html It wasn't applied as is back then, but you might want it now. -- YK On 13-Oct-11 4:50 AM, Karl Schulz wrote: Thanks Ira, My apologies for not following the conventional standard. Should I generate a new patch? -k On Oct 12, 2011, at 5:13 PM, Ira Weiny wrote: I think this is a reasonable idea. Comment on the patch. - OSM_EVENT_ID_MAX + OSM_EVENT_ID_MAX, + OSM_EVENT_ID_LIGHT_SWEEP_START, + OSM_EVENT_ID_LIGHT_SWEEP_DONE, Traditionally the MAX value in the enum is kept at the end. Ira On Wed, 12 Oct 2011 14:31:07 -0700 Karl Schulzk...@tacc.utexas.edu wrote: Hello, Would it be possible to consider exposing light-sweep events to the current OpenSM plugin interface? Something along the lines of the attached patch is what we are using locally against opensm-3.3.9. The motivation is to support a plugin module we have written to expose topology information to a query service which can be used by MPI stacks (in user-space) for topology-aware optimization and for topology-aware scheduling via batch systems. Thanks for the consideration, Karl -- Ira Weiny Member of Technical Staff Lawrence Livermore National Lab 925-423-8008 wei...@llnl.gov -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
