Skip to contentSkip to conversation

libibumad: Provide MAD definitions with libibumad

PATCH In review [email protected] 3 participants 22 messages Jan 28, 2013 – Feb 21, 2013 13 messages not in the archive

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/7 libibumad: Provide MAD definitions with libibumad

From: Sean Hefty <[email protected]>

The only definitions for MAD data types are in ib_types.h, which is an opensm file. The libibumad interface is essentially useless without these data types. Add new header files to libibumad with basic MAD data types.

The definitions and structures are based on those defined in the linux kernel. Only an initial framework is given, basically the values for various methods, attributes, etc. along with structure definitions for the common, rmpp, and vendor specific headers. Other data structures are left for future development.

---
 include/infiniband/umad_types.h |  192 +++++++++++++++++++++++++++++++++++++++
 1 files changed, 192 insertions(+), 0 deletions(-)
 create mode 100755 include/infiniband/umad_types.h
include/infiniband/umad_types.h new file +192 -0
new file mode 100755
index 0000000..54b7e72
@@ -0,0 +1,192 @@
+/*
+ * Copyright (c) 2004 Mellanox Technologies Ltd.  All rights reserved.
+ * Copyright (c) 2004 Infinicon Corporation.  All rights reserved.
+ * Copyright (c) 2004, 2010 Intel Corporation.  All rights reserved.
+ * Copyright (c) 2004 Topspin Corporation.  All rights reserved.
+ * Copyright (c) 2004-2006 Voltaire Corporation.  All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ *     Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *      - Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *
+ *      - Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ *
+ */
+#ifndef _UMAD_TYPES_H
+#define _UMAD_TYPES_H
+
+#include <stdint.h>
+
+#ifdef __cplusplus
+#  define BEGIN_C_DECLS extern "C" {
+#  define END_C_DECLS   }
+#else				/* !__cplusplus */
+#  define BEGIN_C_DECLS
+#  define END_C_DECLS
+#endif				/* __cplusplus */
+
+BEGIN_C_DECLS
+
+#define UMAD_BASE_VERSION		1
+
+/* Management classes */
+enum {
+	UMAD_CLASS_SUBN_LID_ROUTED	= 0x01,
+	UMAD_CLASS_SUBN_DIRECTED_ROUTE	= 0x81,
+	UMAD_CLASS_SUBN_ADM		= 0x03,
+	UMAD_CLASS_PERF_MGMT		= 0x04,
+	UMAD_CLASS_BM			= 0x05,
+	UMAD_CLASS_DEVICE_MGMT		= 0x06,
+	UMAD_CLASS_CM			= 0x07,
+	UMAD_CLASS_SNMP			= 0x08,
+	UMAD_CLASS_VENDOR_RANGE1_START	= 0x09,
+	UMAD_CLASS_VENDOR_RANGE1_END	= 0x0F,
+	UMAD_CLASS_DEVICE_ADM		= 0x10,
+	UMAD_CLASS_BOOT_MGMT		= 0x11,
+	UMAD_CLASS_BIS			= 0x12,
+	UMAD_CLASS_CONG_MGMT		= 0x21,
+	UMAD_CLASS_VENDOR_RANGE2_START	= 0x30,
+	UMAD_CLASS_VENDOR_RANGE2_END	= 0x4F
+};
+
+/* Management methods */
+enum {
+	UMAD_METHOD_GET			= 0x01,
+	UMAD_METHOD_SET			= 0x02,
+	UMAD_METHOD_GET_RESP		= 0x81,
+	UMAD_METHOD_SEND		= 0x03,
+	UMAD_METHOD_TRAP		= 0x05,
+	UMAD_METHOD_REPORT		= 0x06,
+	UMAD_METHOD_REPORT_RESP		= 0x86,
+	UMAD_METHOD_TRAP_REPRESS	= 0x07,
+	UMAD_METHOD_RESP		= 0x80
+};
+
+enum {
+	UMAD_STATUS_SUCCESS  = 0x0000,
+	UMAD_STATUS_BUSY     = 0x0001,
+	UMAD_STATUS_REDIRECT = 0x0002,
+
+	/* Invalid fields, bits 2-4 */
+	UMAD_STATUS_BAD_VERSION          = (1 << 2),
+	UMAD_STATUS_METHOD_NOT_SUPPORTED = (2 << 2),
+	UMAD_STATUS_ATTR_NOT_SUPPORTED   = (3 << 2),
+	UMAD_STATUS_INVALID_ATTR_VALUE   = (7 << 2),
+
+	UMAD_STATUS_CLASS_MASK = 0xFF00
+};
+
+/* Attributes common to multiple classes */
+enum {
+	UMAD_ATTR_CLASS_PORT_INFO	= 0x0001,
+	UMAD_ATTR_NOTICE		= 0x0002,
+	UMAD_ATTR_INFORM_INFO		= 0x0003
+};
+
+/* RMPP information */
+#define UMAD_RMPP_VERSION		1
+enum {
+	UMAD_RMPP_TYPE_DATA		= 1,
+	UMAD_RMPP_TYPE_ACK		= 2,
+	UMAD_RMPP_TYPE_STOP		= 3,
+	UMAD_RMPP_TYPE_ABORT		= 4,
+
+	UMAD_RMPP_FLAG_MASK		= 0x07,
+	UMAD_RMPP_FLAG_ACTIVE		= 1,
+	UMAD_RMPP_FLAG_FIRST		= (1 << 1),
+	UMAD_RMPP_FLAG_LAST		= (1 << 2),
+
+	UMAD_RMPP_RESP_TIME_SHIFT	= 3,
+	UMAD_RMPP_NO_RESP_TIME		= 0x1F,
+
+	UMAD_RMPP_STATUS_SUCCESS	= 0,
+	UMAD_RMPP_STATUS_RESX		= 1,
+	UMAD_RMPP_STATUS_ABORT_MIN	= 118,
+	UMAD_RMPP_STATUS_T2L		= 118,
+	UMAD_RMPP_STATUS_BAD_LEN	= 119,
+	UMAD_RMPP_STATUS_BAD_SEG	= 120,
+	UMAD_RMPP_STATUS_BADT		= 121,
+	UMAD_RMPP_STATUS_W2S		= 122,
+	UMAD_RMPP_STATUS_S2B		= 123,
+	UMAD_RMPP_STATUS_BAD_STATUS	= 124,
+	UMAD_RMPP_STATUS_UNV		= 125,
+	UMAD_RMPP_STATUS_TMR		= 126,
+	UMAD_RMPP_STATUS_UNSPEC		= 127,
+	UMAD_RMPP_STATUS_ABORT_MAX	= 127
+};
+
+enum {
+	UMAD_LEN_DATA			= 232,
+	UMAD_LEN_RMPP_DATA		= 220,
+	UMAD_LEN_VENDOR_DATA		= 216,
+};
+
+struct umad_hdr {
+	uint8_t	 base_version;
+	uint8_t	 mgmt_class;
+	uint8_t	 class_version;
+	uint8_t	 method;
+	uint16_t status;
+	uint16_t class_specific;
+	uint64_t tid;
+	uint16_t attr_id;
+	uint16_t resv;
+	uint32_t attr_mod;
+};
+
+struct umad_rmpp_hdr {
+	uint8_t	 rmpp_version;
+	uint8_t	 rmpp_type;
+	uint8_t	 rmpp_rtime_flags;
+	uint8_t	 rmpp_status;
+	uint32_t seg_num;
+	uint32_t paylen_newwin;
+};
+
+struct umad_packet {
+	struct umad_hdr		mad_hdr;
+	uint8_t			data[UMAD_LEN_DATA];
+};
+
+struct umad_rmpp_packet {
+	struct umad_hdr		mad_hdr;
+	struct umad_rmpp_hdr	rmpp_hdr;
+	uint8_t			data[UMAD_LEN_RMPP_DATA];
+};
+
+struct umad_vendor_packet {
+	struct umad_hdr		mad_hdr;
+	struct umad_rmpp_hdr	rmpp_hdr;
+	uint8_t			reserved;
+	uint8_t			oui[3];
+	uint8_t			data[UMAD_LEN_VENDOR_DATA];
+};
+
+enum {
+	UMAD_OPENIB_OUI		= 0x001405
+};
+
+END_C_DECLS
+#endif				/* _UMAD_TYPES_H */
Signature · 6 lines
1.7.3

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 1359409135-559-1-git-send-email-sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org

