Re: [PATCH] opensm/osm_ucast_ftree.c: Handle [sw hca]_create failures
On 20:40 Thu 02 Jun , Hal Rosenstock wrote: Signed-off-by: Hal Rosenstock h...@mellanox.com --- Applied, thanks. -- 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/osm_switch.c: In switch_find_guid_common, handle NULL parameter
On 20:40 Thu 02 Jun , Hal Rosenstock wrote: Since port-priv can be NULL, struct osm_remote_guids_count * supplied can be NULL so handle this. Signed-off-by: Hal Rosenstock h...@mellanox.com --- Applied, thanks. -- 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/libvendor: Fix compile warnings on 64 bit machines when building --with-osmv=sim
On 15:03 Thu 02 Jun , Hal Rosenstock wrote: osm_vendor_mlx.c: In function '__osmv_get_send_txn': osm_vendor_mlx.c:708: warning: format '%llX' expects type 'long long unsigned int', but argument 4 has type 'uint64_t' osm_vendor_mlx.c:723: warning: format '%llX' expects type 'long long unsigned int', but argument 4 has type 'uint64_t' osm_vendor_mlx.c:733: warning: format '%llX' expects type 'long long unsigned int', but argument 4 has type 'uint64_t' osm_vendor_mlx.c:746: warning: format '%llX' expects type 'long long unsigned int', but argument 4 has type 'uint64_t' osm_vendor_mlx_hca_sim.c: In function '__parse_ca_info_file': osm_vendor_mlx_hca_sim.c:268: warning: format '%016llx' expects type 'long long unsigned int', but argument 5 has type 'uint64_t' osm_vendor_mlx_dispatcher.c: In function '__osmv_dispatch_route': osm_vendor_mlx_dispatcher.c:208: warning: format '%llX' expects type 'long long unsigned int', but argument 4 has type 'uint64_t' osm_vendor_mlx_dispatcher.c:221: warning: format '%llX' expects type 'long long unsigned int', but argument 4 has type 'uint64_t' osm_vendor_mlx_dispatcher.c: In function '__osmv_dispatch_simple_mad': osm_vendor_mlx_dispatcher.c:276: warning: format '%llX' expects type 'long long unsigned int', but argument 4 has type 'long unsigned int' osm_vendor_mlx_dispatcher.c: In function '__osmv_dispatch_rmpp_mad': osm_vendor_mlx_dispatcher.c:331: warning: format '%llX' expects type 'long long unsigned int', but argument 4 has type 'uint64_t' osm_vendor_mlx_dispatcher.c: In function '__osmv_dispatch_rmpp_rcv': osm_vendor_mlx_dispatcher.c:570: warning: format '%llX' expects type 'long long unsigned int', but argument 4 has type 'uint64_t' osm_vendor_mlx_dispatcher.c:624: warning: format '%llX' expects type 'long long unsigned int', but argument 5 has type 'uint64_t' osm_vendor_mlx_dispatcher.c:629: warning: format '%llX' expects type 'long long unsigned int', but argument 4 has type 'long unsigned int' osm_vendor_mlx_dispatcher.c: In function '__osmv_dispatch_accept_seg': osm_vendor_mlx_dispatcher.c:661: warning: format '%llX' expects type 'long long unsigned int', but argument 4 has type 'uint64_t' osm_vendor_mlx_dispatcher.c:674: warning: format '%llX' expects type 'long long unsigned int', but argument 4 has type 'uint64_t' osm_vendor_mlx_sender.c: In function '__osmv_rmpp_send_segment': osm_vendor_mlx_sender.c:345: warning: format '%llX' expects type 'long long unsigned int', but argument 5 has type 'ib_net64_t' Signed-off-by: Hal Rosenstock h...@mellanox.com --- Applied, thanks -- 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/2] opensm: use OSM_LOG_INFO on duplicate torus port order parsing
On 16:33 Wed 01 Jun , Jim Schutt wrote: Since it doesn't cause OpenSM to exit, it isn't an error. We just want to give the admin information that will allow them to clean up their configuration. Signed-off-by: Jim Schutt jasc...@sandia.gov --- Applied, thanks. -- 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 1/2] opensm: fail if configured torus port order references a port not available in all switches
On 16:33 Wed 01 Jun , Jim Schutt wrote: Signed-off-by: Jim Schutt jasc...@sandia.gov --- Applied, thanks. -- 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: [RFC] [PATCH 1/2] libibverbs: Allow 3rd party extensions to verb routines
I'm not quite sure I understand the use for enum ibv_extension_type.
Where/how is this used?
Ira
On Jun 3, 2011, at 5:34 PM, Hefty, Sean wrote:
In order to support OFED or vendor specific calls, define a
generic extension mechanism. This allows OFED, an RDMA vendor,
or another registered 3rd party (for example, the librdmacm)
to define RDMA extensions.
Users which make use extensions are aware that they are not
only using an extended call, but are given information regarding
how widely the extension by be supported. Support for extended
functions, data structures, and enums are defined.
Extensions are referenced by name. There is an assumption that
extension names are prefixed relative to the supporting party.
Until an extension has been incorporated into libibverbs, it
should be defined in an appropriate external header file.
For example, OFA could provide a header file with their definition
for XRC extensions. A partial view of such a header file might
look something similar to:
#ifndef OFA_XRC_H
#define OFA_XRC_H
#include infiniband/verbs.h
#define OFA_XRC_OPS ofa-xrc
/* Extend IBV_QP_TYPE for XRC */
#define OFA_QPT_XRC ((enum ibv_qp_type) \
(IBV_EXTENSION_OFA IBV_EXTENSION_BASE_SHIFT) + 6)
struct ofa_xrcd {
struct ibv_context *context;
};
struct ofa_xrc_ops {
struct ofa_xrcd * (*open_xrcd)(struct ibv_context *context,
inf fd, int oflags);
int * (*close_xrcd)(struct ofa_xrcd *xrcd);
/* other functions left as exercise to the reader */
};
#endif /* OFA_XRC_H */
Driver libraries that support extensions are given a new
registration call, ibv_register_device_ext(). Use of this call
indicates to libibverbs that the library allocates extended
versions of struct ibv_device and struct ibv_context.
The following new APIs are added to libibverbs to applications
to use to determine if an extension is supported and to obtain the
extended function calls.
ibv_have_ext_ops - returns true if an extension is supported
ibv_get_device_ext_ops - return extended operations for a device
ibv_get_ext_ops - return extended operations for an open context
To maintain backwards compatibility with existing applications,
internally, the library uses the last byte of the device name
to record if the device was registered with extension support.
Signed-off-by: Sean Hefty sean.he...@intel.com
---
Compile tested only at this point. I'm still working on writing
an XRC sample program.
include/infiniband/driver.h |1 +
include/infiniband/verbs.h | 40 +++-
src/device.c| 18 ++
src/ibverbs.h | 18 ++
src/init.c | 17 -
src/libibverbs.map |5 +
src/verbs.c |9 +
7 files changed, 106 insertions(+), 2 deletions(-)
diff --git a/include/infiniband/driver.h b/include/infiniband/driver.h
index 9a81416..e48abfd 100644
--- a/include/infiniband/driver.h
+++ b/include/infiniband/driver.h
@@ -57,6 +57,7 @@ typedef struct ibv_device *(*ibv_driver_init_func)(const
char *uverbs_sys_path,
int abi_version);
void ibv_register_driver(const char *name, ibv_driver_init_func init_func);
+void ibv_register_driver_ext(const char *name, ibv_driver_init_func
init_func);
int ibv_cmd_get_context(struct ibv_context *context, struct ibv_get_context
*cmd,
size_t cmd_size, struct ibv_get_context_resp *resp,
size_t resp_size);
diff --git a/include/infiniband/verbs.h b/include/infiniband/verbs.h
index 0f1cb2e..b82cd3a 100644
--- a/include/infiniband/verbs.h
+++ b/include/infiniband/verbs.h
@@ -55,6 +55,15 @@
BEGIN_C_DECLS
+enum ibv_extension_type {
+ IBV_EXTENSION_COMMON,
+ IBV_EXTENSION_VENDOR,
+ IBV_EXTENSION_OFA,
+ IBV_EXTENSION_RDMA_CM
+};
+#define IBV_EXTENSION_BASE_SHIFT 24
+#define IBV_EXTENSION_MASK 0xFF00
+
union ibv_gid {
uint8_t raw[16];
struct {
@@ -92,7 +101,8 @@ enum ibv_device_cap_flags {
IBV_DEVICE_SYS_IMAGE_GUID = 1 11,
IBV_DEVICE_RC_RNR_NAK_GEN = 1 12,
IBV_DEVICE_SRQ_RESIZE = 1 13,
- IBV_DEVICE_N_NOTIFY_CQ = 1 14
+ IBV_DEVICE_N_NOTIFY_CQ = 1 14,
+ IBV_DEVICE_EXTENSIONS = 1 (IBV_EXTENSION_BASE_SHIFT - 1)
};
enum ibv_atomic_cap {
@@ -623,6 +633,13 @@ struct ibv_device {
chardev_path[IBV_SYSFS_PATH_MAX];
/* Path to infiniband class device in sysfs */
charibdev_path[IBV_SYSFS_PATH_MAX];
+
+ /* Following fields only available if device supports extensions */
+ void *private;
+ int (*have_ext_ops)(struct ibv_device
