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 for Android: free password hash cracker in your pocket

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

Message-Id: <A08F0571-5705-4FD6-9C5D-55B4C0734712@cs.com>
Date:   Thu, 21 Oct 2021 20:13:13 +0800
From:   R W van Schagen <vschagen@...com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org
Subject: Re: DSA slaves not inheriting hw_enc_features and xfrmdev_ops?


> On 20 Oct 2021, at 20:06, Andrew Lunn <andrew@...n.ch> wrote:
> 
> 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

Thanks for the explanation. For now I will proceed using notifier callbacks.

One more strange thing I am noticing: Even if I set NETIF_F_GSO_ESP
I am still not getting any GSO packets (skb_is_gso is always false) so my
transmit speeds are like 2/3 of the receive speeds. Hardware Decryption vs
Encryption is not 100% the same, but it is close.

I am getting the esp_gro_receive callbacks, but not the esp_gso_segment,
BUT: for some reason my packets still get TCP GSO.

Richard