netdev - Re: [PATCH v3 net-next 2/4] net: dsa: Link aggregation support

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]

Message-ID: <20201203162428.ffdj7gdyudndphmn@skbuf>
Date:   Thu, 3 Dec 2020 18:24:28 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Tobias Waldekranz <tobias@...dekranz.com>
Cc:     davem@...emloft.net, kuba@...nel.org, andrew@...n.ch,
        vivien.didelot@...il.com, f.fainelli@...il.com,
        j.vosburgh@...il.com, vfalico@...il.com, andy@...yhouse.net,
        netdev@...r.kernel.org
Subject: Re: [PATCH v3 net-next 2/4] net: dsa: Link aggregation support

On Wed, Dec 02, 2020 at 10:13:54AM +0100, Tobias Waldekranz wrote:
> +static inline bool dsa_lag_offloading(struct dsa_switch_tree *dst)
> +{
> +	return dst->lags.num > 0;
> +}

You assume that the DSA switch, when it sets a non-zero number of LAGs,
can offload any type of LAG TX type, when in fact the switch might be
able to offload just NETDEV_LAG_TX_TYPE_HASH.

I like the fact that we revert to a software-based implementation for
features the hardware can't offload. So rejecting other TX types is out
of the question. However we still have to prevent hardware bridging.

Should we add an array of supported TX types that the switch port can
offload, and that should be checked by DSA in dsa_lag_offloading?