>On Fri, 01 Sep 2006, Doug Maxey wrote:
> Ravi,
>
> While working on a patch to add shared tags to qla4xxx was looking at
> the shost->can_queue settings, I see the value is set pretty high:
>
> qla4xxx_probe()
> ...
> host->can_queue = REQUEST_QUEUE_DEPTH + 128;
>
> where REQUEST_QUEUE_DEPTH works out to be 1024.
>
> My question:
> what is the relationship between the can_queue and the
> setting in
> qla4xxx_slave_configure()
> if (sdev->tagged_supported)
> scsi_activate_tcq(sdev, 32);
> else
> scsi_deactivate_tcq(sdev, 32);
>
> Does this imply that the firmware can ultimately track more requests
> than we can possibly stuff in it? Where do the other 1012 requests get
> queued, in the block layer?
My understanding is that the "can_queue" is on a per HBA basis.
In other words maximum no of cmd's a give host adapter can
queue at any given point of time.
While the setting the slave_configure() is on a per lun basis.
Which basically means max no of simultaneous cmd's that
can be outstanding for any given lun.
>
> James' shared tag patch for stex has the following
> +stex_slave_alloc(struct scsi_device *sdev)
> +{
> + /* Cheat: usually extracted from Inquiry data */
> + sdev->tagged_supported = 1;
> +
> + scsi_activate_tcq(sdev, sdev->host->can_queue);
>
> where in this case the can_queue is set to ST_CAN_QUEUE, which works
> out to 32.
Dont know much about stex driver. So cant comment on it.
James any thought ?
Ravi
--
VGER BF report: H 4.75946e-10
-
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
