Skip to content
  • Mike Christie's avatar
    [SCSI] Add helper code so transport classes/driver can control queueing (v3) · f0c0a376
    Mike Christie authored
    
    
    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.
    
    bnx2i, when they rework their firmware according to netdev
    developers requests, 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.
    
    Changes:
    v1 - initial patch.
    v2 - Fix scsi_run_queue handling of multiple blocked targets.
    Previously we would break from the main loop if a device was added back on
    the starved list. We now run over the list and check if any target is
    blocked.
    v3 - Rediff for scsi-misc.
    
    Signed-off-by: default avatarMike Christie <michaelc@cs.wisc.edu>
    Signed-off-by: default avatarJames Bottomley <James.Bottomley@HansenPartnership.com>
    f0c0a376