RE: iSCSI: need for new data SNACK code?

["Randy Jennings" <randyj@data-transit.com>]

Fair enough.  That is actually what I meant about being able to recalculate
it somehow; although, I did not have it developed quite so neatly.  However,
your argument applies to both the previous discussion, and also seems to
fall in David's favor, because the necessary state would need to be saved
anyway (for any retransmission to happen).

I guess what I was confused about is how this argues against having another
opcode for the SNACK and against the target being the one catching the error
condition.

Sincerely,
Randy Jennings
Data Transit

> -----Original Message-----
> 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.
>
> > > > 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".
> >
> > 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...)