On Wed, 2009-08-26 at 14:19 -0400, Jeff Garzik wrote: > On 08/26/2009 02:03 PM, Vasu Dev wrote: > > From: Mike Christie<michaelc@xxxxxxxxxxx> > > > > This is a simple port of the drivers setting a change_queue_depth > > callback but were not tracking queue fulls. In the patch I just have > > these LLDs adjust the queue depth if the user was requesting it. > > Where is the doc describing how, and why, queue-full tracking occurs? > The FCP-3 sec 4.2 states "If command queueing resources are unavailable in the logical unit when a command is received, the device server returns TASK SET FULL status or BUSY status in the FCP_RSP IU as specified by SAM-3". But this patch series is to move the QUEUE_FULL and then the ramp up code from libfc, qla2xxx and lpfc drives to scsi-ml, the libfc had QUEUE_FULL code to move up. This series is not to change how and why part in current queue_full tracking and that was better described in first RFC cover by Mike at http://www.spinics.net/lists/linux-scsi/msg35959.html . > > > diff --git a/drivers/ata/sata_nv.c b/drivers/ata/sata_nv.c > > index 86a4058..fb28be9 100644 > > --- a/drivers/ata/sata_nv.c > > +++ b/drivers/ata/sata_nv.c > > @@ -1963,7 +1963,7 @@ static int nv_swncq_slave_config(struct scsi_device *sdev) > > ata_id_c_string(dev->id, model_num, ATA_ID_PROD, sizeof(model_num)); > > > > if (strncmp(model_num, "Maxtor", 6) == 0) { > > - ata_scsi_change_queue_depth(sdev, 1); > > + ata_scsi_change_queue_depth(sdev, 1, SCSI_QDEPTH_SYSFS_REQ); > > ata_dev_printk(dev, KERN_NOTICE, > > "Disabling SWNCQ mode (depth %x)\n", sdev->queue_depth); > > } > > This queue depth change was clearly not requested via sysfs... > Can be renamed as SCSI_QDEPTH_DEFAULT or SCSI_QDEPTH_NONE reason. What do you think Mike ? Added SCSI_QDEPTH_SYSFS_REQ is default reason code for other drivers code impacted by addition of new reason parameter to existing scsi_host_template->change_queue_depth(), then other non-FC driver ignore any other reason code to keep their existing functionality intact by this API change, so any generic reason name will work and Mike may find more suitable common name for this. Thanks Vasu -- 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
