I am not sure how many "dumb" HBAs you saw? But at least more than 5 kinds of HBAs with the limited queue depth. It's a common sense to me at least.
The queue depth of the HBA has nothing to do with the target device queue-full and target device's throttle. The queue limitation of the HBA stands for the capability of the HBA dealing with outstanding commands. As for the two option ways I provided are used by more than 4 drivers what I saw. TRAN_BUSY means the HBA driver has not enough resource to handle the IO request temporarily and ask for target driver retry later until there is spare or free queue to send command through HBA. As for the per HBA instance throttle, it's just a HBA capability. However, target throttle stands for the target device capability. They are different because target throttle is not predictable since the target device can be attached to multiple initiators. But single HBA instance, the throttle is predictable and can be controlled by driver in advance. So no any conflicts between per HBA throttle and target throttle. Anyway, in my mind, if you want to make your driver simple, use the option 1:TRAN_BUSY. If you want to control throttle by yourself, you can use option2: per HBA instance throttle. If you can think of any new idea, please share with us. Thanks Javen Tom Cumming wrote: > Javen Wu wrote: > >> Most of HBA controllers regardless RAID or non-RAID have limited >> queue depth. > > I disagree. A dumb HBA will simply pass commands onward to targets. > The target will return queue-full, not the HBA. A RAID controller has > target(s) built into it. Depending on the design, a RAID controller > acquires resources from a pool that is common to all targets. > Therefore what limits the queue depth for some RAID controllers is the > controller itself, not per target as in the HBA case. > >> If failed, return TRAN_BUSY to ask target driver retry later, or >> implement a waiting queue in HBA driver >> put the command enter into waiting queue until there is >> spared/released slot. > > I am aware of these two options. Returning TRAN_BUSY seemed rather > heavy handed to me. It means that the target driver will (hopefully) > invoke it's throttling mechanism, queue the request, time it, and > retry it. The other problem is that the TRAN_BUSY's will appear to be > random across multiple targets. This may confuse the throttling > algorithm. > > I could queue the request in my driver, but I'd like to keep it > simple. Since I know the target driver already has it's own queue, why > reinvent the wheel and do it again (and increase the likelihood of > introducing bugs)? > > Since the target driver already throttles requests sent to a target, > it would be nice if I could use it's throttling mechanism per-controller. > > I gather from your response that that may not be possible. > > carlos > >> Carlos Cumming wrote: >> >>> I'm writing a driver for a RAID controller that has a limited queue >>> depth. Note it's the controller that has limited queue depth, not >>> the target (like SCSI expects). I only know how to limit the queue >>> depth per I_T nexus, not per controller like I need. >>> >>> Is there a way to do this that I'm missing? >>> >>> Thanx, Carlos. >>> >>> _______________________________________________ >>> driver-discuss mailing list >>> [email protected] >>> http://mail.opensolaris.org/mailman/listinfo/driver-discuss >>> >>> >> Most of HBA controllers regardless RAID or non-RAID have limited >> queue depth. >> The depth means HBA's capability of dealing with outstanding commands >> concurrently. >> So the correct method in HBA driver should be: >> >> each time transport, request allocation of a slot of the queue in >> *tran_start() >> If success, transport the command by use of the slot. >> If failed, return TRAN_BUSY to ask target driver retry later, or >> implement a waiting queue in HBA driver >> put the command enter into waiting queue until there is >> spared/released slot. >> >> Thanks >> Javen > > _______________________________________________ driver-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/driver-discuss
