netdev - Re: DSA slaves not inheriting hw_enc_features and xfrmdev

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: <YXAGNmH+GsI5e9ly@lunn.ch>
Date:   Wed, 20 Oct 2021 14:06:14 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     R W van Schagen <vschagen@...com>
Cc:     netdev@...r.kernel.org
Subject: Re: DSA slaves not inheriting hw_enc_features and xfrmdev_ops?

On Wed, Oct 20, 2021 at 09:28:40AM +0800, R W van Schagen wrote:
> Hi all,
> 
> When I register a master device (eth0) with ESP hardware offload:
> 
> 	netdev->xfrmdev_ops = &mtk_xfrmdev_ops;
> 	netdev->features |= NETIF_F_HW_ESP;
> 	netdev->hw_enc_features |= NETIF_F_HW_ESP;
> 
> Only the “features” are inherited by the DSA slaves. When those
> get registered without the xfrmdev_ops the HW_ESP feature is
> dropped again.
> 
> Is this a “bug” and should I make a patch to fix this or is this actually
> a design feature?

Design feature.

The problem is, for most MAC devices, the additional DSA
header/trailer messes up all acceleration. The HW does not understand
the header/trailer, don't know they have to skip it, have trouble
finding the IP header, etc. So in general, we turn off all
acceleration features.

If you pair a Marvell MAC with a Marvell Switch, there is a good
chance it understands the Marvell DSA header and some forms of
acceleration work. Same goes for a Broadcom MAC with a Broadcom
switch. But pair a Freescale MAC with a Marvell Switch and even basic
IP checksumming does not work, the FEC HW cannot find the IP header.

> As a work-around I am using a notifier call and add those features but
> I don’t think this is the proper way to do this in a production driver.

It is not a simple problem to solve in a generic way. You end up with
an M by S matrices for HW features which work, where M is the MAC and
S is the switch.

So for you board, with your specific pairing of MAC and Switch, which
i assume is a mediatek MAC connected to a mediatek switch, using a
notifier call is not too unreasonable.

We could also consider DT properties, indicating which features work
for this board. That should be a reasonably generic solution, which
you can implement in the DSA core.

	    Andrew