On 09/26/2014 10:03 AM, Christoph Hellwig wrote: > On Fri, Sep 26, 2014 at 08:29:29AM +0200, Hannes Reinecke wrote: >> Hi Christoph, >> >> as discussed it would make sense to use the request->tag in eg >> scmd_printk() to identify the command. >> Which I duly did, only to figure out that the tag is always '-1', ie >> tagging is not in use. >> (Which is okay from the SCSI side, seeing the TCQ is basically a >> SCSI parallel thing). > > tag are still a live part of SAM for every transport, they've only > been renamed to "command identifier" in SAM-4 to confuse everyone. > >> Looking closer I found plenty of code for handling tags in the block >> layer (and the blk-mq stuff, of course), but virtually none of the >> non-SPI driver seems to be using them. > > A quick grep for scsi_activate_tcq disagrees with you. > Yeah, I've noticed after I've written the mail. However, main point still stands: using 'tag' to identify commands is pointless if not all of the LLDDs use tagging ... >> Which makes the original idea a bit pointless, seeing that we need >> to identify the command _always_, and not just if the host happens >> to support tagging. >> >> Which leads me to some questions: >> - Is the stuff in blk-mq supposed to work as a superset of SCSI TCQ? > > Yes. > >> - If so, should any HBAs with a queue depth > 1 (which does not >> support TCQ) set the tag of a command? >> (that's what I've initially thought would happen ...) >> - If not (and the ->tag field is basically unused), can't we >> have the HBA to fill in a value here? > > blk-mq will always provide, and does rely on a valid request->tag. > A LLDD can still use it's own internal tagging or mess with scmd->tag, > although in general it should benefit from using the block layer > tagging. > I know. But I was asking about non-mq LLDDs. >> Which apparently was too much to hope for ... > > I guess for now we'll need to stay with the command pointer address. > We can revisit this once the old request layer is gone. > Too bad. The tags would have provided a really nice concise way of identifying the command... Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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
