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

Mike Christie
2004-07-13T21:02:29Z

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