|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: Keep-alive traffic (was iSCSI: more on StatRN)Cheng, You misunderstood my point slightly. There must be a separate flow control above TCP flow control that a specialized adapter must implement. RFC 2960 allows multiple flow controls and is a different subject. Again, what advantage is there in handling a connection probe out of sequence? Doug > > > The adapter treats ACK's and Pings packets separately. It has the > > > intelligence to know the ACK of fibre channel. It could be programmed > to > > > handle iSCSI pings. As that in TCP-zero-copy, with > cooperation from the > TCP > > > driver, the adapter can even be programmed to handle the TCP ACKs > without > > > queuing or waiting. I guess this is a different way of avoiding > blocking. > > > > This is not how a streaming protocol like TCP works, you cannot discard > > TCP segments and then process a later ping. If you toss a TCP segment it > > will keep coming back to you repeatedly until you process it. You won't > even > > see the iSCSI ping until you have processed all the data before > it. Unless > > you want the adapter to understand the ULP (which you said you did not) > > you must pass things up and the ULP must have buffers available or the > > adapter must assert TCP flow control which you said you didn't need to > do... > > A TCP-Offload-Engine will interpret the TCP/IP header in order to > move data > payload directly to application software. Doug has just pointed > out that in > so doing, the adapter must obey the rule of flow control specified by > RFC2960. Since the TOE adapter is going over the TCP/IP header, > all I said > was with changes to the TCP/IP software like that of zero-copy > TCP function, > the adapter can generate ping-response automatically. No, we are not > discarding any unprocessed TCP segments. > > >
Home Last updated: Tue Sep 04 01:06:32 2001 6315 messages in chronological order |