|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: Bidirectional SCSI commands and iSCSIJim, Both the examples you gave have something peculiar - the operations are to executed really in sequence (we are no talking about full duplex I/O operations?). I any case, in order no to extend excessively the headers we can either introduce a "next header" field (as in IP V6) or split the operation at the iSCSI level into two phases - each carrying its parameters and each ended with a status - like: - out XOP1, XOP2, OD1, -in S1, ID, S2 In any case commands having only a parameter set (fixed or variable) - like those for the object disk should be handled with the parameters sent as immediate data (as with the three party commands) - parameter size will probably be limited and the performance requirement will be similar to those of block read/write. Do we need for those to care also about residual counts for parameters? Julo "Jim Hafner/Almaden/IBM" <hafner@almaden.ibm.com> on 29/09/2000 00:21:32 Please respond to "Jim Hafner/Almaden/IBM" <hafner@almaden.ibm.com> To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: Bidirectional SCSI commands and iSCSI Julo, The primary motivation is for object-based storage devices (OSDs). The protocol that seems to be needed in that environment is the ability to send a CDB, plus some parameter data (DataOut) AND get back read-type data (DataIn) in the same command sequence. One (non-OSD) command has been proposed in T10 for an XOR type XDREADWRITE command. SAM-2 has now allowed for such commands in the architecture. From this perspective, it is completely symmetric. Transports that support this feature will need to have data structures in there PDUs or IUs (or whatever) to indicate things like DataOut datalength, DataIn datalength, possible virtual addresses for each buffer, etc. In other words, there will potentially be two active buffers (on each end) for use with the same command. So, e.g., iSCSI PDU may need to have both "DataIn expected data transfer length" and "DataOut expected transfer length" fields. I'm assuming that the data direction in the existing iSCSI PDU is derived from the SCSI opcode, unlike FCP where there are fields to indicate the data direction. (I am surprised not to find such things in the iSCSI Command PDU.) There are two proposals in T10 to enable this feature in SPI-4 and in FCP-x (probably FCP-3). Jim Hafner julian_satran@il.ibm.com@ece.cmu.edu on 09-28-2000 12:10:53 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: Bidirectional SCSI commands and iSCSI Jim, What is the intended use? Are there already commands that use it? Is there a major/minor distinction - like output data & input results or output parameters & input data - or is it intended to be completely symmetric? Julo "Jim Hafner/Almaden/IBM" <hafner@almaden.ibm.com> on 20/09/2000 17:56:27 Please respond to "Jim Hafner/Almaden/IBM" <hafner@almaden.ibm.com> To: ips@ece.cmu.edu cc: (bcc: Julian Satran/Haifa/IBM) Subject: Bidirectional SCSI commands and iSCSI Folks, In case you missed this, T10 just approved changes to SAM-2 (rev14) which remove the restriction that a single SCSI command can have a data flow in only one direction (DataIn xor DataOut). Transport specs (that want to allow this) will need to change to allow for two sets of Data buffer fields in the headers (length, over/underrun, etc.). Is anybody looking to modify the iSCSI spec to get these concepts supported? Jim Hafner
Home Last updated: Tue Sep 04 01:06:56 2001 6315 messages in chronological order |