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 h...@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)
