All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/7] nvme-fabrics: Add FC transport FC-NVME definitions
@ 2016-10-04  6:26 James Smart
  2016-10-04  7:32 ` Hannes Reinecke
  0 siblings, 1 reply; 6+ messages in thread
From: James Smart @ 2016-10-04  6:26 UTC (permalink / raw)



nvme-fabrics: Add FC transport FC-NVME definitions:
- Formats for Cmd, Data, Rsp IUs
- Formats FC-4 LS definitions

(Patch unchanged from prior posting)

Signed-off-by: James Smart <james.smart at broadcom.com>
Acked-by: Johannes Thumshirn <jth at kernel.org>
Acked-by: Jay Freyensee <james_p_freyensee at linux.intel.com>
Reviewed-by: Christoph Hellwig <hch at lst.de>
---
 include/linux/nvme-fc.h | 296 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 296 insertions(+)
 create mode 100644 include/linux/nvme-fc.h

diff --git a/include/linux/nvme-fc.h b/include/linux/nvme-fc.h
new file mode 100644
index 0000000..99e9200
--- /dev/null
+++ b/include/linux/nvme-fc.h
@@ -0,0 +1,296 @@
+/*
+ * Copyright (c) 2016 Avago Technologies.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful.
+ * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES,
+ * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A
+ * PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO
+ * THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID.
+ * See the GNU General Public License for more details, a copy of which
+ * can be found in the file COPYING included with this package
+ *
+ */
+
+/*
+ * This file contains definitions relative to FC-NVME r1.05
+ */
+
+#ifndef _NVME_FC_H
+#define _NVME_FC_H 1
+
+#define NVME_FC4_TYPE			0x28
+
+#define NVME_CMD_SCSI_ID		0xFD
+#define NVME_CMD_FC_ID			NVME_FC4_TYPE
+
+/* FC-NVME Cmd IU Flags */
+#define FCNVME_CMD_FLAGS_DIRMASK	0x03
+#define FCNVME_CMD_FLAGS_WRITE		0x01
+#define FCNVME_CMD_FLAGS_READ		0x02
+
+struct nvme_fc_cmd_iu {
+	__u8			scsi_id;
+	__u8			fc_id;
+	__be16			iu_len;
+	__u8			rsvd4[3];
+	__u8			flags;
+	__be32			rsvd8[2];
+	__be64			connection_id;
+	__be32			csn;
+	__be32			data_len;
+	struct nvme_command	sqe;
+};
+
+#define NVME_FC_SIZEOF_ZEROS_RSP	12
+
+struct nvme_fc_ersp_iu {
+	__u8			rsvd0[2];
+	__be16			iu_len;
+	__be32			rsn;
+	__be32			rsvd8[2];
+	struct nvme_completion	cqe;
+	/* for now - no additional payload */
+};
+
+
+/* FC-NVME r1.03/16-119v0 NVME Link Services */
+enum {
+	FCNVME_LS_RSVD			= 0,
+	FCNVME_LS_RJT			= 1,
+	FCNVME_LS_ACC			= 2,
+	FCNVME_LS_CREATE_ASSOCIATION	= 3,
+	FCNVME_LS_CREATE_CONNECTION	= 4,
+	FCNVME_LS_DISCONNECT		= 5,
+};
+
+/* FC-NVME r1.03/16-119v0 NVME Link Service Descriptors */
+enum {
+	FCNVME_LSDESC_RSVD		= 0x0,
+	FCNVME_LSDESC_RQST		= 0x1,
+	FCNVME_LSDESC_RJT		= 0x2,
+	FCNVME_LSDESC_CREATE_ASSOC_CMD	= 0x3,
+	FCNVME_LSDESC_CREATE_CONN_CMD	= 0x4,
+	FCNVME_LSDESC_DISCONN_CMD	= 0x5,
+	FCNVME_LSDESC_CONN_ID		= 0x6,
+	FCNVME_LSDESC_ASSOC_ID		= 0x7,
+};
+
+
+/* ********** start of Link Service Descriptors ********** */
+
+
+/* fills in length of a descriptor. Struture minus descriptor header */
+#define FCNVME_LSDESC_LEN(lsdesc) \
+		cpu_to_be32(sizeof(lsdesc) - (2*(sizeof(u32))))
+
+struct fcnvme_ls_rqst_w0 {
+	u8	ls_cmd;			/* FCNVME_LS_xxx */
+	u8	zeros[3];
+};
+
+/* FCNVME_LSDESC_RQST */
+struct fcnvme_lsdesc_rqst {
+	__be32	desc_tag;		/* FCNVME_LSDESC_xxx */
+	__be32	desc_len;
+	struct fcnvme_ls_rqst_w0	w0;
+	__be32	rsvd12;
+};
+
+/* From LS-3 */
+enum {
+	LSRJT_REASON_INVALID_ELS_CODE		= 0x1,
+	LSRJT_REASON_LOGICAL_ERROR		= 0x3,
+	LSRJT_REASON_LOGICAL_BUSY		= 0x5,
+	LSRJT_REASON_PROTOCOL_ERROR		= 0x7,
+	LSRJT_REASON_UNABLE_TO_PERFORM_CMD	= 0x9,
+	LSRJT_REASON_CMD_NOT_SUPPORTED		= 0xB,
+	LSRJT_REASON_CMD_ALREADY_IN_PROGRESS	= 0xE,
+	LSRJT_REASON_FIP_ERROR			= 0x20,
+	/* Add others later */
+};
+
+enum {
+	LSRJT_EXPL_NO_EXPLANATION		= 0x0,
+	/* Add others later */
+};
+
+
+/* FCNVME_LSDESC_RJT */
+struct fcnvme_lsdesc_rjt {
+	__be32	desc_tag;		/* FCNVME_LSDESC_xxx */
+	__be32	desc_len;
+	u8	rsvd8;
+	u8	reason_code;
+	u8	reason_explanation;
+	u8	vendor;
+	__be32	rsvd12;
+};
+
+
+#define FCNVME_ASSOC_HOSTID_LEN		64
+#define FCNVME_ASSOC_HOSTNQN_LEN	256
+#define FCNVME_ASSOC_SUBNQN_LEN		256
+
+/* FCNVME_LSDESC_CREATE_ASSOC_CMD */
+struct fcnvme_lsdesc_cr_assoc_cmd {
+	__be32	desc_tag;		/* FCNVME_LSDESC_xxx */
+	__be32	desc_len;
+	__be16	ersp_ratio;
+	__be16	rsvd10;
+	__be32	rsvd12[9];
+	__be16	cntlid;
+	__be16	sqsize;
+	__be32	rsvd52;
+	u8	hostid[FCNVME_ASSOC_HOSTID_LEN];
+	u8	hostnqn[FCNVME_ASSOC_HOSTNQN_LEN];
+	u8	subnqn[FCNVME_ASSOC_SUBNQN_LEN];
+	u8	rsvd632[384];
+};
+
+/* FCNVME_LSDESC_CREATE_CONN_CMD */
+struct fcnvme_lsdesc_cr_conn_cmd {
+	__be32	desc_tag;		/* FCNVME_LSDESC_xxx */
+	__be32	desc_len;
+	__be16	ersp_ratio;
+	__be16	rsvd10;
+	__be32	rsvd12[9];
+	__be16	qid;
+	__be16	sqsize;
+	__be32  rsvd52;
+};
+
+/* Disconnect Scope Values */
+enum {
+	FCNVME_DISCONN_ASSOCIATION	= 0,
+	FCNVME_DISCONN_CONNECTION	= 1,
+};
+
+/* FCNVME_LSDESC_DISCONN_CMD */
+struct fcnvme_lsdesc_disconn_cmd {
+	__be32	desc_tag;		/* FCNVME_LSDESC_xxx */
+	__be32	desc_len;
+	u8	rsvd8[3];
+	/* note: scope is really a 1 bit field */
+	u8	scope;			/* FCNVME_DISCONN_xxx */
+	__be32	rsvd12;
+	__be64	id;
+};
+
+/* FCNVME_LSDESC_CONN_ID */
+struct fcnvme_lsdesc_conn_id {
+	__be32	desc_tag;		/* FCNVME_LSDESC_xxx */
+	__be32	desc_len;
+	__be64	connection_id;
+};
+
+/* FCNVME_LSDESC_ASSOC_ID */
+struct fcnvme_lsdesc_assoc_id {
+	__be32	desc_tag;		/* FCNVME_LSDESC_xxx */
+	__be32	desc_len;
+	__be64	association_id;
+};
+
+
+/* ********** start of Link Services ********** */
+
+
+/* FCNVME_LS_RJT */
+struct fcnvme_ls_rjt {
+	struct fcnvme_ls_rqst_w0		w0;
+	__be32					desc_list_len;
+	struct fcnvme_lsdesc_rqst		rqst;
+	struct fcnvme_lsdesc_rjt		rjt;
+};
+
+/* FCNVME_LS_ACC */
+struct fcnvme_ls_acc_hdr {
+	struct fcnvme_ls_rqst_w0		w0;
+	__be32					desc_list_len;
+	struct fcnvme_lsdesc_rqst		rqst;
+	/* Followed by cmd-specific ACC descriptors, see next definitions */
+};
+
+/* FCNVME_LS_CREATE_ASSOCIATION */
+struct fcnvme_ls_cr_assoc_rqst {
+	struct fcnvme_ls_rqst_w0		w0;
+	__be32					desc_list_len;
+	struct fcnvme_lsdesc_cr_assoc_cmd	assoc_cmd;
+};
+
+struct fcnvme_ls_cr_assoc_acc {
+	struct fcnvme_ls_acc_hdr		hdr;
+	struct fcnvme_lsdesc_assoc_id		associd;
+	struct fcnvme_lsdesc_conn_id		connectid;
+};
+
+
+/* FCNVME_LS_CREATE_CONNECTION */
+struct fcnvme_ls_cr_conn_rqst {
+	struct fcnvme_ls_rqst_w0		w0;
+	__be32					desc_list_len;
+	struct fcnvme_lsdesc_assoc_id		associd;
+	struct fcnvme_lsdesc_cr_conn_cmd	connect_cmd;
+};
+
+struct fcnvme_ls_cr_conn_acc {
+	struct fcnvme_ls_acc_hdr		hdr;
+	struct fcnvme_lsdesc_conn_id		connectid;
+};
+
+/* FCNVME_LS_DISCONNECT */
+struct fcnvme_ls_disconnect_rqst {
+	struct fcnvme_ls_rqst_w0		w0;
+	__be32					desc_list_len;
+	struct fcnvme_lsdesc_assoc_id		associd;
+	struct fcnvme_lsdesc_disconn_cmd	discon_cmd;
+};
+
+struct fcnvme_ls_disconnect_acc {
+	struct fcnvme_ls_acc_hdr		hdr;
+};
+
+
+/*
+ * Yet to be defined in FC-NVME:
+ */
+#define NVME_FC_CONNECT_TIMEOUT_SEC	2		/* 2 seconds */
+#define NVME_FC_LS_TIMEOUT_SEC		2		/* 2 seconds */
+#define NVME_FC_TGTOP_TIMEOUT_SEC	2		/* 2 seconds */
+
+
+/*
+ * FC Transport-specific error status values for NVME commands
+ *
+ * Need to incorporate into NVME Over Fabrics standard
+ *
+ * A request has been made to include transport-specific status values
+ * into the standard but it is not yet complete/defined.
+ *
+ * For now, we will use a range within the Fabric values.  The range
+ * will be 0xA0-0xBF, which is a reserved area in the fabric spec.
+ * Currently, Only the values below have been defined within that range.
+ */
+enum {
+	/* Generic FC failure - catchall */
+	NVME_SC_FC_TRANSPORT_ERROR	= 0x00A0,
+
+	/* I/O failure due to FC ABTS'd */
+	NVME_SC_FC_TRANSPORT_ABORTED	= 0x00A1,
+
+	/* FC Transport Connection in error */
+	NVME_SC_FC_NO_CONNECTION	= 0x40A2,	/* not retryable */
+
+	/* NVME Completion did not contain original CMDID */
+	NVME_SC_FC_CMDID_MISMATCH	= 0x00A3,
+
+	/* IU format error */
+	NVME_SC_FC_FORMAT		= 0x00A4,
+};
+
+
+#endif /* _NVME_FC_H */
+
-- 
2.5.0

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* [PATCH 1/7] nvme-fabrics: Add FC transport FC-NVME definitions
  2016-10-04  6:26 [PATCH 1/7] nvme-fabrics: Add FC transport FC-NVME definitions James Smart
@ 2016-10-04  7:32 ` Hannes Reinecke
  2016-10-04 13:58   ` Christoph Hellwig
  0 siblings, 1 reply; 6+ messages in thread
From: Hannes Reinecke @ 2016-10-04  7:32 UTC (permalink / raw)


On 10/04/2016 08:26 AM, James Smart wrote:
> 
> nvme-fabrics: Add FC transport FC-NVME definitions:
> - Formats for Cmd, Data, Rsp IUs
> - Formats FC-4 LS definitions
> 
> (Patch unchanged from prior posting)
> 
> Signed-off-by: James Smart <james.smart at broadcom.com>
> Acked-by: Johannes Thumshirn <jth at kernel.org>
> Acked-by: Jay Freyensee <james_p_freyensee at linux.intel.com>
> Reviewed-by: Christoph Hellwig <hch at lst.de>
> ---
>  include/linux/nvme-fc.h | 296 ++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 296 insertions(+)
>  create mode 100644 include/linux/nvme-fc.h
> 

I would have loved to use the SCSI FC headers here; eg the definitions
for FC-LS are most definitely duplicated.
But until we've sorted that one out:

Reviewed-by: Hannes Reinecke <hare at suse.com>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare at suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg
GF: J. Hawn, J. Guild, F. Imend?rffer, HRB 16746 (AG N?rnberg)

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [PATCH 1/7] nvme-fabrics: Add FC transport FC-NVME definitions
  2016-10-04  7:32 ` Hannes Reinecke
