Christian Schmid wrote:
Offload parameters for eth0:
tcp segmentation offload: on
What exactly is tcp segmentation offload?
TCP Segmentation Offload, aka TSO or in other contexts "large send" can be
thought of as a "poor man's" Jumbo Frame. The NIC advertises to the host that
it can resegment larger TCP segments into sizes apropriate for the network.
This allows the host CPU stack to make fewer trips down the protocol stack to
transfer a given quantity of data, thus reducing the service demand (quantity of
CPU consumed per quantity of work). The reduction in service demand can result
in an increase in throughput if the transfer was previously CPU-bound.
It has the advantage over JumboFrame in that it does not require support in the
rest of the infrastructure (switches, routers, receivers etc). I call it "poor
man's" JumboFrame because it does not reduce the overheads on the receiver - the
receiver still sees just as many "normally" sized segments as before, and sends
just as many ACKs per KB transferred as before.
If a NIC is implemented with a microprocessor (bletch - personal opinion) the
additional demands of TSO resegmenation may actually reduce throughput even as
it greatly reduces server CPU utilization. That was particularly evident in old
Tigon2 NICs. I am not sure if that is noticable in current generation BMC570X's
or not - most of the systems I have at my disposal have BCM5701's in them and
I'm not sure the drivers allow TSO to be enabled on that rev? I've not seen a
drop in maximum throughput on the "e1000" NICs I've played with, which have been
some dual-port cards HP sells. YMMV.
> Where can I read more about it?
In addition to whatever there may be in Linux documentation...
TSO or large send is also a long-standing feature of TCP in AIX and (dare I say
it here?-) Windows. As such IBM and Microsoft may have writeups - I'm pretty
sure that Microsoft had a write-up about it on their website - talking about the
NDIS interface at least. It is also a fairly recent addition to HP-UX, but I am
not sure if there are any writeups about it on HP's websites yet.
Should I disable it or is this not a good idea?
That depends. If you are concerned about proper slow-start behaviour at the
beginning of a connection you should disable it until you are on a later rev.
I've always wondered if it wouldn't be an interesting experiment with a "real"
server to see if dishonouring slow-start at connection establishment (and there
only, keep it after RTO) made all that much a difference in the host's