Re: [PATCH 1/9] scsi: Add helper code so transport classes/driver can control queueing

[Mike Christie <michaelc@cs.wisc.edu>]

Oh yeah, these patches were made over scsi-rc-fixes and can be applied 
over the target resets ones (the target reset ones can be applied over 
these too).

michaelc@cs.wisc.edu wrote:
> From: Mike Christie <michaelc@cs.wisc.edu>
> 
> SCSI-ml manages the queueing limits for the device and host, but
> does not do so at the target level. However something something similar
> can come in userful when a driver is transitioning a transport object to
> the the blocked state, becuase at that time we do not want to queue
> io and we do not want the queuecommand to be called again.
> 
> The patch adds code similar to the exisiting SCSI_ML_*BUSY handlers.
> You can now return SCSI_MLQUEUE_TARGET_BUSY when we hit
> a transport level queueing issue like the hw cannot allocate some
> resource at the iscsi session/connection level, or the target has temporarily
> closed or shrunk the queueing window, or if we are transitioning
> to the blocked state.
> 
> For bnx2i we will also need to be able to limit queueing at this level.
> bnx2i will hook into libiscsi, but will allocate a scsi host per
> netdevice/hba, so unlike pure software iscsi/iser which is allocating
> a host per session, it cannot set the scsi_host->can_queue and return
> SCSI_MLQUEUE_HOST_BUSY to reflect queueing limits on the transport.
> 
> The iscsi class/driver can also set a scsi_target->can_queue value which
> reflects the max commands the driver/class can support. For iscsi this
> reflects the number of commands we can support for each session due to
> session/connection hw limits, driver limits, and to also reflect the
> session/targets's queueing window.
>