@ 2016-10-04 13:58   ` Christoph Hellwig
  2016-10-05  6:29     ` Sagi Grimberg
  2016-10-05 23:21     ` James Smart
  0 siblings, 2 replies; 6+ messages in thread
From: Christoph Hellwig @ 2016-10-04 13:58 UTC (permalink / raw)


On Tue, Oct 04, 2016@09:32:39AM +0200, Hannes Reinecke wrote:
> I would have loved to use the SCSI FC headers here; eg the definitions
> for FC-LS are most definitely duplicated.
> But until we've sorted that one out:

I remember we discussed this before, but I've forgot the outcome on
why this needed to be separate.  IIRC it was just a timing issue,
but now that we've just missed the previous merge window we should
have plenty of time to sort that out properly.  Correct me if I'm wrong.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [PATCH 1/7] nvme-fabrics: Add FC transport FC-NVME definitions
  2016-10-04 13:58   ` Christoph Hellwig
@ 2016-10-05  6:29     ` Sagi Grimberg
  2016-10-05 23:21     ` James Smart
  1 sibling, 0 replies; 6+ messages in thread
From: Sagi Grimberg @ 2016-10-05  6:29 UTC (permalink / raw)


Hay James,

I'm not sure why, but the original patchset from you
doesn't appear in my mailbox. Can you please either:
- provide a pull location and/or
- resend with cc'ing sagi at grimberg.me so I can also
provide feedback? (or simply git send me the series
and I'll include linux-nvme on relevant feedback which
will avoid spamming linux-nvme).

