Bridged interfaces flowtable HW_OFFLOAD

Banana Pi Router design
1

@frank-w @dangowrt @ghostbuster91 and any others interested

I have finished the rough version of my newest patch-set. Of course, the patch-set needs some more cleaning up and removing the printk()'s. Also I do need to do some more testing. Perhaps any of you care to test or review it, before I try it as a [RFC PATCH] to netfilter, maybe somewhere in the next following weeks or months.

The patch-set adds the possibility for adding hardware offloaded flow through nftables for bridged interfaces. Until now this was only possible using the userspace tool bridger, but it runs on openwrt only. Since I’m running ArchlinuxArm on my BananaPi routers, I can’t use bridger. Of course this patch-set will also work on Debian/Ubuntu, Openwrt and other distributions.

You can find it in this branch, starting with the commit COVER LETTER:

https://github.com/ericwoud/linux/commits/bpir-nftflow-stable

This branch will get rebased/fixedup/squashed very often.

The contents of the cover-letter commit is only used for debugging. The description holds the [0/X] description of the patch-set.

The patch-set also addresses a few other issues that have come to light during testing the bridged flow.

After applying the patches, one can add the bridged flow. It needs CONFIG_NF_CONNTRACK_BRIDGE enabled. The flowtable is added as an extra flowtable, called fb in this example:

table inet filter {
        flowtable f {
                hook ingress priority filter
                devices = { eth1, lan0, lan1, lan2, lan3, lan4, wlan0, wlan1 }
                flags offload
        }
        chain forward {
                type filter hook forward priority filter
                ct state established flow add @f
        }
}

table bridge filter {
        flowtable fb {
                hook ingress priority filter
                devices = { lan0, lan1, lan2, lan3, lan4, wlan0, wlan1 }
                flags offload
        }
        chain forward {
                type filter hook forward priority filter
                ct state established flow add @fb
        }
}

In this example eth1 is used as wan port.

         forward fastpath bypass
 .----------------------------------------.
/                                          \
|                        IP - forwarding    |
|                       /                \  v
|                      /                  wan ...
|                     /
|                     |
|                     |
|                   brlan.1
|                     |
|    +-------------------------------+
|    |           vlan 1              |
|    |                               |
|    |     brlan (vlan-filtering)    |
|    +---------------+               |
|    |  DSA-SWITCH   |               |
|    |               |    vlan 1     |
|    |               |      to       |
|    |   vlan 1      |   untagged    |
|    +---------------+---------------+
.         /                   \
 ------>lan0                 wlan1
        .  ^                 ^
        .  |                 |
        .  \_________________/
        .  bridge fastpass bypass
        .
        ^
     vlan 1 tagged packets

This combination of vlan-aware bridge and use of vlan-device turns out to be an excellent test setup. It also represents a pretty common vlan setup.

For pppoe, for now, it is assumed the pppoe-device is only in the forward path, not in the bridge path. Only passing along the pppoe tag, if it is present, is supported in the bridge fastpath.

TODO:

* Test wenxu's rebased selftest script.
* Test all related to pppoe (in both fastpath types).
* Find out if pkt->skb->dev->ifindex == out_dev->ifindex is always true.
* Replace "dev_get_by_index(dev_net(nft_in(pkt)), nft_in(pkt)->ifindex)" by "nft_in(pkt)"?
* General cleanup.
1 Like