Re: [linux-iscsi-devel] Re: PATCH [3/5] qla2xxx: TCQ fixes

[James Bottomley <James.Bottomley@SteelEye.com>]

On Tue, 2004-07-13 at 14:04, Mike Christie wrote:
> Unfortunately not, but it could be done. The iSCSI requirement is only 
> that every iSCSI task has a tag which has the gaurantee of it being 
> unique across a session, so if the host value was unique across all 
> request_queues then it would still be safe to use.

Yes, I know...I've been over this several times with iscsi people.  The
basic point, I think, is that the driver could be so much tidier if
session state were stored in the host, and there were a direct
host<->end point correspondence.  You're certainly going to damage
scalability with a single host because of the way we use the host lock
to count per-host outstanding commands.

> The problem is that we need a tag for every iscsi task, so this includes 
> untagged commands and logins (before there is a device/request_queue). 
> Should we just keep it in the driver, or could the request queue have 
> functions pointers so someone could override the block layer tag 
> fucntions? What I am also thinking is that instead of passing the block 
> layer request_queue (with the queue always allocating and setting the 
> map) as an argument, it might be possible to make the tag functions 
> some-new-map-structure based.

That's the tag model.  Once TCQ is turned on, all tasks must be tagged,
even in SPI.

I don't quite understand why you need to override the block tag
functions, or why you want to operate without a request queue.  Even for
device probing in SCSI, we allocate a request queue, send the INQUIRY,
find there's nothing there and destroy the queue again.

The whole of SCSI is designed to operate with request structures backing
tasks; if you have to worry about this not being true, you'll generate a
maze of special cases in the driver.

> Bascially, the host could allocate this map and it could be initialized 
> to have start_tag/end_tag functions that are possibly transport specific 
> (iSCSI has some magic tag values, but I do not know about spi or fc). 
> this way if it needed to allocate tags before a queue is present (for 
> logins for iscsi's case) then it could do so (this also means the tag 
> must have some new structure becuase for normal populate_msg usage the 
> msg is dependant on request properties). Then when blk_init_queue is 
> finally called it can inherit the existing map structure with its 
> function pointers.

Tell me more about the magic tags.  We don't have a way to single them
out currently, but that could be easily added by just marking them
occupied in the bitmap.

James