On Fri, Apr 07, 2006 at 05:29:28PM -0500, Brian King wrote: > Patrick Mansfield wrote: > > Currently cmd_per_lun is the default queue depth for both tagged and > > untagged queueing. That is, if the LLDD does not modify queue_depth in its > > slave_configure, queue_depth will be set to cmd_per_lun, no matter what > > the command queueing/tag support. > > > > If we don't allow queueing in the LLDD, and cmd_per_lun is supposed to be > > the default depth for untagged support, shouldn't it always be 1, and > > hence go away? > > This seems to assume there are no SCSI devices which do command queuing, but do > not support queue tags. This is not the case. I should not have used "untagged", that is misleading and a problem with current scsi core, where we reference tcq, tags, and don't seem to mention task attributes. But LLDD can override anything in slave_configure. Also, it looks like we could safely use cmd_per_lun as the default queue_depth, rather than setting it to 1 as done in my previous post/patch. > > Similarily, why do some LLDD's use a cmd_per_lun of 3, or (like > > ncr53c8xx_slave_configure) set queue_depth for !tagged_supported to > > anything other than 1? > > In the case of ipr, there are two scenarios. The first is for JBOD disks. > I use a default queue depth of 6 in ipr. When running untagged, with a queue depth > of > 1, the ipr adapter firmware then maintains a queue, guaranteeing only > one command will be outstanding to the device at once. This lower level > queue allows for a faster turnaround of commands and improved performance. > The second case is that of RAID arrays. These show up as logical scsi disks. > They support command queueing, but not tagged command queueing. So you just want the task attibutes, and don't care about tag management (i.e. you don't ever use cmd->request->tags)? That is similar to FCP. > > I know (at least) FCP can always do simple queueing, but I don't think > > scsi core should allow multiple commands to be sent if the device does not > > have CMDQUE (or BQUE). > > This will break both of the working scenarios I described above for ipr > and performance will suffer significantly. The inquiry data for ipr RAID > arrays does not set either CMDQUE or BQUE. Sounds like they are sort of SCSI-2 compliant, that is allowed there but mentioned as obsolete in current SCSI-3 (spc3r23.pdf). The LLDD can override the queue_depth for these cases. > > Also we don't even check the BQUE in the INQUIRY result (byte 6, bit 7). > > Should this be changed? That is set tagged_supported if BQUE is set, like > > we do for CMDQUE (byte 7 bit 1). And also set simple_tags if > > tagged_supported is set. > > I don't like the idea of always enabling TCQ in scsi core simply if > the device supports it. What if the HBA does not support it? To make > matters more interesting, what if the HBA does not support TCQ, but does > support untagged command queueing, similar to ipr as described above? They can override it in slave_configure. It really does look like we should set tagged_supported if BQUE *or* CMDQUE is set, independent of any queue_depth setting. Things are messy in this area, we use scsi-2/SPI based variable names (simple_tags, tagged_supported, tcq), that don't apply to newer transports. We should use task attributes, not tag/untagged. And not combine task attributes with tag management. That is FCP and ipr don't need cmd->request->tag, they don't need the data setup by blk_queue_start_tag(). Also for emulex/lpfc, cmd->tag is set before we have even set request->tag, and neither of those include task attributes. cmd->tag should be deleted. > Additionally, ipr is currently relying on the fact that TCQ does not > get enabled by default. It lets userspace code enable it after verifying > the mode page settings of the drive for things like qerr, which the adapter > firmware has dependencies on. > > Brian -- Patrick Mansfield - : 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
