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

[Hannes Reinecke <hare@suse.de>]

On 02/18/2016 11:12 AM, John Garry wrote:
> On 18/02/2016 07:40, Hannes Reinecke wrote:
[ .. ]
>> 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?
> 
That depends.
Typically the can_queue setting reflects the number of commands the
_host_ can queue internally (due to hardware limitations etc).
They do not necessarily reflect the queue depth for the device
(unless you have a single device, of course).
So if the host has a hardware limit on the number of commands it can
queue, it should set the 'can_queue' variable to the appropriate
number; a host-wide shared tag map is always assumed with recent
kernels.

The queue_depth of an individual device is controlled by the
'cmd_per_lun' setting, and of course capped by can_queue.

But yes, I definitely recommend this method.
Is saves one _so much_ time trying to figure out which command slot
to use. Drawback is that you have to have some sort of fixed order
on them slots to do an efficient lookup.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		   Teamlead Storage & Networking
hare@suse.de			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)