RE: iSCSI sessions: Let's try again

["Douglas Otis" <dotis@sanlight.net>]

Charles,

MaxCmdRN - the maximum number to be shipped - defines the queuing capacity
of the receiving iSCSI. CmdRN can take any value from ExpCmdRN to MaxCmdRN
except 0.

iSCSI targets are required to provide ExpCmdRN and MaxCmdRN values that will
enable the initiator to make progress.

I do not like mixing EE with BB controls as it requires far greater effort.
:(

Doug
-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Binford, Charles
Sent: Tuesday, October 03, 2000 1:05 PM
To: IPS Reflector
Subject: 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
> >
> >
>
>