Re: iscsi : default iscsi mode page settings - Consensus call

[Santosh Rao <santoshr@cup.hp.com>]

Rob,

Some comments inline.

Regards,
Santosh


"Elliott, Robert" wrote:


> If an iSCSI initiator is talking to a FC target through an
> iSCSI to FC bridge, the target will include these mode pages.

The back-end target may or may not support the mode pages and in most
cases, these will not have the same format across different transport
protocols. For example : 

a) SCSI-FCP targets would not support these mode pages, and a large FC
installed base still uses FCP [and not FCP-2].

b) These mode pages differ for FCP-2, SPI-x & iSCSI. 


> Does the bridge need to intercept the MODE SENSE/SELECT
> commands and hide the presence of these pages? 

Yes, for a few reasons :

1) A bridging device is not limited to the capabilities of its back-end
targets for the support of un-solicited data and thus, need not forward
negotiation of these parameters to its back end targets. Doing so, may
fail the negotiation as well for reasons stated further above.

2) The format of these mode pages differs from iSCSI to FCP-2 to SPI-x.
Hence, a bridge would not be able to forward these mode pages in a
transparent manner in any case.

3) Bridges may be performing virtualization and the targets exported by
an iscsi bridge to an initiator may not have a 1-1 correspondence with
the back end FC/pSCSI targets.


> Does the
> bridge have to generate its own MODE SELECT commands
> on the FC side to match the iSCSI key settings?

I guess this is implementation dependent and is based on the mapping of
the bridge's iscsi targets to its back-end targets, the type of back-end
targets in use, etc.


> 
> Similarly, if a FC initiator is talking to an iSCSI target
> through an FC to iSCSI bridge, and the iSCSI target does not
> have these pages, does the bridge have to create fake pages?
> Without them, it doesn't look FCP-2 compliant.

The bridge will have to fake a number of FC/FCP functionality on behalf
of the back-end iscsi target like PRLI response, PLOGI response,
responses to ELS, etc. This is just one more to that list. Besides, the
mode pages are not identical b/n FCP-2 & iSCSI and hence, the bridge
would need to do some faking anyway, even if iscsi did use the same mode
pages. For example :

a) In the disconnect-reconnect mode page, the bridge would need to fake
values for "Buffer Full Ratio", "Buffer Empty Ratio", "Bus Inactivity
Limit", etc on behalf of a back-end iscsi target.

> 
> I think it's better if iSCSI looks like the other SCSI
> protocols and controls these features with the existing
> mode pages.


> ---
> Rob Elliott, Compaq Server Storage
> Robert.Elliott@compaq.com
> 
> > -----Original Message-----
> > From: Santosh Rao [mailto:santoshr@cup.hp.com]
> > Sent: Thursday, September 27, 2001 11:36 AM
> > To: Julian Satran
> > Cc: ips@ece.cmu.edu
> > Subject: Re: iscsi : default iscsi mode page settings - Consensus call
> >
> >
> > Julian,
> >
> > As we've discussed earlier, SCSI level software looking at transport
> > specific mode pages MUST be aware of the format of those mode
> > pages for
> > the given transport. (For example : The format of the
> > disconnect-reconnect mode page is different for SPI-4, FCP-2, SRP &
> > iSCSI).
> >
> > Thus, any SCSI level software needs to first be upgraded when new SCSI
> > transports come along, before it can understand the mode page
> > formats of
> > that transport.
> >
> > By declaring the iscsi mode page fields as reserved, you would not be
> > breaking any legacy software. There is no legacy issue here.
> >
> > Regards,
> > Santosh
> >
> >
> > Julian Satran wrote:
> > >
> > > Santosh,
> > >
> > > You ignore the fact that there might be SCSI level software
> > that may want
> > > those values.
> > >
> > > Julo
> > >
> > >
> > >                     Santosh Rao
> > >                     <santoshr@cup.       To:
> > "'Black_David@emc.com'" <Black_David@emc.com>,
> > >                     hp.com>               ips@ece.cmu.edu
> > >                     Sent by:             cc:
> > >                     owner-ips@ece.       Subject:     Re:
> > iscsi : default iscsi mode page
> > >                     cmu.edu               settings - Consensus call
> > >
> > >
> > >                     27-09-01 04:02
> > >                     Please respond
> > >                     to Santosh Rao
> > >
> > >
> > >
> > > David,
> > >
> > > By specifying that these values be read-only in mode pages, we have
> > > retained some of the complexity that lies in having to go
> > across layers
> > > to communicate the defaults to the scsi layer, or
> > alternatively to have
> > > the target's iscsi layer snoop for such mode sense commands
> > and respond
> > > to them.
> > >
> > > I would prefer to see iscsi declare these fields as reserved in the
> > > iscsi definition of the mode pages [like is done in SPI-4 for
> > > FirstBurstSize] so that this issue does not arise at all.
> > >
> > > Thanks,
> > > Santosh
> > >
> > > > > If some aspect of the
> > > > > SCSI protocol requires that they be readable via a mode page,
> > > > > the mode page values will be read-only.
> > >
> > > #### santoshr.vcf has been removed from this note on
> > September 27 2001 by
> > > Julian Satran
> >
> > --
> > ##################################
> > Santosh Rao
> > Software Design Engineer,
> > HP-UX iSCSI Driver Team,
> > Hewlett Packard, Cupertino.
> > email : santoshr@cup.hp.com
> > Phone : 408-447-3751
> > ##################################
> >

-- 
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
##################################