[PATCH 1/7] libibumad: Provide MAD definitions with libibumad

[PATCH 1/7] libibumad: Provide MAD definitions with libibumad

[sean.hefty-ral2JQCrhuEAvxtiuMwx3w]

From: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

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.

Signed-off-by: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
 include/infiniband/umad_types.h |  192 +++++++++++++++++++++++++++++++++++++++
 1 files changed, 192 insertions(+), 0 deletions(-)
 create mode 100755 include/infiniband/umad_types.h

diff --git a/include/infiniband/umad_types.h b/include/infiniband/umad_types.h
new file mode 100755
index 0000000..54b7e72
--- /dev/null
+++ b/include/infiniband/umad_types.h
@@ -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 */
-- 
1.7.3

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[sean.hefty-ral2JQCrhuEAvxtiuMwx3w]

From: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

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.

Signed-off-by: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
 include/infiniband/umad_sa.h |  101 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 101 insertions(+), 0 deletions(-)
 create mode 100755 include/infiniband/umad_sa.h

diff --git a/include/infiniband/umad_sa.h b/include/infiniband/umad_sa.h
new file mode 100755
index 0000000..f3e161e
--- /dev/null
+++ b/include/infiniband/umad_sa.h
@@ -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 */
-- 
1.7.3

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Hal Rosenstock]

On 1/28/2013 4:38 PM, sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org wrote:
> From: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> 
> 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.
> 
> Signed-off-by: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[sean.hefty-ral2JQCrhuEAvxtiuMwx3w]

From: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

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.

Signed-off-by: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
 include/infiniband/umad_sm.h |  102 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 102 insertions(+), 0 deletions(-)
 create mode 100755 include/infiniband/umad_sm.h

diff --git a/include/infiniband/umad_sm.h b/include/infiniband/umad_sm.h
new file mode 100755
index 0000000..62c75da
--- /dev/null
+++ b/include/infiniband/umad_sm.h
@@ -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 */
-- 
1.7.3

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Hal Rosenstock]

On 1/28/2013 4:38 PM, sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org wrote:
> From: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> 
> 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.
> 
> Signed-off-by: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[sean.hefty-ral2JQCrhuEAvxtiuMwx3w]

From: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

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.

Signed-off-by: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
 include/infiniband/umad_cm.h |   64 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 64 insertions(+), 0 deletions(-)
 create mode 100755 include/infiniband/umad_cm.h

diff --git a/include/infiniband/umad_cm.h b/include/infiniband/umad_cm.h
new file mode 100755
index 0000000..d48ecee
--- /dev/null
+++ b/include/infiniband/umad_cm.h
@@ -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 */
-- 
1.7.3

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Hal Rosenstock]

On 1/28/2013 4:38 PM, sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org wrote:
> From: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> 
> 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.
> 
> Signed-off-by: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[sean.hefty-ral2JQCrhuEAvxtiuMwx3w]

From: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

Signed-off-by: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
 Makefile.am |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 604f57a..14e2389 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -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 \
-- 
1.7.3

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Hal Rosenstock]

On 1/28/2013 4:38 PM, sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org wrote:
> From: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> 
> Signed-off-by: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

Thanks. Applied.

-- Hal
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[sean.hefty-ral2JQCrhuEAvxtiuMwx3w]

From: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

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

Signed-off-by: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
 include/infiniband/umad.h |   15 +++++++++++++--
 1 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/include/infiniband/umad.h b/include/infiniband/umad.h
index 23abf0d..08fff71 100644
--- a/include/infiniband/umad.h
+++ b/include/infiniband/umad.h
@@ -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 */
-- 
1.7.3

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Hal Rosenstock]

On 1/28/2013 4:38 PM, sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org wrote:
> From: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> 
> Users of umad require ntohll/htonll to set/extract data from
> MADs.  Include the definition with umad, not just libibmad.
> 
> Signed-off-by: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

Thanks. Applied.

-- Hal
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[sean.hefty-ral2JQCrhuEAvxtiuMwx3w]

From: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

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.

Signed-off-by: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
 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(-)

diff --git a/include/infiniband/umad.h b/include/infiniband/umad.h
index 08fff71..b3f00e7 100644
--- a/include/infiniband/umad.h
+++ b/include/infiniband/umad.h
@@ -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;
 
