Re: iscsi : iscsi parameter default values

[James Smart <james.smart@trebia.com>]

I second the comments made by Charles. Most debates I've participated in for out
of order delivery have been more theoretical than in practice. Given the
tradeoff is significantly simpler/faster implementations for in-order delivery,
especially at the low level hardware, I agree it should be EMDP=0;

I also fully agree with the default login keys proposed by Santosh.

-- James


"Binford, Charles" wrote:

> I strongly agree that EMDP should not "default" to 1.  Two reasons:
>
> 1) as I recently argued on this thread, I think it is invalid for a protocol
> to define a "default" for a mode page - that's not how mode pages work.
>
> 2) **main reason** The whole concept of delivering data out order (for the
> normal I/O, not error recovery) buys a lot of complexity in both initiator
> and target for marginal "improvements" in buffer management and or
> performance.  I'm not convinced most targets gain anything from sending or
> receiving normal I/O data out of order.  Therefore I think it is a mistake
> for iSCSI for force a host to be able to handle the out of order case or
> else issue a mode select *every* time a new session starts up.  Keep it
> SIMPLE.  I fully agree with Santosh that the defaults for login keys should
> be conservative.
>
> Charles Binford
> Pirus Networks
> 316.315.0382 x222
>
> -----Original Message-----
> From: Santosh Rao [mailto:santoshr@cup.hp.com]
> Sent: Wednesday, September 26, 2001 9:29 PM
> To: ips@ece.cmu.edu
> Subject: iscsi : iscsi parameter default values
>
> All,
>
> With the issue of mode page vs. login keys having [almost] drawn to a close,
> I would like to
> raise the below issues again, on the subject of default values for login
> keys and other iscsi
> parameters :
>
>    * In keeping with traditional use of scsi mode pages, iscsi should not
> specify any default
>      settings for any mode pages that continue to exist for iscsi. "Default
> values" for mode
>      pages are target specific and should not be bound to the protocol
> draft.
>
>    * MORE IMPORTANTLY, I read the default for EMDP as being set to 1  :-<
> This implies that
>      targets must be always prepared to deal with out of order data and
> initiators must be
>      prepared to deal with out of order data, unless the initiator performs
> a mode select to
>      disable it. [which defeats all the previous advantages gained thru
> mandating use of login
>      keys for other negotiations.]. A default, if it were to exist, should
> be 0. (in-order, by
>      default).
>
>    * Conservative specification of defaults for login keys along the
> following lines :
>                             MaxConnections = 1
>                             FMarker = "no"
>                             InitialR2T = "yes"
>                             BidiInitialR2T = "yes"
>                             ImmediateData = "no"
>                             DataPDULength = 16
>                             MaxOutstandingR2T = 1
>                             DataPDUInOrder = "yes"
>                             ErrorRecoveryLevel = 0
>                             SessionType = "normal"
>
>    * Should the iscsi protocol require a "Lun Control Mode Page"? IOW, is an
> EnableCRN bit
>      required at the transport layer ? If the device server capability is to
> be negotiated , I
>      suggest this bit be moved to a SCSI ULP Mode Page such as the "Control
> Mode Page", through a
>      T10 change as a part of the SCSI changes being driven by iscsi.
>
> Comments ?
>
> Thanks,
> Santosh
>
> Santosh Rao wrote:
>
> > There are the separate issues of :
> >
> >    * iscsi's specification of defaults for its mode pages which is not in
> line with mode page
> >      usage. This impacts the target's ability to enforce values other than
> the protocol
> >      specified default, if the initiator were to not use mode
> sense/select.
> >
> >    * default settings for login keys.
> >
> >    * Is there a need for the "LUN Control Mode Page" and whether "Enable
> CRN" should be in a
> >      transport specific mode page ?
> >
> > which need to be driven to closure as well.
> >
> > Regards,
> > Santosh