2017-02-13 05:52:32 +08:00
|
|
|
/*******************************************************************
|
|
|
|
* This file is part of the Emulex Linux Device Driver for *
|
|
|
|
* Fibre Channel Host Bus Adapters. *
|
2023-03-02 07:16:26 +08:00
|
|
|
* Copyright (C) 2017-2023 Broadcom. All Rights Reserved. The term *
|
2018-05-05 11:37:59 +08:00
|
|
|
* “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. *
|
2017-02-13 05:52:32 +08:00
|
|
|
* Copyright (C) 2004-2016 Emulex. All rights reserved. *
|
|
|
|
* EMULEX and SLI are trademarks of Emulex. *
|
2017-02-13 05:52:39 +08:00
|
|
|
* www.broadcom.com *
|
2017-02-13 05:52:32 +08: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 "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-13 05:52:33 +08:00
|
|
|
#include "lpfc_debugfs.h"
|
2017-02-13 05:52:32 +08: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-29 03:14:28 +08:00
|
|
|
static struct lpfc_io_buf *
|
2017-12-09 09:18:03 +08:00
|
|
|
lpfc_get_nvme_buf(struct lpfc_hba *phba, struct lpfc_nodelist *ndlp,
|
2019-01-29 03:14:22 +08:00
|
|
|
int idx, int expedite);
|
2017-02-13 05:52:32 +08: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-29 03:14:28 +08:00
|
|
|
lpfc_release_nvme_buf(struct lpfc_hba *, struct lpfc_io_buf *);
|
2017-02-13 05:52:32 +08:00
|
|
|
|
2017-11-21 08:00:43 +08:00
|
|
|
static struct nvme_fc_port_template lpfc_nvme_template;
|
2017-02-13 05:52:32 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* lpfc_nvme_create_queue -
|
2020-07-13 15:59:57 +08:00
|
|
|
* @pnvme_lport: Transport localport that LS is to be issued from
|
2017-02-13 05:52:32 +08:00
|
|
|
* @qidx: An cpu index used to affinitize IO queues and MSIX vectors.
|
2020-07-13 15:59:57 +08:00
|
|
|
* @qsize: Size of the queue in bytes
|
2017-02-13 05:52:32 +08:00
|
|
|
* @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 08:00:42 +08:00
|
|
|
if (!pnvme_lport->private)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2017-02-13 05:52:32 +08:00
|
|
|
lport = (struct lpfc_nvme_lport *)pnvme_lport->private;
|
|
|
|
vport = lport->vport;
|
2022-03-17 11:27:35 +08:00
|
|
|
|
|
|
|
if (!vport || vport->load_flag & FC_UNLOADING ||
|
|
|
|
vport->phba->hba_flag & HBA_IOQ_FLUSH)
|
|
|
|
return -ENODEV;
|
|
|
|
|
2017-02-13 05:52:32 +08:00
|
|
|
qhandle = kzalloc(sizeof(struct lpfc_nvme_qhandle), GFP_KERNEL);
|
|
|
|
if (qhandle == NULL)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2019-03-29 02:06:22 +08:00
|
|
|
qhandle->cpu_id = raw_smp_processor_id();
|
2017-02-13 05:52:32 +08: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-29 03:14:31 +08:00
|
|
|
lpfc_nvme_template.max_hw_queues);
|
2017-02-13 05:52:32 +08:00
|
|
|
} else {
|
|
|
|
str = "ADM"; /* Admin queue */
|
|
|
|
qhandle->index = qidx;
|
|
|
|
}
|
|
|
|
|
2017-08-24 07:55:46 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME,
|
2017-02-13 05:52:32 +08:00
|
|
|
"6073 Binding %s HdwQueue %d (cpu %d) to "
|
2019-08-15 07:57:06 +08:00
|
|
|
"hdw_queue %d qhandle x%px\n", str,
|
2017-02-13 05:52:32 +08:00
|
|
|
qidx, qhandle->cpu_id, qhandle->index, qhandle);
|
|
|
|
*handle = (void *)qhandle;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* lpfc_nvme_delete_queue -
|
2020-07-13 15:59:57 +08:00
|
|
|
* @pnvme_lport: Transport localport that LS is to be issued from
|
2017-02-13 05:52:32 +08:00
|
|
|
* @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 08:00:42 +08:00
|
|
|
if (!pnvme_lport->private)
|
|
|
|
return;
|
|
|
|
|
2017-02-13 05:52:32 +08:00
|
|
|
lport = (struct lpfc_nvme_lport *)pnvme_lport->private;
|
|
|
|
vport = lport->vport;
|
|
|
|
|
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME,
|
2019-08-15 07:57:06 +08:00
|
|
|
"6001 ENTER. lpfc_pnvme x%px, qidx x%x qhandle x%px\n",
|
2017-02-13 05:52:32 +08: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 08:00:40 +08:00
|
|
|
lpfc_printf_vlog(lport->vport, KERN_INFO, LOG_NVME,
|
2019-08-15 07:57:06 +08:00
|
|
|
"6173 localport x%px delete complete\n",
|
2017-11-21 08:00:40 +08:00
|
|
|
lport);
|
|
|
|
|
2017-02-13 05:52:32 +08:00
|
|
|
/* release any threads waiting for the unreg to complete */
|
2019-01-18 00:14:44 +08:00
|
|
|
if (lport->vport->localport)
|
|
|
|
complete(lport->lport_unreg_cmp);
|
2017-02-13 05:52:32 +08: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-29 02:06:16 +08:00
|
|
|
static void
|
2017-02-13 05:52:32 +08: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;
|
2020-11-16 03:26:33 +08:00
|
|
|
u32 fc4_xpt_flags;
|
2017-02-13 05:52:32 +08:00
|
|
|
|
|
|
|
ndlp = rport->ndlp;
|
2020-11-16 03:26:33 +08:00
|
|
|
if (!ndlp) {
|
2021-04-12 09:31:24 +08:00
|
|
|
pr_err("**** %s: NULL ndlp on rport x%px remoteport x%px\n",
|
2020-11-16 03:26:33 +08:00
|
|
|
__func__, rport, remoteport);
|
2017-02-13 05:52:32 +08:00
|
|
|
goto rport_err;
|
2020-11-16 03:26:33 +08:00
|
|
|
}
|
2017-02-13 05:52:32 +08:00
|
|
|
|
|
|
|
vport = ndlp->vport;
|
2020-11-16 03:26:33 +08:00
|
|
|
if (!vport) {
|
2021-04-12 09:31:24 +08:00
|
|
|
pr_err("**** %s: Null vport on ndlp x%px, ste x%x rport x%px\n",
|
2020-11-16 03:26:33 +08:00
|
|
|
__func__, ndlp, ndlp->nlp_state, rport);
|
2017-02-13 05:52:32 +08:00
|
|
|
goto rport_err;
|
2020-11-16 03:26:33 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
fc4_xpt_flags = NVME_XPT_REGD | SCSI_XPT_REGD;
|
2017-02-13 05:52:32 +08:00
|
|
|
|
|
|
|
/* 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 12:06:55 +08:00
|
|
|
* calling state machine to remove the node.
|
2017-02-13 05:52:32 +08:00
|
|
|
*/
|
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_DISC,
|
2021-09-11 07:31:47 +08:00
|
|
|
"6146 remoteport delete of remoteport x%px, ndlp x%px "
|
|
|
|
"DID x%x xflags x%x\n",
|
|
|
|
remoteport, ndlp, ndlp->nlp_DID, ndlp->fc4_xpt_flags);
|
2020-11-16 03:26:34 +08:00
|
|
|
spin_lock_irq(&ndlp->lock);
|
2018-04-10 05:24:30 +08:00
|
|
|
|
|
|
|
/* The register rebind might have occurred before the delete
|
|
|
|
* downcall. Guard against this race.
|
|
|
|
*/
|
2021-07-08 02:43:46 +08:00
|
|
|
if (ndlp->fc4_xpt_flags & NVME_XPT_UNREG_WAIT)
|
|
|
|
ndlp->fc4_xpt_flags &= ~(NVME_XPT_UNREG_WAIT | NVME_XPT_REGD);
|
2017-12-09 09:18:09 +08:00
|
|
|
|
2020-11-16 03:26:34 +08:00
|
|
|
spin_unlock_irq(&ndlp->lock);
|
2020-11-16 03:26:33 +08:00
|
|
|
|
|
|
|
/* On a devloss timeout event, one more put is executed provided the
|
|
|
|
* NVME and SCSI rport unregister requests are complete. If the vport
|
|
|
|
* is unloading, this extra put is executed by lpfc_drop_node.
|
|
|
|
*/
|
|
|
|
if (!(ndlp->fc4_xpt_flags & fc4_xpt_flags))
|
|
|
|
lpfc_disc_state_machine(vport, ndlp, NULL, NLP_EVT_DEVICE_RM);
|
2017-02-13 05:52:32 +08:00
|
|
|
|
|
|
|
rport_err:
|
2017-12-09 09:18:09 +08:00
|
|
|
return;
|
2017-02-13 05:52:32 +08:00
|
|
|
}
|
|
|
|
|
2020-04-01 00:50:05 +08:00
|
|
|
/**
|
|
|
|
* lpfc_nvme_handle_lsreq - Process an unsolicited NVME LS request
|
|
|
|
* @phba: pointer to lpfc hba data structure.
|
|
|
|
* @axchg: pointer to exchange context for the NVME LS request
|
|
|
|
*
|
|
|
|
* This routine is used for processing an asychronously received NVME LS
|
|
|
|
* request. Any remaining validation is done and the LS is then forwarded
|
|
|
|
* to the nvme-fc transport via nvme_fc_rcv_ls_req().
|
|
|
|
*
|
2020-04-01 00:50:09 +08:00
|
|
|
* The calling sequence should be: nvme_fc_rcv_ls_req() -> (processing)
|
|
|
|
* -> lpfc_nvme_xmt_ls_rsp/cmp -> req->done.
|
|
|
|
* __lpfc_nvme_xmt_ls_rsp_cmp should free the allocated axchg.
|
|
|
|
*
|
2020-04-01 00:50:05 +08:00
|
|
|
* Returns 0 if LS was handled and delivered to the transport
|
|
|
|
* Returns 1 if LS failed to be handled and should be dropped
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
lpfc_nvme_handle_lsreq(struct lpfc_hba *phba,
|
|
|
|
struct lpfc_async_xchg_ctx *axchg)
|
|
|
|
{
|
2020-04-01 00:50:09 +08:00
|
|
|
#if (IS_ENABLED(CONFIG_NVME_FC))
|
|
|
|
struct lpfc_vport *vport;
|
|
|
|
struct lpfc_nvme_rport *lpfc_rport;
|
|
|
|
struct nvme_fc_remote_port *remoteport;
|
|
|
|
struct lpfc_nvme_lport *lport;
|
|
|
|
uint32_t *payload = axchg->payload;
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
vport = axchg->ndlp->vport;
|
|
|
|
lpfc_rport = axchg->ndlp->nrport;
|
|
|
|
if (!lpfc_rport)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
remoteport = lpfc_rport->remoteport;
|
2022-03-17 11:27:35 +08:00
|
|
|
if (!vport->localport ||
|
|
|
|
vport->phba->hba_flag & HBA_IOQ_FLUSH)
|
2020-04-01 00:50:09 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
lport = vport->localport->private;
|
|
|
|
if (!lport)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
rc = nvme_fc_rcv_ls_req(remoteport, &axchg->ls_rsp, axchg->payload,
|
|
|
|
axchg->size);
|
|
|
|
|
|
|
|
lpfc_printf_log(phba, KERN_INFO, LOG_NVME_DISC,
|
|
|
|
"6205 NVME Unsol rcv: sz %d rc %d: %08x %08x %08x "
|
|
|
|
"%08x %08x %08x\n",
|
|
|
|
axchg->size, rc,
|
|
|
|
*payload, *(payload+1), *(payload+2),
|
|
|
|
*(payload+3), *(payload+4), *(payload+5));
|
|
|
|
|
|
|
|
if (!rc)
|
|
|
|
return 0;
|
|
|
|
#endif
|
2020-04-01 00:50:05 +08:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2020-04-01 00:50:06 +08:00
|
|
|
/**
|
|
|
|
* __lpfc_nvme_ls_req_cmp - Generic completion handler for a NVME
|
|
|
|
* LS request.
|
|
|
|
* @phba: Pointer to HBA context object
|
|
|
|
* @vport: The local port that issued the LS
|
|
|
|
* @cmdwqe: Pointer to driver command WQE object.
|
|
|
|
* @wcqe: Pointer to driver response CQE object.
|
|
|
|
*
|
|
|
|
* This function is the generic completion handler for NVME LS requests.
|
|
|
|
* The function updates any states and statistics, calls the transport
|
|
|
|
* ls_req done() routine, then tears down the command and buffers used
|
|
|
|
* for the LS request.
|
|
|
|
**/
|
|
|
|
void
|
2023-05-24 02:32:03 +08:00
|
|
|
__lpfc_nvme_ls_req_cmp(struct lpfc_hba *phba, struct lpfc_vport *vport,
|
2020-04-01 00:50:06 +08:00
|
|
|
struct lpfc_iocbq *cmdwqe,
|
|
|
|
struct lpfc_wcqe_complete *wcqe)
|
2017-02-13 05:52:32 +08:00
|
|
|
{
|
|
|
|
struct nvmefc_ls_req *pnvme_lsreq;
|
|
|
|
struct lpfc_dmabuf *buf_ptr;
|
|
|
|
struct lpfc_nodelist *ndlp;
|
2023-05-24 02:32:03 +08:00
|
|
|
int status;
|
2017-02-13 05:52:32 +08:00
|
|
|
|
2022-04-13 06:20:02 +08:00
|
|
|
pnvme_lsreq = cmdwqe->context_un.nvme_lsreq;
|
|
|
|
ndlp = cmdwqe->ndlp;
|
|
|
|
buf_ptr = cmdwqe->bpl_dmabuf;
|
|
|
|
|
2023-05-24 02:32:03 +08:00
|
|
|
status = bf_get(lpfc_wcqe_c_status, wcqe);
|
2018-04-10 05:24:23 +08:00
|
|
|
|
2017-02-13 05:52:32 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_DISC,
|
2021-04-12 09:31:24 +08:00
|
|
|
"6047 NVMEx LS REQ x%px cmpl DID %x Xri: %x "
|
2020-04-01 00:50:06 +08:00
|
|
|
"status %x reason x%x cmd:x%px lsreg:x%px bmp:x%px "
|
|
|
|
"ndlp:x%px\n",
|
2017-02-13 05:52:32 +08: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-31 07:59:01 +08:00
|
|
|
(wcqe->parameter & 0xffff),
|
2022-04-13 06:20:02 +08:00
|
|
|
cmdwqe, pnvme_lsreq, cmdwqe->bpl_dmabuf,
|
|
|
|
ndlp);
|
2017-02-13 05:52:32 +08:00
|
|
|
|
2020-04-01 00:50:06 +08:00
|
|
|
lpfc_nvmeio_data(phba, "NVMEx LS CMPL: xri x%x stat x%x parm x%x\n",
|
2017-02-13 05:52:33 +08:00
|
|
|
cmdwqe->sli4_xritag, status, wcqe->parameter);
|
|
|
|
|
2022-04-13 06:20:02 +08:00
|
|
|
if (buf_ptr) {
|
2017-02-13 05:52:32 +08:00
|
|
|
lpfc_mbuf_free(phba, buf_ptr->virt, buf_ptr->phys);
|
|
|
|
kfree(buf_ptr);
|
2022-04-13 06:20:02 +08:00
|
|
|
cmdwqe->bpl_dmabuf = NULL;
|
2017-02-13 05:52:32 +08:00
|
|
|
}
|
2023-05-24 02:32:03 +08:00
|
|
|
if (pnvme_lsreq->done) {
|
|
|
|
if (status != CQE_STATUS_SUCCESS)
|
|
|
|
status = -ENXIO;
|
2017-02-13 05:52:32 +08:00
|
|
|
pnvme_lsreq->done(pnvme_lsreq, status);
|
2023-05-24 02:32:03 +08:00
|
|
|
} else {
|
2020-07-01 05:50:00 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_TRACE_EVENT,
|
2020-04-01 00:50:06 +08:00
|
|
|
"6046 NVMEx cmpl without done call back? "
|
2021-04-12 09:31:24 +08:00
|
|
|
"Data x%px DID %x Xri: %x status %x\n",
|
2017-02-13 05:52:32 +08:00
|
|
|
pnvme_lsreq, ndlp ? ndlp->nlp_DID : 0,
|
|
|
|
cmdwqe->sli4_xritag, status);
|
2023-05-24 02:32:03 +08:00
|
|
|
}
|
2017-02-13 05:52:32 +08:00
|
|
|
if (ndlp) {
|
|
|
|
lpfc_nlp_put(ndlp);
|
2022-04-13 06:20:02 +08:00
|
|
|
cmdwqe->ndlp = NULL;
|
2017-02-13 05:52:32 +08:00
|
|
|
}
|
|
|
|
lpfc_sli_release_iocbq(phba, cmdwqe);
|
|
|
|
}
|
|
|
|
|
2020-04-01 00:50:06 +08:00
|
|
|
static void
|
|
|
|
lpfc_nvme_ls_req_cmp(struct lpfc_hba *phba, struct lpfc_iocbq *cmdwqe,
|
2022-02-25 10:22:52 +08:00
|
|
|
struct lpfc_iocbq *rspwqe)
|
2020-04-01 00:50:06 +08:00
|
|
|
{
|
|
|
|
struct lpfc_vport *vport = cmdwqe->vport;
|
|
|
|
struct lpfc_nvme_lport *lport;
|
|
|
|
uint32_t status;
|
2022-02-25 10:22:52 +08:00
|
|
|
struct lpfc_wcqe_complete *wcqe = &rspwqe->wcqe_cmpl;
|
2020-04-01 00:50:06 +08:00
|
|
|
|
2023-05-24 02:32:03 +08:00
|
|
|
status = bf_get(lpfc_wcqe_c_status, wcqe);
|
2020-04-01 00:50:06 +08: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);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
__lpfc_nvme_ls_req_cmp(phba, vport, cmdwqe, wcqe);
|
|
|
|
}
|
|
|
|
|
2017-02-13 05:52:32 +08:00
|
|
|
static int
|
|
|
|
lpfc_nvme_gen_req(struct lpfc_vport *vport, struct lpfc_dmabuf *bmp,
|
|
|
|
struct lpfc_dmabuf *inp,
|
2018-03-06 04:04:03 +08:00
|
|
|
struct nvmefc_ls_req *pnvme_lsreq,
|
|
|
|
void (*cmpl)(struct lpfc_hba *, struct lpfc_iocbq *,
|
2022-02-25 10:22:52 +08:00
|
|
|
struct lpfc_iocbq *),
|
2018-03-06 04:04:03 +08:00
|
|
|
struct lpfc_nodelist *ndlp, uint32_t num_entry,
|
|
|
|
uint32_t tmo, uint8_t retry)
|
2017-02-13 05:52:32 +08:00
|
|
|
{
|
2018-03-06 04:04:03 +08:00
|
|
|
struct lpfc_hba *phba = vport->phba;
|
|
|
|
union lpfc_wqe128 *wqe;
|
2017-02-13 05:52:32 +08: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-15 07:57:04 +08:00
|
|
|
/* Initialize only 64 bytes */
|
2017-02-13 05:52:32 +08:00
|
|
|
memset(wqe, 0, sizeof(union lpfc_wqe));
|
|
|
|
|
2022-04-13 06:20:02 +08:00
|
|
|
genwqe->bpl_dmabuf = bmp;
|
2022-02-25 10:22:52 +08:00
|
|
|
genwqe->cmd_flag |= LPFC_IO_NVME_LS;
|
2017-02-13 05:52:32 +08:00
|
|
|
|
|
|
|
/* Save for completion so we can release these resources */
|
2022-04-13 06:20:02 +08:00
|
|
|
genwqe->ndlp = lpfc_nlp_get(ndlp);
|
|
|
|
if (!genwqe->ndlp) {
|
2020-11-16 03:26:31 +08:00
|
|
|
dev_warn(&phba->pcidev->dev,
|
|
|
|
"Warning: Failed node ref, not sending LS_REQ\n");
|
|
|
|
lpfc_sli_release_iocbq(phba, genwqe);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2022-04-13 06:20:02 +08:00
|
|
|
genwqe->context_un.nvme_lsreq = pnvme_lsreq;
|
2017-02-13 05:52:32 +08:00
|
|
|
/* 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;
|
|
|
|
}
|
|
|
|
|
2022-02-25 10:22:52 +08:00
|
|
|
genwqe->num_bdes = num_entry;
|
2017-02-13 05:52:32 +08:00
|
|
|
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-05 01:30:26 +08:00
|
|
|
bf_set(wqe_rctl, &wqe->gen_req.wge_ctl, FC_RCTL_ELS4_REQ);
|
2017-02-13 05:52:32 +08: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 */
|
2021-01-05 02:02:30 +08:00
|
|
|
bf_set(wqe_tmo, &wqe->gen_req.wqe_com, tmo);
|
2017-02-13 05:52:32 +08:00
|
|
|
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> */
|
2022-02-25 10:22:52 +08:00
|
|
|
genwqe->cmd_cmpl = cmpl;
|
2017-02-13 05:52:32 +08:00
|
|
|
genwqe->drvrTimeout = tmo + LPFC_DRVR_TIMEOUT;
|
|
|
|
genwqe->vport = vport;
|
|
|
|
genwqe->retry = retry;
|
|
|
|
|
2017-02-13 05:52:33 +08: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-29 03:14:26 +08:00
|
|
|
rc = lpfc_sli4_issue_wqe(phba, &phba->sli4_hba.hdwq[0], genwqe);
|
2017-08-24 07:55:35 +08:00
|
|
|
if (rc) {
|
2020-07-01 05:50:00 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_TRACE_EVENT,
|
2017-02-13 05:52:32 +08:00
|
|
|
"6045 Issue GEN REQ WQE to NPORT x%x "
|
2020-04-01 00:50:06 +08:00
|
|
|
"Data: x%x x%x rc x%x\n",
|
2017-02-13 05:52:32 +08:00
|
|
|
ndlp->nlp_DID, genwqe->iotag,
|
2020-04-01 00:50:06 +08:00
|
|
|
vport->port_state, rc);
|
2020-11-16 03:26:33 +08:00
|
|
|
lpfc_nlp_put(ndlp);
|
2017-02-13 05:52:32 +08:00
|
|
|
lpfc_sli_release_iocbq(phba, genwqe);
|
|
|
|
return 1;
|
|
|
|
}
|
2020-04-01 00:50:06 +08:00
|
|
|
|
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_DISC | LOG_ELS,
|
|
|
|
"6050 Issue GEN REQ WQE to NPORT x%x "
|
|
|
|
"Data: oxid: x%x state: x%x wq:x%px lsreq:x%px "
|
|
|
|
"bmp:x%px xmit:%d 1st:%d\n",
|
|
|
|
ndlp->nlp_DID, genwqe->sli4_xritag,
|
|
|
|
vport->port_state,
|
|
|
|
genwqe, pnvme_lsreq, bmp, xmit_len, first_len);
|
2017-02-13 05:52:32 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-04-01 00:50:06 +08:00
|
|
|
|
2017-02-13 05:52:32 +08:00
|
|
|
/**
|
2020-04-01 00:50:06 +08:00
|
|
|
* __lpfc_nvme_ls_req - Generic service routine to issue an NVME LS request
|
|
|
|
* @vport: The local port issuing the LS
|
|
|
|
* @ndlp: The remote port to send the LS to
|
|
|
|
* @pnvme_lsreq: Pointer to LS request structure from the transport
|
2020-07-13 15:59:57 +08:00
|
|
|
* @gen_req_cmp: Completion call-back
|
2017-02-13 05:52:32 +08:00
|
|
|
*
|
2020-04-01 00:50:06 +08:00
|
|
|
* Routine validates the ndlp, builds buffers and sends a GEN_REQUEST
|
|
|
|
* WQE to perform the LS operation.
|
2017-02-13 05:52:32 +08:00
|
|
|
*
|
|
|
|
* Return value :
|
|
|
|
* 0 - Success
|
2020-04-01 00:50:06 +08:00
|
|
|
* non-zero: various error codes, in form of -Exxx
|
2017-02-13 05:52:32 +08:00
|
|
|
**/
|
2020-04-01 00:50:06 +08:00
|
|
|
int
|
|
|
|
__lpfc_nvme_ls_req(struct lpfc_vport *vport, struct lpfc_nodelist *ndlp,
|
|
|
|
struct nvmefc_ls_req *pnvme_lsreq,
|
|
|
|
void (*gen_req_cmp)(struct lpfc_hba *phba,
|
|
|
|
struct lpfc_iocbq *cmdwqe,
|
2022-02-25 10:22:52 +08:00
|
|
|
struct lpfc_iocbq *rspwqe))
|
2017-02-13 05:52:32 +08:00
|
|
|
{
|
|
|
|
struct lpfc_dmabuf *bmp;
|
2020-04-01 00:50:06 +08:00
|
|
|
struct ulp_bde64 *bpl;
|
|
|
|
int ret;
|
2017-04-22 07:04:47 +08:00
|
|
|
uint16_t ntype, nstate;
|
2017-02-13 05:52:32 +08:00
|
|
|
|
2020-11-16 03:26:30 +08:00
|
|
|
if (!ndlp) {
|
2020-07-01 05:50:00 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_TRACE_EVENT,
|
2020-04-01 00:50:06 +08:00
|
|
|
"6051 NVMEx LS REQ: Bad NDLP x%px, Failing "
|
|
|
|
"LS Req\n",
|
|
|
|
ndlp);
|
2017-04-22 07:04:47 +08:00
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
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)) {
|
2020-07-01 05:50:00 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_TRACE_EVENT,
|
2020-04-01 00:50:06 +08:00
|
|
|
"6088 NVMEx LS REQ: Fail DID x%06x not "
|
|
|
|
"ready for IO. Type x%x, State x%x\n",
|
|
|
|
ndlp->nlp_DID, ntype, nstate);
|
2017-04-22 07:04:47 +08:00
|
|
|
return -ENODEV;
|
2017-02-13 05:52:32 +08:00
|
|
|
}
|
2022-03-17 11:27:35 +08:00
|
|
|
if (vport->phba->hba_flag & HBA_IOQ_FLUSH)
|
|
|
|
return -ENODEV;
|
2020-04-01 00:50:06 +08:00
|
|
|
|
2021-01-28 06:16:01 +08:00
|
|
|
if (!vport->phba->sli4_hba.nvmels_wq)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2020-04-01 00:50:06 +08: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.
|
|
|
|
*/
|
|
|
|
|
|
|
|
bmp = kmalloc(sizeof(*bmp), GFP_KERNEL);
|
2017-02-13 05:52:32 +08:00
|
|
|
if (!bmp) {
|
2020-07-01 05:50:00 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_TRACE_EVENT,
|
2020-04-01 00:50:06 +08:00
|
|
|
"6044 NVMEx LS REQ: Could not alloc LS buf "
|
|
|
|
"for DID %x\n",
|
|
|
|
ndlp->nlp_DID);
|
|
|
|
return -ENOMEM;
|
2017-02-13 05:52:32 +08:00
|
|
|
}
|
2020-04-01 00:50:06 +08:00
|
|
|
|
2017-02-13 05:52:32 +08:00
|
|
|
bmp->virt = lpfc_mbuf_alloc(vport->phba, MEM_PRI, &(bmp->phys));
|
|
|
|
if (!bmp->virt) {
|
2020-07-01 05:50:00 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_TRACE_EVENT,
|
2020-04-01 00:50:06 +08:00
|
|
|
"6042 NVMEx LS REQ: Could not alloc mbuf "
|
|
|
|
"for DID %x\n",
|
|
|
|
ndlp->nlp_DID);
|
2017-02-13 05:52:32 +08:00
|
|
|
kfree(bmp);
|
2020-04-01 00:50:06 +08:00
|
|
|
return -ENOMEM;
|
2017-02-13 05:52:32 +08:00
|
|
|
}
|
2020-04-01 00:50:06 +08:00
|
|
|
|
|
|
|
INIT_LIST_HEAD(&bmp->list);
|
|
|
|
|
2017-02-13 05:52:32 +08:00
|
|
|
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);
|
|
|
|
|
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_DISC,
|
2020-04-01 00:50:06 +08:00
|
|
|
"6149 NVMEx LS REQ: Issue to DID 0x%06x lsreq x%px, "
|
|
|
|
"rqstlen:%d rsplen:%d %pad %pad\n",
|
|
|
|
ndlp->nlp_DID, pnvme_lsreq, pnvme_lsreq->rqstlen,
|
|
|
|
pnvme_lsreq->rsplen, &pnvme_lsreq->rqstdma,
|
|
|
|
&pnvme_lsreq->rspdma);
|
2017-02-13 05:52:32 +08:00
|
|
|
|
|
|
|
ret = lpfc_nvme_gen_req(vport, bmp, pnvme_lsreq->rqstaddr,
|
2020-04-01 00:50:06 +08:00
|
|
|
pnvme_lsreq, gen_req_cmp, ndlp, 2,
|
2021-01-05 02:02:30 +08:00
|
|
|
pnvme_lsreq->timeout, 0);
|
2017-02-13 05:52:32 +08:00
|
|
|
if (ret != WQE_SUCCESS) {
|
2020-07-01 05:50:00 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_TRACE_EVENT,
|
2020-04-01 00:50:06 +08:00
|
|
|
"6052 NVMEx REQ: EXIT. issue ls wqe failed "
|
|
|
|
"lsreq x%px Status %x DID %x\n",
|
|
|
|
pnvme_lsreq, ret, ndlp->nlp_DID);
|
2017-02-13 05:52:32 +08:00
|
|
|
lpfc_mbuf_free(vport->phba, bmp->virt, bmp->phys);
|
|
|
|
kfree(bmp);
|
2020-04-01 00:50:06 +08:00
|
|
|
return -EIO;
|
2017-02-13 05:52:32 +08:00
|
|
|
}
|
|
|
|
|
2020-04-01 00:50:06 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* lpfc_nvme_ls_req - Issue an NVME Link Service request
|
2020-07-13 15:59:57 +08:00
|
|
|
* @pnvme_lport: Transport localport that LS is to be issued from.
|
2020-11-02 22:23:52 +08:00
|
|
|
* @pnvme_rport: Transport remoteport that LS is to be sent to.
|
2020-07-13 15:59:57 +08:00
|
|
|
* @pnvme_lsreq: the transport nvme_ls_req structure for the LS
|
2020-04-01 00:50:06 +08:00
|
|
|
*
|
|
|
|
* 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
|
|
|
|
* non-zero: various error codes, in form of -Exxx
|
|
|
|
**/
|
|
|
|
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)
|
|
|
|
{
|
|
|
|
struct lpfc_nvme_lport *lport;
|
|
|
|
struct lpfc_nvme_rport *rport;
|
|
|
|
struct lpfc_vport *vport;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
lport = (struct lpfc_nvme_lport *)pnvme_lport->private;
|
|
|
|
rport = (struct lpfc_nvme_rport *)pnvme_rport->private;
|
|
|
|
if (unlikely(!lport) || unlikely(!rport))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
vport = lport->vport;
|
2022-03-17 11:27:35 +08:00
|
|
|
if (vport->load_flag & FC_UNLOADING ||
|
|
|
|
vport->phba->hba_flag & HBA_IOQ_FLUSH)
|
2020-04-01 00:50:06 +08:00
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
atomic_inc(&lport->fc4NvmeLsRequests);
|
|
|
|
|
|
|
|
ret = __lpfc_nvme_ls_req(vport, rport->ndlp, pnvme_lsreq,
|
|
|
|
lpfc_nvme_ls_req_cmp);
|
|
|
|
if (ret)
|
|
|
|
atomic_inc(&lport->xmt_ls_err);
|
|
|
|
|
2017-02-13 05:52:32 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2020-04-01 00:50:07 +08:00
|
|
|
* __lpfc_nvme_ls_abort - Generic service routine to abort a prior
|
|
|
|
* NVME LS request
|
|
|
|
* @vport: The local port that issued the LS
|
|
|
|
* @ndlp: The remote port the LS was sent to
|
|
|
|
* @pnvme_lsreq: Pointer to LS request structure from the transport
|
2017-02-13 05:52:32 +08:00
|
|
|
*
|
2020-04-01 00:50:07 +08:00
|
|
|
* The driver validates the ndlp, looks for the LS, and aborts the
|
|
|
|
* LS if found.
|
2017-02-13 05:52:32 +08:00
|
|
|
*
|
2020-04-01 00:50:07 +08:00
|
|
|
* Returns:
|
|
|
|
* 0 : if LS found and aborted
|
|
|
|
* non-zero: various error conditions in form -Exxx
|
2017-02-13 05:52:32 +08:00
|
|
|
**/
|
2020-04-01 00:50:07 +08:00
|
|
|
int
|
|
|
|
__lpfc_nvme_ls_abort(struct lpfc_vport *vport, struct lpfc_nodelist *ndlp,
|
|
|
|
struct nvmefc_ls_req *pnvme_lsreq)
|
2017-02-13 05:52:32 +08:00
|
|
|
{
|
2020-04-01 00:50:07 +08:00
|
|
|
struct lpfc_hba *phba = vport->phba;
|
2017-02-13 05:52:32 +08:00
|
|
|
struct lpfc_sli_ring *pring;
|
|
|
|
struct lpfc_iocbq *wqe, *next_wqe;
|
2020-04-01 00:50:07 +08:00
|
|
|
bool foundit = false;
|
2017-02-13 05:52:32 +08:00
|
|
|
|
|
|
|
if (!ndlp) {
|
2020-07-01 05:50:00 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_TRACE_EVENT,
|
2020-04-01 00:50:07 +08:00
|
|
|
"6049 NVMEx LS REQ Abort: Bad NDLP x%px DID "
|
|
|
|
"x%06x, Failing LS Req\n",
|
|
|
|
ndlp, ndlp ? ndlp->nlp_DID : 0);
|
|
|
|
return -EINVAL;
|
2017-02-13 05:52:32 +08:00
|
|
|
}
|
|
|
|
|
2020-04-01 00:50:07 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_DISC | LOG_NVME_ABTS,
|
|
|
|
"6040 NVMEx LS REQ Abort: Issue LS_ABORT for lsreq "
|
2021-04-12 09:31:24 +08:00
|
|
|
"x%px rqstlen:%d rsplen:%d %pad %pad\n",
|
2017-02-13 05:52:32 +08:00
|
|
|
pnvme_lsreq, pnvme_lsreq->rqstlen,
|
2017-02-28 04:37:12 +08:00
|
|
|
pnvme_lsreq->rsplen, &pnvme_lsreq->rqstdma,
|
|
|
|
&pnvme_lsreq->rspdma);
|
2017-02-13 05:52:32 +08:00
|
|
|
|
|
|
|
/*
|
2020-04-01 00:50:07 +08:00
|
|
|
* Lock the ELS ring txcmplq and look for the wqe that matches
|
|
|
|
* this ELS. If found, issue an abort on the wqe.
|
2017-02-13 05:52:32 +08:00
|
|
|
*/
|
|
|
|
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) {
|
2022-04-13 06:20:02 +08:00
|
|
|
if (wqe->context_un.nvme_lsreq == pnvme_lsreq) {
|
2022-02-25 10:22:52 +08:00
|
|
|
wqe->cmd_flag |= LPFC_DRIVER_ABORTED;
|
2020-04-01 00:50:07 +08:00
|
|
|
foundit = true;
|
|
|
|
break;
|
2017-02-13 05:52:32 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
spin_unlock(&pring->ring_lock);
|
2020-04-01 00:50:07 +08:00
|
|
|
|
|
|
|
if (foundit)
|
2020-11-16 03:26:44 +08:00
|
|
|
lpfc_sli_issue_abort_iotag(phba, pring, wqe, NULL);
|
2017-02-13 05:52:32 +08:00
|
|
|
spin_unlock_irq(&phba->hbalock);
|
|
|
|
|
2020-04-01 00:50:07 +08:00
|
|
|
if (foundit)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_DISC | LOG_NVME_ABTS,
|
2021-04-12 09:31:24 +08:00
|
|
|
"6213 NVMEx LS REQ Abort: Unable to locate req x%px\n",
|
2020-04-01 00:50:07 +08:00
|
|
|
pnvme_lsreq);
|
2020-05-21 02:59:29 +08:00
|
|
|
return -EINVAL;
|
2020-04-01 00:50:07 +08:00
|
|
|
}
|
|
|
|
|
2020-04-01 00:50:09 +08:00
|
|
|
static int
|
|
|
|
lpfc_nvme_xmt_ls_rsp(struct nvme_fc_local_port *localport,
|
|
|
|
struct nvme_fc_remote_port *remoteport,
|
|
|
|
struct nvmefc_ls_rsp *ls_rsp)
|
|
|
|
{
|
|
|
|
struct lpfc_async_xchg_ctx *axchg =
|
|
|
|
container_of(ls_rsp, struct lpfc_async_xchg_ctx, ls_rsp);
|
|
|
|
struct lpfc_nvme_lport *lport;
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
if (axchg->phba->pport->load_flag & FC_UNLOADING)
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
lport = (struct lpfc_nvme_lport *)localport->private;
|
|
|
|
|
|
|
|
rc = __lpfc_nvme_xmt_ls_rsp(axchg, ls_rsp, __lpfc_nvme_xmt_ls_rsp_cmp);
|
|
|
|
|
|
|
|
if (rc) {
|
|
|
|
/*
|
|
|
|
* unless the failure is due to having already sent
|
|
|
|
* the response, an abort will be generated for the
|
|
|
|
* exchange if the rsp can't be sent.
|
|
|
|
*/
|
|
|
|
if (rc != -EALREADY)
|
|
|
|
atomic_inc(&lport->xmt_ls_abort);
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-04-01 00:50:07 +08:00
|
|
|
/**
|
|
|
|
* lpfc_nvme_ls_abort - Abort a prior NVME LS request
|
2020-07-13 15:59:57 +08:00
|
|
|
* @pnvme_lport: Transport localport that LS is to be issued from.
|
|
|
|
* @pnvme_rport: Transport remoteport that LS is to be sent to.
|
|
|
|
* @pnvme_lsreq: the transport nvme_ls_req structure for the LS
|
2020-04-01 00:50:07 +08:00
|
|
|
*
|
|
|
|
* Driver registers this routine to abort a NVME LS request that is
|
|
|
|
* in progress (from the transports perspective).
|
|
|
|
**/
|
|
|
|
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_nodelist *ndlp;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
lport = (struct lpfc_nvme_lport *)pnvme_lport->private;
|
|
|
|
if (unlikely(!lport))
|
|
|
|
return;
|
|
|
|
vport = lport->vport;
|
|
|
|
|
|
|
|
if (vport->load_flag & FC_UNLOADING)
|
|
|
|
return;
|
|
|
|
|
|
|
|
ndlp = lpfc_findnode_did(vport, pnvme_rport->port_id);
|
|
|
|
|
|
|
|
ret = __lpfc_nvme_ls_abort(vport, ndlp, pnvme_lsreq);
|
|
|
|
if (!ret)
|
2017-12-09 09:18:10 +08:00
|
|
|
atomic_inc(&lport->xmt_ls_abort);
|
2017-02-13 05:52:32 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Fix up the existing sgls for NVME IO. */
|
2018-03-06 04:04:04 +08:00
|
|
|
static inline void
|
2017-02-13 05:52:32 +08: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-29 03:14:28 +08:00
|
|
|
struct lpfc_io_buf *lpfc_ncmd,
|
2017-02-13 05:52:32 +08:00
|
|
|
struct nvmefc_fcp_req *nCmd)
|
|
|
|
{
|
2018-02-23 00:18:50 +08:00
|
|
|
struct lpfc_hba *phba = vport->phba;
|
2017-02-13 05:52:32 +08:00
|
|
|
struct sli4_sge *sgl;
|
|
|
|
union lpfc_wqe128 *wqe;
|
|
|
|
uint32_t *wptr, *dptr;
|
|
|
|
|
2018-02-23 00:18:50 +08: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-06 04:04:03 +08:00
|
|
|
wqe = &lpfc_ncmd->cur_iocbq.wqe;
|
2018-02-23 00:18:50 +08:00
|
|
|
|
2017-02-13 05:52:32 +08: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-29 03:14:19 +08:00
|
|
|
sgl = lpfc_ncmd->dma_sgl;
|
2017-02-13 05:52:32 +08:00
|
|
|
sgl->sge_len = cpu_to_le32(nCmd->cmdlen);
|
2018-02-23 00:18:50 +08: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-06 04:04:04 +08: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-23 00:18:50 +08: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-06 04:04:04 +08:00
|
|
|
|
|
|
|
/* Word 10 */
|
|
|
|
bf_set(wqe_dbde, &wqe->generic.wqe_com, 1);
|
|
|
|
bf_set(wqe_wqes, &wqe->generic.wqe_com, 0);
|
2018-02-23 00:18:50 +08:00
|
|
|
}
|
2017-02-13 05:52:32 +08: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-13 05:52:33 +08:00
|
|
|
|
2020-07-13 15:59:57 +08:00
|
|
|
/*
|
2022-02-25 10:22:52 +08:00
|
|
|
* lpfc_nvme_io_cmd_cmpl - Complete an NVME-over-FCP IO
|
2017-02-13 05:52:32 +08:00
|
|
|
*
|
|
|
|
* 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
|
2022-02-25 10:22:52 +08:00
|
|
|
lpfc_nvme_io_cmd_cmpl(struct lpfc_hba *phba, struct lpfc_iocbq *pwqeIn,
|
|
|
|
struct lpfc_iocbq *pwqeOut)
|
2017-02-13 05:52:32 +08:00
|
|
|
{
|
2022-04-13 06:20:02 +08:00
|
|
|
struct lpfc_io_buf *lpfc_ncmd = pwqeIn->io_buf;
|
2022-02-25 10:22:52 +08:00
|
|
|
struct lpfc_wcqe_complete *wcqe = &pwqeOut->wcqe_cmpl;
|
2017-02-13 05:52:32 +08: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 08:49:08 +08:00
|
|
|
struct lpfc_nvme_fcpreq_priv *freqpriv;
|
2017-12-09 09:18:10 +08:00
|
|
|
struct lpfc_nvme_lport *lport;
|
2019-03-05 03:39:08 +08:00
|
|
|
uint32_t code, status, idx;
|
2017-02-13 05:52:32 +08:00
|
|
|
uint16_t cid, sqhd, data;
|
|
|
|
uint32_t *ptr;
|
2021-08-17 00:28:54 +08:00
|
|
|
uint32_t lat;
|
|
|
|
bool call_done = false;
|
2020-03-23 02:13:00 +08:00
|
|
|
#ifdef CONFIG_SCSI_LPFC_DEBUG_FS
|
|
|
|
int cpu;
|
|
|
|
#endif
|
scsi: lpfc: Fix EEH support for NVMe I/O
Injecting errors on the PCI slot while the driver is handling NVMe I/O will
cause crashes and hangs.
There are several rather difficult scenarios occurring. The main issue is
that the adapter can report a PCI error before or simultaneously to the PCI
subsystem reporting the error. Both paths have different entry points and
currently there is no interlock between them. Thus multiple teardown paths
are competing and all heck breaks loose.
Complicating things is the NVMs path. To a large degree, I/O was able to be
shutdown for a full FC port on the SCSI stack. But on NVMe, there isn't a
similar call. At best, it works on a per-controller basis, but even at the
controller level, it's a controller "reset" call. All of which means I/O is
still flowing on different CPUs with reset paths expecting hw access
(mailbox commands) to execute properly.
The following modifications are made:
- A new flag is set in PCI error entrypoints so the driver can track being
called by that path.
- An interlock is added in the SLI hw error path and the PCI error path
such that only one of the paths proceeds with the teardown logic.
- RPI cleanup is patched such that RPIs are marked unregistered w/o mbx
cmds in cases of hw error.
- If entering the SLI port re-init calls, a case where SLI error teardown
was quick and beat the PCI calls now reporting error, check whether the
SLI port is still live on the PCI bus.
- In the PCI reset code to bring the adapter back, recheck the IRQ
settings. Different checks for SLI3 vs SLI4.
- In I/O completions, that may be called as part of the cleanup or
underway just before the hw error, check the state of the adapter. If
in error, shortcut handling that would expect further adapter
completions as the hw error won't be sending them.
- In routines waiting on I/O completions, which may have been in progress
prior to the hw error, detect the device is being torn down and abort
from their waits and just give up. This points to a larger issue in the
driver on ref-counting for data structures, as it doesn't have
ref-counting on q and port structures. We'll do this fix for now as it
would be a major rework to be done differently.
- Fix the NVMe cleanup to simulate NVMe I/O completions if I/O is being
failed back due to hw error.
- In I/O buf allocation, done at the start of new I/Os, check hw state and
fail if hw error.
Link: https://lore.kernel.org/r/20210910233159.115896-10-jsmart2021@gmail.com
Co-developed-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-09-11 07:31:54 +08:00
|
|
|
int offline = 0;
|
2017-02-13 05:52:32 +08:00
|
|
|
|
|
|
|
/* Sanity check on return of outstanding command */
|
2019-01-29 03:14:37 +08:00
|
|
|
if (!lpfc_ncmd) {
|
2020-07-01 05:50:00 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_TRACE_EVENT,
|
2019-01-29 03:14:37 +08:00
|
|
|
"6071 Null lpfc_ncmd pointer. No "
|
|
|
|
"release, skip completion\n");
|
|
|
|
return;
|
|
|
|
}
|
2018-05-25 12:08:58 +08:00
|
|
|
|
2019-01-29 03:14:37 +08:00
|
|
|
/* Guard against abort handler being called at same time */
|
|
|
|
spin_lock(&lpfc_ncmd->buf_lock);
|
2018-05-25 12:08:58 +08:00
|
|
|
|
2019-01-29 03:14:37 +08:00
|
|
|
if (!lpfc_ncmd->nvmeCmd) {
|
|
|
|
spin_unlock(&lpfc_ncmd->buf_lock);
|
2020-07-01 05:50:00 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_TRACE_EVENT,
|
2019-08-15 07:57:06 +08:00
|
|
|
"6066 Missing cmpl ptrs: lpfc_ncmd x%px, "
|
|
|
|
"nvmeCmd x%px\n",
|
2019-01-29 03:14:17 +08:00
|
|
|
lpfc_ncmd, lpfc_ncmd->nvmeCmd);
|
2018-05-25 12:08:58 +08:00
|
|
|
|
|
|
|
/* Release the lpfc_ncmd regardless of the missing elements. */
|
|
|
|
lpfc_release_nvme_buf(phba, lpfc_ncmd);
|
2017-02-13 05:52:32 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
nCmd = lpfc_ncmd->nvmeCmd;
|
2017-12-09 09:18:10 +08:00
|
|
|
status = bf_get(lpfc_wcqe_c_status, wcqe);
|
2018-04-10 05:24:23 +08:00
|
|
|
|
2019-01-29 03:14:25 +08:00
|
|
|
idx = lpfc_ncmd->cur_iocbq.hba_wqidx;
|
|
|
|
phba->sli4_hba.hdwq[idx].nvme_cstat.io_cmpls++;
|
|
|
|
|
2019-08-15 07:57:05 +08:00
|
|
|
if (unlikely(status && vport->localport)) {
|
2018-04-10 05:24:31 +08:00
|
|
|
lport = (struct lpfc_nvme_lport *)vport->localport->private;
|
2019-08-15 07:57:05 +08:00
|
|
|
if (lport) {
|
2019-01-29 03:14:25 +08:00
|
|
|
if (bf_get(lpfc_wcqe_c_xb, wcqe))
|
|
|
|
atomic_inc(&lport->cmpl_fcp_xb);
|
|
|
|
atomic_inc(&lport->cmpl_fcp_err);
|
2018-04-10 05:24:23 +08:00
|
|
|
}
|
2017-12-09 09:18:10 +08:00
|
|
|
}
|
2017-02-13 05:52:32 +08:00
|
|
|
|
2017-02-13 05:52:33 +08: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 09:18:10 +08:00
|
|
|
status, wcqe->parameter);
|
2017-02-13 05:52:32 +08:00
|
|
|
/*
|
|
|
|
* Catch race where our node has transitioned, but the
|
|
|
|
* transport is still transitioning.
|
|
|
|
*/
|
2019-01-29 03:14:17 +08:00
|
|
|
ndlp = lpfc_ncmd->ndlp;
|
2020-11-16 03:26:30 +08:00
|
|
|
if (!ndlp) {
|
2020-07-01 05:50:00 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_TRACE_EVENT,
|
2019-01-29 03:14:17 +08:00
|
|
|
"6062 Ignoring NVME cmpl. No ndlp\n");
|
|
|
|
goto out_err;
|
2017-02-13 05:52:32 +08: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 {
|
2023-05-24 02:32:03 +08:00
|
|
|
lpfc_ncmd->status = status;
|
2017-09-30 08:34:43 +08:00
|
|
|
lpfc_ncmd->result = (wcqe->parameter & IOERR_PARAM_MASK);
|
2017-02-13 05:52:32 +08: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;
|
2021-05-15 03:55:50 +08:00
|
|
|
|
2022-06-04 01:43:27 +08:00
|
|
|
/* Get the NVME cmd details for this unique error. */
|
|
|
|
cp = (struct nvme_fc_cmd_iu *)nCmd->cmdaddr;
|
|
|
|
ep = (struct nvme_fc_ersp_iu *)nCmd->rspaddr;
|
|
|
|
|
2021-05-15 03:55:50 +08:00
|
|
|
/* Check if this is really an ERSP */
|
|
|
|
if (nCmd->rcv_rsplen == LPFC_NVME_ERSP_LEN) {
|
|
|
|
lpfc_ncmd->status = IOSTAT_SUCCESS;
|
|
|
|
lpfc_ncmd->result = 0;
|
|
|
|
|
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME,
|
2022-06-04 01:43:27 +08:00
|
|
|
"6084 NVME FCP_ERR ERSP: "
|
|
|
|
"xri %x placed x%x opcode x%x cmd_id "
|
|
|
|
"x%x cqe_status x%x\n",
|
|
|
|
lpfc_ncmd->cur_iocbq.sli4_xritag,
|
|
|
|
wcqe->total_data_placed,
|
|
|
|
cp->sqe.common.opcode,
|
|
|
|
cp->sqe.common.command_id,
|
|
|
|
ep->cqe.status);
|
2017-02-13 05:52:32 +08:00
|
|
|
break;
|
2021-05-15 03:55:50 +08:00
|
|
|
}
|
2020-07-01 05:50:00 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_TRACE_EVENT,
|
2017-02-13 05:52:32 +08:00
|
|
|
"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-22 07:05:04 +08:00
|
|
|
"xri %x status x%x result x%x "
|
2022-06-04 01:43:27 +08:00
|
|
|
"placed x%x opcode x%x cmd_id x%x, "
|
|
|
|
"cqe_status 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-22 07:05:04 +08:00
|
|
|
lpfc_ncmd->cur_iocbq.sli4_xritag,
|
2017-02-13 05:52:32 +08:00
|
|
|
lpfc_ncmd->status, lpfc_ncmd->result,
|
2022-06-04 01:43:27 +08:00
|
|
|
wcqe->total_data_placed,
|
|
|
|
cp->sqe.common.opcode,
|
|
|
|
cp->sqe.common.command_id,
|
|
|
|
ep->cqe.status);
|
2017-02-13 05:52:32 +08:00
|
|
|
break;
|
2017-09-30 08:34:43 +08: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-15 07:57:06 +08:00
|
|
|
"6032 Delay Aborted cmd x%px "
|
|
|
|
"nvme cmd x%px, xri x%x, "
|
2017-09-30 08:34:43 +08:00
|
|
|
"xb %d\n",
|
|
|
|
lpfc_ncmd, nCmd,
|
|
|
|
lpfc_ncmd->cur_iocbq.sli4_xritag,
|
|
|
|
bf_get(lpfc_wcqe_c_xb, wcqe));
|
2020-08-24 06:36:59 +08:00
|
|
|
fallthrough;
|
2017-02-13 05:52:32 +08:00
|
|
|
default:
|
|
|
|
out_err:
|
2017-09-30 08:34:36 +08: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-22 07:05:04 +08:00
|
|
|
"6072 NVME Completion Error: xri %x "
|
2019-03-13 07:30:31 +08: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-22 07:05:04 +08:00
|
|
|
lpfc_ncmd->cur_iocbq.sli4_xritag,
|
2017-02-13 05:52:32 +08:00
|
|
|
lpfc_ncmd->status, lpfc_ncmd->result,
|
2019-03-13 07:30:31 +08:00
|
|
|
wcqe->parameter,
|
2017-02-13 05:52:32 +08:00
|
|
|
wcqe->total_data_placed);
|
|
|
|
nCmd->transferred_length = 0;
|
|
|
|
nCmd->rcv_rsplen = 0;
|
2017-09-08 07:27:29 +08:00
|
|
|
nCmd->status = NVME_SC_INTERNAL;
|
scsi: lpfc: Fix EEH support for NVMe I/O
Injecting errors on the PCI slot while the driver is handling NVMe I/O will
cause crashes and hangs.
There are several rather difficult scenarios occurring. The main issue is
that the adapter can report a PCI error before or simultaneously to the PCI
subsystem reporting the error. Both paths have different entry points and
currently there is no interlock between them. Thus multiple teardown paths
are competing and all heck breaks loose.
Complicating things is the NVMs path. To a large degree, I/O was able to be
shutdown for a full FC port on the SCSI stack. But on NVMe, there isn't a
similar call. At best, it works on a per-controller basis, but even at the
controller level, it's a controller "reset" call. All of which means I/O is
still flowing on different CPUs with reset paths expecting hw access
(mailbox commands) to execute properly.
The following modifications are made:
- A new flag is set in PCI error entrypoints so the driver can track being
called by that path.
- An interlock is added in the SLI hw error path and the PCI error path
such that only one of the paths proceeds with the teardown logic.
- RPI cleanup is patched such that RPIs are marked unregistered w/o mbx
cmds in cases of hw error.
- If entering the SLI port re-init calls, a case where SLI error teardown
was quick and beat the PCI calls now reporting error, check whether the
SLI port is still live on the PCI bus.
- In the PCI reset code to bring the adapter back, recheck the IRQ
settings. Different checks for SLI3 vs SLI4.
- In I/O completions, that may be called as part of the cleanup or
underway just before the hw error, check the state of the adapter. If
in error, shortcut handling that would expect further adapter
completions as the hw error won't be sending them.
- In routines waiting on I/O completions, which may have been in progress
prior to the hw error, detect the device is being torn down and abort
from their waits and just give up. This points to a larger issue in the
driver on ref-counting for data structures, as it doesn't have
ref-counting on q and port structures. We'll do this fix for now as it
would be a major rework to be done differently.
- Fix the NVMe cleanup to simulate NVMe I/O completions if I/O is being
failed back due to hw error.
- In I/O buf allocation, done at the start of new I/Os, check hw state and
fail if hw error.
Link: https://lore.kernel.org/r/20210910233159.115896-10-jsmart2021@gmail.com
Co-developed-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-09-11 07:31:54 +08:00
|
|
|
offline = pci_channel_offline(vport->phba->pcidev);
|
2017-02-13 05:52:32 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* pick up SLI4 exhange busy condition */
|
scsi: lpfc: Fix EEH support for NVMe I/O
Injecting errors on the PCI slot while the driver is handling NVMe I/O will
cause crashes and hangs.
There are several rather difficult scenarios occurring. The main issue is
that the adapter can report a PCI error before or simultaneously to the PCI
subsystem reporting the error. Both paths have different entry points and
currently there is no interlock between them. Thus multiple teardown paths
are competing and all heck breaks loose.
Complicating things is the NVMs path. To a large degree, I/O was able to be
shutdown for a full FC port on the SCSI stack. But on NVMe, there isn't a
similar call. At best, it works on a per-controller basis, but even at the
controller level, it's a controller "reset" call. All of which means I/O is
still flowing on different CPUs with reset paths expecting hw access
(mailbox commands) to execute properly.
The following modifications are made:
- A new flag is set in PCI error entrypoints so the driver can track being
called by that path.
- An interlock is added in the SLI hw error path and the PCI error path
such that only one of the paths proceeds with the teardown logic.
- RPI cleanup is patched such that RPIs are marked unregistered w/o mbx
cmds in cases of hw error.
- If entering the SLI port re-init calls, a case where SLI error teardown
was quick and beat the PCI calls now reporting error, check whether the
SLI port is still live on the PCI bus.
- In the PCI reset code to bring the adapter back, recheck the IRQ
settings. Different checks for SLI3 vs SLI4.
- In I/O completions, that may be called as part of the cleanup or
underway just before the hw error, check the state of the adapter. If
in error, shortcut handling that would expect further adapter
completions as the hw error won't be sending them.
- In routines waiting on I/O completions, which may have been in progress
prior to the hw error, detect the device is being torn down and abort
from their waits and just give up. This points to a larger issue in the
driver on ref-counting for data structures, as it doesn't have
ref-counting on q and port structures. We'll do this fix for now as it
would be a major rework to be done differently.
- Fix the NVMe cleanup to simulate NVMe I/O completions if I/O is being
failed back due to hw error.
- In I/O buf allocation, done at the start of new I/Os, check hw state and
fail if hw error.
Link: https://lore.kernel.org/r/20210910233159.115896-10-jsmart2021@gmail.com
Co-developed-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-09-11 07:31:54 +08:00
|
|
|
if (bf_get(lpfc_wcqe_c_xb, wcqe) && !offline)
|
2017-02-13 05:52:32 +08:00
|
|
|
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-13 05:52:33 +08:00
|
|
|
#ifdef CONFIG_SCSI_LPFC_DEBUG_FS
|
2017-09-30 08:34:33 +08:00
|
|
|
if (lpfc_ncmd->ts_cmd_start) {
|
2017-02-13 05:52:33 +08:00
|
|
|
lpfc_ncmd->ts_isr_cmpl = pwqeIn->isr_timestamp;
|
2020-03-23 02:13:02 +08: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-13 05:52:33 +08:00
|
|
|
}
|
2020-03-23 02:13:00 +08:00
|
|
|
if (unlikely(phba->hdwqstat_on & LPFC_CHECK_NVME_IO)) {
|
2019-03-29 02:06:22 +08:00
|
|
|
cpu = raw_smp_processor_id();
|
2020-03-23 02:13:00 +08: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-13 05:52:33 +08:00
|
|
|
}
|
|
|
|
#endif
|
2017-09-30 08:34:43 +08:00
|
|
|
|
|
|
|
/* NVME targets need completion held off until the abort exchange
|
2017-11-21 08:00:40 +08:00
|
|
|
* completes unless the NVME Rport is getting unregistered.
|
2017-09-30 08:34:43 +08:00
|
|
|
*/
|
2017-11-21 08:00:40 +08:00
|
|
|
|
2017-12-09 09:18:09 +08:00
|
|
|
if (!(lpfc_ncmd->flags & LPFC_SBUF_XBUSY)) {
|
2018-01-31 07:58:51 +08:00
|
|
|
freqpriv = nCmd->private;
|
|
|
|
freqpriv->nvme_buf = NULL;
|
2017-12-09 09:18:09 +08:00
|
|
|
lpfc_ncmd->nvmeCmd = NULL;
|
2021-08-17 00:28:54 +08:00
|
|
|
call_done = true;
|
|
|
|
}
|
|
|
|
spin_unlock(&lpfc_ncmd->buf_lock);
|
|
|
|
|
|
|
|
/* Check if IO qualified for CMF */
|
|
|
|
if (phba->cmf_active_mode != LPFC_CFG_OFF &&
|
|
|
|
nCmd->io_dir == NVMEFC_FCP_READ &&
|
|
|
|
nCmd->payload_length) {
|
|
|
|
/* Used when calculating average latency */
|
|
|
|
lat = ktime_get_ns() - lpfc_ncmd->rx_cmd_start;
|
|
|
|
lpfc_update_cmf_cmpl(phba, lat, nCmd->payload_length, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (call_done)
|
2019-01-29 03:14:37 +08:00
|
|
|
nCmd->done(nCmd);
|
2017-02-13 05:52:32 +08:00
|
|
|
|
2017-09-30 08:34:43 +08:00
|
|
|
/* Call release with XB=1 to queue the IO into the abort list. */
|
2017-02-13 05:52:32 +08:00
|
|
|
lpfc_release_nvme_buf(phba, lpfc_ncmd);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* lpfc_nvme_prep_io_cmd - Issue an NVME-over-FCP IO
|
2020-07-13 15:59:57 +08:00
|
|
|
* @vport: pointer to a host virtual N_Port data structure
|
2020-11-02 22:23:52 +08:00
|
|
|
* @lpfc_ncmd: Pointer to lpfc scsi command
|
2020-07-13 15:59:57 +08:00
|
|
|
* @pnode: pointer to a node-list data structure
|
|
|
|
* @cstat: pointer to the control status structure
|
2017-02-13 05:52:32 +08:00
|
|
|
*
|
|
|
|
* 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-29 03:14:28 +08:00
|
|
|
struct lpfc_io_buf *lpfc_ncmd,
|
2018-04-10 05:24:23 +08:00
|
|
|
struct lpfc_nodelist *pnode,
|
2019-01-29 03:14:25 +08:00
|
|
|
struct lpfc_fc4_ctrl_stat *cstat)
|
2017-02-13 05:52:32 +08:00
|
|
|
{
|
|
|
|
struct lpfc_hba *phba = vport->phba;
|
|
|
|
struct nvmefc_fcp_req *nCmd = lpfc_ncmd->nvmeCmd;
|
2022-06-04 01:43:28 +08:00
|
|
|
struct nvme_common_command *sqe;
|
|
|
|
struct lpfc_iocbq *pwqeq = &lpfc_ncmd->cur_iocbq;
|
2018-03-06 04:04:03 +08:00
|
|
|
union lpfc_wqe128 *wqe = &pwqeq->wqe;
|
2017-02-13 05:52:32 +08:00
|
|
|
uint32_t req_len;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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-06 04:04:04 +08: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-13 05:52:32 +08: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-06 04:04:04 +08:00
|
|
|
} else {
|
|
|
|
wqe->fcp_iwrite.initial_xfer_len = 0;
|
2017-02-13 05:52:32 +08:00
|
|
|
}
|
2019-01-29 03:14:25 +08:00
|
|
|
cstat->output_requests++;
|
2017-02-13 05:52:32 +08:00
|
|
|
} else {
|
2018-03-06 04:04:04 +08: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-13 05:52:32 +08:00
|
|
|
|
2021-08-17 00:28:54 +08:00
|
|
|
/* For a CMF Managed port, iod must be zero'ed */
|
|
|
|
if (phba->cmf_active_mode == LPFC_CFG_MANAGED)
|
|
|
|
bf_set(wqe_iod, &wqe->fcp_iread.wqe_com,
|
|
|
|
LPFC_WQE_IOD_NONE);
|
2019-01-29 03:14:25 +08:00
|
|
|
cstat->input_requests++;
|
2017-02-13 05:52:32 +08:00
|
|
|
}
|
|
|
|
} else {
|
2018-03-06 04:04:04 +08: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-29 03:14:25 +08:00
|
|
|
cstat->control_requests++;
|
2017-02-13 05:52:32 +08:00
|
|
|
}
|
2019-08-15 07:57:10 +08:00
|
|
|
|
2022-06-04 01:43:28 +08:00
|
|
|
if (pnode->nlp_nvme_info & NLP_NVME_NSLER) {
|
2019-08-15 07:57:10 +08:00
|
|
|
bf_set(wqe_erp, &wqe->generic.wqe_com, 1);
|
2022-06-04 01:43:28 +08:00
|
|
|
sqe = &((struct nvme_fc_cmd_iu *)
|
|
|
|
nCmd->cmdaddr)->sqe.common;
|
|
|
|
if (sqe->opcode == nvme_admin_async_event)
|
|
|
|
bf_set(wqe_ffrq, &wqe->generic.wqe_com, 1);
|
|
|
|
}
|
|
|
|
|
2017-02-13 05:52:32 +08:00
|
|
|
/*
|
|
|
|
* Finish initializing those WQE fields that are independent
|
|
|
|
* of the nvme_cmnd request_buffer
|
|
|
|
*/
|
|
|
|
|
2018-03-06 04:04:04 +08:00
|
|
|
/* Word 3 */
|
|
|
|
bf_set(payload_offset_len, &wqe->fcp_icmd,
|
|
|
|
(nCmd->rsplen + nCmd->cmdlen));
|
|
|
|
|
2017-02-13 05:52:32 +08: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);
|
|
|
|
|
2020-11-16 03:26:40 +08:00
|
|
|
/* Word 10 */
|
|
|
|
bf_set(wqe_xchg, &wqe->fcp_iwrite.wqe_com, LPFC_NVME_XCHG);
|
|
|
|
|
2018-06-26 23:24:26 +08:00
|
|
|
/* Words 13 14 15 are for PBDE support */
|
|
|
|
|
2022-05-19 20:31:10 +08:00
|
|
|
/* add the VMID tags as per switch response */
|
|
|
|
if (unlikely(lpfc_ncmd->cur_iocbq.cmd_flag & LPFC_IO_VMID)) {
|
|
|
|
if (phba->pport->vmid_priority_tagging) {
|
|
|
|
bf_set(wqe_ccpe, &wqe->fcp_iwrite.wqe_com, 1);
|
|
|
|
bf_set(wqe_ccp, &wqe->fcp_iwrite.wqe_com,
|
|
|
|
lpfc_ncmd->cur_iocbq.vmid_tag.cs_ctl_vmid);
|
|
|
|
} else {
|
|
|
|
bf_set(wqe_appid, &wqe->fcp_iwrite.wqe_com, 1);
|
|
|
|
bf_set(wqe_wqes, &wqe->fcp_iwrite.wqe_com, 1);
|
|
|
|
wqe->words[31] = lpfc_ncmd->cur_iocbq.vmid_tag.app_id;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-02-13 05:52:32 +08:00
|
|
|
pwqeq->vport = vport;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* lpfc_nvme_prep_io_dma - Issue an NVME-over-FCP IO
|
2020-07-13 15:59:57 +08:00
|
|
|
* @vport: pointer to a host virtual N_Port data structure
|
2020-11-02 22:23:52 +08:00
|
|
|
* @lpfc_ncmd: Pointer to lpfc scsi command
|
2017-02-13 05:52:32 +08:00
|
|
|
*
|
|
|
|
* 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-29 03:14:28 +08:00
|
|
|
struct lpfc_io_buf *lpfc_ncmd)
|
2017-02-13 05:52:32 +08:00
|
|
|
{
|
|
|
|
struct lpfc_hba *phba = vport->phba;
|
|
|
|
struct nvmefc_fcp_req *nCmd = lpfc_ncmd->nvmeCmd;
|
2018-03-06 04:04:03 +08:00
|
|
|
union lpfc_wqe128 *wqe = &lpfc_ncmd->cur_iocbq.wqe;
|
2019-01-29 03:14:19 +08: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-15 07:57:09 +08:00
|
|
|
struct sli4_hybrid_sgl *sgl_xtra = NULL;
|
2017-02-13 05:52:32 +08:00
|
|
|
struct scatterlist *data_sg;
|
|
|
|
struct sli4_sge *first_data_sgl;
|
2018-02-23 00:18:48 +08: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-15 07:57:09 +08:00
|
|
|
dma_addr_t physaddr = 0;
|
|
|
|
uint32_t dma_len = 0;
|
2017-02-13 05:52:32 +08: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-15 07:57:09 +08:00
|
|
|
int nseg, i, j;
|
|
|
|
bool lsp_just_set = false;
|
2017-02-13 05:52:32 +08: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 08:00:43 +08:00
|
|
|
if (lpfc_ncmd->seg_cnt > lpfc_nvme_template.max_sgl_segments) {
|
2020-07-01 05:50:00 +08:00
|
|
|
lpfc_printf_log(phba, KERN_ERR, LOG_TRACE_EVENT,
|
2017-02-13 05:52:32 +08:00
|
|
|
"6058 Too many sg segments from "
|
|
|
|
"NVME Transport. Max %d, "
|
|
|
|
"nvmeIO sg_cnt %d\n",
|
2017-09-30 08:34:46 +08:00
|
|
|
phba->cfg_nvme_seg_cnt + 1,
|
2017-02-13 05:52:32 +08: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-15 07:57:09 +08:00
|
|
|
|
|
|
|
/* for tracking the segment boundaries */
|
|
|
|
j = 2;
|
2017-02-13 05:52:32 +08:00
|
|
|
for (i = 0; i < nseg; i++) {
|
|
|
|
if (data_sg == NULL) {
|
2020-07-01 05:50:00 +08:00
|
|
|
lpfc_printf_log(phba, KERN_ERR, LOG_TRACE_EVENT,
|
2017-02-13 05:52:32 +08:00
|
|
|
"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-15 07:57:09 +08:00
|
|
|
|
|
|
|
sgl->word2 = 0;
|
2021-09-11 07:31:58 +08:00
|
|
|
if (nseg == 1) {
|
2017-02-13 05:52:32 +08: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-15 07:57:09 +08:00
|
|
|
bf_set(lpfc_sli4_sge_type, sgl,
|
|
|
|
LPFC_SGE_TYPE_DATA);
|
|
|
|
} else {
|
2017-02-13 05:52:32 +08: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-15 07:57:09 +08: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);
|
|
|
|
|
2022-05-06 11:55:18 +08:00
|
|
|
physaddr = sg_dma_address(data_sg);
|
|
|
|
dma_len = sg_dma_len(data_sg);
|
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-15 07:57:09 +08:00
|
|
|
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-13 05:52:32 +08:00
|
|
|
}
|
2021-09-11 07:31:58 +08:00
|
|
|
|
|
|
|
/* PBDE support for first data SGE only */
|
|
|
|
if (nseg == 1 && phba->cfg_enable_pbde) {
|
2018-02-23 00:18:48 +08:00
|
|
|
/* 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);
|
2020-11-16 03:26:39 +08:00
|
|
|
|
2021-09-11 07:31:58 +08:00
|
|
|
/* Word 11 - set PBDE bit */
|
2020-11-16 03:26:39 +08:00
|
|
|
bf_set(wqe_pbde, &wqe->generic.wqe_com, 1);
|
2018-03-06 04:04:04 +08:00
|
|
|
} else {
|
|
|
|
memset(&wqe->words[13], 0, (sizeof(uint32_t) * 3));
|
2021-09-11 07:31:58 +08:00
|
|
|
/* Word 11 - PBDE bit disabled by default template */
|
2018-03-06 04:04:04 +08:00
|
|
|
}
|
2018-02-23 00:18:48 +08:00
|
|
|
|
2018-06-26 23:24:26 +08:00
|
|
|
} else {
|
2019-01-29 03:14:19 +08:00
|
|
|
lpfc_ncmd->seg_cnt = 0;
|
|
|
|
|
2017-02-13 05:52:32 +08:00
|
|
|
/* For this clause to be valid, the payload_length
|
|
|
|
* and sg_cnt must zero.
|
|
|
|
*/
|
|
|
|
if (nCmd->payload_length != 0) {
|
2020-07-01 05:50:00 +08:00
|
|
|
lpfc_printf_log(phba, KERN_ERR, LOG_TRACE_EVENT,
|
2017-02-13 05:52:32 +08:00
|
|
|
"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
|
2020-11-02 22:23:52 +08:00
|
|
|
* @pnvme_lport: Pointer to the driver's local port data
|
|
|
|
* @pnvme_rport: Pointer to the rport getting the @lpfc_nvme_ereq
|
2017-02-13 05:52:32 +08:00
|
|
|
* @hw_queue_handle: Driver-returned handle in lpfc_nvme_create_queue
|
2020-11-02 22:23:52 +08:00
|
|
|
* @pnvme_fcreq: IO request from nvme fc to driver.
|
2017-02-13 05:52:32 +08:00
|
|
|
*
|
|
|
|
* Driver registers this routine as it io request handler. This
|
|
|
|
* routine issues an fcp WQE with data from the @lpfc_nvme_fcpreq
|
2020-11-02 22:23:52 +08:00
|
|
|
* data structure to the rport indicated in @lpfc_nvme_rport.
|
2017-02-13 05:52:32 +08:00
|
|
|
*
|
|
|
|
* 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 09:18:03 +08:00
|
|
|
int expedite = 0;
|
2019-01-29 03:14:24 +08:00
|
|
|
int idx, cpu;
|
2017-02-13 05:52:32 +08:00
|
|
|
struct lpfc_nvme_lport *lport;
|
2019-01-29 03:14:25 +08:00
|
|
|
struct lpfc_fc4_ctrl_stat *cstat;
|
2017-02-13 05:52:32 +08: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-29 03:14:28 +08:00
|
|
|
struct lpfc_io_buf *lpfc_ncmd;
|
2017-02-13 05:52:32 +08:00
|
|
|
struct lpfc_nvme_rport *rport;
|
|
|
|
struct lpfc_nvme_qhandle *lpfc_queue_info;
|
2017-11-21 08:00:42 +08:00
|
|
|
struct lpfc_nvme_fcpreq_priv *freqpriv;
|
2017-12-09 09:18:03 +08:00
|
|
|
struct nvme_common_command *sqe;
|
2017-02-13 05:52:33 +08:00
|
|
|
uint64_t start = 0;
|
2022-05-19 20:31:10 +08:00
|
|
|
#if (IS_ENABLED(CONFIG_NVME_FC))
|
|
|
|
u8 *uuid = NULL;
|
|
|
|
int err;
|
|
|
|
enum dma_data_direction iodir;
|
|
|
|
#endif
|
2017-02-13 05:52:32 +08:00
|
|
|
|
2017-11-21 08:00:42 +08:00
|
|
|
/* Validate pointers. LLDD fault handling with transport does
|
|
|
|
* have timing races.
|
|
|
|
*/
|
2017-02-13 05:52:32 +08:00
|
|
|
lport = (struct lpfc_nvme_lport *)pnvme_lport->private;
|
2017-11-21 08:00:42 +08:00
|
|
|
if (unlikely(!lport)) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto out_fail;
|
|
|
|
}
|
|
|
|
|
2017-02-13 05:52:32 +08:00
|
|
|
vport = lport->vport;
|
2017-11-21 08:00:42 +08:00
|
|
|
|
|
|
|
if (unlikely(!hw_queue_handle)) {
|
2018-05-05 11:37:56 +08: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 11:37:50 +08:00
|
|
|
ret = -EBUSY;
|
2017-11-21 08:00:42 +08:00
|
|
|
goto out_fail;
|
|
|
|
}
|
|
|
|
|
2017-02-13 05:52:32 +08:00
|
|
|
phba = vport->phba;
|
|
|
|
|
2022-03-17 11:27:35 +08:00
|
|
|
if ((unlikely(vport->load_flag & FC_UNLOADING)) ||
|
|
|
|
phba->hba_flag & HBA_IOQ_FLUSH) {
|
2018-05-05 11:37:56 +08: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 08:00:41 +08:00
|
|
|
ret = -ENODEV;
|
|
|
|
goto out_fail;
|
|
|
|
}
|
|
|
|
|
2017-11-21 08:00:42 +08:00
|
|
|
freqpriv = pnvme_fcreq->private;
|
|
|
|
if (unlikely(!freqpriv)) {
|
2018-05-05 11:37:56 +08: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 08:00:42 +08:00
|
|
|
ret = -EINVAL;
|
2017-09-30 08:34:41 +08:00
|
|
|
goto out_fail;
|
|
|
|
}
|
|
|
|
|
2017-02-13 05:52:33 +08:00
|
|
|
#ifdef CONFIG_SCSI_LPFC_DEBUG_FS
|
|
|
|
if (phba->ktime_on)
|
|
|
|
start = ktime_get_ns();
|
|
|
|
#endif
|
2017-02-13 05:52:32 +08: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;
|
2020-11-16 03:26:30 +08:00
|
|
|
if (!ndlp) {
|
2018-05-05 11:37:56 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NODE | LOG_NVME_IOERR,
|
2019-08-15 07:57:06 +08:00
|
|
|
"6053 Busy IO, ndlp not ready: rport x%px "
|
|
|
|
"ndlp x%px, DID x%06x\n",
|
2017-02-13 05:52:32 +08:00
|
|
|
rport, ndlp, pnvme_rport->port_id);
|
2018-05-05 11:37:56 +08:00
|
|
|
atomic_inc(&lport->xmt_fcp_err);
|
|
|
|
ret = -EBUSY;
|
|
|
|
goto out_fail;
|
2017-02-13 05:52:32 +08: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 11:37:56 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NODE | LOG_NVME_IOERR,
|
|
|
|
"6036 Fail IO, DID x%06x not ready for "
|
2018-05-05 11:37:50 +08:00
|
|
|
"IO. State x%x, Type x%x Flg x%x\n",
|
2018-05-05 11:37:56 +08:00
|
|
|
pnvme_rport->port_id,
|
2018-05-05 11:37:50 +08:00
|
|
|
ndlp->nlp_state, ndlp->nlp_type,
|
2020-11-16 03:26:33 +08:00
|
|
|
ndlp->fc4_xpt_flags);
|
2017-12-09 09:18:10 +08:00
|
|
|
atomic_inc(&lport->xmt_fcp_bad_ndlp);
|
2018-05-05 11:37:50 +08:00
|
|
|
ret = -EBUSY;
|
2017-02-13 05:52:32 +08:00
|
|
|
goto out_fail;
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2017-12-09 09:18:03 +08: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;
|
|
|
|
}
|
|
|
|
|
2021-08-17 00:28:54 +08:00
|
|
|
/* Check if IO qualifies for CMF */
|
|
|
|
if (phba->cmf_active_mode != LPFC_CFG_OFF &&
|
|
|
|
pnvme_fcreq->io_dir == NVMEFC_FCP_READ &&
|
|
|
|
pnvme_fcreq->payload_length) {
|
|
|
|
ret = lpfc_update_cmf_cmd(phba, pnvme_fcreq->payload_length);
|
|
|
|
if (ret) {
|
|
|
|
ret = -EBUSY;
|
|
|
|
goto out_fail;
|
|
|
|
}
|
|
|
|
/* Get start time for IO latency */
|
|
|
|
start = ktime_get_ns();
|
|
|
|
}
|
|
|
|
|
2017-02-13 05:52:32 +08:00
|
|
|
/* The node is shared with FCP IO, make sure the IO pending count does
|
|
|
|
* not exceed the programmed depth.
|
|
|
|
*/
|
2018-08-01 08:23:22 +08: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;
|
2021-08-17 00:28:54 +08:00
|
|
|
goto out_fail1;
|
2018-08-01 08:23:22 +08:00
|
|
|
}
|
2017-02-13 05:52:32 +08:00
|
|
|
}
|
|
|
|
|
2019-01-29 03:14:31 +08:00
|
|
|
/* Lookup Hardware Queue index based on fcp_io_sched module parameter */
|
2019-01-29 03:14:29 +08:00
|
|
|
if (phba->cfg_fcp_io_sched == LPFC_FCP_SCHED_BY_HDWQ) {
|
|
|
|
idx = lpfc_queue_info->index;
|
|
|
|
} else {
|
2019-03-29 02:06:22 +08:00
|
|
|
cpu = raw_smp_processor_id();
|
2019-01-29 03:14:31 +08:00
|
|
|
idx = phba->sli4_hba.cpu_map[cpu].hdwq;
|
2019-01-29 03:14:29 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
lpfc_ncmd = lpfc_get_nvme_buf(phba, ndlp, idx, expedite);
|
2017-02-13 05:52:32 +08:00
|
|
|
if (lpfc_ncmd == NULL) {
|
2017-12-09 09:18:10 +08:00
|
|
|
atomic_inc(&lport->xmt_fcp_noxri);
|
2017-02-13 05:52:32 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_IOERR,
|
2018-05-05 11:37:56 +08:00
|
|
|
"6065 Fail IO, driver buffer pool is empty: "
|
|
|
|
"idx %d DID %x\n",
|
|
|
|
lpfc_queue_info->index, ndlp->nlp_DID);
|
2017-08-24 07:55:35 +08:00
|
|
|
ret = -EBUSY;
|
2021-08-17 00:28:54 +08:00
|
|
|
goto out_fail1;
|
2017-02-13 05:52:32 +08:00
|
|
|
}
|
2017-02-13 05:52:33 +08:00
|
|
|
#ifdef CONFIG_SCSI_LPFC_DEBUG_FS
|
2017-09-30 08:34:33 +08:00
|
|
|
if (start) {
|
2017-02-13 05:52:33 +08:00
|
|
|
lpfc_ncmd->ts_cmd_start = start;
|
|
|
|
lpfc_ncmd->ts_last_cmd = phba->ktime_last_cmd;
|
2017-09-30 08:34:33 +08:00
|
|
|
} else {
|
|
|
|
lpfc_ncmd->ts_cmd_start = 0;
|
2017-02-13 05:52:33 +08:00
|
|
|
}
|
|
|
|
#endif
|
2021-08-17 00:28:54 +08:00
|
|
|
lpfc_ncmd->rx_cmd_start = start;
|
2017-02-13 05:52:32 +08: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 08:49:08 +08:00
|
|
|
freqpriv->nvme_buf = lpfc_ncmd;
|
2017-02-13 05:52:32 +08:00
|
|
|
lpfc_ncmd->nvmeCmd = pnvme_fcreq;
|
2017-03-05 01:30:30 +08:00
|
|
|
lpfc_ncmd->ndlp = ndlp;
|
2019-01-29 03:14:19 +08:00
|
|
|
lpfc_ncmd->qidx = lpfc_queue_info->qidx;
|
2017-02-13 05:52:32 +08:00
|
|
|
|
2022-05-19 20:31:10 +08:00
|
|
|
#if (IS_ENABLED(CONFIG_NVME_FC))
|
|
|
|
/* check the necessary and sufficient condition to support VMID */
|
|
|
|
if (lpfc_is_vmid_enabled(phba) &&
|
|
|
|
(ndlp->vmid_support ||
|
|
|
|
phba->pport->vmid_priority_tagging ==
|
|
|
|
LPFC_VMID_PRIO_TAG_ALL_TARGETS)) {
|
|
|
|
/* is the I/O generated by a VM, get the associated virtual */
|
|
|
|
/* entity id */
|
|
|
|
uuid = nvme_fc_io_getuuid(pnvme_fcreq);
|
|
|
|
|
|
|
|
if (uuid) {
|
|
|
|
if (pnvme_fcreq->io_dir == NVMEFC_FCP_WRITE)
|
|
|
|
iodir = DMA_TO_DEVICE;
|
|
|
|
else if (pnvme_fcreq->io_dir == NVMEFC_FCP_READ)
|
|
|
|
iodir = DMA_FROM_DEVICE;
|
|
|
|
else
|
|
|
|
iodir = DMA_NONE;
|
|
|
|
|
|
|
|
err = lpfc_vmid_get_appid(vport, uuid, iodir,
|
|
|
|
(union lpfc_vmid_io_tag *)
|
|
|
|
&lpfc_ncmd->cur_iocbq.vmid_tag);
|
|
|
|
if (!err)
|
|
|
|
lpfc_ncmd->cur_iocbq.cmd_flag |= LPFC_IO_VMID;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2017-02-13 05:52:32 +08: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-10 05:24:23 +08:00
|
|
|
lpfc_ncmd->cur_iocbq.hba_wqidx = idx;
|
2019-01-29 03:14:25 +08:00
|
|
|
cstat = &phba->sli4_hba.hdwq[idx].nvme_cstat;
|
2018-04-10 05:24:23 +08: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 11:37:56 +08: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-10 05:24:23 +08:00
|
|
|
ret = -ENOMEM;
|
|
|
|
goto out_free_nvme_buf;
|
|
|
|
}
|
|
|
|
|
2017-02-13 05:52:33 +08: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-29 03:14:26 +08:00
|
|
|
ret = lpfc_sli4_issue_wqe(phba, lpfc_ncmd->hdwq, &lpfc_ncmd->cur_iocbq);
|
2017-02-13 05:52:32 +08:00
|
|
|
if (ret) {
|
2017-12-09 09:18:10 +08:00
|
|
|
atomic_inc(&lport->xmt_fcp_wqerr);
|
2017-09-30 08:34:36 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_IOERR,
|
2018-05-05 11:37:56 +08:00
|
|
|
"6113 Fail IO, Could not issue WQE err %x "
|
2017-02-13 05:52:32 +08: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-29 03:14:28 +08:00
|
|
|
if (phba->cfg_xri_rebalancing)
|
|
|
|
lpfc_keep_pvt_pool_above_lowwm(phba, lpfc_ncmd->hdwq_no);
|
|
|
|
|
2017-02-13 05:52:33 +08:00
|
|
|
#ifdef CONFIG_SCSI_LPFC_DEBUG_FS
|
2017-09-30 08:34:33 +08:00
|
|
|
if (lpfc_ncmd->ts_cmd_start)
|
2017-02-13 05:52:33 +08:00
|
|
|
lpfc_ncmd->ts_cmd_wqput = ktime_get_ns();
|
|
|
|
|
2020-03-23 02:13:00 +08:00
|
|
|
if (phba->hdwqstat_on & LPFC_CHECK_NVME_IO) {
|
2019-03-29 02:06:22 +08:00
|
|
|
cpu = raw_smp_processor_id();
|
2020-03-23 02:13:00 +08: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-13 05:52:33 +08:00
|
|
|
}
|
|
|
|
#endif
|
2017-02-13 05:52:32 +08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
out_free_nvme_buf:
|
2017-06-02 12:07:02 +08:00
|
|
|
if (lpfc_ncmd->nvmeCmd->sg_cnt) {
|
|
|
|
if (lpfc_ncmd->nvmeCmd->io_dir == NVMEFC_FCP_WRITE)
|
2019-01-29 03:14:25 +08:00
|
|
|
cstat->output_requests--;
|
2017-06-02 12:07:02 +08:00
|
|
|
else
|
2019-01-29 03:14:25 +08:00
|
|
|
cstat->input_requests--;
|
2017-06-02 12:07:02 +08:00
|
|
|
} else
|
2019-01-29 03:14:25 +08:00
|
|
|
cstat->control_requests--;
|
2017-02-13 05:52:32 +08:00
|
|
|
lpfc_release_nvme_buf(phba, lpfc_ncmd);
|
2021-08-17 00:28:54 +08:00
|
|
|
out_fail1:
|
|
|
|
lpfc_update_cmf_cmpl(phba, LPFC_CGN_NOT_SENT,
|
|
|
|
pnvme_fcreq->payload_length, NULL);
|
2017-02-13 05:52:32 +08:00
|
|
|
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.
|
2022-06-04 01:43:22 +08:00
|
|
|
* @rspiocb: Pointer to response iocb object.
|
2017-02-13 05:52:32 +08:00
|
|
|
*
|
|
|
|
* 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,
|
2022-06-04 01:43:22 +08:00
|
|
|
struct lpfc_iocbq *rspiocb)
|
2017-02-13 05:52:32 +08:00
|
|
|
{
|
2022-06-04 01:43:22 +08:00
|
|
|
struct lpfc_wcqe_complete *abts_cmpl = &rspiocb->wcqe_cmpl;
|
|
|
|
|
2017-09-30 08:34:36 +08:00
|
|
|
lpfc_printf_log(phba, KERN_INFO, LOG_NVME,
|
2017-02-13 05:52:32 +08: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",
|
2022-02-25 10:23:05 +08:00
|
|
|
bf_get(wqe_ctxt_tag, &cmdiocb->wqe.generic.wqe_com),
|
|
|
|
get_job_abtsiotag(phba, cmdiocb), cmdiocb->iotag,
|
2017-02-13 05:52:32 +08:00
|
|
|
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
|
2020-11-02 22:23:52 +08:00
|
|
|
* @pnvme_lport: Pointer to the driver's local port data
|
|
|
|
* @pnvme_rport: Pointer to the rport getting the @lpfc_nvme_ereq
|
2017-02-13 05:52:32 +08:00
|
|
|
* @hw_queue_handle: Driver-returned handle in lpfc_nvme_create_queue
|
2020-11-02 22:23:52 +08:00
|
|
|
* @pnvme_fcreq: IO request from nvme fc to driver.
|
2017-02-13 05:52:32 +08:00
|
|
|
*
|
|
|
|
* 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-29 03:14:28 +08:00
|
|
|
struct lpfc_io_buf *lpfc_nbuf;
|
2017-02-13 05:52:32 +08:00
|
|
|
struct lpfc_iocbq *nvmereq_wqe;
|
2017-11-21 08:00:42 +08:00
|
|
|
struct lpfc_nvme_fcpreq_priv *freqpriv;
|
2017-02-13 05:52:32 +08:00
|
|
|
unsigned long flags;
|
|
|
|
int ret_val;
|
2022-06-04 01:43:27 +08:00
|
|
|
struct nvme_fc_cmd_iu *cp;
|
2017-02-13 05:52:32 +08:00
|
|
|
|
2017-11-21 08:00:42 +08:00
|
|
|
/* Validate pointers. LLDD fault handling with transport does
|
|
|
|
* have timing races.
|
|
|
|
*/
|
2017-02-13 05:52:32 +08:00
|
|
|
lport = (struct lpfc_nvme_lport *)pnvme_lport->private;
|
2017-11-21 08:00:42 +08:00
|
|
|
if (unlikely(!lport))
|
|
|
|
return;
|
|
|
|
|
2017-02-13 05:52:32 +08:00
|
|
|
vport = lport->vport;
|
2017-11-21 08:00:42 +08: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-13 05:52:32 +08:00
|
|
|
phba = vport->phba;
|
2017-11-21 08:00:42 +08:00
|
|
|
freqpriv = pnvme_fcreq->private;
|
2017-02-13 05:52:32 +08:00
|
|
|
|
2017-11-21 08:00:42 +08:00
|
|
|
if (unlikely(!freqpriv))
|
|
|
|
return;
|
2017-11-21 08:00:41 +08:00
|
|
|
if (vport->load_flag & FC_UNLOADING)
|
|
|
|
return;
|
|
|
|
|
2017-02-13 05:52:32 +08: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-22 07:05:04 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_ABTS,
|
2017-02-13 05:52:32 +08:00
|
|
|
"6002 Abort Request to rport DID x%06x "
|
2019-08-15 07:57:06 +08:00
|
|
|
"for nvme_fc_req x%px\n",
|
2017-02-13 05:52:32 +08:00
|
|
|
pnvme_rport->port_id,
|
|
|
|
pnvme_fcreq);
|
|
|
|
|
2017-04-22 08:49:08 +08:00
|
|
|
lpfc_nbuf = freqpriv->nvme_buf;
|
2017-02-13 05:52:32 +08:00
|
|
|
if (!lpfc_nbuf) {
|
2020-07-01 05:50:00 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_TRACE_EVENT,
|
2017-02-13 05:52:32 +08:00
|
|
|
"6140 NVME IO req has no matching lpfc nvme "
|
|
|
|
"io buffer. Skipping abort req.\n");
|
|
|
|
return;
|
|
|
|
} else if (!lpfc_nbuf->nvmeCmd) {
|
2020-07-01 05:50:00 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_TRACE_EVENT,
|
2017-02-13 05:52:32 +08:00
|
|
|
"6141 lpfc NVME IO req has no nvme_fcreq "
|
|
|
|
"io buffer. Skipping abort req.\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2019-01-29 03:14:37 +08:00
|
|
|
/* Guard against IO completion being called at same time */
|
2023-04-18 03:15:54 +08:00
|
|
|
spin_lock_irqsave(&lpfc_nbuf->buf_lock, flags);
|
|
|
|
|
|
|
|
/* If the hba is getting reset, this flag is set. It is
|
|
|
|
* cleared when the reset is complete and rings reestablished.
|
|
|
|
*/
|
|
|
|
spin_lock(&phba->hbalock);
|
|
|
|
/* driver queued commands are in process of being flushed */
|
|
|
|
if (phba->hba_flag & HBA_IOQ_FLUSH) {
|
|
|
|
spin_unlock(&phba->hbalock);
|
|
|
|
spin_unlock_irqrestore(&lpfc_nbuf->buf_lock, flags);
|
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_TRACE_EVENT,
|
|
|
|
"6139 Driver in reset cleanup - flushing "
|
|
|
|
"NVME Req now. hba_flag x%x\n",
|
|
|
|
phba->hba_flag);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
nvmereq_wqe = &lpfc_nbuf->cur_iocbq;
|
2019-01-29 03:14:37 +08:00
|
|
|
|
2017-02-13 05:52:32 +08: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) {
|
2020-07-01 05:50:00 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_TRACE_EVENT,
|
2017-02-13 05:52:32 +08:00
|
|
|
"6143 NVME req mismatch: "
|
2019-08-15 07:57:06 +08:00
|
|
|
"lpfc_nbuf x%px nvmeCmd x%px, "
|
|
|
|
"pnvme_fcreq x%px. Skipping Abort xri x%x\n",
|
2017-02-13 05:52:32 +08:00
|
|
|
lpfc_nbuf, lpfc_nbuf->nvmeCmd,
|
2017-04-22 07:04:59 +08:00
|
|
|
pnvme_fcreq, nvmereq_wqe->sli4_xritag);
|
2019-01-29 03:14:37 +08:00
|
|
|
goto out_unlock;
|
2017-02-13 05:52:32 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Don't abort IOs no longer on the pending queue. */
|
2022-02-25 10:22:52 +08:00
|
|
|
if (!(nvmereq_wqe->cmd_flag & LPFC_IO_ON_TXCMPLQ)) {
|
2020-07-01 05:50:00 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_TRACE_EVENT,
|
2019-08-15 07:57:06 +08:00
|
|
|
"6142 NVME IO req x%px not queued - skipping "
|
2017-04-22 07:04:59 +08:00
|
|
|
"abort req xri x%x\n",
|
|
|
|
pnvme_fcreq, nvmereq_wqe->sli4_xritag);
|
2019-01-29 03:14:37 +08:00
|
|
|
goto out_unlock;
|
2017-02-13 05:52:32 +08:00
|
|
|
}
|
|
|
|
|
2017-12-09 09:18:10 +08:00
|
|
|
atomic_inc(&lport->xmt_fcp_abort);
|
2017-02-13 05:52:33 +08:00
|
|
|
lpfc_nvmeio_data(phba, "NVME FCP ABORT: xri x%x idx %d to %06x\n",
|
|
|
|
nvmereq_wqe->sli4_xritag,
|
2017-06-22 01:37:58 +08:00
|
|
|
nvmereq_wqe->hba_wqidx, pnvme_rport->port_id);
|
2017-02-13 05:52:33 +08:00
|
|
|
|
2017-02-13 05:52:32 +08:00
|
|
|
/* Outstanding abort is in progress */
|
2022-02-25 10:22:52 +08:00
|
|
|
if (nvmereq_wqe->cmd_flag & LPFC_DRIVER_ABORTED) {
|
2020-07-01 05:50:00 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_TRACE_EVENT,
|
2017-02-13 05:52:32 +08:00
|
|
|
"6144 Outstanding NVME I/O Abort Request "
|
2019-08-15 07:57:06 +08:00
|
|
|
"still pending on nvme_fcreq x%px, "
|
2021-04-12 09:31:24 +08:00
|
|
|
"lpfc_ncmd x%px xri x%x\n",
|
2017-04-22 07:04:59 +08:00
|
|
|
pnvme_fcreq, lpfc_nbuf,
|
|
|
|
nvmereq_wqe->sli4_xritag);
|
2019-01-29 03:14:37 +08:00
|
|
|
goto out_unlock;
|
2017-02-13 05:52:32 +08:00
|
|
|
}
|
|
|
|
|
2020-11-16 03:26:44 +08:00
|
|
|
ret_val = lpfc_sli4_issue_abort_iotag(phba, nvmereq_wqe,
|
|
|
|
lpfc_nvme_abort_fcreq_cmpl);
|
2017-02-13 05:52:32 +08:00
|
|
|
|
2023-04-18 03:15:54 +08:00
|
|
|
spin_unlock(&phba->hbalock);
|
|
|
|
spin_unlock_irqrestore(&lpfc_nbuf->buf_lock, flags);
|
scsi: lpfc: Implement health checking when aborting I/O
Several errors have occurred where the adapter stops or fails but does not
raise the register values for the driver to detect failure. Thus driver is
unaware of the failure. The failure typically results in I/O timeouts, the
I/O timeout handler failing (after several seconds), and the error handler
escalating recovery policy and resulting in more errors. Eventually, the
driver is in a position where things have spiraled and it can't do recovery
because other recovery ops are still outstanding and it becomes unusable.
Resolve the situation by having the I/O timeout handler (actually a els,
SCSI I/O, NVMe ls, or NVMe I/O timeout), in addition to aborting the I/O,
perform a mailbox command and look for a response from the hardware. If
the mailbox command fails, it will mark the adapter offline and then invoke
the adapter reset handler to clean up.
The new I/O timeout test will be limited to a test every 5s. If there are
multiple I/O timeouts concurrently, only the 1st I/O timeout will generate
the mailbox command. Further testing will only occur once a timeout occurs
after a 5s delay from the last mailbox command has expired.
Link: https://lore.kernel.org/r/20210104180240.46824-14-jsmart2021@gmail.com
Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
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>
2021-01-05 02:02:38 +08:00
|
|
|
|
|
|
|
/* Make sure HBA is alive */
|
|
|
|
lpfc_issue_hb_tmo(phba);
|
|
|
|
|
2020-11-16 03:26:44 +08:00
|
|
|
if (ret_val != WQE_SUCCESS) {
|
2020-07-01 05:50:00 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_TRACE_EVENT,
|
2017-02-13 05:52:32 +08:00
|
|
|
"6137 Failed abts issue_wqe with status x%x "
|
2019-08-15 07:57:06 +08:00
|
|
|
"for nvme_fcreq x%px.\n",
|
2017-02-13 05:52:32 +08:00
|
|
|
ret_val, pnvme_fcreq);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2022-06-04 01:43:27 +08:00
|
|
|
/*
|
|
|
|
* 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 *)lpfc_nbuf->nvmeCmd->cmdaddr;
|
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-22 07:05:04 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_ABTS,
|
2017-04-22 07:04:59 +08:00
|
|
|
"6138 Transport Abort NVME Request Issued for "
|
2022-06-04 01:43:27 +08:00
|
|
|
"ox_id x%x nvme opcode x%x nvme cmd_id x%x\n",
|
|
|
|
nvmereq_wqe->sli4_xritag, cp->sqe.common.opcode,
|
|
|
|
cp->sqe.common.command_id);
|
2019-01-29 03:14:37 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
out_unlock:
|
2023-04-18 03:15:54 +08:00
|
|
|
spin_unlock(&phba->hbalock);
|
|
|
|
spin_unlock_irqrestore(&lpfc_nbuf->buf_lock, flags);
|
2019-01-29 03:14:37 +08:00
|
|
|
return;
|
2017-02-13 05:52:32 +08: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,
|
2020-04-01 00:50:09 +08:00
|
|
|
.xmt_ls_rsp = lpfc_nvme_xmt_ls_rsp,
|
2017-02-13 05:52:32 +08:00
|
|
|
|
|
|
|
.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 08:49:08 +08:00
|
|
|
.fcprqst_priv_sz = sizeof(struct lpfc_nvme_fcpreq_priv),
|
2017-02-13 05:52:32 +08:00
|
|
|
};
|
|
|
|
|
2020-11-02 22:23:52 +08:00
|
|
|
/*
|
2019-01-29 03:14:22 +08:00
|
|
|
* lpfc_get_nvme_buf - Get a nvme buffer from io_buf_list of the HBA
|
2017-02-13 05:52:32 +08:00
|
|
|
*
|
2019-01-29 03:14:22 +08:00
|
|
|
* This routine removes a nvme buffer from head of @hdwq io_buf_list
|
2017-02-13 05:52:32 +08: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-29 03:14:28 +08:00
|
|
|
static struct lpfc_io_buf *
|
2017-12-09 09:18:03 +08:00
|
|
|
lpfc_get_nvme_buf(struct lpfc_hba *phba, struct lpfc_nodelist *ndlp,
|
2019-01-29 03:14:22 +08:00
|
|
|
int idx, int expedite)
|
2017-02-13 05:52:32 +08: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-29 03:14:28 +08:00
|
|
|
struct lpfc_io_buf *lpfc_ncmd;
|
2019-01-29 03:14:22 +08:00
|
|
|
struct lpfc_sli4_hdw_queue *qp;
|
2019-01-29 03:14:19 +08:00
|
|
|
struct sli4_sge *sgl;
|
2017-02-13 05:52:32 +08: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-29 03:14:28 +08:00
|
|
|
lpfc_ncmd = lpfc_get_io_buf(phba, NULL, idx, expedite);
|
2018-08-01 08:23:22 +08:00
|
|
|
|
2019-01-29 03:14:19 +08:00
|
|
|
if (lpfc_ncmd) {
|
2017-02-13 05:52:32 +08:00
|
|
|
pwqeq = &(lpfc_ncmd->cur_iocbq);
|
2018-03-06 04:04:03 +08:00
|
|
|
wqe = &pwqeq->wqe;
|
2017-02-13 05:52:32 +08:00
|
|
|
|
2019-01-29 03:14:19 +08:00
|
|
|
/* Setup key fields in buffer that may have been changed
|
|
|
|
* if other protocols used this buffer.
|
|
|
|
*/
|
2022-02-25 10:22:52 +08:00
|
|
|
pwqeq->cmd_flag = LPFC_IO_NVME;
|
|
|
|
pwqeq->cmd_cmpl = lpfc_nvme_io_cmd_cmpl;
|
2019-01-29 03:14:19 +08:00
|
|
|
lpfc_ncmd->start_time = jiffies;
|
|
|
|
lpfc_ncmd->flags = 0;
|
2017-02-13 05:52:32 +08: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-29 03:14:19 +08:00
|
|
|
sgl = lpfc_ncmd->dma_sgl;
|
2017-02-13 05:52:32 +08: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-15 07:57:04 +08:00
|
|
|
/* Initialize 64 bytes only */
|
2018-03-06 04:04:04 +08:00
|
|
|
memset(wqe, 0, sizeof(union lpfc_wqe));
|
2017-02-13 05:52:32 +08:00
|
|
|
|
2019-01-29 03:14:19 +08: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-29 03:14:28 +08:00
|
|
|
lpfc_ncmd->flags |= LPFC_SBUF_BUMP_QDEPTH;
|
2019-01-29 03:14:19 +08:00
|
|
|
}
|
2017-02-13 05:52:32 +08: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-29 03:14:28 +08:00
|
|
|
} else {
|
|
|
|
qp = &phba->sli4_hba.hdwq[idx];
|
2019-01-29 03:14:22 +08:00
|
|
|
qp->empty_io_bufs++;
|
2017-02-13 05:52:32 +08:00
|
|
|
}
|
2018-08-01 08:23:22 +08:00
|
|
|
|
2017-02-13 05:52:32 +08: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-29 03:14:22 +08:00
|
|
|
* lpfc_io_buf_list list. For SLI4 XRI's are tied to the nvme buffer
|
2017-02-13 05:52:32 +08: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-29 03:14:28 +08:00
|
|
|
lpfc_release_nvme_buf(struct lpfc_hba *phba, struct lpfc_io_buf *lpfc_ncmd)
|
2017-02-13 05:52:32 +08:00
|
|
|
{
|
2019-01-29 03:14:22 +08:00
|
|
|
struct lpfc_sli4_hdw_queue *qp;
|
2017-02-13 05:52:32 +08: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-29 03:14:28 +08:00
|
|
|
if ((lpfc_ncmd->flags & LPFC_SBUF_BUMP_QDEPTH) && lpfc_ncmd->ndlp)
|
2018-08-01 08:23:22 +08: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-29 03:14:28 +08:00
|
|
|
lpfc_ncmd->flags &= ~LPFC_SBUF_BUMP_QDEPTH;
|
2018-08-01 08:23:22 +08:00
|
|
|
|
2019-01-29 03:14:26 +08:00
|
|
|
qp = lpfc_ncmd->hdwq;
|
2019-10-19 05:18:24 +08: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-22 07:05:04 +08: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-15 07:57:11 +08:00
|
|
|
spin_lock_irqsave(&qp->abts_io_buf_list_lock, iflag);
|
2017-02-13 05:52:32 +08:00
|
|
|
list_add_tail(&lpfc_ncmd->list,
|
2019-08-15 07:57:11 +08:00
|
|
|
&qp->lpfc_abts_io_buf_list);
|
2019-01-29 03:14:22 +08:00
|
|
|
qp->abts_nvme_io_bufs++;
|
2019-08-15 07:57:11 +08: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-29 03:14:28 +08:00
|
|
|
} else
|
|
|
|
lpfc_release_io_buf(phba, (struct lpfc_io_buf *)lpfc_ncmd, qp);
|
2017-02-13 05:52:32 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* lpfc_nvme_create_localport - Create/Bind an nvme localport instance.
|
2021-03-12 17:47:23 +08:00
|
|
|
* @vport: the lpfc_vport instance requesting a localport.
|
2017-02-13 05:52:32 +08:00
|
|
|
*
|
|
|
|
* 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-05 01:30:33 +08:00
|
|
|
int ret = 0;
|
2017-02-13 05:52:32 +08: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-11 01:30:42 +08: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-22 07:05:01 +08:00
|
|
|
*/
|
|
|
|
lpfc_nvme_template.max_sgl_segments = phba->cfg_nvme_seg_cnt + 1;
|
2017-02-13 05:52:32 +08:00
|
|
|
|
2019-11-12 07:04:00 +08: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-10 05:24:23 +08:00
|
|
|
|
2019-03-22 22:25:49 +08:00
|
|
|
if (!IS_ENABLED(CONFIG_NVME_FC))
|
|
|
|
return ret;
|
|
|
|
|
2017-02-13 05:52:32 +08:00
|
|
|
/* localport is allocated from the stack, but the registration
|
|
|
|
* call allocates heap memory as well as the private area.
|
|
|
|
*/
|
2019-03-22 22:25:49 +08:00
|
|
|
|
2017-02-13 05:52:32 +08: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-15 07:57:06 +08:00
|
|
|
"NVME port num %d, localP x%px, private "
|
|
|
|
"x%px, sg_seg %d\n",
|
2017-02-13 05:52:32 +08: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-24 07:55:45 +08:00
|
|
|
|
2017-12-09 09:18:10 +08: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 11:37:56 +08:00
|
|
|
atomic_set(&lport->xmt_fcp_err, 0);
|
2017-12-09 09:18:10 +08: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);
|
2020-04-01 00:50:09 +08:00
|
|
|
|
2018-04-10 05:24:23 +08:00
|
|
|
atomic_set(&lport->fc4NvmeLsRequests, 0);
|
|
|
|
atomic_set(&lport->fc4NvmeLsCmpls, 0);
|
2017-02-13 05:52:32 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2019-04-06 00:14:10 +08:00
|
|
|
#if (IS_ENABLED(CONFIG_NVME_FC))
|
2017-11-21 08:00:40 +08: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-29 02:06:16 +08:00
|
|
|
static void
|
2017-11-21 08:00:40 +08:00
|
|
|
lpfc_nvme_lport_unreg_wait(struct lpfc_vport *vport,
|
2019-01-18 00:14:44 +08:00
|
|
|
struct lpfc_nvme_lport *lport,
|
|
|
|
struct completion *lport_unreg_cmp)
|
2017-11-21 08:00:40 +08:00
|
|
|
{
|
|
|
|
u32 wait_tmo;
|
2019-05-22 08:48:54 +08:00
|
|
|
int ret, i, pending = 0;
|
|
|
|
struct lpfc_sli_ring *pring;
|
|
|
|
struct lpfc_hba *phba = vport->phba;
|
2020-10-21 04:27:12 +08:00
|
|
|
struct lpfc_sli4_hdw_queue *qp;
|
|
|
|
int abts_scsi, abts_nvme;
|
2017-11-21 08:00:40 +08: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-18 00:14:44 +08:00
|
|
|
ret = wait_for_completion_timeout(lport_unreg_cmp, wait_tmo);
|
2017-11-21 08:00:40 +08:00
|
|
|
if (unlikely(!ret)) {
|
2019-05-22 08:48:54 +08:00
|
|
|
pending = 0;
|
2020-10-21 04:27:12 +08:00
|
|
|
abts_scsi = 0;
|
|
|
|
abts_nvme = 0;
|
2019-05-22 08:48:54 +08:00
|
|
|
for (i = 0; i < phba->cfg_hdw_queue; i++) {
|
2020-10-21 04:27:12 +08:00
|
|
|
qp = &phba->sli4_hba.hdwq[i];
|
2022-03-17 11:27:34 +08:00
|
|
|
if (!vport->localport || !qp || !qp->io_wq)
|
scsi: lpfc: Fix EEH support for NVMe I/O
Injecting errors on the PCI slot while the driver is handling NVMe I/O will
cause crashes and hangs.
There are several rather difficult scenarios occurring. The main issue is
that the adapter can report a PCI error before or simultaneously to the PCI
subsystem reporting the error. Both paths have different entry points and
currently there is no interlock between them. Thus multiple teardown paths
are competing and all heck breaks loose.
Complicating things is the NVMs path. To a large degree, I/O was able to be
shutdown for a full FC port on the SCSI stack. But on NVMe, there isn't a
similar call. At best, it works on a per-controller basis, but even at the
controller level, it's a controller "reset" call. All of which means I/O is
still flowing on different CPUs with reset paths expecting hw access
(mailbox commands) to execute properly.
The following modifications are made:
- A new flag is set in PCI error entrypoints so the driver can track being
called by that path.
- An interlock is added in the SLI hw error path and the PCI error path
such that only one of the paths proceeds with the teardown logic.
- RPI cleanup is patched such that RPIs are marked unregistered w/o mbx
cmds in cases of hw error.
- If entering the SLI port re-init calls, a case where SLI error teardown
was quick and beat the PCI calls now reporting error, check whether the
SLI port is still live on the PCI bus.
- In the PCI reset code to bring the adapter back, recheck the IRQ
settings. Different checks for SLI3 vs SLI4.
- In I/O completions, that may be called as part of the cleanup or
underway just before the hw error, check the state of the adapter. If
in error, shortcut handling that would expect further adapter
completions as the hw error won't be sending them.
- In routines waiting on I/O completions, which may have been in progress
prior to the hw error, detect the device is being torn down and abort
from their waits and just give up. This points to a larger issue in the
driver on ref-counting for data structures, as it doesn't have
ref-counting on q and port structures. We'll do this fix for now as it
would be a major rework to be done differently.
- Fix the NVMe cleanup to simulate NVMe I/O completions if I/O is being
failed back due to hw error.
- In I/O buf allocation, done at the start of new I/Os, check hw state and
fail if hw error.
Link: https://lore.kernel.org/r/20210910233159.115896-10-jsmart2021@gmail.com
Co-developed-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-09-11 07:31:54 +08:00
|
|
|
return;
|
|
|
|
|
2020-10-21 04:27:12 +08:00
|
|
|
pring = qp->io_wq->pring;
|
2019-05-22 08:48:54 +08:00
|
|
|
if (!pring)
|
|
|
|
continue;
|
2020-10-21 04:27:12 +08:00
|
|
|
pending += pring->txcmplq_cnt;
|
|
|
|
abts_scsi += qp->abts_scsi_io_bufs;
|
|
|
|
abts_nvme += qp->abts_nvme_io_bufs;
|
2019-05-22 08:48:54 +08:00
|
|
|
}
|
2022-03-17 11:27:34 +08:00
|
|
|
if (!vport->localport ||
|
|
|
|
test_bit(HBA_PCI_ERR, &vport->phba->bit_flags) ||
|
2023-03-02 07:16:23 +08:00
|
|
|
phba->link_state == LPFC_HBA_ERROR ||
|
2022-03-17 11:27:34 +08:00
|
|
|
vport->load_flag & FC_UNLOADING)
|
scsi: lpfc: Fix EEH support for NVMe I/O
Injecting errors on the PCI slot while the driver is handling NVMe I/O will
cause crashes and hangs.
There are several rather difficult scenarios occurring. The main issue is
that the adapter can report a PCI error before or simultaneously to the PCI
subsystem reporting the error. Both paths have different entry points and
currently there is no interlock between them. Thus multiple teardown paths
are competing and all heck breaks loose.
Complicating things is the NVMs path. To a large degree, I/O was able to be
shutdown for a full FC port on the SCSI stack. But on NVMe, there isn't a
similar call. At best, it works on a per-controller basis, but even at the
controller level, it's a controller "reset" call. All of which means I/O is
still flowing on different CPUs with reset paths expecting hw access
(mailbox commands) to execute properly.
The following modifications are made:
- A new flag is set in PCI error entrypoints so the driver can track being
called by that path.
- An interlock is added in the SLI hw error path and the PCI error path
such that only one of the paths proceeds with the teardown logic.
- RPI cleanup is patched such that RPIs are marked unregistered w/o mbx
cmds in cases of hw error.
- If entering the SLI port re-init calls, a case where SLI error teardown
was quick and beat the PCI calls now reporting error, check whether the
SLI port is still live on the PCI bus.
- In the PCI reset code to bring the adapter back, recheck the IRQ
settings. Different checks for SLI3 vs SLI4.
- In I/O completions, that may be called as part of the cleanup or
underway just before the hw error, check the state of the adapter. If
in error, shortcut handling that would expect further adapter
completions as the hw error won't be sending them.
- In routines waiting on I/O completions, which may have been in progress
prior to the hw error, detect the device is being torn down and abort
from their waits and just give up. This points to a larger issue in the
driver on ref-counting for data structures, as it doesn't have
ref-counting on q and port structures. We'll do this fix for now as it
would be a major rework to be done differently.
- Fix the NVMe cleanup to simulate NVMe I/O completions if I/O is being
failed back due to hw error.
- In I/O buf allocation, done at the start of new I/Os, check hw state and
fail if hw error.
Link: https://lore.kernel.org/r/20210910233159.115896-10-jsmart2021@gmail.com
Co-developed-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-09-11 07:31:54 +08:00
|
|
|
return;
|
|
|
|
|
2020-07-01 05:50:00 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_TRACE_EVENT,
|
2019-08-15 07:57:06 +08:00
|
|
|
"6176 Lport x%px Localport x%px wait "
|
2020-10-21 04:27:12 +08:00
|
|
|
"timed out. Pending %d [%d:%d]. "
|
|
|
|
"Renewing.\n",
|
|
|
|
lport, vport->localport, pending,
|
|
|
|
abts_scsi, abts_nvme);
|
2017-11-21 08:00:40 +08:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_IOERR,
|
2019-08-15 07:57:06 +08:00
|
|
|
"6177 Lport x%px Localport x%px Complete Success\n",
|
2017-11-21 08:00:40 +08:00
|
|
|
lport, vport->localport);
|
|
|
|
}
|
2019-04-06 00:14:10 +08:00
|
|
|
#endif
|
2017-11-21 08:00:40 +08:00
|
|
|
|
2017-02-13 05:52:32 +08:00
|
|
|
/**
|
|
|
|
* lpfc_nvme_destroy_localport - Destroy lpfc_nvme bound to nvme transport.
|
2020-11-02 22:23:52 +08:00
|
|
|
* @vport: pointer to a host virtual N_Port data structure
|
2017-02-13 05:52:32 +08:00
|
|
|
*
|
|
|
|
* 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-09 06:36:01 +08:00
|
|
|
#if (IS_ENABLED(CONFIG_NVME_FC))
|
2017-02-13 05:52:32 +08:00
|
|
|
struct nvme_fc_local_port *localport;
|
|
|
|
struct lpfc_nvme_lport *lport;
|
|
|
|
int ret;
|
2019-01-18 00:14:44 +08:00
|
|
|
DECLARE_COMPLETION_ONSTACK(lport_unreg_cmp);
|
2017-02-13 05:52:32 +08:00
|
|
|
|
|
|
|
if (vport->nvmei_support == 0)
|
|
|
|
return;
|
|
|
|
|
|
|
|
localport = vport->localport;
|
scsi: lpfc: Fix EEH support for NVMe I/O
Injecting errors on the PCI slot while the driver is handling NVMe I/O will
cause crashes and hangs.
There are several rather difficult scenarios occurring. The main issue is
that the adapter can report a PCI error before or simultaneously to the PCI
subsystem reporting the error. Both paths have different entry points and
currently there is no interlock between them. Thus multiple teardown paths
are competing and all heck breaks loose.
Complicating things is the NVMs path. To a large degree, I/O was able to be
shutdown for a full FC port on the SCSI stack. But on NVMe, there isn't a
similar call. At best, it works on a per-controller basis, but even at the
controller level, it's a controller "reset" call. All of which means I/O is
still flowing on different CPUs with reset paths expecting hw access
(mailbox commands) to execute properly.
The following modifications are made:
- A new flag is set in PCI error entrypoints so the driver can track being
called by that path.
- An interlock is added in the SLI hw error path and the PCI error path
such that only one of the paths proceeds with the teardown logic.
- RPI cleanup is patched such that RPIs are marked unregistered w/o mbx
cmds in cases of hw error.
- If entering the SLI port re-init calls, a case where SLI error teardown
was quick and beat the PCI calls now reporting error, check whether the
SLI port is still live on the PCI bus.
- In the PCI reset code to bring the adapter back, recheck the IRQ
settings. Different checks for SLI3 vs SLI4.
- In I/O completions, that may be called as part of the cleanup or
underway just before the hw error, check the state of the adapter. If
in error, shortcut handling that would expect further adapter
completions as the hw error won't be sending them.
- In routines waiting on I/O completions, which may have been in progress
prior to the hw error, detect the device is being torn down and abort
from their waits and just give up. This points to a larger issue in the
driver on ref-counting for data structures, as it doesn't have
ref-counting on q and port structures. We'll do this fix for now as it
would be a major rework to be done differently.
- Fix the NVMe cleanup to simulate NVMe I/O completions if I/O is being
failed back due to hw error.
- In I/O buf allocation, done at the start of new I/Os, check hw state and
fail if hw error.
Link: https://lore.kernel.org/r/20210910233159.115896-10-jsmart2021@gmail.com
Co-developed-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-09-11 07:31:54 +08:00
|
|
|
if (!localport)
|
|
|
|
return;
|
2017-02-13 05:52:32 +08:00
|
|
|
lport = (struct lpfc_nvme_lport *)localport->private;
|
|
|
|
|
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME,
|
2019-08-15 07:57:06 +08:00
|
|
|
"6011 Destroying NVME localport x%px\n",
|
2017-02-13 05:52:32 +08:00
|
|
|
localport);
|
2017-03-05 01:30:33 +08:00
|
|
|
|
2017-02-13 05:52:32 +08:00
|
|
|
/* lport's rport list is clear. Unregister
|
|
|
|
* lport and release resources.
|
|
|
|
*/
|
2019-01-18 00:14:44 +08:00
|
|
|
lport->lport_unreg_cmp = &lport_unreg_cmp;
|
2017-02-13 05:52:32 +08:00
|
|
|
ret = nvme_fc_unregister_localport(localport);
|
2017-11-21 08:00:40 +08:00
|
|
|
|
|
|
|
/* Wait for completion. This either blocks
|
|
|
|
* indefinitely or succeeds
|
|
|
|
*/
|
2019-01-18 00:14:44 +08:00
|
|
|
lpfc_nvme_lport_unreg_wait(vport, lport, &lport_unreg_cmp);
|
|
|
|
vport->localport = NULL;
|
2017-02-13 05:52:32 +08: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-05 01:30:33 +08:00
|
|
|
#endif
|
2017-02-13 05:52:32 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
lpfc_nvme_update_localport(struct lpfc_vport *vport)
|
|
|
|
{
|
2017-04-22 07:04:57 +08:00
|
|
|
#if (IS_ENABLED(CONFIG_NVME_FC))
|
2017-02-13 05:52:32 +08:00
|
|
|
struct nvme_fc_local_port *localport;
|
|
|
|
struct lpfc_nvme_lport *lport;
|
|
|
|
|
|
|
|
localport = vport->localport;
|
2017-04-22 07:04:57 +08:00
|
|
|
if (!localport) {
|
|
|
|
lpfc_printf_vlog(vport, KERN_WARNING, LOG_NVME,
|
|
|
|
"6710 Update NVME fail. No localport\n");
|
|
|
|
return;
|
|
|
|
}
|
2017-02-13 05:52:32 +08:00
|
|
|
lport = (struct lpfc_nvme_lport *)localport->private;
|
2017-04-22 07:04:57 +08:00
|
|
|
if (!lport) {
|
|
|
|
lpfc_printf_vlog(vport, KERN_WARNING, LOG_NVME,
|
2019-08-15 07:57:06 +08:00
|
|
|
"6171 Update NVME fail. localP x%px, No lport\n",
|
2017-04-22 07:04:57 +08:00
|
|
|
localport);
|
|
|
|
return;
|
|
|
|
}
|
2017-02-13 05:52:32 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME,
|
2019-08-15 07:57:06 +08:00
|
|
|
"6012 Update NVME lport x%px did x%x\n",
|
2017-02-13 05:52:32 +08: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-15 07:57:06 +08:00
|
|
|
"6030 bound lport x%px to DID x%06x\n",
|
2017-02-13 05:52:32 +08:00
|
|
|
lport, localport->port_id);
|
2017-04-22 07:04:57 +08:00
|
|
|
#endif
|
2017-02-13 05:52:32 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
lpfc_nvme_register_port(struct lpfc_vport *vport, struct lpfc_nodelist *ndlp)
|
|
|
|
{
|
2017-03-09 06:36:01 +08:00
|
|
|
#if (IS_ENABLED(CONFIG_NVME_FC))
|
2017-02-13 05:52:32 +08:00
|
|
|
int ret = 0;
|
|
|
|
struct nvme_fc_local_port *localport;
|
|
|
|
struct lpfc_nvme_lport *lport;
|
|
|
|
struct lpfc_nvme_rport *rport;
|
2018-04-10 05:24:27 +08:00
|
|
|
struct lpfc_nvme_rport *oldrport;
|
2017-02-13 05:52:32 +08:00
|
|
|
struct nvme_fc_remote_port *remote_port;
|
|
|
|
struct nvme_fc_port_info rpinfo;
|
2018-08-01 08:23:21 +08:00
|
|
|
struct lpfc_nodelist *prev_ndlp = NULL;
|
2020-07-15 05:14:12 +08:00
|
|
|
struct fc_rport *srport = ndlp->rport;
|
2017-02-13 05:52:32 +08: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-24 07:55:33 +08:00
|
|
|
if (!localport)
|
|
|
|
return 0;
|
|
|
|
|
2017-02-13 05:52:32 +08:00
|
|
|
lport = (struct lpfc_nvme_lport *)localport->private;
|
|
|
|
|
2017-06-02 12:06:55 +08: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);
|
2020-07-15 05:14:12 +08:00
|
|
|
if (srport)
|
|
|
|
rpinfo.dev_loss_tmo = srport->dev_loss_tmo;
|
|
|
|
else
|
|
|
|
rpinfo.dev_loss_tmo = vport->cfg_devloss_tmo;
|
2018-04-10 05:24:27 +08:00
|
|
|
|
2020-11-16 03:26:34 +08:00
|
|
|
spin_lock_irq(&ndlp->lock);
|
2022-05-06 11:55:09 +08:00
|
|
|
|
|
|
|
/* If an oldrport exists, so does the ndlp reference. If not
|
|
|
|
* a new reference is needed because either the node has never
|
|
|
|
* been registered or it's been unregistered and getting deleted.
|
|
|
|
*/
|
2018-04-10 05:24:27 +08:00
|
|
|
oldrport = lpfc_ndlp_get_nrport(ndlp);
|
2019-08-15 07:56:41 +08:00
|
|
|
if (oldrport) {
|
|
|
|
prev_ndlp = oldrport->ndlp;
|
2020-11-16 03:26:34 +08:00
|
|
|
spin_unlock_irq(&ndlp->lock);
|
2019-08-15 07:56:41 +08:00
|
|
|
} else {
|
2020-11-16 03:26:34 +08:00
|
|
|
spin_unlock_irq(&ndlp->lock);
|
2020-11-16 03:26:31 +08:00
|
|
|
if (!lpfc_nlp_get(ndlp)) {
|
|
|
|
dev_warn(&vport->phba->pcidev->dev,
|
|
|
|
"Warning - No node ref - exit register\n");
|
|
|
|
return 0;
|
|
|
|
}
|
2019-08-15 07:56:41 +08:00
|
|
|
}
|
2017-12-09 09:18:09 +08:00
|
|
|
|
2017-06-02 12:06:55 +08: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-13 05:52:32 +08:00
|
|
|
*/
|
2018-04-10 05:24:30 +08:00
|
|
|
/* Guard against an unregister/reregister
|
|
|
|
* race that leaves the WAIT flag set.
|
|
|
|
*/
|
2020-11-16 03:26:34 +08:00
|
|
|
spin_lock_irq(&ndlp->lock);
|
2021-07-08 02:43:46 +08:00
|
|
|
ndlp->fc4_xpt_flags &= ~NVME_XPT_UNREG_WAIT;
|
2020-11-16 03:26:33 +08:00
|
|
|
ndlp->fc4_xpt_flags |= NVME_XPT_REGD;
|
2020-11-16 03:26:34 +08:00
|
|
|
spin_unlock_irq(&ndlp->lock);
|
2017-06-02 12:06:55 +08:00
|
|
|
rport = remote_port->private;
|
2018-04-10 05:24:27 +08:00
|
|
|
if (oldrport) {
|
2017-09-30 08:34:30 +08:00
|
|
|
|
2017-12-09 09:18:09 +08:00
|
|
|
/* Sever the ndlp<->rport association
|
|
|
|
* before dropping the ndlp ref from
|
|
|
|
* register.
|
2017-09-30 08:34:30 +08:00
|
|
|
*/
|
2020-11-16 03:26:34 +08:00
|
|
|
spin_lock_irq(&ndlp->lock);
|
2017-09-30 08:34:30 +08:00
|
|
|
ndlp->nrport = NULL;
|
2021-07-08 02:43:46 +08:00
|
|
|
ndlp->fc4_xpt_flags &= ~NVME_XPT_UNREG_WAIT;
|
2020-11-16 03:26:34 +08:00
|
|
|
spin_unlock_irq(&ndlp->lock);
|
2017-09-30 08:34:30 +08:00
|
|
|
rport->ndlp = NULL;
|
2017-12-09 09:18:09 +08:00
|
|
|
rport->remoteport = NULL;
|
2018-04-10 05:24:29 +08: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) {
|
2020-11-16 03:26:30 +08:00
|
|
|
if (!prev_ndlp->nrport)
|
2018-04-10 05:24:29 +08:00
|
|
|
lpfc_nlp_put(prev_ndlp);
|
|
|
|
}
|
2017-02-13 05:52:32 +08:00
|
|
|
}
|
2017-09-30 08:34:30 +08:00
|
|
|
|
|
|
|
/* Clean bind the rport to the ndlp. */
|
|
|
|
rport->remoteport = remote_port;
|
|
|
|
rport->lport = lport;
|
2017-12-09 09:18:09 +08:00
|
|
|
rport->ndlp = ndlp;
|
2020-11-16 03:26:34 +08:00
|
|
|
spin_lock_irq(&ndlp->lock);
|
2017-09-30 08:34:30 +08:00
|
|
|
ndlp->nrport = rport;
|
2020-11-16 03:26:34 +08:00
|
|
|
spin_unlock_irq(&ndlp->lock);
|
2017-09-30 08:34:30 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_INFO,
|
|
|
|
LOG_NVME_DISC | LOG_NODE,
|
2019-08-15 07:56:51 +08:00
|
|
|
"6022 Bind lport x%px to remoteport x%px "
|
|
|
|
"rport x%px WWNN 0x%llx, "
|
2017-09-30 08:34:30 +08:00
|
|
|
"Rport WWPN 0x%llx DID "
|
2019-08-15 07:57:06 +08:00
|
|
|
"x%06x Role x%x, ndlp %p prev_ndlp x%px\n",
|
2018-08-01 08:23:21 +08:00
|
|
|
lport, remote_port, rport,
|
2017-09-30 08:34:30 +08:00
|
|
|
rpinfo.node_name, rpinfo.port_name,
|
2017-12-09 09:18:09 +08:00
|
|
|
rpinfo.port_id, rpinfo.port_role,
|
2018-08-01 08:23:21 +08:00
|
|
|
ndlp, prev_ndlp);
|
2017-02-13 05:52:32 +08:00
|
|
|
} else {
|
2017-06-02 12:06:55 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR,
|
2020-07-01 05:50:00 +08:00
|
|
|
LOG_TRACE_EVENT,
|
2017-06-02 12:06:55 +08:00
|
|
|
"6031 RemotePort Registration failed "
|
|
|
|
"err: %d, DID x%06x\n",
|
|
|
|
ret, ndlp->nlp_DID);
|
2017-02-13 05:52:32 +08:00
|
|
|
}
|
2017-06-02 12:06:55 +08:00
|
|
|
|
2017-02-13 05:52:32 +08:00
|
|
|
return ret;
|
2017-03-05 01:30:33 +08:00
|
|
|
#else
|
|
|
|
return 0;
|
|
|
|
#endif
|
2017-02-13 05:52:32 +08:00
|
|
|
}
|
|
|
|
|
2020-11-02 22:23:52 +08:00
|
|
|
/*
|
2019-05-15 05:58:07 +08: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-15 07:56:50 +08:00
|
|
|
struct lpfc_nvme_rport *nrport;
|
|
|
|
struct nvme_fc_remote_port *remoteport = NULL;
|
2019-05-15 05:58:07 +08:00
|
|
|
|
2020-11-16 03:26:34 +08:00
|
|
|
spin_lock_irq(&ndlp->lock);
|
2019-08-15 07:56:50 +08:00
|
|
|
nrport = lpfc_ndlp_get_nrport(ndlp);
|
|
|
|
if (nrport)
|
|
|
|
remoteport = nrport->remoteport;
|
2020-11-16 03:26:34 +08:00
|
|
|
spin_unlock_irq(&ndlp->lock);
|
2019-05-15 05:58:07 +08:00
|
|
|
|
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_DISC,
|
|
|
|
"6170 Rescan NPort DID x%06x type x%x "
|
2019-08-15 07:56:50 +08: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-15 05:58:07 +08:00
|
|
|
|
2022-04-13 06:19:43 +08:00
|
|
|
/* Rescan an NVME target in MAPPED state with DISCOVERY role set */
|
2019-05-15 05:58:07 +08:00
|
|
|
if (remoteport->port_role & FC_PORT_ROLE_NVME_DISCOVERY &&
|
|
|
|
ndlp->nlp_state == NLP_STE_MAPPED_NODE) {
|
|
|
|
nvme_fc_rescan_remoteport(remoteport);
|
|
|
|
|
2022-04-13 06:19:43 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_DISC,
|
2019-05-15 05:58:07 +08:00
|
|
|
"6172 NVME rescanned DID x%06x "
|
|
|
|
"port_state x%x\n",
|
|
|
|
ndlp->nlp_DID, remoteport->port_state);
|
|
|
|
}
|
|
|
|
return;
|
2019-08-15 07:56:50 +08:00
|
|
|
rescan_exit:
|
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_DISC,
|
|
|
|
"6169 Skip NVME Rport Rescan, NVME remoteport "
|
|
|
|
"unregistered\n");
|
2019-05-15 05:58:07 +08:00
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2017-02-13 05:52:32 +08: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-09 06:36:01 +08:00
|
|
|
#if (IS_ENABLED(CONFIG_NVME_FC))
|
2017-02-13 05:52:32 +08:00
|
|
|
int ret;
|
|
|
|
struct nvme_fc_local_port *localport;
|
|
|
|
struct lpfc_nvme_lport *lport;
|
|
|
|
struct lpfc_nvme_rport *rport;
|
2018-09-14 06:41:10 +08:00
|
|
|
struct nvme_fc_remote_port *remoteport = NULL;
|
2017-02-13 05:52:32 +08: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;
|
|
|
|
|
2020-11-16 03:26:34 +08:00
|
|
|
spin_lock_irq(&ndlp->lock);
|
2018-04-10 05:24:27 +08:00
|
|
|
rport = lpfc_ndlp_get_nrport(ndlp);
|
2018-09-14 06:41:10 +08:00
|
|
|
if (rport)
|
|
|
|
remoteport = rport->remoteport;
|
2020-11-16 03:26:34 +08:00
|
|
|
spin_unlock_irq(&ndlp->lock);
|
2018-09-14 06:41:10 +08:00
|
|
|
if (!remoteport)
|
2017-02-13 05:52:32 +08:00
|
|
|
goto input_err;
|
|
|
|
|
|
|
|
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_DISC,
|
2019-08-15 07:57:06 +08:00
|
|
|
"6033 Unreg nvme remoteport x%px, portname x%llx, "
|
2020-11-16 03:26:33 +08:00
|
|
|
"port_id x%06x, portstate x%x port type x%x "
|
|
|
|
"refcnt %d\n",
|
2017-02-13 05:52:32 +08:00
|
|
|
remoteport, remoteport->port_name,
|
|
|
|
remoteport->port_id, remoteport->port_state,
|
2020-11-16 03:26:33 +08:00
|
|
|
ndlp->nlp_type, kref_read(&ndlp->kref));
|
2017-02-13 05:52:32 +08:00
|
|
|
|
|
|
|
/* Sanity check ndlp type. Only call for NVME ports. Don't
|
|
|
|
* clear any rport state until the transport calls back.
|
|
|
|
*/
|
2017-11-21 08:00:39 +08:00
|
|
|
|
|
|
|
if (ndlp->nlp_type & NLP_NVME_TARGET) {
|
2017-06-02 12:06:55 +08:00
|
|
|
/* No concern about the role change on the nvme remoteport.
|
|
|
|
* The transport will update it.
|
|
|
|
*/
|
2020-11-16 03:26:33 +08:00
|
|
|
spin_lock_irq(&vport->phba->hbalock);
|
2021-07-08 02:43:46 +08:00
|
|
|
ndlp->fc4_xpt_flags |= NVME_XPT_UNREG_WAIT;
|
2020-11-16 03:26:33 +08:00
|
|
|
spin_unlock_irq(&vport->phba->hbalock);
|
2018-05-25 12:08:59 +08: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.
|
|
|
|
*/
|
2023-03-02 07:16:23 +08:00
|
|
|
if (vport->load_flag & FC_UNLOADING ||
|
|
|
|
unlikely(vport->phba->link_state == LPFC_HBA_ERROR))
|
2018-05-25 12:08:59 +08:00
|
|
|
(void)nvme_fc_set_remoteport_devloss(remoteport, 0);
|
|
|
|
|
2017-02-13 05:52:32 +08:00
|
|
|
ret = nvme_fc_unregister_remoteport(remoteport);
|
2020-11-16 03:26:33 +08:00
|
|
|
|
|
|
|
/* The driver no longer knows if the nrport memory is valid.
|
|
|
|
* because the controller teardown process has begun and
|
|
|
|
* is asynchronous. Break the binding in the ndlp. Also
|
|
|
|
* remove the register ndlp reference to setup node release.
|
|
|
|
*/
|
|
|
|
ndlp->nrport = NULL;
|
|
|
|
lpfc_nlp_put(ndlp);
|
2017-12-09 09:18:09 +08:00
|
|
|
if (ret != 0) {
|
2020-07-01 05:50:00 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_TRACE_EVENT,
|
2017-02-13 05:52:32 +08:00
|
|
|
"6167 NVME unregister failed %d "
|
|
|
|
"port_state x%x\n",
|
|
|
|
ret, remoteport->port_state);
|
2017-12-09 09:18:09 +08:00
|
|
|
}
|
2017-02-13 05:52:32 +08:00
|
|
|
}
|
|
|
|
return;
|
|
|
|
|
|
|
|
input_err:
|
2017-03-05 01:30:33 +08:00
|
|
|
#endif
|
2020-07-01 05:50:00 +08:00
|
|
|
lpfc_printf_vlog(vport, KERN_ERR, LOG_TRACE_EVENT,
|
2019-08-15 07:57:06 +08:00
|
|
|
"6168 State error: lport x%px, rport x%px FCID x%06x\n",
|
2017-02-13 05:52:32 +08:00
|
|
|
vport->localport, ndlp->rport, ndlp->nlp_DID);
|
|
|
|
}
|
2017-03-05 01:30:30 +08:00
|
|
|
|
scsi: lpfc: Fix EEH support for NVMe I/O
Injecting errors on the PCI slot while the driver is handling NVMe I/O will
cause crashes and hangs.
There are several rather difficult scenarios occurring. The main issue is
that the adapter can report a PCI error before or simultaneously to the PCI
subsystem reporting the error. Both paths have different entry points and
currently there is no interlock between them. Thus multiple teardown paths
are competing and all heck breaks loose.
Complicating things is the NVMs path. To a large degree, I/O was able to be
shutdown for a full FC port on the SCSI stack. But on NVMe, there isn't a
similar call. At best, it works on a per-controller basis, but even at the
controller level, it's a controller "reset" call. All of which means I/O is
still flowing on different CPUs with reset paths expecting hw access
(mailbox commands) to execute properly.
The following modifications are made:
- A new flag is set in PCI error entrypoints so the driver can track being
called by that path.
- An interlock is added in the SLI hw error path and the PCI error path
such that only one of the paths proceeds with the teardown logic.
- RPI cleanup is patched such that RPIs are marked unregistered w/o mbx
cmds in cases of hw error.
- If entering the SLI port re-init calls, a case where SLI error teardown
was quick and beat the PCI calls now reporting error, check whether the
SLI port is still live on the PCI bus.
- In the PCI reset code to bring the adapter back, recheck the IRQ
settings. Different checks for SLI3 vs SLI4.
- In I/O completions, that may be called as part of the cleanup or
underway just before the hw error, check the state of the adapter. If
in error, shortcut handling that would expect further adapter
completions as the hw error won't be sending them.
- In routines waiting on I/O completions, which may have been in progress
prior to the hw error, detect the device is being torn down and abort
from their waits and just give up. This points to a larger issue in the
driver on ref-counting for data structures, as it doesn't have
ref-counting on q and port structures. We'll do this fix for now as it
would be a major rework to be done differently.
- Fix the NVMe cleanup to simulate NVMe I/O completions if I/O is being
failed back due to hw error.
- In I/O buf allocation, done at the start of new I/Os, check hw state and
fail if hw error.
Link: https://lore.kernel.org/r/20210910233159.115896-10-jsmart2021@gmail.com
Co-developed-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-09-11 07:31:54 +08:00
|
|
|
/**
|
|
|
|
* lpfc_sli4_nvme_pci_offline_aborted - Fast-path process of NVME xri abort
|
|
|
|
* @phba: pointer to lpfc hba data structure.
|
|
|
|
* @lpfc_ncmd: The nvme job structure for the request being aborted.
|
|
|
|
*
|
|
|
|
* This routine is invoked by the worker thread to process a SLI4 fast-path
|
|
|
|
* NVME aborted xri. Aborted NVME IO commands are completed to the transport
|
|
|
|
* here.
|
|
|
|
**/
|
|
|
|
void
|
|
|
|
lpfc_sli4_nvme_pci_offline_aborted(struct lpfc_hba *phba,
|
|
|
|
struct lpfc_io_buf *lpfc_ncmd)
|
|
|
|
{
|
|
|
|
struct nvmefc_fcp_req *nvme_cmd = NULL;
|
|
|
|
|
|
|
|
lpfc_printf_log(phba, KERN_INFO, LOG_NVME_ABTS,
|
|
|
|
"6533 %s nvme_cmd %p tag x%x abort complete and "
|
|
|
|
"xri released\n", __func__,
|
|
|
|
lpfc_ncmd->nvmeCmd,
|
|
|
|
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->transferred_length = 0;
|
|
|
|
nvme_cmd->rcv_rsplen = 0;
|
|
|
|
nvme_cmd->status = NVME_SC_INTERNAL;
|
|
|
|
nvme_cmd->done(nvme_cmd);
|
|
|
|
lpfc_ncmd->nvmeCmd = NULL;
|
|
|
|
}
|
|
|
|
lpfc_release_nvme_buf(phba, lpfc_ncmd);
|
|
|
|
}
|
|
|
|
|
2017-03-05 01:30:30 +08: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-15 07:57:11 +08:00
|
|
|
* @lpfc_ncmd: The nvme job structure for the request being aborted.
|
2017-03-05 01:30:30 +08:00
|
|
|
*
|
|
|
|
* This routine is invoked by the worker thread to process a SLI4 fast-path
|
2017-09-30 08:34:43 +08:00
|
|
|
* NVME aborted xri. Aborted NVME IO commands are completed to the transport
|
|
|
|
* here.
|
2017-03-05 01:30:30 +08:00
|
|
|
**/
|
|
|
|
void
|
|
|
|
lpfc_sli4_nvme_xri_aborted(struct lpfc_hba *phba,
|
2019-08-15 07:57:11 +08:00
|
|
|
struct sli4_wcqe_xri_aborted *axri,
|
|
|
|
struct lpfc_io_buf *lpfc_ncmd)
|
2017-03-05 01:30:30 +08:00
|
|
|
{
|
|
|
|
uint16_t xri = bf_get(lpfc_wcqe_xa_xri, axri);
|
2017-09-30 08:34:43 +08:00
|
|
|
struct nvmefc_fcp_req *nvme_cmd = NULL;
|
2019-08-15 07:57:11 +08:00
|
|
|
struct lpfc_nodelist *ndlp = lpfc_ncmd->ndlp;
|
2017-03-05 01:30:30 +08: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-22 07:05:04 +08:00
|
|
|
|
2019-08-15 07:57:11 +08: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-22 07:05:04 +08:00
|
|
|
|
2019-08-15 07:57:11 +08: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-05 01:30:30 +08:00
|
|
|
}
|
2017-11-21 08:00:42 +08: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-29 03:14:21 +08:00
|
|
|
if (phba->sli_rev < LPFC_SLI_REV4 || !phba->sli4_hba.hdwq)
|
2017-11-21 08:00:42 +08:00
|
|
|
return;
|
|
|
|
|
2019-08-15 07:57:11 +08:00
|
|
|
/* Cycle through all IO rings and make sure all outstanding
|
2017-11-21 08:00:42 +08: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-29 03:14:21 +08:00
|
|
|
for (i = 0; i < phba->cfg_hdw_queue; i++) {
|
2019-08-15 07:57:11 +08:00
|
|
|
if (!phba->sli4_hba.hdwq[i].io_wq)
|
2019-01-29 03:14:31 +08:00
|
|
|
continue;
|
2019-08-15 07:57:11 +08:00
|
|
|
pring = phba->sli4_hba.hdwq[i].io_wq->pring;
|
2017-11-21 08:00:42 +08:00
|
|
|
|
2018-06-26 23:24:24 +08:00
|
|
|
if (!pring)
|
|
|
|
continue;
|
|
|
|
|
2017-11-21 08:00:42 +08: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) {
|
2020-07-01 05:50:00 +08:00
|
|
|
lpfc_printf_log(phba, KERN_ERR, LOG_TRACE_EVENT,
|
2017-11-21 08:00:42 +08:00
|
|
|
"6178 NVME IO not empty, "
|
|
|
|
"cnt %d\n", wait_cnt);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
scsi: lpfc: Implement health checking when aborting I/O
Several errors have occurred where the adapter stops or fails but does not
raise the register values for the driver to detect failure. Thus driver is
unaware of the failure. The failure typically results in I/O timeouts, the
I/O timeout handler failing (after several seconds), and the error handler
escalating recovery policy and resulting in more errors. Eventually, the
driver is in a position where things have spiraled and it can't do recovery
because other recovery ops are still outstanding and it becomes unusable.
Resolve the situation by having the I/O timeout handler (actually a els,
SCSI I/O, NVMe ls, or NVMe I/O timeout), in addition to aborting the I/O,
perform a mailbox command and look for a response from the hardware. If
the mailbox command fails, it will mark the adapter offline and then invoke
the adapter reset handler to clean up.
The new I/O timeout test will be limited to a test every 5s. If there are
multiple I/O timeouts concurrently, only the 1st I/O timeout will generate
the mailbox command. Further testing will only occur once a timeout occurs
after a 5s delay from the last mailbox command has expired.
Link: https://lore.kernel.org/r/20210104180240.46824-14-jsmart2021@gmail.com
Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
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>
2021-01-05 02:02:38 +08:00
|
|
|
|
|
|
|
/* Make sure HBA is alive */
|
|
|
|
lpfc_issue_hb_tmo(phba);
|
|
|
|
|
2017-11-21 08:00:42 +08:00
|
|
|
}
|
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-15 07:56:55 +08:00
|
|
|
|
|
|
|
void
|
2021-01-05 02:02:35 +08:00
|
|
|
lpfc_nvme_cancel_iocb(struct lpfc_hba *phba, struct lpfc_iocbq *pwqeIn,
|
|
|
|
uint32_t stat, uint32_t param)
|
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-15 07:56:55 +08:00
|
|
|
{
|
|
|
|
#if (IS_ENABLED(CONFIG_NVME_FC))
|
|
|
|
struct lpfc_io_buf *lpfc_ncmd;
|
|
|
|
struct nvmefc_fcp_req *nCmd;
|
2021-01-05 02:02:35 +08:00
|
|
|
struct lpfc_wcqe_complete wcqe;
|
|
|
|
struct lpfc_wcqe_complete *wcqep = &wcqe;
|
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-15 07:56:55 +08:00
|
|
|
|
2022-04-13 06:20:02 +08:00
|
|
|
lpfc_ncmd = pwqeIn->io_buf;
|
2021-01-05 02:02:35 +08:00
|
|
|
if (!lpfc_ncmd) {
|
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-15 07:56:55 +08:00
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
|
|
|
spin_lock(&lpfc_ncmd->buf_lock);
|
2021-01-05 02:02:35 +08:00
|
|
|
nCmd = lpfc_ncmd->nvmeCmd;
|
|
|
|
if (!nCmd) {
|
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-15 07:56:55 +08:00
|
|
|
spin_unlock(&lpfc_ncmd->buf_lock);
|
|
|
|
lpfc_release_nvme_buf(phba, lpfc_ncmd);
|
|
|
|
return;
|
|
|
|
}
|
2021-01-05 02:02:35 +08:00
|
|
|
spin_unlock(&lpfc_ncmd->buf_lock);
|
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-15 07:56:55 +08:00
|
|
|
|
|
|
|
lpfc_printf_log(phba, KERN_INFO, LOG_NVME_IOERR,
|
|
|
|
"6194 NVME Cancel xri %x\n",
|
|
|
|
lpfc_ncmd->cur_iocbq.sli4_xritag);
|
|
|
|
|
2021-01-05 02:02:35 +08:00
|
|
|
wcqep->word0 = 0;
|
|
|
|
bf_set(lpfc_wcqe_c_status, wcqep, stat);
|
|
|
|
wcqep->parameter = param;
|
2022-07-02 05:14:14 +08:00
|
|
|
wcqep->total_data_placed = 0;
|
2021-01-05 02:02:35 +08:00
|
|
|
wcqep->word3 = 0; /* xb is 0 */
|
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-15 07:56:55 +08:00
|
|
|
|
|
|
|
/* Call release with XB=1 to queue the IO into the abort list. */
|
2021-01-05 02:02:35 +08:00
|
|
|
if (phba->sli.sli_flag & LPFC_SLI_ACTIVE)
|
|
|
|
bf_set(lpfc_wcqe_c_xb, wcqep, 1);
|
|
|
|
|
2022-02-25 10:22:52 +08:00
|
|
|
memcpy(&pwqeIn->wcqe_cmpl, wcqep, sizeof(*wcqep));
|
|
|
|
(pwqeIn->cmd_cmpl)(phba, pwqeIn, pwqeIn);
|
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-15 07:56:55 +08:00
|
|
|
#endif
|
|
|
|
}
|