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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 15 May 2013 21:44:31 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Maciej Żenczykowski <zenczykowski@...il.com>
Cc:	Michał Mirosław <mirqus@...il.com>,
	David Miller <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>, Jay Vosburgh <fubar@...ibm.com>,
	Andy Gospodarek <andy@...yhouse.net>,
	Tom Herbert <therbert@...gle.com>,
	Neal Cardwell <ncardwell@...gle.com>,
	Yuchung Cheng <ycheng@...gle.com>
Subject: Re: [PATCH] bonding: allow TSO being set on bonding master

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.


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html