#2 lore raw

PATCH 2/7 libibumad: Add SA MAD definitions to umad

From: Sean Hefty <[email protected]>

Add a new header file, umad_sa.h, to libibumad that contains basic SA MAD definitions.

Only the SA attributes values, new methods, and base SA MAD format are given. SA attribute structure definitions are left for future development.

---
 include/infiniband/umad_sa.h |  101 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 101 insertions(+), 0 deletions(-)
 create mode 100755 include/infiniband/umad_sa.h
include/infiniband/umad_sa.h new file +101 -0
new file mode 100755
index 0000000..f3e161e
@@ -0,0 +1,101 @@
+/*
+ * Copyright (c) 2004 Topspin Communications.  All rights reserved.
+ * Copyright (c) 2005 Voltaire, Inc.  All rights reserved.
+ * Copyright (c) 2006, 2010 Intel Corporation.  All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ *     Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *      - Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *
+ *      - Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ *
+ */
+#ifndef _UMAD_SA_H
+#define _UMAD_SA_H
+
+#include <infiniband/umad_types.h>
+
+#ifdef __cplusplus
+#  define BEGIN_C_DECLS extern "C" {
+#  define END_C_DECLS   }
+#else				/* !__cplusplus */
+#  define BEGIN_C_DECLS
+#  define END_C_DECLS
+#endif				/* __cplusplus */
+
+BEGIN_C_DECLS
+
+/* SA specific methods */
+enum {
+	UMAD_SA_CLASS_VERSION		= 2,	/* IB spec version 1.1/1.2 */
+
+	UMAD_SA_METHOD_GET_TABLE	= 0x12,
+	UMAD_SA_METHOD_GET_TABLE_RESP	= 0x92,
+	UMAD_SA_METHOD_DELETE		= 0x15,
+	UMAD_SA_METHOD_DELETE_RESP	= 0x95,
+	UMAD_SA_METHOD_GET_MULTI	= 0x14,
+	UMAD_SA_METHOD_GET_MULTI_RESP	= 0x94,
+	UMAD_SA_METHOD_GET_TRACE_TABLE	= 0x13
+};
+
+/* SA attributes */
+enum {
+	UMAD_SA_ATTR_NODE_REC		= 0x0011,
+	UMAD_SA_ATTR_PORT_INFO_REC	= 0x0012,
+	UMAD_SA_ATTR_SLVL_REC		= 0x0013,
+	UMAD_SA_ATTR_SWITCH_INFO_REC	= 0x0014,
+	UMAD_SA_ATTR_LINEAR_FT_REC	= 0x0015,
+	UMAD_SA_ATTR_RANDOM_FT_REC	= 0x0016,
+	UMAD_SA_ATTR_MCAST_FT_REC	= 0x0017,
+	UMAD_SA_ATTR_SM_INFO_REC	= 0x0018,
+	UMAD_SA_ATTR_INFORM_INFO_REC	= 0x00F3,
+	UMAD_SA_ATTR_LINK_REC		= 0x0020,
+	UMAD_SA_ATTR_GUID_INFO_REC	= 0x0030,
+	UMAD_SA_ATTR_SERVICE_REC	= 0x0031,
+	UMAD_SA_ATTR_PKEY_TABLE_REC	= 0x0033,
+	UMAD_SA_ATTR_PATH_REC		= 0x0035,
+	UMAD_SA_ATTR_VL_ARB_REC		= 0x0036,
+	UMAD_SA_ATTR_MCMEMBER_REC	= 0x0038,
+	UMAD_SA_ATTR_TRACE_REC		= 0x0039,
+	UMAD_SA_ATTR_MULTI_PATH_REC	= 0x003A,
+	UMAD_SA_ATTR_SERVICE_ASSOC_REC	= 0x003B
+};
+
+enum {
+	UMAD_LEN_SA_DATA		= 200
+};
+
+struct umad_sa_packet {
+	struct umad_hdr		mad_hdr;
+	struct umad_rmpp_hdr	rmpp_hdr;
+	uint8_t			sm_key[8];
+	uint16_t		attr_offset;
+	uint16_t		reserved;
+	uint64_t		comp_mask;
+	uint8_t 		data[UMAD_LEN_SA_DATA];
+};
+
+END_C_DECLS
+#endif				/* _UMAD_SA_H */
Signature · 6 lines
1.7.3

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 1359409135-559-2-git-send-email-sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org