diff --git a/include/infiniband/umad_sa.h b/include/infiniband/umad_sa.h
index f3e161e..92248de 100755
--- a/include/infiniband/umad_sa.h
+++ b/include/infiniband/umad_sa.h
@@ -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
diff --git a/include/infiniband/umad_sm.h b/include/infiniband/umad_sm.h
index 62c75da..10348d4 100755
--- a/include/infiniband/umad_sm.h
+++ b/include/infiniband/umad_sm.h
@@ -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];
diff --git a/include/infiniband/umad_types.h b/include/infiniband/umad_types.h
index 54b7e72..bf93add 100755
--- a/include/infiniband/umad_types.h
+++ b/include/infiniband/umad_types.h
@@ -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 {
-- 
1.7.3

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Hal Rosenstock]

On 1/28/2013 4:38 PM, sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org wrote:
> From: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> 
> 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.
> 
> Signed-off-by: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

Thanks. Applied.

-- Hal
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/7] libibumad: Provide MAD definitions with libibumad

[Hal Rosenstock]

On 1/28/2013 4:38 PM, sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org wrote:
> From: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> 
> 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.
> 
> Signed-off-by: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> ---
>  include/infiniband/umad_types.h |  192 +++++++++++++++++++++++++++++++++++++++
>  1 files changed, 192 insertions(+), 0 deletions(-)
>  create mode 100755 include/infiniband/umad_types.h
> 
> diff --git a/include/infiniband/umad_types.h b/include/infiniband/umad_types.h
> new file mode 100755
> index 0000000..54b7e72
> --- /dev/null
> +++ b/include/infiniband/umad_types.h
> @@ -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
> +};

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

-- Hal

> +
> +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 */

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 1/7] libibumad: Provide MAD definitions with libibumad

[Hefty, Sean]

> > +/* 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
> > +};
> 
> 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 1/7] libibumad: Provide MAD definitions with libibumad

[Hefty, Sean]

> 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/7] libibumad: Provide MAD definitions with libibumad

[Hal Rosenstock]

On 2/20/2013 11:29 AM, Hefty, Sean wrote:
>> 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

> - Sean
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/7] libibumad: Provide MAD definitions with libibumad

[Ira Weiny]

On Wed, 20 Feb 2013 11:39:53 -0500
Hal Rosenstock <hal-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> wrote:

> On 2/20/2013 11:29 AM, Hefty, Sean wrote:
> >> 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

> -- Hal
> 
> > - Sean
> > 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Ira Weiny
Member of Technical Staff
Lawrence Livermore National Lab
925-423-8008
weiny2-i2BcT+NCU+M@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/7] libibumad: Provide MAD definitions with libibumad

[Hal Rosenstock]

On 2/20/2013 12:42 PM, Ira Weiny wrote:
> On Wed, 20 Feb 2013 11:39:53 -0500
> Hal Rosenstock <hal-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> wrote:
> 
>> On 2/20/2013 11:29 AM, Hefty, Sean wrote:
>>>> 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.

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

-- Hal

> If you do accept the RMPP defines I have a subsequent patch for the *_str functions for them.
> 
> Ira
> 
>> -- Hal
>>
>>> - Sean
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/7] libibumad: Provide MAD definitions with libibumad

[Hal Rosenstock]

On 2/20/2013 11:39 AM, Hal Rosenstock wrote:
> On 2/20/2013 11:29 AM, Hefty, Sean wrote:
>>> 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

> 
> -- Hal
> 
>> - Sean
>>
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 1/7] libibumad: Provide MAD definitions with libibumad

[Hefty, Sean]

> 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/7] libibumad: Provide MAD definitions with libibumad

[Hal Rosenstock]

On 1/28/2013 4:38 PM, sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org wrote:
> From: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> 
> 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.
> 
> Signed-off-by: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Hefty, Sean]

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

Signed-off-by: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
 include/infiniband/umad.h |   21 +++++++++++++++++++--
 1 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/include/infiniband/umad.h b/include/infiniband/umad.h
index 23abf0d..6c337c0 100644
--- a/include/infiniband/umad.h
+++ b/include/infiniband/umad.h
@@ -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,22 @@ static inline void umad_free(void *umad)
 	free(umad);
 }
 
+#ifndef ntohll
+  #if __BYTE_ORDER == __LITTLE_ENDIAN
+    static inline uint64_t ntohll(uint64_t x)
+    {
+        return bswap_64(x);
+    }
+  #elif __BYTE_ORDER == __BIG_ENDIAN
+    static inline uint64_t ntohll(uint64_t x)
+    {
+        return x;
+    }
+  #endif
+#endif
+#ifndef htonll
+  #define htonll ntohll
+#endif
+
 END_C_DECLS
 #endif				/* _UMAD_H */


--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html