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

[Mike Christie <mikenc@us.ibm.com>]

James Bottomley wrote:
> 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.

I will put that on my todo list then.

> 
>>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.

An excess of those already exist in the driver today :) :(

Maybe our driver initialization is the problem or maybe I am trying to do
too much. Here's how driver init is performed today in 2.6:

1. userspace does discovery, then passes this info down through an ioctl.
2. driver then uses this info to establish an iSCSI session. To accomplish this
we must do a login which requires a task tag. However, at this point there has not
been a request queue allocated and scsi-ml is not yet scanning.
3. session is established, so we scan away.

I think we could wait to establish a session, until a scan is actually initiated,
so we could do
1. from above.
2. initiate a scan.
3. in our slave_alloc if a session has not yet been established we could do this
there.

> 
>>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.


For some operations the tag value can be 0xffffffff. This is just a reserved
value for special cases. For example if we send a NOP-out and set a valid tag
then this means we want a NOP-in back (a ping), but if the tag was set to
0xffffffff other side affects will result.


-- 
Mike Christie
mikenc@us.ibm.com