|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI: Check Condition and ResidualsSantosh Rao wrote: > > It sounds to me like there is a mis-understanding here on who owns the > "RESID" field. > > FCP-2 makes it clear that it is the FCP-2 SCSI LLP in the target that > should initialize this field based on FCP_DL and its state information > on the bytes transferred. IOW, this is a field owned by the scsi > transport and should be initialized/computed by the scsi transport. (See > FCP-2 Rev 07a Section 9.4.8). Saying ``owned by the scsi transport'' is incomplete. A number of players may be interested in the residual count and can take action appropriately. From the transport to the user app initiating the IO. That is, residuals are not ``transport-exclusive''. And so, iSCSI does the right thing by providing _mechanism_ to report them, should there be any reported by the players underneath the iSCSI Target. But going as far as what you're suggesting may be too restrictive. On top of that I don't see any problems with the way FCP-2 puts it. As I said before we're at par with it. > It sounds like folks here are assuming the the SCSI device server is > going to provide this information to the iSCSI LLP layer in the target > and the iscsi target layer would then copy this information into the > Response PDU. There is quite a few things you have to communicate _with_ BEFORE you get to talk to the actual SCSI device server. _Anyone_ of those can set a residual for any number of things. (See my original reply-post on residuals in the thread ``Re: iSCSI: plugfest4 issues'' dated Tue, 30 Jul 2002 23:54:49 -0400.) > It is upto the iSCSI layer to initialize the RESID field anytime a data > underflow or overflow condition occurs. Yes. > Perhaps, the RESID field > definition should provide guidelines on how the iscsi target layer > should compute the RESID, as is done by FCP-2 Section 9.4.8. iSCSI does specify enough. Nothing is needed. Matter closed. -- Luben
Home Last updated: Fri Aug 09 20:18:53 2002 11599 messages in chronological order |