[PATCH] bcm53xx: disable GRO support at kernel level
rosenp at gmail.com
Wed Jun 22 23:29:06 PDT 2022
On Wed, Jun 22, 2022 at 8:49 PM Rafał Miłecki <zajec5 at gmail.com> wrote:
> On 21.06.2022 01:13, Rosen Penev wrote:
> > On Mon, Jun 20, 2022 at 2:33 AM Rafał Miłecki <zajec5 at gmail.com> wrote:
> >> On 10.06.2022 15:16, Rafał Miłecki wrote:
> >>> This improves NAT masquarade network performance.
> >>> An alternative to kernel change would be runtime setup but that requires
> >>> ethtool and identifying relevant network interface and all related
> >>> switch ports interfaces.
> >> I sent another patch that should supersede this one:
> >> [PATCH] bcm53xx: disable GRO by default at kernel level
> >> https://email@example.com/
> >> It's probably a better idea to disable GRO *by default* (and allow
> >> re-enabling it).
> > Reminds me of this patch:
> > https://github.com/openwrt/openwrt/commit/13e5e473699b92f171205e0f5c57c9ebe7922492
> > which was subsequently reverted because of slower routing performance
> > Is this patch the same as using napi_gro_receive and passing NETIF_F_GRO ?
> Kind of. Reverting above patch removes ar71xx support for GRO totally.
> It's not the best option as some people / cases / devices may want it.
> It's much better to just disable it.
I imagine that would be no routing cases.
> GRO can be runtime disabled using ethtool like:
> ethtool -K eth0 gro off
> ethtool -K lan1 gro off
> ethtool -K lan2 gro off
> ethtool -K lan3 gro off
> ethtool -K lan4 gro off
> ethtool -K wan gro off
> (or enabled with "on").
> It can also be disabled by default with patch like the one I sent. In
> that case you can still enable it with:
> ethtool -K eth0 gro on
> ethtool -K lan1 gro on
> ethtool -K lan2 gro on
> ethtool -K lan3 gro on
> ethtool -K lan4 gro on
> ethtool -K wan gro on
> So for ar71xx I'd suggest to:
> 1. Re-implement GRO support
> 2. Disable GRO by default if it worsens performance for most devices
Basically your other patch.
More information about the openwrt-devel