Re: iSCSI: need for new data SNACK code?

["Mallikarjun C." <cbm@rose.hp.com>]

[ Catching up on my email after a weekend site power shutdown....]

Randy,

Please refer to my old email to Eddy:

  http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10674.html

It required the following -
    a) target must always send MaxRecvDataSegmentLegth sized data-in 
        PDUs except possibly for the last PDU.
    b) *if* a PDU size change happens during the life of  a task, target
         notes the DataSN (let's say "size_changed_from") when that happens.
    c) connection (*not* the task) maintains the current and previous 
        MaxRecvDataSegmentLength (let's say "PDU_size_history", an array of size 2).
    d) if "n" PDU size changes are to be designed for, during the life of a task,
        make the "size_changed_from" into an array of size n, and make the
        "PDU_size_history" an array of size (n+1).

I believe one doesn't need to maintain exhaustive DataSN-to-PDU_size tuples
for all PDUs for all active tasks as David's revised description implied.  IOW,
what I am suggesting is that a target can translate a DataSN to a buffer offset
(even with PDU size changes) with *much* less metadata, *if* it always sends 
MaxRecvDataSegmentLegth sized data-in PDUs except possibly for the last PDU.
Any retransmission request would have to take the aforementioned size_changed_from
and PDU_size_history arrays into consideration, and calculate the buffer offset 
accordingly.

Agreed, this is additional CPU cycles where a simple (and memory-consuming)
tuple table could be faster - but it's exception processing, speed is not much of
a consideration here.

Hope that explains my earlier response.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668 
Roseville CA 95747
cbm@rose.hp.com


----- Original Message ----- 
From: "Randy Jennings" <randyj@data-transit.com>
To: "Mallikarjun C." <cbm@rose.hp.com>; <Black_David@emc.com>
Cc: <ips@ece.cmu.edu>
Sent: Friday, July 12, 2002 5:06 PM
Subject: RE: iSCSI: need for new data SNACK code?


> > > The flag per task is not needed - I'd expect the Target to look
> > > at the Data PDUs it would have to resend, check them against the max
> > > Data PDU size for this connection and fail the regular SNACK if any
> > > PDU is too large
> >
> > I am afraid there's no free lunch here.  In this description, you're now
> > expecting targets to maintain the PDU size of every PDU that it shipped
> > for each of the tasks, which causes a metadata explosion.  This
> > was discussed
> > by Eddy Quicksall and myself in an earlier thread - "changing
> > MaxPDUDataLength".
> 
> I did not check the thread, but I remember your conversation with Eddy
> Quicksall.
> 
> However, I do not remember what was said about knowing the length of the
> PDU.  From this isolated discussion, though, it seems like you would at
> least be able to recalculate the length of the PDU at all times or you could
> never send it again.  (Unless you redid all the steps that got to that point
> in the first place, and I do not think that is possible based off a PDU id
> number...)
> 
> Am I missing something?
> 
> Sincerely,
> Randy
> Data Transit
> 
>