David Miller wrote:

From: Lennert Buytenhek <redacted>
Date: Thu, 31 Jul 2008 14:25:41 +0200

quoted

At this point things seem to be CPU limited at the sender again.  E.g.
by simply dropping IRQF_SAMPLE_RANDOM from mv643xx_eth.c (the driver
used on the sender), throughput jumps to ~108 MiB/s, and I get:

 ...

quoted

Putting the 5 * mss_now nagle hack back in doesn't seem to change
the gso_size distribution anymore at this point, and it doesn't
change the numbers much:

 ...

quoted

The throughput with software GSO off again seems to be about ~93 MiB/s:

So I would conclude that at the moment we should just do the software
GSO enabling thing (with the recent suggestions made by Herbert) and
for the time being the nagle hack isn't something to consider closely.

You might want to think about providing a way for soft-GSO to generate
more lightweight structures than skbs.  The overhead for skb allocation
becomes quite significant beyond 1 Gbit/s, which is why we added the soft-
TSO implementation in sfc using per-interface pools of header buffers.  I
would guess niu would benefit from this sort of approach, though it looks
like all the other 10G NICs do TSO in hardware/firmware.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.