On 02/18/2016 11:12 AM, John Garry wrote:
On 18/02/2016 07:40, Hannes Reinecke wrote:[ .. ]
That depends.Well, the classical thing would be to associate each request tagHi,
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
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?
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