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

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

Santosh,

As I said, this is an endless debate. I don't think
everything can be optimized out of the code path.
I apologise in advance for not responding any more
to this thread.

Somesh

> -----Original Message-----
> From: santoshr@cup.hp.com [mailto:santoshr@cup.hp.com]
> Sent: Friday, October 12, 2001 5:20 PM
> To: somesh_gupta@silverbacksystems.com
> Cc: ips@ece.cmu.edu
> Subject: Re: iSCSI: SCSI Iniitator port: a simple approach, acceptable?
>
>
> Somesh Gupta wrote:
>
> > > 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?
>
> I think the above can be optimized out by some proper design. I don't
> think locking or cache thrashing are significant performance inhibitors
> that cannot be worked around in this case.
>
>
> >
> >   This does not include the cost/complexity of managing multiple queues,
> >   (and additional cache lines to share)
>
> What multiple queues ? (I don't see any major issues here either.)
>
> >   and the fact that the "rare" retransmit has the potential to slow
> >   everything down to the speed of the slowest connection.
>
> But, this is not a drawback of multi-connection session. It is a
> drawback due to the fact that the iscsi protocol chose to impose strict
> command ordering across the session [,which is not really required. But,
> I won't start that thread again !].
>
>
> > >
> > >
> > >
> > > 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
> ##################################
>