Re: DSA slaves not inheriting hw_enc_features and xfrmdev_ops?
From: Andrew Lunn <andrew@lunn.ch>
Date: 2021-10-20 12:06:19
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