|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iscsi : iscsi parameter default valuesThe one that I have trouble living with is ImmediateData. This is important for low-end desktops and hardly matters for large boxes. As such I would suggest it stays as yes. Julo "Eddy Quicksall" To: "'Santosh Rao'" <santoshr@cup.hp.com>, <EQuicksall@med <ips@ece.cmu.edu> iaone.net> cc: Sent by: Subject: RE: iscsi : iscsi parameter default values owner-ips@ece.c mu.edu 27-09-01 17:22 Please respond to "Eddy Quicksall" I like your defaults below. But, section 5 says: The initial Login request MUST include the InitiatorName and SessionType key=value pairs. Since SessionType is REQUIRED, naming a default would imply a possible typo in the spec. Eddy -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Wednesday, September 26, 2001 10: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
Home Last updated: Fri Sep 28 18:17:19 2001 6838 messages in chronological order |