|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: twist on iSCSI asymmetric modelKalman, I am not sure what your new suggestion solves. Especially if what Charles wrote is correct: {Snip} "2. As I recall (possibly not very accurately) SAM-xx states that an initiator should not have more than one pending task management request at a time. In general, such requests are "think-time" limited and therefore non blocking, so this seems not to be a problem in practice. 3. It's important that this set of control functions flow over the same control connection that's used for commands (ie. these functions need to flow through the command delivery pipe). Otherwise their behavior is indeterminate. An example is an "abort task" function which arrives at the target while the command to be aborted is still in transit. 4. Considering the rule of allowing only one pending task management request at a time, it might be sufficient to have the initiator budget one "credit" to be used for this purpose." {Snip} (His use of Credit here meant a reserved Buffer) I believe that you also have determined that Two connections per Session Solves the key problems (especially if what Charles said is correct,) and they are on the same NIC, since you said ".... If the control and data connections happen to be on the same NIC, then this might not be a problem". This, I believe, is the point that Matt has been trying to make. He felt that two connections per session were key and should be required. So lets put it all together; Control should flow on the same connection as Commands, and Data on a separate connection (within the same session). This solves the blockage issue, and both connections within the same NIC solve the interrupt problem. Plus it does not have iSCSI sliding windows etc. etc., the implementation is relatively easy, compatible with the concept of iSCSI HW on the NIC, and the Wedge Drivers still work as they do today. Based on that, I think Matt has a strong point. What do you think? You also added (on your last Paragraph) a statement that I think takes us in a different direction "...Only one interrupt is required upon completing a READ data transfer, if we mark the last iSCSI Data PDU of the data transfer". I am not sure what you are attempting to say here, are you making a new recommendation? In any event, please address the previous questions, before you amplify your last paragraph. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSD San Jose Ca (408) 256-0403, Tie: 276-0403 Internet address: hufferd@us.ibm.com Notes address: John Hufferd/San Jose/IBM @ IBMUS VM address: hufferd at IBMUSM54 meth@il.ibm.com@ece.cmu.edu on 09/28/2000 06:30:58 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: twist on iSCSI asymmetric model In the asymmetric model, one TCP connection (the control connection) is used for sending all of the commands, thus ensuring ordered delivery of the SCSI commands. If (a large amount of) data is also sent on the control connection, there is the possibility that the data would fill up the window, and critical task management requests couldn't get through. On the other hand, it has been pointed that some implementations will prefer a single (and only) TCP connection for both commands and data. I would like to suggest the possibility of combining these 2 cases; either (1) have a single connection for everything or (2) have one connection for control and one or more data connections. In this case, no (WRITE or READ) data may be sent over the control connection. The initiator and target negotiate during the first login as to which of the 2 possibilities they will use. In (1), it is the responsibility of the initiator to worry about not overloading the one and only connection so as not to delay delivery of critical task management messages. In (2), the iSCSI SCSI Command PDU specifies which data connection to use for the data of this command. On the data channels, where we will have iSCSI Data and R2T PDUs, we shouldn't need to use the long headers that we use to specify an iSCSI SCSI Command PDU. We will therefore have a shortened header for the data channels. In (1), since data will travel on the control channel, the iSCSI Data PDU and R2T headers will be padded with zeros so that all headers are of the same length on a particular connection. The use of R2T is negotiated during the first login of the iSCSI session. If R2T is to be used, then the initiator may not send data before it is requested by the target. Thus there will always be buffers ready to accept the data. If the target agrees to not use R2T, then the target implicitly agrees to have some number of buffers available to receive data sent by the initiator, even if the data arrives before the command arrives. In this case the initiator MUST send data in the data connections in the same order that the corresponding commands were sent. (This avoids deadlocks.) If the target runs out of buffers, then it will let data back up in the TCP window of the data connections, while it is processing the data from earlier commands. The only main drawback remaining with the asymmetric model is that 2 separate operations may be required to set up sending a command and to register its DMA buffers. If the control and data connections happen to be on the same NIC, then this might not be a problem. Only one interrupt is required upon completing a READ data transfer, if we mark the last iSCSI Data PDU of the data transfer. - Kalman Meth.
Home Last updated: Tue Sep 04 01:07:00 2001 6315 messages in chronological order |