Daniel Smith wrote:
> 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.
The point was that in order meet the low cpu utilization, the implementation
would have to be offloaded. Of course the urgent pointer is not required to
enable offloading, however, read on.
>
>
> > - 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.
For 10Gbps links you will need lots more than 1meg of memory to handle all the
potential connections in the presense of lost frames.
>
>
> > 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. Should there have been a PDU header in the dropped frame,
> then the segment will need to be buffered until the PDU header arrives. 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.
Framing is not meant for processing command PDUs. It's meant to process DATA
PDUs so that the data can be placed properly into the iSCSI buffers in the host,
rather than piling up on the adapter. Once the missing PDU header does arrive,
now the adapter has the task of dumping to the host all the buffered data plus
all the new data coming in from the link. This puts a real bottleneck on the
backplane.
> 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.)
Like I said, the framing is for placing data, not commands.
> 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
-Matt
