|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: Question On R2T Behaviour?Suresh, The only statement that can be made is that the target is the master of the data transfers. For the case you describe any of the behaviors you describe is legal. The behavior is defined by SSCSI (SAM). The results are implementation dependent. The only think that we might say is that the results "should match expectation" and "the residual counts should match transfers". In practical terms you will find many targets that will terminate the transfer with an error status if an R2T request is not properly fulfilled. Julo "Suresh Tanjore" <sureshtk@aarohicommunications.com> Sent by: owner-ips@ece.cmu.edu 16-11-01 19:39 Please respond to "Suresh Tanjore" To: <ips@ece.cmu.edu> cc: Subject: Question On R2T Behaviour? Hi all, On page 75 of iSCSi 0.8 revision " The data length of the DATA PDU MUST *not exceed* the desired data transer length specified in the R2T. If the R2T is answered with a sequence of data PDUs the buffer offset and Length must be within the range of those specfied by R2T, the last PDU SHOULD have the F bit set to 1. The data-out PDU ordering is goverened by DataPDUInOrder." My question is if the data length of the DATA PDU is less than the desired data transfer length and the F bit is set, what should be the behaviour of the target. For the sake of this discussion let us assume DataPDUInOrder to be set to Yes. 1. It looks intutive that target may send another R2T with different sequence number and collect the data initially that the host was not able to send for the previous R2T request. Or 2. It is an error that need to be detected by target that the host was not able to fully satisfy the R2T request sent by the target in the first place. Please let me know what is the right behaviour and should this be documented in the specification if it is not already documented. If it is documented may be i missed reading this, please point to me where it is defined. Thanks sureshtk
Home Last updated: Sun Nov 18 10:17:57 2001 7845 messages in chronological order |