RE: iSCSI: SCSI Iniitator port: a simple approach, acceptable?

["Somesh Gupta" <somesh_gupta@silverbacksystems.com>]

> -----Original Message-----
> From: santoshr@cup.hp.com [mailto:santoshr@cup.hp.com]
> Sent: Friday, October 12, 2001 4:10 PM
> To: somesh_gupta@silverbacksystems.com
> Cc: ips@ece.cmu.edu
> Subject: Re: iSCSI: SCSI Iniitator port: a simple approach, acceptable?
> 
> 
> Somesh,
> 
> I don't understand your concern voiced below. 
> 
> A session spanning multiple adapters requires the host resident session
> manager to co-ordinate assignment of initiator task tag, cmdsn,
> exp_cmdsn & max_cmdsn, [over and beyond the usual initiator name &
> ISID/TSID].
> 
> The initiator task tag & cmdsn can be passed down from the session
> manager to the HBA in a mailbox command, as a part of issuing a new
> iscsi command, and the (exp_cmdsn, max_cmdsn) values can be updated to
> the host resident session manager by the HBA as a part of conveying a
> mailbox command completion. There are no extra host interrupts in normal
> I/O paths due to the presence of a host resident session manager.
> 
> If you're referring to locking overheads, then, these can be optimized
> out.

  You sort of answered the question yourself. As a cache line (containing
  common numbers) ping-pongs
  between processors that handle interrupts for different adapters, its
  adds significant overhead. A 2GHz processor in a CC-Numa box sharing
  cache lines between multiple processors?

  This does not include the cost/complexity of managing multiple queues,
  (and additional cache lines to share)
  and the fact that the "rare" retransmit has the potential to slow
  everything down to the speed of the slowest connection.

  We will see. I don't think this debate is going to be solved
  by discussion. People will even obtain different results from
  experiments.

> 
> I don't see why a host resident session manager affects performance of a
> multi-connection session ? 
> 
> Regards,
> Santosh
> 
>  
> 
> Somesh Gupta wrote:
> > 
> > Jim,
> > 
> > Multiple connections, especially when spread across multiple
> > adapters will give performance that will be much less than
> > that of multiple sessions in parallel (of course when there
> > are multiple connections/session over multiple adapters - the
> > adapters have to be able to take the session id from the
> > host software - I obviously don't get the point of the debate).
> > 
> > There is no way a common synchronization point for
> > command sequencing and flow control at the host level will not
> > cause sub-standard performance. I have argued this point
> > many times before, only to have it be brushed aside. Of course,
> > only time will tell.
> > 
> > Somesh
> > 
> 
> 
> -- 
> ##################################
> Santosh Rao
> Software Design Engineer,
> HP-UX iSCSI Driver Team,
> Hewlett Packard, Cupertino.
> email : santoshr@cup.hp.com
> Phone : 408-447-3751
> ##################################
>