Re: ISCSI: Urgent pointer consensus

[Matt Wakeley <matt_wakeley@agilent.com>]

Daniel Smith wrote:

> Matt Wakeley wrote:
> >
> > placed.  If you lose an iSCSI PDU header due to a lost TCP segment, you
> > lose iSCSI PDU framing from then on (until the missing segment is
> > received).  You then have to store the TCP data (received after the
>
> Ah!  Now I am beginning to see how your implementation works.  In your view,
> a write CDB for 128MB would have a sequence like...
>
> send CDB PDU
> rx R2T for 1MB          (rx=receive)
> send 1MB
> rx R2T for 1MB
> send 1MB
> ...
> rx status PDU

Actually, I see something more like:

send CDB PDU A
send CDB PDU B
rx r2t for A
send CDB PDU C
rx data for B (512-4K typically)
send data for A
rx data for C

In other words, lots of I/Os with lots of small (no longer than a few K) iSCSI
messages going in both directions.  Typical disk I/Os are not in the megabytes.
That way, if "rx data for A" gets lost, the data for B and C (and all the others
that will arrive - there could be 10's or 100's of commands outstanding) can be
placed in their dedicated I/O buffers before A is retransmitted.

-Matt

>
>
> ... whereas some of us imagine something like...
>
> send CDB PDU
> rx R2T for 128MB
> send 128MB
> rx status PDU
>
> For short transactions (<1MB) the urgent doesn't help much because R2Ts will
> cover the whole amount of data.
>
> For long transactions (>1MB) there may be some benefit, although with all
> those R2Ts flying about TCP may lose streaming metrics.  Hmm, I'll give it
> more thought, but this still seems very specialized and closely tied in with
> your (and others) implementation view.
>
> 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