RE: iSCSI sessions: Let's try again

["Binford, Charles" <cbinford@lsil.com>]

Title: RE: iSCSI sessions: Let's try again

Doug,
  What "command window" are you referring to?  I know of no such mechanism in SCSI.  Does "this scheme" refer to something in iSCSI that will regulate the flow of new commands to a target, something is generic SCSI (i.e. SAM/SPC-2, etc), or something in TCP?

Charles Binford
LSI Logic Storage Systems
(316) 636-8566

> -----Original Message-----
> From: Douglas Otis [mailto:dotis@sanlight.net]
> Sent: Tuesday, October 03, 2000 12:41 PM
> To: Matt Wakeley; IPS Reflector
> Subject: RE: iSCSI sessions: Let's try again
>
>
> Matt,
>
> From the little I understand, there is a command window built
> into this
> scheme which should act as a means to regulate flow of
> commands.  You should
> not need an additional connection to perform that function. 
> I do not think
> stuffing receive buffers is a good technique but it is a good
> system test.
>
> Doug
>
> > -----Original Message-----
> > From: owner-ips@ece.cmu.edu
> [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > Matt Wakeley
> >
> Sent: Tuesday, October 03, 2000 12:37 AM
> > To: Douglas Otis; IPS Reflector
> > Subject: Re: iSCSI sessions: Let's try again
> >
> >
> >
> >
> > Douglas Otis wrote:
> >
> > > > Reasons requiring 2 tcp connections per iSCSI session (one for
> > > > commands the
> > > > other for data):
> > > >
> > > > 1- It allows a target to temporarily flow control commands from
> > > > the initiator
> > > > while still allowing data to continue on the "data"
> > connection (allowing
> > > > commands to complete so that the flow control can be
> opened again).
> > >
> > > How do you go about managing the buffers of these
> connections using TCP?
> >
> > Doug, even you know that if you stop reading <in this case the
> > commands> from
> > the TCP stream, TCP will eventually stop the initiator from
> > sending commands.
> > Thus, if the SCSI command queue fills up, the target stops
> > reading from TCP,
> > which eventually shuts down the initiator from sending more
> commands.
> >
> > -Matt
> >
> >
>
>