#4 lore raw

Re: [PATCH 2/7] libibumad: Add SA MAD definitions to umad

Quoted 10 lines · On 1/28/2013 4:38 PM, [email protected] wrote:

From: Sean Hefty <[email protected]>

Add a new header file, umad_sa.h, to libibumad that contains basic SA MAD definitions.

Only the SA attributes values, new methods, and base SA MAD format are given. SA attribute structure definitions are left for future development.

Thanks. Applied with changed file permissions.

-- Hal
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#5 lore raw

PATCH 3/7 libibumad: Add basic SM definitions to umad

In reply to a message not in the archive

From: Sean Hefty <[email protected]>

Add a new header file, umad_sm.h, to libibumad that contains basic SM MAD definitions.

Only the SM attributes values, new methods, and base SM MAD format are given. SM attribute structure definitions are left for future development.

---
 include/infiniband/umad_sm.h |  102 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 102 insertions(+), 0 deletions(-)
 create mode 100755 include/infiniband/umad_sm.h
include/infiniband/umad_sm.h new file +102 -0
new file mode 100755
index 0000000..62c75da
@@ -0,0 +1,102 @@
+/*
+ * Copyright (c) 2004 Mellanox Technologies Ltd.  All rights reserved.
+ * Copyright (c) 2004 Infinicon Corporation.  All rights reserved.
+ * Copyright (c) 2004 Intel Corporation.  All rights reserved.
+ * Copyright (c) 2004 Topspin Corporation.  All rights reserved.
+ * Copyright (c) 2004 Voltaire Corporation.  All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ *     Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *      - Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *
+ *      - Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#ifndef _UMAD_SM_H
+#define _UMAD_SM_H
+
+#include <infiniband/umad_types.h>
+
+#ifdef __cplusplus
+#  define BEGIN_C_DECLS extern "C" {
+#  define END_C_DECLS   }
+#else				/* !__cplusplus */
+#  define BEGIN_C_DECLS
+#  define END_C_DECLS
+#endif				/* __cplusplus */
+
+BEGIN_C_DECLS
+
+enum {
+	UMAD_SMP_DIRECTION		= 0x8000,
+};
+
+/* Subnet management attributes */
+enum {
+	UMAD_SMP_ATTR_NODE_DESC		= 0x0010,
+	UMAD_SMP_ATTR_NODE_INFO		= 0x0011,
+	UMAD_SMP_ATTR_SWITCH_INFO	= 0x0012,
+	UMAD_SMP_ATTR_GUID_INFO		= 0x0014,
+	UMAD_SMP_ATTR_PORT_INFO		= 0x0015,
+	UMAD_SMP_ATTR_PKEY_TABLE	= 0x0016,
+	UMAD_SMP_ATTR_SLVL_TABLE	= 0x0017,
+	UMAD_SMP_ATTR_VL_ARB_TABLE	= 0x0018,
+	UMAD_SMP_ATTR_LINEAR_FT		= 0x0019,
+	UMAD_SMP_ATTR_RANDOM_FT		= 0x001A,
+	UMAD_SMP_ATTR_MCAST_FT		= 0x001B,
+	UMAD_SMP_ATTR_SM_INFO		= 0x0020,
+	UMAD_SMP_ATTR_VENDOR_DIAG	= 0x0030,
+	UMAD_SMP_ATTR_LED_INFO		= 0x0031,
+	UMAD_SMP_ATTR_VENDOR_MASK	= 0xFF00
+};
+
+enum {
+	UMAD_LEN_SMP_DATA		= 64,
+	UMAD_SMP_MAX_HOPS		= 64
+};
+
+struct umad_smp {
+	uint8_t	 base_version;
+	uint8_t	 mgmt_class;
+	uint8_t	 class_version;
+	uint8_t	 method;
+	uint16_t status;
+	uint8_t  hop_ptr;
+	uint8_t  hop_cnt;
+	uint64_t tid;
+	uint16_t attr_id;
+	uint16_t resv;
+	uint32_t attr_mod;
+	uint64_t mkey;
+	uint16_t dr_slid;
+	uint16_t dr_dlid;
+	uint8_t  reserved[28];
+	uint8_t  data[UMAD_LEN_SMP_DATA];
+	uint8_t  initial_path[UMAD_SMP_MAX_HOPS];
+	uint8_t  return_path[UMAD_SMP_MAX_HOPS];
+};
+
+END_C_DECLS
+#endif				/* _UMAD_SM_H */
Signature · 6 lines
1.7.3

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 1359409135-559-3-git-send-email-sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org

#7 lore raw

Re: [PATCH 3/7] libibumad: Add basic SM definitions to umad

Quoted 10 lines · On 1/28/2013 4:38 PM, [email protected] wrote:

