[PATCH/libmlx4] Use BlueFlame for RDMA_WRITE_WITH_IMM without data requests too
Use BlueFlame for RDMA Write with immediate without any data (no s/g) too. This improves latency. Signed-off-by: Dotan Barak dot...@dev.mellanox.co.il Reviewed-by: Jack Morgenstein ja...@dev.mellanox.co.il --- src/qp.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/src/qp.c b/src/qp.c index e046da1..10ccbff 100644 --- a/src/qp.c +++ b/src/qp.c @@ -283,8 +283,11 @@ int mlx4_post_send(struct ibv_qp *ibqp, struct ibv_send_wr *wr, case IBV_WR_RDMA_READ: inl = 1; /* fall through */ - case IBV_WR_RDMA_WRITE: case IBV_WR_RDMA_WRITE_WITH_IMM: + if (!wr-num_sge) + inl = 1; + /* fall through */ + case IBV_WR_RDMA_WRITE: set_raddr_seg(wqe, wr-wr.rdma.remote_addr, wr-wr.rdma.rkey); wqe += sizeof (struct mlx4_wqe_raddr_seg); -- 1.5.3 -- 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
[PATCHv2] libibmad: Add PortExtendedSpeedsCounters support
Signed-off-by: Hal Rosenstock h...@mellanox.com
---
diff --git a/include/infiniband/mad.h b/include/infiniband/mad.h
index 7500e1a..f00bf7a 100644
--- a/include/infiniband/mad.h
+++ b/include/infiniband/mad.h
@@ -175,6 +175,7 @@ enum GSI_ATTR_ID {
IB_GSI_PORT_RCV_ERROR_DETAILS = 0x15,
IB_GSI_PORT_XMIT_DISCARD_DETAILS = 0x16,
IB_GSI_PORT_COUNTERS_EXT = 0x1D,
+ IB_GSI_PORT_EXT_SPEEDS_COUNTERS = 0x1F,
IB_GSI_PORT_XMIT_DATA_SL = 0x36,
IB_GSI_PORT_RCV_DATA_SL = 0x37,
IB_GSI_ATTR_LAST
@@ -759,6 +760,51 @@ enum MAD_FIELDS {
IB_PORT_LINK_SPEED_EXT_ENABLED_F,
IB_PORT_LINK_SPEED_EXT_LAST_F,
+ /*
+* PortExtendedSpeedsCounters fields
+*/
+ IB_PESC_PORT_SELECT_F,
+ IB_PESC_COUNTER_SELECT_F,
+ IB_PESC_SYNC_HDR_ERR_CTR_F,
+ IB_PESC_UNK_BLOCK_CTR_F,
+ IB_PESC_ERR_DET_CTR_LANE0_F,
+ IB_PESC_ERR_DET_CTR_LANE1_F,
+ IB_PESC_ERR_DET_CTR_LANE2_F,
+ IB_PESC_ERR_DET_CTR_LANE3_F,
+ IB_PESC_ERR_DET_CTR_LANE4_F,
+ IB_PESC_ERR_DET_CTR_LANE5_F,
+ IB_PESC_ERR_DET_CTR_LANE6_F,
+ IB_PESC_ERR_DET_CTR_LANE7_F,
+ IB_PESC_ERR_DET_CTR_LANE8_F,
+ IB_PESC_ERR_DET_CTR_LANE9_F,
+ IB_PESC_ERR_DET_CTR_LANE10_F,
+ IB_PESC_ERR_DET_CTR_LANE11_F,
+ IB_PESC_FEC_CORR_BLOCK_CTR_LANE0_F,
+ IB_PESC_FEC_CORR_BLOCK_CTR_LANE1_F,
+ IB_PESC_FEC_CORR_BLOCK_CTR_LANE2_F,
+ IB_PESC_FEC_CORR_BLOCK_CTR_LANE3_F,
+ IB_PESC_FEC_CORR_BLOCK_CTR_LANE4_F,
+ IB_PESC_FEC_CORR_BLOCK_CTR_LANE5_F,
+ IB_PESC_FEC_CORR_BLOCK_CTR_LANE6_F,
+ IB_PESC_FEC_CORR_BLOCK_CTR_LANE7_F,
+ IB_PESC_FEC_CORR_BLOCK_CTR_LANE8_F,
+ IB_PESC_FEC_CORR_BLOCK_CTR_LANE9_F,
+ IB_PESC_FEC_CORR_BLOCK_CTR_LANE10_F,
+ IB_PESC_FEC_CORR_BLOCK_CTR_LANE11_F,
+ IB_PESC_FEC_UNCORR_BLOCK_CTR_LANE0_F,
+ IB_PESC_FEC_UNCORR_BLOCK_CTR_LANE1_F,
+ IB_PESC_FEC_UNCORR_BLOCK_CTR_LANE2_F,
+ IB_PESC_FEC_UNCORR_BLOCK_CTR_LANE3_F,
+ IB_PESC_FEC_UNCORR_BLOCK_CTR_LANE4_F,
+ IB_PESC_FEC_UNCORR_BLOCK_CTR_LANE5_F,
+ IB_PESC_FEC_UNCORR_BLOCK_CTR_LANE6_F,
+ IB_PESC_FEC_UNCORR_BLOCK_CTR_LANE7_F,
+ IB_PESC_FEC_UNCORR_BLOCK_CTR_LANE8_F,
+ IB_PESC_FEC_UNCORR_BLOCK_CTR_LANE9_F,
+ IB_PESC_FEC_UNCORR_BLOCK_CTR_LANE10_F,
+ IB_PESC_FEC_UNCORR_BLOCK_CTR_LANE11_F,
+ IB_PESC_LAST_F,
+
IB_FIELD_LAST_ /* must be last */
};
@@ -1091,7 +1137,7 @@ MAD_EXPORT ib_mad_dump_fn
mad_dump_switchinfo, mad_dump_perfcounters, mad_dump_perfcounters_ext,
mad_dump_perfcounters_xmt_sl, mad_dump_perfcounters_rcv_sl,
mad_dump_perfcounters_xmt_disc, mad_dump_perfcounters_rcv_err,
-mad_dump_portsamples_control;
+mad_dump_portsamples_control, mad_dump_port_ext_speeds_counters;
MAD_EXPORT void mad_dump_fields(char *buf, int bufsz, void *val, int valsz,
int start, int end);
diff --git a/src/dump.c b/src/dump.c
index 39e1bbf..4b4279d 100644
--- a/src/dump.c
+++ b/src/dump.c
@@ -831,6 +831,11 @@ void mad_dump_portsamples_control(char *buf, int bufsz,
void *val, int valsz)
_dump_fields(buf, bufsz, val, IB_PSC_OPCODE_F, IB_PSC_LAST_F);
}
+void mad_dump_port_ext_speeds_counters(char *buf, int bufsz, void *val, int
valsz)
+{
+ _dump_fields(buf, bufsz, val, IB_PESC_PORT_SELECT_F, IB_PESC_LAST_F);
+}
+
void xdump(FILE * file, char *msg, void *p, int size)
{
#define HEX(x) ((x) 10 ? '0' + (x) : 'a' + ((x) -10))
diff --git a/src/fields.c b/src/fields.c
index 92c1b6b..8039882 100644
--- a/src/fields.c
+++ b/src/fields.c
@@ -533,6 +533,51 @@ static const ib_field_t ib_mad_f[] = {
{BITSOFFS(507, 5), LinkSpeedExtEnabled, mad_dump_linkspeedexten},
{0, 0}, /* IB_PORT_LINK_SPEED_EXT_LAST_F */
+ /*
+* PortExtendedSpeedsCounters fields
+*/
+ {BITSOFFS(8, 8), PortSelect, mad_dump_uint},
+ {64, 64, CounterSelect, mad_dump_hex},
+ {BITSOFFS(128, 8), SyncHeaderErrorCounter, mad_dump_uint},
+ {BITSOFFS(136, 8), UnknownBlockCounter, mad_dump_uint},
+ {BITSOFFS(144, 8), ErrorDetectionCounterLane0, mad_dump_uint},
+ {BITSOFFS(152, 8), ErrorDetectionCounterLane1, mad_dump_uint},
+ {BITSOFFS(160, 8), ErrorDetectionCounterLane2, mad_dump_uint},
+ {BITSOFFS(168, 8), ErrorDetectionCounterLane3, mad_dump_uint},
+ {BITSOFFS(176, 8), ErrorDetectionCounterLane4, mad_dump_uint},
+ {BITSOFFS(184, 8), ErrorDetectionCounterLane5, mad_dump_uint},
+ {BITSOFFS(192, 8), ErrorDetectionCounterLane6, mad_dump_uint},
+ {BITSOFFS(200, 8), ErrorDetectionCounterLane7, mad_dump_uint},
+ {BITSOFFS(208, 8), ErrorDetectionCounterLane8, mad_dump_uint},
+ {BITSOFFS(216, 8), ErrorDetectionCounterLane9, mad_dump_uint},
+ {BITSOFFS(224, 8), ErrorDetectionCounterLane10, mad_dump_uint},
+ {BITSOFFS(232, 8), ErrorDetectionCounterLane11, mad_dump_uint},
Re: [PATCH] opensm: Add support for partition enforcement types
Hi Alex, On 7/10/2011 7:26 AM, Alex Netes wrote: Hi Hal, On 14:52 Tue 05 Jul , Hal Rosenstock wrote: Partition enforcement types are in, out, and both. Prior to this support, both was being used so that is the default. Signed-off-by: Hal Rosenstock h...@mellanox.com --- Now we end up with two parameters for same functionality: no_part_enforce - you define whether the enforcement is disabled or enabled. part_enforcement_type - you define enforcement type: in/out/both. When no_part_enforce is disabled, part_enforcement_type has no meaning. Yes. Don't you find it simpler if we had only one option for partition enforcement with 4 options: disabled/in/out/both(default)? I didn't want to break backward compatibility with existing command line or option file. If we were starting from scratch, it would be one option. -- Hal -- Alex -- 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 2/4] infiniband-diags: move core saquery functionality to ibdiag_common
On 7/8/2011 5:41 PM, Hal Rosenstock wrote:
On 7/5/2011 3:08 PM, Ira Weiny wrote:
While this is sub-optimal it is the easiest way to get saquery support to the
other diags.
Just some nits below...
Signed-off-by: Ira Weiny wei...@llnl.gov
---
include/ibdiag_common.h | 45 +++
src/ibdiag_common.c | 172
src/saquery.c | 198
++-
3 files changed, 224 insertions(+), 191 deletions(-)
diff --git a/include/ibdiag_common.h b/include/ibdiag_common.h
index b113cfe..69cddfb 100644
--- a/include/ibdiag_common.h
+++ b/include/ibdiag_common.h
Merge saquery.c copyrights into here...
@@ -81,4 +81,49 @@ extern int ibdiag_process_opts(int argc, char *const
argv[], void *context,
extern void ibdiag_show_usage();
extern void iberror(const char *fn, char *msg, ...);
+/* define an SA query structure to be common
+ * This is by no means optimal but it moves the saquery functionality out of
+ * the saquery tool and provides it to other utilities.
+ */
+struct bind_handle {
+int fd, agent;
+ib_portid_t dport;
+struct ibmad_port *srcport;
+};
+typedef struct bind_handle * bind_handle_t;
+bind_handle_t sa_get_bind_handle(void);
+void sa_free_bind_handle(bind_handle_t h);
+
+struct sa_query_result {
+uint32_t status;
+unsigned result_cnt;
+void *p_result_madw;
+};
+int sa_query(struct bind_handle *h, uint8_t method,
+ uint16_t attr, uint32_t mod, uint64_t comp_mask, uint64_t sm_key,
+ void *data, struct sa_query_result *result);
+void sa_free_result_mad(struct sa_query_result *result);
+void *sa_get_query_rec(void *mad, unsigned i);
+void sa_report_err(int status);
+
+#define cl_hton8(x) (x)
+#define CHECK_AND_SET_VAL(val, size, comp_with, target, name, mask) \
+if ((int##size##_t) val != (int##size##_t) comp_with) { \
+target = cl_hton##size((uint##size##_t) val); \
+comp_mask |= IB_##name##_COMPMASK_##mask; \
+}
+
+#define CHECK_AND_SET_GID(val, target, name, mask) \
+if (valid_gid((val))) { \
+memcpy((target), (val), sizeof(val)); \
+comp_mask |= IB_##name##_COMPMASK_##mask; \
+}
+
+#define CHECK_AND_SET_VAL_AND_SEL(val, target, name, mask, sel) \
+if (val) { \
+target = val; \
+comp_mask |= IB_##name##_COMPMASK_##mask##sel; \
+comp_mask |= IB_##name##_COMPMASK_##mask; \
+}
+
#endif /* _IBDIAG_COMMON_H_ */
diff --git a/src/ibdiag_common.c b/src/ibdiag_common.c
index 82f72af..6d03a43 100644
--- a/src/ibdiag_common.c
+++ b/src/ibdiag_common.c
Merge saquery.c copyrights into here...
@@ -337,3 +337,175 @@ void iberror(const char *fn, char *msg, ...)
exit(-1);
}
+
+/* define an SA query structure to be common
+ * This is by no means optimal but it moves the saquery functionality out of
+ * the saquery tool and provides it to other utilities.
+ */
+bind_handle_t sa_get_bind_handle(void)
+{
+struct ibmad_port * srcport;
+bind_handle_t handle;
+int mgmt_classes[2] = { IB_SMI_CLASS, IB_SMI_DIRECT_CLASS };
+
+srcport = mad_rpc_open_port(ibd_ca, ibd_ca_port, mgmt_classes, 2);
+if (!srcport) {
+IBWARN(Failed to open '%s' port '%d', ibd_ca, ibd_ca_port);
+return (NULL);
+}
+
+handle = calloc(1, sizeof(*handle));
+if (!handle)
+IBPANIC(calloc failed);
Should we IBPANIC in a library or IBWARN and return NULL here or some
other way to get the app to exit ?
IBPANIC is fine. I mistakenly thought this (ibdiag_common) was being
moved into a library.
+
+ib_resolve_smlid_via(handle-dport, ibd_timeout, srcport);
+if (!handle-dport.lid) {
+IBWARN(No SM found.);
+free(handle);
+return (NULL);
+}
+
+handle-dport.qp = 1;
+if (!handle-dport.qkey)
+handle-dport.qkey = IB_DEFAULT_QP1_QKEY;
+
+handle-srcport = srcport;
+handle-fd = mad_rpc_portid(srcport);
+handle-agent = umad_register(handle-fd, IB_SA_CLASS, 2, 1, NULL);
+
+return handle;
+}
+
+void sa_free_bind_handle(bind_handle_t h)
+{
+umad_unregister(h-fd, h-agent);
+mad_rpc_close_port(h-srcport);
+free(h);
+}
+
+int sa_query(bind_handle_t h, uint8_t method,
+uint16_t attr, uint32_t mod, uint64_t comp_mask,
+uint64_t sm_key, void *data, struct sa_query_result *result)
+{
+ib_rpc_t rpc;
+void *umad, *mad;
+int ret, offset, len = 256;
+
+memset(rpc, 0, sizeof(rpc));
+rpc.mgtclass = IB_SA_CLASS;
+rpc.method = method;
+rpc.attr.id = attr;
+rpc.attr.mod = mod;
+rpc.mask = comp_mask;
+rpc.datasz = IB_SA_DATA_SIZE;
+rpc.dataoffs = IB_SA_DATA_OFFS;
+
+umad = calloc(1, len + umad_size());
+if (!umad)
+
Re: install.pl chown issue (Was: Re: rhel6 ofed v1.5.3)
On Tue, Jul 5, 2011 at 6:36 PM, Ira Weiny wei...@llnl.gov wrote: On Fri, 1 Jul 2011 10:08:47 -0700 Michael Di Domenico mdidomeni...@gmail.com wrote: According to my installation of Ofed 1.5.3 on RHEL6, the infiniband-diags package rpm is trying to chown /usr/local in order to deposit a library in lib64. infiniband-diags does not do a chown. Sorry for the late reply, your reply got lost in my email bins... I should correct my statement, when RPM does the cpio extraction of the data that's what's reporting the error In my environment /usr/local is off-limits to root and all package installs. Is this a bug? Is there a workaround to allow the install.pl to complete? I just tried this on a vanilla Fedora 15 system and was able to build the source rpms just fine. Try building and installing in this order. libibumad-1.3.7-1.src.rpm libibmad-1.3.7-1.src.rpm opensm-3.3.9-1.src.rpm infiniband-diags-1.5.8-1.src.rpm these all build correctly using the install.pl file upto the infiniband-diags file then i get error: unpacking archive file on file /usr/local: cpio: Operation not supported -- 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: install.pl chown issue (Was: Re: rhel6 ofed v1.5.3)
On Mon, Jul 11, 2011 at 9:28 AM, Michael Di Domenico mdidomeni...@gmail.com wrote: On Tue, Jul 5, 2011 at 6:36 PM, Ira Weiny wei...@llnl.gov wrote: On Fri, 1 Jul 2011 10:08:47 -0700 Michael Di Domenico mdidomeni...@gmail.com wrote: According to my installation of Ofed 1.5.3 on RHEL6, the infiniband-diags package rpm is trying to chown /usr/local in order to deposit a library in lib64. infiniband-diags does not do a chown. Sorry for the late reply, your reply got lost in my email bins... I should correct my statement, when RPM does the cpio extraction of the data that's what's reporting the error In my environment /usr/local is off-limits to root and all package installs. Is this a bug? Is there a workaround to allow the install.pl to complete? I just tried this on a vanilla Fedora 15 system and was able to build the source rpms just fine. Try building and installing in this order. libibumad-1.3.7-1.src.rpm libibmad-1.3.7-1.src.rpm opensm-3.3.9-1.src.rpm infiniband-diags-1.5.8-1.src.rpm these all build correctly using the install.pl file upto the infiniband-diags file then i get error: unpacking archive file on file /usr/local: cpio: Operation not supported the file that seems to get included in the rpm is /usr/local/lib64/perl5/IBswcountlimits.pm i can't seem to locate where that's coming from though -- 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] drivers/infiniband/hw/qib/qib_iba7322: remove double define
Double define removed. Signed-off-by: Edwin van Vliet ed...@cheatah.nl --- drivers/infiniband/hw/qib/qib_iba7322.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) Thanks for the patch! Acked-by: Mike Marciniszyn mike.marcinis...@qlogic.com This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message. -- 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: install.pl chown issue (Was: Re: rhel6 ofed v1.5.3)
On Mon, Jul 11, 2011 at 9:43 AM, Michael Di Domenico mdidomeni...@gmail.com wrote: On Mon, Jul 11, 2011 at 9:28 AM, Michael Di Domenico mdidomeni...@gmail.com wrote: On Tue, Jul 5, 2011 at 6:36 PM, Ira Weiny wei...@llnl.gov wrote: On Fri, 1 Jul 2011 10:08:47 -0700 Michael Di Domenico mdidomeni...@gmail.com wrote: According to my installation of Ofed 1.5.3 on RHEL6, the infiniband-diags package rpm is trying to chown /usr/local in order to deposit a library in lib64. infiniband-diags does not do a chown. Sorry for the late reply, your reply got lost in my email bins... I should correct my statement, when RPM does the cpio extraction of the data that's what's reporting the error In my environment /usr/local is off-limits to root and all package installs. Is this a bug? Is there a workaround to allow the install.pl to complete? I just tried this on a vanilla Fedora 15 system and was able to build the source rpms just fine. Try building and installing in this order. libibumad-1.3.7-1.src.rpm libibmad-1.3.7-1.src.rpm opensm-3.3.9-1.src.rpm infiniband-diags-1.5.8-1.src.rpm these all build correctly using the install.pl file upto the infiniband-diags file then i get error: unpacking archive file on file /usr/local: cpio: Operation not supported the file that seems to get included in the rpm is /usr/local/lib64/perl5/IBswcountlimits.pm i can't seem to locate where that's coming from though Looks like the spec file pulls the installsitearch from the perl config. on redhat 5 there doesn't seem to be an installsitearch variable defined in the perl -V output, but on redhat 6 there is a -Dinstallsitearch=/usr/local/lib64 this is a redhat 6'ism, i did a fresh install of rhel6.0 to test whether it was something i messed up in the perl or not, but it wasn't me. i can likely work around the issue in the short term by recompiling the spec file by hand -- 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] opensm: make loopback console compile on by default.
On Jul 10, 2011, at 2:14 AM, Alex Netes wrote: Hi Ira, On 15:54 Wed 06 Jul , Ira Weiny wrote: The console is very useful for debugging and should be available in opensm.conf as an option. Generic socket is still an option which is off for security reasons. Signed-off-by: Ira Weiny wei...@llnl.gov --- I was digging a little in a history and one concern that was issued while socket support was introduced is that it requires libwrap devel package, so any one who lacks this package, opensm compilation will fail. My intention was to disable console_looback if libwrap was not available. But as I look at the configure.in I think there may be a bug in that logic. I don't have a system without libwrap readily available so give me some time to fix this. Ira -- Alex -- 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 v2] IB/CMA: Invalidate connections in port space IPoIB over Ethernet link layer
From: Moni Shoua mo...@mellanox.com This patch fixes a kernel crash in cma_set_qkey(). When link layer is ETHERNET it is wrong to use IPoIB port space since no IPoIB interface is available. Specifically, setting qkey when port space is RDMA_PS_IPOIB, requires mgid calculation and SA query which is illegal over Ethernet. Signed-off-by: Moni Shoua mo...@mellanox.co.il --- drivers/infiniband/core/cma.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c index b6a33b3..2d60130 100644 --- a/drivers/infiniband/core/cma.c +++ b/drivers/infiniband/core/cma.c @@ -359,6 +359,10 @@ static int cma_acquire_dev(struct rdma_id_private *id_priv) enum rdma_link_layer dev_ll = dev_addr-dev_type == ARPHRD_INFINIBAND ? IB_LINK_LAYER_INFINIBAND : IB_LINK_LAYER_ETHERNET; + if (dev_ll == IB_LINK_LAYER_ETHERNET + id_priv-id.ps == RDMA_PS_IPOIB) + return -EINVAL; + mutex_lock(lock); iboe_addr_get_sgid(dev_addr, iboe_gid); memcpy(gid, dev_addr-src_dev_addr + -- 1.7.4.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 0/3] opensm: fixing unused-but-set warnings in compilation
Latest GCC 4.6 include -Wunused-* flags as part of the -Wall flag, causing many warnings during OpenSM compilation. This patch series tries to clean these warnings. Where possible, unused variables were just deleted. In other cases where some variables are used only when specific compilation flags are used (DEBUG, VENDOR_RMPP_SUPPORT, etc') this variables marked as __attribute__((unused)) meaning that the variable is meant to be possibly unused. More info: http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Variable-Attributes.html#Variable-Attributes -- Alex -- 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 1/3] fixed unsused-but-set warning for DEBUG variables
Some variables are used only when compiling opensm with DEBUG flag.
In general compilation, this might produce unused-but-set warning.
Setting thais variables with __attribute__((unused)) removes this
warning.
Signed-off-by: Alex Netes ale...@mellanox.com
---
complib/cl_event_wheel.c |2 +-
complib/cl_map.c |8 +---
include/complib/cl_passivelock.h |6 +++---
include/vendor/osm_vendor_sa_api.h | 12 ++--
opensm/osm_ucast_lash.c|4 +---
5 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/complib/cl_event_wheel.c b/complib/cl_event_wheel.c
index eb894a6..2557c40 100644
--- a/complib/cl_event_wheel.c
+++ b/complib/cl_event_wheel.c
@@ -229,7 +229,7 @@ cl_status_t cl_event_wheel_init_ex(IN cl_event_wheel_t *
const p_event_wheel,
void cl_event_wheel_dump(IN cl_event_wheel_t * const p_event_wheel)
{
cl_list_item_t *p_list_item;
- cl_event_wheel_reg_info_t *p_event;
+ cl_event_wheel_reg_info_t __attribute__((__unused__)) *p_event;
p_list_item = cl_qlist_head(p_event_wheel-events_wheel);
diff --git a/complib/cl_map.c b/complib/cl_map.c
index f5fb1f3..81426ee 100644
--- a/complib/cl_map.c
+++ b/complib/cl_map.c
@@ -626,7 +626,8 @@ static void __cl_qmap_delta_move(IN OUT cl_qmap_t * const
p_dest,
IN OUT cl_qmap_t * const p_src,
IN OUT cl_map_item_t ** const pp_item)
{
- cl_map_item_t *p_temp, *p_next;
+ cl_map_item_t __attribute__((__unused__)) *p_temp;
+ cl_map_item_t *p_next;
/*
* Get the next item so that we can ensure that pp_item points to
@@ -870,7 +871,7 @@ static void __cl_map_revert(IN OUT cl_map_t * const p_map1,
IN OUT cl_map_t * const p_new,
IN OUT cl_map_t * const p_old)
{
- cl_status_t status;
+ cl_status_t __attribute__((__unused__)) status;
/* Restore the initial state. */
status = cl_map_merge(p_map1, p_old);
@@ -1562,7 +1563,8 @@ static void __cl_fmap_delta_move(IN OUT cl_fmap_t * const
p_dest,
IN OUT cl_fmap_t * const p_src,
IN OUT cl_fmap_item_t ** const pp_item)
{
- cl_fmap_item_t *p_temp, *p_next;
+ cl_fmap_item_t __attribute__((__unused__)) *p_temp;
+ cl_fmap_item_t *p_next;
/*
* Get the next item so that we can ensure that pp_item points to
diff --git a/include/complib/cl_passivelock.h b/include/complib/cl_passivelock.h
index aea3bab..0fad6ef 100644
--- a/include/complib/cl_passivelock.h
+++ b/include/complib/cl_passivelock.h
@@ -234,7 +234,7 @@ static inline cl_status_t cl_plock_init(IN cl_plock_t *
const p_lock)
*/
static inline void cl_plock_acquire(IN cl_plock_t * const p_lock)
{
- cl_status_t status;
+ cl_status_t __attribute__((unused)) status;
CL_ASSERT(p_lock);
CL_ASSERT(p_lock-state == CL_INITIALIZED);
@@ -266,7 +266,7 @@ static inline void cl_plock_acquire(IN cl_plock_t * const
p_lock)
*/
static inline void cl_plock_excl_acquire(IN cl_plock_t * const p_lock)
{
- cl_status_t status;
+ cl_status_t __attribute__((unused)) status;
CL_ASSERT(p_lock);
CL_ASSERT(p_lock-state == CL_INITIALIZED);
@@ -299,7 +299,7 @@ static inline void cl_plock_excl_acquire(IN cl_plock_t *
const p_lock)
*/
static inline void cl_plock_release(IN cl_plock_t * const p_lock)
{
- cl_status_t status;
+ cl_status_t __attribute__((unused)) status;
CL_ASSERT(p_lock);
CL_ASSERT(p_lock-state == CL_INITIALIZED);
diff --git a/include/vendor/osm_vendor_sa_api.h
b/include/vendor/osm_vendor_sa_api.h
index dd37c3a..653d847 100644
--- a/include/vendor/osm_vendor_sa_api.h
+++ b/include/vendor/osm_vendor_sa_api.h
@@ -448,7 +448,7 @@ static inline ib_path_rec_t *osmv_get_query_path_rec(IN
osm_madw_t *
p_result_madw,
IN uint32_t result_index)
{
- ib_sa_mad_t *p_sa_mad;
+ ib_sa_mad_t __attribute__((__unused__)) *p_sa_mad;
CL_ASSERT(p_result_madw);
p_sa_mad = (ib_sa_mad_t *) osm_madw_get_mad_ptr(p_result_madw);
@@ -490,7 +490,7 @@ static inline ib_portinfo_record_t
*osmv_get_query_portinfo_rec(IN osm_madw_t *
IN uint32_t
result_index)
{
- ib_sa_mad_t *p_sa_mad;
+ ib_sa_mad_t __attribute__((__unused__)) *p_sa_mad;
CL_ASSERT(p_result_madw);
p_sa_mad = (ib_sa_mad_t *) osm_madw_get_mad_ptr(p_result_madw);
@@ -532,7 +532,7 @@ static inline ib_node_record_t *osmv_get_query_node_rec(IN
osm_madw_t *
IN uint32_t
result_index)
[PATCH 2/3] libvendor/osm_vendor_ibumad.c: fix unused-but-set warning
is_rmpp might be set but unused when VENDOR_RMPP_SUPPORT is TRUE. Mark this variable as __attribute__((unused)) to remove this warning. Signed-off-by: Alex Netes ale...@mellanox.com --- libvendor/osm_vendor_ibumad.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/libvendor/osm_vendor_ibumad.c b/libvendor/osm_vendor_ibumad.c index 5cd6f46..e2ebd8e 100644 --- a/libvendor/osm_vendor_ibumad.c +++ b/libvendor/osm_vendor_ibumad.c @@ -1002,7 +1002,7 @@ osm_vendor_send(IN osm_bind_handle_t h_bind, ib_mad_t *const p_mad = osm_madw_get_mad_ptr(p_madw); ib_sa_mad_t *const p_sa = (ib_sa_mad_t *) p_mad; int ret = -1; - int is_rmpp = 0; + int __attribute__((__unused__)) is_rmpp = 0; uint32_t sent_mad_size; uint64_t tid; #ifndef VENDOR_RMPP_SUPPORT -- 1.7.6 -- 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 3/3] Remove unused variables from code
Unused variables may cause unused-but-set warning
Signed-off-by: Alex Netes ale...@mellanox.com
---
opensm/osm_inform.c |2 --
opensm/osm_lid_mgr.c|5 +++--
opensm/osm_mesh.c |2 --
opensm/osm_sa.c |3 +--
opensm/osm_sa_informinfo.c |2 --
opensm/osm_sa_link_record.c |4 ++--
opensm/osm_sa_mcmember_record.c |3 ---
opensm/osm_sa_pkey_record.c |2 --
opensm/osm_sa_portinfo_record.c |3 ---
opensm/osm_sa_service_record.c |3 ---
opensm/osm_sa_slvl_record.c |2 --
opensm/osm_sa_vlarb_record.c|2 --
opensm/osm_torus.c |4 +---
opensm/osm_ucast_file.c |2 --
osmtest/osmt_slvl_vl_arb.c | 32
15 files changed, 23 insertions(+), 48 deletions(-)
diff --git a/opensm/osm_inform.c b/opensm/osm_inform.c
index 8af8616..fd7caa2 100644
--- a/opensm/osm_inform.c
+++ b/opensm/osm_inform.c
@@ -451,7 +451,6 @@ static void match_notice_to_inf_rec(IN cl_list_item_t *
p_list_item,
ib_mad_notice_attr_t *p_ntc = p_infr_match-p_ntc;
osm_infr_t *p_infr_rec = (osm_infr_t *) p_list_item;
ib_inform_info_t *p_ii = (p_infr_rec-inform_record.inform_info);
- cl_status_t status = CL_NOT_FOUND;
osm_log_t *p_log = p_infr_rec-sa-p_log;
OSM_LOG_ENTER(p_log);
@@ -559,7 +558,6 @@ static void match_notice_to_inf_rec(IN cl_list_item_t *
p_list_item,
/* send the report to the address provided in the inform record */
OSM_LOG(p_log, OSM_LOG_DEBUG, MATCH! Sending Report...\n);
send_report(p_infr_rec, p_ntc);
- status = CL_SUCCESS;
Exit:
OSM_LOG_EXIT(p_log);
diff --git a/opensm/osm_lid_mgr.c b/opensm/osm_lid_mgr.c
index 5d0247a..015e65a 100644
--- a/opensm/osm_lid_mgr.c
+++ b/opensm/osm_lid_mgr.c
@@ -1183,8 +1183,9 @@ int osm_lid_mgr_process_subnet(IN osm_lid_mgr_t * p_mgr)
to look for any field change and will only send an updated
if required */
OSM_LOG(p_mgr-p_log, OSM_LOG_VERBOSE,
- Assigned port 0x%016 PRIx64 , LID [%u,%u]\n,
- cl_ntoh64(port_guid), min_lid_ho, max_lid_ho);
+ Assigned port 0x%016 PRIx64 , %s LID [%u,%u]\n,
+ cl_ntoh64(port_guid), lid_changed ? new : ,
+ min_lid_ho, max_lid_ho);
/* the proc returns the fact it sent a set port info */
if (lid_mgr_set_physp_pi(p_mgr, p_port, p_port-p_physp,
diff --git a/opensm/osm_mesh.c b/opensm/osm_mesh.c
index d156b7a..aa9b682 100644
--- a/opensm/osm_mesh.c
+++ b/opensm/osm_mesh.c
@@ -1634,7 +1634,6 @@ int osm_do_mesh_analysis(lash_t *p_lash)
{
osm_log_t *p_log = p_lash-p_osm-log;
mesh_t *mesh;
- int max_class = -1;
int max_class_num = 0;
int max_class_type = -1;
int i;
@@ -1667,7 +1666,6 @@ int osm_do_mesh_analysis(lash_t *p_lash)
i, mesh-class_count[i],
p_lash-switches[mesh-class_type[i]]-node-type);
if (mesh-class_count[i] max_class_num) {
- max_class = i;
max_class_num = mesh-class_count[i];
max_class_type = mesh-class_type[i];
}
diff --git a/opensm/osm_sa.c b/opensm/osm_sa.c
index bbd1a56..cdb8999 100644
--- a/opensm/osm_sa.c
+++ b/opensm/osm_sa.c
@@ -101,13 +101,12 @@ void osm_sa_construct(IN osm_sa_t * p_sa)
void osm_sa_shutdown(IN osm_sa_t * p_sa)
{
- ib_api_status_t status;
OSM_LOG_ENTER(p_sa-p_log);
cl_timer_stop(p_sa-sr_timer);
/* unbind from the mad service */
- status = osm_sa_mad_ctrl_unbind(p_sa-mad_ctrl);
+ osm_sa_mad_ctrl_unbind(p_sa-mad_ctrl);
/* remove any registered dispatcher message */
cl_disp_unregister(p_sa-nr_disp_h);
diff --git a/opensm/osm_sa_informinfo.c b/opensm/osm_sa_informinfo.c
index be7aba7..f775d36 100644
--- a/opensm/osm_sa_informinfo.c
+++ b/opensm/osm_sa_informinfo.c
@@ -235,7 +235,6 @@ static void sa_inform_info_rec_by_comp_mask(IN osm_sa_t *
sa,
IN const osm_infr_t * p_infr,
osm_iir_search_ctxt_t * p_ctxt)
{
- const ib_inform_info_record_t *p_rcvd_rec = NULL;
ib_net64_t comp_mask;
ib_net64_t portguid;
osm_port_t *p_subscriber_port;
@@ -245,7 +244,6 @@ static void sa_inform_info_rec_by_comp_mask(IN osm_sa_t *
sa,
OSM_LOG_ENTER(sa-p_log);
- p_rcvd_rec = p_ctxt-p_rcvd_rec;
comp_mask = p_ctxt-comp_mask;
p_req_physp = p_ctxt-p_req_physp;
diff --git a/opensm/osm_sa_link_record.c b/opensm/osm_sa_link_record.c
index 5b97b90..8ac4962 100644
--- a/opensm/osm_sa_link_record.c
+++ b/opensm/osm_sa_link_record.c
@@ -370,7 +370,7 @@ static ib_net16_t lr_rcv_get_end_points(IN osm_sa_t
Re: [PATCH 3/4] infiniband-diags: properly resolve node guids
Ira, On 7/8/2011 6:29 PM, Ira Weiny wrote: On Fri, 8 Jul 2011 14:59:01 -0700 Hal Rosenstock h...@dev.mellanox.co.il wrote: On 7/8/2011 5:50 PM, Jason Gunthorpe wrote: On Fri, Jul 08, 2011 at 05:42:38PM -0400, Hal Rosenstock wrote: Should the request just be a GET rather than GET_TABLE and avoid this check ? I don't think multiple nodes can register with same Node GUID, can they ? Also, I think it makes eliminates this check and the missing 0 check. Multiport HCAs should (and do..) show up with multiple node records. There is one node record per end port, not per node. This is why using node GUID as an end port identifier is a bad choice. It is _not_ a bad choice if you are looking for a node. One could also equally well query for the node records to which a port GUID belongs if this is better to keep the guid meaning consistent. Looking at the current man pages though, ibqueryerrors does say node GUID and iblinkinfo says switch GUID which is the node GUID. -- Hal Before this patch, it did used to use the port GUID for this. The point of this patch is to do the right thing when the user is requesting a node they want information about. The next step is to accept NodeDescription and use that from the NodeRecord as a key. However, you could use GET and look at the return code to disambiguate no records/one record/many records. Yes, that was getting at (and that there was no check for no records returned with the get table code). Ok, that is a bug. We should check for no records. As for multiple records, I left that for a future patch which would query all of those ports. Ira -- Hal Jason -- 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 3/4] infiniband-diags: properly resolve node guids
On Fri, 8 Jul 2011 15:55:10 -0700 Jason Gunthorpe jguntho...@obsidianresearch.com wrote: On Fri, Jul 08, 2011 at 03:29:53PM -0700, Ira Weiny wrote: On Fri, 8 Jul 2011 14:59:01 -0700 Hal Rosenstock h...@dev.mellanox.co.il wrote: On 7/8/2011 5:50 PM, Jason Gunthorpe wrote: On Fri, Jul 08, 2011 at 05:42:38PM -0400, Hal Rosenstock wrote: Should the request just be a GET rather than GET_TABLE and avoid this check ? I don't think multiple nodes can register with same Node GUID, can they ? Also, I think it makes eliminates this check and the missing 0 check. Multiport HCAs should (and do..) show up with multiple node records. There is one node record per end port, not per node. This is why using node GUID as an end port identifier is a bad choice. It is _not_ a bad choice if you are looking for a node. But very few diags seem to be designed around the idea that they will operate on a bundle of end ports (eg a node), they tend to be one end port only, so asking for a node is nonsense. Why do you object to tools which report information for an entire node? Nodes, specifically switches, are much more manageable chunks than an entire fabric. What does it mean? Operate on a random end port of that node? For some queries, like NodeInfo, yes that is all we need. All end ports? Yes, why not? While this particular patch only supports the fist port found. That will support 90% of the fabrics out there which have a single port of an HCA connected to a fabric. That is why I added the warning message indicating there was a problem, as well as responding to Hal that further work would be required. Just fail with error? Only if you can't resolve what the user is looking for. I don't like this trend to make node GUID the default GUID input format for diags. FWIW, ibtool consistently uses port GUID as the default GUID type for all end port specifications. I am not proposing this for all tools. Why shouldn't a user be able to query more than a single port at a time in some higher level tools? Also how would you propose to resolve a query via NodeDescription? Put yourself in the shoes of the administrator who is trying to manage 1000's of nodes in a system. Names are much easier to deal with than GUID's and LID's. Before this patch, it did used to use the port GUID for this. The point of this patch is to do the right thing when the user is requesting a node they want information about. The next step is to accept NodeDescription and use that from the NodeRecord as a key. Well, it looks like this is a bug fix for both iblinkinfo and ibqueryerrors, eg they seem to be documented to accept node GUIDs but were treating them as port GUIDs in one place and node GUIDs in another. Yes this was based on the assumption that PortGUID of [E]SP0 == node GUID, which AFAIK works on all current switches, but is wrong. This was ok when iblinkinfo and ibqueryerrors only supported switches. I wanted to expand them. Though please update the -S section of the man page for iblinkinfo to reflect the GUID is a node GUID.. This was included as part of the next patch 3/4 infiniband-diags: libibnetdisc/iblinkinfo Allow for a partial fabric query centered around a CA Ira Jason -- 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 -- Ira Weiny Math Programmer/Computer Scientist 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
Re: [PATCH 3/4] infiniband-diags: properly resolve node guids
On Mon, Jul 11, 2011 at 02:06:02PM -0700, Ira Weiny wrote: But very few diags seem to be designed around the idea that they will operate on a bundle of end ports (eg a node), they tend to be one end port only, so asking for a node is nonsense. Why do you object to tools which report information for an entire node? Nodes, specifically switches, are much more manageable chunks than an entire fabric. I don't object to that, I'm just pointing out that most of the tools aren't like that today, and many don't have a clear way to format their output in a multi-end-port format. And, I don't think there is anything wrong with reporting a whole switch node either - but the portGUID should be identifier, not the node GUID. I don't like this trend to make node GUID the default GUID input format for diags. FWIW, ibtool consistently uses port GUID as the default GUID type for all end port specifications. I am not proposing this for all tools. Why shouldn't a user be able to query more than a single port at a time in some higher level tools? I'd much rather see only portGUID used as an argument and a --all-ports option that would report all HCA ports - by automatically doing the necessary SA operations to find them. This is much better than having to force an admin to use port GUIDs in some tools and node GUID in (very few) other tools. Ie, admins should never need to know what the node GUID is, and they certainly should not be required to keep track of both a port GUID and a node GUID for every CA just to use one tool or another. Also how would you propose to resolve a query via NodeDescription? Put yourself in the shoes of the administrator who is trying to manage 1000's of nodes in a system. Names are much easier to deal with than GUID's and LID's. I've no objection to searching by node description, as long as the tool supports a multiple end port output format. Don't see what this has to do with node GUID support :) Jason -- 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 v2] IB/CMA: Invalidate connections in port space IPoIB over Ethernet link layer
diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c index b6a33b3..2d60130 100644 --- a/drivers/infiniband/core/cma.c +++ b/drivers/infiniband/core/cma.c @@ -359,6 +359,10 @@ static int cma_acquire_dev(struct rdma_id_private *id_priv) enum rdma_link_layer dev_ll = dev_addr-dev_type == ARPHRD_INFINIBAND ? IB_LINK_LAYER_INFINIBAND : IB_LINK_LAYER_ETHERNET; + if (dev_ll == IB_LINK_LAYER_ETHERNET + id_priv-id.ps == RDMA_PS_IPOIB) + return -EINVAL; thanks - one nit - can you change the first part to dev_ll != IB_LINK_LAYER_INFINIBAND? Just in case we ever add a new link type, we don't need to change the check. - 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
