On 10/01/2014 11:10 PM, Christoph Hellwig wrote:
> On Wed, Oct 01, 2014 at 02:51:31PM -0400, Webb Scales wrote:
>> Hannes,
>>
>> In megasas_change_queue_type(), is it possible for sdev->queue_depth to be
>> greater than 256?
>>
>> Unless I'm misunderstanding the SCSI code, we can request a
>> queue-depth/tag-map-size which is greater than 256, but, since the
>> scsi_cmnd::tag field is an unsigned char, depths greater than 256 may
>> overflow the field when high-numbered tags are used...do I have that right?
>
> Yes, we really need to increase the size of the tag field. SAM allows
> a transport specific limit of up to 64 _bytes_ for it, although I don't
> know implementation that large. Given that the block layer can generate
> up to 32-bit tags both for the old blk-tag.c code and the new
> blk-mq-tag.c version it would be good to use a u32 there. Can you send
> me a patch?
>
Weeelll ...
I'm afraid it's not _that_ easy.
SCSI-II tagged queueing has some specific tag values:
#define SIMPLE_QUEUE_TAG 0x20
#define HEAD_OF_QUEUE_TAG 0x21
#define ORDERED_QUEUE_TAG 0x22
drivers/scsi/vmw_pvscsi.c:
e->tag = SIMPLE_QUEUE_TAG;
if (sdev->tagged_supported &&
(cmd->tag == HEAD_OF_QUEUE_TAG ||
cmd->tag == ORDERED_QUEUE_TAG))
e->tag = cmd->tag;
So we cannot translate between them easily.
Unless we move the SCSI-II values to negative and use the positive
values for 'real' tag numbers.
The recommendation here is to use 'scmd->request->tag' whenever
you want to get to the tag number, and 'scmd->tag' if you have to
play around with SCSI-II TCQ.
But if not I would strongly advise to leave 'scmd->tag' alone.
Speaking of which:
We have
drivers/scsi/scsi_lib.c:scsi_get_cmd_from_request()
/* pull a tag out of the request if we have one */
cmd->tag = req->tag;
cmd->request = req;
What would happen if the block layer decides to use tag number 0x22?
Wouldn't that completely bugger up the TCQ logic?
Why do we need to pull the request tag into the scmd tag, anyway?
I'd rather leave that alone, so that the SCSI midlayer can insert
whatever magic it'll decide to do here ...
James?
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
