| Message ID | 20201126014824.123831-2-tyreld@linux.ibm.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | ibmvfc: initial MQ development | expand |
| Context | Check | Description |
|---|---|---|
| snowpatch_ozlabs/apply_patch | success | Successfully applied on branch powerpc/merge (4c202167192a77481310a3cacae9f12618b92216) |
| snowpatch_ozlabs/build-ppc64le | success | Build succeeded |
| snowpatch_ozlabs/build-ppc64be | success | Build succeeded |
| snowpatch_ozlabs/build-ppc64e | success | Build succeeded |
| snowpatch_ozlabs/build-pmac32 | success | Build succeeded |
| snowpatch_ozlabs/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 40 lines checked |
| snowpatch_ozlabs/needsstable | success | Patch has no Fixes tags |
On 11/25/20 7:48 PM, Tyrel Datwyler wrote: > diff --git a/drivers/scsi/ibmvscsi/ibmvfc.h b/drivers/scsi/ibmvscsi/ibmvfc.h > index 9d58cfd774d3..8225bdbb127e 100644 > --- a/drivers/scsi/ibmvscsi/ibmvfc.h > +++ b/drivers/scsi/ibmvscsi/ibmvfc.h > @@ -41,6 +41,11 @@ > #define IBMVFC_DEFAULT_LOG_LEVEL 2 > #define IBMVFC_MAX_CDB_LEN 16 > #define IBMVFC_CLS3_ERROR 0 > +#define IBMVFC_MQ 0 Given that IBMVFC_MQ is getting set to 0 here, that means mq_enabled is also always zero, so am I correct that a lot of this code being added is not yet capable of being executed? > +#define IBMVFC_SCSI_CHANNELS 0 Similar comment here... > +#define IBMVFC_SCSI_HW_QUEUES 1 I don't see any subsequent patches in this series that would ever result in nr_hw_queues getting set to anything other than 1. Is that future work planned or am I missing something? > +#define IBMVFC_MIG_NO_SUB_TO_CRQ 0 > +#define IBMVFC_MIG_NO_N_TO_M 0 > > /* > * Ensure we have resources for ERP and initialization: > @@ -826,6 +831,10 @@ struct ibmvfc_host { > int delay_init; > int scan_complete; > int logged_in; > + int mq_enabled; > + int using_channels; > + int do_enquiry; > + int client_scsi_channels; > int aborting_passthru; > int events_to_log; > #define IBMVFC_AE_LINKUP 0x0001 >
On 11/27/20 9:45 AM, Brian King wrote: > On 11/25/20 7:48 PM, Tyrel Datwyler wrote: >> diff --git a/drivers/scsi/ibmvscsi/ibmvfc.h b/drivers/scsi/ibmvscsi/ibmvfc.h >> index 9d58cfd774d3..8225bdbb127e 100644 >> --- a/drivers/scsi/ibmvscsi/ibmvfc.h >> +++ b/drivers/scsi/ibmvscsi/ibmvfc.h >> @@ -41,6 +41,11 @@ >> #define IBMVFC_DEFAULT_LOG_LEVEL 2 >> #define IBMVFC_MAX_CDB_LEN 16 >> #define IBMVFC_CLS3_ERROR 0 >> +#define IBMVFC_MQ 0 > > Given that IBMVFC_MQ is getting set to 0 here, that means mq_enabled is also > always zero, so am I correct that a lot of this code being added is not > yet capable of being executed? Not with out a direct intervention from a hard coding a different value when building the code. See comment below. > >> +#define IBMVFC_SCSI_CHANNELS 0 > > Similar comment here... > >> +#define IBMVFC_SCSI_HW_QUEUES 1 > > I don't see any subsequent patches in this series that would ever result > in nr_hw_queues getting set to anything other than 1. Is that future work > planned or am I missing something? Yes, there is still some changes to EH that need to be included before those values are safe to be set to anything else by the average user. -Tyrel > >> +#define IBMVFC_MIG_NO_SUB_TO_CRQ 0 >> +#define IBMVFC_MIG_NO_N_TO_M 0 >> >> /* >> * Ensure we have resources for ERP and initialization: >> @@ -826,6 +831,10 @@ struct ibmvfc_host { >> int delay_init; >> int scan_complete; >> int logged_in; >> + int mq_enabled; >> + int using_channels; >> + int do_enquiry; >> + int client_scsi_channels; >> int aborting_passthru; >> int events_to_log; >> #define IBMVFC_AE_LINKUP 0x0001 >> > >
diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c index 42e4d35e0d35..cd609d19e6a1 100644 --- a/drivers/scsi/ibmvscsi/ibmvfc.c +++ b/drivers/scsi/ibmvscsi/ibmvfc.c @@ -5167,6 +5167,7 @@ static int ibmvfc_probe(struct vio_dev *vdev, const struct vio_device_id *id) shost->max_sectors = IBMVFC_MAX_SECTORS; shost->max_cmd_len = IBMVFC_MAX_CDB_LEN; shost->unique_id = shost->host_no; + shost->nr_hw_queues = IBMVFC_SCSI_HW_QUEUES; vhost = shost_priv(shost); INIT_LIST_HEAD(&vhost->sent); @@ -5178,6 +5179,12 @@ static int ibmvfc_probe(struct vio_dev *vdev, const struct vio_device_id *id) vhost->partition_number = -1; vhost->log_level = log_level; vhost->task_set = 1; + + vhost->mq_enabled = IBMVFC_MQ; + vhost->client_scsi_channels = IBMVFC_SCSI_CHANNELS; + vhost->using_channels = 0; + vhost->do_enquiry = 1; + strcpy(vhost->partition_name, "UNKNOWN"); init_waitqueue_head(&vhost->work_wait_q); init_waitqueue_head(&vhost->init_wait_q); diff --git a/drivers/scsi/ibmvscsi/ibmvfc.h b/drivers/scsi/ibmvscsi/ibmvfc.h index 9d58cfd774d3..8225bdbb127e 100644 --- a/drivers/scsi/ibmvscsi/ibmvfc.h +++ b/drivers/scsi/ibmvscsi/ibmvfc.h @@ -41,6 +41,11 @@ #define IBMVFC_DEFAULT_LOG_LEVEL 2 #define IBMVFC_MAX_CDB_LEN 16 #define IBMVFC_CLS3_ERROR 0 +#define IBMVFC_MQ 0 +#define IBMVFC_SCSI_CHANNELS 0 +#define IBMVFC_SCSI_HW_QUEUES 1 +#define IBMVFC_MIG_NO_SUB_TO_CRQ 0 +#define IBMVFC_MIG_NO_N_TO_M 0 /* * Ensure we have resources for ERP and initialization: @@ -826,6 +831,10 @@ struct ibmvfc_host { int delay_init; int scan_complete; int logged_in; + int mq_enabled; + int using_channels; + int do_enquiry; + int client_scsi_channels; int aborting_passthru; int events_to_log; #define IBMVFC_AE_LINKUP 0x0001
Introduce several new vhost fields for managing MQ state of the adapter as well as initial defaults for MQ enablement. Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com> --- drivers/scsi/ibmvscsi/ibmvfc.c | 7 +++++++ drivers/scsi/ibmvscsi/ibmvfc.h | 9 +++++++++ 2 files changed, 16 insertions(+)