Sorry and thanks,
Sagi.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [PATCH 1/7] nvme-fabrics: Add FC transport FC-NVME definitions
  2016-10-04 13:58   ` Christoph Hellwig
  2016-10-05  6:29     ` Sagi Grimberg
@ 2016-10-05 23:21     ` James Smart
  2016-10-06  6:31       ` Hannes Reinecke
  1 sibling, 1 reply; 6+ messages in thread
From: James Smart @ 2016-10-05 23:21 UTC (permalink / raw)




On 10/4/2016 6:58 AM, Christoph Hellwig wrote:
> On Tue, Oct 04, 2016@09:32:39AM +0200, Hannes Reinecke wrote:
>> I would have loved to use the SCSI FC headers here; eg the definitions
>> for FC-LS are most definitely duplicated.
>> But until we've sorted that one out:
> I remember we discussed this before, but I've forgot the outcome on
> why this needed to be separate.  IIRC it was just a timing issue,
> but now that we've just missed the previous merge window we should
> have plenty of time to sort that out properly.  Correct me if I'm wrong.

I looked at the include/uapi/scsi/fc headers.

The only field that should be there is the addition of the NVME type code.

The LS's things - although they look very similar to ELS things, they 
aren't the same thing.  The LS items are specific to type code 0x28 - a 
value in the FC frame header, while ELS's are type code 0x01 in the 
frame header.  The content is specific to the type code.  True, some of 
the formats, like xx_ACC, and a little of xx_RJT are similar (on purpose 
by the fc-nvme group) - there's no real reason that they had to be, so 
actually forcing things into using the other's structures isn't a good 
idea in case things change.

