Subject: RE: iscsi : default iscsi mode page settings.

From: "Elliott, Robert" <[email-masked]>
Date: Sun, 23 Sep 2001 19:09:25 -0500

> -----Original Message-----
> From: Santosh Rao [mailto:[email-masked]]
> 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
[email-masked]

---

From: Santosh Rao <[email-masked]>
Date: Mon, 24 Sep 2001 12:44:34 -0700

> with the same meaning when presented through an iSCSI bridge

Rob,

Is the un-solicited data support offered by an iSCSI bridge tied to its
back end target's ability to support the same ?

My understanding is that the immediate data and un-solicited data
buffering limits are a measure of the iscsi bridge's buffering
capabilities and settings like FirstBurstSize and DataPDULength are
properties of the iscsi bridge rather than its back end targets. Why,
then, would it be interested in forwarding the mode sense/select to the
back-end device ? Rather, it would be attempting to filter out such
commands from the command stream destined to the back-end target and
process such commands within the bridge.

(Example : Is an iscsi bridge that is supporting back-end pSCSI devices
and older gen FCP devices that do not support FirstBurstSize prevented
from the use of un-solicited data. ? )

IMO, using the mode select/sense for setting these attributes, rather than
iscsi login keys implies MORE work for iscsi bridge developers since they
need to snoop and intercept these mode sense/select, rather than have them
negotiated/queried thru iscsi means such as login keys. They may also need
to take action preventing such mode select/sense CDBs from being delivered
to its back end for the same reason.

Regards,
Santosh