2017-02-12 21:52:32 +00:00
|
|
|
/*******************************************************************
|
|
|
|
* This file is part of the Emulex Linux Device Driver for *
|
|
|
|
* Fibre Channel Host Bus Adapters. *
|
2019-01-28 19:14:41 +00:00
|
|
|
* Copyright (C) 2017-2019 Broadcom. All Rights Reserved. The term *
|
2018-05-05 03:37:59 +00:00
|
|
|
* “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. *
|
2017-02-12 21:52:32 +00:00
|
|
|
* Copyright (C) 2004-2016 Emulex. All rights reserved. *
|
|
|
|
* EMULEX and SLI are trademarks of Emulex. *
|
2017-02-12 21:52:39 +00:00
|
|
|
* www.broadcom.com *
|
2017-02-12 21:52:32 +00:00
|
|
|
* Portions Copyright (C) 2004-2005 Christoph Hellwig *
|
|
|
|
* *
|
|
|
|
* 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. *
|
|
|
|
********************************************************************/
|
|
|
|
#include <linux/pci.h>
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/interrupt.h>
|
|
|
|
#include <linux/delay.h>
|
|
|
|
#include <asm/unaligned.h>
|
|
|
|
#include <linux/crc-t10dif.h>
|
|
|
|
#include <net/checksum.h>
|
|
|
|
|
|
|
|
#include <scsi/scsi.h>
|
|
|
|
#include <scsi/scsi_device.h>
|
|
|
|
#include <scsi/scsi_eh.h>
|
|
|
|
#include <scsi/scsi_host.h>
|
|
|
|
#include <scsi/scsi_tcq.h>
|
|
|
|
#include <scsi/scsi_transport_fc.h>
|
|
|
|
#include <scsi/fc/fc_fs.h>
|
|
|
|
|
|
|
|
#include <linux/nvme.h>
|
|
|
|
#include <linux/nvme-fc-driver.h>
|
|
|
|
#include <linux/nvme-fc.h>
|
|
|
|
#include "lpfc_version.h"
|
|
|
|
#include "lpfc_hw4.h"
|
|
|
|
#include "lpfc_hw.h"
|
|
|
|
#include "lpfc_sli.h"
|
|
|
|
#include "lpfc_sli4.h"
|
|
|
|
#include "lpfc_nl.h"
|
|
|
|
#include "lpfc_disc.h"
|
|
|
|
#include "lpfc.h"
|
|
|
|
#include "lpfc_nvme.h"
|
|
|
|
#include "lpfc_scsi.h"
|
|
|
|
#include "lpfc_logmsg.h"
|
|
|
|
#include "lpfc_crtn.h"
|
|
|
|
#include "lpfc_vport.h"
|
2017-02-12 21:52:33 +00:00
|
|
|
#include "lpfc_debugfs.h"
|
2017-02-12 21:52:32 +00:00
|
|
|
|
|
|
|
/* NVME initiator-based functions */
|
|
|
|
|
scsi: lpfc: Adapt partitioned XRI lists to efficient sharing
The XRI get/put lists were partitioned per hardware queue. However, the
adapter rarely had sufficient resources to give a large number of resources
per queue. As such, it became common for a cpu to encounter a lack of XRI
resource and request the upper io stack to retry after returning a BUSY
condition. This occurred even though other cpus were idle and not using
their resources.
Create as efficient a scheme as possible to move resources to the cpus that
need them. Each cpu maintains a small private pool which it allocates from
for io. There is a watermark that the cpu attempts to keep in the private
pool. The private pool, when empty, pulls from a global pool from the
cpu. When the cpu's global pool is empty it will pull from other cpu's
global pool. As there many cpu global pools (1 per cpu or hardware queue
count) and as each cpu selects what cpu to pull from at different rates and
at different times, it creates a radomizing effect that minimizes the
number of cpu's that will contend with each other when the steal XRI's from
another cpu's global pool.
On io completion, a cpu will push the XRI back on to its private pool. A
watermark level is maintained for the private pool such that when it is
exceeded it will move XRI's to the CPU global pool so that other cpu's may
allocate them.
On NVME, as heartbeat commands are critical to get placed on the wire, a
single expedite pool is maintained. When a heartbeat is to be sent, it will
allocate an XRI from the expedite pool rather than the normal cpu
private/global pools. On any io completion, if a reduction in the expedite
pools is seen, it will be replenished before the XRI is placed on the cpu
private pool.
Statistics are added to aid understanding the XRI levels on each cpu and
their behaviors.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-01-28 19:14:28 +00:00
|
|
|
static struct lpfc_io_buf *
|
2017-12-09 01:18:03 +00:00
|
|
|
lpfc_get_nvme_buf(struct lpfc_hba *phba, struct lpfc_nodelist *ndlp,
|
2019-01-28 19:14:22 +00:00
|
|
|
int idx, int expedite);
|
2017-02-12 21:52:32 +00:00
|
|
|
|
|
|
|
static void
|
scsi: lpfc: Adapt partitioned XRI lists to efficient sharing
The XRI get/put lists were partitioned per hardware queue. However, the
adapter rarely had sufficient resources to give a large number of resources
per queue. As such, it became common for a cpu to encounter a lack of XRI
resource and request the upper io stack to retry after returning a BUSY
condition. This occurred even though other cpus were idle and not using
their resources.
Create as efficient a scheme as possible to move resources to the cpus that
need them. Each cpu maintains a small private pool which it allocates from
for io. There is a watermark that the cpu attempts to keep in the private
pool. The private pool, when empty, pulls from a global pool from the
cpu. When the cpu's global pool is empty it will pull from other cpu's
global pool. As there many cpu global pools (1 per cpu or hardware queue
count) and as each cpu selects what cpu to pull from at different rates and
at different times, it creates a radomizing effect that minimizes the
number of cpu's that will contend with each other when the steal XRI's from
another cpu's global pool.
On io completion, a cpu will push the XRI back on to its private pool. A
watermark level is maintained for the private pool such that when it is
exceeded it will move XRI's to the CPU global pool so that other cpu's may
allocate them.
On NVME, as heartbeat commands are critical to get placed on the wire, a
single expedite pool is maintained. When a heartbeat is to be sent, it will
allocate an XRI from the expedite pool rather than the normal cpu
private/global pools. On any io completion, if a reduction in the expedite
pools is seen, it will be replenished before the XRI is placed on the cpu
private pool.
Statistics are added to aid understanding the XRI levels on each cpu and
their behaviors.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-01-28 19:14:28 +00:00
|
|
|
lpfc_release_nvme_buf(struct lpfc_hba *, struct lpfc_io_buf *);
|
2017-02-12 21:52:32 +00:00
|
|
|
|
2017-11-21 00:00:43 +00:00
|
|
|
static struct nvme_fc_port_template lpfc_nvme_template;
|
2017-02-12 21:52:32 +00:00
|
|
|
|
2018-03-13 12:08:49 +00:00
|
|
|
static union lpfc_wqe128 lpfc_iread_cmd_template;
|
|
|
|
static union lpfc_wqe128 lpfc_iwrite_cmd_template;
|
|
|
|
static union lpfc_wqe128 lpfc_icmnd_cmd_template;
|
2018-03-05 20:04:04 +00:00
|
|
|
|
|
|
|
/* Setup WQE templates for NVME IOs */
|
|
|
|
void
|
2018-03-13 12:08:49 +00:00
|
|
|
lpfc_nvme_cmd_template(void)
|
2018-03-05 20:04:04 +00:00
|
|
|
{
|
|
|
|
union lpfc_wqe128 *wqe;
|
|
|
|
|
|
|
|
/* IREAD template */
|
|
|
|
wqe = &lpfc_iread_cmd_template;
|
|
|
|
memset(wqe, 0, sizeof(union lpfc_wqe128));
|
|
|
|
|
|
|
|
/* Word 0, 1, 2 - BDE is variable */
|
|
|
|
|
|
|
|
/* Word 3 - cmd_buff_len, payload_offset_len is zero */
|
|
|
|
|
|
|
|
/* Word 4 - total_xfer_len is variable */
|
|
|
|
|
|
|
|
/* Word 5 - is zero */
|
|
|
|
|
|
|
|
/* Word 6 - ctxt_tag, xri_tag is variable */
|
|
|
|
|
|
|
|
/* Word 7 */
|
|
|
|
bf_set(wqe_cmnd, &wqe->fcp_iread.wqe_com, CMD_FCP_IREAD64_WQE);
|
|
|
|
bf_set(wqe_pu, &wqe->fcp_iread.wqe_com, PARM_READ_CHECK);
|
|
|
|
bf_set(wqe_class, &wqe->fcp_iread.wqe_com, CLASS3);
|
|
|
|
bf_set(wqe_ct, &wqe->fcp_iread.wqe_com, SLI4_CT_RPI);
|
|
|
|
|
|
|
|
/* Word 8 - abort_tag is variable */
|
|
|
|
|
|
|
|
/* Word 9 - reqtag is variable */
|
|
|
|
|
|
|
|
/* Word 10 - dbde, wqes is variable */
|
|
|
|
bf_set(wqe_qosd, &wqe->fcp_iread.wqe_com, 0);
|
|
|
|
bf_set(wqe_nvme, &wqe->fcp_iread.wqe_com, 1);
|
|
|
|
bf_set(wqe_iod, &wqe->fcp_iread.wqe_com, LPFC_WQE_IOD_READ);
|
|
|
|
bf_set(wqe_lenloc, &wqe->fcp_iread.wqe_com, LPFC_WQE_LENLOC_WORD4);
|
|
|
|
bf_set(wqe_dbde, &wqe->fcp_iread.wqe_com, 0);
|
|
|
|
bf_set(wqe_wqes, &wqe->fcp_iread.wqe_com, 1);
|
|
|
|
|
|
|
|
/* Word 11 - pbde is variable */
|
|
|
|
bf_set(wqe_cmd_type, &wqe->fcp_iread.wqe_com, NVME_READ_CMD);
|
|
|
|
bf_set(wqe_cqid, &wqe->fcp_iread.wqe_com, LPFC_WQE_CQ_ID_DEFAULT);
|
|
|
|
bf_set(wqe_pbde, &wqe->fcp_iread.wqe_com, 1);
|
|
|
|
|
|
|
|
/* Word 12 - is zero */
|
|
|
|
|
|
|
|
/* Word 13, 14, 15 - PBDE is variable */
|
|
|
|
|
|
|
|
/* IWRITE template */
|
|
|
|
wqe = &lpfc_iwrite_cmd_template;
|
|
|
|
memset(wqe, 0, sizeof(union lpfc_wqe128));
|
|
|
|
|
|
|
|
/* Word 0, 1, 2 - BDE is variable */
|
|
|
|
|
|
|
|
/* Word 3 - cmd_buff_len, payload_offset_len is zero */
|
|
|
|
|
|
|
|
/* Word 4 - total_xfer_len is variable */
|
|
|
|
|
|
|
|
/* Word 5 - initial_xfer_len is variable */
|
|
|
|
|
|
|
|
/* Word 6 - ctxt_tag, xri_tag is variable */
|
|
|
|
|
|
|
|
/* Word 7 */
|
|
|
|
bf_set(wqe_cmnd, &wqe->fcp_iwrite.wqe_com, CMD_FCP_IWRITE64_WQE);
|
|
|
|
bf_set(wqe_pu, &wqe->fcp_iwrite.wqe_com, PARM_READ_CHECK);
|
|
|
|
bf_set(wqe_class, &wqe->fcp_iwrite.wqe_com, CLASS3);
|
|
|
|
bf_set(wqe_ct, &wqe->fcp_iwrite.wqe_com, SLI4_CT_RPI);
|
|
|
|
|
|
|
|
/* Word 8 - abort_tag is variable */
|
|
|
|
|
|
|
|
/* Word 9 - reqtag is variable */
|
|
|
|
|
|
|
|
/* Word 10 - dbde, wqes is variable */
|
|
|
|
bf_set(wqe_qosd, &wqe->fcp_iwrite.wqe_com, 0);
|
|
|
|
bf_set(wqe_nvme, &wqe->fcp_iwrite.wqe_com, 1);
|
|
|
|
bf_set(wqe_iod, &wqe->fcp_iwrite.wqe_com, LPFC_WQE_IOD_WRITE);
|
|
|
|
bf_set(wqe_lenloc, &wqe->fcp_iwrite.wqe_com, LPFC_WQE_LENLOC_WORD4);
|
|
|
|
bf_set(wqe_dbde, &wqe->fcp_iwrite.wqe_com, 0);
|
|
|
|
bf_set(wqe_wqes, &wqe->fcp_iwrite.wqe_com, 1);
|
|
|
|
|
|
|
|
/* Word 11 - pbde is variable */
|
|
|
|
bf_set(wqe_cmd_type, &wqe->fcp_iwrite.wqe_com, NVME_WRITE_CMD);
|
|
|
|
bf_set(wqe_cqid, &wqe->fcp_iwrite.wqe_com, LPFC_WQE_CQ_ID_DEFAULT);
|
|
|
|
bf_set(wqe_pbde, &wqe->fcp_iwrite.wqe_com, 1);
|
|
|
|
|
|
|
|
/* Word 12 - is zero */
|
|
|
|
|
|
|
|
/* Word 13, 14, 15 - PBDE is variable */
|
|
|
|
|
|
|
|
/* ICMND template */
|
|
|
|
wqe = &lpfc_icmnd_cmd_template;
|
|
|
|
memset(wqe, 0, sizeof(union lpfc_wqe128));
|
|
|
|
|
|
|
|
/* Word 0, 1, 2 - BDE is variable */
|
|
|
|
|
|
|
|
/* Word 3 - payload_offset_len is variable */
|
|
|
|
|
|
|
|
/* Word 4, 5 - is zero */
|
|
|
|
|
|
|
|
/* Word 6 - ctxt_tag, xri_tag is variable */
|
|
|
|
|
|
|
|
/* Word 7 */
|
|
|
|
bf_set(wqe_cmnd, &wqe->fcp_icmd.wqe_com, CMD_FCP_ICMND64_WQE);
|
|
|
|
bf_set(wqe_pu, &wqe->fcp_icmd.wqe_com, 0);
|
|
|
|
bf_set(wqe_class, &wqe->fcp_icmd.wqe_com, CLASS3);
|
|
|
|
bf_set(wqe_ct, &wqe->fcp_icmd.wqe_com, SLI4_CT_RPI);
|
|
|
|
|
|
|
|
/* Word 8 - abort_tag is variable */
|
|
|
|
|
|
|
|
/* Word 9 - reqtag is variable */
|
|
|
|
|
|
|
|
/* Word 10 - dbde, wqes is variable */
|
|
|
|
bf_set(wqe_qosd, &wqe->fcp_icmd.wqe_com, 1);
|
|
|
|
bf_set(wqe_nvme, &wqe->fcp_icmd.wqe_com, 1);
|
|
|
|
bf_set(wqe_iod, &wqe->fcp_icmd.wqe_com, LPFC_WQE_IOD_NONE);
|
|
|
|
bf_set(wqe_lenloc, &wqe->fcp_icmd.wqe_com, LPFC_WQE_LENLOC_NONE);
|
|
|
|
bf_set(wqe_dbde, &wqe->fcp_icmd.wqe_com, 0);
|
|
|
|
bf_set(wqe_wqes, &wqe->fcp_icmd.wqe_com, 1);
|
|
|
|
|
|
|
|
/* Word 11 */
|
|
|
|
bf_set(wqe_cmd_type, &wqe->fcp_icmd.wqe_com, FCP_COMMAND);
|
|
|
|
bf_set(wqe_cqid, &wqe->fcp_icmd.wqe_com, LPFC_WQE_CQ_ID_DEFAULT);
|
|
|
|
bf_set(wqe_pbde, &wqe->fcp_icmd.wqe_com, 0);
|
|
|
|
|
|
|
|
/* Word 12, 13, 14, 15 - is zero */
|
|
|
|
}
|
|
|
|
|
2019-09-22 03:58:56 +00:00
|
|
|
/**
|
|
|
|
* lpfc_nvme_prep_abort_wqe - set up 'abort' work queue entry.
|
|
|
|
* @pwqeq: Pointer to command iocb.
|
|
|
|
* @xritag: Tag that uniqely identifies the local exchange resource.
|
|
|
|
* @opt: Option bits -
|
|
|
|
* bit 0 = inhibit sending abts on the link
|
|
|
|
*
|
|
|
|
* This function is called with hbalock held.
|
|
|
|
**/
|
|
|
|
void
|
|
|
|
lpfc_nvme_prep_abort_wqe(struct lpfc_iocbq *pwqeq, u16 xritag, u8 opt)
|
|
|
|
{
|
|
|
|
union lpfc_wqe128 *wqe = &pwqeq->wqe;
|
|
|
|
|
|
|
|
/* WQEs are reused. Clear stale data and set key fields to
|
|
|
|
* zero like ia, iaab, iaar, xri_tag, and ctxt_tag.
|
|
|
|
*/
|
|
|
|
memset(wqe, 0, sizeof(*wqe));
|
|
|
|
|
|
|
|
if (opt & INHIBIT_ABORT)
|
|
|
|
bf_set(abort_cmd_ia, &wqe->abort_cmd, 1);
|
|
|
|
/* Abort specified xri tag, with the mask deliberately zeroed */
|
|
|
|
bf_set(abort_cmd_criteria, &wqe->abort_cmd, T_XRI_TAG);
|
|
|
|
|
|
|
|
bf_set(wqe_cmnd, &wqe->abort_cmd.wqe_com, CMD_ABORT_XRI_CX);
|
|
|
|
|
|
|
|
/* Abort the IO associated with this outstanding exchange ID. */
|
|
|
|
wqe->abort_cmd.wqe_com.abort_tag = xritag;
|
|
|
|
|
|
|
|
/* iotag for the wqe completion. */
|
|
|
|
bf_set(wqe_reqtag, &wqe->abort_cmd.wqe_com, pwqeq->iotag);
|
|
|
|
|
|
|
|
bf_set(wqe_qosd, &wqe->abort_cmd.wqe_com, 1);
|
|
|
|
bf_set(wqe_lenloc, &wqe->abort_cmd.wqe_com, LPFC_WQE_LENLOC_NONE);
|
|
|
|
|
|
|
|
bf_set(wqe_cmd_type, &wqe->abort_cmd.wqe_com, OTHER_COMMAND);
|
|
|
|
bf_set(wqe_wqec, &wqe->abort_cmd.wqe_com, 1);
|
|
|
|
bf_set(wqe_cqid, &wqe->abort_cmd.wqe_com, LPFC_WQE_CQ_ID_DEFAULT);
|
|
|
|
}
|
|
|
|
|
2017-02-12 21:52:32 +00:00
|
|
|
/**
|
|
|
|
* lpfc_nvme_create_queue -
|
|
|
|
* @lpfc_pnvme: Pointer to the driver's nvme instance data
|
|
|
|
* @qidx: An cpu index used to affinitize IO queues and MSIX vectors.
|
|
|
|
* @handle: An opaque driver handle used in follow-up calls.
|
|
|
|
*
|
|
|
|
* Driver registers this routine to preallocate and initialize any
|
|
|
|
* internal data structures to bind the @qidx to its internal IO queues.
|
|
|
|
* A hardware queue maps (qidx) to a specific driver MSI-X vector/EQ/CQ/WQ.
|
|
|
|
*
|
|
|
|
* Return value :
|
|
|
|
* 0 - Success
|
|
|
|
* -EINVAL - Unsupported input value.
|
|
|
|
* -ENOMEM - Could not alloc necessary memory
|
|
|
|
**/
|
|
|
|
static int
|
|
|
|
lpfc_nvme_create_queue(struct nvme_fc_local_port *pnvme_lport,
|
|
|
|
unsigned int qidx, u16 qsize,
|
|
|
|
void **handle)
|
|
|
|
{
|
|
|
|
struct lpfc_nvme_lport *lport;
|
|
|
|
struct lpfc_vport *vport;
|
|
|
|
struct lpfc_nvme_qhandle *qhandle;
|
|
|
|
char *str;
|
|
|
|
|
2017-11-21 00:00:42 +00:00
|
|
|
if (!pnvme_lport->private)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2017-02-12 21:52:32 +00:00
|
|
|
lport = (struct lpfc_nvme_lport *)pnvme_lport->private;
|
|
|
|
vport = lport->vport;
|
|
|
|
qhandle = kzalloc(sizeof(struct lpfc_nvme_qhandle), GFP_KERNEL);
|
|
|
|
if (qhandle == NULL)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2019-03-28 18:06:22 +00:00
|
|
|
qhandle->cpu_id = raw_smp_processor_id();
|
2017-02-12 21:52:32 +00:00
|
|
|
qhandle->qidx = qidx;
|
|
|
|
/*
|
|
|
|
* NVME qidx == 0 is the admin queue, so both admin queue
|
|
|
|
* and first IO queue will use MSI-X vector and associated
|
|
|
|
* EQ/CQ/WQ at index 0. After that they are sequentially assigned.
|
|
|
|
*/
|
|
|
|
if (qidx) {
|
|
|
|
str = "IO "; /* IO queue */
|
|
|
|
qhandle->index = ((qidx - 1) %
|
2019-01-28 19:14:31 +00:00
|
|
|
lpfc_nvme_template.max_hw_queues);
|
2017-02-12 21:52:32 +00:00
|
|
|
} else {
|
|
|
|
str = "ADM"; /* Admin queue */
|
|
|
|
qhandle->index = qidx;
|
|
|
|
}
|
|
|
|
|
2017-08-23 23:55:46 +00:00
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME,
|
2017-02-12 21:52:32 +00:00
|
|
|
"6073 Binding %s HdwQueue %d (cpu %d) to "
|
2019-08-14 23:57:06 +00:00
|
|
|
"hdw_queue %d qhandle x%px\n", str,
|
2017-02-12 21:52:32 +00:00
|
|
|
qidx, qhandle->cpu_id, qhandle->index, qhandle);
|
|
|
|
*handle = (void *)qhandle;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* lpfc_nvme_delete_queue -
|
|
|
|
* @lpfc_pnvme: Pointer to the driver's nvme instance data
|
|
|
|
* @qidx: An cpu index used to affinitize IO queues and MSIX vectors.
|
|
|
|
* @handle: An opaque driver handle from lpfc_nvme_create_queue
|
|
|
|
*
|
|
|
|
* Driver registers this routine to free
|
|
|
|
* any internal data structures to bind the @qidx to its internal
|
|
|
|
* IO queues.
|
|
|
|
*
|
|
|
|
* Return value :
|
|
|
|
* 0 - Success
|
|
|
|
* TODO: What are the failure codes.
|
|
|
|
**/
|
|
|
|
static void
|
|
|
|
lpfc_nvme_delete_queue(struct nvme_fc_local_port *pnvme_lport,
|
|
|
|
unsigned int qidx,
|
|
|
|
void *handle)
|
|
|
|
{
|
|
|
|
struct lpfc_nvme_lport *lport;
|
|
|
|
struct lpfc_vport *vport;
|
|
|
|
|
2017-11-21 00:00:42 +00:00
|
|
|
if (!pnvme_lport->private)
|
|
|
|
return;
|
|
|
|
|
2017-02-12 21:52:32 +00:00
|
|
|
lport = (struct lpfc_nvme_lport *)pnvme_lport->private;
|
|
|
|
vport = lport->vport;
|
|
|
|
|
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME,
|
2019-08-14 23:57:06 +00:00
|
|
|
"6001 ENTER. lpfc_pnvme x%px, qidx x%x qhandle x%px\n",
|
2017-02-12 21:52:32 +00:00
|
|
|
lport, qidx, handle);
|
|
|
|
kfree(handle);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
lpfc_nvme_localport_delete(struct nvme_fc_local_port *localport)
|
|
|
|
{
|
|
|
|
struct lpfc_nvme_lport *lport = localport->private;
|
|
|
|
|
2017-11-21 00:00:40 +00:00
|
|
|
lpfc_printf_vlog(lport->vport, KERN_INFO, LOG_NVME,
|
2019-08-14 23:57:06 +00:00
|
|
|
"6173 localport x%px delete complete\n",
|
2017-11-21 00:00:40 +00:00
|
|
|
lport);
|
|
|
|
|
2017-02-12 21:52:32 +00:00
|
|
|
/* release any threads waiting for the unreg to complete */
|
2019-01-17 16:14:44 +00:00
|
|
|
if (lport->vport->localport)
|
|
|
|
complete(lport->lport_unreg_cmp);
|
2017-02-12 21:52:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* lpfc_nvme_remoteport_delete
|
|
|
|
*
|
|
|
|
* @remoteport: Pointer to an nvme transport remoteport instance.
|
|
|
|
*
|
|
|
|
* This is a template downcall. NVME transport calls this function
|
|
|
|
* when it has completed the unregistration of a previously
|
|
|
|
* registered remoteport.
|
|
|
|
*
|
|
|
|
* Return value :
|
|
|
|
* None
|
|
|
|
*/
|
2019-03-28 18:06:16 +00:00
|
|
|
static void
|
2017-02-12 21:52:32 +00:00
|
|
|
lpfc_nvme_remoteport_delete(struct nvme_fc_remote_port *remoteport)
|
|
|
|
{
|
|
|
|
struct lpfc_nvme_rport *rport = remoteport->private;
|
|
|
|
struct lpfc_vport *vport;
|
|
|
|
struct lpfc_nodelist *ndlp;
|
|
|
|
|
|
|
|
ndlp = rport->ndlp;
|
|
|
|
if (!ndlp)
|
|
|
|
goto rport_err;
|
|
|
|
|
|
|
|
vport = ndlp->vport;
|
|
|
|
if (!vport)
|
|
|
|
goto rport_err;
|
|
|
|
|
|
|
|
/* Remove this rport from the lport's list - memory is owned by the
|
|
|
|
* transport. Remove the ndlp reference for the NVME transport before
|
2017-06-02 04:06:55 +00:00
|
|
|
* calling state machine to remove the node.
|
2017-02-12 21:52:32 +00:00
|
|
|
*/
|
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_DISC,
|
2019-08-14 23:57:06 +00:00
|
|
|
"6146 remoteport delete of remoteport x%px\n",
|
2017-02-12 21:52:32 +00:00
|
|
|
remoteport);
|
2017-12-09 01:18:09 +00:00
|
|
|
spin_lock_irq(&vport->phba->hbalock);
|
2018-04-09 21:24:30 +00:00
|
|
|
|
|
|
|
/* The register rebind might have occurred before the delete
|
|
|
|
* downcall. Guard against this race.
|
|
|
|
*/
|
|
|
|
if (ndlp->upcall_flags & NLP_WAIT_FOR_UNREG) {
|
|
|
|
ndlp->nrport = NULL;
|
|
|
|
ndlp->upcall_flags &= ~NLP_WAIT_FOR_UNREG;
|
2020-03-22 18:12:59 +00:00
|
|
|
spin_unlock_irq(&vport->phba->hbalock);
|
2017-12-09 01:18:09 +00:00
|
|
|
|
2020-03-22 18:12:59 +00:00
|
|
|
/* Remove original register reference. The host transport
|
|
|
|
* won't reference this rport/remoteport any further.
|
|
|
|
*/
|
|
|
|
lpfc_nlp_put(ndlp);
|
|
|
|
} else {
|
|
|
|
spin_unlock_irq(&vport->phba->hbalock);
|
|
|
|
}
|
2017-02-12 21:52:32 +00:00
|
|
|
|
|
|
|
rport_err:
|
2017-12-09 01:18:09 +00:00
|
|
|
return;
|
2017-02-12 21:52:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
lpfc_nvme_cmpl_gen_req(struct lpfc_hba *phba, struct lpfc_iocbq *cmdwqe,
|
|
|
|
struct lpfc_wcqe_complete *wcqe)
|
|
|
|
{
|
|
|
|
struct lpfc_vport *vport = cmdwqe->vport;
|
2017-12-09 01:18:10 +00:00
|
|
|
struct lpfc_nvme_lport *lport;
|
2017-02-12 21:52:32 +00:00
|
|
|
uint32_t status;
|
|
|
|
struct nvmefc_ls_req *pnvme_lsreq;
|
|
|
|
struct lpfc_dmabuf *buf_ptr;
|
|
|
|
struct lpfc_nodelist *ndlp;
|
|
|
|
|
|
|
|
pnvme_lsreq = (struct nvmefc_ls_req *)cmdwqe->context2;
|
|
|
|
status = bf_get(lpfc_wcqe_c_status, wcqe) & LPFC_IOCB_STATUS_MASK;
|
2018-04-09 21:24:23 +00:00
|
|
|
|
2018-04-09 21:24:31 +00:00
|
|
|
if (vport->localport) {
|
|
|
|
lport = (struct lpfc_nvme_lport *)vport->localport->private;
|
|
|
|
if (lport) {
|
|
|
|
atomic_inc(&lport->fc4NvmeLsCmpls);
|
|
|
|
if (status) {
|
|
|
|
if (bf_get(lpfc_wcqe_c_xb, wcqe))
|
|
|
|
atomic_inc(&lport->cmpl_ls_xb);
|
|
|
|
atomic_inc(&lport->cmpl_ls_err);
|
|
|
|
}
|
2018-04-09 21:24:23 +00:00
|
|
|
}
|
2017-12-09 01:18:10 +00:00
|
|
|
}
|
|
|
|
|
2017-02-12 21:52:32 +00:00
|
|
|
ndlp = (struct lpfc_nodelist *)cmdwqe->context1;
|
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_DISC,
|
|
|
|
"6047 nvme cmpl Enter "
|
2019-08-14 23:57:06 +00:00
|
|
|
"Data %px DID %x Xri: %x status %x reason x%x "
|
|
|
|
"cmd:x%px lsreg:x%px bmp:x%px ndlp:x%px\n",
|
2017-02-12 21:52:32 +00:00
|
|
|
pnvme_lsreq, ndlp ? ndlp->nlp_DID : 0,
|
|
|
|
cmdwqe->sli4_xritag, status,
|
scsi: lpfc: Fix nonrecovery of NVME controller after cable swap.
In a test that is doing large numbers of cable swaps on the target, the
nvme controllers wouldn't reconnect.
During the cable swaps, the targets n_port_id would change. This
information was passed to the nvme-fc transport, in the new remoteport
registration. However, the nvme-fc transport didn't update the n_port_id
value in the remoteport struct when it reused an existing structure.
Later, when a new association was attempted on the remoteport, the
driver's NVME LS routine would use the stale n_port_id from the
remoteport struct to address the LS. As the device is no longer at that
address, the LS would go into never never land.
Separately, the nvme-fc transport will be corrected to update the
n_port_id value on a re-registration.
However, for now, there's no reason to use the transports values. The
private pointer points to the drivers node structure and the node
structure is up to date. Therefore, revise the LS routine to use the
drivers data structures for the LS. Augmented the debug message for
better debugging in the future.
Also removed a duplicate if check that seems to have slipped in.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-01-30 23:59:01 +00:00
|
|
|
(wcqe->parameter & 0xffff),
|
2017-02-12 21:52:32 +00:00
|
|
|
cmdwqe, pnvme_lsreq, cmdwqe->context3, ndlp);
|
|
|
|
|
2017-02-12 21:52:33 +00:00
|
|
|
lpfc_nvmeio_data(phba, "NVME LS CMPL: xri x%x stat x%x parm x%x\n",
|
|
|
|
cmdwqe->sli4_xritag, status, wcqe->parameter);
|
|
|
|
|
2017-02-12 21:52:32 +00:00
|
|
|
if (cmdwqe->context3) {
|
|
|
|
buf_ptr = (struct lpfc_dmabuf *)cmdwqe->context3;
|
|
|
|
lpfc_mbuf_free(phba, buf_ptr->virt, buf_ptr->phys);
|
|
|
|
kfree(buf_ptr);
|
|
|
|
cmdwqe->context3 = NULL;
|
|
|
|
}
|
|
|
|
if (pnvme_lsreq->done)
|
|
|
|
pnvme_lsreq->done(pnvme_lsreq, status);
|
|
|
|
else
|
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_NVME_DISC,
|
|
|
|
"6046 nvme cmpl without done call back? "
|
2019-08-14 23:57:06 +00:00
|
|
|
"Data %px DID %x Xri: %x status %x\n",
|
2017-02-12 21:52:32 +00:00
|
|
|
pnvme_lsreq, ndlp ? ndlp->nlp_DID : 0,
|
|
|
|
cmdwqe->sli4_xritag, status);
|
|
|
|
if (ndlp) {
|
|
|
|
lpfc_nlp_put(ndlp);
|
|
|
|
cmdwqe->context1 = NULL;
|
|
|
|
}
|
|
|
|
lpfc_sli_release_iocbq(phba, cmdwqe);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
lpfc_nvme_gen_req(struct lpfc_vport *vport, struct lpfc_dmabuf *bmp,
|
|
|
|
struct lpfc_dmabuf *inp,
|
2018-03-05 20:04:03 +00:00
|
|
|
struct nvmefc_ls_req *pnvme_lsreq,
|
|
|
|
void (*cmpl)(struct lpfc_hba *, struct lpfc_iocbq *,
|
|
|
|
struct lpfc_wcqe_complete *),
|
|
|
|
struct lpfc_nodelist *ndlp, uint32_t num_entry,
|
|
|
|
uint32_t tmo, uint8_t retry)
|
2017-02-12 21:52:32 +00:00
|
|
|
{
|
2018-03-05 20:04:03 +00:00
|
|
|
struct lpfc_hba *phba = vport->phba;
|
|
|
|
union lpfc_wqe128 *wqe;
|
2017-02-12 21:52:32 +00:00
|
|
|
struct lpfc_iocbq *genwqe;
|
|
|
|
struct ulp_bde64 *bpl;
|
|
|
|
struct ulp_bde64 bde;
|
|
|
|
int i, rc, xmit_len, first_len;
|
|
|
|
|
|
|
|
/* Allocate buffer for command WQE */
|
|
|
|
genwqe = lpfc_sli_get_iocbq(phba);
|
|
|
|
if (genwqe == NULL)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
wqe = &genwqe->wqe;
|
2019-08-14 23:57:04 +00:00
|
|
|
/* Initialize only 64 bytes */
|
2017-02-12 21:52:32 +00:00
|
|
|
memset(wqe, 0, sizeof(union lpfc_wqe));
|
|
|
|
|
|
|
|
genwqe->context3 = (uint8_t *)bmp;
|
|
|
|
genwqe->iocb_flag |= LPFC_IO_NVME_LS;
|
|
|
|
|
|
|
|
/* Save for completion so we can release these resources */
|
|
|
|
genwqe->context1 = lpfc_nlp_get(ndlp);
|
|
|
|
genwqe->context2 = (uint8_t *)pnvme_lsreq;
|
|
|
|
/* Fill in payload, bp points to frame payload */
|
|
|
|
|
|
|
|
if (!tmo)
|
|
|
|
/* FC spec states we need 3 * ratov for CT requests */
|
|
|
|
tmo = (3 * phba->fc_ratov);
|
|
|
|
|
|
|
|
/* For this command calculate the xmit length of the request bde. */
|
|
|
|
xmit_len = 0;
|
|
|
|
first_len = 0;
|
|
|
|
bpl = (struct ulp_bde64 *)bmp->virt;
|
|
|
|
for (i = 0; i < num_entry; i++) {
|
|
|
|
bde.tus.w = bpl[i].tus.w;
|
|
|
|
if (bde.tus.f.bdeFlags != BUFF_TYPE_BDE_64)
|
|
|
|
break;
|
|
|
|
xmit_len += bde.tus.f.bdeSize;
|
|
|
|
if (i == 0)
|
|
|
|
first_len = xmit_len;
|
|
|
|
}
|
|
|
|
|
|
|
|
genwqe->rsvd2 = num_entry;
|
|
|
|
genwqe->hba_wqidx = 0;
|
|
|
|
|
|
|
|
/* Words 0 - 2 */
|
|
|
|
wqe->generic.bde.tus.f.bdeFlags = BUFF_TYPE_BDE_64;
|
|
|
|
wqe->generic.bde.tus.f.bdeSize = first_len;
|
|
|
|
wqe->generic.bde.addrLow = bpl[0].addrLow;
|
|
|
|
wqe->generic.bde.addrHigh = bpl[0].addrHigh;
|
|
|
|
|
|
|
|
/* Word 3 */
|
|
|
|
wqe->gen_req.request_payload_len = first_len;
|
|
|
|
|
|
|
|
/* Word 4 */
|
|
|
|
|
|
|
|
/* Word 5 */
|
|
|
|
bf_set(wqe_dfctl, &wqe->gen_req.wge_ctl, 0);
|
|
|
|
bf_set(wqe_si, &wqe->gen_req.wge_ctl, 1);
|
|
|
|
bf_set(wqe_la, &wqe->gen_req.wge_ctl, 1);
|
2017-03-04 17:30:26 +00:00
|
|
|
bf_set(wqe_rctl, &wqe->gen_req.wge_ctl, FC_RCTL_ELS4_REQ);
|
2017-02-12 21:52:32 +00:00
|
|
|
bf_set(wqe_type, &wqe->gen_req.wge_ctl, FC_TYPE_NVME);
|
|
|
|
|
|
|
|
/* Word 6 */
|
|
|
|
bf_set(wqe_ctxt_tag, &wqe->gen_req.wqe_com,
|
|
|
|
phba->sli4_hba.rpi_ids[ndlp->nlp_rpi]);
|
|
|
|
bf_set(wqe_xri_tag, &wqe->gen_req.wqe_com, genwqe->sli4_xritag);
|
|
|
|
|
|
|
|
/* Word 7 */
|
|
|
|
bf_set(wqe_tmo, &wqe->gen_req.wqe_com, (vport->phba->fc_ratov-1));
|
|
|
|
bf_set(wqe_class, &wqe->gen_req.wqe_com, CLASS3);
|
|
|
|
bf_set(wqe_cmnd, &wqe->gen_req.wqe_com, CMD_GEN_REQUEST64_WQE);
|
|
|
|
bf_set(wqe_ct, &wqe->gen_req.wqe_com, SLI4_CT_RPI);
|
|
|
|
|
|
|
|
/* Word 8 */
|
|
|
|
wqe->gen_req.wqe_com.abort_tag = genwqe->iotag;
|
|
|
|
|
|
|
|
/* Word 9 */
|
|
|
|
bf_set(wqe_reqtag, &wqe->gen_req.wqe_com, genwqe->iotag);
|
|
|
|
|
|
|
|
/* Word 10 */
|
|
|
|
bf_set(wqe_dbde, &wqe->gen_req.wqe_com, 1);
|
|
|
|
bf_set(wqe_iod, &wqe->gen_req.wqe_com, LPFC_WQE_IOD_READ);
|
|
|
|
bf_set(wqe_qosd, &wqe->gen_req.wqe_com, 1);
|
|
|
|
bf_set(wqe_lenloc, &wqe->gen_req.wqe_com, LPFC_WQE_LENLOC_NONE);
|
|
|
|
bf_set(wqe_ebde_cnt, &wqe->gen_req.wqe_com, 0);
|
|
|
|
|
|
|
|
/* Word 11 */
|
|
|
|
bf_set(wqe_cqid, &wqe->gen_req.wqe_com, LPFC_WQE_CQ_ID_DEFAULT);
|
|
|
|
bf_set(wqe_cmd_type, &wqe->gen_req.wqe_com, OTHER_COMMAND);
|
|
|
|
|
|
|
|
|
|
|
|
/* Issue GEN REQ WQE for NPORT <did> */
|
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_ELS,
|
|
|
|
"6050 Issue GEN REQ WQE to NPORT x%x "
|
2019-08-14 23:57:06 +00:00
|
|
|
"Data: x%x x%x wq:x%px lsreq:x%px bmp:x%px "
|
|
|
|
"xmit:%d 1st:%d\n",
|
2017-02-12 21:52:32 +00:00
|
|
|
ndlp->nlp_DID, genwqe->iotag,
|
|
|
|
vport->port_state,
|
|
|
|
genwqe, pnvme_lsreq, bmp, xmit_len, first_len);
|
|
|
|
genwqe->wqe_cmpl = cmpl;
|
|
|
|
genwqe->iocb_cmpl = NULL;
|
|
|
|
genwqe->drvrTimeout = tmo + LPFC_DRVR_TIMEOUT;
|
|
|
|
genwqe->vport = vport;
|
|
|
|
genwqe->retry = retry;
|
|
|
|
|
2017-02-12 21:52:33 +00:00
|
|
|
lpfc_nvmeio_data(phba, "NVME LS XMIT: xri x%x iotag x%x to x%06x\n",
|
|
|
|
genwqe->sli4_xritag, genwqe->iotag, ndlp->nlp_DID);
|
|
|
|
|
2019-01-28 19:14:26 +00:00
|
|
|
rc = lpfc_sli4_issue_wqe(phba, &phba->sli4_hba.hdwq[0], genwqe);
|
2017-08-23 23:55:35 +00:00
|
|
|
if (rc) {
|
2017-02-12 21:52:32 +00:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_ELS,
|
|
|
|
"6045 Issue GEN REQ WQE to NPORT x%x "
|
|
|
|
"Data: x%x x%x\n",
|
|
|
|
ndlp->nlp_DID, genwqe->iotag,
|
|
|
|
vport->port_state);
|
|
|
|
lpfc_sli_release_iocbq(phba, genwqe);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* lpfc_nvme_ls_req - Issue an Link Service request
|
|
|
|
* @lpfc_pnvme: Pointer to the driver's nvme instance data
|
|
|
|
* @lpfc_nvme_lport: Pointer to the driver's local port data
|
|
|
|
* @lpfc_nvme_rport: Pointer to the rport getting the @lpfc_nvme_ereq
|
|
|
|
*
|
|
|
|
* Driver registers this routine to handle any link service request
|
|
|
|
* from the nvme_fc transport to a remote nvme-aware port.
|
|
|
|
*
|
|
|
|
* Return value :
|
|
|
|
* 0 - Success
|
|
|
|
* TODO: What are the failure codes.
|
|
|
|
**/
|
|
|
|
static int
|
|
|
|
lpfc_nvme_ls_req(struct nvme_fc_local_port *pnvme_lport,
|
|
|
|
struct nvme_fc_remote_port *pnvme_rport,
|
|
|
|
struct nvmefc_ls_req *pnvme_lsreq)
|
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
struct lpfc_nvme_lport *lport;
|
scsi: lpfc: Fix nonrecovery of NVME controller after cable swap.
In a test that is doing large numbers of cable swaps on the target, the
nvme controllers wouldn't reconnect.
During the cable swaps, the targets n_port_id would change. This
information was passed to the nvme-fc transport, in the new remoteport
registration. However, the nvme-fc transport didn't update the n_port_id
value in the remoteport struct when it reused an existing structure.
Later, when a new association was attempted on the remoteport, the
driver's NVME LS routine would use the stale n_port_id from the
remoteport struct to address the LS. As the device is no longer at that
address, the LS would go into never never land.
Separately, the nvme-fc transport will be corrected to update the
n_port_id value on a re-registration.
However, for now, there's no reason to use the transports values. The
private pointer points to the drivers node structure and the node
structure is up to date. Therefore, revise the LS routine to use the
drivers data structures for the LS. Augmented the debug message for
better debugging in the future.
Also removed a duplicate if check that seems to have slipped in.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-01-30 23:59:01 +00:00
|
|
|
struct lpfc_nvme_rport *rport;
|
2017-02-12 21:52:32 +00:00
|
|
|
struct lpfc_vport *vport;
|
|
|
|
struct lpfc_nodelist *ndlp;
|
|
|
|
struct ulp_bde64 *bpl;
|
|
|
|
struct lpfc_dmabuf *bmp;
|
2017-04-21 23:04:47 +00:00
|
|
|
uint16_t ntype, nstate;
|
2017-02-12 21:52:32 +00:00
|
|
|
|
|
|
|
/* there are two dma buf in the request, actually there is one and
|
|
|
|
* the second one is just the start address + cmd size.
|
|
|
|
* Before calling lpfc_nvme_gen_req these buffers need to be wrapped
|
|
|
|
* in a lpfc_dmabuf struct. When freeing we just free the wrapper
|
|
|
|
* because the nvem layer owns the data bufs.
|
|
|
|
* We do not have to break these packets open, we don't care what is in
|
|
|
|
* them. And we do not have to look at the resonse data, we only care
|
|
|
|
* that we got a response. All of the caring is going to happen in the
|
|
|
|
* nvme-fc layer.
|
|
|
|
*/
|
|
|
|
|
|
|
|
lport = (struct lpfc_nvme_lport *)pnvme_lport->private;
|
scsi: lpfc: Fix nonrecovery of NVME controller after cable swap.
In a test that is doing large numbers of cable swaps on the target, the
nvme controllers wouldn't reconnect.
During the cable swaps, the targets n_port_id would change. This
information was passed to the nvme-fc transport, in the new remoteport
registration. However, the nvme-fc transport didn't update the n_port_id
value in the remoteport struct when it reused an existing structure.
Later, when a new association was attempted on the remoteport, the
driver's NVME LS routine would use the stale n_port_id from the
remoteport struct to address the LS. As the device is no longer at that
address, the LS would go into never never land.
Separately, the nvme-fc transport will be corrected to update the
n_port_id value on a re-registration.
However, for now, there's no reason to use the transports values. The
private pointer points to the drivers node structure and the node
structure is up to date. Therefore, revise the LS routine to use the
drivers data structures for the LS. Augmented the debug message for
better debugging in the future.
Also removed a duplicate if check that seems to have slipped in.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-01-30 23:59:01 +00:00
|
|
|
rport = (struct lpfc_nvme_rport *)pnvme_rport->private;
|
2018-04-09 21:24:23 +00:00
|
|
|
if (unlikely(!lport) || unlikely(!rport))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2017-02-12 21:52:32 +00:00
|
|
|
vport = lport->vport;
|
|
|
|
|
2017-11-21 00:00:41 +00:00
|
|
|
if (vport->load_flag & FC_UNLOADING)
|
|
|
|
return -ENODEV;
|
|
|
|
|
scsi: lpfc: Fix nonrecovery of NVME controller after cable swap.
In a test that is doing large numbers of cable swaps on the target, the
nvme controllers wouldn't reconnect.
During the cable swaps, the targets n_port_id would change. This
information was passed to the nvme-fc transport, in the new remoteport
registration. However, the nvme-fc transport didn't update the n_port_id
value in the remoteport struct when it reused an existing structure.
Later, when a new association was attempted on the remoteport, the
driver's NVME LS routine would use the stale n_port_id from the
remoteport struct to address the LS. As the device is no longer at that
address, the LS would go into never never land.
Separately, the nvme-fc transport will be corrected to update the
n_port_id value on a re-registration.
However, for now, there's no reason to use the transports values. The
private pointer points to the drivers node structure and the node
structure is up to date. Therefore, revise the LS routine to use the
drivers data structures for the LS. Augmented the debug message for
better debugging in the future.
Also removed a duplicate if check that seems to have slipped in.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-01-30 23:59:01 +00:00
|
|
|
/* Need the ndlp. It is stored in the driver's rport. */
|
|
|
|
ndlp = rport->ndlp;
|
2017-04-21 23:04:47 +00:00
|
|
|
if (!ndlp || !NLP_CHK_NODE_ACT(ndlp)) {
|
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_NODE | LOG_NVME_IOERR,
|
2019-08-14 23:57:06 +00:00
|
|
|
"6051 Remoteport x%px, rport has invalid ndlp. "
|
scsi: lpfc: Fix nonrecovery of NVME controller after cable swap.
In a test that is doing large numbers of cable swaps on the target, the
nvme controllers wouldn't reconnect.
During the cable swaps, the targets n_port_id would change. This
information was passed to the nvme-fc transport, in the new remoteport
registration. However, the nvme-fc transport didn't update the n_port_id
value in the remoteport struct when it reused an existing structure.
Later, when a new association was attempted on the remoteport, the
driver's NVME LS routine would use the stale n_port_id from the
remoteport struct to address the LS. As the device is no longer at that
address, the LS would go into never never land.
Separately, the nvme-fc transport will be corrected to update the
n_port_id value on a re-registration.
However, for now, there's no reason to use the transports values. The
private pointer points to the drivers node structure and the node
structure is up to date. Therefore, revise the LS routine to use the
drivers data structures for the LS. Augmented the debug message for
better debugging in the future.
Also removed a duplicate if check that seems to have slipped in.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-01-30 23:59:01 +00:00
|
|
|
"Failing LS Req\n", pnvme_rport);
|
2017-04-21 23:04:47 +00:00
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* The remote node has to be a mapped nvme target or an
|
|
|
|
* unmapped nvme initiator or it's an error.
|
|
|
|
*/
|
|
|
|
ntype = ndlp->nlp_type;
|
|
|
|
nstate = ndlp->nlp_state;
|
|
|
|
if ((ntype & NLP_NVME_TARGET && nstate != NLP_STE_MAPPED_NODE) ||
|
|
|
|
(ntype & NLP_NVME_INITIATOR && nstate != NLP_STE_UNMAPPED_NODE)) {
|
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_NODE | LOG_NVME_IOERR,
|
|
|
|
"6088 DID x%06x not ready for "
|
|
|
|
"IO. State x%x, Type x%x\n",
|
|
|
|
pnvme_rport->port_id,
|
|
|
|
ndlp->nlp_state, ndlp->nlp_type);
|
|
|
|
return -ENODEV;
|
2017-02-12 21:52:32 +00:00
|
|
|
}
|
|
|
|
bmp = kmalloc(sizeof(struct lpfc_dmabuf), GFP_KERNEL);
|
|
|
|
if (!bmp) {
|
|
|
|
|
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_NVME_DISC,
|
|
|
|
"6044 Could not find node for DID %x\n",
|
|
|
|
pnvme_rport->port_id);
|
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
INIT_LIST_HEAD(&bmp->list);
|
|
|
|
bmp->virt = lpfc_mbuf_alloc(vport->phba, MEM_PRI, &(bmp->phys));
|
|
|
|
if (!bmp->virt) {
|
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_NVME_DISC,
|
|
|
|
"6042 Could not find node for DID %x\n",
|
|
|
|
pnvme_rport->port_id);
|
|
|
|
kfree(bmp);
|
|
|
|
return 3;
|
|
|
|
}
|
|
|
|
bpl = (struct ulp_bde64 *)bmp->virt;
|
|
|
|
bpl->addrHigh = le32_to_cpu(putPaddrHigh(pnvme_lsreq->rqstdma));
|
|
|
|
bpl->addrLow = le32_to_cpu(putPaddrLow(pnvme_lsreq->rqstdma));
|
|
|
|
bpl->tus.f.bdeFlags = 0;
|
|
|
|
bpl->tus.f.bdeSize = pnvme_lsreq->rqstlen;
|
|
|
|
bpl->tus.w = le32_to_cpu(bpl->tus.w);
|
|
|
|
bpl++;
|
|
|
|
|
|
|
|
bpl->addrHigh = le32_to_cpu(putPaddrHigh(pnvme_lsreq->rspdma));
|
|
|
|
bpl->addrLow = le32_to_cpu(putPaddrLow(pnvme_lsreq->rspdma));
|
|
|
|
bpl->tus.f.bdeFlags = BUFF_TYPE_BDE_64I;
|
|
|
|
bpl->tus.f.bdeSize = pnvme_lsreq->rsplen;
|
|
|
|
bpl->tus.w = le32_to_cpu(bpl->tus.w);
|
|
|
|
|
|
|
|
/* Expand print to include key fields. */
|
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_DISC,
|
2019-08-14 23:57:06 +00:00
|
|
|
"6149 Issue LS Req to DID 0x%06x lport x%px, "
|
|
|
|
"rport x%px lsreq x%px rqstlen:%d rsplen:%d "
|
|
|
|
"%pad %pad\n",
|
|
|
|
ndlp->nlp_DID, pnvme_lport, pnvme_rport,
|
2017-02-12 21:52:32 +00:00
|
|
|
pnvme_lsreq, pnvme_lsreq->rqstlen,
|
2017-02-27 20:37:12 +00:00
|
|
|
pnvme_lsreq->rsplen, &pnvme_lsreq->rqstdma,
|
|
|
|
&pnvme_lsreq->rspdma);
|
2017-02-12 21:52:32 +00:00
|
|
|
|
2018-04-09 21:24:23 +00:00
|
|
|
atomic_inc(&lport->fc4NvmeLsRequests);
|
2017-02-12 21:52:32 +00:00
|
|
|
|
|
|
|
/* Hardcode the wait to 30 seconds. Connections are failing otherwise.
|
|
|
|
* This code allows it all to work.
|
|
|
|
*/
|
|
|
|
ret = lpfc_nvme_gen_req(vport, bmp, pnvme_lsreq->rqstaddr,
|
|
|
|
pnvme_lsreq, lpfc_nvme_cmpl_gen_req,
|
|
|
|
ndlp, 2, 30, 0);
|
|
|
|
if (ret != WQE_SUCCESS) {
|
2017-12-09 01:18:10 +00:00
|
|
|
atomic_inc(&lport->xmt_ls_err);
|
scsi: lpfc: Fix nonrecovery of NVME controller after cable swap.
In a test that is doing large numbers of cable swaps on the target, the
nvme controllers wouldn't reconnect.
During the cable swaps, the targets n_port_id would change. This
information was passed to the nvme-fc transport, in the new remoteport
registration. However, the nvme-fc transport didn't update the n_port_id
value in the remoteport struct when it reused an existing structure.
Later, when a new association was attempted on the remoteport, the
driver's NVME LS routine would use the stale n_port_id from the
remoteport struct to address the LS. As the device is no longer at that
address, the LS would go into never never land.
Separately, the nvme-fc transport will be corrected to update the
n_port_id value on a re-registration.
However, for now, there's no reason to use the transports values. The
private pointer points to the drivers node structure and the node
structure is up to date. Therefore, revise the LS routine to use the
drivers data structures for the LS. Augmented the debug message for
better debugging in the future.
Also removed a duplicate if check that seems to have slipped in.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-01-30 23:59:01 +00:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_NVME_DISC,
|
2019-08-14 23:57:06 +00:00
|
|
|
"6052 EXIT. issue ls wqe failed lport x%px, "
|
|
|
|
"rport x%px lsreq x%px Status %x DID %x\n",
|
2017-02-12 21:52:32 +00:00
|
|
|
pnvme_lport, pnvme_rport, pnvme_lsreq,
|
|
|
|
ret, ndlp->nlp_DID);
|
|
|
|
lpfc_mbuf_free(vport->phba, bmp->virt, bmp->phys);
|
|
|
|
kfree(bmp);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Stub in routine and return 0 for now. */
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* lpfc_nvme_ls_abort - Issue an Link Service request
|
|
|
|
* @lpfc_pnvme: Pointer to the driver's nvme instance data
|
|
|
|
* @lpfc_nvme_lport: Pointer to the driver's local port data
|
|
|
|
* @lpfc_nvme_rport: Pointer to the rport getting the @lpfc_nvme_ereq
|
|
|
|
*
|
|
|
|
* Driver registers this routine to handle any link service request
|
|
|
|
* from the nvme_fc transport to a remote nvme-aware port.
|
|
|
|
*
|
|
|
|
* Return value :
|
|
|
|
* 0 - Success
|
|
|
|
* TODO: What are the failure codes.
|
|
|
|
**/
|
|
|
|
static void
|
|
|
|
lpfc_nvme_ls_abort(struct nvme_fc_local_port *pnvme_lport,
|
|
|
|
struct nvme_fc_remote_port *pnvme_rport,
|
|
|
|
struct nvmefc_ls_req *pnvme_lsreq)
|
|
|
|
{
|
|
|
|
struct lpfc_nvme_lport *lport;
|
|
|
|
struct lpfc_vport *vport;
|
|
|
|
struct lpfc_hba *phba;
|
|
|
|
struct lpfc_nodelist *ndlp;
|
|
|
|
LIST_HEAD(abort_list);
|
|
|
|
struct lpfc_sli_ring *pring;
|
|
|
|
struct lpfc_iocbq *wqe, *next_wqe;
|
|
|
|
|
|
|
|
lport = (struct lpfc_nvme_lport *)pnvme_lport->private;
|
2018-04-09 21:24:23 +00:00
|
|
|
if (unlikely(!lport))
|
|
|
|
return;
|
2017-02-12 21:52:32 +00:00
|
|
|
vport = lport->vport;
|
|
|
|
phba = vport->phba;
|
|
|
|
|
2017-11-21 00:00:41 +00:00
|
|
|
if (vport->load_flag & FC_UNLOADING)
|
|
|
|
return;
|
|
|
|
|
2017-02-12 21:52:32 +00:00
|
|
|
ndlp = lpfc_findnode_did(vport, pnvme_rport->port_id);
|
|
|
|
if (!ndlp) {
|
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_NVME_ABTS,
|
|
|
|
"6049 Could not find node for DID %x\n",
|
|
|
|
pnvme_rport->port_id);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Expand print to include key fields. */
|
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_ABTS,
|
2019-08-14 23:57:06 +00:00
|
|
|
"6040 ENTER. lport x%px, rport x%px lsreq x%px rqstlen:%d "
|
2017-02-27 20:37:12 +00:00
|
|
|
"rsplen:%d %pad %pad\n",
|
2017-02-12 21:52:32 +00:00
|
|
|
pnvme_lport, pnvme_rport,
|
|
|
|
pnvme_lsreq, pnvme_lsreq->rqstlen,
|
2017-02-27 20:37:12 +00:00
|
|
|
pnvme_lsreq->rsplen, &pnvme_lsreq->rqstdma,
|
|
|
|
&pnvme_lsreq->rspdma);
|
2017-02-12 21:52:32 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Lock the ELS ring txcmplq and build a local list of all ELS IOs
|
|
|
|
* that need an ABTS. The IOs need to stay on the txcmplq so that
|
|
|
|
* the abort operation completes them successfully.
|
|
|
|
*/
|
|
|
|
pring = phba->sli4_hba.nvmels_wq->pring;
|
|
|
|
spin_lock_irq(&phba->hbalock);
|
|
|
|
spin_lock(&pring->ring_lock);
|
|
|
|
list_for_each_entry_safe(wqe, next_wqe, &pring->txcmplq, list) {
|
|
|
|
/* Add to abort_list on on NDLP match. */
|
|
|
|
if (lpfc_check_sli_ndlp(phba, pring, wqe, ndlp)) {
|
|
|
|
wqe->iocb_flag |= LPFC_DRIVER_ABORTED;
|
|
|
|
list_add_tail(&wqe->dlist, &abort_list);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
spin_unlock(&pring->ring_lock);
|
|
|
|
spin_unlock_irq(&phba->hbalock);
|
|
|
|
|
|
|
|
/* Abort the targeted IOs and remove them from the abort list. */
|
|
|
|
list_for_each_entry_safe(wqe, next_wqe, &abort_list, dlist) {
|
2017-12-09 01:18:10 +00:00
|
|
|
atomic_inc(&lport->xmt_ls_abort);
|
2017-02-12 21:52:32 +00:00
|
|
|
spin_lock_irq(&phba->hbalock);
|
|
|
|
list_del_init(&wqe->dlist);
|
|
|
|
lpfc_sli_issue_abort_iotag(phba, pring, wqe);
|
|
|
|
spin_unlock_irq(&phba->hbalock);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Fix up the existing sgls for NVME IO. */
|
2018-03-05 20:04:04 +00:00
|
|
|
static inline void
|
2017-02-12 21:52:32 +00:00
|
|
|
lpfc_nvme_adj_fcp_sgls(struct lpfc_vport *vport,
|
scsi: lpfc: Adapt partitioned XRI lists to efficient sharing
The XRI get/put lists were partitioned per hardware queue. However, the
adapter rarely had sufficient resources to give a large number of resources
per queue. As such, it became common for a cpu to encounter a lack of XRI
resource and request the upper io stack to retry after returning a BUSY
condition. This occurred even though other cpus were idle and not using
their resources.
Create as efficient a scheme as possible to move resources to the cpus that
need them. Each cpu maintains a small private pool which it allocates from
for io. There is a watermark that the cpu attempts to keep in the private
pool. The private pool, when empty, pulls from a global pool from the
cpu. When the cpu's global pool is empty it will pull from other cpu's
global pool. As there many cpu global pools (1 per cpu or hardware queue
count) and as each cpu selects what cpu to pull from at different rates and
at different times, it creates a radomizing effect that minimizes the
number of cpu's that will contend with each other when the steal XRI's from
another cpu's global pool.
On io completion, a cpu will push the XRI back on to its private pool. A
watermark level is maintained for the private pool such that when it is
exceeded it will move XRI's to the CPU global pool so that other cpu's may
allocate them.
On NVME, as heartbeat commands are critical to get placed on the wire, a
single expedite pool is maintained. When a heartbeat is to be sent, it will
allocate an XRI from the expedite pool rather than the normal cpu
private/global pools. On any io completion, if a reduction in the expedite
pools is seen, it will be replenished before the XRI is placed on the cpu
private pool.
Statistics are added to aid understanding the XRI levels on each cpu and
their behaviors.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-01-28 19:14:28 +00:00
|
|
|
struct lpfc_io_buf *lpfc_ncmd,
|
2017-02-12 21:52:32 +00:00
|
|
|
struct nvmefc_fcp_req *nCmd)
|
|
|
|
{
|
2018-02-22 16:18:50 +00:00
|
|
|
struct lpfc_hba *phba = vport->phba;
|
2017-02-12 21:52:32 +00:00
|
|
|
struct sli4_sge *sgl;
|
|
|
|
union lpfc_wqe128 *wqe;
|
|
|
|
uint32_t *wptr, *dptr;
|
|
|
|
|
2018-02-22 16:18:50 +00:00
|
|
|
/*
|
|
|
|
* Get a local pointer to the built-in wqe and correct
|
|
|
|
* the cmd size to match NVME's 96 bytes and fix
|
|
|
|
* the dma address.
|
|
|
|
*/
|
|
|
|
|
2018-03-05 20:04:03 +00:00
|
|
|
wqe = &lpfc_ncmd->cur_iocbq.wqe;
|
2018-02-22 16:18:50 +00:00
|
|
|
|
2017-02-12 21:52:32 +00:00
|
|
|
/*
|
|
|
|
* Adjust the FCP_CMD and FCP_RSP DMA data and sge_len to
|
|
|
|
* match NVME. NVME sends 96 bytes. Also, use the
|
|
|
|
* nvme commands command and response dma addresses
|
|
|
|
* rather than the virtual memory to ease the restore
|
|
|
|
* operation.
|
|
|
|
*/
|
2019-01-28 19:14:19 +00:00
|
|
|
sgl = lpfc_ncmd->dma_sgl;
|
2017-02-12 21:52:32 +00:00
|
|
|
sgl->sge_len = cpu_to_le32(nCmd->cmdlen);
|
2018-02-22 16:18:50 +00:00
|
|
|
if (phba->cfg_nvme_embed_cmd) {
|
|
|
|
sgl->addr_hi = 0;
|
|
|
|
sgl->addr_lo = 0;
|
|
|
|
|
|
|
|
/* Word 0-2 - NVME CMND IU (embedded payload) */
|
|
|
|
wqe->generic.bde.tus.f.bdeFlags = BUFF_TYPE_BDE_IMMED;
|
|
|
|
wqe->generic.bde.tus.f.bdeSize = 56;
|
|
|
|
wqe->generic.bde.addrHigh = 0;
|
|
|
|
wqe->generic.bde.addrLow = 64; /* Word 16 */
|
2018-03-05 20:04:04 +00:00
|
|
|
|
|
|
|
/* Word 10 - dbde is 0, wqes is 1 in template */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Embed the payload in the last half of the WQE
|
|
|
|
* WQE words 16-30 get the NVME CMD IU payload
|
|
|
|
*
|
|
|
|
* WQE words 16-19 get payload Words 1-4
|
|
|
|
* WQE words 20-21 get payload Words 6-7
|
|
|
|
* WQE words 22-29 get payload Words 16-23
|
|
|
|
*/
|
|
|
|
wptr = &wqe->words[16]; /* WQE ptr */
|
|
|
|
dptr = (uint32_t *)nCmd->cmdaddr; /* payload ptr */
|
|
|
|
dptr++; /* Skip Word 0 in payload */
|
|
|
|
|
|
|
|
*wptr++ = *dptr++; /* Word 1 */
|
|
|
|
*wptr++ = *dptr++; /* Word 2 */
|
|
|
|
*wptr++ = *dptr++; /* Word 3 */
|
|
|
|
*wptr++ = *dptr++; /* Word 4 */
|
|
|
|
dptr++; /* Skip Word 5 in payload */
|
|
|
|
*wptr++ = *dptr++; /* Word 6 */
|
|
|
|
*wptr++ = *dptr++; /* Word 7 */
|
|
|
|
dptr += 8; /* Skip Words 8-15 in payload */
|
|
|
|
*wptr++ = *dptr++; /* Word 16 */
|
|
|
|
*wptr++ = *dptr++; /* Word 17 */
|
|
|
|
*wptr++ = *dptr++; /* Word 18 */
|
|
|
|
*wptr++ = *dptr++; /* Word 19 */
|
|
|
|
*wptr++ = *dptr++; /* Word 20 */
|
|
|
|
*wptr++ = *dptr++; /* Word 21 */
|
|
|
|
*wptr++ = *dptr++; /* Word 22 */
|
|
|
|
*wptr = *dptr; /* Word 23 */
|
2018-02-22 16:18:50 +00:00
|
|
|
} else {
|
|
|
|
sgl->addr_hi = cpu_to_le32(putPaddrHigh(nCmd->cmddma));
|
|
|
|
sgl->addr_lo = cpu_to_le32(putPaddrLow(nCmd->cmddma));
|
|
|
|
|
|
|
|
/* Word 0-2 - NVME CMND IU Inline BDE */
|
|
|
|
wqe->generic.bde.tus.f.bdeFlags = BUFF_TYPE_BDE_64;
|
|
|
|
wqe->generic.bde.tus.f.bdeSize = nCmd->cmdlen;
|
|
|
|
wqe->generic.bde.addrHigh = sgl->addr_hi;
|
|
|
|
wqe->generic.bde.addrLow = sgl->addr_lo;
|
2018-03-05 20:04:04 +00:00
|
|
|
|
|
|
|
/* Word 10 */
|
|
|
|
bf_set(wqe_dbde, &wqe->generic.wqe_com, 1);
|
|
|
|
bf_set(wqe_wqes, &wqe->generic.wqe_com, 0);
|
2018-02-22 16:18:50 +00:00
|
|
|
}
|
2017-02-12 21:52:32 +00:00
|
|
|
|
|
|
|
sgl++;
|
|
|
|
|
|
|
|
/* Setup the physical region for the FCP RSP */
|
|
|
|
sgl->addr_hi = cpu_to_le32(putPaddrHigh(nCmd->rspdma));
|
|
|
|
sgl->addr_lo = cpu_to_le32(putPaddrLow(nCmd->rspdma));
|
|
|
|
sgl->word2 = le32_to_cpu(sgl->word2);
|
|
|
|
if (nCmd->sg_cnt)
|
|
|
|
bf_set(lpfc_sli4_sge_last, sgl, 0);
|
|
|
|
else
|
|
|
|
bf_set(lpfc_sli4_sge_last, sgl, 1);
|
|
|
|
sgl->word2 = cpu_to_le32(sgl->word2);
|
|
|
|
sgl->sge_len = cpu_to_le32(nCmd->rsplen);
|
|
|
|
}
|
|
|
|
|
2017-02-12 21:52:33 +00:00
|
|
|
|
2017-02-12 21:52:32 +00:00
|
|
|
/**
|
|
|
|
* lpfc_nvme_io_cmd_wqe_cmpl - Complete an NVME-over-FCP IO
|
|
|
|
* @lpfc_pnvme: Pointer to the driver's nvme instance data
|
|
|
|
* @lpfc_nvme_lport: Pointer to the driver's local port data
|
|
|
|
* @lpfc_nvme_rport: Pointer to the rport getting the @lpfc_nvme_ereq
|
|
|
|
*
|
|
|
|
* Driver registers this routine as it io request handler. This
|
|
|
|
* routine issues an fcp WQE with data from the @lpfc_nvme_fcpreq
|
|
|
|
* data structure to the rport indicated in @lpfc_nvme_rport.
|
|
|
|
*
|
|
|
|
* Return value :
|
|
|
|
* 0 - Success
|
|
|
|
* TODO: What are the failure codes.
|
|
|
|
**/
|
|
|
|
static void
|
|
|
|
lpfc_nvme_io_cmd_wqe_cmpl(struct lpfc_hba *phba, struct lpfc_iocbq *pwqeIn,
|
|
|
|
struct lpfc_wcqe_complete *wcqe)
|
|
|
|
{
|
scsi: lpfc: Adapt partitioned XRI lists to efficient sharing
The XRI get/put lists were partitioned per hardware queue. However, the
adapter rarely had sufficient resources to give a large number of resources
per queue. As such, it became common for a cpu to encounter a lack of XRI
resource and request the upper io stack to retry after returning a BUSY
condition. This occurred even though other cpus were idle and not using
their resources.
Create as efficient a scheme as possible to move resources to the cpus that
need them. Each cpu maintains a small private pool which it allocates from
for io. There is a watermark that the cpu attempts to keep in the private
pool. The private pool, when empty, pulls from a global pool from the
cpu. When the cpu's global pool is empty it will pull from other cpu's
global pool. As there many cpu global pools (1 per cpu or hardware queue
count) and as each cpu selects what cpu to pull from at different rates and
at different times, it creates a radomizing effect that minimizes the
number of cpu's that will contend with each other when the steal XRI's from
another cpu's global pool.
On io completion, a cpu will push the XRI back on to its private pool. A
watermark level is maintained for the private pool such that when it is
exceeded it will move XRI's to the CPU global pool so that other cpu's may
allocate them.
On NVME, as heartbeat commands are critical to get placed on the wire, a
single expedite pool is maintained. When a heartbeat is to be sent, it will
allocate an XRI from the expedite pool rather than the normal cpu
private/global pools. On any io completion, if a reduction in the expedite
pools is seen, it will be replenished before the XRI is placed on the cpu
private pool.
Statistics are added to aid understanding the XRI levels on each cpu and
their behaviors.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-01-28 19:14:28 +00:00
|
|
|
struct lpfc_io_buf *lpfc_ncmd =
|
|
|
|
(struct lpfc_io_buf *)pwqeIn->context1;
|
2017-02-12 21:52:32 +00:00
|
|
|
struct lpfc_vport *vport = pwqeIn->vport;
|
|
|
|
struct nvmefc_fcp_req *nCmd;
|
|
|
|
struct nvme_fc_ersp_iu *ep;
|
|
|
|
struct nvme_fc_cmd_iu *cp;
|
|
|
|
struct lpfc_nodelist *ndlp;
|
2017-04-22 00:49:08 +00:00
|
|
|
struct lpfc_nvme_fcpreq_priv *freqpriv;
|
2017-12-09 01:18:10 +00:00
|
|
|
struct lpfc_nvme_lport *lport;
|
2019-03-04 19:39:08 +00:00
|
|
|
uint32_t code, status, idx;
|
2017-02-12 21:52:32 +00:00
|
|
|
uint16_t cid, sqhd, data;
|
|
|
|
uint32_t *ptr;
|
2020-03-22 18:13:00 +00:00
|
|
|
#ifdef CONFIG_SCSI_LPFC_DEBUG_FS
|
|
|
|
int cpu;
|
|
|
|
#endif
|
2017-02-12 21:52:32 +00:00
|
|
|
|
|
|
|
/* Sanity check on return of outstanding command */
|
2019-01-28 19:14:37 +00:00
|
|
|
if (!lpfc_ncmd) {
|
|
|
|
lpfc_printf_vlog(vport, KERN_ERR,
|
|
|
|
LOG_NODE | LOG_NVME_IOERR,
|
|
|
|
"6071 Null lpfc_ncmd pointer. No "
|
|
|
|
"release, skip completion\n");
|
|
|
|
return;
|
|
|
|
}
|
2018-05-25 04:08:58 +00:00
|
|
|
|
2019-01-28 19:14:37 +00:00
|
|
|
/* Guard against abort handler being called at same time */
|
|
|
|
spin_lock(&lpfc_ncmd->buf_lock);
|
2018-05-25 04:08:58 +00:00
|
|
|
|
2019-01-28 19:14:37 +00:00
|
|
|
if (!lpfc_ncmd->nvmeCmd) {
|
|
|
|
spin_unlock(&lpfc_ncmd->buf_lock);
|
2017-02-12 21:52:32 +00:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_NODE | LOG_NVME_IOERR,
|
2019-08-14 23:57:06 +00:00
|
|
|
"6066 Missing cmpl ptrs: lpfc_ncmd x%px, "
|
|
|
|
"nvmeCmd x%px\n",
|
2019-01-28 19:14:17 +00:00
|
|
|
lpfc_ncmd, lpfc_ncmd->nvmeCmd);
|
2018-05-25 04:08:58 +00:00
|
|
|
|
|
|
|
/* Release the lpfc_ncmd regardless of the missing elements. */
|
|
|
|
lpfc_release_nvme_buf(phba, lpfc_ncmd);
|
2017-02-12 21:52:32 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
nCmd = lpfc_ncmd->nvmeCmd;
|
2017-12-09 01:18:10 +00:00
|
|
|
status = bf_get(lpfc_wcqe_c_status, wcqe);
|
2018-04-09 21:24:23 +00:00
|
|
|
|
2019-01-28 19:14:25 +00:00
|
|
|
idx = lpfc_ncmd->cur_iocbq.hba_wqidx;
|
|
|
|
phba->sli4_hba.hdwq[idx].nvme_cstat.io_cmpls++;
|
|
|
|
|
2019-08-14 23:57:05 +00:00
|
|
|
if (unlikely(status && vport->localport)) {
|
2018-04-09 21:24:31 +00:00
|
|
|
lport = (struct lpfc_nvme_lport *)vport->localport->private;
|
2019-08-14 23:57:05 +00:00
|
|
|
if (lport) {
|
2019-01-28 19:14:25 +00:00
|
|
|
if (bf_get(lpfc_wcqe_c_xb, wcqe))
|
|
|
|
atomic_inc(&lport->cmpl_fcp_xb);
|
|
|
|
atomic_inc(&lport->cmpl_fcp_err);
|
2018-04-09 21:24:23 +00:00
|
|
|
}
|
2017-12-09 01:18:10 +00:00
|
|
|
}
|
2017-02-12 21:52:32 +00:00
|
|
|
|
2017-02-12 21:52:33 +00:00
|
|
|
lpfc_nvmeio_data(phba, "NVME FCP CMPL: xri x%x stat x%x parm x%x\n",
|
|
|
|
lpfc_ncmd->cur_iocbq.sli4_xritag,
|
2017-12-09 01:18:10 +00:00
|
|
|
status, wcqe->parameter);
|
2017-02-12 21:52:32 +00:00
|
|
|
/*
|
|
|
|
* Catch race where our node has transitioned, but the
|
|
|
|
* transport is still transitioning.
|
|
|
|
*/
|
2019-01-28 19:14:17 +00:00
|
|
|
ndlp = lpfc_ncmd->ndlp;
|
2017-02-12 21:52:32 +00:00
|
|
|
if (!ndlp || !NLP_CHK_NODE_ACT(ndlp)) {
|
2019-01-28 19:14:17 +00:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_NVME_IOERR,
|
|
|
|
"6062 Ignoring NVME cmpl. No ndlp\n");
|
|
|
|
goto out_err;
|
2017-02-12 21:52:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
code = bf_get(lpfc_wcqe_c_code, wcqe);
|
|
|
|
if (code == CQE_CODE_NVME_ERSP) {
|
|
|
|
/* For this type of CQE, we need to rebuild the rsp */
|
|
|
|
ep = (struct nvme_fc_ersp_iu *)nCmd->rspaddr;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Get Command Id from cmd to plug into response. This
|
|
|
|
* code is not needed in the next NVME Transport drop.
|
|
|
|
*/
|
|
|
|
cp = (struct nvme_fc_cmd_iu *)nCmd->cmdaddr;
|
|
|
|
cid = cp->sqe.common.command_id;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* RSN is in CQE word 2
|
|
|
|
* SQHD is in CQE Word 3 bits 15:0
|
|
|
|
* Cmd Specific info is in CQE Word 1
|
|
|
|
* and in CQE Word 0 bits 15:0
|
|
|
|
*/
|
|
|
|
sqhd = bf_get(lpfc_wcqe_c_sqhead, wcqe);
|
|
|
|
|
|
|
|
/* Now lets build the NVME ERSP IU */
|
|
|
|
ep->iu_len = cpu_to_be16(8);
|
|
|
|
ep->rsn = wcqe->parameter;
|
|
|
|
ep->xfrd_len = cpu_to_be32(nCmd->payload_length);
|
|
|
|
ep->rsvd12 = 0;
|
|
|
|
ptr = (uint32_t *)&ep->cqe.result.u64;
|
|
|
|
*ptr++ = wcqe->total_data_placed;
|
|
|
|
data = bf_get(lpfc_wcqe_c_ersp0, wcqe);
|
|
|
|
*ptr = (uint32_t)data;
|
|
|
|
ep->cqe.sq_head = sqhd;
|
|
|
|
ep->cqe.sq_id = nCmd->sqid;
|
|
|
|
ep->cqe.command_id = cid;
|
|
|
|
ep->cqe.status = 0;
|
|
|
|
|
|
|
|
lpfc_ncmd->status = IOSTAT_SUCCESS;
|
|
|
|
lpfc_ncmd->result = 0;
|
|
|
|
nCmd->rcv_rsplen = LPFC_NVME_ERSP_LEN;
|
|
|
|
nCmd->transferred_length = nCmd->payload_length;
|
|
|
|
} else {
|
2017-12-09 01:18:10 +00:00
|
|
|
lpfc_ncmd->status = (status & LPFC_IOCB_STATUS_MASK);
|
2017-09-30 00:34:43 +00:00
|
|
|
lpfc_ncmd->result = (wcqe->parameter & IOERR_PARAM_MASK);
|
2017-02-12 21:52:32 +00:00
|
|
|
|
|
|
|
/* For NVME, the only failure path that results in an
|
|
|
|
* IO error is when the adapter rejects it. All other
|
|
|
|
* conditions are a success case and resolved by the
|
|
|
|
* transport.
|
|
|
|
* IOSTAT_FCP_RSP_ERROR means:
|
|
|
|
* 1. Length of data received doesn't match total
|
|
|
|
* transfer length in WQE
|
|
|
|
* 2. If the RSP payload does NOT match these cases:
|
|
|
|
* a. RSP length 12/24 bytes and all zeros
|
|
|
|
* b. NVME ERSP
|
|
|
|
*/
|
|
|
|
switch (lpfc_ncmd->status) {
|
|
|
|
case IOSTAT_SUCCESS:
|
|
|
|
nCmd->transferred_length = wcqe->total_data_placed;
|
|
|
|
nCmd->rcv_rsplen = 0;
|
|
|
|
nCmd->status = 0;
|
|
|
|
break;
|
|
|
|
case IOSTAT_FCP_RSP_ERROR:
|
|
|
|
nCmd->transferred_length = wcqe->total_data_placed;
|
|
|
|
nCmd->rcv_rsplen = wcqe->parameter;
|
|
|
|
nCmd->status = 0;
|
|
|
|
/* Sanity check */
|
|
|
|
if (nCmd->rcv_rsplen == LPFC_NVME_ERSP_LEN)
|
|
|
|
break;
|
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_NVME_IOERR,
|
|
|
|
"6081 NVME Completion Protocol Error: "
|
Update ABORT processing for NVMET.
The driver with nvme had this routine stubbed.
Right now XRI_ABORTED_CQE is not handled and the FC NVMET
Transport has a new API for the driver.
Missing code path, new NVME abort API
Update ABORT processing for NVMET
There are 3 new FC NVMET Transport API/ template routines for NVMET:
lpfc_nvmet_xmt_fcp_release
This NVMET template callback routine called to release context
associated with an IO This routine is ALWAYS called last, even
if the IO was aborted or completed in error.
lpfc_nvmet_xmt_fcp_abort
This NVMET template callback routine called to abort an exchange that
has an IO in progress
nvmet_fc_rcv_fcp_req
When the lpfc driver receives an ABTS, this NVME FC transport layer
callback routine is called. For this case there are 2 paths thru the
driver: the driver either has an outstanding exchange / context for the
XRI to be aborted or not. If not, a BA_RJT is issued otherwise a BA_ACC
NVMET Driver abort paths:
There are 2 paths for aborting an IO. The first one is we receive an IO and
decide not to process it because of lack of resources. An unsolicated ABTS
is immediately sent back to the initiator as a response.
lpfc_nvmet_unsol_fcp_buffer
lpfc_nvmet_unsol_issue_abort (XMIT_SEQUENCE_WQE)
The second one is we sent the IO up to the NVMET transport layer to
process, and for some reason the NVME Transport layer decided to abort the
IO before it completes all its phases. For this case there are 2 paths
thru the driver:
the driver either has an outstanding TSEND/TRECEIVE/TRSP WQE or no
outstanding WQEs are present for the exchange / context.
lpfc_nvmet_xmt_fcp_abort
if (LPFC_NVMET_IO_INP)
lpfc_nvmet_sol_fcp_issue_abort (ABORT_WQE)
lpfc_nvmet_sol_fcp_abort_cmp
else
lpfc_nvmet_unsol_fcp_issue_abort
lpfc_nvmet_unsol_issue_abort (XMIT_SEQUENCE_WQE)
lpfc_nvmet_unsol_fcp_abort_cmp
Context flags:
LPFC_NVMET_IOP - his flag signifies an IO is in progress on the exchange.
LPFC_NVMET_XBUSY - this flag indicates the IO completed but the firmware
is still busy with the corresponding exchange. The exchange should not be
reused until after a XRI_ABORTED_CQE is received for that exchange.
LPFC_NVMET_ABORT_OP - this flag signifies an ABORT_WQE was issued on the
exchange.
LPFC_NVMET_CTX_RLS - this flag signifies a context free was requested,
but we are deferring it due to an XBUSY or ABORT in progress.
A ctxlock is added to the context structure that is used whenever these
flags are set/read within the context of an IO.
The LPFC_NVMET_CTX_RLS flag is only set in the defer_relase routine when
the transport has resolved all IO associated with the buffer. The flag is
cleared when the CTX is associated with a new IO.
An exchange can has both an LPFC_NVMET_XBUSY and a LPFC_NVMET_ABORT_OP
condition active simultaneously. Both conditions must complete before the
exchange is freed.
When the abort callback (lpfc_nvmet_xmt_fcp_abort) is envoked:
If there is an outstanding IO, the driver will issue an ABORT_WQE. This
should result in 3 completions for the exchange:
1) IO cmpl with XB bit set
2) Abort WQE cmpl
3) XRI_ABORTED_CQE cmpl
For this scenerio, after completion #1, the NVMET Transport IO rsp
callback is called. After completion #2, no action is taken with respect
to the exchange / context. After completion #3, the exchange context is
free for re-use on another IO.
If there is no outstanding activity on the exchange, the driver will send a
ABTS to the Initiator. Upon completion of this WQE, the exchange / context
is freed for re-use on another IO.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
2017-04-21 23:05:04 +00:00
|
|
|
"xri %x status x%x result x%x "
|
|
|
|
"placed x%x\n",
|
|
|
|
lpfc_ncmd->cur_iocbq.sli4_xritag,
|
2017-02-12 21:52:32 +00:00
|
|
|
lpfc_ncmd->status, lpfc_ncmd->result,
|
|
|
|
wcqe->total_data_placed);
|
|
|
|
break;
|
2017-09-30 00:34:43 +00:00
|
|
|
case IOSTAT_LOCAL_REJECT:
|
|
|
|
/* Let fall through to set command final state. */
|
|
|
|
if (lpfc_ncmd->result == IOERR_ABORT_REQUESTED)
|
|
|
|
lpfc_printf_vlog(vport, KERN_INFO,
|
|
|
|
LOG_NVME_IOERR,
|
2019-08-14 23:57:06 +00:00
|
|
|
"6032 Delay Aborted cmd x%px "
|
|
|
|
"nvme cmd x%px, xri x%x, "
|
2017-09-30 00:34:43 +00:00
|
|
|
"xb %d\n",
|
|
|
|
lpfc_ncmd, nCmd,
|
|
|
|
lpfc_ncmd->cur_iocbq.sli4_xritag,
|
|
|
|
bf_get(lpfc_wcqe_c_xb, wcqe));
|
2019-03-28 18:06:18 +00:00
|
|
|
/* fall through */
|
2017-02-12 21:52:32 +00:00
|
|
|
default:
|
|
|
|
out_err:
|
2017-09-30 00:34:36 +00:00
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_IOERR,
|
Update ABORT processing for NVMET.
The driver with nvme had this routine stubbed.
Right now XRI_ABORTED_CQE is not handled and the FC NVMET
Transport has a new API for the driver.
Missing code path, new NVME abort API
Update ABORT processing for NVMET
There are 3 new FC NVMET Transport API/ template routines for NVMET:
lpfc_nvmet_xmt_fcp_release
This NVMET template callback routine called to release context
associated with an IO This routine is ALWAYS called last, even
if the IO was aborted or completed in error.
lpfc_nvmet_xmt_fcp_abort
This NVMET template callback routine called to abort an exchange that
has an IO in progress
nvmet_fc_rcv_fcp_req
When the lpfc driver receives an ABTS, this NVME FC transport layer
callback routine is called. For this case there are 2 paths thru the
driver: the driver either has an outstanding exchange / context for the
XRI to be aborted or not. If not, a BA_RJT is issued otherwise a BA_ACC
NVMET Driver abort paths:
There are 2 paths for aborting an IO. The first one is we receive an IO and
decide not to process it because of lack of resources. An unsolicated ABTS
is immediately sent back to the initiator as a response.
lpfc_nvmet_unsol_fcp_buffer
lpfc_nvmet_unsol_issue_abort (XMIT_SEQUENCE_WQE)
The second one is we sent the IO up to the NVMET transport layer to
process, and for some reason the NVME Transport layer decided to abort the
IO before it completes all its phases. For this case there are 2 paths
thru the driver:
the driver either has an outstanding TSEND/TRECEIVE/TRSP WQE or no
outstanding WQEs are present for the exchange / context.
lpfc_nvmet_xmt_fcp_abort
if (LPFC_NVMET_IO_INP)
lpfc_nvmet_sol_fcp_issue_abort (ABORT_WQE)
lpfc_nvmet_sol_fcp_abort_cmp
else
lpfc_nvmet_unsol_fcp_issue_abort
lpfc_nvmet_unsol_issue_abort (XMIT_SEQUENCE_WQE)
lpfc_nvmet_unsol_fcp_abort_cmp
Context flags:
LPFC_NVMET_IOP - his flag signifies an IO is in progress on the exchange.
LPFC_NVMET_XBUSY - this flag indicates the IO completed but the firmware
is still busy with the corresponding exchange. The exchange should not be
reused until after a XRI_ABORTED_CQE is received for that exchange.
LPFC_NVMET_ABORT_OP - this flag signifies an ABORT_WQE was issued on the
exchange.
LPFC_NVMET_CTX_RLS - this flag signifies a context free was requested,
but we are deferring it due to an XBUSY or ABORT in progress.
A ctxlock is added to the context structure that is used whenever these
flags are set/read within the context of an IO.
The LPFC_NVMET_CTX_RLS flag is only set in the defer_relase routine when
the transport has resolved all IO associated with the buffer. The flag is
cleared when the CTX is associated with a new IO.
An exchange can has both an LPFC_NVMET_XBUSY and a LPFC_NVMET_ABORT_OP
condition active simultaneously. Both conditions must complete before the
exchange is freed.
When the abort callback (lpfc_nvmet_xmt_fcp_abort) is envoked:
If there is an outstanding IO, the driver will issue an ABORT_WQE. This
should result in 3 completions for the exchange:
1) IO cmpl with XB bit set
2) Abort WQE cmpl
3) XRI_ABORTED_CQE cmpl
For this scenerio, after completion #1, the NVMET Transport IO rsp
callback is called. After completion #2, no action is taken with respect
to the exchange / context. After completion #3, the exchange context is
free for re-use on another IO.
If there is no outstanding activity on the exchange, the driver will send a
ABTS to the Initiator. Upon completion of this WQE, the exchange / context
is freed for re-use on another IO.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
2017-04-21 23:05:04 +00:00
|
|
|
"6072 NVME Completion Error: xri %x "
|
2019-03-12 23:30:31 +00:00
|
|
|
"status x%x result x%x [x%x] "
|
|
|
|
"placed x%x\n",
|
Update ABORT processing for NVMET.
The driver with nvme had this routine stubbed.
Right now XRI_ABORTED_CQE is not handled and the FC NVMET
Transport has a new API for the driver.
Missing code path, new NVME abort API
Update ABORT processing for NVMET
There are 3 new FC NVMET Transport API/ template routines for NVMET:
lpfc_nvmet_xmt_fcp_release
This NVMET template callback routine called to release context
associated with an IO This routine is ALWAYS called last, even
if the IO was aborted or completed in error.
lpfc_nvmet_xmt_fcp_abort
This NVMET template callback routine called to abort an exchange that
has an IO in progress
nvmet_fc_rcv_fcp_req
When the lpfc driver receives an ABTS, this NVME FC transport layer
callback routine is called. For this case there are 2 paths thru the
driver: the driver either has an outstanding exchange / context for the
XRI to be aborted or not. If not, a BA_RJT is issued otherwise a BA_ACC
NVMET Driver abort paths:
There are 2 paths for aborting an IO. The first one is we receive an IO and
decide not to process it because of lack of resources. An unsolicated ABTS
is immediately sent back to the initiator as a response.
lpfc_nvmet_unsol_fcp_buffer
lpfc_nvmet_unsol_issue_abort (XMIT_SEQUENCE_WQE)
The second one is we sent the IO up to the NVMET transport layer to
process, and for some reason the NVME Transport layer decided to abort the
IO before it completes all its phases. For this case there are 2 paths
thru the driver:
the driver either has an outstanding TSEND/TRECEIVE/TRSP WQE or no
outstanding WQEs are present for the exchange / context.
lpfc_nvmet_xmt_fcp_abort
if (LPFC_NVMET_IO_INP)
lpfc_nvmet_sol_fcp_issue_abort (ABORT_WQE)
lpfc_nvmet_sol_fcp_abort_cmp
else
lpfc_nvmet_unsol_fcp_issue_abort
lpfc_nvmet_unsol_issue_abort (XMIT_SEQUENCE_WQE)
lpfc_nvmet_unsol_fcp_abort_cmp
Context flags:
LPFC_NVMET_IOP - his flag signifies an IO is in progress on the exchange.
LPFC_NVMET_XBUSY - this flag indicates the IO completed but the firmware
is still busy with the corresponding exchange. The exchange should not be
reused until after a XRI_ABORTED_CQE is received for that exchange.
LPFC_NVMET_ABORT_OP - this flag signifies an ABORT_WQE was issued on the
exchange.
LPFC_NVMET_CTX_RLS - this flag signifies a context free was requested,
but we are deferring it due to an XBUSY or ABORT in progress.
A ctxlock is added to the context structure that is used whenever these
flags are set/read within the context of an IO.
The LPFC_NVMET_CTX_RLS flag is only set in the defer_relase routine when
the transport has resolved all IO associated with the buffer. The flag is
cleared when the CTX is associated with a new IO.
An exchange can has both an LPFC_NVMET_XBUSY and a LPFC_NVMET_ABORT_OP
condition active simultaneously. Both conditions must complete before the
exchange is freed.
When the abort callback (lpfc_nvmet_xmt_fcp_abort) is envoked:
If there is an outstanding IO, the driver will issue an ABORT_WQE. This
should result in 3 completions for the exchange:
1) IO cmpl with XB bit set
2) Abort WQE cmpl
3) XRI_ABORTED_CQE cmpl
For this scenerio, after completion #1, the NVMET Transport IO rsp
callback is called. After completion #2, no action is taken with respect
to the exchange / context. After completion #3, the exchange context is
free for re-use on another IO.
If there is no outstanding activity on the exchange, the driver will send a
ABTS to the Initiator. Upon completion of this WQE, the exchange / context
is freed for re-use on another IO.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
2017-04-21 23:05:04 +00:00
|
|
|
lpfc_ncmd->cur_iocbq.sli4_xritag,
|
2017-02-12 21:52:32 +00:00
|
|
|
lpfc_ncmd->status, lpfc_ncmd->result,
|
2019-03-12 23:30:31 +00:00
|
|
|
wcqe->parameter,
|
2017-02-12 21:52:32 +00:00
|
|
|
wcqe->total_data_placed);
|
|
|
|
nCmd->transferred_length = 0;
|
|
|
|
nCmd->rcv_rsplen = 0;
|
2017-09-07 23:27:29 +00:00
|
|
|
nCmd->status = NVME_SC_INTERNAL;
|
2017-02-12 21:52:32 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* pick up SLI4 exhange busy condition */
|
|
|
|
if (bf_get(lpfc_wcqe_c_xb, wcqe))
|
|
|
|
lpfc_ncmd->flags |= LPFC_SBUF_XBUSY;
|
|
|
|
else
|
|
|
|
lpfc_ncmd->flags &= ~LPFC_SBUF_XBUSY;
|
|
|
|
|
|
|
|
/* Update stats and complete the IO. There is
|
|
|
|
* no need for dma unprep because the nvme_transport
|
|
|
|
* owns the dma address.
|
|
|
|
*/
|
2017-02-12 21:52:33 +00:00
|
|
|
#ifdef CONFIG_SCSI_LPFC_DEBUG_FS
|
2017-09-30 00:34:33 +00:00
|
|
|
if (lpfc_ncmd->ts_cmd_start) {
|
2017-02-12 21:52:33 +00:00
|
|
|
lpfc_ncmd->ts_isr_cmpl = pwqeIn->isr_timestamp;
|
2020-03-22 18:13:02 +00:00
|
|
|
lpfc_ncmd->ts_data_io = ktime_get_ns();
|
|
|
|
phba->ktime_last_cmd = lpfc_ncmd->ts_data_io;
|
|
|
|
lpfc_io_ktime(phba, lpfc_ncmd);
|
2017-02-12 21:52:33 +00:00
|
|
|
}
|
2020-03-22 18:13:00 +00:00
|
|
|
if (unlikely(phba->hdwqstat_on & LPFC_CHECK_NVME_IO)) {
|
2019-03-28 18:06:22 +00:00
|
|
|
cpu = raw_smp_processor_id();
|
2020-03-22 18:13:00 +00:00
|
|
|
this_cpu_inc(phba->sli4_hba.c_stat->cmpl_io);
|
|
|
|
if (lpfc_ncmd->cpu != cpu)
|
|
|
|
lpfc_printf_vlog(vport,
|
|
|
|
KERN_INFO, LOG_NVME_IOERR,
|
|
|
|
"6701 CPU Check cmpl: "
|
|
|
|
"cpu %d expect %d\n",
|
|
|
|
cpu, lpfc_ncmd->cpu);
|
2017-02-12 21:52:33 +00:00
|
|
|
}
|
|
|
|
#endif
|
2017-09-30 00:34:43 +00:00
|
|
|
|
|
|
|
/* NVME targets need completion held off until the abort exchange
|
2017-11-21 00:00:40 +00:00
|
|
|
* completes unless the NVME Rport is getting unregistered.
|
2017-09-30 00:34:43 +00:00
|
|
|
*/
|
2017-11-21 00:00:40 +00:00
|
|
|
|
2017-12-09 01:18:09 +00:00
|
|
|
if (!(lpfc_ncmd->flags & LPFC_SBUF_XBUSY)) {
|
2018-01-30 23:58:51 +00:00
|
|
|
freqpriv = nCmd->private;
|
|
|
|
freqpriv->nvme_buf = NULL;
|
2017-12-09 01:18:09 +00:00
|
|
|
lpfc_ncmd->nvmeCmd = NULL;
|
2019-01-28 19:14:37 +00:00
|
|
|
spin_unlock(&lpfc_ncmd->buf_lock);
|
|
|
|
nCmd->done(nCmd);
|
|
|
|
} else
|
|
|
|
spin_unlock(&lpfc_ncmd->buf_lock);
|
2017-02-12 21:52:32 +00:00
|
|
|
|
2017-09-30 00:34:43 +00:00
|
|
|
/* Call release with XB=1 to queue the IO into the abort list. */
|
2017-02-12 21:52:32 +00:00
|
|
|
lpfc_release_nvme_buf(phba, lpfc_ncmd);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* lpfc_nvme_prep_io_cmd - Issue an NVME-over-FCP IO
|
|
|
|
* @lpfc_pnvme: Pointer to the driver's nvme instance data
|
|
|
|
* @lpfc_nvme_lport: Pointer to the driver's local port data
|
|
|
|
* @lpfc_nvme_rport: Pointer to the rport getting the @lpfc_nvme_ereq
|
|
|
|
* @lpfc_nvme_fcreq: IO request from nvme fc to driver.
|
|
|
|
* @hw_queue_handle: Driver-returned handle in lpfc_nvme_create_queue
|
|
|
|
*
|
|
|
|
* Driver registers this routine as it io request handler. This
|
|
|
|
* routine issues an fcp WQE with data from the @lpfc_nvme_fcpreq
|
|
|
|
* data structure to the rport indicated in @lpfc_nvme_rport.
|
|
|
|
*
|
|
|
|
* Return value :
|
|
|
|
* 0 - Success
|
|
|
|
* TODO: What are the failure codes.
|
|
|
|
**/
|
|
|
|
static int
|
|
|
|
lpfc_nvme_prep_io_cmd(struct lpfc_vport *vport,
|
scsi: lpfc: Adapt partitioned XRI lists to efficient sharing
The XRI get/put lists were partitioned per hardware queue. However, the
adapter rarely had sufficient resources to give a large number of resources
per queue. As such, it became common for a cpu to encounter a lack of XRI
resource and request the upper io stack to retry after returning a BUSY
condition. This occurred even though other cpus were idle and not using
their resources.
Create as efficient a scheme as possible to move resources to the cpus that
need them. Each cpu maintains a small private pool which it allocates from
for io. There is a watermark that the cpu attempts to keep in the private
pool. The private pool, when empty, pulls from a global pool from the
cpu. When the cpu's global pool is empty it will pull from other cpu's
global pool. As there many cpu global pools (1 per cpu or hardware queue
count) and as each cpu selects what cpu to pull from at different rates and
at different times, it creates a radomizing effect that minimizes the
number of cpu's that will contend with each other when the steal XRI's from
another cpu's global pool.
On io completion, a cpu will push the XRI back on to its private pool. A
watermark level is maintained for the private pool such that when it is
exceeded it will move XRI's to the CPU global pool so that other cpu's may
allocate them.
On NVME, as heartbeat commands are critical to get placed on the wire, a
single expedite pool is maintained. When a heartbeat is to be sent, it will
allocate an XRI from the expedite pool rather than the normal cpu
private/global pools. On any io completion, if a reduction in the expedite
pools is seen, it will be replenished before the XRI is placed on the cpu
private pool.
Statistics are added to aid understanding the XRI levels on each cpu and
their behaviors.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-01-28 19:14:28 +00:00
|
|
|
struct lpfc_io_buf *lpfc_ncmd,
|
2018-04-09 21:24:23 +00:00
|
|
|
struct lpfc_nodelist *pnode,
|
2019-01-28 19:14:25 +00:00
|
|
|
struct lpfc_fc4_ctrl_stat *cstat)
|
2017-02-12 21:52:32 +00:00
|
|
|
{
|
|
|
|
struct lpfc_hba *phba = vport->phba;
|
|
|
|
struct nvmefc_fcp_req *nCmd = lpfc_ncmd->nvmeCmd;
|
|
|
|
struct lpfc_iocbq *pwqeq = &(lpfc_ncmd->cur_iocbq);
|
2018-03-05 20:04:03 +00:00
|
|
|
union lpfc_wqe128 *wqe = &pwqeq->wqe;
|
2017-02-12 21:52:32 +00:00
|
|
|
uint32_t req_len;
|
|
|
|
|
2019-01-28 19:14:18 +00:00
|
|
|
if (!NLP_CHK_NODE_ACT(pnode))
|
2017-02-12 21:52:32 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* There are three possibilities here - use scatter-gather segment, use
|
|
|
|
* the single mapping, or neither.
|
|
|
|
*/
|
|
|
|
if (nCmd->sg_cnt) {
|
|
|
|
if (nCmd->io_dir == NVMEFC_FCP_WRITE) {
|
2018-03-05 20:04:04 +00:00
|
|
|
/* From the iwrite template, initialize words 7 - 11 */
|
|
|
|
memcpy(&wqe->words[7],
|
|
|
|
&lpfc_iwrite_cmd_template.words[7],
|
|
|
|
sizeof(uint32_t) * 5);
|
|
|
|
|
|
|
|
/* Word 4 */
|
|
|
|
wqe->fcp_iwrite.total_xfer_len = nCmd->payload_length;
|
|
|
|
|
2017-02-12 21:52:32 +00:00
|
|
|
/* Word 5 */
|
|
|
|
if ((phba->cfg_nvme_enable_fb) &&
|
|
|
|
(pnode->nlp_flag & NLP_FIRSTBURST)) {
|
|
|
|
req_len = lpfc_ncmd->nvmeCmd->payload_length;
|
|
|
|
if (req_len < pnode->nvme_fb_size)
|
|
|
|
wqe->fcp_iwrite.initial_xfer_len =
|
|
|
|
req_len;
|
|
|
|
else
|
|
|
|
wqe->fcp_iwrite.initial_xfer_len =
|
|
|
|
pnode->nvme_fb_size;
|
2018-03-05 20:04:04 +00:00
|
|
|
} else {
|
|
|
|
wqe->fcp_iwrite.initial_xfer_len = 0;
|
2017-02-12 21:52:32 +00:00
|
|
|
}
|
2019-01-28 19:14:25 +00:00
|
|
|
cstat->output_requests++;
|
2017-02-12 21:52:32 +00:00
|
|
|
} else {
|
2018-03-05 20:04:04 +00:00
|
|
|
/* From the iread template, initialize words 7 - 11 */
|
|
|
|
memcpy(&wqe->words[7],
|
|
|
|
&lpfc_iread_cmd_template.words[7],
|
|
|
|
sizeof(uint32_t) * 5);
|
|
|
|
|
|
|
|
/* Word 4 */
|
|
|
|
wqe->fcp_iread.total_xfer_len = nCmd->payload_length;
|
|
|
|
|
|
|
|
/* Word 5 */
|
|
|
|
wqe->fcp_iread.rsrvd5 = 0;
|
2017-02-12 21:52:32 +00:00
|
|
|
|
2019-01-28 19:14:25 +00:00
|
|
|
cstat->input_requests++;
|
2017-02-12 21:52:32 +00:00
|
|
|
}
|
|
|
|
} else {
|
2018-03-05 20:04:04 +00:00
|
|
|
/* From the icmnd template, initialize words 4 - 11 */
|
|
|
|
memcpy(&wqe->words[4], &lpfc_icmnd_cmd_template.words[4],
|
|
|
|
sizeof(uint32_t) * 8);
|
2019-01-28 19:14:25 +00:00
|
|
|
cstat->control_requests++;
|
2017-02-12 21:52:32 +00:00
|
|
|
}
|
2019-08-14 23:57:10 +00:00
|
|
|
|
|
|
|
if (pnode->nlp_nvme_info & NLP_NVME_NSLER)
|
|
|
|
bf_set(wqe_erp, &wqe->generic.wqe_com, 1);
|
2017-02-12 21:52:32 +00:00
|
|
|
/*
|
|
|
|
* Finish initializing those WQE fields that are independent
|
|
|
|
* of the nvme_cmnd request_buffer
|
|
|
|
*/
|
|
|
|
|
2018-03-05 20:04:04 +00:00
|
|
|
/* Word 3 */
|
|
|
|
bf_set(payload_offset_len, &wqe->fcp_icmd,
|
|
|
|
(nCmd->rsplen + nCmd->cmdlen));
|
|
|
|
|
2017-02-12 21:52:32 +00:00
|
|
|
/* Word 6 */
|
|
|
|
bf_set(wqe_ctxt_tag, &wqe->generic.wqe_com,
|
|
|
|
phba->sli4_hba.rpi_ids[pnode->nlp_rpi]);
|
|
|
|
bf_set(wqe_xri_tag, &wqe->generic.wqe_com, pwqeq->sli4_xritag);
|
|
|
|
|
|
|
|
/* Word 8 */
|
|
|
|
wqe->generic.wqe_com.abort_tag = pwqeq->iotag;
|
|
|
|
|
|
|
|
/* Word 9 */
|
|
|
|
bf_set(wqe_reqtag, &wqe->generic.wqe_com, pwqeq->iotag);
|
|
|
|
|
2018-06-26 15:24:26 +00:00
|
|
|
/* Words 13 14 15 are for PBDE support */
|
|
|
|
|
2017-02-12 21:52:32 +00:00
|
|
|
pwqeq->vport = vport;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* lpfc_nvme_prep_io_dma - Issue an NVME-over-FCP IO
|
|
|
|
* @lpfc_pnvme: Pointer to the driver's nvme instance data
|
|
|
|
* @lpfc_nvme_lport: Pointer to the driver's local port data
|
|
|
|
* @lpfc_nvme_rport: Pointer to the rport getting the @lpfc_nvme_ereq
|
|
|
|
* @lpfc_nvme_fcreq: IO request from nvme fc to driver.
|
|
|
|
* @hw_queue_handle: Driver-returned handle in lpfc_nvme_create_queue
|
|
|
|
*
|
|
|
|
* Driver registers this routine as it io request handler. This
|
|
|
|
* routine issues an fcp WQE with data from the @lpfc_nvme_fcpreq
|
|
|
|
* data structure to the rport indicated in @lpfc_nvme_rport.
|
|
|
|
*
|
|
|
|
* Return value :
|
|
|
|
* 0 - Success
|
|
|
|
* TODO: What are the failure codes.
|
|
|
|
**/
|
|
|
|
static int
|
|
|
|
lpfc_nvme_prep_io_dma(struct lpfc_vport *vport,
|
scsi: lpfc: Adapt partitioned XRI lists to efficient sharing
The XRI get/put lists were partitioned per hardware queue. However, the
adapter rarely had sufficient resources to give a large number of resources
per queue. As such, it became common for a cpu to encounter a lack of XRI
resource and request the upper io stack to retry after returning a BUSY
condition. This occurred even though other cpus were idle and not using
their resources.
Create as efficient a scheme as possible to move resources to the cpus that
need them. Each cpu maintains a small private pool which it allocates from
for io. There is a watermark that the cpu attempts to keep in the private
pool. The private pool, when empty, pulls from a global pool from the
cpu. When the cpu's global pool is empty it will pull from other cpu's
global pool. As there many cpu global pools (1 per cpu or hardware queue
count) and as each cpu selects what cpu to pull from at different rates and
at different times, it creates a radomizing effect that minimizes the
number of cpu's that will contend with each other when the steal XRI's from
another cpu's global pool.
On io completion, a cpu will push the XRI back on to its private pool. A
watermark level is maintained for the private pool such that when it is
exceeded it will move XRI's to the CPU global pool so that other cpu's may
allocate them.
On NVME, as heartbeat commands are critical to get placed on the wire, a
single expedite pool is maintained. When a heartbeat is to be sent, it will
allocate an XRI from the expedite pool rather than the normal cpu
private/global pools. On any io completion, if a reduction in the expedite
pools is seen, it will be replenished before the XRI is placed on the cpu
private pool.
Statistics are added to aid understanding the XRI levels on each cpu and
their behaviors.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-01-28 19:14:28 +00:00
|
|
|
struct lpfc_io_buf *lpfc_ncmd)
|
2017-02-12 21:52:32 +00:00
|
|
|
{
|
|
|
|
struct lpfc_hba *phba = vport->phba;
|
|
|
|
struct nvmefc_fcp_req *nCmd = lpfc_ncmd->nvmeCmd;
|
2018-03-05 20:04:03 +00:00
|
|
|
union lpfc_wqe128 *wqe = &lpfc_ncmd->cur_iocbq.wqe;
|
2019-01-28 19:14:19 +00:00
|
|
|
struct sli4_sge *sgl = lpfc_ncmd->dma_sgl;
|
scsi: lpfc: Support dynamic unbounded SGL lists on G7 hardware.
Typical SLI-4 hardware supports up to 2 4KB pages to be registered per XRI
to contain the exchanges Scatter/Gather List. This caps the number of SGL
elements that can be in the SGL. There are not extensions to extend the
list out of the 2 pages.
The G7 hardware adds a SGE type that allows the SGL to be vectored to a
different scatter/gather list segment. And that segment can contain a SGE
to go to another segment and so on. The initial segment must still be
pre-registered for the XRI, but it can be a much smaller amount (256Bytes)
as it can now be dynamically grown. This much smaller allocation can
handle the SG list for most normal I/O, and the dynamic aspect allows it to
support many MB's if needed.
The implementation creates a pool which contains "segments" and which is
initially sized to hold the initial small segment per xri. If an I/O
requires additional segments, they are allocated from the pool. If the
pool has no more segments, the pool is grown based on what is now
needed. After the I/O completes, the additional segments are returned to
the pool for use by other I/Os. Once allocated, the additional segments are
not released under the assumption of "if needed once, it will be needed
again". Pools are kept on a per-hardware queue basis, which is typically
1:1 per cpu, but may be shared by multiple cpus.
The switch to the smaller initial allocation significantly reduces the
memory footprint of the driver (which only grows if large ios are
issued). Based on the several K of XRIs for the adapter, the 8KB->256B
reduction can conserve 32MBs or more.
It has been observed with per-cpu resource pools that allocating a resource
on CPU A, may be put back on CPU B. While the get routines are distributed
evenly, only a limited subset of CPUs may be handling the put routines.
This can put a strain on the lpfc_put_cmd_rsp_buf_per_cpu routine because
all the resources are being put on a limited subset of CPUs.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-08-14 23:57:09 +00:00
|
|
|
struct sli4_hybrid_sgl *sgl_xtra = NULL;
|
2017-02-12 21:52:32 +00:00
|
|
|
struct scatterlist *data_sg;
|
|
|
|
struct sli4_sge *first_data_sgl;
|
2018-02-22 16:18:48 +00:00
|
|
|
struct ulp_bde64 *bde;
|
scsi: lpfc: Support dynamic unbounded SGL lists on G7 hardware.
Typical SLI-4 hardware supports up to 2 4KB pages to be registered per XRI
to contain the exchanges Scatter/Gather List. This caps the number of SGL
elements that can be in the SGL. There are not extensions to extend the
list out of the 2 pages.
The G7 hardware adds a SGE type that allows the SGL to be vectored to a
different scatter/gather list segment. And that segment can contain a SGE
to go to another segment and so on. The initial segment must still be
pre-registered for the XRI, but it can be a much smaller amount (256Bytes)
as it can now be dynamically grown. This much smaller allocation can
handle the SG list for most normal I/O, and the dynamic aspect allows it to
support many MB's if needed.
The implementation creates a pool which contains "segments" and which is
initially sized to hold the initial small segment per xri. If an I/O
requires additional segments, they are allocated from the pool. If the
pool has no more segments, the pool is grown based on what is now
needed. After the I/O completes, the additional segments are returned to
the pool for use by other I/Os. Once allocated, the additional segments are
not released under the assumption of "if needed once, it will be needed
again". Pools are kept on a per-hardware queue basis, which is typically
1:1 per cpu, but may be shared by multiple cpus.
The switch to the smaller initial allocation significantly reduces the
memory footprint of the driver (which only grows if large ios are
issued). Based on the several K of XRIs for the adapter, the 8KB->256B
reduction can conserve 32MBs or more.
It has been observed with per-cpu resource pools that allocating a resource
on CPU A, may be put back on CPU B. While the get routines are distributed
evenly, only a limited subset of CPUs may be handling the put routines.
This can put a strain on the lpfc_put_cmd_rsp_buf_per_cpu routine because
all the resources are being put on a limited subset of CPUs.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-08-14 23:57:09 +00:00
|
|
|
dma_addr_t physaddr = 0;
|
2017-02-12 21:52:32 +00:00
|
|
|
uint32_t num_bde = 0;
|
scsi: lpfc: Support dynamic unbounded SGL lists on G7 hardware.
Typical SLI-4 hardware supports up to 2 4KB pages to be registered per XRI
to contain the exchanges Scatter/Gather List. This caps the number of SGL
elements that can be in the SGL. There are not extensions to extend the
list out of the 2 pages.
The G7 hardware adds a SGE type that allows the SGL to be vectored to a
different scatter/gather list segment. And that segment can contain a SGE
to go to another segment and so on. The initial segment must still be
pre-registered for the XRI, but it can be a much smaller amount (256Bytes)
as it can now be dynamically grown. This much smaller allocation can
handle the SG list for most normal I/O, and the dynamic aspect allows it to
support many MB's if needed.
The implementation creates a pool which contains "segments" and which is
initially sized to hold the initial small segment per xri. If an I/O
requires additional segments, they are allocated from the pool. If the
pool has no more segments, the pool is grown based on what is now
needed. After the I/O completes, the additional segments are returned to
the pool for use by other I/Os. Once allocated, the additional segments are
not released under the assumption of "if needed once, it will be needed
again". Pools are kept on a per-hardware queue basis, which is typically
1:1 per cpu, but may be shared by multiple cpus.
The switch to the smaller initial allocation significantly reduces the
memory footprint of the driver (which only grows if large ios are
issued). Based on the several K of XRIs for the adapter, the 8KB->256B
reduction can conserve 32MBs or more.
It has been observed with per-cpu resource pools that allocating a resource
on CPU A, may be put back on CPU B. While the get routines are distributed
evenly, only a limited subset of CPUs may be handling the put routines.
This can put a strain on the lpfc_put_cmd_rsp_buf_per_cpu routine because
all the resources are being put on a limited subset of CPUs.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-08-14 23:57:09 +00:00
|
|
|
uint32_t dma_len = 0;
|
2017-02-12 21:52:32 +00:00
|
|
|
uint32_t dma_offset = 0;
|
scsi: lpfc: Support dynamic unbounded SGL lists on G7 hardware.
Typical SLI-4 hardware supports up to 2 4KB pages to be registered per XRI
to contain the exchanges Scatter/Gather List. This caps the number of SGL
elements that can be in the SGL. There are not extensions to extend the
list out of the 2 pages.
The G7 hardware adds a SGE type that allows the SGL to be vectored to a
different scatter/gather list segment. And that segment can contain a SGE
to go to another segment and so on. The initial segment must still be
pre-registered for the XRI, but it can be a much smaller amount (256Bytes)
as it can now be dynamically grown. This much smaller allocation can
handle the SG list for most normal I/O, and the dynamic aspect allows it to
support many MB's if needed.
The implementation creates a pool which contains "segments" and which is
initially sized to hold the initial small segment per xri. If an I/O
requires additional segments, they are allocated from the pool. If the
pool has no more segments, the pool is grown based on what is now
needed. After the I/O completes, the additional segments are returned to
the pool for use by other I/Os. Once allocated, the additional segments are
not released under the assumption of "if needed once, it will be needed
again". Pools are kept on a per-hardware queue basis, which is typically
1:1 per cpu, but may be shared by multiple cpus.
The switch to the smaller initial allocation significantly reduces the
memory footprint of the driver (which only grows if large ios are
issued). Based on the several K of XRIs for the adapter, the 8KB->256B
reduction can conserve 32MBs or more.
It has been observed with per-cpu resource pools that allocating a resource
on CPU A, may be put back on CPU B. While the get routines are distributed
evenly, only a limited subset of CPUs may be handling the put routines.
This can put a strain on the lpfc_put_cmd_rsp_buf_per_cpu routine because
all the resources are being put on a limited subset of CPUs.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-08-14 23:57:09 +00:00
|
|
|
int nseg, i, j;
|
|
|
|
bool lsp_just_set = false;
|
2017-02-12 21:52:32 +00:00
|
|
|
|
|
|
|
/* Fix up the command and response DMA stuff. */
|
|
|
|
lpfc_nvme_adj_fcp_sgls(vport, lpfc_ncmd, nCmd);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* There are three possibilities here - use scatter-gather segment, use
|
|
|
|
* the single mapping, or neither.
|
|
|
|
*/
|
|
|
|
if (nCmd->sg_cnt) {
|
|
|
|
/*
|
|
|
|
* Jump over the cmd and rsp SGEs. The fix routine
|
|
|
|
* has already adjusted for this.
|
|
|
|
*/
|
|
|
|
sgl += 2;
|
|
|
|
|
|
|
|
first_data_sgl = sgl;
|
|
|
|
lpfc_ncmd->seg_cnt = nCmd->sg_cnt;
|
2017-11-21 00:00:43 +00:00
|
|
|
if (lpfc_ncmd->seg_cnt > lpfc_nvme_template.max_sgl_segments) {
|
2017-02-12 21:52:32 +00:00
|
|
|
lpfc_printf_log(phba, KERN_ERR, LOG_NVME_IOERR,
|
|
|
|
"6058 Too many sg segments from "
|
|
|
|
"NVME Transport. Max %d, "
|
|
|
|
"nvmeIO sg_cnt %d\n",
|
2017-09-30 00:34:46 +00:00
|
|
|
phba->cfg_nvme_seg_cnt + 1,
|
2017-02-12 21:52:32 +00:00
|
|
|
lpfc_ncmd->seg_cnt);
|
|
|
|
lpfc_ncmd->seg_cnt = 0;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The driver established a maximum scatter-gather segment count
|
|
|
|
* during probe that limits the number of sg elements in any
|
|
|
|
* single nvme command. Just run through the seg_cnt and format
|
|
|
|
* the sge's.
|
|
|
|
*/
|
|
|
|
nseg = nCmd->sg_cnt;
|
|
|
|
data_sg = nCmd->first_sgl;
|
scsi: lpfc: Support dynamic unbounded SGL lists on G7 hardware.
Typical SLI-4 hardware supports up to 2 4KB pages to be registered per XRI
to contain the exchanges Scatter/Gather List. This caps the number of SGL
elements that can be in the SGL. There are not extensions to extend the
list out of the 2 pages.
The G7 hardware adds a SGE type that allows the SGL to be vectored to a
different scatter/gather list segment. And that segment can contain a SGE
to go to another segment and so on. The initial segment must still be
pre-registered for the XRI, but it can be a much smaller amount (256Bytes)
as it can now be dynamically grown. This much smaller allocation can
handle the SG list for most normal I/O, and the dynamic aspect allows it to
support many MB's if needed.
The implementation creates a pool which contains "segments" and which is
initially sized to hold the initial small segment per xri. If an I/O
requires additional segments, they are allocated from the pool. If the
pool has no more segments, the pool is grown based on what is now
needed. After the I/O completes, the additional segments are returned to
the pool for use by other I/Os. Once allocated, the additional segments are
not released under the assumption of "if needed once, it will be needed
again". Pools are kept on a per-hardware queue basis, which is typically
1:1 per cpu, but may be shared by multiple cpus.
The switch to the smaller initial allocation significantly reduces the
memory footprint of the driver (which only grows if large ios are
issued). Based on the several K of XRIs for the adapter, the 8KB->256B
reduction can conserve 32MBs or more.
It has been observed with per-cpu resource pools that allocating a resource
on CPU A, may be put back on CPU B. While the get routines are distributed
evenly, only a limited subset of CPUs may be handling the put routines.
This can put a strain on the lpfc_put_cmd_rsp_buf_per_cpu routine because
all the resources are being put on a limited subset of CPUs.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-08-14 23:57:09 +00:00
|
|
|
|
|
|
|
/* for tracking the segment boundaries */
|
|
|
|
j = 2;
|
2017-02-12 21:52:32 +00:00
|
|
|
for (i = 0; i < nseg; i++) {
|
|
|
|
if (data_sg == NULL) {
|
|
|
|
lpfc_printf_log(phba, KERN_ERR, LOG_NVME_IOERR,
|
|
|
|
"6059 dptr err %d, nseg %d\n",
|
|
|
|
i, nseg);
|
|
|
|
lpfc_ncmd->seg_cnt = 0;
|
|
|
|
return 1;
|
|
|
|
}
|
scsi: lpfc: Support dynamic unbounded SGL lists on G7 hardware.
Typical SLI-4 hardware supports up to 2 4KB pages to be registered per XRI
to contain the exchanges Scatter/Gather List. This caps the number of SGL
elements that can be in the SGL. There are not extensions to extend the
list out of the 2 pages.
The G7 hardware adds a SGE type that allows the SGL to be vectored to a
different scatter/gather list segment. And that segment can contain a SGE
to go to another segment and so on. The initial segment must still be
pre-registered for the XRI, but it can be a much smaller amount (256Bytes)
as it can now be dynamically grown. This much smaller allocation can
handle the SG list for most normal I/O, and the dynamic aspect allows it to
support many MB's if needed.
The implementation creates a pool which contains "segments" and which is
initially sized to hold the initial small segment per xri. If an I/O
requires additional segments, they are allocated from the pool. If the
pool has no more segments, the pool is grown based on what is now
needed. After the I/O completes, the additional segments are returned to
the pool for use by other I/Os. Once allocated, the additional segments are
not released under the assumption of "if needed once, it will be needed
again". Pools are kept on a per-hardware queue basis, which is typically
1:1 per cpu, but may be shared by multiple cpus.
The switch to the smaller initial allocation significantly reduces the
memory footprint of the driver (which only grows if large ios are
issued). Based on the several K of XRIs for the adapter, the 8KB->256B
reduction can conserve 32MBs or more.
It has been observed with per-cpu resource pools that allocating a resource
on CPU A, may be put back on CPU B. While the get routines are distributed
evenly, only a limited subset of CPUs may be handling the put routines.
This can put a strain on the lpfc_put_cmd_rsp_buf_per_cpu routine because
all the resources are being put on a limited subset of CPUs.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-08-14 23:57:09 +00:00
|
|
|
|
|
|
|
sgl->word2 = 0;
|
|
|
|
if ((num_bde + 1) == nseg) {
|
2017-02-12 21:52:32 +00:00
|
|
|
bf_set(lpfc_sli4_sge_last, sgl, 1);
|
scsi: lpfc: Support dynamic unbounded SGL lists on G7 hardware.
Typical SLI-4 hardware supports up to 2 4KB pages to be registered per XRI
to contain the exchanges Scatter/Gather List. This caps the number of SGL
elements that can be in the SGL. There are not extensions to extend the
list out of the 2 pages.
The G7 hardware adds a SGE type that allows the SGL to be vectored to a
different scatter/gather list segment. And that segment can contain a SGE
to go to another segment and so on. The initial segment must still be
pre-registered for the XRI, but it can be a much smaller amount (256Bytes)
as it can now be dynamically grown. This much smaller allocation can
handle the SG list for most normal I/O, and the dynamic aspect allows it to
support many MB's if needed.
The implementation creates a pool which contains "segments" and which is
initially sized to hold the initial small segment per xri. If an I/O
requires additional segments, they are allocated from the pool. If the
pool has no more segments, the pool is grown based on what is now
needed. After the I/O completes, the additional segments are returned to
the pool for use by other I/Os. Once allocated, the additional segments are
not released under the assumption of "if needed once, it will be needed
again". Pools are kept on a per-hardware queue basis, which is typically
1:1 per cpu, but may be shared by multiple cpus.
The switch to the smaller initial allocation significantly reduces the
memory footprint of the driver (which only grows if large ios are
issued). Based on the several K of XRIs for the adapter, the 8KB->256B
reduction can conserve 32MBs or more.
It has been observed with per-cpu resource pools that allocating a resource
on CPU A, may be put back on CPU B. While the get routines are distributed
evenly, only a limited subset of CPUs may be handling the put routines.
This can put a strain on the lpfc_put_cmd_rsp_buf_per_cpu routine because
all the resources are being put on a limited subset of CPUs.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-08-14 23:57:09 +00:00
|
|
|
bf_set(lpfc_sli4_sge_type, sgl,
|
|
|
|
LPFC_SGE_TYPE_DATA);
|
|
|
|
} else {
|
2017-02-12 21:52:32 +00:00
|
|
|
bf_set(lpfc_sli4_sge_last, sgl, 0);
|
scsi: lpfc: Support dynamic unbounded SGL lists on G7 hardware.
Typical SLI-4 hardware supports up to 2 4KB pages to be registered per XRI
to contain the exchanges Scatter/Gather List. This caps the number of SGL
elements that can be in the SGL. There are not extensions to extend the
list out of the 2 pages.
The G7 hardware adds a SGE type that allows the SGL to be vectored to a
different scatter/gather list segment. And that segment can contain a SGE
to go to another segment and so on. The initial segment must still be
pre-registered for the XRI, but it can be a much smaller amount (256Bytes)
as it can now be dynamically grown. This much smaller allocation can
handle the SG list for most normal I/O, and the dynamic aspect allows it to
support many MB's if needed.
The implementation creates a pool which contains "segments" and which is
initially sized to hold the initial small segment per xri. If an I/O
requires additional segments, they are allocated from the pool. If the
pool has no more segments, the pool is grown based on what is now
needed. After the I/O completes, the additional segments are returned to
the pool for use by other I/Os. Once allocated, the additional segments are
not released under the assumption of "if needed once, it will be needed
again". Pools are kept on a per-hardware queue basis, which is typically
1:1 per cpu, but may be shared by multiple cpus.
The switch to the smaller initial allocation significantly reduces the
memory footprint of the driver (which only grows if large ios are
issued). Based on the several K of XRIs for the adapter, the 8KB->256B
reduction can conserve 32MBs or more.
It has been observed with per-cpu resource pools that allocating a resource
on CPU A, may be put back on CPU B. While the get routines are distributed
evenly, only a limited subset of CPUs may be handling the put routines.
This can put a strain on the lpfc_put_cmd_rsp_buf_per_cpu routine because
all the resources are being put on a limited subset of CPUs.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-08-14 23:57:09 +00:00
|
|
|
|
|
|
|
/* expand the segment */
|
|
|
|
if (!lsp_just_set &&
|
|
|
|
!((j + 1) % phba->border_sge_num) &&
|
|
|
|
((nseg - 1) != i)) {
|
|
|
|
/* set LSP type */
|
|
|
|
bf_set(lpfc_sli4_sge_type, sgl,
|
|
|
|
LPFC_SGE_TYPE_LSP);
|
|
|
|
|
|
|
|
sgl_xtra = lpfc_get_sgl_per_hdwq(
|
|
|
|
phba, lpfc_ncmd);
|
|
|
|
|
|
|
|
if (unlikely(!sgl_xtra)) {
|
|
|
|
lpfc_ncmd->seg_cnt = 0;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
sgl->addr_lo = cpu_to_le32(putPaddrLow(
|
|
|
|
sgl_xtra->dma_phys_sgl));
|
|
|
|
sgl->addr_hi = cpu_to_le32(putPaddrHigh(
|
|
|
|
sgl_xtra->dma_phys_sgl));
|
|
|
|
|
|
|
|
} else {
|
|
|
|
bf_set(lpfc_sli4_sge_type, sgl,
|
|
|
|
LPFC_SGE_TYPE_DATA);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!(bf_get(lpfc_sli4_sge_type, sgl) &
|
|
|
|
LPFC_SGE_TYPE_LSP)) {
|
|
|
|
if ((nseg - 1) == i)
|
|
|
|
bf_set(lpfc_sli4_sge_last, sgl, 1);
|
|
|
|
|
|
|
|
physaddr = data_sg->dma_address;
|
|
|
|
dma_len = data_sg->length;
|
|
|
|
sgl->addr_lo = cpu_to_le32(
|
|
|
|
putPaddrLow(physaddr));
|
|
|
|
sgl->addr_hi = cpu_to_le32(
|
|
|
|
putPaddrHigh(physaddr));
|
|
|
|
|
|
|
|
bf_set(lpfc_sli4_sge_offset, sgl, dma_offset);
|
|
|
|
sgl->word2 = cpu_to_le32(sgl->word2);
|
|
|
|
sgl->sge_len = cpu_to_le32(dma_len);
|
|
|
|
|
|
|
|
dma_offset += dma_len;
|
|
|
|
data_sg = sg_next(data_sg);
|
|
|
|
|
|
|
|
sgl++;
|
|
|
|
|
|
|
|
lsp_just_set = false;
|
|
|
|
} else {
|
|
|
|
sgl->word2 = cpu_to_le32(sgl->word2);
|
|
|
|
|
|
|
|
sgl->sge_len = cpu_to_le32(
|
|
|
|
phba->cfg_sg_dma_buf_size);
|
|
|
|
|
|
|
|
sgl = (struct sli4_sge *)sgl_xtra->dma_sgl;
|
|
|
|
i = i - 1;
|
|
|
|
|
|
|
|
lsp_just_set = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
j++;
|
2017-02-12 21:52:32 +00:00
|
|
|
}
|
2018-06-26 15:24:26 +00:00
|
|
|
if (phba->cfg_enable_pbde) {
|
2018-02-22 16:18:48 +00:00
|
|
|
/* Use PBDE support for first SGL only, offset == 0 */
|
|
|
|
/* Words 13-15 */
|
|
|
|
bde = (struct ulp_bde64 *)
|
|
|
|
&wqe->words[13];
|
|
|
|
bde->addrLow = first_data_sgl->addr_lo;
|
|
|
|
bde->addrHigh = first_data_sgl->addr_hi;
|
|
|
|
bde->tus.f.bdeSize =
|
|
|
|
le32_to_cpu(first_data_sgl->sge_len);
|
|
|
|
bde->tus.f.bdeFlags = BUFF_TYPE_BDE_64;
|
|
|
|
bde->tus.w = cpu_to_le32(bde->tus.w);
|
2018-03-05 20:04:04 +00:00
|
|
|
/* wqe_pbde is 1 in template */
|
|
|
|
} else {
|
|
|
|
memset(&wqe->words[13], 0, (sizeof(uint32_t) * 3));
|
2018-02-22 16:18:48 +00:00
|
|
|
bf_set(wqe_pbde, &wqe->generic.wqe_com, 0);
|
2018-03-05 20:04:04 +00:00
|
|
|
}
|
2018-02-22 16:18:48 +00:00
|
|
|
|
2018-06-26 15:24:26 +00:00
|
|
|
} else {
|
2019-01-28 19:14:19 +00:00
|
|
|
lpfc_ncmd->seg_cnt = 0;
|
|
|
|
|
2017-02-12 21:52:32 +00:00
|
|
|
/* For this clause to be valid, the payload_length
|
|
|
|
* and sg_cnt must zero.
|
|
|
|
*/
|
|
|
|
if (nCmd->payload_length != 0) {
|
|
|
|
lpfc_printf_log(phba, KERN_ERR, LOG_NVME_IOERR,
|
|
|
|
"6063 NVME DMA Prep Err: sg_cnt %d "
|
|
|
|
"payload_length x%x\n",
|
|
|
|
nCmd->sg_cnt, nCmd->payload_length);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* lpfc_nvme_fcp_io_submit - Issue an NVME-over-FCP IO
|
|
|
|
* @lpfc_pnvme: Pointer to the driver's nvme instance data
|
|
|
|
* @lpfc_nvme_lport: Pointer to the driver's local port data
|
|
|
|
* @lpfc_nvme_rport: Pointer to the rport getting the @lpfc_nvme_ereq
|
|
|
|
* @lpfc_nvme_fcreq: IO request from nvme fc to driver.
|
|
|
|
* @hw_queue_handle: Driver-returned handle in lpfc_nvme_create_queue
|
|
|
|
*
|
|
|
|
* Driver registers this routine as it io request handler. This
|
|
|
|
* routine issues an fcp WQE with data from the @lpfc_nvme_fcpreq
|
|
|
|
* data structure to the rport
|
|
|
|
indicated in @lpfc_nvme_rport.
|
|
|
|
*
|
|
|
|
* Return value :
|
|
|
|
* 0 - Success
|
|
|
|
* TODO: What are the failure codes.
|
|
|
|
**/
|
|
|
|
static int
|
|
|
|
lpfc_nvme_fcp_io_submit(struct nvme_fc_local_port *pnvme_lport,
|
|
|
|
struct nvme_fc_remote_port *pnvme_rport,
|
|
|
|
void *hw_queue_handle,
|
|
|
|
struct nvmefc_fcp_req *pnvme_fcreq)
|
|
|
|
{
|
|
|
|
int ret = 0;
|
2017-12-09 01:18:03 +00:00
|
|
|
int expedite = 0;
|
2019-01-28 19:14:24 +00:00
|
|
|
int idx, cpu;
|
2017-02-12 21:52:32 +00:00
|
|
|
struct lpfc_nvme_lport *lport;
|
2019-01-28 19:14:25 +00:00
|
|
|
struct lpfc_fc4_ctrl_stat *cstat;
|
2017-02-12 21:52:32 +00:00
|
|
|
struct lpfc_vport *vport;
|
|
|
|
struct lpfc_hba *phba;
|
|
|
|
struct lpfc_nodelist *ndlp;
|
scsi: lpfc: Adapt partitioned XRI lists to efficient sharing
The XRI get/put lists were partitioned per hardware queue. However, the
adapter rarely had sufficient resources to give a large number of resources
per queue. As such, it became common for a cpu to encounter a lack of XRI
resource and request the upper io stack to retry after returning a BUSY
condition. This occurred even though other cpus were idle and not using
their resources.
Create as efficient a scheme as possible to move resources to the cpus that
need them. Each cpu maintains a small private pool which it allocates from
for io. There is a watermark that the cpu attempts to keep in the private
pool. The private pool, when empty, pulls from a global pool from the
cpu. When the cpu's global pool is empty it will pull from other cpu's
global pool. As there many cpu global pools (1 per cpu or hardware queue
count) and as each cpu selects what cpu to pull from at different rates and
at different times, it creates a radomizing effect that minimizes the
number of cpu's that will contend with each other when the steal XRI's from
another cpu's global pool.
On io completion, a cpu will push the XRI back on to its private pool. A
watermark level is maintained for the private pool such that when it is
exceeded it will move XRI's to the CPU global pool so that other cpu's may
allocate them.
On NVME, as heartbeat commands are critical to get placed on the wire, a
single expedite pool is maintained. When a heartbeat is to be sent, it will
allocate an XRI from the expedite pool rather than the normal cpu
private/global pools. On any io completion, if a reduction in the expedite
pools is seen, it will be replenished before the XRI is placed on the cpu
private pool.
Statistics are added to aid understanding the XRI levels on each cpu and
their behaviors.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-01-28 19:14:28 +00:00
|
|
|
struct lpfc_io_buf *lpfc_ncmd;
|
2017-02-12 21:52:32 +00:00
|
|
|
struct lpfc_nvme_rport *rport;
|
|
|
|
struct lpfc_nvme_qhandle *lpfc_queue_info;
|
2017-11-21 00:00:42 +00:00
|
|
|
struct lpfc_nvme_fcpreq_priv *freqpriv;
|
2017-12-09 01:18:03 +00:00
|
|
|
struct nvme_common_command *sqe;
|
2017-02-12 21:52:33 +00:00
|
|
|
#ifdef CONFIG_SCSI_LPFC_DEBUG_FS
|
|
|
|
uint64_t start = 0;
|
|
|
|
#endif
|
2017-02-12 21:52:32 +00:00
|
|
|
|
2017-11-21 00:00:42 +00:00
|
|
|
/* Validate pointers. LLDD fault handling with transport does
|
|
|
|
* have timing races.
|
|
|
|
*/
|
2017-02-12 21:52:32 +00:00
|
|
|
lport = (struct lpfc_nvme_lport *)pnvme_lport->private;
|
2017-11-21 00:00:42 +00:00
|
|
|
if (unlikely(!lport)) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto out_fail;
|
|
|
|
}
|
|
|
|
|
2017-02-12 21:52:32 +00:00
|
|
|
vport = lport->vport;
|
2017-11-21 00:00:42 +00:00
|
|
|
|
|
|
|
if (unlikely(!hw_queue_handle)) {
|
2018-05-05 03:37:56 +00:00
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_IOERR,
|
|
|
|
"6117 Fail IO, NULL hw_queue_handle\n");
|
|
|
|
atomic_inc(&lport->xmt_fcp_err);
|
2018-05-05 03:37:50 +00:00
|
|
|
ret = -EBUSY;
|
2017-11-21 00:00:42 +00:00
|
|
|
goto out_fail;
|
|
|
|
}
|
|
|
|
|
2017-02-12 21:52:32 +00:00
|
|
|
phba = vport->phba;
|
|
|
|
|
2017-09-30 00:34:45 +00:00
|
|
|
if (vport->load_flag & FC_UNLOADING) {
|
|
|
|
ret = -ENODEV;
|
|
|
|
goto out_fail;
|
|
|
|
}
|
|
|
|
|
2019-08-14 23:57:05 +00:00
|
|
|
if (unlikely(vport->load_flag & FC_UNLOADING)) {
|
2018-05-05 03:37:56 +00:00
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_IOERR,
|
|
|
|
"6124 Fail IO, Driver unload\n");
|
|
|
|
atomic_inc(&lport->xmt_fcp_err);
|
2017-11-21 00:00:41 +00:00
|
|
|
ret = -ENODEV;
|
|
|
|
goto out_fail;
|
|
|
|
}
|
|
|
|
|
2017-11-21 00:00:42 +00:00
|
|
|
freqpriv = pnvme_fcreq->private;
|
|
|
|
if (unlikely(!freqpriv)) {
|
2018-05-05 03:37:56 +00:00
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_IOERR,
|
|
|
|
"6158 Fail IO, NULL request data\n");
|
|
|
|
atomic_inc(&lport->xmt_fcp_err);
|
2017-11-21 00:00:42 +00:00
|
|
|
ret = -EINVAL;
|
2017-09-30 00:34:41 +00:00
|
|
|
goto out_fail;
|
|
|
|
}
|
|
|
|
|
2017-02-12 21:52:33 +00:00
|
|
|
#ifdef CONFIG_SCSI_LPFC_DEBUG_FS
|
|
|
|
if (phba->ktime_on)
|
|
|
|
start = ktime_get_ns();
|
|
|
|
#endif
|
2017-02-12 21:52:32 +00:00
|
|
|
rport = (struct lpfc_nvme_rport *)pnvme_rport->private;
|
|
|
|
lpfc_queue_info = (struct lpfc_nvme_qhandle *)hw_queue_handle;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Catch race where our node has transitioned, but the
|
|
|
|
* transport is still transitioning.
|
|
|
|
*/
|
|
|
|
ndlp = rport->ndlp;
|
|
|
|
if (!ndlp || !NLP_CHK_NODE_ACT(ndlp)) {
|
2018-05-05 03:37:56 +00:00
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NODE | LOG_NVME_IOERR,
|
2019-08-14 23:57:06 +00:00
|
|
|
"6053 Busy IO, ndlp not ready: rport x%px "
|
|
|
|
"ndlp x%px, DID x%06x\n",
|
2017-02-12 21:52:32 +00:00
|
|
|
rport, ndlp, pnvme_rport->port_id);
|
2018-05-05 03:37:56 +00:00
|
|
|
atomic_inc(&lport->xmt_fcp_err);
|
|
|
|
ret = -EBUSY;
|
|
|
|
goto out_fail;
|
2017-02-12 21:52:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* The remote node has to be a mapped target or it's an error. */
|
|
|
|
if ((ndlp->nlp_type & NLP_NVME_TARGET) &&
|
|
|
|
(ndlp->nlp_state != NLP_STE_MAPPED_NODE)) {
|
2018-05-05 03:37:56 +00:00
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NODE | LOG_NVME_IOERR,
|
|
|
|
"6036 Fail IO, DID x%06x not ready for "
|
2018-05-05 03:37:50 +00:00
|
|
|
"IO. State x%x, Type x%x Flg x%x\n",
|
2018-05-05 03:37:56 +00:00
|
|
|
pnvme_rport->port_id,
|
2018-05-05 03:37:50 +00:00
|
|
|
ndlp->nlp_state, ndlp->nlp_type,
|
|
|
|
ndlp->upcall_flags);
|
2017-12-09 01:18:10 +00:00
|
|
|
atomic_inc(&lport->xmt_fcp_bad_ndlp);
|
2018-05-05 03:37:50 +00:00
|
|
|
ret = -EBUSY;
|
2017-02-12 21:52:32 +00:00
|
|
|
goto out_fail;
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2017-12-09 01:18:03 +00:00
|
|
|
/* Currently only NVME Keep alive commands should be expedited
|
|
|
|
* if the driver runs out of a resource. These should only be
|
|
|
|
* issued on the admin queue, qidx 0
|
|
|
|
*/
|
|
|
|
if (!lpfc_queue_info->qidx && !pnvme_fcreq->sg_cnt) {
|
|
|
|
sqe = &((struct nvme_fc_cmd_iu *)
|
|
|
|
pnvme_fcreq->cmdaddr)->sqe.common;
|
|
|
|
if (sqe->opcode == nvme_admin_keep_alive)
|
|
|
|
expedite = 1;
|
|
|
|
}
|
|
|
|
|
2017-02-12 21:52:32 +00:00
|
|
|
/* The node is shared with FCP IO, make sure the IO pending count does
|
|
|
|
* not exceed the programmed depth.
|
|
|
|
*/
|
2018-08-01 00:23:22 +00:00
|
|
|
if (lpfc_ndlp_check_qdepth(phba, ndlp)) {
|
|
|
|
if ((atomic_read(&ndlp->cmd_pending) >= ndlp->cmd_qdepth) &&
|
|
|
|
!expedite) {
|
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_IOERR,
|
|
|
|
"6174 Fail IO, ndlp qdepth exceeded: "
|
|
|
|
"idx %d DID %x pend %d qdepth %d\n",
|
|
|
|
lpfc_queue_info->index, ndlp->nlp_DID,
|
|
|
|
atomic_read(&ndlp->cmd_pending),
|
|
|
|
ndlp->cmd_qdepth);
|
|
|
|
atomic_inc(&lport->xmt_fcp_qdepth);
|
|
|
|
ret = -EBUSY;
|
|
|
|
goto out_fail;
|
|
|
|
}
|
2017-02-12 21:52:32 +00:00
|
|
|
}
|
|
|
|
|
2019-01-28 19:14:31 +00:00
|
|
|
/* Lookup Hardware Queue index based on fcp_io_sched module parameter */
|
2019-01-28 19:14:29 +00:00
|
|
|
if (phba->cfg_fcp_io_sched == LPFC_FCP_SCHED_BY_HDWQ) {
|
|
|
|
idx = lpfc_queue_info->index;
|
|
|
|
} else {
|
2019-03-28 18:06:22 +00:00
|
|
|
cpu = raw_smp_processor_id();
|
2019-01-28 19:14:31 +00:00
|
|
|
idx = phba->sli4_hba.cpu_map[cpu].hdwq;
|
2019-01-28 19:14:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
lpfc_ncmd = lpfc_get_nvme_buf(phba, ndlp, idx, expedite);
|
2017-02-12 21:52:32 +00:00
|
|
|
if (lpfc_ncmd == NULL) {
|
2017-12-09 01:18:10 +00:00
|
|
|
atomic_inc(&lport->xmt_fcp_noxri);
|
2017-02-12 21:52:32 +00:00
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_IOERR,
|
2018-05-05 03:37:56 +00:00
|
|
|
"6065 Fail IO, driver buffer pool is empty: "
|
|
|
|
"idx %d DID %x\n",
|
|
|
|
lpfc_queue_info->index, ndlp->nlp_DID);
|
2017-08-23 23:55:35 +00:00
|
|
|
ret = -EBUSY;
|
2017-02-12 21:52:32 +00:00
|
|
|
goto out_fail;
|
|
|
|
}
|
2017-02-12 21:52:33 +00:00
|
|
|
#ifdef CONFIG_SCSI_LPFC_DEBUG_FS
|
2017-09-30 00:34:33 +00:00
|
|
|
if (start) {
|
2017-02-12 21:52:33 +00:00
|
|
|
lpfc_ncmd->ts_cmd_start = start;
|
|
|
|
lpfc_ncmd->ts_last_cmd = phba->ktime_last_cmd;
|
2017-09-30 00:34:33 +00:00
|
|
|
} else {
|
|
|
|
lpfc_ncmd->ts_cmd_start = 0;
|
2017-02-12 21:52:33 +00:00
|
|
|
}
|
|
|
|
#endif
|
2017-02-12 21:52:32 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Store the data needed by the driver to issue, abort, and complete
|
|
|
|
* an IO.
|
|
|
|
* Do not let the IO hang out forever. There is no midlayer issuing
|
|
|
|
* an abort so inform the FW of the maximum IO pending time.
|
|
|
|
*/
|
2017-04-22 00:49:08 +00:00
|
|
|
freqpriv->nvme_buf = lpfc_ncmd;
|
2017-02-12 21:52:32 +00:00
|
|
|
lpfc_ncmd->nvmeCmd = pnvme_fcreq;
|
2017-03-04 17:30:30 +00:00
|
|
|
lpfc_ncmd->ndlp = ndlp;
|
2019-01-28 19:14:19 +00:00
|
|
|
lpfc_ncmd->qidx = lpfc_queue_info->qidx;
|
2017-02-12 21:52:32 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Issue the IO on the WQ indicated by index in the hw_queue_handle.
|
|
|
|
* This identfier was create in our hardware queue create callback
|
|
|
|
* routine. The driver now is dependent on the IO queue steering from
|
|
|
|
* the transport. We are trusting the upper NVME layers know which
|
|
|
|
* index to use and that they have affinitized a CPU to this hardware
|
|
|
|
* queue. A hardware queue maps to a driver MSI-X vector/EQ/CQ/WQ.
|
|
|
|
*/
|
2018-04-09 21:24:23 +00:00
|
|
|
lpfc_ncmd->cur_iocbq.hba_wqidx = idx;
|
2019-01-28 19:14:25 +00:00
|
|
|
cstat = &phba->sli4_hba.hdwq[idx].nvme_cstat;
|
2018-04-09 21:24:23 +00:00
|
|
|
|
|
|
|
lpfc_nvme_prep_io_cmd(vport, lpfc_ncmd, ndlp, cstat);
|
|
|
|
ret = lpfc_nvme_prep_io_dma(vport, lpfc_ncmd);
|
|
|
|
if (ret) {
|
2018-05-05 03:37:56 +00:00
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_IOERR,
|
|
|
|
"6175 Fail IO, Prep DMA: "
|
|
|
|
"idx %d DID %x\n",
|
|
|
|
lpfc_queue_info->index, ndlp->nlp_DID);
|
|
|
|
atomic_inc(&lport->xmt_fcp_err);
|
2018-04-09 21:24:23 +00:00
|
|
|
ret = -ENOMEM;
|
|
|
|
goto out_free_nvme_buf;
|
|
|
|
}
|
|
|
|
|
2017-02-12 21:52:33 +00:00
|
|
|
lpfc_nvmeio_data(phba, "NVME FCP XMIT: xri x%x idx %d to %06x\n",
|
|
|
|
lpfc_ncmd->cur_iocbq.sli4_xritag,
|
|
|
|
lpfc_queue_info->index, ndlp->nlp_DID);
|
|
|
|
|
2019-01-28 19:14:26 +00:00
|
|
|
ret = lpfc_sli4_issue_wqe(phba, lpfc_ncmd->hdwq, &lpfc_ncmd->cur_iocbq);
|
2017-02-12 21:52:32 +00:00
|
|
|
if (ret) {
|
2017-12-09 01:18:10 +00:00
|
|
|
atomic_inc(&lport->xmt_fcp_wqerr);
|
2017-09-30 00:34:36 +00:00
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_IOERR,
|
2018-05-05 03:37:56 +00:00
|
|
|
"6113 Fail IO, Could not issue WQE err %x "
|
2017-02-12 21:52:32 +00:00
|
|
|
"sid: x%x did: x%x oxid: x%x\n",
|
|
|
|
ret, vport->fc_myDID, ndlp->nlp_DID,
|
|
|
|
lpfc_ncmd->cur_iocbq.sli4_xritag);
|
|
|
|
goto out_free_nvme_buf;
|
|
|
|
}
|
|
|
|
|
scsi: lpfc: Adapt partitioned XRI lists to efficient sharing
The XRI get/put lists were partitioned per hardware queue. However, the
adapter rarely had sufficient resources to give a large number of resources
per queue. As such, it became common for a cpu to encounter a lack of XRI
resource and request the upper io stack to retry after returning a BUSY
condition. This occurred even though other cpus were idle and not using
their resources.
Create as efficient a scheme as possible to move resources to the cpus that
need them. Each cpu maintains a small private pool which it allocates from
for io. There is a watermark that the cpu attempts to keep in the private
pool. The private pool, when empty, pulls from a global pool from the
cpu. When the cpu's global pool is empty it will pull from other cpu's
global pool. As there many cpu global pools (1 per cpu or hardware queue
count) and as each cpu selects what cpu to pull from at different rates and
at different times, it creates a radomizing effect that minimizes the
number of cpu's that will contend with each other when the steal XRI's from
another cpu's global pool.
On io completion, a cpu will push the XRI back on to its private pool. A
watermark level is maintained for the private pool such that when it is
exceeded it will move XRI's to the CPU global pool so that other cpu's may
allocate them.
On NVME, as heartbeat commands are critical to get placed on the wire, a
single expedite pool is maintained. When a heartbeat is to be sent, it will
allocate an XRI from the expedite pool rather than the normal cpu
private/global pools. On any io completion, if a reduction in the expedite
pools is seen, it will be replenished before the XRI is placed on the cpu
private pool.
Statistics are added to aid understanding the XRI levels on each cpu and
their behaviors.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-01-28 19:14:28 +00:00
|
|
|
if (phba->cfg_xri_rebalancing)
|
|
|
|
lpfc_keep_pvt_pool_above_lowwm(phba, lpfc_ncmd->hdwq_no);
|
|
|
|
|
2017-02-12 21:52:33 +00:00
|
|
|
#ifdef CONFIG_SCSI_LPFC_DEBUG_FS
|
2017-09-30 00:34:33 +00:00
|
|
|
if (lpfc_ncmd->ts_cmd_start)
|
2017-02-12 21:52:33 +00:00
|
|
|
lpfc_ncmd->ts_cmd_wqput = ktime_get_ns();
|
|
|
|
|
2020-03-22 18:13:00 +00:00
|
|
|
if (phba->hdwqstat_on & LPFC_CHECK_NVME_IO) {
|
2019-03-28 18:06:22 +00:00
|
|
|
cpu = raw_smp_processor_id();
|
2020-03-22 18:13:00 +00:00
|
|
|
this_cpu_inc(phba->sli4_hba.c_stat->xmt_io);
|
|
|
|
lpfc_ncmd->cpu = cpu;
|
|
|
|
if (idx != cpu)
|
|
|
|
lpfc_printf_vlog(vport,
|
|
|
|
KERN_INFO, LOG_NVME_IOERR,
|
|
|
|
"6702 CPU Check cmd: "
|
|
|
|
"cpu %d wq %d\n",
|
|
|
|
lpfc_ncmd->cpu,
|
|
|
|
lpfc_queue_info->index);
|
2017-02-12 21:52:33 +00:00
|
|
|
}
|
|
|
|
#endif
|
2017-02-12 21:52:32 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
out_free_nvme_buf:
|
2017-06-02 04:07:02 +00:00
|
|
|
if (lpfc_ncmd->nvmeCmd->sg_cnt) {
|
|
|
|
if (lpfc_ncmd->nvmeCmd->io_dir == NVMEFC_FCP_WRITE)
|
2019-01-28 19:14:25 +00:00
|
|
|
cstat->output_requests--;
|
2017-06-02 04:07:02 +00:00
|
|
|
else
|
2019-01-28 19:14:25 +00:00
|
|
|
cstat->input_requests--;
|
2017-06-02 04:07:02 +00:00
|
|
|
} else
|
2019-01-28 19:14:25 +00:00
|
|
|
cstat->control_requests--;
|
2017-02-12 21:52:32 +00:00
|
|
|
lpfc_release_nvme_buf(phba, lpfc_ncmd);
|
|
|
|
out_fail:
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* lpfc_nvme_abort_fcreq_cmpl - Complete an NVME FCP abort request.
|
|
|
|
* @phba: Pointer to HBA context object
|
|
|
|
* @cmdiocb: Pointer to command iocb object.
|
|
|
|
* @rspiocb: Pointer to response iocb object.
|
|
|
|
*
|
|
|
|
* This is the callback function for any NVME FCP IO that was aborted.
|
|
|
|
*
|
|
|
|
* Return value:
|
|
|
|
* None
|
|
|
|
**/
|
|
|
|
void
|
|
|
|
lpfc_nvme_abort_fcreq_cmpl(struct lpfc_hba *phba, struct lpfc_iocbq *cmdiocb,
|
|
|
|
struct lpfc_wcqe_complete *abts_cmpl)
|
|
|
|
{
|
2017-09-30 00:34:36 +00:00
|
|
|
lpfc_printf_log(phba, KERN_INFO, LOG_NVME,
|
2017-02-12 21:52:32 +00:00
|
|
|
"6145 ABORT_XRI_CN completing on rpi x%x "
|
|
|
|
"original iotag x%x, abort cmd iotag x%x "
|
|
|
|
"req_tag x%x, status x%x, hwstatus x%x\n",
|
|
|
|
cmdiocb->iocb.un.acxri.abortContextTag,
|
|
|
|
cmdiocb->iocb.un.acxri.abortIoTag,
|
|
|
|
cmdiocb->iotag,
|
|
|
|
bf_get(lpfc_wcqe_c_request_tag, abts_cmpl),
|
|
|
|
bf_get(lpfc_wcqe_c_status, abts_cmpl),
|
|
|
|
bf_get(lpfc_wcqe_c_hw_status, abts_cmpl));
|
|
|
|
lpfc_sli_release_iocbq(phba, cmdiocb);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* lpfc_nvme_fcp_abort - Issue an NVME-over-FCP ABTS
|
|
|
|
* @lpfc_pnvme: Pointer to the driver's nvme instance data
|
|
|
|
* @lpfc_nvme_lport: Pointer to the driver's local port data
|
|
|
|
* @lpfc_nvme_rport: Pointer to the rport getting the @lpfc_nvme_ereq
|
|
|
|
* @lpfc_nvme_fcreq: IO request from nvme fc to driver.
|
|
|
|
* @hw_queue_handle: Driver-returned handle in lpfc_nvme_create_queue
|
|
|
|
*
|
|
|
|
* Driver registers this routine as its nvme request io abort handler. This
|
|
|
|
* routine issues an fcp Abort WQE with data from the @lpfc_nvme_fcpreq
|
|
|
|
* data structure to the rport indicated in @lpfc_nvme_rport. This routine
|
|
|
|
* is executed asynchronously - one the target is validated as "MAPPED" and
|
|
|
|
* ready for IO, the driver issues the abort request and returns.
|
|
|
|
*
|
|
|
|
* Return value:
|
|
|
|
* None
|
|
|
|
**/
|
|
|
|
static void
|
|
|
|
lpfc_nvme_fcp_abort(struct nvme_fc_local_port *pnvme_lport,
|
|
|
|
struct nvme_fc_remote_port *pnvme_rport,
|
|
|
|
void *hw_queue_handle,
|
|
|
|
struct nvmefc_fcp_req *pnvme_fcreq)
|
|
|
|
{
|
|
|
|
struct lpfc_nvme_lport *lport;
|
|
|
|
struct lpfc_vport *vport;
|
|
|
|
struct lpfc_hba *phba;
|
scsi: lpfc: Adapt partitioned XRI lists to efficient sharing
The XRI get/put lists were partitioned per hardware queue. However, the
adapter rarely had sufficient resources to give a large number of resources
per queue. As such, it became common for a cpu to encounter a lack of XRI
resource and request the upper io stack to retry after returning a BUSY
condition. This occurred even though other cpus were idle and not using
their resources.
Create as efficient a scheme as possible to move resources to the cpus that
need them. Each cpu maintains a small private pool which it allocates from
for io. There is a watermark that the cpu attempts to keep in the private
pool. The private pool, when empty, pulls from a global pool from the
cpu. When the cpu's global pool is empty it will pull from other cpu's
global pool. As there many cpu global pools (1 per cpu or hardware queue
count) and as each cpu selects what cpu to pull from at different rates and
at different times, it creates a radomizing effect that minimizes the
number of cpu's that will contend with each other when the steal XRI's from
another cpu's global pool.
On io completion, a cpu will push the XRI back on to its private pool. A
watermark level is maintained for the private pool such that when it is
exceeded it will move XRI's to the CPU global pool so that other cpu's may
allocate them.
On NVME, as heartbeat commands are critical to get placed on the wire, a
single expedite pool is maintained. When a heartbeat is to be sent, it will
allocate an XRI from the expedite pool rather than the normal cpu
private/global pools. On any io completion, if a reduction in the expedite
pools is seen, it will be replenished before the XRI is placed on the cpu
private pool.
Statistics are added to aid understanding the XRI levels on each cpu and
their behaviors.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-01-28 19:14:28 +00:00
|
|
|
struct lpfc_io_buf *lpfc_nbuf;
|
2017-02-12 21:52:32 +00:00
|
|
|
struct lpfc_iocbq *abts_buf;
|
|
|
|
struct lpfc_iocbq *nvmereq_wqe;
|
2017-11-21 00:00:42 +00:00
|
|
|
struct lpfc_nvme_fcpreq_priv *freqpriv;
|
2017-02-12 21:52:32 +00:00
|
|
|
unsigned long flags;
|
|
|
|
int ret_val;
|
|
|
|
|
2017-11-21 00:00:42 +00:00
|
|
|
/* Validate pointers. LLDD fault handling with transport does
|
|
|
|
* have timing races.
|
|
|
|
*/
|
2017-02-12 21:52:32 +00:00
|
|
|
lport = (struct lpfc_nvme_lport *)pnvme_lport->private;
|
2017-11-21 00:00:42 +00:00
|
|
|
if (unlikely(!lport))
|
|
|
|
return;
|
|
|
|
|
2017-02-12 21:52:32 +00:00
|
|
|
vport = lport->vport;
|
2017-11-21 00:00:42 +00:00
|
|
|
|
|
|
|
if (unlikely(!hw_queue_handle)) {
|
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_ABTS,
|
|
|
|
"6129 Fail Abort, HW Queue Handle NULL.\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2017-02-12 21:52:32 +00:00
|
|
|
phba = vport->phba;
|
2017-11-21 00:00:42 +00:00
|
|
|
freqpriv = pnvme_fcreq->private;
|
2017-02-12 21:52:32 +00:00
|
|
|
|
2017-11-21 00:00:42 +00:00
|
|
|
if (unlikely(!freqpriv))
|
|
|
|
return;
|
2017-11-21 00:00:41 +00:00
|
|
|
if (vport->load_flag & FC_UNLOADING)
|
|
|
|
return;
|
|
|
|
|
2017-02-12 21:52:32 +00:00
|
|
|
/* Announce entry to new IO submit field. */
|
Update ABORT processing for NVMET.
The driver with nvme had this routine stubbed.
Right now XRI_ABORTED_CQE is not handled and the FC NVMET
Transport has a new API for the driver.
Missing code path, new NVME abort API
Update ABORT processing for NVMET
There are 3 new FC NVMET Transport API/ template routines for NVMET:
lpfc_nvmet_xmt_fcp_release
This NVMET template callback routine called to release context
associated with an IO This routine is ALWAYS called last, even
if the IO was aborted or completed in error.
lpfc_nvmet_xmt_fcp_abort
This NVMET template callback routine called to abort an exchange that
has an IO in progress
nvmet_fc_rcv_fcp_req
When the lpfc driver receives an ABTS, this NVME FC transport layer
callback routine is called. For this case there are 2 paths thru the
driver: the driver either has an outstanding exchange / context for the
XRI to be aborted or not. If not, a BA_RJT is issued otherwise a BA_ACC
NVMET Driver abort paths:
There are 2 paths for aborting an IO. The first one is we receive an IO and
decide not to process it because of lack of resources. An unsolicated ABTS
is immediately sent back to the initiator as a response.
lpfc_nvmet_unsol_fcp_buffer
lpfc_nvmet_unsol_issue_abort (XMIT_SEQUENCE_WQE)
The second one is we sent the IO up to the NVMET transport layer to
process, and for some reason the NVME Transport layer decided to abort the
IO before it completes all its phases. For this case there are 2 paths
thru the driver:
the driver either has an outstanding TSEND/TRECEIVE/TRSP WQE or no
outstanding WQEs are present for the exchange / context.
lpfc_nvmet_xmt_fcp_abort
if (LPFC_NVMET_IO_INP)
lpfc_nvmet_sol_fcp_issue_abort (ABORT_WQE)
lpfc_nvmet_sol_fcp_abort_cmp
else
lpfc_nvmet_unsol_fcp_issue_abort
lpfc_nvmet_unsol_issue_abort (XMIT_SEQUENCE_WQE)
lpfc_nvmet_unsol_fcp_abort_cmp
Context flags:
LPFC_NVMET_IOP - his flag signifies an IO is in progress on the exchange.
LPFC_NVMET_XBUSY - this flag indicates the IO completed but the firmware
is still busy with the corresponding exchange. The exchange should not be
reused until after a XRI_ABORTED_CQE is received for that exchange.
LPFC_NVMET_ABORT_OP - this flag signifies an ABORT_WQE was issued on the
exchange.
LPFC_NVMET_CTX_RLS - this flag signifies a context free was requested,
but we are deferring it due to an XBUSY or ABORT in progress.
A ctxlock is added to the context structure that is used whenever these
flags are set/read within the context of an IO.
The LPFC_NVMET_CTX_RLS flag is only set in the defer_relase routine when
the transport has resolved all IO associated with the buffer. The flag is
cleared when the CTX is associated with a new IO.
An exchange can has both an LPFC_NVMET_XBUSY and a LPFC_NVMET_ABORT_OP
condition active simultaneously. Both conditions must complete before the
exchange is freed.
When the abort callback (lpfc_nvmet_xmt_fcp_abort) is envoked:
If there is an outstanding IO, the driver will issue an ABORT_WQE. This
should result in 3 completions for the exchange:
1) IO cmpl with XB bit set
2) Abort WQE cmpl
3) XRI_ABORTED_CQE cmpl
For this scenerio, after completion #1, the NVMET Transport IO rsp
callback is called. After completion #2, no action is taken with respect
to the exchange / context. After completion #3, the exchange context is
free for re-use on another IO.
If there is no outstanding activity on the exchange, the driver will send a
ABTS to the Initiator. Upon completion of this WQE, the exchange / context
is freed for re-use on another IO.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
2017-04-21 23:05:04 +00:00
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_ABTS,
|
2017-02-12 21:52:32 +00:00
|
|
|
"6002 Abort Request to rport DID x%06x "
|
2019-08-14 23:57:06 +00:00
|
|
|
"for nvme_fc_req x%px\n",
|
2017-02-12 21:52:32 +00:00
|
|
|
pnvme_rport->port_id,
|
|
|
|
pnvme_fcreq);
|
|
|
|
|
|
|
|
/* If the hba is getting reset, this flag is set. It is
|
|
|
|
* cleared when the reset is complete and rings reestablished.
|
|
|
|
*/
|
|
|
|
spin_lock_irqsave(&phba->hbalock, flags);
|
|
|
|
/* driver queued commands are in process of being flushed */
|
2019-08-14 23:57:11 +00:00
|
|
|
if (phba->hba_flag & HBA_IOQ_FLUSH) {
|
2017-02-12 21:52:32 +00:00
|
|
|
spin_unlock_irqrestore(&phba->hbalock, flags);
|
Update ABORT processing for NVMET.
The driver with nvme had this routine stubbed.
Right now XRI_ABORTED_CQE is not handled and the FC NVMET
Transport has a new API for the driver.
Missing code path, new NVME abort API
Update ABORT processing for NVMET
There are 3 new FC NVMET Transport API/ template routines for NVMET:
lpfc_nvmet_xmt_fcp_release
This NVMET template callback routine called to release context
associated with an IO This routine is ALWAYS called last, even
if the IO was aborted or completed in error.
lpfc_nvmet_xmt_fcp_abort
This NVMET template callback routine called to abort an exchange that
has an IO in progress
nvmet_fc_rcv_fcp_req
When the lpfc driver receives an ABTS, this NVME FC transport layer
callback routine is called. For this case there are 2 paths thru the
driver: the driver either has an outstanding exchange / context for the
XRI to be aborted or not. If not, a BA_RJT is issued otherwise a BA_ACC
NVMET Driver abort paths:
There are 2 paths for aborting an IO. The first one is we receive an IO and
decide not to process it because of lack of resources. An unsolicated ABTS
is immediately sent back to the initiator as a response.
lpfc_nvmet_unsol_fcp_buffer
lpfc_nvmet_unsol_issue_abort (XMIT_SEQUENCE_WQE)
The second one is we sent the IO up to the NVMET transport layer to
process, and for some reason the NVME Transport layer decided to abort the
IO before it completes all its phases. For this case there are 2 paths
thru the driver:
the driver either has an outstanding TSEND/TRECEIVE/TRSP WQE or no
outstanding WQEs are present for the exchange / context.
lpfc_nvmet_xmt_fcp_abort
if (LPFC_NVMET_IO_INP)
lpfc_nvmet_sol_fcp_issue_abort (ABORT_WQE)
lpfc_nvmet_sol_fcp_abort_cmp
else
lpfc_nvmet_unsol_fcp_issue_abort
lpfc_nvmet_unsol_issue_abort (XMIT_SEQUENCE_WQE)
lpfc_nvmet_unsol_fcp_abort_cmp
Context flags:
LPFC_NVMET_IOP - his flag signifies an IO is in progress on the exchange.
LPFC_NVMET_XBUSY - this flag indicates the IO completed but the firmware
is still busy with the corresponding exchange. The exchange should not be
reused until after a XRI_ABORTED_CQE is received for that exchange.
LPFC_NVMET_ABORT_OP - this flag signifies an ABORT_WQE was issued on the
exchange.
LPFC_NVMET_CTX_RLS - this flag signifies a context free was requested,
but we are deferring it due to an XBUSY or ABORT in progress.
A ctxlock is added to the context structure that is used whenever these
flags are set/read within the context of an IO.
The LPFC_NVMET_CTX_RLS flag is only set in the defer_relase routine when
the transport has resolved all IO associated with the buffer. The flag is
cleared when the CTX is associated with a new IO.
An exchange can has both an LPFC_NVMET_XBUSY and a LPFC_NVMET_ABORT_OP
condition active simultaneously. Both conditions must complete before the
exchange is freed.
When the abort callback (lpfc_nvmet_xmt_fcp_abort) is envoked:
If there is an outstanding IO, the driver will issue an ABORT_WQE. This
should result in 3 completions for the exchange:
1) IO cmpl with XB bit set
2) Abort WQE cmpl
3) XRI_ABORTED_CQE cmpl
For this scenerio, after completion #1, the NVMET Transport IO rsp
callback is called. After completion #2, no action is taken with respect
to the exchange / context. After completion #3, the exchange context is
free for re-use on another IO.
If there is no outstanding activity on the exchange, the driver will send a
ABTS to the Initiator. Upon completion of this WQE, the exchange / context
is freed for re-use on another IO.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
2017-04-21 23:05:04 +00:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_NVME_ABTS,
|
2017-02-12 21:52:32 +00:00
|
|
|
"6139 Driver in reset cleanup - flushing "
|
|
|
|
"NVME Req now. hba_flag x%x\n",
|
|
|
|
phba->hba_flag);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2017-04-22 00:49:08 +00:00
|
|
|
lpfc_nbuf = freqpriv->nvme_buf;
|
2017-02-12 21:52:32 +00:00
|
|
|
if (!lpfc_nbuf) {
|
|
|
|
spin_unlock_irqrestore(&phba->hbalock, flags);
|
Update ABORT processing for NVMET.
The driver with nvme had this routine stubbed.
Right now XRI_ABORTED_CQE is not handled and the FC NVMET
Transport has a new API for the driver.
Missing code path, new NVME abort API
Update ABORT processing for NVMET
There are 3 new FC NVMET Transport API/ template routines for NVMET:
lpfc_nvmet_xmt_fcp_release
This NVMET template callback routine called to release context
associated with an IO This routine is ALWAYS called last, even
if the IO was aborted or completed in error.
lpfc_nvmet_xmt_fcp_abort
This NVMET template callback routine called to abort an exchange that
has an IO in progress
nvmet_fc_rcv_fcp_req
When the lpfc driver receives an ABTS, this NVME FC transport layer
callback routine is called. For this case there are 2 paths thru the
driver: the driver either has an outstanding exchange / context for the
XRI to be aborted or not. If not, a BA_RJT is issued otherwise a BA_ACC
NVMET Driver abort paths:
There are 2 paths for aborting an IO. The first one is we receive an IO and
decide not to process it because of lack of resources. An unsolicated ABTS
is immediately sent back to the initiator as a response.
lpfc_nvmet_unsol_fcp_buffer
lpfc_nvmet_unsol_issue_abort (XMIT_SEQUENCE_WQE)
The second one is we sent the IO up to the NVMET transport layer to
process, and for some reason the NVME Transport layer decided to abort the
IO before it completes all its phases. For this case there are 2 paths
thru the driver:
the driver either has an outstanding TSEND/TRECEIVE/TRSP WQE or no
outstanding WQEs are present for the exchange / context.
lpfc_nvmet_xmt_fcp_abort
if (LPFC_NVMET_IO_INP)
lpfc_nvmet_sol_fcp_issue_abort (ABORT_WQE)
lpfc_nvmet_sol_fcp_abort_cmp
else
lpfc_nvmet_unsol_fcp_issue_abort
lpfc_nvmet_unsol_issue_abort (XMIT_SEQUENCE_WQE)
lpfc_nvmet_unsol_fcp_abort_cmp
Context flags:
LPFC_NVMET_IOP - his flag signifies an IO is in progress on the exchange.
LPFC_NVMET_XBUSY - this flag indicates the IO completed but the firmware
is still busy with the corresponding exchange. The exchange should not be
reused until after a XRI_ABORTED_CQE is received for that exchange.
LPFC_NVMET_ABORT_OP - this flag signifies an ABORT_WQE was issued on the
exchange.
LPFC_NVMET_CTX_RLS - this flag signifies a context free was requested,
but we are deferring it due to an XBUSY or ABORT in progress.
A ctxlock is added to the context structure that is used whenever these
flags are set/read within the context of an IO.
The LPFC_NVMET_CTX_RLS flag is only set in the defer_relase routine when
the transport has resolved all IO associated with the buffer. The flag is
cleared when the CTX is associated with a new IO.
An exchange can has both an LPFC_NVMET_XBUSY and a LPFC_NVMET_ABORT_OP
condition active simultaneously. Both conditions must complete before the
exchange is freed.
When the abort callback (lpfc_nvmet_xmt_fcp_abort) is envoked:
If there is an outstanding IO, the driver will issue an ABORT_WQE. This
should result in 3 completions for the exchange:
1) IO cmpl with XB bit set
2) Abort WQE cmpl
3) XRI_ABORTED_CQE cmpl
For this scenerio, after completion #1, the NVMET Transport IO rsp
callback is called. After completion #2, no action is taken with respect
to the exchange / context. After completion #3, the exchange context is
free for re-use on another IO.
If there is no outstanding activity on the exchange, the driver will send a
ABTS to the Initiator. Upon completion of this WQE, the exchange / context
is freed for re-use on another IO.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
2017-04-21 23:05:04 +00:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_NVME_ABTS,
|
2017-02-12 21:52:32 +00:00
|
|
|
"6140 NVME IO req has no matching lpfc nvme "
|
|
|
|
"io buffer. Skipping abort req.\n");
|
|
|
|
return;
|
|
|
|
} else if (!lpfc_nbuf->nvmeCmd) {
|
|
|
|
spin_unlock_irqrestore(&phba->hbalock, flags);
|
Update ABORT processing for NVMET.
The driver with nvme had this routine stubbed.
Right now XRI_ABORTED_CQE is not handled and the FC NVMET
Transport has a new API for the driver.
Missing code path, new NVME abort API
Update ABORT processing for NVMET
There are 3 new FC NVMET Transport API/ template routines for NVMET:
lpfc_nvmet_xmt_fcp_release
This NVMET template callback routine called to release context
associated with an IO This routine is ALWAYS called last, even
if the IO was aborted or completed in error.
lpfc_nvmet_xmt_fcp_abort
This NVMET template callback routine called to abort an exchange that
has an IO in progress
nvmet_fc_rcv_fcp_req
When the lpfc driver receives an ABTS, this NVME FC transport layer
callback routine is called. For this case there are 2 paths thru the
driver: the driver either has an outstanding exchange / context for the
XRI to be aborted or not. If not, a BA_RJT is issued otherwise a BA_ACC
NVMET Driver abort paths:
There are 2 paths for aborting an IO. The first one is we receive an IO and
decide not to process it because of lack of resources. An unsolicated ABTS
is immediately sent back to the initiator as a response.
lpfc_nvmet_unsol_fcp_buffer
lpfc_nvmet_unsol_issue_abort (XMIT_SEQUENCE_WQE)
The second one is we sent the IO up to the NVMET transport layer to
process, and for some reason the NVME Transport layer decided to abort the
IO before it completes all its phases. For this case there are 2 paths
thru the driver:
the driver either has an outstanding TSEND/TRECEIVE/TRSP WQE or no
outstanding WQEs are present for the exchange / context.
lpfc_nvmet_xmt_fcp_abort
if (LPFC_NVMET_IO_INP)
lpfc_nvmet_sol_fcp_issue_abort (ABORT_WQE)
lpfc_nvmet_sol_fcp_abort_cmp
else
lpfc_nvmet_unsol_fcp_issue_abort
lpfc_nvmet_unsol_issue_abort (XMIT_SEQUENCE_WQE)
lpfc_nvmet_unsol_fcp_abort_cmp
Context flags:
LPFC_NVMET_IOP - his flag signifies an IO is in progress on the exchange.
LPFC_NVMET_XBUSY - this flag indicates the IO completed but the firmware
is still busy with the corresponding exchange. The exchange should not be
reused until after a XRI_ABORTED_CQE is received for that exchange.
LPFC_NVMET_ABORT_OP - this flag signifies an ABORT_WQE was issued on the
exchange.
LPFC_NVMET_CTX_RLS - this flag signifies a context free was requested,
but we are deferring it due to an XBUSY or ABORT in progress.
A ctxlock is added to the context structure that is used whenever these
flags are set/read within the context of an IO.
The LPFC_NVMET_CTX_RLS flag is only set in the defer_relase routine when
the transport has resolved all IO associated with the buffer. The flag is
cleared when the CTX is associated with a new IO.
An exchange can has both an LPFC_NVMET_XBUSY and a LPFC_NVMET_ABORT_OP
condition active simultaneously. Both conditions must complete before the
exchange is freed.
When the abort callback (lpfc_nvmet_xmt_fcp_abort) is envoked:
If there is an outstanding IO, the driver will issue an ABORT_WQE. This
should result in 3 completions for the exchange:
1) IO cmpl with XB bit set
2) Abort WQE cmpl
3) XRI_ABORTED_CQE cmpl
For this scenerio, after completion #1, the NVMET Transport IO rsp
callback is called. After completion #2, no action is taken with respect
to the exchange / context. After completion #3, the exchange context is
free for re-use on another IO.
If there is no outstanding activity on the exchange, the driver will send a
ABTS to the Initiator. Upon completion of this WQE, the exchange / context
is freed for re-use on another IO.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
2017-04-21 23:05:04 +00:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_NVME_ABTS,
|
2017-02-12 21:52:32 +00:00
|
|
|
"6141 lpfc NVME IO req has no nvme_fcreq "
|
|
|
|
"io buffer. Skipping abort req.\n");
|
|
|
|
return;
|
|
|
|
}
|
2017-04-21 23:04:59 +00:00
|
|
|
nvmereq_wqe = &lpfc_nbuf->cur_iocbq;
|
2017-02-12 21:52:32 +00:00
|
|
|
|
2019-01-28 19:14:37 +00:00
|
|
|
/* Guard against IO completion being called at same time */
|
|
|
|
spin_lock(&lpfc_nbuf->buf_lock);
|
|
|
|
|
2017-02-12 21:52:32 +00:00
|
|
|
/*
|
|
|
|
* The lpfc_nbuf and the mapped nvme_fcreq in the driver's
|
|
|
|
* state must match the nvme_fcreq passed by the nvme
|
|
|
|
* transport. If they don't match, it is likely the driver
|
|
|
|
* has already completed the NVME IO and the nvme transport
|
|
|
|
* has not seen it yet.
|
|
|
|
*/
|
|
|
|
if (lpfc_nbuf->nvmeCmd != pnvme_fcreq) {
|
Update ABORT processing for NVMET.
The driver with nvme had this routine stubbed.
Right now XRI_ABORTED_CQE is not handled and the FC NVMET
Transport has a new API for the driver.
Missing code path, new NVME abort API
Update ABORT processing for NVMET
There are 3 new FC NVMET Transport API/ template routines for NVMET:
lpfc_nvmet_xmt_fcp_release
This NVMET template callback routine called to release context
associated with an IO This routine is ALWAYS called last, even
if the IO was aborted or completed in error.
lpfc_nvmet_xmt_fcp_abort
This NVMET template callback routine called to abort an exchange that
has an IO in progress
nvmet_fc_rcv_fcp_req
When the lpfc driver receives an ABTS, this NVME FC transport layer
callback routine is called. For this case there are 2 paths thru the
driver: the driver either has an outstanding exchange / context for the
XRI to be aborted or not. If not, a BA_RJT is issued otherwise a BA_ACC
NVMET Driver abort paths:
There are 2 paths for aborting an IO. The first one is we receive an IO and
decide not to process it because of lack of resources. An unsolicated ABTS
is immediately sent back to the initiator as a response.
lpfc_nvmet_unsol_fcp_buffer
lpfc_nvmet_unsol_issue_abort (XMIT_SEQUENCE_WQE)
The second one is we sent the IO up to the NVMET transport layer to
process, and for some reason the NVME Transport layer decided to abort the
IO before it completes all its phases. For this case there are 2 paths
thru the driver:
the driver either has an outstanding TSEND/TRECEIVE/TRSP WQE or no
outstanding WQEs are present for the exchange / context.
lpfc_nvmet_xmt_fcp_abort
if (LPFC_NVMET_IO_INP)
lpfc_nvmet_sol_fcp_issue_abort (ABORT_WQE)
lpfc_nvmet_sol_fcp_abort_cmp
else
lpfc_nvmet_unsol_fcp_issue_abort
lpfc_nvmet_unsol_issue_abort (XMIT_SEQUENCE_WQE)
lpfc_nvmet_unsol_fcp_abort_cmp
Context flags:
LPFC_NVMET_IOP - his flag signifies an IO is in progress on the exchange.
LPFC_NVMET_XBUSY - this flag indicates the IO completed but the firmware
is still busy with the corresponding exchange. The exchange should not be
reused until after a XRI_ABORTED_CQE is received for that exchange.
LPFC_NVMET_ABORT_OP - this flag signifies an ABORT_WQE was issued on the
exchange.
LPFC_NVMET_CTX_RLS - this flag signifies a context free was requested,
but we are deferring it due to an XBUSY or ABORT in progress.
A ctxlock is added to the context structure that is used whenever these
flags are set/read within the context of an IO.
The LPFC_NVMET_CTX_RLS flag is only set in the defer_relase routine when
the transport has resolved all IO associated with the buffer. The flag is
cleared when the CTX is associated with a new IO.
An exchange can has both an LPFC_NVMET_XBUSY and a LPFC_NVMET_ABORT_OP
condition active simultaneously. Both conditions must complete before the
exchange is freed.
When the abort callback (lpfc_nvmet_xmt_fcp_abort) is envoked:
If there is an outstanding IO, the driver will issue an ABORT_WQE. This
should result in 3 completions for the exchange:
1) IO cmpl with XB bit set
2) Abort WQE cmpl
3) XRI_ABORTED_CQE cmpl
For this scenerio, after completion #1, the NVMET Transport IO rsp
callback is called. After completion #2, no action is taken with respect
to the exchange / context. After completion #3, the exchange context is
free for re-use on another IO.
If there is no outstanding activity on the exchange, the driver will send a
ABTS to the Initiator. Upon completion of this WQE, the exchange / context
is freed for re-use on another IO.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
2017-04-21 23:05:04 +00:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_NVME_ABTS,
|
2017-02-12 21:52:32 +00:00
|
|
|
"6143 NVME req mismatch: "
|
2019-08-14 23:57:06 +00:00
|
|
|
"lpfc_nbuf x%px nvmeCmd x%px, "
|
|
|
|
"pnvme_fcreq x%px. Skipping Abort xri x%x\n",
|
2017-02-12 21:52:32 +00:00
|
|
|
lpfc_nbuf, lpfc_nbuf->nvmeCmd,
|
2017-04-21 23:04:59 +00:00
|
|
|
pnvme_fcreq, nvmereq_wqe->sli4_xritag);
|
2019-01-28 19:14:37 +00:00
|
|
|
goto out_unlock;
|
2017-02-12 21:52:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Don't abort IOs no longer on the pending queue. */
|
|
|
|
if (!(nvmereq_wqe->iocb_flag & LPFC_IO_ON_TXCMPLQ)) {
|
Update ABORT processing for NVMET.
The driver with nvme had this routine stubbed.
Right now XRI_ABORTED_CQE is not handled and the FC NVMET
Transport has a new API for the driver.
Missing code path, new NVME abort API
Update ABORT processing for NVMET
There are 3 new FC NVMET Transport API/ template routines for NVMET:
lpfc_nvmet_xmt_fcp_release
This NVMET template callback routine called to release context
associated with an IO This routine is ALWAYS called last, even
if the IO was aborted or completed in error.
lpfc_nvmet_xmt_fcp_abort
This NVMET template callback routine called to abort an exchange that
has an IO in progress
nvmet_fc_rcv_fcp_req
When the lpfc driver receives an ABTS, this NVME FC transport layer
callback routine is called. For this case there are 2 paths thru the
driver: the driver either has an outstanding exchange / context for the
XRI to be aborted or not. If not, a BA_RJT is issued otherwise a BA_ACC
NVMET Driver abort paths:
There are 2 paths for aborting an IO. The first one is we receive an IO and
decide not to process it because of lack of resources. An unsolicated ABTS
is immediately sent back to the initiator as a response.
lpfc_nvmet_unsol_fcp_buffer
lpfc_nvmet_unsol_issue_abort (XMIT_SEQUENCE_WQE)
The second one is we sent the IO up to the NVMET transport layer to
process, and for some reason the NVME Transport layer decided to abort the
IO before it completes all its phases. For this case there are 2 paths
thru the driver:
the driver either has an outstanding TSEND/TRECEIVE/TRSP WQE or no
outstanding WQEs are present for the exchange / context.
lpfc_nvmet_xmt_fcp_abort
if (LPFC_NVMET_IO_INP)
lpfc_nvmet_sol_fcp_issue_abort (ABORT_WQE)
lpfc_nvmet_sol_fcp_abort_cmp
else
lpfc_nvmet_unsol_fcp_issue_abort
lpfc_nvmet_unsol_issue_abort (XMIT_SEQUENCE_WQE)
lpfc_nvmet_unsol_fcp_abort_cmp
Context flags:
LPFC_NVMET_IOP - his flag signifies an IO is in progress on the exchange.
LPFC_NVMET_XBUSY - this flag indicates the IO completed but the firmware
is still busy with the corresponding exchange. The exchange should not be
reused until after a XRI_ABORTED_CQE is received for that exchange.
LPFC_NVMET_ABORT_OP - this flag signifies an ABORT_WQE was issued on the
exchange.
LPFC_NVMET_CTX_RLS - this flag signifies a context free was requested,
but we are deferring it due to an XBUSY or ABORT in progress.
A ctxlock is added to the context structure that is used whenever these
flags are set/read within the context of an IO.
The LPFC_NVMET_CTX_RLS flag is only set in the defer_relase routine when
the transport has resolved all IO associated with the buffer. The flag is
cleared when the CTX is associated with a new IO.
An exchange can has both an LPFC_NVMET_XBUSY and a LPFC_NVMET_ABORT_OP
condition active simultaneously. Both conditions must complete before the
exchange is freed.
When the abort callback (lpfc_nvmet_xmt_fcp_abort) is envoked:
If there is an outstanding IO, the driver will issue an ABORT_WQE. This
should result in 3 completions for the exchange:
1) IO cmpl with XB bit set
2) Abort WQE cmpl
3) XRI_ABORTED_CQE cmpl
For this scenerio, after completion #1, the NVMET Transport IO rsp
callback is called. After completion #2, no action is taken with respect
to the exchange / context. After completion #3, the exchange context is
free for re-use on another IO.
If there is no outstanding activity on the exchange, the driver will send a
ABTS to the Initiator. Upon completion of this WQE, the exchange / context
is freed for re-use on another IO.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
2017-04-21 23:05:04 +00:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_NVME_ABTS,
|
2019-08-14 23:57:06 +00:00
|
|
|
"6142 NVME IO req x%px not queued - skipping "
|
2017-04-21 23:04:59 +00:00
|
|
|
"abort req xri x%x\n",
|
|
|
|
pnvme_fcreq, nvmereq_wqe->sli4_xritag);
|
2019-01-28 19:14:37 +00:00
|
|
|
goto out_unlock;
|
2017-02-12 21:52:32 +00:00
|
|
|
}
|
|
|
|
|
2017-12-09 01:18:10 +00:00
|
|
|
atomic_inc(&lport->xmt_fcp_abort);
|
2017-02-12 21:52:33 +00:00
|
|
|
lpfc_nvmeio_data(phba, "NVME FCP ABORT: xri x%x idx %d to %06x\n",
|
|
|
|
nvmereq_wqe->sli4_xritag,
|
2017-06-21 17:37:58 +00:00
|
|
|
nvmereq_wqe->hba_wqidx, pnvme_rport->port_id);
|
2017-02-12 21:52:33 +00:00
|
|
|
|
2017-02-12 21:52:32 +00:00
|
|
|
/* Outstanding abort is in progress */
|
|
|
|
if (nvmereq_wqe->iocb_flag & LPFC_DRIVER_ABORTED) {
|
Update ABORT processing for NVMET.
The driver with nvme had this routine stubbed.
Right now XRI_ABORTED_CQE is not handled and the FC NVMET
Transport has a new API for the driver.
Missing code path, new NVME abort API
Update ABORT processing for NVMET
There are 3 new FC NVMET Transport API/ template routines for NVMET:
lpfc_nvmet_xmt_fcp_release
This NVMET template callback routine called to release context
associated with an IO This routine is ALWAYS called last, even
if the IO was aborted or completed in error.
lpfc_nvmet_xmt_fcp_abort
This NVMET template callback routine called to abort an exchange that
has an IO in progress
nvmet_fc_rcv_fcp_req
When the lpfc driver receives an ABTS, this NVME FC transport layer
callback routine is called. For this case there are 2 paths thru the
driver: the driver either has an outstanding exchange / context for the
XRI to be aborted or not. If not, a BA_RJT is issued otherwise a BA_ACC
NVMET Driver abort paths:
There are 2 paths for aborting an IO. The first one is we receive an IO and
decide not to process it because of lack of resources. An unsolicated ABTS
is immediately sent back to the initiator as a response.
lpfc_nvmet_unsol_fcp_buffer
lpfc_nvmet_unsol_issue_abort (XMIT_SEQUENCE_WQE)
The second one is we sent the IO up to the NVMET transport layer to
process, and for some reason the NVME Transport layer decided to abort the
IO before it completes all its phases. For this case there are 2 paths
thru the driver:
the driver either has an outstanding TSEND/TRECEIVE/TRSP WQE or no
outstanding WQEs are present for the exchange / context.
lpfc_nvmet_xmt_fcp_abort
if (LPFC_NVMET_IO_INP)
lpfc_nvmet_sol_fcp_issue_abort (ABORT_WQE)
lpfc_nvmet_sol_fcp_abort_cmp
else
lpfc_nvmet_unsol_fcp_issue_abort
lpfc_nvmet_unsol_issue_abort (XMIT_SEQUENCE_WQE)
lpfc_nvmet_unsol_fcp_abort_cmp
Context flags:
LPFC_NVMET_IOP - his flag signifies an IO is in progress on the exchange.
LPFC_NVMET_XBUSY - this flag indicates the IO completed but the firmware
is still busy with the corresponding exchange. The exchange should not be
reused until after a XRI_ABORTED_CQE is received for that exchange.
LPFC_NVMET_ABORT_OP - this flag signifies an ABORT_WQE was issued on the
exchange.
LPFC_NVMET_CTX_RLS - this flag signifies a context free was requested,
but we are deferring it due to an XBUSY or ABORT in progress.
A ctxlock is added to the context structure that is used whenever these
flags are set/read within the context of an IO.
The LPFC_NVMET_CTX_RLS flag is only set in the defer_relase routine when
the transport has resolved all IO associated with the buffer. The flag is
cleared when the CTX is associated with a new IO.
An exchange can has both an LPFC_NVMET_XBUSY and a LPFC_NVMET_ABORT_OP
condition active simultaneously. Both conditions must complete before the
exchange is freed.
When the abort callback (lpfc_nvmet_xmt_fcp_abort) is envoked:
If there is an outstanding IO, the driver will issue an ABORT_WQE. This
should result in 3 completions for the exchange:
1) IO cmpl with XB bit set
2) Abort WQE cmpl
3) XRI_ABORTED_CQE cmpl
For this scenerio, after completion #1, the NVMET Transport IO rsp
callback is called. After completion #2, no action is taken with respect
to the exchange / context. After completion #3, the exchange context is
free for re-use on another IO.
If there is no outstanding activity on the exchange, the driver will send a
ABTS to the Initiator. Upon completion of this WQE, the exchange / context
is freed for re-use on another IO.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
2017-04-21 23:05:04 +00:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_NVME_ABTS,
|
2017-02-12 21:52:32 +00:00
|
|
|
"6144 Outstanding NVME I/O Abort Request "
|
2019-08-14 23:57:06 +00:00
|
|
|
"still pending on nvme_fcreq x%px, "
|
|
|
|
"lpfc_ncmd %px xri x%x\n",
|
2017-04-21 23:04:59 +00:00
|
|
|
pnvme_fcreq, lpfc_nbuf,
|
|
|
|
nvmereq_wqe->sli4_xritag);
|
2019-01-28 19:14:37 +00:00
|
|
|
goto out_unlock;
|
2017-02-12 21:52:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
abts_buf = __lpfc_sli_get_iocbq(phba);
|
|
|
|
if (!abts_buf) {
|
Update ABORT processing for NVMET.
The driver with nvme had this routine stubbed.
Right now XRI_ABORTED_CQE is not handled and the FC NVMET
Transport has a new API for the driver.
Missing code path, new NVME abort API
Update ABORT processing for NVMET
There are 3 new FC NVMET Transport API/ template routines for NVMET:
lpfc_nvmet_xmt_fcp_release
This NVMET template callback routine called to release context
associated with an IO This routine is ALWAYS called last, even
if the IO was aborted or completed in error.
lpfc_nvmet_xmt_fcp_abort
This NVMET template callback routine called to abort an exchange that
has an IO in progress
nvmet_fc_rcv_fcp_req
When the lpfc driver receives an ABTS, this NVME FC transport layer
callback routine is called. For this case there are 2 paths thru the
driver: the driver either has an outstanding exchange / context for the
XRI to be aborted or not. If not, a BA_RJT is issued otherwise a BA_ACC
NVMET Driver abort paths:
There are 2 paths for aborting an IO. The first one is we receive an IO and
decide not to process it because of lack of resources. An unsolicated ABTS
is immediately sent back to the initiator as a response.
lpfc_nvmet_unsol_fcp_buffer
lpfc_nvmet_unsol_issue_abort (XMIT_SEQUENCE_WQE)
The second one is we sent the IO up to the NVMET transport layer to
process, and for some reason the NVME Transport layer decided to abort the
IO before it completes all its phases. For this case there are 2 paths
thru the driver:
the driver either has an outstanding TSEND/TRECEIVE/TRSP WQE or no
outstanding WQEs are present for the exchange / context.
lpfc_nvmet_xmt_fcp_abort
if (LPFC_NVMET_IO_INP)
lpfc_nvmet_sol_fcp_issue_abort (ABORT_WQE)
lpfc_nvmet_sol_fcp_abort_cmp
else
lpfc_nvmet_unsol_fcp_issue_abort
lpfc_nvmet_unsol_issue_abort (XMIT_SEQUENCE_WQE)
lpfc_nvmet_unsol_fcp_abort_cmp
Context flags:
LPFC_NVMET_IOP - his flag signifies an IO is in progress on the exchange.
LPFC_NVMET_XBUSY - this flag indicates the IO completed but the firmware
is still busy with the corresponding exchange. The exchange should not be
reused until after a XRI_ABORTED_CQE is received for that exchange.
LPFC_NVMET_ABORT_OP - this flag signifies an ABORT_WQE was issued on the
exchange.
LPFC_NVMET_CTX_RLS - this flag signifies a context free was requested,
but we are deferring it due to an XBUSY or ABORT in progress.
A ctxlock is added to the context structure that is used whenever these
flags are set/read within the context of an IO.
The LPFC_NVMET_CTX_RLS flag is only set in the defer_relase routine when
the transport has resolved all IO associated with the buffer. The flag is
cleared when the CTX is associated with a new IO.
An exchange can has both an LPFC_NVMET_XBUSY and a LPFC_NVMET_ABORT_OP
condition active simultaneously. Both conditions must complete before the
exchange is freed.
When the abort callback (lpfc_nvmet_xmt_fcp_abort) is envoked:
If there is an outstanding IO, the driver will issue an ABORT_WQE. This
should result in 3 completions for the exchange:
1) IO cmpl with XB bit set
2) Abort WQE cmpl
3) XRI_ABORTED_CQE cmpl
For this scenerio, after completion #1, the NVMET Transport IO rsp
callback is called. After completion #2, no action is taken with respect
to the exchange / context. After completion #3, the exchange context is
free for re-use on another IO.
If there is no outstanding activity on the exchange, the driver will send a
ABTS to the Initiator. Upon completion of this WQE, the exchange / context
is freed for re-use on another IO.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
2017-04-21 23:05:04 +00:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_NVME_ABTS,
|
2017-02-12 21:52:32 +00:00
|
|
|
"6136 No available abort wqes. Skipping "
|
2019-08-14 23:57:06 +00:00
|
|
|
"Abts req for nvme_fcreq x%px xri x%x\n",
|
2017-04-21 23:04:59 +00:00
|
|
|
pnvme_fcreq, nvmereq_wqe->sli4_xritag);
|
2019-01-28 19:14:37 +00:00
|
|
|
goto out_unlock;
|
2017-02-12 21:52:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Ready - mark outstanding as aborted by driver. */
|
|
|
|
nvmereq_wqe->iocb_flag |= LPFC_DRIVER_ABORTED;
|
|
|
|
|
2019-09-22 03:58:56 +00:00
|
|
|
lpfc_nvme_prep_abort_wqe(abts_buf, nvmereq_wqe->sli4_xritag, 0);
|
2017-02-12 21:52:32 +00:00
|
|
|
|
|
|
|
/* ABTS WQE must go to the same WQ as the WQE to be aborted */
|
|
|
|
abts_buf->iocb_flag |= LPFC_IO_NVME;
|
|
|
|
abts_buf->hba_wqidx = nvmereq_wqe->hba_wqidx;
|
|
|
|
abts_buf->vport = vport;
|
|
|
|
abts_buf->wqe_cmpl = lpfc_nvme_abort_fcreq_cmpl;
|
2019-01-28 19:14:26 +00:00
|
|
|
ret_val = lpfc_sli4_issue_wqe(phba, lpfc_nbuf->hdwq, abts_buf);
|
2019-01-28 19:14:37 +00:00
|
|
|
spin_unlock(&lpfc_nbuf->buf_lock);
|
2017-02-12 21:52:32 +00:00
|
|
|
spin_unlock_irqrestore(&phba->hbalock, flags);
|
2017-08-23 23:55:35 +00:00
|
|
|
if (ret_val) {
|
Update ABORT processing for NVMET.
The driver with nvme had this routine stubbed.
Right now XRI_ABORTED_CQE is not handled and the FC NVMET
Transport has a new API for the driver.
Missing code path, new NVME abort API
Update ABORT processing for NVMET
There are 3 new FC NVMET Transport API/ template routines for NVMET:
lpfc_nvmet_xmt_fcp_release
This NVMET template callback routine called to release context
associated with an IO This routine is ALWAYS called last, even
if the IO was aborted or completed in error.
lpfc_nvmet_xmt_fcp_abort
This NVMET template callback routine called to abort an exchange that
has an IO in progress
nvmet_fc_rcv_fcp_req
When the lpfc driver receives an ABTS, this NVME FC transport layer
callback routine is called. For this case there are 2 paths thru the
driver: the driver either has an outstanding exchange / context for the
XRI to be aborted or not. If not, a BA_RJT is issued otherwise a BA_ACC
NVMET Driver abort paths:
There are 2 paths for aborting an IO. The first one is we receive an IO and
decide not to process it because of lack of resources. An unsolicated ABTS
is immediately sent back to the initiator as a response.
lpfc_nvmet_unsol_fcp_buffer
lpfc_nvmet_unsol_issue_abort (XMIT_SEQUENCE_WQE)
The second one is we sent the IO up to the NVMET transport layer to
process, and for some reason the NVME Transport layer decided to abort the
IO before it completes all its phases. For this case there are 2 paths
thru the driver:
the driver either has an outstanding TSEND/TRECEIVE/TRSP WQE or no
outstanding WQEs are present for the exchange / context.
lpfc_nvmet_xmt_fcp_abort
if (LPFC_NVMET_IO_INP)
lpfc_nvmet_sol_fcp_issue_abort (ABORT_WQE)
lpfc_nvmet_sol_fcp_abort_cmp
else
lpfc_nvmet_unsol_fcp_issue_abort
lpfc_nvmet_unsol_issue_abort (XMIT_SEQUENCE_WQE)
lpfc_nvmet_unsol_fcp_abort_cmp
Context flags:
LPFC_NVMET_IOP - his flag signifies an IO is in progress on the exchange.
LPFC_NVMET_XBUSY - this flag indicates the IO completed but the firmware
is still busy with the corresponding exchange. The exchange should not be
reused until after a XRI_ABORTED_CQE is received for that exchange.
LPFC_NVMET_ABORT_OP - this flag signifies an ABORT_WQE was issued on the
exchange.
LPFC_NVMET_CTX_RLS - this flag signifies a context free was requested,
but we are deferring it due to an XBUSY or ABORT in progress.
A ctxlock is added to the context structure that is used whenever these
flags are set/read within the context of an IO.
The LPFC_NVMET_CTX_RLS flag is only set in the defer_relase routine when
the transport has resolved all IO associated with the buffer. The flag is
cleared when the CTX is associated with a new IO.
An exchange can has both an LPFC_NVMET_XBUSY and a LPFC_NVMET_ABORT_OP
condition active simultaneously. Both conditions must complete before the
exchange is freed.
When the abort callback (lpfc_nvmet_xmt_fcp_abort) is envoked:
If there is an outstanding IO, the driver will issue an ABORT_WQE. This
should result in 3 completions for the exchange:
1) IO cmpl with XB bit set
2) Abort WQE cmpl
3) XRI_ABORTED_CQE cmpl
For this scenerio, after completion #1, the NVMET Transport IO rsp
callback is called. After completion #2, no action is taken with respect
to the exchange / context. After completion #3, the exchange context is
free for re-use on another IO.
If there is no outstanding activity on the exchange, the driver will send a
ABTS to the Initiator. Upon completion of this WQE, the exchange / context
is freed for re-use on another IO.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
2017-04-21 23:05:04 +00:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_NVME_ABTS,
|
2017-02-12 21:52:32 +00:00
|
|
|
"6137 Failed abts issue_wqe with status x%x "
|
2019-08-14 23:57:06 +00:00
|
|
|
"for nvme_fcreq x%px.\n",
|
2017-02-12 21:52:32 +00:00
|
|
|
ret_val, pnvme_fcreq);
|
|
|
|
lpfc_sli_release_iocbq(phba, abts_buf);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
Update ABORT processing for NVMET.
The driver with nvme had this routine stubbed.
Right now XRI_ABORTED_CQE is not handled and the FC NVMET
Transport has a new API for the driver.
Missing code path, new NVME abort API
Update ABORT processing for NVMET
There are 3 new FC NVMET Transport API/ template routines for NVMET:
lpfc_nvmet_xmt_fcp_release
This NVMET template callback routine called to release context
associated with an IO This routine is ALWAYS called last, even
if the IO was aborted or completed in error.
lpfc_nvmet_xmt_fcp_abort
This NVMET template callback routine called to abort an exchange that
has an IO in progress
nvmet_fc_rcv_fcp_req
When the lpfc driver receives an ABTS, this NVME FC transport layer
callback routine is called. For this case there are 2 paths thru the
driver: the driver either has an outstanding exchange / context for the
XRI to be aborted or not. If not, a BA_RJT is issued otherwise a BA_ACC
NVMET Driver abort paths:
There are 2 paths for aborting an IO. The first one is we receive an IO and
decide not to process it because of lack of resources. An unsolicated ABTS
is immediately sent back to the initiator as a response.
lpfc_nvmet_unsol_fcp_buffer
lpfc_nvmet_unsol_issue_abort (XMIT_SEQUENCE_WQE)
The second one is we sent the IO up to the NVMET transport layer to
process, and for some reason the NVME Transport layer decided to abort the
IO before it completes all its phases. For this case there are 2 paths
thru the driver:
the driver either has an outstanding TSEND/TRECEIVE/TRSP WQE or no
outstanding WQEs are present for the exchange / context.
lpfc_nvmet_xmt_fcp_abort
if (LPFC_NVMET_IO_INP)
lpfc_nvmet_sol_fcp_issue_abort (ABORT_WQE)
lpfc_nvmet_sol_fcp_abort_cmp
else
lpfc_nvmet_unsol_fcp_issue_abort
lpfc_nvmet_unsol_issue_abort (XMIT_SEQUENCE_WQE)
lpfc_nvmet_unsol_fcp_abort_cmp
Context flags:
LPFC_NVMET_IOP - his flag signifies an IO is in progress on the exchange.
LPFC_NVMET_XBUSY - this flag indicates the IO completed but the firmware
is still busy with the corresponding exchange. The exchange should not be
reused until after a XRI_ABORTED_CQE is received for that exchange.
LPFC_NVMET_ABORT_OP - this flag signifies an ABORT_WQE was issued on the
exchange.
LPFC_NVMET_CTX_RLS - this flag signifies a context free was requested,
but we are deferring it due to an XBUSY or ABORT in progress.
A ctxlock is added to the context structure that is used whenever these
flags are set/read within the context of an IO.
The LPFC_NVMET_CTX_RLS flag is only set in the defer_relase routine when
the transport has resolved all IO associated with the buffer. The flag is
cleared when the CTX is associated with a new IO.
An exchange can has both an LPFC_NVMET_XBUSY and a LPFC_NVMET_ABORT_OP
condition active simultaneously. Both conditions must complete before the
exchange is freed.
When the abort callback (lpfc_nvmet_xmt_fcp_abort) is envoked:
If there is an outstanding IO, the driver will issue an ABORT_WQE. This
should result in 3 completions for the exchange:
1) IO cmpl with XB bit set
2) Abort WQE cmpl
3) XRI_ABORTED_CQE cmpl
For this scenerio, after completion #1, the NVMET Transport IO rsp
callback is called. After completion #2, no action is taken with respect
to the exchange / context. After completion #3, the exchange context is
free for re-use on another IO.
If there is no outstanding activity on the exchange, the driver will send a
ABTS to the Initiator. Upon completion of this WQE, the exchange / context
is freed for re-use on another IO.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
2017-04-21 23:05:04 +00:00
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_ABTS,
|
2017-04-21 23:04:59 +00:00
|
|
|
"6138 Transport Abort NVME Request Issued for "
|
2017-02-12 21:52:32 +00:00
|
|
|
"ox_id x%x on reqtag x%x\n",
|
|
|
|
nvmereq_wqe->sli4_xritag,
|
|
|
|
abts_buf->iotag);
|
2019-01-28 19:14:37 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
out_unlock:
|
|
|
|
spin_unlock(&lpfc_nbuf->buf_lock);
|
|
|
|
spin_unlock_irqrestore(&phba->hbalock, flags);
|
|
|
|
return;
|
2017-02-12 21:52:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Declare and initialization an instance of the FC NVME template. */
|
|
|
|
static struct nvme_fc_port_template lpfc_nvme_template = {
|
|
|
|
/* initiator-based functions */
|
|
|
|
.localport_delete = lpfc_nvme_localport_delete,
|
|
|
|
.remoteport_delete = lpfc_nvme_remoteport_delete,
|
|
|
|
.create_queue = lpfc_nvme_create_queue,
|
|
|
|
.delete_queue = lpfc_nvme_delete_queue,
|
|
|
|
.ls_req = lpfc_nvme_ls_req,
|
|
|
|
.fcp_io = lpfc_nvme_fcp_io_submit,
|
|
|
|
.ls_abort = lpfc_nvme_ls_abort,
|
|
|
|
.fcp_abort = lpfc_nvme_fcp_abort,
|
|
|
|
|
|
|
|
.max_hw_queues = 1,
|
|
|
|
.max_sgl_segments = LPFC_NVME_DEFAULT_SEGS,
|
|
|
|
.max_dif_sgl_segments = LPFC_NVME_DEFAULT_SEGS,
|
|
|
|
.dma_boundary = 0xFFFFFFFF,
|
|
|
|
|
|
|
|
/* Sizes of additional private data for data structures.
|
|
|
|
* No use for the last two sizes at this time.
|
|
|
|
*/
|
|
|
|
.local_priv_sz = sizeof(struct lpfc_nvme_lport),
|
|
|
|
.remote_priv_sz = sizeof(struct lpfc_nvme_rport),
|
|
|
|
.lsrqst_priv_sz = 0,
|
2017-04-22 00:49:08 +00:00
|
|
|
.fcprqst_priv_sz = sizeof(struct lpfc_nvme_fcpreq_priv),
|
2017-02-12 21:52:32 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
2019-01-28 19:14:22 +00:00
|
|
|
* lpfc_get_nvme_buf - Get a nvme buffer from io_buf_list of the HBA
|
2017-02-12 21:52:32 +00:00
|
|
|
* @phba: The HBA for which this call is being executed.
|
|
|
|
*
|
2019-01-28 19:14:22 +00:00
|
|
|
* This routine removes a nvme buffer from head of @hdwq io_buf_list
|
2017-02-12 21:52:32 +00:00
|
|
|
* and returns to caller.
|
|
|
|
*
|
|
|
|
* Return codes:
|
|
|
|
* NULL - Error
|
|
|
|
* Pointer to lpfc_nvme_buf - Success
|
|
|
|
**/
|
scsi: lpfc: Adapt partitioned XRI lists to efficient sharing
The XRI get/put lists were partitioned per hardware queue. However, the
adapter rarely had sufficient resources to give a large number of resources
per queue. As such, it became common for a cpu to encounter a lack of XRI
resource and request the upper io stack to retry after returning a BUSY
condition. This occurred even though other cpus were idle and not using
their resources.
Create as efficient a scheme as possible to move resources to the cpus that
need them. Each cpu maintains a small private pool which it allocates from
for io. There is a watermark that the cpu attempts to keep in the private
pool. The private pool, when empty, pulls from a global pool from the
cpu. When the cpu's global pool is empty it will pull from other cpu's
global pool. As there many cpu global pools (1 per cpu or hardware queue
count) and as each cpu selects what cpu to pull from at different rates and
at different times, it creates a radomizing effect that minimizes the
number of cpu's that will contend with each other when the steal XRI's from
another cpu's global pool.
On io completion, a cpu will push the XRI back on to its private pool. A
watermark level is maintained for the private pool such that when it is
exceeded it will move XRI's to the CPU global pool so that other cpu's may
allocate them.
On NVME, as heartbeat commands are critical to get placed on the wire, a
single expedite pool is maintained. When a heartbeat is to be sent, it will
allocate an XRI from the expedite pool rather than the normal cpu
private/global pools. On any io completion, if a reduction in the expedite
pools is seen, it will be replenished before the XRI is placed on the cpu
private pool.
Statistics are added to aid understanding the XRI levels on each cpu and
their behaviors.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-01-28 19:14:28 +00:00
|
|
|
static struct lpfc_io_buf *
|
2017-12-09 01:18:03 +00:00
|
|
|
lpfc_get_nvme_buf(struct lpfc_hba *phba, struct lpfc_nodelist *ndlp,
|
2019-01-28 19:14:22 +00:00
|
|
|
int idx, int expedite)
|
2017-02-12 21:52:32 +00:00
|
|
|
{
|
scsi: lpfc: Adapt partitioned XRI lists to efficient sharing
The XRI get/put lists were partitioned per hardware queue. However, the
adapter rarely had sufficient resources to give a large number of resources
per queue. As such, it became common for a cpu to encounter a lack of XRI
resource and request the upper io stack to retry after returning a BUSY
condition. This occurred even though other cpus were idle and not using
their resources.
Create as efficient a scheme as possible to move resources to the cpus that
need them. Each cpu maintains a small private pool which it allocates from
for io. There is a watermark that the cpu attempts to keep in the private
pool. The private pool, when empty, pulls from a global pool from the
cpu. When the cpu's global pool is empty it will pull from other cpu's
global pool. As there many cpu global pools (1 per cpu or hardware queue
count) and as each cpu selects what cpu to pull from at different rates and
at different times, it creates a radomizing effect that minimizes the
number of cpu's that will contend with each other when the steal XRI's from
another cpu's global pool.
On io completion, a cpu will push the XRI back on to its private pool. A
watermark level is maintained for the private pool such that when it is
exceeded it will move XRI's to the CPU global pool so that other cpu's may
allocate them.
On NVME, as heartbeat commands are critical to get placed on the wire, a
single expedite pool is maintained. When a heartbeat is to be sent, it will
allocate an XRI from the expedite pool rather than the normal cpu
private/global pools. On any io completion, if a reduction in the expedite
pools is seen, it will be replenished before the XRI is placed on the cpu
private pool.
Statistics are added to aid understanding the XRI levels on each cpu and
their behaviors.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-01-28 19:14:28 +00:00
|
|
|
struct lpfc_io_buf *lpfc_ncmd;
|
2019-01-28 19:14:22 +00:00
|
|
|
struct lpfc_sli4_hdw_queue *qp;
|
2019-01-28 19:14:19 +00:00
|
|
|
struct sli4_sge *sgl;
|
2017-02-12 21:52:32 +00:00
|
|
|
struct lpfc_iocbq *pwqeq;
|
|
|
|
union lpfc_wqe128 *wqe;
|
|
|
|
|
scsi: lpfc: Adapt partitioned XRI lists to efficient sharing
The XRI get/put lists were partitioned per hardware queue. However, the
adapter rarely had sufficient resources to give a large number of resources
per queue. As such, it became common for a cpu to encounter a lack of XRI
resource and request the upper io stack to retry after returning a BUSY
condition. This occurred even though other cpus were idle and not using
their resources.
Create as efficient a scheme as possible to move resources to the cpus that
need them. Each cpu maintains a small private pool which it allocates from
for io. There is a watermark that the cpu attempts to keep in the private
pool. The private pool, when empty, pulls from a global pool from the
cpu. When the cpu's global pool is empty it will pull from other cpu's
global pool. As there many cpu global pools (1 per cpu or hardware queue
count) and as each cpu selects what cpu to pull from at different rates and
at different times, it creates a radomizing effect that minimizes the
number of cpu's that will contend with each other when the steal XRI's from
another cpu's global pool.
On io completion, a cpu will push the XRI back on to its private pool. A
watermark level is maintained for the private pool such that when it is
exceeded it will move XRI's to the CPU global pool so that other cpu's may
allocate them.
On NVME, as heartbeat commands are critical to get placed on the wire, a
single expedite pool is maintained. When a heartbeat is to be sent, it will
allocate an XRI from the expedite pool rather than the normal cpu
private/global pools. On any io completion, if a reduction in the expedite
pools is seen, it will be replenished before the XRI is placed on the cpu
private pool.
Statistics are added to aid understanding the XRI levels on each cpu and
their behaviors.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-01-28 19:14:28 +00:00
|
|
|
lpfc_ncmd = lpfc_get_io_buf(phba, NULL, idx, expedite);
|
2018-08-01 00:23:22 +00:00
|
|
|
|
2019-01-28 19:14:19 +00:00
|
|
|
if (lpfc_ncmd) {
|
2017-02-12 21:52:32 +00:00
|
|
|
pwqeq = &(lpfc_ncmd->cur_iocbq);
|
2018-03-05 20:04:03 +00:00
|
|
|
wqe = &pwqeq->wqe;
|
2017-02-12 21:52:32 +00:00
|
|
|
|
2019-01-28 19:14:19 +00:00
|
|
|
/* Setup key fields in buffer that may have been changed
|
|
|
|
* if other protocols used this buffer.
|
|
|
|
*/
|
|
|
|
pwqeq->iocb_flag = LPFC_IO_NVME;
|
2017-02-12 21:52:32 +00:00
|
|
|
pwqeq->wqe_cmpl = lpfc_nvme_io_cmd_wqe_cmpl;
|
2019-01-28 19:14:19 +00:00
|
|
|
lpfc_ncmd->start_time = jiffies;
|
|
|
|
lpfc_ncmd->flags = 0;
|
2017-02-12 21:52:32 +00:00
|
|
|
|
|
|
|
/* Rsp SGE will be filled in when we rcv an IO
|
|
|
|
* from the NVME Layer to be sent.
|
|
|
|
* The cmd is going to be embedded so we need a SKIP SGE.
|
|
|
|
*/
|
2019-01-28 19:14:19 +00:00
|
|
|
sgl = lpfc_ncmd->dma_sgl;
|
2017-02-12 21:52:32 +00:00
|
|
|
bf_set(lpfc_sli4_sge_type, sgl, LPFC_SGE_TYPE_SKIP);
|
|
|
|
bf_set(lpfc_sli4_sge_last, sgl, 0);
|
|
|
|
sgl->word2 = cpu_to_le32(sgl->word2);
|
|
|
|
/* Fill in word 3 / sgl_len during cmd submission */
|
|
|
|
|
2019-08-14 23:57:04 +00:00
|
|
|
/* Initialize 64 bytes only */
|
2018-03-05 20:04:04 +00:00
|
|
|
memset(wqe, 0, sizeof(union lpfc_wqe));
|
2017-02-12 21:52:32 +00:00
|
|
|
|
2019-01-28 19:14:19 +00:00
|
|
|
if (lpfc_ndlp_check_qdepth(phba, ndlp)) {
|
|
|
|
atomic_inc(&ndlp->cmd_pending);
|
scsi: lpfc: Adapt partitioned XRI lists to efficient sharing
The XRI get/put lists were partitioned per hardware queue. However, the
adapter rarely had sufficient resources to give a large number of resources
per queue. As such, it became common for a cpu to encounter a lack of XRI
resource and request the upper io stack to retry after returning a BUSY
condition. This occurred even though other cpus were idle and not using
their resources.
Create as efficient a scheme as possible to move resources to the cpus that
need them. Each cpu maintains a small private pool which it allocates from
for io. There is a watermark that the cpu attempts to keep in the private
pool. The private pool, when empty, pulls from a global pool from the
cpu. When the cpu's global pool is empty it will pull from other cpu's
global pool. As there many cpu global pools (1 per cpu or hardware queue
count) and as each cpu selects what cpu to pull from at different rates and
at different times, it creates a radomizing effect that minimizes the
number of cpu's that will contend with each other when the steal XRI's from
another cpu's global pool.
On io completion, a cpu will push the XRI back on to its private pool. A
watermark level is maintained for the private pool such that when it is
exceeded it will move XRI's to the CPU global pool so that other cpu's may
allocate them.
On NVME, as heartbeat commands are critical to get placed on the wire, a
single expedite pool is maintained. When a heartbeat is to be sent, it will
allocate an XRI from the expedite pool rather than the normal cpu
private/global pools. On any io completion, if a reduction in the expedite
pools is seen, it will be replenished before the XRI is placed on the cpu
private pool.
Statistics are added to aid understanding the XRI levels on each cpu and
their behaviors.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-01-28 19:14:28 +00:00
|
|
|
lpfc_ncmd->flags |= LPFC_SBUF_BUMP_QDEPTH;
|
2019-01-28 19:14:19 +00:00
|
|
|
}
|
2017-02-12 21:52:32 +00:00
|
|
|
|
scsi: lpfc: Adapt partitioned XRI lists to efficient sharing
The XRI get/put lists were partitioned per hardware queue. However, the
adapter rarely had sufficient resources to give a large number of resources
per queue. As such, it became common for a cpu to encounter a lack of XRI
resource and request the upper io stack to retry after returning a BUSY
condition. This occurred even though other cpus were idle and not using
their resources.
Create as efficient a scheme as possible to move resources to the cpus that
need them. Each cpu maintains a small private pool which it allocates from
for io. There is a watermark that the cpu attempts to keep in the private
pool. The private pool, when empty, pulls from a global pool from the
cpu. When the cpu's global pool is empty it will pull from other cpu's
global pool. As there many cpu global pools (1 per cpu or hardware queue
count) and as each cpu selects what cpu to pull from at different rates and
at different times, it creates a radomizing effect that minimizes the
number of cpu's that will contend with each other when the steal XRI's from
another cpu's global pool.
On io completion, a cpu will push the XRI back on to its private pool. A
watermark level is maintained for the private pool such that when it is
exceeded it will move XRI's to the CPU global pool so that other cpu's may
allocate them.
On NVME, as heartbeat commands are critical to get placed on the wire, a
single expedite pool is maintained. When a heartbeat is to be sent, it will
allocate an XRI from the expedite pool rather than the normal cpu
private/global pools. On any io completion, if a reduction in the expedite
pools is seen, it will be replenished before the XRI is placed on the cpu
private pool.
Statistics are added to aid understanding the XRI levels on each cpu and
their behaviors.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-01-28 19:14:28 +00:00
|
|
|
} else {
|
|
|
|
qp = &phba->sli4_hba.hdwq[idx];
|
2019-01-28 19:14:22 +00:00
|
|
|
qp->empty_io_bufs++;
|
2017-02-12 21:52:32 +00:00
|
|
|
}
|
2018-08-01 00:23:22 +00:00
|
|
|
|
2017-02-12 21:52:32 +00:00
|
|
|
return lpfc_ncmd;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* lpfc_release_nvme_buf: Return a nvme buffer back to hba nvme buf list.
|
|
|
|
* @phba: The Hba for which this call is being executed.
|
|
|
|
* @lpfc_ncmd: The nvme buffer which is being released.
|
|
|
|
*
|
|
|
|
* This routine releases @lpfc_ncmd nvme buffer by adding it to tail of @phba
|
2019-01-28 19:14:22 +00:00
|
|
|
* lpfc_io_buf_list list. For SLI4 XRI's are tied to the nvme buffer
|
2017-02-12 21:52:32 +00:00
|
|
|
* and cannot be reused for at least RA_TOV amount of time if it was
|
|
|
|
* aborted.
|
|
|
|
**/
|
|
|
|
static void
|
scsi: lpfc: Adapt partitioned XRI lists to efficient sharing
The XRI get/put lists were partitioned per hardware queue. However, the
adapter rarely had sufficient resources to give a large number of resources
per queue. As such, it became common for a cpu to encounter a lack of XRI
resource and request the upper io stack to retry after returning a BUSY
condition. This occurred even though other cpus were idle and not using
their resources.
Create as efficient a scheme as possible to move resources to the cpus that
need them. Each cpu maintains a small private pool which it allocates from
for io. There is a watermark that the cpu attempts to keep in the private
pool. The private pool, when empty, pulls from a global pool from the
cpu. When the cpu's global pool is empty it will pull from other cpu's
global pool. As there many cpu global pools (1 per cpu or hardware queue
count) and as each cpu selects what cpu to pull from at different rates and
at different times, it creates a radomizing effect that minimizes the
number of cpu's that will contend with each other when the steal XRI's from
another cpu's global pool.
On io completion, a cpu will push the XRI back on to its private pool. A
watermark level is maintained for the private pool such that when it is
exceeded it will move XRI's to the CPU global pool so that other cpu's may
allocate them.
On NVME, as heartbeat commands are critical to get placed on the wire, a
single expedite pool is maintained. When a heartbeat is to be sent, it will
allocate an XRI from the expedite pool rather than the normal cpu
private/global pools. On any io completion, if a reduction in the expedite
pools is seen, it will be replenished before the XRI is placed on the cpu
private pool.
Statistics are added to aid understanding the XRI levels on each cpu and
their behaviors.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-01-28 19:14:28 +00:00
|
|
|
lpfc_release_nvme_buf(struct lpfc_hba *phba, struct lpfc_io_buf *lpfc_ncmd)
|
2017-02-12 21:52:32 +00:00
|
|
|
{
|
2019-01-28 19:14:22 +00:00
|
|
|
struct lpfc_sli4_hdw_queue *qp;
|
2017-02-12 21:52:32 +00:00
|
|
|
unsigned long iflag = 0;
|
|
|
|
|
scsi: lpfc: Adapt partitioned XRI lists to efficient sharing
The XRI get/put lists were partitioned per hardware queue. However, the
adapter rarely had sufficient resources to give a large number of resources
per queue. As such, it became common for a cpu to encounter a lack of XRI
resource and request the upper io stack to retry after returning a BUSY
condition. This occurred even though other cpus were idle and not using
their resources.
Create as efficient a scheme as possible to move resources to the cpus that
need them. Each cpu maintains a small private pool which it allocates from
for io. There is a watermark that the cpu attempts to keep in the private
pool. The private pool, when empty, pulls from a global pool from the
cpu. When the cpu's global pool is empty it will pull from other cpu's
global pool. As there many cpu global pools (1 per cpu or hardware queue
count) and as each cpu selects what cpu to pull from at different rates and
at different times, it creates a radomizing effect that minimizes the
number of cpu's that will contend with each other when the steal XRI's from
another cpu's global pool.
On io completion, a cpu will push the XRI back on to its private pool. A
watermark level is maintained for the private pool such that when it is
exceeded it will move XRI's to the CPU global pool so that other cpu's may
allocate them.
On NVME, as heartbeat commands are critical to get placed on the wire, a
single expedite pool is maintained. When a heartbeat is to be sent, it will
allocate an XRI from the expedite pool rather than the normal cpu
private/global pools. On any io completion, if a reduction in the expedite
pools is seen, it will be replenished before the XRI is placed on the cpu
private pool.
Statistics are added to aid understanding the XRI levels on each cpu and
their behaviors.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-01-28 19:14:28 +00:00
|
|
|
if ((lpfc_ncmd->flags & LPFC_SBUF_BUMP_QDEPTH) && lpfc_ncmd->ndlp)
|
2018-08-01 00:23:22 +00:00
|
|
|
atomic_dec(&lpfc_ncmd->ndlp->cmd_pending);
|
|
|
|
|
|
|
|
lpfc_ncmd->ndlp = NULL;
|
scsi: lpfc: Adapt partitioned XRI lists to efficient sharing
The XRI get/put lists were partitioned per hardware queue. However, the
adapter rarely had sufficient resources to give a large number of resources
per queue. As such, it became common for a cpu to encounter a lack of XRI
resource and request the upper io stack to retry after returning a BUSY
condition. This occurred even though other cpus were idle and not using
their resources.
Create as efficient a scheme as possible to move resources to the cpus that
need them. Each cpu maintains a small private pool which it allocates from
for io. There is a watermark that the cpu attempts to keep in the private
pool. The private pool, when empty, pulls from a global pool from the
cpu. When the cpu's global pool is empty it will pull from other cpu's
global pool. As there many cpu global pools (1 per cpu or hardware queue
count) and as each cpu selects what cpu to pull from at different rates and
at different times, it creates a radomizing effect that minimizes the
number of cpu's that will contend with each other when the steal XRI's from
another cpu's global pool.
On io completion, a cpu will push the XRI back on to its private pool. A
watermark level is maintained for the private pool such that when it is
exceeded it will move XRI's to the CPU global pool so that other cpu's may
allocate them.
On NVME, as heartbeat commands are critical to get placed on the wire, a
single expedite pool is maintained. When a heartbeat is to be sent, it will
allocate an XRI from the expedite pool rather than the normal cpu
private/global pools. On any io completion, if a reduction in the expedite
pools is seen, it will be replenished before the XRI is placed on the cpu
private pool.
Statistics are added to aid understanding the XRI levels on each cpu and
their behaviors.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-01-28 19:14:28 +00:00
|
|
|
lpfc_ncmd->flags &= ~LPFC_SBUF_BUMP_QDEPTH;
|
2018-08-01 00:23:22 +00:00
|
|
|
|
2019-01-28 19:14:26 +00:00
|
|
|
qp = lpfc_ncmd->hdwq;
|
2019-10-18 21:18:24 +00:00
|
|
|
if (unlikely(lpfc_ncmd->flags & LPFC_SBUF_XBUSY)) {
|
Update ABORT processing for NVMET.
The driver with nvme had this routine stubbed.
Right now XRI_ABORTED_CQE is not handled and the FC NVMET
Transport has a new API for the driver.
Missing code path, new NVME abort API
Update ABORT processing for NVMET
There are 3 new FC NVMET Transport API/ template routines for NVMET:
lpfc_nvmet_xmt_fcp_release
This NVMET template callback routine called to release context
associated with an IO This routine is ALWAYS called last, even
if the IO was aborted or completed in error.
lpfc_nvmet_xmt_fcp_abort
This NVMET template callback routine called to abort an exchange that
has an IO in progress
nvmet_fc_rcv_fcp_req
When the lpfc driver receives an ABTS, this NVME FC transport layer
callback routine is called. For this case there are 2 paths thru the
driver: the driver either has an outstanding exchange / context for the
XRI to be aborted or not. If not, a BA_RJT is issued otherwise a BA_ACC
NVMET Driver abort paths:
There are 2 paths for aborting an IO. The first one is we receive an IO and
decide not to process it because of lack of resources. An unsolicated ABTS
is immediately sent back to the initiator as a response.
lpfc_nvmet_unsol_fcp_buffer
lpfc_nvmet_unsol_issue_abort (XMIT_SEQUENCE_WQE)
The second one is we sent the IO up to the NVMET transport layer to
process, and for some reason the NVME Transport layer decided to abort the
IO before it completes all its phases. For this case there are 2 paths
thru the driver:
the driver either has an outstanding TSEND/TRECEIVE/TRSP WQE or no
outstanding WQEs are present for the exchange / context.
lpfc_nvmet_xmt_fcp_abort
if (LPFC_NVMET_IO_INP)
lpfc_nvmet_sol_fcp_issue_abort (ABORT_WQE)
lpfc_nvmet_sol_fcp_abort_cmp
else
lpfc_nvmet_unsol_fcp_issue_abort
lpfc_nvmet_unsol_issue_abort (XMIT_SEQUENCE_WQE)
lpfc_nvmet_unsol_fcp_abort_cmp
Context flags:
LPFC_NVMET_IOP - his flag signifies an IO is in progress on the exchange.
LPFC_NVMET_XBUSY - this flag indicates the IO completed but the firmware
is still busy with the corresponding exchange. The exchange should not be
reused until after a XRI_ABORTED_CQE is received for that exchange.
LPFC_NVMET_ABORT_OP - this flag signifies an ABORT_WQE was issued on the
exchange.
LPFC_NVMET_CTX_RLS - this flag signifies a context free was requested,
but we are deferring it due to an XBUSY or ABORT in progress.
A ctxlock is added to the context structure that is used whenever these
flags are set/read within the context of an IO.
The LPFC_NVMET_CTX_RLS flag is only set in the defer_relase routine when
the transport has resolved all IO associated with the buffer. The flag is
cleared when the CTX is associated with a new IO.
An exchange can has both an LPFC_NVMET_XBUSY and a LPFC_NVMET_ABORT_OP
condition active simultaneously. Both conditions must complete before the
exchange is freed.
When the abort callback (lpfc_nvmet_xmt_fcp_abort) is envoked:
If there is an outstanding IO, the driver will issue an ABORT_WQE. This
should result in 3 completions for the exchange:
1) IO cmpl with XB bit set
2) Abort WQE cmpl
3) XRI_ABORTED_CQE cmpl
For this scenerio, after completion #1, the NVMET Transport IO rsp
callback is called. After completion #2, no action is taken with respect
to the exchange / context. After completion #3, the exchange context is
free for re-use on another IO.
If there is no outstanding activity on the exchange, the driver will send a
ABTS to the Initiator. Upon completion of this WQE, the exchange / context
is freed for re-use on another IO.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
2017-04-21 23:05:04 +00:00
|
|
|
lpfc_printf_log(phba, KERN_INFO, LOG_NVME_ABTS,
|
|
|
|
"6310 XB release deferred for "
|
|
|
|
"ox_id x%x on reqtag x%x\n",
|
|
|
|
lpfc_ncmd->cur_iocbq.sli4_xritag,
|
|
|
|
lpfc_ncmd->cur_iocbq.iotag);
|
|
|
|
|
2019-08-14 23:57:11 +00:00
|
|
|
spin_lock_irqsave(&qp->abts_io_buf_list_lock, iflag);
|
2017-02-12 21:52:32 +00:00
|
|
|
list_add_tail(&lpfc_ncmd->list,
|
2019-08-14 23:57:11 +00:00
|
|
|
&qp->lpfc_abts_io_buf_list);
|
2019-01-28 19:14:22 +00:00
|
|
|
qp->abts_nvme_io_bufs++;
|
2019-08-14 23:57:11 +00:00
|
|
|
spin_unlock_irqrestore(&qp->abts_io_buf_list_lock, iflag);
|
scsi: lpfc: Adapt partitioned XRI lists to efficient sharing
The XRI get/put lists were partitioned per hardware queue. However, the
adapter rarely had sufficient resources to give a large number of resources
per queue. As such, it became common for a cpu to encounter a lack of XRI
resource and request the upper io stack to retry after returning a BUSY
condition. This occurred even though other cpus were idle and not using
their resources.
Create as efficient a scheme as possible to move resources to the cpus that
need them. Each cpu maintains a small private pool which it allocates from
for io. There is a watermark that the cpu attempts to keep in the private
pool. The private pool, when empty, pulls from a global pool from the
cpu. When the cpu's global pool is empty it will pull from other cpu's
global pool. As there many cpu global pools (1 per cpu or hardware queue
count) and as each cpu selects what cpu to pull from at different rates and
at different times, it creates a radomizing effect that minimizes the
number of cpu's that will contend with each other when the steal XRI's from
another cpu's global pool.
On io completion, a cpu will push the XRI back on to its private pool. A
watermark level is maintained for the private pool such that when it is
exceeded it will move XRI's to the CPU global pool so that other cpu's may
allocate them.
On NVME, as heartbeat commands are critical to get placed on the wire, a
single expedite pool is maintained. When a heartbeat is to be sent, it will
allocate an XRI from the expedite pool rather than the normal cpu
private/global pools. On any io completion, if a reduction in the expedite
pools is seen, it will be replenished before the XRI is placed on the cpu
private pool.
Statistics are added to aid understanding the XRI levels on each cpu and
their behaviors.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-01-28 19:14:28 +00:00
|
|
|
} else
|
|
|
|
lpfc_release_io_buf(phba, (struct lpfc_io_buf *)lpfc_ncmd, qp);
|
2017-02-12 21:52:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* lpfc_nvme_create_localport - Create/Bind an nvme localport instance.
|
|
|
|
* @pvport - the lpfc_vport instance requesting a localport.
|
|
|
|
*
|
|
|
|
* This routine is invoked to create an nvme localport instance to bind
|
|
|
|
* to the nvme_fc_transport. It is called once during driver load
|
|
|
|
* like lpfc_create_shost after all other services are initialized.
|
|
|
|
* It requires a vport, vpi, and wwns at call time. Other localport
|
|
|
|
* parameters are modified as the driver's FCID and the Fabric WWN
|
|
|
|
* are established.
|
|
|
|
*
|
|
|
|
* Return codes
|
|
|
|
* 0 - successful
|
|
|
|
* -ENOMEM - no heap memory available
|
|
|
|
* other values - from nvme registration upcall
|
|
|
|
**/
|
|
|
|
int
|
|
|
|
lpfc_nvme_create_localport(struct lpfc_vport *vport)
|
|
|
|
{
|
2017-03-04 17:30:33 +00:00
|
|
|
int ret = 0;
|
2017-02-12 21:52:32 +00:00
|
|
|
struct lpfc_hba *phba = vport->phba;
|
|
|
|
struct nvme_fc_port_info nfcp_info;
|
|
|
|
struct nvme_fc_local_port *localport;
|
|
|
|
struct lpfc_nvme_lport *lport;
|
|
|
|
|
|
|
|
/* Initialize this localport instance. The vport wwn usage ensures
|
|
|
|
* that NPIV is accounted for.
|
|
|
|
*/
|
|
|
|
memset(&nfcp_info, 0, sizeof(struct nvme_fc_port_info));
|
|
|
|
nfcp_info.port_role = FC_PORT_ROLE_NVME_INITIATOR;
|
|
|
|
nfcp_info.node_name = wwn_to_u64(vport->fc_nodename.u.wwn);
|
|
|
|
nfcp_info.port_name = wwn_to_u64(vport->fc_portname.u.wwn);
|
|
|
|
|
2018-09-10 17:30:42 +00:00
|
|
|
/* We need to tell the transport layer + 1 because it takes page
|
|
|
|
* alignment into account. When space for the SGL is allocated we
|
|
|
|
* allocate + 3, one for cmd, one for rsp and one for this alignment
|
2017-04-21 23:05:01 +00:00
|
|
|
*/
|
|
|
|
lpfc_nvme_template.max_sgl_segments = phba->cfg_nvme_seg_cnt + 1;
|
2017-02-12 21:52:32 +00:00
|
|
|
|
2019-11-11 23:04:00 +00:00
|
|
|
/* Advertise how many hw queues we support based on cfg_hdw_queue,
|
|
|
|
* which will not exceed cpu count.
|
|
|
|
*/
|
|
|
|
lpfc_nvme_template.max_hw_queues = phba->cfg_hdw_queue;
|
2018-04-09 21:24:23 +00:00
|
|
|
|
2019-03-22 14:25:49 +00:00
|
|
|
if (!IS_ENABLED(CONFIG_NVME_FC))
|
|
|
|
return ret;
|
|
|
|
|
2017-02-12 21:52:32 +00:00
|
|
|
/* localport is allocated from the stack, but the registration
|
|
|
|
* call allocates heap memory as well as the private area.
|
|
|
|
*/
|
2019-03-22 14:25:49 +00:00
|
|
|
|
2017-02-12 21:52:32 +00:00
|
|
|
ret = nvme_fc_register_localport(&nfcp_info, &lpfc_nvme_template,
|
|
|
|
&vport->phba->pcidev->dev, &localport);
|
|
|
|
if (!ret) {
|
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME | LOG_NVME_DISC,
|
|
|
|
"6005 Successfully registered local "
|
2019-08-14 23:57:06 +00:00
|
|
|
"NVME port num %d, localP x%px, private "
|
|
|
|
"x%px, sg_seg %d\n",
|
2017-02-12 21:52:32 +00:00
|
|
|
localport->port_num, localport,
|
|
|
|
localport->private,
|
|
|
|
lpfc_nvme_template.max_sgl_segments);
|
|
|
|
|
|
|
|
/* Private is our lport size declared in the template. */
|
|
|
|
lport = (struct lpfc_nvme_lport *)localport->private;
|
|
|
|
vport->localport = localport;
|
|
|
|
lport->vport = vport;
|
|
|
|
vport->nvmei_support = 1;
|
2017-08-23 23:55:45 +00:00
|
|
|
|
2017-12-09 01:18:10 +00:00
|
|
|
atomic_set(&lport->xmt_fcp_noxri, 0);
|
|
|
|
atomic_set(&lport->xmt_fcp_bad_ndlp, 0);
|
|
|
|
atomic_set(&lport->xmt_fcp_qdepth, 0);
|
2018-05-05 03:37:56 +00:00
|
|
|
atomic_set(&lport->xmt_fcp_err, 0);
|
2017-12-09 01:18:10 +00:00
|
|
|
atomic_set(&lport->xmt_fcp_wqerr, 0);
|
|
|
|
atomic_set(&lport->xmt_fcp_abort, 0);
|
|
|
|
atomic_set(&lport->xmt_ls_abort, 0);
|
|
|
|
atomic_set(&lport->xmt_ls_err, 0);
|
|
|
|
atomic_set(&lport->cmpl_fcp_xb, 0);
|
|
|
|
atomic_set(&lport->cmpl_fcp_err, 0);
|
|
|
|
atomic_set(&lport->cmpl_ls_xb, 0);
|
|
|
|
atomic_set(&lport->cmpl_ls_err, 0);
|
2018-04-09 21:24:23 +00:00
|
|
|
atomic_set(&lport->fc4NvmeLsRequests, 0);
|
|
|
|
atomic_set(&lport->fc4NvmeLsCmpls, 0);
|
2017-02-12 21:52:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2019-04-05 16:14:10 +00:00
|
|
|
#if (IS_ENABLED(CONFIG_NVME_FC))
|
2017-11-21 00:00:40 +00:00
|
|
|
/* lpfc_nvme_lport_unreg_wait - Wait for the host to complete an lport unreg.
|
|
|
|
*
|
|
|
|
* The driver has to wait for the host nvme transport to callback
|
|
|
|
* indicating the localport has successfully unregistered all
|
|
|
|
* resources. Since this is an uninterruptible wait, loop every ten
|
|
|
|
* seconds and print a message indicating no progress.
|
|
|
|
*
|
|
|
|
* An uninterruptible wait is used because of the risk of transport-to-
|
|
|
|
* driver state mismatch.
|
|
|
|
*/
|
2019-03-28 18:06:16 +00:00
|
|
|
static void
|
2017-11-21 00:00:40 +00:00
|
|
|
lpfc_nvme_lport_unreg_wait(struct lpfc_vport *vport,
|
2019-01-17 16:14:44 +00:00
|
|
|
struct lpfc_nvme_lport *lport,
|
|
|
|
struct completion *lport_unreg_cmp)
|
2017-11-21 00:00:40 +00:00
|
|
|
{
|
|
|
|
u32 wait_tmo;
|
2019-05-22 00:48:54 +00:00
|
|
|
int ret, i, pending = 0;
|
|
|
|
struct lpfc_sli_ring *pring;
|
|
|
|
struct lpfc_hba *phba = vport->phba;
|
2017-11-21 00:00:40 +00:00
|
|
|
|
|
|
|
/* Host transport has to clean up and confirm requiring an indefinite
|
|
|
|
* wait. Print a message if a 10 second wait expires and renew the
|
|
|
|
* wait. This is unexpected.
|
|
|
|
*/
|
|
|
|
wait_tmo = msecs_to_jiffies(LPFC_NVME_WAIT_TMO * 1000);
|
|
|
|
while (true) {
|
2019-01-17 16:14:44 +00:00
|
|
|
ret = wait_for_completion_timeout(lport_unreg_cmp, wait_tmo);
|
2017-11-21 00:00:40 +00:00
|
|
|
if (unlikely(!ret)) {
|
2019-05-22 00:48:54 +00:00
|
|
|
pending = 0;
|
|
|
|
for (i = 0; i < phba->cfg_hdw_queue; i++) {
|
2019-08-14 23:57:11 +00:00
|
|
|
pring = phba->sli4_hba.hdwq[i].io_wq->pring;
|
2019-05-22 00:48:54 +00:00
|
|
|
if (!pring)
|
|
|
|
continue;
|
|
|
|
if (pring->txcmplq_cnt)
|
|
|
|
pending += pring->txcmplq_cnt;
|
|
|
|
}
|
2017-11-21 00:00:40 +00:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_NVME_IOERR,
|
2019-08-14 23:57:06 +00:00
|
|
|
"6176 Lport x%px Localport x%px wait "
|
2019-05-22 00:48:54 +00:00
|
|
|
"timed out. Pending %d. Renewing.\n",
|
|
|
|
lport, vport->localport, pending);
|
2017-11-21 00:00:40 +00:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_IOERR,
|
2019-08-14 23:57:06 +00:00
|
|
|
"6177 Lport x%px Localport x%px Complete Success\n",
|
2017-11-21 00:00:40 +00:00
|
|
|
lport, vport->localport);
|
|
|
|
}
|
2019-04-05 16:14:10 +00:00
|
|
|
#endif
|
2017-11-21 00:00:40 +00:00
|
|
|
|
2017-02-12 21:52:32 +00:00
|
|
|
/**
|
|
|
|
* lpfc_nvme_destroy_localport - Destroy lpfc_nvme bound to nvme transport.
|
|
|
|
* @pnvme: pointer to lpfc nvme data structure.
|
|
|
|
*
|
|
|
|
* This routine is invoked to destroy all lports bound to the phba.
|
|
|
|
* The lport memory was allocated by the nvme fc transport and is
|
|
|
|
* released there. This routine ensures all rports bound to the
|
|
|
|
* lport have been disconnected.
|
|
|
|
*
|
|
|
|
**/
|
|
|
|
void
|
|
|
|
lpfc_nvme_destroy_localport(struct lpfc_vport *vport)
|
|
|
|
{
|
2017-03-08 22:36:01 +00:00
|
|
|
#if (IS_ENABLED(CONFIG_NVME_FC))
|
2017-02-12 21:52:32 +00:00
|
|
|
struct nvme_fc_local_port *localport;
|
|
|
|
struct lpfc_nvme_lport *lport;
|
|
|
|
int ret;
|
2019-01-17 16:14:44 +00:00
|
|
|
DECLARE_COMPLETION_ONSTACK(lport_unreg_cmp);
|
2017-02-12 21:52:32 +00:00
|
|
|
|
|
|
|
if (vport->nvmei_support == 0)
|
|
|
|
return;
|
|
|
|
|
|
|
|
localport = vport->localport;
|
|
|
|
lport = (struct lpfc_nvme_lport *)localport->private;
|
|
|
|
|
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME,
|
2019-08-14 23:57:06 +00:00
|
|
|
"6011 Destroying NVME localport x%px\n",
|
2017-02-12 21:52:32 +00:00
|
|
|
localport);
|
2017-03-04 17:30:33 +00:00
|
|
|
|
2017-02-12 21:52:32 +00:00
|
|
|
/* lport's rport list is clear. Unregister
|
|
|
|
* lport and release resources.
|
|
|
|
*/
|
2019-01-17 16:14:44 +00:00
|
|
|
lport->lport_unreg_cmp = &lport_unreg_cmp;
|
2017-02-12 21:52:32 +00:00
|
|
|
ret = nvme_fc_unregister_localport(localport);
|
2017-11-21 00:00:40 +00:00
|
|
|
|
|
|
|
/* Wait for completion. This either blocks
|
|
|
|
* indefinitely or succeeds
|
|
|
|
*/
|
2019-01-17 16:14:44 +00:00
|
|
|
lpfc_nvme_lport_unreg_wait(vport, lport, &lport_unreg_cmp);
|
|
|
|
vport->localport = NULL;
|
2017-02-12 21:52:32 +00:00
|
|
|
|
|
|
|
/* Regardless of the unregister upcall response, clear
|
|
|
|
* nvmei_support. All rports are unregistered and the
|
|
|
|
* driver will clean up.
|
|
|
|
*/
|
|
|
|
vport->nvmei_support = 0;
|
|
|
|
if (ret == 0) {
|
|
|
|
lpfc_printf_vlog(vport,
|
|
|
|
KERN_INFO, LOG_NVME_DISC,
|
|
|
|
"6009 Unregistered lport Success\n");
|
|
|
|
} else {
|
|
|
|
lpfc_printf_vlog(vport,
|
|
|
|
KERN_INFO, LOG_NVME_DISC,
|
|
|
|
"6010 Unregistered lport "
|
|
|
|
"Failed, status x%x\n",
|
|
|
|
ret);
|
|
|
|
}
|
2017-03-04 17:30:33 +00:00
|
|
|
#endif
|
2017-02-12 21:52:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
lpfc_nvme_update_localport(struct lpfc_vport *vport)
|
|
|
|
{
|
2017-04-21 23:04:57 +00:00
|
|
|
#if (IS_ENABLED(CONFIG_NVME_FC))
|
2017-02-12 21:52:32 +00:00
|
|
|
struct nvme_fc_local_port *localport;
|
|
|
|
struct lpfc_nvme_lport *lport;
|
|
|
|
|
|
|
|
localport = vport->localport;
|
2017-04-21 23:04:57 +00:00
|
|
|
if (!localport) {
|
|
|
|
lpfc_printf_vlog(vport, KERN_WARNING, LOG_NVME,
|
|
|
|
"6710 Update NVME fail. No localport\n");
|
|
|
|
return;
|
|
|
|
}
|
2017-02-12 21:52:32 +00:00
|
|
|
lport = (struct lpfc_nvme_lport *)localport->private;
|
2017-04-21 23:04:57 +00:00
|
|
|
if (!lport) {
|
|
|
|
lpfc_printf_vlog(vport, KERN_WARNING, LOG_NVME,
|
2019-08-14 23:57:06 +00:00
|
|
|
"6171 Update NVME fail. localP x%px, No lport\n",
|
2017-04-21 23:04:57 +00:00
|
|
|
localport);
|
|
|
|
return;
|
|
|
|
}
|
2017-02-12 21:52:32 +00:00
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME,
|
2019-08-14 23:57:06 +00:00
|
|
|
"6012 Update NVME lport x%px did x%x\n",
|
2017-02-12 21:52:32 +00:00
|
|
|
localport, vport->fc_myDID);
|
|
|
|
|
|
|
|
localport->port_id = vport->fc_myDID;
|
|
|
|
if (localport->port_id == 0)
|
|
|
|
localport->port_role = FC_PORT_ROLE_NVME_DISCOVERY;
|
|
|
|
else
|
|
|
|
localport->port_role = FC_PORT_ROLE_NVME_INITIATOR;
|
|
|
|
|
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_DISC,
|
2019-08-14 23:57:06 +00:00
|
|
|
"6030 bound lport x%px to DID x%06x\n",
|
2017-02-12 21:52:32 +00:00
|
|
|
lport, localport->port_id);
|
2017-04-21 23:04:57 +00:00
|
|
|
#endif
|
2017-02-12 21:52:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
lpfc_nvme_register_port(struct lpfc_vport *vport, struct lpfc_nodelist *ndlp)
|
|
|
|
{
|
2017-03-08 22:36:01 +00:00
|
|
|
#if (IS_ENABLED(CONFIG_NVME_FC))
|
2017-02-12 21:52:32 +00:00
|
|
|
int ret = 0;
|
|
|
|
struct nvme_fc_local_port *localport;
|
|
|
|
struct lpfc_nvme_lport *lport;
|
|
|
|
struct lpfc_nvme_rport *rport;
|
2018-04-09 21:24:27 +00:00
|
|
|
struct lpfc_nvme_rport *oldrport;
|
2017-02-12 21:52:32 +00:00
|
|
|
struct nvme_fc_remote_port *remote_port;
|
|
|
|
struct nvme_fc_port_info rpinfo;
|
2018-08-01 00:23:21 +00:00
|
|
|
struct lpfc_nodelist *prev_ndlp = NULL;
|
2017-02-12 21:52:32 +00:00
|
|
|
|
|
|
|
lpfc_printf_vlog(ndlp->vport, KERN_INFO, LOG_NVME_DISC,
|
|
|
|
"6006 Register NVME PORT. DID x%06x nlptype x%x\n",
|
|
|
|
ndlp->nlp_DID, ndlp->nlp_type);
|
|
|
|
|
|
|
|
localport = vport->localport;
|
2017-08-23 23:55:33 +00:00
|
|
|
if (!localport)
|
|
|
|
return 0;
|
|
|
|
|
2017-02-12 21:52:32 +00:00
|
|
|
lport = (struct lpfc_nvme_lport *)localport->private;
|
|
|
|
|
2017-06-02 04:06:55 +00:00
|
|
|
/* NVME rports are not preserved across devloss.
|
|
|
|
* Just register this instance. Note, rpinfo->dev_loss_tmo
|
|
|
|
* is left 0 to indicate accept transport defaults. The
|
|
|
|
* driver communicates port role capabilities consistent
|
|
|
|
* with the PRLI response data.
|
|
|
|
*/
|
|
|
|
memset(&rpinfo, 0, sizeof(struct nvme_fc_port_info));
|
|
|
|
rpinfo.port_id = ndlp->nlp_DID;
|
|
|
|
if (ndlp->nlp_type & NLP_NVME_TARGET)
|
|
|
|
rpinfo.port_role |= FC_PORT_ROLE_NVME_TARGET;
|
|
|
|
if (ndlp->nlp_type & NLP_NVME_INITIATOR)
|
|
|
|
rpinfo.port_role |= FC_PORT_ROLE_NVME_INITIATOR;
|
|
|
|
|
|
|
|
if (ndlp->nlp_type & NLP_NVME_DISCOVERY)
|
|
|
|
rpinfo.port_role |= FC_PORT_ROLE_NVME_DISCOVERY;
|
|
|
|
|
|
|
|
rpinfo.port_name = wwn_to_u64(ndlp->nlp_portname.u.wwn);
|
|
|
|
rpinfo.node_name = wwn_to_u64(ndlp->nlp_nodename.u.wwn);
|
2018-04-09 21:24:27 +00:00
|
|
|
|
2018-09-13 22:41:10 +00:00
|
|
|
spin_lock_irq(&vport->phba->hbalock);
|
2018-04-09 21:24:27 +00:00
|
|
|
oldrport = lpfc_ndlp_get_nrport(ndlp);
|
2019-08-14 23:56:41 +00:00
|
|
|
if (oldrport) {
|
|
|
|
prev_ndlp = oldrport->ndlp;
|
|
|
|
spin_unlock_irq(&vport->phba->hbalock);
|
|
|
|
} else {
|
|
|
|
spin_unlock_irq(&vport->phba->hbalock);
|
2017-12-09 01:18:09 +00:00
|
|
|
lpfc_nlp_get(ndlp);
|
2019-08-14 23:56:41 +00:00
|
|
|
}
|
2017-12-09 01:18:09 +00:00
|
|
|
|
2017-06-02 04:06:55 +00:00
|
|
|
ret = nvme_fc_register_remoteport(localport, &rpinfo, &remote_port);
|
|
|
|
if (!ret) {
|
|
|
|
/* If the ndlp already has an nrport, this is just
|
|
|
|
* a resume of the existing rport. Else this is a
|
|
|
|
* new rport.
|
2017-02-12 21:52:32 +00:00
|
|
|
*/
|
2018-04-09 21:24:30 +00:00
|
|
|
/* Guard against an unregister/reregister
|
|
|
|
* race that leaves the WAIT flag set.
|
|
|
|
*/
|
|
|
|
spin_lock_irq(&vport->phba->hbalock);
|
|
|
|
ndlp->upcall_flags &= ~NLP_WAIT_FOR_UNREG;
|
|
|
|
spin_unlock_irq(&vport->phba->hbalock);
|
2017-06-02 04:06:55 +00:00
|
|
|
rport = remote_port->private;
|
2018-04-09 21:24:27 +00:00
|
|
|
if (oldrport) {
|
2018-08-01 00:23:21 +00:00
|
|
|
/* New remoteport record does not guarantee valid
|
|
|
|
* host private memory area.
|
|
|
|
*/
|
2018-04-09 21:24:27 +00:00
|
|
|
if (oldrport == remote_port->private) {
|
2018-08-01 00:23:21 +00:00
|
|
|
/* Same remoteport - ndlp should match.
|
|
|
|
* Just reuse.
|
|
|
|
*/
|
2017-12-09 01:18:09 +00:00
|
|
|
lpfc_printf_vlog(ndlp->vport, KERN_INFO,
|
|
|
|
LOG_NVME_DISC,
|
2019-08-14 23:56:51 +00:00
|
|
|
"6014 Rebind lport to current "
|
2019-08-14 23:57:06 +00:00
|
|
|
"remoteport x%px wwpn 0x%llx, "
|
|
|
|
"Data: x%x x%x x%px x%px x%x "
|
|
|
|
" x%06x\n",
|
2017-12-09 01:18:09 +00:00
|
|
|
remote_port,
|
|
|
|
remote_port->port_name,
|
|
|
|
remote_port->port_id,
|
|
|
|
remote_port->port_role,
|
2019-08-14 23:56:41 +00:00
|
|
|
oldrport->ndlp,
|
2017-12-09 01:18:09 +00:00
|
|
|
ndlp,
|
|
|
|
ndlp->nlp_type,
|
|
|
|
ndlp->nlp_DID);
|
2019-08-14 23:56:51 +00:00
|
|
|
|
|
|
|
/* It's a complete rebind only if the driver
|
|
|
|
* is registering with the same ndlp. Otherwise
|
|
|
|
* the driver likely executed a node swap
|
|
|
|
* prior to this registration and the ndlp to
|
|
|
|
* remoteport binding needs to be redone.
|
|
|
|
*/
|
|
|
|
if (prev_ndlp == ndlp)
|
|
|
|
return 0;
|
|
|
|
|
2017-12-09 01:18:09 +00:00
|
|
|
}
|
2017-09-30 00:34:30 +00:00
|
|
|
|
2017-12-09 01:18:09 +00:00
|
|
|
/* Sever the ndlp<->rport association
|
|
|
|
* before dropping the ndlp ref from
|
|
|
|
* register.
|
2017-09-30 00:34:30 +00:00
|
|
|
*/
|
2017-12-09 01:18:09 +00:00
|
|
|
spin_lock_irq(&vport->phba->hbalock);
|
2017-09-30 00:34:30 +00:00
|
|
|
ndlp->nrport = NULL;
|
2018-04-09 21:24:27 +00:00
|
|
|
ndlp->upcall_flags &= ~NLP_WAIT_FOR_UNREG;
|
2017-12-09 01:18:09 +00:00
|
|
|
spin_unlock_irq(&vport->phba->hbalock);
|
2017-09-30 00:34:30 +00:00
|
|
|
rport->ndlp = NULL;
|
2017-12-09 01:18:09 +00:00
|
|
|
rport->remoteport = NULL;
|
2018-04-09 21:24:29 +00:00
|
|
|
|
|
|
|
/* Reference only removed if previous NDLP is no longer
|
|
|
|
* active. It might be just a swap and removing the
|
|
|
|
* reference would cause a premature cleanup.
|
|
|
|
*/
|
|
|
|
if (prev_ndlp && prev_ndlp != ndlp) {
|
|
|
|
if ((!NLP_CHK_NODE_ACT(prev_ndlp)) ||
|
|
|
|
(!prev_ndlp->nrport))
|
|
|
|
lpfc_nlp_put(prev_ndlp);
|
|
|
|
}
|
2017-02-12 21:52:32 +00:00
|
|
|
}
|
2017-09-30 00:34:30 +00:00
|
|
|
|
|
|
|
/* Clean bind the rport to the ndlp. */
|
|
|
|
rport->remoteport = remote_port;
|
|
|
|
rport->lport = lport;
|
2017-12-09 01:18:09 +00:00
|
|
|
rport->ndlp = ndlp;
|
|
|
|
spin_lock_irq(&vport->phba->hbalock);
|
2017-09-30 00:34:30 +00:00
|
|
|
ndlp->nrport = rport;
|
2017-12-09 01:18:09 +00:00
|
|
|
spin_unlock_irq(&vport->phba->hbalock);
|
2017-09-30 00:34:30 +00:00
|
|
|
lpfc_printf_vlog(vport, KERN_INFO,
|
|
|
|
LOG_NVME_DISC | LOG_NODE,
|
2019-08-14 23:56:51 +00:00
|
|
|
"6022 Bind lport x%px to remoteport x%px "
|
|
|
|
"rport x%px WWNN 0x%llx, "
|
2017-09-30 00:34:30 +00:00
|
|
|
"Rport WWPN 0x%llx DID "
|
2019-08-14 23:57:06 +00:00
|
|
|
"x%06x Role x%x, ndlp %p prev_ndlp x%px\n",
|
2018-08-01 00:23:21 +00:00
|
|
|
lport, remote_port, rport,
|
2017-09-30 00:34:30 +00:00
|
|
|
rpinfo.node_name, rpinfo.port_name,
|
2017-12-09 01:18:09 +00:00
|
|
|
rpinfo.port_id, rpinfo.port_role,
|
2018-08-01 00:23:21 +00:00
|
|
|
ndlp, prev_ndlp);
|
2017-02-12 21:52:32 +00:00
|
|
|
} else {
|
2017-06-02 04:06:55 +00:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR,
|
|
|
|
LOG_NVME_DISC | LOG_NODE,
|
|
|
|
"6031 RemotePort Registration failed "
|
|
|
|
"err: %d, DID x%06x\n",
|
|
|
|
ret, ndlp->nlp_DID);
|
2017-02-12 21:52:32 +00:00
|
|
|
}
|
2017-06-02 04:06:55 +00:00
|
|
|
|
2017-02-12 21:52:32 +00:00
|
|
|
return ret;
|
2017-03-04 17:30:33 +00:00
|
|
|
#else
|
|
|
|
return 0;
|
|
|
|
#endif
|
2017-02-12 21:52:32 +00:00
|
|
|
}
|
|
|
|
|
2019-05-14 21:58:07 +00:00
|
|
|
/**
|
|
|
|
* lpfc_nvme_rescan_port - Check to see if we should rescan this remoteport
|
|
|
|
*
|
|
|
|
* If the ndlp represents an NVME Target, that we are logged into,
|
|
|
|
* ping the NVME FC Transport layer to initiate a device rescan
|
|
|
|
* on this remote NPort.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
lpfc_nvme_rescan_port(struct lpfc_vport *vport, struct lpfc_nodelist *ndlp)
|
|
|
|
{
|
|
|
|
#if (IS_ENABLED(CONFIG_NVME_FC))
|
2019-08-14 23:56:50 +00:00
|
|
|
struct lpfc_nvme_rport *nrport;
|
|
|
|
struct nvme_fc_remote_port *remoteport = NULL;
|
2019-05-14 21:58:07 +00:00
|
|
|
|
2019-08-14 23:56:50 +00:00
|
|
|
spin_lock_irq(&vport->phba->hbalock);
|
|
|
|
nrport = lpfc_ndlp_get_nrport(ndlp);
|
|
|
|
if (nrport)
|
|
|
|
remoteport = nrport->remoteport;
|
|
|
|
spin_unlock_irq(&vport->phba->hbalock);
|
2019-05-14 21:58:07 +00:00
|
|
|
|
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_DISC,
|
|
|
|
"6170 Rescan NPort DID x%06x type x%x "
|
2019-08-14 23:56:50 +00:00
|
|
|
"state x%x nrport x%px remoteport x%px\n",
|
|
|
|
ndlp->nlp_DID, ndlp->nlp_type, ndlp->nlp_state,
|
|
|
|
nrport, remoteport);
|
|
|
|
|
|
|
|
if (!nrport || !remoteport)
|
|
|
|
goto rescan_exit;
|
2019-05-14 21:58:07 +00:00
|
|
|
|
|
|
|
/* Only rescan if we are an NVME target in the MAPPED state */
|
|
|
|
if (remoteport->port_role & FC_PORT_ROLE_NVME_DISCOVERY &&
|
|
|
|
ndlp->nlp_state == NLP_STE_MAPPED_NODE) {
|
|
|
|
nvme_fc_rescan_remoteport(remoteport);
|
|
|
|
|
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_NVME_DISC,
|
|
|
|
"6172 NVME rescanned DID x%06x "
|
|
|
|
"port_state x%x\n",
|
|
|
|
ndlp->nlp_DID, remoteport->port_state);
|
|
|
|
}
|
|
|
|
return;
|
2019-08-14 23:56:50 +00:00
|
|
|
rescan_exit:
|
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_DISC,
|
|
|
|
"6169 Skip NVME Rport Rescan, NVME remoteport "
|
|
|
|
"unregistered\n");
|
2019-05-14 21:58:07 +00:00
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2017-02-12 21:52:32 +00:00
|
|
|
/* lpfc_nvme_unregister_port - unbind the DID and port_role from this rport.
|
|
|
|
*
|
|
|
|
* There is no notion of Devloss or rport recovery from the current
|
|
|
|
* nvme_transport perspective. Loss of an rport just means IO cannot
|
|
|
|
* be sent and recovery is completely up to the initator.
|
|
|
|
* For now, the driver just unbinds the DID and port_role so that
|
|
|
|
* no further IO can be issued. Changes are planned for later.
|
|
|
|
*
|
|
|
|
* Notes - the ndlp reference count is not decremented here since
|
|
|
|
* since there is no nvme_transport api for devloss. Node ref count
|
|
|
|
* is only adjusted in driver unload.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
lpfc_nvme_unregister_port(struct lpfc_vport *vport, struct lpfc_nodelist *ndlp)
|
|
|
|
{
|
2017-03-08 22:36:01 +00:00
|
|
|
#if (IS_ENABLED(CONFIG_NVME_FC))
|
2017-02-12 21:52:32 +00:00
|
|
|
int ret;
|
|
|
|
struct nvme_fc_local_port *localport;
|
|
|
|
struct lpfc_nvme_lport *lport;
|
|
|
|
struct lpfc_nvme_rport *rport;
|
2018-09-13 22:41:10 +00:00
|
|
|
struct nvme_fc_remote_port *remoteport = NULL;
|
2017-02-12 21:52:32 +00:00
|
|
|
|
|
|
|
localport = vport->localport;
|
|
|
|
|
|
|
|
/* This is fundamental error. The localport is always
|
|
|
|
* available until driver unload. Just exit.
|
|
|
|
*/
|
|
|
|
if (!localport)
|
|
|
|
return;
|
|
|
|
|
|
|
|
lport = (struct lpfc_nvme_lport *)localport->private;
|
|
|
|
if (!lport)
|
|
|
|
goto input_err;
|
|
|
|
|
2018-09-13 22:41:10 +00:00
|
|
|
spin_lock_irq(&vport->phba->hbalock);
|
2018-04-09 21:24:27 +00:00
|
|
|
rport = lpfc_ndlp_get_nrport(ndlp);
|
2018-09-13 22:41:10 +00:00
|
|
|
if (rport)
|
|
|
|
remoteport = rport->remoteport;
|
|
|
|
spin_unlock_irq(&vport->phba->hbalock);
|
|
|
|
if (!remoteport)
|
2017-02-12 21:52:32 +00:00
|
|
|
goto input_err;
|
|
|
|
|
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_DISC,
|
2019-08-14 23:57:06 +00:00
|
|
|
"6033 Unreg nvme remoteport x%px, portname x%llx, "
|
2017-02-12 21:52:32 +00:00
|
|
|
"port_id x%06x, portstate x%x port type x%x\n",
|
|
|
|
remoteport, remoteport->port_name,
|
|
|
|
remoteport->port_id, remoteport->port_state,
|
|
|
|
ndlp->nlp_type);
|
|
|
|
|
|
|
|
/* Sanity check ndlp type. Only call for NVME ports. Don't
|
|
|
|
* clear any rport state until the transport calls back.
|
|
|
|
*/
|
2017-11-21 00:00:39 +00:00
|
|
|
|
|
|
|
if (ndlp->nlp_type & NLP_NVME_TARGET) {
|
2017-06-02 04:06:55 +00:00
|
|
|
/* No concern about the role change on the nvme remoteport.
|
|
|
|
* The transport will update it.
|
|
|
|
*/
|
2017-11-21 00:00:40 +00:00
|
|
|
ndlp->upcall_flags |= NLP_WAIT_FOR_UNREG;
|
2018-05-25 04:08:59 +00:00
|
|
|
|
|
|
|
/* Don't let the host nvme transport keep sending keep-alives
|
|
|
|
* on this remoteport. Vport is unloading, no recovery. The
|
|
|
|
* return values is ignored. The upcall is a courtesy to the
|
|
|
|
* transport.
|
|
|
|
*/
|
|
|
|
if (vport->load_flag & FC_UNLOADING)
|
|
|
|
(void)nvme_fc_set_remoteport_devloss(remoteport, 0);
|
|
|
|
|
2017-02-12 21:52:32 +00:00
|
|
|
ret = nvme_fc_unregister_remoteport(remoteport);
|
2017-12-09 01:18:09 +00:00
|
|
|
if (ret != 0) {
|
|
|
|
lpfc_nlp_put(ndlp);
|
2017-02-12 21:52:32 +00:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_NVME_DISC,
|
|
|
|
"6167 NVME unregister failed %d "
|
|
|
|
"port_state x%x\n",
|
|
|
|
ret, remoteport->port_state);
|
2017-12-09 01:18:09 +00:00
|
|
|
}
|
2017-02-12 21:52:32 +00:00
|
|
|
}
|
|
|
|
return;
|
|
|
|
|
|
|
|
input_err:
|
2017-03-04 17:30:33 +00:00
|
|
|
#endif
|
2017-02-12 21:52:32 +00:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_NVME_DISC,
|
2019-08-14 23:57:06 +00:00
|
|
|
"6168 State error: lport x%px, rport x%px FCID x%06x\n",
|
2017-02-12 21:52:32 +00:00
|
|
|
vport->localport, ndlp->rport, ndlp->nlp_DID);
|
|
|
|
}
|
2017-03-04 17:30:30 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* lpfc_sli4_nvme_xri_aborted - Fast-path process of NVME xri abort
|
|
|
|
* @phba: pointer to lpfc hba data structure.
|
|
|
|
* @axri: pointer to the fcp xri abort wcqe structure.
|
2019-08-14 23:57:11 +00:00
|
|
|
* @lpfc_ncmd: The nvme job structure for the request being aborted.
|
2017-03-04 17:30:30 +00:00
|
|
|
*
|
|
|
|
* This routine is invoked by the worker thread to process a SLI4 fast-path
|
2017-09-30 00:34:43 +00:00
|
|
|
* NVME aborted xri. Aborted NVME IO commands are completed to the transport
|
|
|
|
* here.
|
2017-03-04 17:30:30 +00:00
|
|
|
**/
|
|
|
|
void
|
|
|
|
lpfc_sli4_nvme_xri_aborted(struct lpfc_hba *phba,
|
2019-08-14 23:57:11 +00:00
|
|
|
struct sli4_wcqe_xri_aborted *axri,
|
|
|
|
struct lpfc_io_buf *lpfc_ncmd)
|
2017-03-04 17:30:30 +00:00
|
|
|
{
|
|
|
|
uint16_t xri = bf_get(lpfc_wcqe_xa_xri, axri);
|
2017-09-30 00:34:43 +00:00
|
|
|
struct nvmefc_fcp_req *nvme_cmd = NULL;
|
2019-08-14 23:57:11 +00:00
|
|
|
struct lpfc_nodelist *ndlp = lpfc_ncmd->ndlp;
|
2017-03-04 17:30:30 +00:00
|
|
|
|
Update ABORT processing for NVMET.
The driver with nvme had this routine stubbed.
Right now XRI_ABORTED_CQE is not handled and the FC NVMET
Transport has a new API for the driver.
Missing code path, new NVME abort API
Update ABORT processing for NVMET
There are 3 new FC NVMET Transport API/ template routines for NVMET:
lpfc_nvmet_xmt_fcp_release
This NVMET template callback routine called to release context
associated with an IO This routine is ALWAYS called last, even
if the IO was aborted or completed in error.
lpfc_nvmet_xmt_fcp_abort
This NVMET template callback routine called to abort an exchange that
has an IO in progress
nvmet_fc_rcv_fcp_req
When the lpfc driver receives an ABTS, this NVME FC transport layer
callback routine is called. For this case there are 2 paths thru the
driver: the driver either has an outstanding exchange / context for the
XRI to be aborted or not. If not, a BA_RJT is issued otherwise a BA_ACC
NVMET Driver abort paths:
There are 2 paths for aborting an IO. The first one is we receive an IO and
decide not to process it because of lack of resources. An unsolicated ABTS
is immediately sent back to the initiator as a response.
lpfc_nvmet_unsol_fcp_buffer
lpfc_nvmet_unsol_issue_abort (XMIT_SEQUENCE_WQE)
The second one is we sent the IO up to the NVMET transport layer to
process, and for some reason the NVME Transport layer decided to abort the
IO before it completes all its phases. For this case there are 2 paths
thru the driver:
the driver either has an outstanding TSEND/TRECEIVE/TRSP WQE or no
outstanding WQEs are present for the exchange / context.
lpfc_nvmet_xmt_fcp_abort
if (LPFC_NVMET_IO_INP)
lpfc_nvmet_sol_fcp_issue_abort (ABORT_WQE)
lpfc_nvmet_sol_fcp_abort_cmp
else
lpfc_nvmet_unsol_fcp_issue_abort
lpfc_nvmet_unsol_issue_abort (XMIT_SEQUENCE_WQE)
lpfc_nvmet_unsol_fcp_abort_cmp
Context flags:
LPFC_NVMET_IOP - his flag signifies an IO is in progress on the exchange.
LPFC_NVMET_XBUSY - this flag indicates the IO completed but the firmware
is still busy with the corresponding exchange. The exchange should not be
reused until after a XRI_ABORTED_CQE is received for that exchange.
LPFC_NVMET_ABORT_OP - this flag signifies an ABORT_WQE was issued on the
exchange.
LPFC_NVMET_CTX_RLS - this flag signifies a context free was requested,
but we are deferring it due to an XBUSY or ABORT in progress.
A ctxlock is added to the context structure that is used whenever these
flags are set/read within the context of an IO.
The LPFC_NVMET_CTX_RLS flag is only set in the defer_relase routine when
the transport has resolved all IO associated with the buffer. The flag is
cleared when the CTX is associated with a new IO.
An exchange can has both an LPFC_NVMET_XBUSY and a LPFC_NVMET_ABORT_OP
condition active simultaneously. Both conditions must complete before the
exchange is freed.
When the abort callback (lpfc_nvmet_xmt_fcp_abort) is envoked:
If there is an outstanding IO, the driver will issue an ABORT_WQE. This
should result in 3 completions for the exchange:
1) IO cmpl with XB bit set
2) Abort WQE cmpl
3) XRI_ABORTED_CQE cmpl
For this scenerio, after completion #1, the NVMET Transport IO rsp
callback is called. After completion #2, no action is taken with respect
to the exchange / context. After completion #3, the exchange context is
free for re-use on another IO.
If there is no outstanding activity on the exchange, the driver will send a
ABTS to the Initiator. Upon completion of this WQE, the exchange / context
is freed for re-use on another IO.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
2017-04-21 23:05:04 +00:00
|
|
|
|
2019-08-14 23:57:11 +00:00
|
|
|
if (ndlp)
|
|
|
|
lpfc_sli4_abts_err_handler(phba, ndlp, axri);
|
Update ABORT processing for NVMET.
The driver with nvme had this routine stubbed.
Right now XRI_ABORTED_CQE is not handled and the FC NVMET
Transport has a new API for the driver.
Missing code path, new NVME abort API
Update ABORT processing for NVMET
There are 3 new FC NVMET Transport API/ template routines for NVMET:
lpfc_nvmet_xmt_fcp_release
This NVMET template callback routine called to release context
associated with an IO This routine is ALWAYS called last, even
if the IO was aborted or completed in error.
lpfc_nvmet_xmt_fcp_abort
This NVMET template callback routine called to abort an exchange that
has an IO in progress
nvmet_fc_rcv_fcp_req
When the lpfc driver receives an ABTS, this NVME FC transport layer
callback routine is called. For this case there are 2 paths thru the
driver: the driver either has an outstanding exchange / context for the
XRI to be aborted or not. If not, a BA_RJT is issued otherwise a BA_ACC
NVMET Driver abort paths:
There are 2 paths for aborting an IO. The first one is we receive an IO and
decide not to process it because of lack of resources. An unsolicated ABTS
is immediately sent back to the initiator as a response.
lpfc_nvmet_unsol_fcp_buffer
lpfc_nvmet_unsol_issue_abort (XMIT_SEQUENCE_WQE)
The second one is we sent the IO up to the NVMET transport layer to
process, and for some reason the NVME Transport layer decided to abort the
IO before it completes all its phases. For this case there are 2 paths
thru the driver:
the driver either has an outstanding TSEND/TRECEIVE/TRSP WQE or no
outstanding WQEs are present for the exchange / context.
lpfc_nvmet_xmt_fcp_abort
if (LPFC_NVMET_IO_INP)
lpfc_nvmet_sol_fcp_issue_abort (ABORT_WQE)
lpfc_nvmet_sol_fcp_abort_cmp
else
lpfc_nvmet_unsol_fcp_issue_abort
lpfc_nvmet_unsol_issue_abort (XMIT_SEQUENCE_WQE)
lpfc_nvmet_unsol_fcp_abort_cmp
Context flags:
LPFC_NVMET_IOP - his flag signifies an IO is in progress on the exchange.
LPFC_NVMET_XBUSY - this flag indicates the IO completed but the firmware
is still busy with the corresponding exchange. The exchange should not be
reused until after a XRI_ABORTED_CQE is received for that exchange.
LPFC_NVMET_ABORT_OP - this flag signifies an ABORT_WQE was issued on the
exchange.
LPFC_NVMET_CTX_RLS - this flag signifies a context free was requested,
but we are deferring it due to an XBUSY or ABORT in progress.
A ctxlock is added to the context structure that is used whenever these
flags are set/read within the context of an IO.
The LPFC_NVMET_CTX_RLS flag is only set in the defer_relase routine when
the transport has resolved all IO associated with the buffer. The flag is
cleared when the CTX is associated with a new IO.
An exchange can has both an LPFC_NVMET_XBUSY and a LPFC_NVMET_ABORT_OP
condition active simultaneously. Both conditions must complete before the
exchange is freed.
When the abort callback (lpfc_nvmet_xmt_fcp_abort) is envoked:
If there is an outstanding IO, the driver will issue an ABORT_WQE. This
should result in 3 completions for the exchange:
1) IO cmpl with XB bit set
2) Abort WQE cmpl
3) XRI_ABORTED_CQE cmpl
For this scenerio, after completion #1, the NVMET Transport IO rsp
callback is called. After completion #2, no action is taken with respect
to the exchange / context. After completion #3, the exchange context is
free for re-use on another IO.
If there is no outstanding activity on the exchange, the driver will send a
ABTS to the Initiator. Upon completion of this WQE, the exchange / context
is freed for re-use on another IO.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
2017-04-21 23:05:04 +00:00
|
|
|
|
2019-08-14 23:57:11 +00:00
|
|
|
lpfc_printf_log(phba, KERN_INFO, LOG_NVME_ABTS,
|
|
|
|
"6311 nvme_cmd %p xri x%x tag x%x abort complete and "
|
|
|
|
"xri released\n",
|
|
|
|
lpfc_ncmd->nvmeCmd, xri,
|
|
|
|
lpfc_ncmd->cur_iocbq.iotag);
|
|
|
|
|
|
|
|
/* Aborted NVME commands are required to not complete
|
|
|
|
* before the abort exchange command fully completes.
|
|
|
|
* Once completed, it is available via the put list.
|
|
|
|
*/
|
|
|
|
if (lpfc_ncmd->nvmeCmd) {
|
|
|
|
nvme_cmd = lpfc_ncmd->nvmeCmd;
|
|
|
|
nvme_cmd->done(nvme_cmd);
|
|
|
|
lpfc_ncmd->nvmeCmd = NULL;
|
|
|
|
}
|
|
|
|
lpfc_release_nvme_buf(phba, lpfc_ncmd);
|
2017-03-04 17:30:30 +00:00
|
|
|
}
|
2017-11-21 00:00:42 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* lpfc_nvme_wait_for_io_drain - Wait for all NVME wqes to complete
|
|
|
|
* @phba: Pointer to HBA context object.
|
|
|
|
*
|
|
|
|
* This function flushes all wqes in the nvme rings and frees all resources
|
|
|
|
* in the txcmplq. This function does not issue abort wqes for the IO
|
|
|
|
* commands in txcmplq, they will just be returned with
|
|
|
|
* IOERR_SLI_DOWN. This function is invoked with EEH when device's PCI
|
|
|
|
* slot has been permanently disabled.
|
|
|
|
**/
|
|
|
|
void
|
|
|
|
lpfc_nvme_wait_for_io_drain(struct lpfc_hba *phba)
|
|
|
|
{
|
|
|
|
struct lpfc_sli_ring *pring;
|
|
|
|
u32 i, wait_cnt = 0;
|
|
|
|
|
scsi: lpfc: Replace io_channels for nvme and fcp with general hdw_queues per cpu
Currently, both nvme and fcp each have their own concept of an io_channel,
which is a combination wq/cq and associated msix. Different cpus would
share an io_channel.
The driver is now moving to per-cpu wq/cq pairs and msix vectors. The
driver will still use separate wq/cq pairs per protocol on each cpu, but
the protocols will share the msix vector.
Given the elimination of the nvme and fcp io channels, the module
parameters will be removed. A new parameter, lpfc_hdw_queue is added which
allows the wq/cq pair allocation per cpu to be overridden and allocated to
lesser value. If lpfc_hdw_queue is zero, the number of pairs allocated will
be based on the number of cpus. If non-zero, the parameter specifies the
number of queues to allocate. At this time, the maximum non-zero value is
64.
To manage this new paradigm, a new hardware queue structure is created to
track queue activity and relationships.
As MSIX vector allocation must be known before setting up the
relationships, msix allocation now occurs before queue datastructures are
allocated. If the number of vectors allocated is less than the desired
hardware queues, the hardware queue counts will be reduced to the number of
vectors
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-01-28 19:14:21 +00:00
|
|
|
if (phba->sli_rev < LPFC_SLI_REV4 || !phba->sli4_hba.hdwq)
|
2017-11-21 00:00:42 +00:00
|
|
|
return;
|
|
|
|
|
2019-08-14 23:57:11 +00:00
|
|
|
/* Cycle through all IO rings and make sure all outstanding
|
2017-11-21 00:00:42 +00:00
|
|
|
* WQEs have been removed from the txcmplqs.
|
|
|
|
*/
|
scsi: lpfc: Replace io_channels for nvme and fcp with general hdw_queues per cpu
Currently, both nvme and fcp each have their own concept of an io_channel,
which is a combination wq/cq and associated msix. Different cpus would
share an io_channel.
The driver is now moving to per-cpu wq/cq pairs and msix vectors. The
driver will still use separate wq/cq pairs per protocol on each cpu, but
the protocols will share the msix vector.
Given the elimination of the nvme and fcp io channels, the module
parameters will be removed. A new parameter, lpfc_hdw_queue is added which
allows the wq/cq pair allocation per cpu to be overridden and allocated to
lesser value. If lpfc_hdw_queue is zero, the number of pairs allocated will
be based on the number of cpus. If non-zero, the parameter specifies the
number of queues to allocate. At this time, the maximum non-zero value is
64.
To manage this new paradigm, a new hardware queue structure is created to
track queue activity and relationships.
As MSIX vector allocation must be known before setting up the
relationships, msix allocation now occurs before queue datastructures are
allocated. If the number of vectors allocated is less than the desired
hardware queues, the hardware queue counts will be reduced to the number of
vectors
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-01-28 19:14:21 +00:00
|
|
|
for (i = 0; i < phba->cfg_hdw_queue; i++) {
|
2019-08-14 23:57:11 +00:00
|
|
|
if (!phba->sli4_hba.hdwq[i].io_wq)
|
2019-01-28 19:14:31 +00:00
|
|
|
continue;
|
2019-08-14 23:57:11 +00:00
|
|
|
pring = phba->sli4_hba.hdwq[i].io_wq->pring;
|
2017-11-21 00:00:42 +00:00
|
|
|
|
2018-06-26 15:24:24 +00:00
|
|
|
if (!pring)
|
|
|
|
continue;
|
|
|
|
|
2017-11-21 00:00:42 +00:00
|
|
|
/* Retrieve everything on the txcmplq */
|
|
|
|
while (!list_empty(&pring->txcmplq)) {
|
|
|
|
msleep(LPFC_XRI_EXCH_BUSY_WAIT_T1);
|
|
|
|
wait_cnt++;
|
|
|
|
|
|
|
|
/* The sleep is 10mS. Every ten seconds,
|
|
|
|
* dump a message. Something is wrong.
|
|
|
|
*/
|
|
|
|
if ((wait_cnt % 1000) == 0) {
|
|
|
|
lpfc_printf_log(phba, KERN_ERR, LOG_NVME_IOERR,
|
|
|
|
"6178 NVME IO not empty, "
|
|
|
|
"cnt %d\n", wait_cnt);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
scsi: lpfc: Fix hang when downloading fw on port enabled for nvme
As part of firmware download, the adapter is reset. On the adapter the
reset causes the function to stop and all outstanding io is terminated
(without responses). The reset path then starts teardown of the adapter,
starting with deregistration of the remote ports with the nvme-fc
transport. The local port is then deregistered and the driver waits for
local port deregistration. This never finishes.
The remote port deregistrations terminated the nvme controllers, causing
them to send aborts for all the outstanding io. The aborts were serviced in
the driver, but stalled due to its state. The nvme layer then stops to
reclaim it's outstanding io before continuing. The io must be returned
before the reset on the controller is deemed complete and the controller
delete performed. The remote port deregistration won't complete until all
the controllers are terminated. And the local port deregistration won't
complete until all controllers and remote ports are terminated. Thus things
hang.
The issue is the reset which stopped the adapter also stopped all the
responses that would drive i/o completions, and the aborts were also
stopped that stopped i/o completions. The driver, when resetting the
adapter like this, needs to be generating the completions as part of the
adapter reset so that I/O complete (in error), and any aborts are not
queued.
Fix by adding flush routines whenever the adapter port has been reset or
discovered in error. The flush routines will generate the completions for
the scsi and nvme outstanding io. The abort ios, if waiting, will be caught
and flushed as well.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-08-14 23:56:55 +00:00
|
|
|
|
|
|
|
void
|
|
|
|
lpfc_nvme_cancel_iocb(struct lpfc_hba *phba, struct lpfc_iocbq *pwqeIn)
|
|
|
|
{
|
|
|
|
#if (IS_ENABLED(CONFIG_NVME_FC))
|
|
|
|
struct lpfc_io_buf *lpfc_ncmd;
|
|
|
|
struct nvmefc_fcp_req *nCmd;
|
|
|
|
struct lpfc_nvme_fcpreq_priv *freqpriv;
|
|
|
|
|
|
|
|
if (!pwqeIn->context1) {
|
|
|
|
lpfc_sli_release_iocbq(phba, pwqeIn);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
/* For abort iocb just return, IO iocb will do a done call */
|
|
|
|
if (bf_get(wqe_cmnd, &pwqeIn->wqe.gen_req.wqe_com) ==
|
|
|
|
CMD_ABORT_XRI_CX) {
|
|
|
|
lpfc_sli_release_iocbq(phba, pwqeIn);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
lpfc_ncmd = (struct lpfc_io_buf *)pwqeIn->context1;
|
|
|
|
|
|
|
|
spin_lock(&lpfc_ncmd->buf_lock);
|
|
|
|
if (!lpfc_ncmd->nvmeCmd) {
|
|
|
|
spin_unlock(&lpfc_ncmd->buf_lock);
|
|
|
|
lpfc_release_nvme_buf(phba, lpfc_ncmd);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
nCmd = lpfc_ncmd->nvmeCmd;
|
|
|
|
lpfc_printf_log(phba, KERN_INFO, LOG_NVME_IOERR,
|
|
|
|
"6194 NVME Cancel xri %x\n",
|
|
|
|
lpfc_ncmd->cur_iocbq.sli4_xritag);
|
|
|
|
|
|
|
|
nCmd->transferred_length = 0;
|
|
|
|
nCmd->rcv_rsplen = 0;
|
|
|
|
nCmd->status = NVME_SC_INTERNAL;
|
|
|
|
freqpriv = nCmd->private;
|
|
|
|
freqpriv->nvme_buf = NULL;
|
|
|
|
lpfc_ncmd->nvmeCmd = NULL;
|
|
|
|
|
|
|
|
spin_unlock(&lpfc_ncmd->buf_lock);
|
|
|
|
nCmd->done(nCmd);
|
|
|
|
|
|
|
|
/* Call release with XB=1 to queue the IO into the abort list. */
|
|
|
|
lpfc_release_nvme_buf(phba, lpfc_ncmd);
|
|
|
|
#endif
|
|
|
|
}
|