On 18/02/2016 10:30, Hannes Reinecke wrote:
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
I would like to make a point on cmd_per_lun before considering tagging
slots: For our host the can_queue is considerably greater than
cmd_per_lun (even though we initially set the same in the host template,
which would be incorrect). Regardless I find the host cmd_per_lun is
effectively ignored for the slave device queue depth as it is reset in
sas_slave_configure() to 256 [if this function is used and tagging
enabled]. So if we we choose a reasonable cmd_per_lun for our host, it
is ignored, right? Or am I missing something?
Thanks,
John
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
