Re: using software TSO on non-TSO capable netdevices

[Ben Hutchings <bhutchings@solarflare.com>]

David Miller wrote:
> From: Lennert Buytenhek <buytenh@wantstofly.org>
> Date: Thu, 31 Jul 2008 14:25:41 +0200
> 
> > 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:
>  ...
> > 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:
>  ...
> > 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.