Re: ISCSI: Why the use of the Urgent Pointer

[Daniel Smith <dfsmith@almaden.ibm.com>]

Matt Wakeley wrote:
> 
> If we review the iSCSI Requirements document it requires:
> 
> - Low CPU utilization, equal to or better than current technology.

Reveiwing further (from the July 7 document,
http://search.ietf.org/internet-drafts/draft-haagens-ips-iscsireqs-00.txt)
the wording is "iSCSI must make it possible to build I/O adapters that handle
an entire SCSI task, as alternative SCSI transport implementations do."  If
you are arguing that this requirement cannot be met without the urgent
pointer, then I am extremely interested to read your arguments.  Any adapter
that understands TCP and iSCSI also knows where to place the data and where
the boundaries are.

> - Cost competitive with alternative storage network technologies.

Gigabit ethernet cards with two CPUs and a megabyte of memory on board have
been less expensive (retail quantity one) that FC for a long time now.  Is
this about to change?  I would hazard a guess that requiring urgent flag
processing in the new generation of ethernet adapters will slightly increase
price if anything.  I may be wildly inaccurate on this point though.

> The urgent pointer mechanism in the current draft provides the framing
> mechanism so that data can be placed properly in the presence of dropped
> frames.

The segment arriving after the dropped frame will have the TCP sequence
number in it, and the adapter will know exactly where to place it is memory
if it is part of a data transfer.

Should there have been a PDU header or headers in the dropped frame, then
the segment will need to be buffered until the PDU header(s) arrive(s).  The
urgent pointer would allow the delivery port to process the subsequent PDU
without waiting for the lost segment.  However...

1) it wouldn't do this because (in all likelihood) the CmdRN would be out of
sequence.

2) it wouldn't do this because the "lost" PDU(s) may have had (a) really
important command(s) that would affect subsequent operation of the commands. 
(E.g., change tape recording density.)

3) it might do this if the out-of-order PDU is destined for a different
logical unit.  Assuming the target can guarantee that the lost PDU wasn't
for that very same LU, or, say, an enclosure LU that would affect the
destination LU (e.g., remap LUN x to y).  Very risky.

Don't get me wrong, the urgent pointer is a good idea.  It's just rather
hairy to actually make good use of.  I'm not sure I'd trust an adapter that
does out-of-order processing without having written the drivers myself.  B-)

Daniel Smith.
-- 
IBM Almaden Research Center, 650 Harry Road, San Jose, CA 95120-6099, USA
K65B/C2 Phone: +1(408)927-2072 Fax: +1(408)927-3010


-- 
IBM Almaden Research Center, 650 Harry Road, San Jose, CA 95120-6099, USA
K65B/C2 Phone: +1(408)927-2072 Fax: +1(408)927-3010 Home: +1(408)227-5786