* [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.