Re: ISCSI: Urgent pointer consensus

[Matt Wakeley <matt_wakeley@agilent.com>]

Matt Wakeley wrote:

> 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

This should say "rx r2t for A" gets lost...

>

>
> 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