>
> However, the way that the Qlogic driver needs to calculate both the
> available sg table entries and the available command queue slots is
> actually odd enough that no generic mechanism for supporting it in the mid
> layer is possible. Only the driver really knows how these finite
> resources are used up, and when you know the manipulations the driver goes
> through then you'll agree only the driver should know, I'm sure ;-)
It's a combination of:
how much request queue space is available*
how many s/g elements you need to use (depending on length of
command and whether you need to use A64 or A32 entries)
how much SRAM is on the card in question and how much was taken
up by firmware version XYZ loaded from flash or host
how many commands are in process
how many current active exception conditions are in use
Note that the request queue space just is there long enough to put down a
command and notify the f/w on the qlogic. When it can, it moves the request
into onboard SRAM before beginning execution.
Except for running out of queue space with extremely long s/g lists, the rest
is far too hard to really figure out.
Luckily the QLogic f/w will synthesize a QFULL if you go over execution
throttle, or otherwise overrun internal resources. So it goes.
-matt
* 256 entries for 1020/1040 product, any unsigned 16 bit value for
Ultra2/Ultra3 or FC products.
-
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
|
