RE: iscsi : default iscsi mode page settings.

["Julian Satran" <Julian_Satran@il.ibm.com>]

It has exactly the FCP-2 meaning. Julo


                                                                                              
                    "Elliott, Robert"                                                         
                    <Robert.Elliott@c       To:     "IPS Reflector" <ips@ece.cmu.edu>         
                    ompaq.com>              cc:                                               
                    Sent by:                Subject:     RE: iscsi : default iscsi mode page  
                    owner-ips@ece.cmu        settings.                                        
                    .edu                                                                      
                                                                                              
                                                                                              
                    24-09-01 02:09                                                            
                    Please respond to                                                         
                    "Elliott, Robert"                                                         
                                                                                              
                                                                                              




> -----Original Message-----
> From: Santosh Rao [mailto:santoshr@cup.hp.com]
> Sent: Friday, September 21, 2001 2:27 PM

> > If an initiator cares about any settings it better run MODE SENSE
> > to set them.  In a multi-initiator environment with various kinds

(I meant both MODE SENSE and MODE SELECT)

> > of reset events occuring on the SAN, an initiator can't be sure
> > of the state of a mode page.  (see the tape problem discovered by
> > Veritas in FCP-2 public review; tape mode pages were reset without
> > the knowledge of the application, breaking backups).
>
> Isn't this all the more reason to avoid setting FirstBurstSize
> through a mode page and use a login key for this ? Shared mode
> pages can cause some strange side effects on I/Os that are
> using un-solicited data.

If there were not already a FirstBurstSize for other protocols
controlled by the mode page, I'd agree - these protocol-specific
fields shouldn't be controlled by mode pages, which can be
changed by applications at any time.  They ought to be properties
of the login session and controlled only by the iSCSI drivers.

However, it has been defined this way for other protocols, so
I think a compatible control is needed for iSCSI.  This makes
protocol bridges simpler, and will avoid confusing software that
does try to use these mode pages.  A page that appears when
a FC target is connected to a host via FC should also appear
with the same meaning when presented through an iSCSI bridge
via Ethernet.

As Sanjeev noted in another email, this mode page is LU specific
which would be hard to emulate in the login key approach.

> > > Logical Unit Control Mode Page
> > > ==============================
> > > ...
> > ...
> Does the EPDC bit verify the CRN capabilities of both the target
> FCP layer and the target SCSI ULP (device server) ? One would think
> the capabilities of the 2 layers need to be checked through seperate
> bits. The device server's ability to support CRN is a SCSI ULP
> feature and seems more like a bit in the Control Mode Page.
> (does not exist today ?). The target FCP's CRN capability is
> tested through the FCP specific EPDC bit in the FCP
> specific lun control mode page.

The CRN is carried as part of the IU (aka PDU), so I think of it as
part of the iSCSI layer, not the SCSI layer.  Stuff in the CDBs
is what the SCSI layer deals with.  Enabling or disabling CRN is
done through a mode page, which is SCSI layer activity.  For
protocol-specific mode page fields (like EPDC and FirstBurstSize)
the SCSI layer has to talk to the iSCSI layer to read/write the
controls.

The disconnect-reconnect mode page has fields that can apply to
most different protocols like FirstBurstSize.  Provided the
semantics are the same, any protocol offering those features should
use the mode page to control them.

New issue
=========
iSCSI's FirstBurstSize does appear to have one difference from
that described in SPC-2 and FCP-2: iSCSI-07-90 requires the entire
transfer fit in the FirstBurstSize if enabled, while SPC-2/FCP-2
have no such restriction.  I'd like to see it work the same as
the other protocols.

iSCSI:
"It is also an error for an initiator to send more data, whether
immediate or as separate PDUs, than the SCSI limit for first
burst."

SPC-2:
"The FIRST BURST SIZE field indicates the maximum amount of data that
may be transferred to the target for a command along with the command."

FCP-2:
"...If the maximum amount of data has been transmitted, but more data
remains to be transferred, the target shall request that data with
subsequent FCP_XFER_RDY IUs."

---
Rob Elliott, Compaq Server Storage
Robert.Elliott@compaq.com