RE: Avoiding deadlock in iSCSI

["Prasenjit Sarkar/Almaden/IBM" <psarkar@almaden.ibm.com>]

Actually, because of interrupt coalescing in Gigabit Ethernet adapters, you
can
have potentially close many SCSI transactions with one interrupt.

However, you have hit the nail on the head, parallelism tends to (I'm not
saying will always) increase the average number of interrupts per
transaction
if the parallelism decreases the possibility of interrupt coalescing.

And since interrupt coalescing is a statically determined parameter (in
current implementations), getting speedups out of parallelism is harder
than
it appears.

Anyways, I dont want to distract the discussion on symmetric and assymetric
connections..


Robert Snively <rsnively@Brocade.COM>@ece.cmu.edu on 09/15/2000 12:34:01 PM

Sent by:  owner-ips@ece.cmu.edu


To:   Kalman Meth/Haifa/IBM@IBMIL, Pierre Labat <pierre_labat@hp.com>,
      ips@ece.cmu.edu
cc:
Subject:  RE: Avoiding deadlock in iSCSI




This concerns me a little bit.  In all other versions of SCSI
(FCP, Parallel, etc.) there is a maximum of one completion interrupt
per complete SCSI task, regardless of the number of data information
units or linked commands executed.  That is provided at the time the status
(and autosense data if any) for the last command in the I/O operation
is presented.  The use of the word maximum allows for the possibility of
processing multiple SCSI completions if there happens to be more than
one completed during the time the interrupt context is active.

I hope we can expect the same behavior of iSCSI.

Bob

>  The current iSCSI draft allows for (successful) status to be
>  sent with the
>  last data PDU. This should also be done in the asymmetric
>  case, precisely
>  for the reason articulated by Pierre. The NIC receiving the
>  data will know
>  when to perform the interrupt when the data transfer has
>  completed and
>  return a good status, and only one interrupt will be
>  required to complete
>  the data transfer. (The data buffers are registered to the
>  NIC together
>  with the Initiator Task Tag [or Transfer Tag], so successful status
>  received on the data NIC can be easily associated with the original
>  command, and there is no need for an interrupt on the command NIC.)