On 1/5/21 4:55 PM, Lee Duncan wrote:
> On 12/20/20 6:37 PM, Mike Christie wrote:
>> We are setting the shost's can_queue after we add the host which is
>> too late, because scsi-ml will have allocated the tag set based on
>> the can_queue value at that time. This patch has us use the
>> iscsi_host_get_max_scsi_cmds helper to figure out the number of
>> scsi cmds, so we can set it properly. We should now not be limited
>> to 128 cmds per session.
>>
>> It also fixes up the template can_queue so it reflects the max scsi
>> cmds we can support like how other drivers work.
>>
>> Signed-off-by: Mike Christie <michael.christie@xxxxxxxxxx>
>> ---
>> drivers/scsi/iscsi_tcp.c | 9 +++++++--
>> 1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
>> index df47557..7a5aec7 100644
>> --- a/drivers/scsi/iscsi_tcp.c
>> +++ b/drivers/scsi/iscsi_tcp.c
>> @@ -847,6 +847,7 @@ static int iscsi_sw_tcp_host_get_param(struct Scsi_Host *shost,
>> struct iscsi_session *session;
>> struct iscsi_sw_tcp_host *tcp_sw_host;
>> struct Scsi_Host *shost;
>> + int rc;
>>
>> if (ep) {
>> printk(KERN_ERR "iscsi_tcp: invalid ep %p.\n", ep);
>> @@ -864,6 +865,11 @@ static int iscsi_sw_tcp_host_get_param(struct Scsi_Host *shost,
>> shost->max_channel = 0;
>> shost->max_cmd_len = SCSI_MAX_VARLEN_CDB_SIZE;
>>
>> + rc = iscsi_host_get_max_scsi_cmds(shost, cmds_max);
>> + if (rc < 0)
>> + goto free_host;
>
> Same question as in Patch 4: Is having "0" max scsi commands ok?
>
This could hit zero. I think before we would end up where no cmds
would be executed. They would just be stuck in the queues because
the target->can_queue limit would always be hit. I'll fix that up too.
