Revisiting task tags and Linux SCSI

Revisiting task tags and Linux SCSI

[Heinz, Michael]

Okay guys,

Maybe I'm an idiot - but I cannot find *anywhere* in sd.c, sg.c, scsi.c
or elsewhere that the scsi_cmnd.tag field is set to anything except
zero, nor can I find anywhere in the high level SCSI drivers that the
"scsi_device.tagged_*" fields are used. 

Am I wrong here? I can certainly generate task tags that are guaranteed
to be unique (I already have to do that anyway), and I can certainly
'or' them with ORDERED_QUEUE_TAG but I'm not sure how that's going to
impact the higher level SCSI drivers since they never pay attention to
the values of any of the "tagged_*" fields anyway.....

--
Michael Heinz
Infinicon Systems, Inc.
http://www.infiniconsys.com 

Re: Revisiting task tags and Linux SCSI

[Matthew Jacob]

scsi_scan.c:

        /*
         * Set the tagged_queue flag for SCSI-II devices that purport to
support
         * tagged queuing in the INQUIRY data.
         */
        SDpnt->tagged_queue = 0;
        if ((SDpnt->scsi_level >= SCSI_2) &&
            (scsi_result[7] & 2) &&
            !(bflags & BLIST_NOTQ)) {
                SDpnt->tagged_supported = 1;
                SDpnt->current_tag = 0;
        }

This just generates the usage of multiple commands outstanding for this nexus.

I don't think you're looking very hard.

The actually tag generation and management is left up to each HBA driver.

On Wed, 8 May 2002, Heinz, Michael wrote:

> Okay guys,
> 
> Maybe I'm an idiot - but I cannot find *anywhere* in sd.c, sg.c, scsi.c
> or elsewhere that the scsi_cmnd.tag field is set to anything except
> zero, nor can I find anywhere in the high level SCSI drivers that the
> "scsi_device.tagged_*" fields are used. 
> 
> Am I wrong here? I can certainly generate task tags that are guaranteed
> to be unique (I already have to do that anyway), and I can certainly
> 'or' them with ORDERED_QUEUE_TAG but I'm not sure how that's going to
> impact the higher level SCSI drivers since they never pay attention to
> the values of any of the "tagged_*" fields anyway.....
> 
> --
> Michael Heinz
> Infinicon Systems, Inc.
> http://www.infiniconsys.com 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Revisiting task tags and Linux SCSI

[James Bottomley]

mheinz@infiniconsys.com said:
> Maybe I'm an idiot - but I cannot find *anywhere* in sd.c, sg.c,
> scsi.c or elsewhere that the scsi_cmnd.tag field is set to anything
> except zero, nor can I find anywhere in the high level SCSI drivers
> that the "scsi_device.tagged_*" fields are used. 

> Am I wrong here? I can certainly generate task tags that are
> guaranteed to be unique (I already have to do that anyway), and I can
> certainly 'or' them with ORDERED_QUEUE_TAG but I'm not sure how that's
> going to impact the higher level SCSI drivers since they never pay
> attention to the values of any of the "tagged_*" fields anyway..... 

No, you're not wrong.  In the current layering model, tags are manipulated 
almost exclusively by the low level drivers (see aic7xxx, sym8xxx, 53c700 for 
details).  If you use a LLD without TCQ support, then you only send one 
command per lun.

scsi_cmnd.tag is really never used, I believe.

This is counter intuitive since tag manipulation functions should be higher up 
in the driver stack, but that's the way it works today.  Jens Axboe is working 
on generic tag functions (look in block/ll_rw_block.c) but they were only 
introduced recently and aren't yet used in the SCSI layer at all.

James Bottomley

RE: Revisiting task tags and Linux SCSI

[Heinz, Michael]

Thanks, James. I was seriously doubting my sanity.

I'll keep digging to figure out what I need to do to enable TCQ.

--
Michael Heinz
Infinicon Systems, Inc.
http://www.infiniconsys.com