RE: Please read - proposed WG termination

 

From: Michael Krause [mailto:[email protected]]
Sent: Saturday, September 03, 2005 1:24 AM

Large send can be implemented entirely in software and local to the
injection point making it rather trivial to accomplish whille reaping the
performance benefits.   

[dg] This is really interesting ! Why would the performance of a NIC driver
doing LSO/TSO in SW be better than the TCP stack doing it on its own ? I
tend to believe that the TCP stack is highly optimized, especially in the
mainstream path where packet is being constructed. When moving the LSO/TSO
from the OS to the NIC driver, you essentially take the same piece of SW and
just move it somewhere else in the stack. Am I missing something ?

 Large receive generally needs some hardware assist to work well but given a
large percentage of the protocol off-load implementations rely upon firmware
for various operations, it will vary as to whether there is a legitimate
execution problem or not.   

[dg] There was a paper at OLS talking about LRO (
http://www.linuxsymposium.org/2005/linuxsymposium_procv1.pdf
<http://www.linuxsymposium.org/2005/linuxsymposium_procv1.pdf> ).
My recollection from the talk is that also LRO implementation requires
changes from the OS too. For example, in TCP, you're supposed to send an ACK
every other incoming segments. If you have LRO implemented in the NIC
driver, then you loose track of segment count, unless you can pass that
along to the OS (new indication).
There is another issue which has to do with duplication of TCP stack work
while doing LRO in SW. The paper describes performing many of the TCP/IP
checks in the NIC driver in order to take an LRO decision... So, I'm not
sure whether this doesn't degrade mainstream operation.
There is also a strong assumption on locality for LRO. The paper describes
coalescing of subsequent frames. It obviously does great on synthetic
benchmarks. To some systems, the locality assumption may not perform well.
 
 The same cannot be said for the OS infrastructure changes which is what I
and a couple of others have touched upon. 
 
[dg] Putting aside for a second the different MTU issue. Can't we just run
ipoib-cm on any OS that supports Ethernet jumbo frames ? If yes, then we can
say that ipoib-cm cleanly falls into the domain of the IHV NIC driver, and
can therefore be supported in a larger variety of OSes.

_______________________________________________
IPoverIB mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ipoverib