realtek: remove firewall and other core components? [Was: Re: [PATCH 1/2] realtek: Use firewall4]

Birger Koblitz mail at
Fri Mar 25 14:40:29 PDT 2022


> The layer 2 (MAC, VLAN, Ethernet frame contents) offloading in Linux is normally done over tc and not nftabels. With flower you can filter, redirect and modify packets based on VLAN IDs, VLAN PCP, MAC 
> addresses, .. and so on. qdisc allows to configure traffic schedulers to do advance QoS based on Ethernet frames.
Ah, so they are complementary, thanks for that explanation.
The layer 2 stuff that is done with flower is all implemented as HW offloaded in the driver btw for all SoCs and cursory testing seems to show it works. The QoS is missing so far.

> I think we backported all of the patches from flow offloading from kernel 5.15 to our kernel 5.10.
> The net/netfilter/nf_flow_table_core.c file in OpenWrt kernel 5.10 looks very similar to upstream 5.15.
>> Supporting tc flower and offloading it requires however about a dozen kernel modules and user
>> space tools, which is really tricky to get right. It would be great to have these packets
>> on board by default, to make this feature more usable, also for people to test it.
> The tc command should be sufficient to configure the flower offloading, but we would need some more kernel modules, which are already packed, but not interluded by default in OpenWrt.
> OpenWrt misses some central configuration service for tc flower and tc qdisc as far as I know. We could add this to netifd.
Indeed this would be great, because if routing is configured and offloaded this can circumvent firewall filtering.
If there is central configuration support, this is much easier to set up by users and sanity checks can be done, i.e.
that the filtering rules come first, before offloading the routes as both are handled by the Packet Inspection Engine
and this handles rules strictly in the sequence they are ordered in the content addressable memory. Currently this
only depends on the sequence routes and tc rules are being set up. The HW would however also support re-ordering
of rules even while switching packets.

>> I yesterday learned that someone was using an 838x device for OLSR with between 200 and 300 offloaded
>> next-hop routes, so the hardware offload is something that interests people who would normally
>> find this only in proprietary vendor solutions.> 
> Some of the switches which are used on normal consumer routers have some of these features as well. The Lantiq/Maxlinear switches support for example filtering based on VID, PCP and can also remove 
> and add VLAN tags. They also support different traffic scheduling algorithms. Currently this is not implemented in the driver used in OpenWrt and I am not sure what is supported by the Lantiq switch 
> support by Openwrt.
> Hauke


More information about the openwrt-devel mailing list