We all agree that there is a problem, and each is offering a solution. The
point is that claiming stateless offload is ideal and that TOE is just bad
is not objective. Each has its pros and cons. The performance benefits of
TOE have been demonstrated for many real applications, and we've seen quite
a lot of interest in the technology. We are opening up the implementation
(both the toe module and kernel hooks) with the hope that more people would
benefit more readily with Linux.
We are more than willing to address any technical or other objective
concerns folks may have, as well as to help in maintaining the code, and
would appreciate any feedback in this direction.
In short, you've brought several strawmen in an attempt to discredit
stateless offloading as not being standards compliant. If you truly
believe what you say, then please go ask SPEC to invalidate most of
the current SpecWEB benchmark results because the vast majority of
them are using LSO.
On the spec website, the current results have it off.
Q1 2005 for IBM:
SUT Notes
a.. 1 disk for OS 1 disk for docroot 2 disks for tux log and 3 disks
for
fileset internal raid0 raids
b.. SMT enabled - smt-enabled=on
c.. TSO disabled on network adapters
d.. InterruptThrottlingRate set to 1900 on network adapters
e.. 4 external 7311-D11 I/O drawers used for 16 Gigabit adapters (4
adapters per drawer)
Q3 2005 for HP:
Network Notes
a.. Networking Tunable Parameters:
b.. Ethtool used to disable TSO on all NICs (default enabled)
c.. InterruptThrottleRate=700 (via modprobe) Set maximum interrupt
rate
for NIC (default dynamic)
d.. RxDescriptors=512 (via modprobe) Number of receive descriptors
allocated (default 256)
e.. txqueuelen=20000 (via ifconfig) Sets transmit queue length
(default
100)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