From: Sean Hefty <[email protected]>

Add a new header file, umad_sm.h, to libibumad that contains basic SM MAD definitions.

Only the SM attributes values, new methods, and base SM MAD format are given. SM attribute structure definitions are left for future development.

Thanks. Applied with changed file permissions.

-- Hal
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#8 lore raw

PATCH 4/7 libibumad: Add CM definitions to umad

In reply to a message not in the archive

From: Sean Hefty <[email protected]>

To support the madeye diag and ibacm, add CM MAD definitions to umad. Only minimal definitions are added for now. Additional structure definitions will be added later.

---
 include/infiniband/umad_cm.h |   64 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 64 insertions(+), 0 deletions(-)
 create mode 100755 include/infiniband/umad_cm.h
include/infiniband/umad_cm.h new file +64 -0
new file mode 100755
index 0000000..d48ecee
@@ -0,0 +1,64 @@
+/*
+ * Copyright (c) 2010 Intel Corporation.  All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ *     Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *      - Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *
+ *      - Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#ifndef _UMAD_CM_H
+#define _UMAD_CM_H
+
+#include <infiniband/umad_types.h>
+
+#ifdef __cplusplus
+#  define BEGIN_C_DECLS extern "C" {
+#  define END_C_DECLS   }
+#else				/* !__cplusplus */
+#  define BEGIN_C_DECLS
+#  define END_C_DECLS
+#endif				/* __cplusplus */
+
+BEGIN_C_DECLS
+
+/* Communication management attributes */
+enum {
+	UMAD_CM_ATTR_REQ		= 0x0010,
+	UMAD_CM_ATTR_MRA		= 0x0011,
+	UMAD_CM_ATTR_REJ		= 0x0012,
+	UMAD_CM_ATTR_REP		= 0x0013,
+	UMAD_CM_ATTR_RTU		= 0x0014,
+	UMAD_CM_ATTR_DREQ		= 0x0015,
+	UMAD_CM_ATTR_DREP		= 0x0016,
+	UMAD_CM_ATTR_SIDR_REQ		= 0x0017,
+	UMAD_CM_ATTR_SIDR_REP		= 0x0018,
+	UMAD_CM_ATTR_LAP		= 0x0019,
+	UMAD_CM_ATTR_APR		= 0x001A,
+};
+
+END_C_DECLS
+#endif				/* _UMAD_CM_H */
Signature · 6 lines
1.7.3

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 1359409135-559-4-git-send-email-sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org

#10 lore raw

Re: [PATCH 4/7] libibumad: Add CM definitions to umad

Quoted 7 lines · On 1/28/2013 4:38 PM, [email protected] wrote:

From: Sean Hefty <[email protected]>

To support the madeye diag and ibacm, add CM MAD definitions to umad. Only minimal definitions are added for now. Additional structure definitions will be added later.

Thanks. Applied with changed file permissions.

-- Hal
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#11 lore raw

PATCH 5/7 libibumad: Add new umad header files to release

In reply to a message not in the archive

From: Sean Hefty <[email protected]>

---
 Makefile.am |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)
Makefile.am +5 -1
index 604f57a..14e2389 100644
@@ -34,7 +34,11 @@ libibumad_la_DEPENDENCIES = $(srcdir)/src/libibumad.map
 
 libibumadincludedir = $(includedir)/infiniband
 
-libibumadinclude_HEADERS = $(srcdir)/include/infiniband/umad.h
+libibumadinclude_HEADERS = $(srcdir)/include/infiniband/umad.h \
+	$(srcdir)/include/infiniband/umad_types.h \
+	$(srcdir)/include/infiniband/umad_sa.h \
+	$(srcdir)/include/infiniband/umad_sm.h \
+	$(srcdir)/include/infiniband/umad_cm.h
 
 EXTRA_DIST = $(srcdir)/include/infiniband/umad.h \
 	libibumad.spec.in libibumad.spec \
Signature · 6 lines
1.7.3

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 1359409135-559-5-git-send-email-sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org

#14 lore raw

PATCH 6/7 libibumad: Define ntohll/htonll

In reply to a message not in the archive

From: Sean Hefty <[email protected]>

Users of umad require ntohll/htonll to set/extract data from MADs. Include the definition with umad, not just libibmad.

---
 include/infiniband/umad.h |   15 +++++++++++++--
 1 files changed, 13 insertions(+), 2 deletions(-)
include/infiniband/umad.h +13 -2
index 23abf0d..08fff71 100644
@@ -35,6 +35,8 @@
 
 #include <stdint.h>
 #include <stdlib.h>
+#include <byteswap.h>
+#include <arpa/inet.h>
 
 #ifdef __cplusplus
 #  define BEGIN_C_DECLS extern "C" {
@@ -193,8 +195,6 @@ int umad_debug(int level);
 void umad_addr_dump(ib_mad_addr_t * addr);
 void umad_dump(void *umad);
 
-#include <stdlib.h>
-
 static inline void *umad_alloc(int num, size_t size)
 {				/* alloc array of umad buffers */
 	return calloc(num, size);
@@ -205,5 +205,16 @@ static inline void umad_free(void *umad)
 	free(umad);
 }
 
+#ifndef ntohll
+  #if __BYTE_ORDER == __LITTLE_ENDIAN
+    #define ntohll(x) bswap_64(x)
+  #elif __BYTE_ORDER == __BIG_ENDIAN
+    #define ntohll(x) x
+  #endif
+#endif
+#ifndef htonll
+  #define htonll ntohll
+#endif
+
 END_C_DECLS
 #endif				/* _UMAD_H */
Signature · 6 lines
1.7.3

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 1359409135-559-6-git-send-email-sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org

#16 lore raw

Re: [PATCH 6/7] libibumad: Define ntohll/htonll

Quoted 6 lines · On 1/28/2013 4:38 PM, [email protected] wrote:

