Do not add all physical devices for soft offload

Let kernel heuristics take care of offloading decapsulation Packets may still enter flow engine one encapsulation below actual interface subject to heuristics, while exiting it on listed interfaces, in kernel subject to non-flow encapsulation offloads.

Fixes: openwrt/openwrt#13410 Accidentally-part-fixes: openwrt/openwrt#10224

Signed-off-by: Andris PE [email protected]

@brada4 Any idea when will this be merged? What is needed for this to get some love from the devs?

@lorand-horvath you can copy single file over v23 or master its like 2 years pbr mtu still not ga

@brada4 Any idea when will this be merged? What is needed for this to get some love from the devs?

Go ahead and approve it

@brada4 Any idea when will this be merged? What is needed for this to get some love from the devs?

Go ahead and approve it

What difference does it make if I approve it? I'm not an openwrt dev.

It is another pair of eyes, think of situation I accidentally make firewall pass all - your shout out would be certainly worth. Luckily this list filled is used only in templates/ruleset.uc in the flowtable definition.

I can confirm that this patch fixed the performance downgrade I got after moving from 21.x series to 23.x series on my Archer C7 v2 as explained in this report

Does @jow- have any wisdom to add here? This looks like a low-hanging performance fix for at least PPPoE users on C7v2.

/1/ minimal heuristic would be to add only interfaces that are forward endpoints like br-lan and wan /2/ list is used as output interface of quickpath, ie packet enters normal linux netdev before arp and bridge fdb /3/ list is used as a hint for ingress interface, but some smart heuristic may move the hash processing to one encapsulation lower than that (only one,not two) (the unintended pluses removing 2nd encap) /4/ Now the fail mechanism: if packet hash is matched on ingress interface but it cannot calculate quickpath then the ingress hash entry is removed and packet doomed to slowpath (ct state esta ack + few decors), basically we add extra ingress device that kernel would not consider as valid ingress points, which while in good intent does the damage.

/1/ and /2/ is intended effect, I am sure /3/ and /4/ needs further research, but im still happy that at least partial fruit is there.

@jow- Can you take a look at this PR, please? It would be nice to have your input regarding this performance fix for PPPoE (software offload). More details can be found on the forum https://forum.openwrt.org/t/massive-pppoe-performance-drop-in-23-x-with-archer-c7-v2/197288

Thanks!

I have no idea if the code is sound but this works on PPPoE VDSL tested on the 3370 Fritzbox.

Improved code by @jow- at https://github.com/openwrt/firewall4/commit/e00958884416f59b273595f941d198de63acc1dd achieves identical result.