Re: [PATCH 5/6] hisi_sas: add hisi_sas_slave_configure()

[John Garry <john.garry@huawei.com>]

On 18/02/2016 07:40, Hannes Reinecke wrote:
> On 02/16/2016 05:56 PM, John Garry wrote:
>> On 16/02/2016 15:33, Hannes Reinecke wrote:
>>> On 02/16/2016 01:22 PM, John Garry wrote:
>>>> In high-datarate aging tests, it is found that
>>>> the SCSI framework can periodically
>>>> issue lu resets to the device. This is because scsi
>>>> commands begin to timeout. It is found that TASK SET
>>>> FULL may be returned many times for the same command,
>>>> causing the timeouts.
>>>> To overcome this, the queue depth for the device needs
>>>> to be reduced to 64 (from 256, set in
>>>> sas_slave_configure()).
>>>>
>>> Hmm. TASK SET FULL should cause the queue depth to be reduced
>>> automatically, no?
>>>
>>> Cheers,
>>>
>>> Hannes
>>>
>>
>> I need to double-check if Task set full reduces the depth, I don't
>> think it does.
>>
>> Regardless I found we were getting a combination of commands being
>> retried due to Task Set Full and also SAS_QUEUE_FULL errors. For
>> sure the SAS_QUEUE_FULL task errors reduce the queue depth in
>> scsi_track_queue_full(). However I found it to be very slow in
>> tracking, and we were getting commands timing out before the queue
>> depth fell enough.
>>
>> It would be nice to change default queue depth in
>> sas_slave_configure() to a lower value so we can avoid this patch,
>> but I am not sure if other vendor's HBA performance would be
>> affected. From looking at the history of sas_slave_configure(), it
>> would seem the value of 256 was inherited from mpt2sas driver, so
>> I'm not sure.
>>
> Well, the classical thing would be to associate each request tag
> with a SAS task; or, in your case, associate each slot index with a
> request tag.
> You probably would need to reserve some slots for TMFs, ie you'd
> need to decrease the resulting ->can_queue variable by that.
> But once you've done that you shouldn't hit any QUEUE_FULL issues,
> as the block layer will ensure that no tags will be reused while the
> command is in flight.
> Plus this is something you really need to be doing if you ever
> consider moving to scsi-mq ...
>
> Cheers,
>
> Hannes
>
Hi,

So would you recommend this method under the assumption that the 
can_queue value for the host is similar to the queue depth for the device?

Regards,
John