Hi James, 

This series is about reducing locking contention in the IO submission/response 
processing 
fast path of libiscsi and the various iscsi transports usage of libiscsi code.

We replace the session lock with two locks, a forward lock and a backwards lock 
named frwd_lock and back_lock respectively.

The forward lock protects resources that change while sending a request to the 
target, such as cmdsn, queued_cmdsn, and allocating task from the commands' 
pool with kfifo_out.

The backward lock protects resources that change while processing a response or 
in error path, such as cmdsn_exp, cmdsn_max, and returning tasks to the 
commands' 
pool with kfifo_in. 

The 1st patch in the series is a restructuring patch for iscsi_tcp r2t response
logic, the 2nd is the main patch and the 3rd is cleanup asked by Mike who 
reviewed
the whole series when we posted in over the open-iscsi mailing list.

Under a "steady state" fast-path situation, that is when one or more 
processes/threads 
submit IO to an iscsi device and a single kernel upcall (e.g softirq) is 
dealing 
with processing  of responses without errors, this patch eliminates the 
contention
between the queuecommand()/request response/scsi_done() associated with iscsi 
sessions.

Or and Shlomo.

Shlomo Pongratz (3):
  SCSI/libiscsi: Restructure iscsi_tcp r2t response logic
  SCSI/libiscsi: Reduce locking contention in fast path
  SCSI/libiscsi: Remove unneeded code

 drivers/scsi/be2iscsi/be_main.c  |   26 ++--
 drivers/scsi/bnx2i/bnx2i_hwi.c   |   46 ++++----
 drivers/scsi/bnx2i/bnx2i_iscsi.c |    8 +-
 drivers/scsi/iscsi_tcp.c         |   22 ++--
 drivers/scsi/libiscsi.c          |  226 ++++++++++++++++++++------------------
 drivers/scsi/libiscsi_tcp.c      |   71 +++++++-----
 drivers/scsi/qla4xxx/ql4_isr.c   |    4 +-
 include/scsi/libiscsi.h          |   17 ++-
 include/scsi/libiscsi_tcp.h      |    2 +
 9 files changed, 228 insertions(+), 194 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to