On 21.06.2022 01:13, Rosen Penev wrote:
On Mon, Jun 20, 2022 at 2:33 AM Rafał Miłecki <zaj...@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://patchwork.ozlabs.org/project/openwrt/patch/20220620082120.11714-1-zaj...@gmail.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.
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
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel