Re: [PATCH] bonding: allow TSO being set on bonding master

[Eric Dumazet <eric.dumazet@gmail.com>]

Please do not top post on netdev.

On Wed, 2013-05-15 at 21:31 -0700, Maciej Żenczykowski wrote:
> I think it should always be possible to enable both TSO and GSO on the
> bond master - regardless of what the slaves support and/or currently
> have enabled.
> At the last moment as we're passing a packet to a slave, we should
> check whether the slave will like it and if not GSO it.
> This means TSO or GSO enabled on the master can effectively almost
> force (or force emulation of) GSO on slaves.
> Even if the slaves themselves don't support GSO.

GSO is software provided in core network.

> 
> There's a lot more room for argument with regards to the default state
> of TSO/GSO on the master.
> I would argue for default to on for both.
> One could argue that if none of the slaves support GSO or TSO then
> maybe it should default to off, but I don't buy that.
> 
> I don't really understand the point of passing GSO/TSO up from the
> slaves to the master.
> Although the maximum size and/or number of segs for a packet probably
> needs to be propagated from TSO capable devices,
> unless one were to add a "split big GSO packet into smaller (but still
> larger than mtu) TSO packets" step as well.

We could always build GSO packets in TCP stack and if these packets land
on a non SG/TSO capable device, segment them, but it would be more
expensive than building non GSO packets at the beginning.
Its also risky because this segmentation uses GFP_ATOMIC allocations and
therefore can easily fail (especially if SG is lacking)

So bonding has heuristics : 

- If at least one slave supports TSO, then the master supports TSO 
- If at least one slave support GSO, then the master supports GSO
...

Point is : as we do have software fallback, we should allow the admin to
set/unset TSO on the bonding master, regardless of slaves settings.

Depending on the netfilter/qdisc setups, an admin might know better than
the kernel heuristics.