After looking at it - the only thing that I was wondering is whether the 
fc-nvme definitions should be in "include/linux/nvme-fc.h" as it's 
specific to nvme fabrics or whether they should be in 
"include/uapi/scsi/fc/fc-nvme.h" - so it's in a location where all other 
fc'isms are at. Even though NVME and the scsi directory name doesn't 
seem to make sense.

-- james

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [PATCH 1/7] nvme-fabrics: Add FC transport FC-NVME definitions
  2016-10-05 23:21     ` James Smart
@ 2016-10-06  6:31       ` Hannes Reinecke
  0 siblings, 0 replies; 6+ messages in thread
From: Hannes Reinecke @ 2016-10-06  6:31 UTC (permalink / raw)


On 10/06/2016 01:21 AM, James Smart wrote:
>
>
> On 10/4/2016 6:58 AM, Christoph Hellwig wrote:
>> On Tue, Oct 04, 2016@09:32:39AM +0200, Hannes Reinecke wrote:
>>> I would have loved to use the SCSI FC headers here; eg the definitions
>>> for FC-LS are most definitely duplicated.
>>> But until we've sorted that one out:
>> I remember we discussed this before, but I've forgot the outcome on
>> why this needed to be separate.  IIRC it was just a timing issue,
>> but now that we've just missed the previous merge window we should
>> have plenty of time to sort that out properly.  Correct me if I'm wrong.
>
> I looked at the include/uapi/scsi/fc headers.
>
> The only field that should be there is the addition of the NVME type code.
>
> The LS's things - although they look very similar to ELS things, they
> aren't the same thing.  The LS items are specific to type code 0x28 - a
> value in the FC frame header, while ELS's are type code 0x01 in the
> frame header.  The content is specific to the type code.  True, some of
> the formats, like xx_ACC, and a little of xx_RJT are similar (on purpose
> by the fc-nvme group) - there's no real reason that they had to be, so
> actually forcing things into using the other's structures isn't a good
> idea in case things change.
>
> After looking at it - the only thing that I was wondering is whether the
> fc-nvme definitions should be in "include/linux/nvme-fc.h" as it's
> specific to nvme fabrics or whether they should be in
> "include/uapi/scsi/fc/fc-nvme.h" - so it's in a location where all other
> fc'isms are at. Even though NVME and the scsi directory name doesn't
> seem to make sense.
>
Ah, right. Thanks for the explanation.
I wasn't aware that the FC-LS codes are in fact type dependent.
But if they are then it indeed makes not much sense to have them merged.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare at suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg
GF: J. Hawn, J. Guild, F. Imend?rffer, HRB 16746 (AG N?rnberg)

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2016-10-06  6:31 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-10-04  6:26 [PATCH 1/7] nvme-fabrics: Add FC transport FC-NVME definitions James Smart
2016-10-04  7:32 ` Hannes Reinecke
2016-10-04 13:58   ` Christoph Hellwig
2016-10-05  6:29     ` Sagi Grimberg
2016-10-05 23:21     ` James Smart
2016-10-06  6:31       ` Hannes Reinecke

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.