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

Message ID	1359409135-559-1-git-send-email-sean.hefty@intel.com (mailing list archive)
State	Accepted
Delegated to:	Hal Rosenstock
Headers	show Return-Path: <linux-rdma-owner@vger.kernel.org> From: sean.hefty@intel.com To: linux-rdma@vger.kernel.org, alexne@mellanox.com Cc: Sean Hefty <sean.hefty@intel.com> Subject: [PATCH 1/7] libibumad: Provide MAD definitions with libibumad Date: Mon, 28 Jan 2013 13:38:49 -0800 Message-Id: <1359409135-559-1-git-send-email-sean.hefty@intel.com> Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk

Hefty, Sean Jan. 28, 2013, 9:38 p.m. UTC

From: Sean Hefty <sean.hefty@intel.com>

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@intel.com>
---
 include/infiniband/umad_types.h |  192 +++++++++++++++++++++++++++++++++++++++
 1 files changed, 192 insertions(+), 0 deletions(-)
 create mode 100755 include/infiniband/umad_types.h

Hal Rosenstock Feb. 20, 2013, 3:56 p.m. UTC | #1

On 1/28/2013 4:38 PM, sean.hefty@intel.com wrote:
> From: Sean Hefty <sean.hefty@intel.com>
> 
> 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@intel.com>
> ---
>  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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hefty, Sean Feb. 20, 2013, 4:07 p.m. UTC | #2

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

Hefty, Sean Feb. 20, 2013, 4:29 p.m. UTC | #3

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

Hal Rosenstock Feb. 20, 2013, 4:39 p.m. UTC | #4

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

Ira Weiny Feb. 20, 2013, 5:42 p.m. UTC | #5

On Wed, 20 Feb 2013 11:39:53 -0500
Hal Rosenstock <hal@dev.mellanox.co.il> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hal Rosenstock Feb. 20, 2013, 7:12 p.m. UTC | #6

On 2/20/2013 12:42 PM, Ira Weiny wrote:
> On Wed, 20 Feb 2013 11:39:53 -0500
> Hal Rosenstock <hal@dev.mellanox.co.il> 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@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

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

Hal Rosenstock Feb. 20, 2013, 7:15 p.m. UTC | #7

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

Hefty, Sean Feb. 20, 2013, 9:06 p.m. UTC | #8

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

Hal Rosenstock Feb. 20, 2013, 10:39 p.m. UTC | #9

On 1/28/2013 4:38 PM, sean.hefty@intel.com wrote:
> From: Sean Hefty <sean.hefty@intel.com>
> 
> 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@intel.com>

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

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

Commit Message

Comments

Patch