|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: Flow ControlDavid, In your example C1, C2, D1, D2 will always work (as will any ordered combination). The troublesome situation is C1, C2+D2 (immediate), C3 (window closed) followed by an R2T for D1. This is why I think we should either explicitly forbid immediate data if R2T is enabled or specify that this behavior may get an initiator into trouble. Julo David Robinson <David.Robinson@EBay.Sun.COM> on 21/09/2000 03:13:05 Please respond to David Robinson <David.Robinson@EBay.Sun.COM> To: ips@ece.cmu.edu cc: (bcc: Julian Satran/Haifa/IBM) Subject: RE: iSCSI: Flow Control > I'm not a s/w engineer, so I could be getting myself into trouble here, > but I still see an issue.... > > iSCSI will not know whether the next PDU in the TCP buffer is a command > or data PDU until it actually reads the data. iSCSI should NEVER stop > reading > data from TCP or else deadlock if the next message is a data PDU (as was so > eloquently explained to me in a prior message). It must continue reading > data (thus emptying the TCP receive window), and if the SCSI command queue > is full, then SCSI will respond with TASK SET FULL. This works okay > (depending > on who you ask) in a parallel SCSI or FC world where latency is measured in > us, > but in iSCSI it could be 100ms and 1000+ commands later before the initiator > ever finds out. The TCP connection can have either a command or data. In either case reading a short fixed amount of data can determine if it is one or the other. With a single connection I can only see deadlock occuring if the initiator sends Command1, Command2, then Data1 on a single command/data connection. With a single connection this seems like a broken initiator as doing the right thing of C1, D1, C2 shouldn't be any more expensive and it is definately safer. Well one other case can occur is if the initiator wants the target to issue an RTT and it interposes another command before the RTT is received, this too seems like a broken things to do as I don't see much value in doing RTT on a single connection. In the multiple connection asymettric case this isn't an issue as data is never interleved with commands. So is there a fundamental requirement that the target must handle the case of C1, C2, then D1? It seems easy to just write the iSCSI initiator to never issue such a sequence and if the target gets one return an error when C2 arrives before D1. It again seems like we are trying to impose or solve datagram problems in a stream world. Does parallel SCSI have this problem? -David
Home Last updated: Tue Sep 04 01:06:58 2001 6315 messages in chronological order |