From: Sean Hefty <[email protected]>

Users of umad require ntohll/htonll to set/extract data from MADs. Include the definition with umad, not just libibmad.

Thanks. Applied.

-- Hal
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#17 lore raw

PATCH 7/7 libibumad: Define data type to indicate values are in big-endian

In reply to a message not in the archive

From: Sean Hefty <[email protected]>

The ib management interfaces require that the user specify certain values in network-byte order. To clarify which values should be in big endian format, introduce a new data type at the libibumad level.

---
 include/infiniband/umad.h       |   17 +++++++++++------
 include/infiniband/umad_sa.h    |   13 ++++++++-----
 include/infiniband/umad_sm.h    |   16 ++++++++--------
 include/infiniband/umad_types.h |   23 ++++++++++++-----------
 4 files changed, 39 insertions(+), 30 deletions(-)
include/infiniband/umad.h +11 -6
index 08fff71..b3f00e7 100644
@@ -47,21 +47,26 @@
 #endif				/* __cplusplus */
 
 BEGIN_C_DECLS
+
+typedef uint16_t be16_t;
+typedef uint32_t be32_t;
+typedef uint64_t be64_t;
+
 #define UMAD_MAX_DEVICES 32
 #define UMAD_ANY_PORT	0
 typedef struct ib_mad_addr {
-	uint32_t qpn;
-	uint32_t qkey;
-	uint16_t lid;
+	be32_t qpn;
+	be32_t qkey;
+	be16_t lid;
 	uint8_t sl;
 	uint8_t path_bits;
 	uint8_t grh_present;
 	uint8_t gid_index;
 	uint8_t hop_limit;
 	uint8_t traffic_class;
-	uint8_t gid[16];
-	uint32_t flow_label;
-	uint16_t pkey_index;
+	uint8_t gid[16]; /* network-byte order */
+	be32_t flow_label;
+	be16_t pkey_index;
 	uint8_t reserved[6];
 } ib_mad_addr_t;
 
include/infiniband/umad_sa.h +8 -5
index f3e161e..92248de 100755
@@ -87,14 +87,17 @@ enum {
 	UMAD_LEN_SA_DATA		= 200
 };
 
+/*
+ *  sm_key is not aligned on an 8-byte boundary, so is defined as a byte array
+ */
 struct umad_sa_packet {
 	struct umad_hdr		mad_hdr;
 	struct umad_rmpp_hdr	rmpp_hdr;
-	uint8_t			sm_key[8];
-	uint16_t		attr_offset;
-	uint16_t		reserved;
-	uint64_t		comp_mask;
-	uint8_t 		data[UMAD_LEN_SA_DATA];
+	uint8_t			sm_key[8]; /* network-byte order */
+	be16_t			attr_offset;
+	be16_t			reserved;
+	be64_t			comp_mask;
+	uint8_t 		data[UMAD_LEN_SA_DATA]; /* network-byte order */
 };
 
 END_C_DECLS
