2007-06-18 08:56:39 +08:00
|
|
|
/*******************************************************************
|
|
|
|
|
* This file is part of the Emulex Linux Device Driver for *
|
|
|
|
|
* Fibre Channel Host Bus Adapters. *
|
2019-01-29 03:14:41 +08:00
|
|
|
* Copyright (C) 2017-2019 Broadcom. All Rights Reserved. The term *
|
2018-06-26 23:24:31 +08:00
|
|
|
* “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. *
|
2011-02-17 01:40:06 +08:00
|
|
|
* Copyright (C) 2007-2011 Emulex. All rights reserved. *
|
2007-06-18 08:56:39 +08:00
|
|
|
* EMULEX and SLI are trademarks of Emulex. *
|
2017-02-13 05:52:39 +08:00
|
|
|
* www.broadcom.com *
|
2007-06-18 08:56:39 +08:00
|
|
|
* *
|
|
|
|
|
* 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. *
|
|
|
|
|
*******************************************************************/
|
|
|
|
|
|
|
|
|
|
#ifndef _H_LPFC_DEBUG_FS
|
|
|
|
|
#define _H_LPFC_DEBUG_FS
|
|
|
|
|
|
2008-12-05 11:40:07 +08:00
|
|
|
#ifdef CONFIG_SCSI_LPFC_DEBUG_FS
|
2011-02-17 01:40:06 +08:00
|
|
|
|
|
|
|
|
/* size of output line, for discovery_trace and slow_ring_trace */
|
|
|
|
|
#define LPFC_DEBUG_TRC_ENTRY_SIZE 100
|
|
|
|
|
|
|
|
|
|
/* nodelist output buffer size */
|
|
|
|
|
#define LPFC_NODELIST_SIZE 8192
|
|
|
|
|
#define LPFC_NODELIST_ENTRY_SIZE 120
|
|
|
|
|
|
|
|
|
|
/* dumpHBASlim output buffer size */
|
|
|
|
|
#define LPFC_DUMPHBASLIM_SIZE 4096
|
|
|
|
|
|
|
|
|
|
/* dumpHostSlim output buffer size */
|
|
|
|
|
#define LPFC_DUMPHOSTSLIM_SIZE 4096
|
|
|
|
|
|
2012-08-04 00:35:13 +08:00
|
|
|
/* dumpSLIqinfo output buffer size */
|
|
|
|
|
#define LPFC_DUMPSLIQINFO_SIZE 4096
|
|
|
|
|
|
2011-02-17 01:40:06 +08:00
|
|
|
/* hbqinfo output buffer size */
|
|
|
|
|
#define LPFC_HBQINFO_SIZE 8192
|
|
|
|
|
|
2017-02-13 05:52:33 +08:00
|
|
|
/* nvmestat output buffer size */
|
|
|
|
|
#define LPFC_NVMESTAT_SIZE 8192
|
|
|
|
|
#define LPFC_NVMEKTIME_SIZE 8192
|
|
|
|
|
#define LPFC_CPUCHECK_SIZE 8192
|
|
|
|
|
#define LPFC_NVMEIO_TRC_SIZE 8192
|
|
|
|
|
|
2019-01-29 03:14:25 +08:00
|
|
|
/* scsistat output buffer size */
|
|
|
|
|
#define LPFC_SCSISTAT_SIZE 8192
|
|
|
|
|
|
2017-02-13 05:52:33 +08:00
|
|
|
#define LPFC_DEBUG_OUT_LINE_SZ 80
|
|
|
|
|
|
2011-07-23 06:37:42 +08:00
|
|
|
/*
|
|
|
|
|
* For SLI4 iDiag debugfs diagnostics tool
|
|
|
|
|
*/
|
|
|
|
|
|
2011-04-16 23:03:04 +08:00
|
|
|
/* pciConf */
|
|
|
|
|
#define LPFC_PCI_CFG_BROWSE 0xffff
|
|
|
|
|
#define LPFC_PCI_CFG_RD_CMD_ARG 2
|
|
|
|
|
#define LPFC_PCI_CFG_WR_CMD_ARG 3
|
2011-02-17 01:40:06 +08:00
|
|
|
#define LPFC_PCI_CFG_SIZE 4096
|
|
|
|
|
#define LPFC_PCI_CFG_RD_SIZE (LPFC_PCI_CFG_SIZE/4)
|
|
|
|
|
|
2011-07-23 06:37:42 +08:00
|
|
|
#define IDIAG_PCICFG_WHERE_INDX 0
|
|
|
|
|
#define IDIAG_PCICFG_COUNT_INDX 1
|
|
|
|
|
#define IDIAG_PCICFG_VALUE_INDX 2
|
|
|
|
|
|
|
|
|
|
/* barAcc */
|
|
|
|
|
#define LPFC_PCI_BAR_BROWSE 0xffff
|
|
|
|
|
#define LPFC_PCI_BAR_RD_CMD_ARG 3
|
|
|
|
|
#define LPFC_PCI_BAR_WR_CMD_ARG 3
|
|
|
|
|
|
|
|
|
|
#define LPFC_PCI_IF0_BAR0_SIZE (1024 * 16)
|
|
|
|
|
#define LPFC_PCI_IF0_BAR1_SIZE (1024 * 128)
|
|
|
|
|
#define LPFC_PCI_IF0_BAR2_SIZE (1024 * 128)
|
|
|
|
|
#define LPFC_PCI_IF2_BAR0_SIZE (1024 * 32)
|
|
|
|
|
|
|
|
|
|
#define LPFC_PCI_BAR_RD_BUF_SIZE 4096
|
|
|
|
|
#define LPFC_PCI_BAR_RD_SIZE (LPFC_PCI_BAR_RD_BUF_SIZE/4)
|
|
|
|
|
|
|
|
|
|
#define LPFC_PCI_IF0_BAR0_RD_SIZE (LPFC_PCI_IF0_BAR0_SIZE/4)
|
|
|
|
|
#define LPFC_PCI_IF0_BAR1_RD_SIZE (LPFC_PCI_IF0_BAR1_SIZE/4)
|
|
|
|
|
#define LPFC_PCI_IF0_BAR2_RD_SIZE (LPFC_PCI_IF0_BAR2_SIZE/4)
|
|
|
|
|
#define LPFC_PCI_IF2_BAR0_RD_SIZE (LPFC_PCI_IF2_BAR0_SIZE/4)
|
|
|
|
|
|
|
|
|
|
#define IDIAG_BARACC_BAR_NUM_INDX 0
|
|
|
|
|
#define IDIAG_BARACC_OFF_SET_INDX 1
|
|
|
|
|
#define IDIAG_BARACC_ACC_MOD_INDX 2
|
|
|
|
|
#define IDIAG_BARACC_REG_VAL_INDX 2
|
|
|
|
|
#define IDIAG_BARACC_BAR_SZE_INDX 3
|
|
|
|
|
|
|
|
|
|
#define IDIAG_BARACC_BAR_0 0
|
|
|
|
|
#define IDIAG_BARACC_BAR_1 1
|
|
|
|
|
#define IDIAG_BARACC_BAR_2 2
|
|
|
|
|
|
|
|
|
|
#define SINGLE_WORD 1
|
|
|
|
|
|
2011-04-16 23:03:04 +08:00
|
|
|
/* queue info */
|
|
|
|
|
#define LPFC_QUE_INFO_GET_BUF_SIZE 4096
|
|
|
|
|
|
|
|
|
|
/* queue acc */
|
|
|
|
|
#define LPFC_QUE_ACC_BROWSE 0xffff
|
|
|
|
|
#define LPFC_QUE_ACC_RD_CMD_ARG 4
|
|
|
|
|
#define LPFC_QUE_ACC_WR_CMD_ARG 6
|
|
|
|
|
#define LPFC_QUE_ACC_BUF_SIZE 4096
|
|
|
|
|
#define LPFC_QUE_ACC_SIZE (LPFC_QUE_ACC_BUF_SIZE/2)
|
|
|
|
|
|
|
|
|
|
#define LPFC_IDIAG_EQ 1
|
|
|
|
|
#define LPFC_IDIAG_CQ 2
|
|
|
|
|
#define LPFC_IDIAG_MQ 3
|
|
|
|
|
#define LPFC_IDIAG_WQ 4
|
|
|
|
|
#define LPFC_IDIAG_RQ 5
|
|
|
|
|
|
2011-07-23 06:37:42 +08:00
|
|
|
#define IDIAG_QUEACC_QUETP_INDX 0
|
|
|
|
|
#define IDIAG_QUEACC_QUEID_INDX 1
|
|
|
|
|
#define IDIAG_QUEACC_INDEX_INDX 2
|
|
|
|
|
#define IDIAG_QUEACC_COUNT_INDX 3
|
|
|
|
|
#define IDIAG_QUEACC_OFFST_INDX 4
|
|
|
|
|
#define IDIAG_QUEACC_VALUE_INDX 5
|
|
|
|
|
|
|
|
|
|
/* doorbell register acc */
|
2011-04-16 23:03:04 +08:00
|
|
|
#define LPFC_DRB_ACC_ALL 0xffff
|
|
|
|
|
#define LPFC_DRB_ACC_RD_CMD_ARG 1
|
|
|
|
|
#define LPFC_DRB_ACC_WR_CMD_ARG 2
|
|
|
|
|
#define LPFC_DRB_ACC_BUF_SIZE 256
|
|
|
|
|
|
2018-02-23 00:18:41 +08:00
|
|
|
#define LPFC_DRB_EQ 1
|
|
|
|
|
#define LPFC_DRB_CQ 2
|
|
|
|
|
#define LPFC_DRB_MQ 3
|
|
|
|
|
#define LPFC_DRB_WQ 4
|
|
|
|
|
#define LPFC_DRB_RQ 5
|
2011-04-16 23:03:04 +08:00
|
|
|
|
2018-02-23 00:18:41 +08:00
|
|
|
#define LPFC_DRB_MAX 5
|
2011-02-17 01:40:06 +08:00
|
|
|
|
2011-07-23 06:37:42 +08:00
|
|
|
#define IDIAG_DRBACC_REGID_INDX 0
|
|
|
|
|
#define IDIAG_DRBACC_VALUE_INDX 1
|
|
|
|
|
|
|
|
|
|
/* control register acc */
|
|
|
|
|
#define LPFC_CTL_ACC_ALL 0xffff
|
|
|
|
|
#define LPFC_CTL_ACC_RD_CMD_ARG 1
|
|
|
|
|
#define LPFC_CTL_ACC_WR_CMD_ARG 2
|
|
|
|
|
#define LPFC_CTL_ACC_BUF_SIZE 256
|
|
|
|
|
|
|
|
|
|
#define LPFC_CTL_PORT_SEM 1
|
|
|
|
|
#define LPFC_CTL_PORT_STA 2
|
|
|
|
|
#define LPFC_CTL_PORT_CTL 3
|
|
|
|
|
#define LPFC_CTL_PORT_ER1 4
|
|
|
|
|
#define LPFC_CTL_PORT_ER2 5
|
|
|
|
|
#define LPFC_CTL_PDEV_CTL 6
|
|
|
|
|
|
|
|
|
|
#define LPFC_CTL_MAX 6
|
|
|
|
|
|
|
|
|
|
#define IDIAG_CTLACC_REGID_INDX 0
|
|
|
|
|
#define IDIAG_CTLACC_VALUE_INDX 1
|
|
|
|
|
|
|
|
|
|
/* mailbox access */
|
|
|
|
|
#define LPFC_MBX_DMP_ARG 4
|
|
|
|
|
|
|
|
|
|
#define LPFC_MBX_ACC_BUF_SIZE 512
|
|
|
|
|
#define LPFC_MBX_ACC_LBUF_SZ 128
|
|
|
|
|
|
|
|
|
|
#define LPFC_MBX_DMP_MBX_WORD 0x00000001
|
|
|
|
|
#define LPFC_MBX_DMP_MBX_BYTE 0x00000002
|
|
|
|
|
#define LPFC_MBX_DMP_MBX_ALL (LPFC_MBX_DMP_MBX_WORD | LPFC_MBX_DMP_MBX_BYTE)
|
|
|
|
|
|
|
|
|
|
#define LPFC_BSG_DMP_MBX_RD_MBX 0x00000001
|
|
|
|
|
#define LPFC_BSG_DMP_MBX_RD_BUF 0x00000002
|
|
|
|
|
#define LPFC_BSG_DMP_MBX_WR_MBX 0x00000004
|
|
|
|
|
#define LPFC_BSG_DMP_MBX_WR_BUF 0x00000008
|
|
|
|
|
#define LPFC_BSG_DMP_MBX_ALL (LPFC_BSG_DMP_MBX_RD_MBX | \
|
|
|
|
|
LPFC_BSG_DMP_MBX_RD_BUF | \
|
|
|
|
|
LPFC_BSG_DMP_MBX_WR_MBX | \
|
|
|
|
|
LPFC_BSG_DMP_MBX_WR_BUF)
|
|
|
|
|
|
|
|
|
|
#define LPFC_MBX_DMP_ALL 0xffff
|
|
|
|
|
#define LPFC_MBX_ALL_CMD 0xff
|
|
|
|
|
|
|
|
|
|
#define IDIAG_MBXACC_MBCMD_INDX 0
|
|
|
|
|
#define IDIAG_MBXACC_DPMAP_INDX 1
|
|
|
|
|
#define IDIAG_MBXACC_DPCNT_INDX 2
|
|
|
|
|
#define IDIAG_MBXACC_WDCNT_INDX 3
|
|
|
|
|
|
|
|
|
|
/* extents access */
|
|
|
|
|
#define LPFC_EXT_ACC_CMD_ARG 1
|
|
|
|
|
#define LPFC_EXT_ACC_BUF_SIZE 4096
|
|
|
|
|
|
|
|
|
|
#define LPFC_EXT_ACC_AVAIL 0x1
|
|
|
|
|
#define LPFC_EXT_ACC_ALLOC 0x2
|
|
|
|
|
#define LPFC_EXT_ACC_DRIVR 0x4
|
|
|
|
|
#define LPFC_EXT_ACC_ALL (LPFC_EXT_ACC_DRIVR | \
|
|
|
|
|
LPFC_EXT_ACC_AVAIL | \
|
|
|
|
|
LPFC_EXT_ACC_ALLOC)
|
|
|
|
|
|
|
|
|
|
#define IDIAG_EXTACC_EXMAP_INDX 0
|
|
|
|
|
|
2011-02-17 01:40:06 +08:00
|
|
|
#define SIZE_U8 sizeof(uint8_t)
|
|
|
|
|
#define SIZE_U16 sizeof(uint16_t)
|
|
|
|
|
#define SIZE_U32 sizeof(uint32_t)
|
|
|
|
|
|
2017-02-13 05:52:33 +08:00
|
|
|
#define lpfc_nvmeio_data(phba, fmt, arg...) \
|
|
|
|
|
{ \
|
|
|
|
|
if (phba->nvmeio_trc_on) \
|
|
|
|
|
lpfc_debugfs_nvme_trc(phba, fmt, ##arg); \
|
|
|
|
|
}
|
|
|
|
|
|
2011-02-17 01:40:06 +08:00
|
|
|
struct lpfc_debug {
|
|
|
|
|
char *i_private;
|
|
|
|
|
char op;
|
|
|
|
|
#define LPFC_IDIAG_OP_RD 1
|
|
|
|
|
#define LPFC_IDIAG_OP_WR 2
|
|
|
|
|
char *buffer;
|
|
|
|
|
int len;
|
|
|
|
|
};
|
|
|
|
|
|
2007-08-02 23:09:43 +08:00
|
|
|
struct lpfc_debugfs_trc {
|
2007-06-18 08:56:39 +08:00
|
|
|
char *fmt;
|
|
|
|
|
uint32_t data1;
|
|
|
|
|
uint32_t data2;
|
|
|
|
|
uint32_t data3;
|
|
|
|
|
uint32_t seq_cnt;
|
|
|
|
|
unsigned long jif;
|
|
|
|
|
};
|
2011-02-17 01:40:06 +08:00
|
|
|
|
2017-02-13 05:52:33 +08:00
|
|
|
struct lpfc_debugfs_nvmeio_trc {
|
|
|
|
|
char *fmt;
|
|
|
|
|
uint16_t data1;
|
|
|
|
|
uint16_t data2;
|
|
|
|
|
uint32_t data3;
|
|
|
|
|
};
|
|
|
|
|
|
2011-02-17 01:40:06 +08:00
|
|
|
struct lpfc_idiag_offset {
|
|
|
|
|
uint32_t last_rd;
|
|
|
|
|
};
|
|
|
|
|
|
2011-04-16 23:03:04 +08:00
|
|
|
#define LPFC_IDIAG_CMD_DATA_SIZE 8
|
2011-02-17 01:40:06 +08:00
|
|
|
struct lpfc_idiag_cmd {
|
|
|
|
|
uint32_t opcode;
|
|
|
|
|
#define LPFC_IDIAG_CMD_PCICFG_RD 0x00000001
|
|
|
|
|
#define LPFC_IDIAG_CMD_PCICFG_WR 0x00000002
|
|
|
|
|
#define LPFC_IDIAG_CMD_PCICFG_ST 0x00000003
|
|
|
|
|
#define LPFC_IDIAG_CMD_PCICFG_CL 0x00000004
|
2011-04-16 23:03:04 +08:00
|
|
|
|
2011-07-23 06:37:42 +08:00
|
|
|
#define LPFC_IDIAG_CMD_BARACC_RD 0x00000008
|
|
|
|
|
#define LPFC_IDIAG_CMD_BARACC_WR 0x00000009
|
|
|
|
|
#define LPFC_IDIAG_CMD_BARACC_ST 0x0000000a
|
|
|
|
|
#define LPFC_IDIAG_CMD_BARACC_CL 0x0000000b
|
|
|
|
|
|
2011-04-16 23:03:04 +08:00
|
|
|
#define LPFC_IDIAG_CMD_QUEACC_RD 0x00000011
|
|
|
|
|
#define LPFC_IDIAG_CMD_QUEACC_WR 0x00000012
|
|
|
|
|
#define LPFC_IDIAG_CMD_QUEACC_ST 0x00000013
|
|
|
|
|
#define LPFC_IDIAG_CMD_QUEACC_CL 0x00000014
|
|
|
|
|
|
|
|
|
|
#define LPFC_IDIAG_CMD_DRBACC_RD 0x00000021
|
|
|
|
|
#define LPFC_IDIAG_CMD_DRBACC_WR 0x00000022
|
|
|
|
|
#define LPFC_IDIAG_CMD_DRBACC_ST 0x00000023
|
|
|
|
|
#define LPFC_IDIAG_CMD_DRBACC_CL 0x00000024
|
2011-07-23 06:37:42 +08:00
|
|
|
|
|
|
|
|
#define LPFC_IDIAG_CMD_CTLACC_RD 0x00000031
|
|
|
|
|
#define LPFC_IDIAG_CMD_CTLACC_WR 0x00000032
|
|
|
|
|
#define LPFC_IDIAG_CMD_CTLACC_ST 0x00000033
|
|
|
|
|
#define LPFC_IDIAG_CMD_CTLACC_CL 0x00000034
|
|
|
|
|
|
|
|
|
|
#define LPFC_IDIAG_CMD_MBXACC_DP 0x00000041
|
|
|
|
|
#define LPFC_IDIAG_BSG_MBXACC_DP 0x00000042
|
|
|
|
|
|
|
|
|
|
#define LPFC_IDIAG_CMD_EXTACC_RD 0x00000051
|
|
|
|
|
|
2011-02-17 01:40:06 +08:00
|
|
|
uint32_t data[LPFC_IDIAG_CMD_DATA_SIZE];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct lpfc_idiag {
|
|
|
|
|
uint32_t active;
|
|
|
|
|
struct lpfc_idiag_cmd cmd;
|
|
|
|
|
struct lpfc_idiag_offset offset;
|
2011-04-16 23:03:04 +08:00
|
|
|
void *ptr_private;
|
2011-02-17 01:40:06 +08:00
|
|
|
};
|
2017-03-23 22:53:45 +08:00
|
|
|
|
|
|
|
|
#else
|
|
|
|
|
|
|
|
|
|
#define lpfc_nvmeio_data(phba, fmt, arg...) \
|
|
|
|
|
no_printk(fmt, ##arg)
|
|
|
|
|
|
2007-06-18 08:56:39 +08:00
|
|
|
#endif
|
|
|
|
|
|
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
|
|
|
/* multixripool output buffer size */
|
|
|
|
|
#define LPFC_DUMP_MULTIXRIPOOL_SIZE 8192
|
|
|
|
|
|
2017-03-23 22:53:45 +08:00
|
|
|
enum {
|
|
|
|
|
DUMP_FCP,
|
|
|
|
|
DUMP_NVME,
|
|
|
|
|
DUMP_MBX,
|
|
|
|
|
DUMP_ELS,
|
|
|
|
|
DUMP_NVMELS,
|
|
|
|
|
};
|
|
|
|
|
|
2007-06-18 08:56:39 +08:00
|
|
|
/* Mask for discovery_trace */
|
|
|
|
|
#define LPFC_DISC_TRC_ELS_CMD 0x1 /* Trace ELS commands */
|
|
|
|
|
#define LPFC_DISC_TRC_ELS_RSP 0x2 /* Trace ELS response */
|
|
|
|
|
#define LPFC_DISC_TRC_ELS_UNSOL 0x4 /* Trace ELS rcv'ed */
|
|
|
|
|
#define LPFC_DISC_TRC_ELS_ALL 0x7 /* Trace ELS */
|
|
|
|
|
#define LPFC_DISC_TRC_MBOX_VPORT 0x8 /* Trace vport MBOXs */
|
|
|
|
|
#define LPFC_DISC_TRC_MBOX 0x10 /* Trace other MBOXs */
|
|
|
|
|
#define LPFC_DISC_TRC_MBOX_ALL 0x18 /* Trace all MBOXs */
|
|
|
|
|
#define LPFC_DISC_TRC_CT 0x20 /* Trace disc CT requests */
|
|
|
|
|
#define LPFC_DISC_TRC_DSM 0x40 /* Trace DSM events */
|
|
|
|
|
#define LPFC_DISC_TRC_RPORT 0x80 /* Trace rport events */
|
|
|
|
|
#define LPFC_DISC_TRC_NODE 0x100 /* Trace ndlp state changes */
|
|
|
|
|
|
|
|
|
|
#define LPFC_DISC_TRC_DISCOVERY 0xef /* common mask for general
|
|
|
|
|
* discovery */
|
|
|
|
|
#endif /* H_LPFC_DEBUG_FS */
|
2012-05-10 09:19:25 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Driver debug utility routines outside of debugfs. The debug utility
|
|
|
|
|
* routines implemented here is intended to be used in the instrumented
|
|
|
|
|
* debug driver for debugging host or port issues.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* lpfc_debug_dump_qe - dump an specific entry from a queue
|
|
|
|
|
* @q: Pointer to the queue descriptor.
|
|
|
|
|
* @idx: Index to the entry on the queue.
|
|
|
|
|
*
|
|
|
|
|
* This function dumps an entry indexed by @idx from a queue specified by the
|
|
|
|
|
* queue descriptor @q.
|
|
|
|
|
**/
|
|
|
|
|
static inline void
|
|
|
|
|
lpfc_debug_dump_qe(struct lpfc_queue *q, uint32_t idx)
|
|
|
|
|
{
|
|
|
|
|
char line_buf[LPFC_LBUF_SZ];
|
|
|
|
|
int i, esize, qe_word_cnt, len;
|
|
|
|
|
uint32_t *pword;
|
|
|
|
|
|
|
|
|
|
/* sanity checks */
|
|
|
|
|
if (!q)
|
|
|
|
|
return;
|
|
|
|
|
if (idx >= q->entry_count)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
esize = q->entry_size;
|
|
|
|
|
qe_word_cnt = esize / sizeof(uint32_t);
|
2019-03-13 07:30:28 +08:00
|
|
|
pword = lpfc_sli4_qe(q, idx);
|
2012-05-10 09:19:25 +08:00
|
|
|
|
|
|
|
|
len = 0;
|
scsi: lpfc: change snprintf to scnprintf for possible overflow
Change snprintf to scnprintf. There are generally two cases where using
snprintf causes problems.
1) Uses of size += snprintf(buf, SIZE - size, fmt, ...)
In this case, if snprintf would have written more characters than what the
buffer size (SIZE) is, then size will end up larger than SIZE. In later
uses of snprintf, SIZE - size will result in a negative number, leading
to problems. Note that size might already be too large by using
size = snprintf before the code reaches a case of size += snprintf.
2) If size is ultimately used as a length parameter for a copy back to user
space, then it will potentially allow for a buffer overflow and information
disclosure when size is greater than SIZE. When the size is used to index
the buffer directly, we can have memory corruption. This also means when
size = snprintf... is used, it may also cause problems since size may become
large. Copying to userspace is mitigated by the HARDENED_USERCOPY kernel
configuration.
The solution to these issues is to use scnprintf which returns the number of
characters actually written to the buffer, so the size variable will never
exceed SIZE.
Signed-off-by: Silvio Cesare <silvio.cesare@gmail.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: James Smart <james.smart@broadcom.com>
Cc: Dick Kennedy <dick.kennedy@broadcom.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-03-22 00:44:32 +08:00
|
|
|
len += scnprintf(line_buf+len, LPFC_LBUF_SZ-len, "QE[%04d]: ", idx);
|
2012-05-10 09:19:25 +08:00
|
|
|
if (qe_word_cnt > 8)
|
|
|
|
|
printk(KERN_ERR "%s\n", line_buf);
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < qe_word_cnt; i++) {
|
|
|
|
|
if (!(i % 8)) {
|
|
|
|
|
if (i != 0)
|
|
|
|
|
printk(KERN_ERR "%s\n", line_buf);
|
|
|
|
|
if (qe_word_cnt > 8) {
|
|
|
|
|
len = 0;
|
|
|
|
|
memset(line_buf, 0, LPFC_LBUF_SZ);
|
scsi: lpfc: change snprintf to scnprintf for possible overflow
Change snprintf to scnprintf. There are generally two cases where using
snprintf causes problems.
1) Uses of size += snprintf(buf, SIZE - size, fmt, ...)
In this case, if snprintf would have written more characters than what the
buffer size (SIZE) is, then size will end up larger than SIZE. In later
uses of snprintf, SIZE - size will result in a negative number, leading
to problems. Note that size might already be too large by using
size = snprintf before the code reaches a case of size += snprintf.
2) If size is ultimately used as a length parameter for a copy back to user
space, then it will potentially allow for a buffer overflow and information
disclosure when size is greater than SIZE. When the size is used to index
the buffer directly, we can have memory corruption. This also means when
size = snprintf... is used, it may also cause problems since size may become
large. Copying to userspace is mitigated by the HARDENED_USERCOPY kernel
configuration.
The solution to these issues is to use scnprintf which returns the number of
characters actually written to the buffer, so the size variable will never
exceed SIZE.
Signed-off-by: Silvio Cesare <silvio.cesare@gmail.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: James Smart <james.smart@broadcom.com>
Cc: Dick Kennedy <dick.kennedy@broadcom.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-03-22 00:44:32 +08:00
|
|
|
len += scnprintf(line_buf+len, LPFC_LBUF_SZ-len,
|
2012-05-10 09:19:25 +08:00
|
|
|
"%03d: ", i);
|
|
|
|
|
}
|
|
|
|
|
}
|
scsi: lpfc: change snprintf to scnprintf for possible overflow
Change snprintf to scnprintf. There are generally two cases where using
snprintf causes problems.
1) Uses of size += snprintf(buf, SIZE - size, fmt, ...)
In this case, if snprintf would have written more characters than what the
buffer size (SIZE) is, then size will end up larger than SIZE. In later
uses of snprintf, SIZE - size will result in a negative number, leading
to problems. Note that size might already be too large by using
size = snprintf before the code reaches a case of size += snprintf.
2) If size is ultimately used as a length parameter for a copy back to user
space, then it will potentially allow for a buffer overflow and information
disclosure when size is greater than SIZE. When the size is used to index
the buffer directly, we can have memory corruption. This also means when
size = snprintf... is used, it may also cause problems since size may become
large. Copying to userspace is mitigated by the HARDENED_USERCOPY kernel
configuration.
The solution to these issues is to use scnprintf which returns the number of
characters actually written to the buffer, so the size variable will never
exceed SIZE.
Signed-off-by: Silvio Cesare <silvio.cesare@gmail.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: James Smart <james.smart@broadcom.com>
Cc: Dick Kennedy <dick.kennedy@broadcom.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-03-22 00:44:32 +08:00
|
|
|
len += scnprintf(line_buf+len, LPFC_LBUF_SZ-len, "%08x ",
|
2012-05-10 09:19:25 +08:00
|
|
|
((uint32_t)*pword) & 0xffffffff);
|
|
|
|
|
pword++;
|
|
|
|
|
}
|
|
|
|
|
if (qe_word_cnt <= 8 || (i - 1) % 8)
|
|
|
|
|
printk(KERN_ERR "%s\n", line_buf);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* lpfc_debug_dump_q - dump all entries from an specific queue
|
|
|
|
|
* @q: Pointer to the queue descriptor.
|
|
|
|
|
*
|
|
|
|
|
* This function dumps all entries from a queue specified by the queue
|
|
|
|
|
* descriptor @q.
|
|
|
|
|
**/
|
|
|
|
|
static inline void
|
|
|
|
|
lpfc_debug_dump_q(struct lpfc_queue *q)
|
|
|
|
|
{
|
|
|
|
|
int idx, entry_count;
|
|
|
|
|
|
|
|
|
|
/* sanity check */
|
|
|
|
|
if (!q)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
dev_printk(KERN_ERR, &(((q->phba))->pcidev)->dev,
|
|
|
|
|
"%d: [qid:%d, type:%d, subtype:%d, "
|
|
|
|
|
"qe_size:%d, qe_count:%d, "
|
|
|
|
|
"host_index:%d, port_index:%d]\n",
|
|
|
|
|
(q->phba)->brd_no,
|
|
|
|
|
q->queue_id, q->type, q->subtype,
|
|
|
|
|
q->entry_size, q->entry_count,
|
|
|
|
|
q->host_index, q->hba_index);
|
|
|
|
|
entry_count = q->entry_count;
|
|
|
|
|
for (idx = 0; idx < entry_count; idx++)
|
|
|
|
|
lpfc_debug_dump_qe(q, idx);
|
|
|
|
|
printk(KERN_ERR "\n");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2017-02-13 05:52:30 +08:00
|
|
|
* lpfc_debug_dump_wq - dump all entries from the fcp or nvme work queue
|
2012-05-10 09:19:25 +08:00
|
|
|
* @phba: Pointer to HBA context object.
|
2017-02-13 05:52:30 +08:00
|
|
|
* @wqidx: Index to a FCP or NVME work queue.
|
2012-05-10 09:19:25 +08:00
|
|
|
*
|
2017-02-13 05:52:30 +08:00
|
|
|
* This function dumps all entries from a FCP or NVME work queue specified
|
2017-02-13 05:52:29 +08:00
|
|
|
* by the wqidx.
|
2012-05-10 09:19:25 +08:00
|
|
|
**/
|
|
|
|
|
static inline void
|
2017-02-13 05:52:29 +08:00
|
|
|
lpfc_debug_dump_wq(struct lpfc_hba *phba, int qtype, int wqidx)
|
2012-05-10 09:19:25 +08:00
|
|
|
{
|
2017-02-13 05:52:29 +08:00
|
|
|
struct lpfc_queue *wq;
|
|
|
|
|
char *qtypestr;
|
|
|
|
|
|
|
|
|
|
if (qtype == DUMP_FCP) {
|
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
|
|
|
wq = phba->sli4_hba.hdwq[wqidx].fcp_wq;
|
2017-02-13 05:52:29 +08:00
|
|
|
qtypestr = "FCP";
|
2017-02-13 05:52:30 +08:00
|
|
|
} else if (qtype == DUMP_NVME) {
|
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
|
|
|
wq = phba->sli4_hba.hdwq[wqidx].nvme_wq;
|
2017-02-13 05:52:30 +08:00
|
|
|
qtypestr = "NVME";
|
2017-02-13 05:52:29 +08:00
|
|
|
} else if (qtype == DUMP_MBX) {
|
|
|
|
|
wq = phba->sli4_hba.mbx_wq;
|
|
|
|
|
qtypestr = "MBX";
|
|
|
|
|
} else if (qtype == DUMP_ELS) {
|
|
|
|
|
wq = phba->sli4_hba.els_wq;
|
|
|
|
|
qtypestr = "ELS";
|
2017-02-13 05:52:30 +08:00
|
|
|
} else if (qtype == DUMP_NVMELS) {
|
|
|
|
|
wq = phba->sli4_hba.nvmels_wq;
|
|
|
|
|
qtypestr = "NVMELS";
|
2017-02-13 05:52:29 +08:00
|
|
|
} else
|
2012-05-10 09:19:25 +08:00
|
|
|
return;
|
|
|
|
|
|
2017-02-13 05:52:30 +08:00
|
|
|
if (qtype == DUMP_FCP || qtype == DUMP_NVME)
|
2017-02-13 05:52:29 +08:00
|
|
|
pr_err("%s WQ: WQ[Idx:%d|Qid:%d]\n",
|
|
|
|
|
qtypestr, wqidx, wq->queue_id);
|
|
|
|
|
else
|
|
|
|
|
pr_err("%s WQ: WQ[Qid:%d]\n",
|
|
|
|
|
qtypestr, wq->queue_id);
|
|
|
|
|
|
|
|
|
|
lpfc_debug_dump_q(wq);
|
2012-05-10 09:19:25 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2017-02-13 05:52:30 +08:00
|
|
|
* lpfc_debug_dump_cq - dump all entries from a fcp or nvme work queue's
|
2017-02-13 05:52:29 +08:00
|
|
|
* cmpl queue
|
2012-05-10 09:19:25 +08:00
|
|
|
* @phba: Pointer to HBA context object.
|
2017-02-13 05:52:29 +08:00
|
|
|
* @wqidx: Index to a FCP work queue.
|
2012-05-10 09:19:25 +08:00
|
|
|
*
|
2017-02-13 05:52:30 +08:00
|
|
|
* This function dumps all entries from a FCP or NVME completion queue
|
2017-02-13 05:52:29 +08:00
|
|
|
* which is associated to the work queue specified by the @wqidx.
|
2012-05-10 09:19:25 +08:00
|
|
|
**/
|
|
|
|
|
static inline void
|
2017-02-13 05:52:29 +08:00
|
|
|
lpfc_debug_dump_cq(struct lpfc_hba *phba, int qtype, int wqidx)
|
2012-05-10 09:19:25 +08:00
|
|
|
{
|
2017-02-13 05:52:29 +08:00
|
|
|
struct lpfc_queue *wq, *cq, *eq;
|
|
|
|
|
char *qtypestr;
|
|
|
|
|
int eqidx;
|
|
|
|
|
|
2017-02-13 05:52:30 +08:00
|
|
|
/* fcp/nvme wq and cq are 1:1, thus same indexes */
|
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
|
|
|
eq = NULL;
|
2017-02-13 05:52:29 +08:00
|
|
|
|
|
|
|
|
if (qtype == DUMP_FCP) {
|
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
|
|
|
wq = phba->sli4_hba.hdwq[wqidx].fcp_wq;
|
|
|
|
|
cq = phba->sli4_hba.hdwq[wqidx].fcp_cq;
|
2017-02-13 05:52:29 +08:00
|
|
|
qtypestr = "FCP";
|
2017-02-13 05:52:30 +08:00
|
|
|
} else if (qtype == DUMP_NVME) {
|
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
|
|
|
wq = phba->sli4_hba.hdwq[wqidx].nvme_wq;
|
|
|
|
|
cq = phba->sli4_hba.hdwq[wqidx].nvme_cq;
|
2017-02-13 05:52:30 +08:00
|
|
|
qtypestr = "NVME";
|
2017-02-13 05:52:29 +08:00
|
|
|
} else if (qtype == DUMP_MBX) {
|
|
|
|
|
wq = phba->sli4_hba.mbx_wq;
|
|
|
|
|
cq = phba->sli4_hba.mbx_cq;
|
|
|
|
|
qtypestr = "MBX";
|
|
|
|
|
} else if (qtype == DUMP_ELS) {
|
|
|
|
|
wq = phba->sli4_hba.els_wq;
|
|
|
|
|
cq = phba->sli4_hba.els_cq;
|
|
|
|
|
qtypestr = "ELS";
|
2017-02-13 05:52:30 +08:00
|
|
|
} else if (qtype == DUMP_NVMELS) {
|
|
|
|
|
wq = phba->sli4_hba.nvmels_wq;
|
|
|
|
|
cq = phba->sli4_hba.nvmels_cq;
|
|
|
|
|
qtypestr = "NVMELS";
|
2017-02-13 05:52:29 +08:00
|
|
|
} else
|
2012-05-10 09:19:25 +08:00
|
|
|
return;
|
|
|
|
|
|
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 (eqidx = 0; eqidx < phba->cfg_hdw_queue; eqidx++) {
|
|
|
|
|
eq = phba->sli4_hba.hdwq[eqidx].hba_eq;
|
|
|
|
|
if (cq->assoc_qid == eq->queue_id)
|
2012-05-10 09:19:25 +08:00
|
|
|
break;
|
2017-02-13 05:52:29 +08:00
|
|
|
}
|
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 (eqidx == phba->cfg_hdw_queue) {
|
2017-02-13 05:52:29 +08:00
|
|
|
pr_err("Couldn't find EQ for CQ. Using EQ[0]\n");
|
|
|
|
|
eqidx = 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
|
|
|
eq = phba->sli4_hba.hdwq[0].hba_eq;
|
2012-06-13 01:54:20 +08:00
|
|
|
}
|
2012-05-10 09:19:25 +08:00
|
|
|
|
2017-02-13 05:52:30 +08:00
|
|
|
if (qtype == DUMP_FCP || qtype == DUMP_NVME)
|
2017-02-13 05:52:29 +08:00
|
|
|
pr_err("%s CQ: WQ[Idx:%d|Qid%d]->CQ[Idx%d|Qid%d]"
|
|
|
|
|
"->EQ[Idx:%d|Qid:%d]:\n",
|
|
|
|
|
qtypestr, wqidx, wq->queue_id, wqidx, cq->queue_id,
|
|
|
|
|
eqidx, eq->queue_id);
|
|
|
|
|
else
|
|
|
|
|
pr_err("%s CQ: WQ[Qid:%d]->CQ[Qid:%d]"
|
|
|
|
|
"->EQ[Idx:%d|Qid:%d]:\n",
|
|
|
|
|
qtypestr, wq->queue_id, cq->queue_id,
|
|
|
|
|
eqidx, eq->queue_id);
|
|
|
|
|
|
|
|
|
|
lpfc_debug_dump_q(cq);
|
2012-05-10 09:19:25 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2012-08-04 00:36:13 +08:00
|
|
|
* lpfc_debug_dump_hba_eq - dump all entries from a fcp work queue's evt queue
|
2012-05-10 09:19:25 +08:00
|
|
|
* @phba: Pointer to HBA context object.
|
|
|
|
|
* @fcp_wqidx: Index to a FCP work queue.
|
|
|
|
|
*
|
|
|
|
|
* This function dumps all entries from a FCP event queue which is
|
|
|
|
|
* associated to the FCP work queue specified by the @fcp_wqidx.
|
|
|
|
|
**/
|
|
|
|
|
static inline void
|
2017-02-13 05:52:29 +08:00
|
|
|
lpfc_debug_dump_hba_eq(struct lpfc_hba *phba, int qidx)
|
2012-05-10 09:19:25 +08:00
|
|
|
{
|
2017-02-13 05:52:29 +08:00
|
|
|
struct lpfc_queue *qp;
|
2012-05-10 09:19:25 +08:00
|
|
|
|
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
|
|
|
qp = phba->sli4_hba.hdwq[qidx].hba_eq;
|
2012-05-10 09:19:25 +08:00
|
|
|
|
2017-02-13 05:52:29 +08:00
|
|
|
pr_err("EQ[Idx:%d|Qid:%d]\n", qidx, qp->queue_id);
|
2012-05-10 09:19:25 +08:00
|
|
|
|
2017-02-13 05:52:29 +08:00
|
|
|
lpfc_debug_dump_q(qp);
|
2012-05-10 09:19:25 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* lpfc_debug_dump_dat_rq - dump all entries from the receive data queue
|
|
|
|
|
* @phba: Pointer to HBA context object.
|
|
|
|
|
*
|
|
|
|
|
* This function dumps all entries from the receive data queue.
|
|
|
|
|
**/
|
|
|
|
|
static inline void
|
|
|
|
|
lpfc_debug_dump_dat_rq(struct lpfc_hba *phba)
|
|
|
|
|
{
|
|
|
|
|
printk(KERN_ERR "DAT RQ: RQ[Qid:%d]\n",
|
|
|
|
|
phba->sli4_hba.dat_rq->queue_id);
|
|
|
|
|
lpfc_debug_dump_q(phba->sli4_hba.dat_rq);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* lpfc_debug_dump_hdr_rq - dump all entries from the receive header queue
|
|
|
|
|
* @phba: Pointer to HBA context object.
|
|
|
|
|
*
|
|
|
|
|
* This function dumps all entries from the receive header queue.
|
|
|
|
|
**/
|
|
|
|
|
static inline void
|
|
|
|
|
lpfc_debug_dump_hdr_rq(struct lpfc_hba *phba)
|
|
|
|
|
{
|
|
|
|
|
printk(KERN_ERR "HDR RQ: RQ[Qid:%d]\n",
|
|
|
|
|
phba->sli4_hba.hdr_rq->queue_id);
|
|
|
|
|
lpfc_debug_dump_q(phba->sli4_hba.hdr_rq);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* lpfc_debug_dump_wq_by_id - dump all entries from a work queue by queue id
|
|
|
|
|
* @phba: Pointer to HBA context object.
|
|
|
|
|
* @qid: Work queue identifier.
|
|
|
|
|
*
|
|
|
|
|
* This function dumps all entries from a work queue identified by the queue
|
|
|
|
|
* identifier.
|
|
|
|
|
**/
|
|
|
|
|
static inline void
|
|
|
|
|
lpfc_debug_dump_wq_by_id(struct lpfc_hba *phba, int qid)
|
|
|
|
|
{
|
|
|
|
|
int wq_idx;
|
|
|
|
|
|
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 (wq_idx = 0; wq_idx < phba->cfg_hdw_queue; wq_idx++)
|
|
|
|
|
if (phba->sli4_hba.hdwq[wq_idx].fcp_wq->queue_id == qid)
|
2012-05-10 09:19:25 +08:00
|
|
|
break;
|
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 (wq_idx < phba->cfg_hdw_queue) {
|
2017-02-13 05:52:29 +08:00
|
|
|
pr_err("FCP WQ[Idx:%d|Qid:%d]\n", wq_idx, qid);
|
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
|
|
|
lpfc_debug_dump_q(phba->sli4_hba.hdwq[wq_idx].fcp_wq);
|
2012-05-10 09:19:25 +08:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
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 (wq_idx = 0; wq_idx < phba->cfg_hdw_queue; wq_idx++)
|
|
|
|
|
if (phba->sli4_hba.hdwq[wq_idx].nvme_wq->queue_id == qid)
|
2017-02-13 05:52:30 +08:00
|
|
|
break;
|
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 (wq_idx < phba->cfg_hdw_queue) {
|
2017-02-13 05:52:30 +08:00
|
|
|
pr_err("NVME WQ[Idx:%d|Qid:%d]\n", wq_idx, qid);
|
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
|
|
|
lpfc_debug_dump_q(phba->sli4_hba.hdwq[wq_idx].nvme_wq);
|
2017-02-13 05:52:30 +08:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2012-05-10 09:19:25 +08:00
|
|
|
if (phba->sli4_hba.els_wq->queue_id == qid) {
|
2017-02-13 05:52:29 +08:00
|
|
|
pr_err("ELS WQ[Qid:%d]\n", qid);
|
2012-05-10 09:19:25 +08:00
|
|
|
lpfc_debug_dump_q(phba->sli4_hba.els_wq);
|
2017-02-13 05:52:29 +08:00
|
|
|
return;
|
2012-05-10 09:19:25 +08:00
|
|
|
}
|
2017-02-13 05:52:30 +08:00
|
|
|
|
|
|
|
|
if (phba->sli4_hba.nvmels_wq->queue_id == qid) {
|
|
|
|
|
pr_err("NVME LS WQ[Qid:%d]\n", qid);
|
|
|
|
|
lpfc_debug_dump_q(phba->sli4_hba.nvmels_wq);
|
|
|
|
|
}
|
2012-05-10 09:19:25 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* lpfc_debug_dump_mq_by_id - dump all entries from a mbox queue by queue id
|
|
|
|
|
* @phba: Pointer to HBA context object.
|
|
|
|
|
* @qid: Mbox work queue identifier.
|
|
|
|
|
*
|
|
|
|
|
* This function dumps all entries from a mbox work queue identified by the
|
|
|
|
|
* queue identifier.
|
|
|
|
|
**/
|
|
|
|
|
static inline void
|
|
|
|
|
lpfc_debug_dump_mq_by_id(struct lpfc_hba *phba, int qid)
|
|
|
|
|
{
|
|
|
|
|
if (phba->sli4_hba.mbx_wq->queue_id == qid) {
|
|
|
|
|
printk(KERN_ERR "MBX WQ[Qid:%d]\n", qid);
|
|
|
|
|
lpfc_debug_dump_q(phba->sli4_hba.mbx_wq);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* lpfc_debug_dump_rq_by_id - dump all entries from a receive queue by queue id
|
|
|
|
|
* @phba: Pointer to HBA context object.
|
|
|
|
|
* @qid: Receive queue identifier.
|
|
|
|
|
*
|
|
|
|
|
* This function dumps all entries from a receive queue identified by the
|
|
|
|
|
* queue identifier.
|
|
|
|
|
**/
|
|
|
|
|
static inline void
|
|
|
|
|
lpfc_debug_dump_rq_by_id(struct lpfc_hba *phba, int qid)
|
|
|
|
|
{
|
|
|
|
|
if (phba->sli4_hba.hdr_rq->queue_id == qid) {
|
|
|
|
|
printk(KERN_ERR "HDR RQ[Qid:%d]\n", qid);
|
|
|
|
|
lpfc_debug_dump_q(phba->sli4_hba.hdr_rq);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
if (phba->sli4_hba.dat_rq->queue_id == qid) {
|
|
|
|
|
printk(KERN_ERR "DAT RQ[Qid:%d]\n", qid);
|
|
|
|
|
lpfc_debug_dump_q(phba->sli4_hba.dat_rq);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* lpfc_debug_dump_cq_by_id - dump all entries from a cmpl queue by queue id
|
|
|
|
|
* @phba: Pointer to HBA context object.
|
|
|
|
|
* @qid: Complete queue identifier.
|
|
|
|
|
*
|
|
|
|
|
* This function dumps all entries from a complete queue identified by the
|
|
|
|
|
* queue identifier.
|
|
|
|
|
**/
|
|
|
|
|
static inline void
|
|
|
|
|
lpfc_debug_dump_cq_by_id(struct lpfc_hba *phba, int qid)
|
|
|
|
|
{
|
2017-02-13 05:52:29 +08:00
|
|
|
int cq_idx;
|
2012-05-10 09:19:25 +08:00
|
|
|
|
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 (cq_idx = 0; cq_idx < phba->cfg_hdw_queue; cq_idx++)
|
|
|
|
|
if (phba->sli4_hba.hdwq[cq_idx].fcp_cq->queue_id == qid)
|
2012-05-10 09:19:25 +08:00
|
|
|
break;
|
|
|
|
|
|
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 (cq_idx < phba->cfg_hdw_queue) {
|
2017-02-13 05:52:29 +08:00
|
|
|
pr_err("FCP CQ[Idx:%d|Qid:%d]\n", cq_idx, qid);
|
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
|
|
|
lpfc_debug_dump_q(phba->sli4_hba.hdwq[cq_idx].fcp_cq);
|
2012-05-10 09:19:25 +08:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
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 (cq_idx = 0; cq_idx < phba->cfg_hdw_queue; cq_idx++)
|
|
|
|
|
if (phba->sli4_hba.hdwq[cq_idx].nvme_cq->queue_id == qid)
|
2017-02-13 05:52:30 +08:00
|
|
|
break;
|
|
|
|
|
|
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 (cq_idx < phba->cfg_hdw_queue) {
|
2017-02-13 05:52:30 +08:00
|
|
|
pr_err("NVME CQ[Idx:%d|Qid:%d]\n", cq_idx, qid);
|
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
|
|
|
lpfc_debug_dump_q(phba->sli4_hba.hdwq[cq_idx].nvme_cq);
|
2017-02-13 05:52:30 +08:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2012-05-10 09:19:25 +08:00
|
|
|
if (phba->sli4_hba.els_cq->queue_id == qid) {
|
2017-02-13 05:52:29 +08:00
|
|
|
pr_err("ELS CQ[Qid:%d]\n", qid);
|
2012-05-10 09:19:25 +08:00
|
|
|
lpfc_debug_dump_q(phba->sli4_hba.els_cq);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2017-02-13 05:52:30 +08:00
|
|
|
if (phba->sli4_hba.nvmels_cq->queue_id == qid) {
|
|
|
|
|
pr_err("NVME LS CQ[Qid:%d]\n", qid);
|
|
|
|
|
lpfc_debug_dump_q(phba->sli4_hba.nvmels_cq);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2012-05-10 09:19:25 +08:00
|
|
|
if (phba->sli4_hba.mbx_cq->queue_id == qid) {
|
2017-02-13 05:52:29 +08:00
|
|
|
pr_err("MBX CQ[Qid:%d]\n", qid);
|
2012-05-10 09:19:25 +08:00
|
|
|
lpfc_debug_dump_q(phba->sli4_hba.mbx_cq);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* lpfc_debug_dump_eq_by_id - dump all entries from an event queue by queue id
|
|
|
|
|
* @phba: Pointer to HBA context object.
|
|
|
|
|
* @qid: Complete queue identifier.
|
|
|
|
|
*
|
|
|
|
|
* This function dumps all entries from an event queue identified by the
|
|
|
|
|
* queue identifier.
|
|
|
|
|
**/
|
|
|
|
|
static inline void
|
|
|
|
|
lpfc_debug_dump_eq_by_id(struct lpfc_hba *phba, int qid)
|
|
|
|
|
{
|
|
|
|
|
int eq_idx;
|
|
|
|
|
|
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 (eq_idx = 0; eq_idx < phba->cfg_hdw_queue; eq_idx++)
|
|
|
|
|
if (phba->sli4_hba.hdwq[eq_idx].hba_eq->queue_id == qid)
|
2012-05-10 09:19:25 +08:00
|
|
|
break;
|
|
|
|
|
|
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 (eq_idx < phba->cfg_hdw_queue) {
|
2012-05-10 09:19:25 +08:00
|
|
|
printk(KERN_ERR "FCP EQ[Idx:%d|Qid:%d]\n", eq_idx, qid);
|
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
|
|
|
lpfc_debug_dump_q(phba->sli4_hba.hdwq[eq_idx].hba_eq);
|
2012-05-10 09:19:25 +08:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void lpfc_debug_dump_all_queues(struct lpfc_hba *);
|