include/infiniband/umad_sm.h +8 -8
index 62c75da..10348d4 100755
@@ -82,16 +82,16 @@ struct umad_smp {
 	uint8_t	 mgmt_class;
 	uint8_t	 class_version;
 	uint8_t	 method;
-	uint16_t status;
+	be16_t   status;
 	uint8_t  hop_ptr;
 	uint8_t  hop_cnt;
-	uint64_t tid;
-	uint16_t attr_id;
-	uint16_t resv;
-	uint32_t attr_mod;
-	uint64_t mkey;
-	uint16_t dr_slid;
-	uint16_t dr_dlid;
+	be64_t   tid;
+	be16_t   attr_id;
+	be16_t   resv;
+	be32_t   attr_mod;
+	be64_t   mkey;
+	be16_t   dr_slid;
+	be16_t   dr_dlid;
 	uint8_t  reserved[28];
 	uint8_t  data[UMAD_LEN_SMP_DATA];
 	uint8_t  initial_path[UMAD_SMP_MAX_HOPS];
include/infiniband/umad_types.h +12 -11
index 54b7e72..bf93add 100755
@@ -38,6 +38,7 @@
 #define _UMAD_TYPES_H
 
 #include <stdint.h>
+#include <infiniband/umad.h>
 
 #ifdef __cplusplus
 #  define BEGIN_C_DECLS extern "C" {
@@ -149,11 +150,11 @@ struct umad_hdr {
 	uint8_t	 class_version;
 	uint8_t	 method;
 	uint16_t status;
-	uint16_t class_specific;
-	uint64_t tid;
-	uint16_t attr_id;
-	uint16_t resv;
-	uint32_t attr_mod;
+	be16_t   class_specific;
+	be64_t   tid;
+	be16_t   attr_id;
+	be16_t   resv;
+	be32_t   attr_mod;
 };
 
 struct umad_rmpp_hdr {
@@ -161,27 +162,27 @@ struct umad_rmpp_hdr {
 	uint8_t	 rmpp_type;
 	uint8_t	 rmpp_rtime_flags;
 	uint8_t	 rmpp_status;
-	uint32_t seg_num;
-	uint32_t paylen_newwin;
+	be32_t   seg_num;
+	be32_t   paylen_newwin;
 };
 
 struct umad_packet {
 	struct umad_hdr		mad_hdr;
-	uint8_t			data[UMAD_LEN_DATA];
+	uint8_t			data[UMAD_LEN_DATA]; /* network-byte order */
 };
 
 struct umad_rmpp_packet {
 	struct umad_hdr		mad_hdr;
 	struct umad_rmpp_hdr	rmpp_hdr;
-	uint8_t			data[UMAD_LEN_RMPP_DATA];
+	uint8_t			data[UMAD_LEN_RMPP_DATA]; /* network-byte order */
 };
 
 struct umad_vendor_packet {
 	struct umad_hdr		mad_hdr;
 	struct umad_rmpp_hdr	rmpp_hdr;
 	uint8_t			reserved;
-	uint8_t			oui[3];
-	uint8_t			data[UMAD_LEN_VENDOR_DATA];
+	uint8_t			oui[3];	/* network-byte order */
+	uint8_t			data[UMAD_LEN_VENDOR_DATA]; /* network-byte order */
 };
 
 enum {
Signature · 6 lines
1.7.3

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 1359409135-559-7-git-send-email-sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org

#19 lore raw

Re: [PATCH 7/7] libibumad: Define data type to indicate values are in big-endian

Quoted 8 lines · On 1/28/2013 4:38 PM, [email protected] wrote:

From: Sean Hefty <[email protected]>

The ib management interfaces require that the user specify certain values in network-byte order. To clarify which values should be in big endian format, introduce a new data type at the libibumad level.

Thanks. Applied.

-- Hal
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#20 lore raw
In reply to a message not in the archive
Quoted 153 lines · On 1/28/2013 4:38 PM, [email protected] wrote:

From: Sean Hefty <[email protected]>

The only definitions for MAD data types are in ib_types.h, which is an opensm file. The libibumad interface is essentially useless without these data types. Add new header files to libibumad with basic MAD data types.

The definitions and structures are based on those defined in the linux kernel. Only an initial framework is given, basically the values for various methods, attributes, etc. along with structure definitions for the common, rmpp, and vendor specific headers. Other data structures are left for future development.

---
 include/infiniband/umad_types.h |  192 +++++++++++++++++++++++++++++++++++++++
 1 files changed, 192 insertions(+), 0 deletions(-)
 create mode 100755 include/infiniband/umad_types.h
include/infiniband/umad_types.h new file +128 -0
new file mode 100755
index 0000000..54b7e72
@@ -0,0 +1,192 @@
+/*
+ * Copyright (c) 2004 Mellanox Technologies Ltd.  All rights reserved.
+ * Copyright (c) 2004 Infinicon Corporation.  All rights reserved.
+ * Copyright (c) 2004, 2010 Intel Corporation.  All rights reserved.
+ * Copyright (c) 2004 Topspin Corporation.  All rights reserved.
+ * Copyright (c) 2004-2006 Voltaire Corporation.  All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ *     Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *      - Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *
+ *      - Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ *
+ */
+#ifndef _UMAD_TYPES_H
+#define _UMAD_TYPES_H
+
+#include <stdint.h>
+
+#ifdef __cplusplus
+#  define BEGIN_C_DECLS extern "C" {
+#  define END_C_DECLS   }
+#else				/* !__cplusplus */
+#  define BEGIN_C_DECLS
+#  define END_C_DECLS
+#endif				/* __cplusplus */
+
+BEGIN_C_DECLS
+
+#define UMAD_BASE_VERSION		1
+
+/* Management classes */
+enum {
+	UMAD_CLASS_SUBN_LID_ROUTED	= 0x01,
+	UMAD_CLASS_SUBN_DIRECTED_ROUTE	= 0x81,
+	UMAD_CLASS_SUBN_ADM		= 0x03,
+	UMAD_CLASS_PERF_MGMT		= 0x04,
+	UMAD_CLASS_BM			= 0x05,
+	UMAD_CLASS_DEVICE_MGMT		= 0x06,
+	UMAD_CLASS_CM			= 0x07,
+	UMAD_CLASS_SNMP			= 0x08,
+	UMAD_CLASS_VENDOR_RANGE1_START	= 0x09,
+	UMAD_CLASS_VENDOR_RANGE1_END	= 0x0F,
+	UMAD_CLASS_DEVICE_ADM		= 0x10,
+	UMAD_CLASS_BOOT_MGMT		= 0x11,
+	UMAD_CLASS_BIS			= 0x12,
+	UMAD_CLASS_CONG_MGMT		= 0x21,
+	UMAD_CLASS_VENDOR_RANGE2_START	= 0x30,
+	UMAD_CLASS_VENDOR_RANGE2_END	= 0x4F
+};
+
+/* Management methods */
+enum {
+	UMAD_METHOD_GET			= 0x01,
+	UMAD_METHOD_SET			= 0x02,
+	UMAD_METHOD_GET_RESP		= 0x81,
+	UMAD_METHOD_SEND		= 0x03,
+	UMAD_METHOD_TRAP		= 0x05,
+	UMAD_METHOD_REPORT		= 0x06,
+	UMAD_METHOD_REPORT_RESP		= 0x86,
+	UMAD_METHOD_TRAP_REPRESS	= 0x07,
+	UMAD_METHOD_RESP		= 0x80
+};
+
+enum {
+	UMAD_STATUS_SUCCESS  = 0x0000,
+	UMAD_STATUS_BUSY     = 0x0001,
+	UMAD_STATUS_REDIRECT = 0x0002,
+
+	/* Invalid fields, bits 2-4 */
+	UMAD_STATUS_BAD_VERSION          = (1 << 2),
+	UMAD_STATUS_METHOD_NOT_SUPPORTED = (2 << 2),
+	UMAD_STATUS_ATTR_NOT_SUPPORTED   = (3 << 2),
+	UMAD_STATUS_INVALID_ATTR_VALUE   = (7 << 2),
+
+	UMAD_STATUS_CLASS_MASK = 0xFF00
+};
+
+/* Attributes common to multiple classes */
+enum {
+	UMAD_ATTR_CLASS_PORT_INFO	= 0x0001,
+	UMAD_ATTR_NOTICE		= 0x0002,
+	UMAD_ATTR_INFORM_INFO		= 0x0003
+};
+
+/* RMPP information */
+#define UMAD_RMPP_VERSION		1
+enum {
+	UMAD_RMPP_TYPE_DATA		= 1,
+	UMAD_RMPP_TYPE_ACK		= 2,
+	UMAD_RMPP_TYPE_STOP		= 3,
+	UMAD_RMPP_TYPE_ABORT		= 4,
+
+	UMAD_RMPP_FLAG_MASK		= 0x07,
+	UMAD_RMPP_FLAG_ACTIVE		= 1,
+	UMAD_RMPP_FLAG_FIRST		= (1 << 1),
+	UMAD_RMPP_FLAG_LAST		= (1 << 2),
+
+	UMAD_RMPP_RESP_TIME_SHIFT	= 3,
+	UMAD_RMPP_NO_RESP_TIME		= 0x1F,
+
+	UMAD_RMPP_STATUS_SUCCESS	= 0,
+	UMAD_RMPP_STATUS_RESX		= 1,
+	UMAD_RMPP_STATUS_ABORT_MIN	= 118,
+	UMAD_RMPP_STATUS_T2L		= 118,
+	UMAD_RMPP_STATUS_BAD_LEN	= 119,

include/infiniband/umad_types.h line 138

Quoted 10 lines
include/infiniband/umad_types.h new file +10 -0
+	UMAD_RMPP_STATUS_BAD_SEG	= 120,
+	UMAD_RMPP_STATUS_BADT		= 121,
+	UMAD_RMPP_STATUS_W2S		= 122,
+	UMAD_RMPP_STATUS_S2B		= 123,
+	UMAD_RMPP_STATUS_BAD_STATUS	= 124,
+	UMAD_RMPP_STATUS_UNV		= 125,
+	UMAD_RMPP_STATUS_TMR		= 126,
+	UMAD_RMPP_STATUS_UNSPEC		= 127,
+	UMAD_RMPP_STATUS_ABORT_MAX	= 127
+};

Should RMPP be included here as it's not currently exposed to user space ?

-- Hal

Quoted 44 lines
include/infiniband/umad_types.h new file +44 -0
+
+enum {
+	UMAD_LEN_DATA			= 232,
+	UMAD_LEN_RMPP_DATA		= 220,
+	UMAD_LEN_VENDOR_DATA		= 216,
+};
+
+struct umad_hdr {
+	uint8_t	 base_version;
+	uint8_t	 mgmt_class;
+	uint8_t	 class_version;
+	uint8_t	 method;
+	uint16_t status;
+	uint16_t class_specific;
+	uint64_t tid;
+	uint16_t attr_id;
+	uint16_t resv;
+	uint32_t attr_mod;
+};
+
+struct umad_rmpp_hdr {
+	uint8_t	 rmpp_version;
+	uint8_t	 rmpp_type;
+	uint8_t	 rmpp_rtime_flags;
+	uint8_t	 rmpp_status;
+	uint32_t seg_num;
+	uint32_t paylen_newwin;
+};
+
+struct umad_packet {
+	struct umad_hdr		mad_hdr;
+	uint8_t			data[UMAD_LEN_DATA];
+};
+
+struct umad_rmpp_packet {
+	struct umad_hdr		mad_hdr;
+	struct umad_rmpp_hdr	rmpp_hdr;
+	uint8_t			data[UMAD_LEN_RMPP_DATA];
+};
+
+struct umad_vendor_packet {
+	struct umad_hdr		mad_hdr;
+	struct umad_rmpp_hdr	rmpp_hdr;
+	uint8_t			reserved;

include/infiniband/umad_types.h line 192

Quoted 10 lines
include/infiniband/umad_types.h new file +10 -0
+	uint8_t			oui[3];
+	uint8_t			data[UMAD_LEN_VENDOR_DATA];
+};
+
+enum {
+	UMAD_OPENIB_OUI		= 0x001405
+};
+
+END_C_DECLS
+#endif				/* _UMAD_TYPES_H */

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 5124F212.2060503-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org

#22 lore raw
Quoted 25 lines
Quoted 25 lines
include/infiniband/umad_types.h new file +25 -0
+/* RMPP information */
+#define UMAD_RMPP_VERSION		1
+enum {
+	UMAD_RMPP_TYPE_DATA		= 1,
+	UMAD_RMPP_TYPE_ACK		= 2,
+	UMAD_RMPP_TYPE_STOP		= 3,
+	UMAD_RMPP_TYPE_ABORT		= 4,
+
+	UMAD_RMPP_FLAG_MASK		= 0x07,
+	UMAD_RMPP_FLAG_ACTIVE		= 1,
+	UMAD_RMPP_FLAG_FIRST		= (1 << 1),
+	UMAD_RMPP_FLAG_LAST		= (1 << 2),
+
+	UMAD_RMPP_RESP_TIME_SHIFT	= 3,
+	UMAD_RMPP_NO_RESP_TIME		= 0x1F,
+
+	UMAD_RMPP_STATUS_SUCCESS	= 0,
+	UMAD_RMPP_STATUS_RESX		= 1,
+	UMAD_RMPP_STATUS_ABORT_MIN	= 118,
+	UMAD_RMPP_STATUS_T2L		= 118,
+	UMAD_RMPP_STATUS_BAD_LEN	= 119,
+	UMAD_RMPP_STATUS_BAD_SEG	= 120,
+	UMAD_RMPP_STATUS_BADT		= 121,
+	UMAD_RMPP_STATUS_W2S		= 122,
+	UMAD_RMPP_STATUS_S2B		= 123,
Quoted 8 lines

include/infiniband/umad_types.h line 138

Quoted 6 lines
include/infiniband/umad_types.h new file +6 -0
+	UMAD_RMPP_STATUS_BAD_STATUS	= 124,
+	UMAD_RMPP_STATUS_UNV		= 125,
+	UMAD_RMPP_STATUS_TMR		= 126,
+	UMAD_RMPP_STATUS_UNSPEC		= 127,
+	UMAD_RMPP_STATUS_ABORT_MAX	= 127
+};

Should RMPP be included here as it's not currently exposed to user space ?

I need to check the kernel code, but I believe that the RMPP header is exposed.

- Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 1828884A29C6694DAF28B7E6B8A823736F34E958-P5GAC/[email protected]

#24 lore raw
Quoted 1 line

I need to check the kernel code, but I believe that the RMPP header is exposed.

I looked at copy_recv_mad(), and it copies the entire 256-byte MAD to user space, which includes any RMPP header, followed by any additional segmented data. So most of the RMPP definitions are relevant, the exceptions possibly being UMAD_RMPP_TYPE_[ACK | STOP | ABORT]. IMO - I would keep those for completeness.

- Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 1828884A29C6694DAF28B7E6B8A823736F34E976-P5GAC/[email protected]

#26 lore raw
Quoted 3 lines · Sean
Quoted 1 line

I need to check the kernel code, but I believe that the RMPP header is exposed.

I looked at copy_recv_mad(), and it copies the entire 256-byte MAD to user space, which includes any RMPP header, followed by any additional segmented data. So most of the RMPP definitions are relevant, the exceptions possibly being UMAD_RMPP_TYPE_[ACK | STOP | ABORT]. IMO - I would keep those for completeness.

Yes but how much of header is relevant when it's a multipacket RMPP MAD message ? My concern is that it may be confusing as to validity/use of certain RMPP fields, etc.

-- Hal

Quoted 2 lines

- Sean

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 5124FC59.2070602-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org

#28 lore raw
Quoted 9 lines · On Wed, 20 Feb 2013 11:39:53 -0500 Hal Rosenstock…
Quoted 3 lines · Sean
Quoted 1 line

I need to check the kernel code, but I believe that the RMPP header is exposed.

I looked at copy_recv_mad(), and it copies the entire 256-byte MAD to user space, which includes any RMPP header, followed by any additional segmented data. So most of the RMPP definitions are relevant, the exceptions possibly being UMAD_RMPP_TYPE_[ACK | STOP | ABORT]. IMO - I would keep those for completeness.

Yes but how much of header is relevant when it's a multipacket RMPP MAD message ? My concern is that it may be confusing as to validity/use of certain RMPP fields, etc.

IMO the confusion can be overcome by documenting that fact that libibumad coalesces the multipacket RMPP response into one buffer returned by umad_recv as well as how it is done. This is where the confusion lies.

If you do accept the RMPP defines I have a subsequent patch for the *_str functions for them.

Ira

Quoted 9 lines

-- Hal

Quoted 2 lines

- Sean

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Signature · 9 lines
Ira Weiny
Member of Technical Staff
Lawrence Livermore National Lab
925-423-8008
[email protected]
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 20130220094219.19f80f5c0b65c50a48b29c96-i2BcT+NCU+M@public.gmane.org

#30 lore raw
Quoted 6 lines · Ira Weiny
Quoted 3 lines · On Wed, 20 Feb 2013 11:39:53 -0500 Hal Rosenstock…
Quoted 2 lines · Sean
Quoted 1 line

I need to check the kernel code, but I believe that the RMPP header is exposed.

Quoted 8 lines
Quoted 6 lines
Quoted 1 line

I looked at copy_recv_mad(), and it copies the entire 256-byte MAD to user space, which includes any RMPP header, followed by any additional segmented data. So most of the RMPP definitions are relevant, the exceptions possibly being UMAD_RMPP_TYPE_[ACK | STOP | ABORT]. IMO - I would keep those for completeness.

Yes but how much of header is relevant when it's a multipacket RMPP MAD message ? My concern is that it may be confusing as to validity/use of certain RMPP fields, etc.

IMO the confusion can be overcome by documenting that fact that libibumad coalesces the multipacket RMPP response into one buffer returned by umad_recv as well as how it is done. This is where the confusion lies.

Would you generate a patch that clarifies this issue for both the receive and send sides ? Thanks.

-- Hal

Quoted 15 lines

If you do accept the RMPP defines I have a subsequent patch for the *_str functions for them.

Ira

Quoted 9 lines

-- Hal

Quoted 2 lines

- Sean

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#31 lore raw
In reply to a message not in the archive
Quoted 8 lines · Hal Rosenstock
Quoted 3 lines · Sean
Quoted 1 line

I need to check the kernel code, but I believe that the RMPP header is exposed.

I looked at copy_recv_mad(), and it copies the entire 256-byte MAD to user space, which includes any RMPP header, followed by any additional segmented data. So most of the RMPP definitions are relevant, the exceptions possibly being UMAD_RMPP_TYPE_[ACK | STOP | ABORT]. IMO - I would keep those for completeness.

Yes but how much of header is relevant when it's a multipacket RMPP MAD message ? My concern is that it may be confusing as to validity/use of certain RMPP fields, etc.

How about moving ahead without these for now ? They can always be added back in when the time is right. If that's acceptable to you, I'll make that modification myself and move onto the other libibumad patches in your series.

-- Hal

Quoted 6 lines

-- Hal

Quoted 2 lines

- Sean

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 512520CF.8000902-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org

#33 lore raw
Quoted 4 lines

How about moving ahead without these for now ? They can always be added back in when the time is right. If that's acceptable to you, I'll make that modification myself and move onto the other libibumad patches in your series.

That's fine.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#34 lore raw
In reply to a message not in the archive
Quoted 7 lines · On 1/28/2013 4:38 PM, [email protected] wrote:

From: Sean Hefty <[email protected]>

The only definitions for MAD data types are in ib_types.h, which is an opensm file. The libibumad interface is essentially useless without these data types. Add new header files to libibumad with basic MAD data types.

Quoted 7 lines

The definitions and structures are based on those defined in the linux kernel. Only an initial framework is given, basically the values for various methods, attributes, etc. along with structure definitions for the common, rmpp, and vendor specific headers. Other data structures are left for future development.

Thanks. Applied without RMPP enum and changed file permissions.

-- Hal
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html