| Message ID | 20201015163038.26992-1-pablo@netfilter.org |
|---|---|
| Headers | show |
| Series | netfilter: flowtable bridge and vlan enhancements | expand |
On Thu, 15 Oct 2020 18:30:29 +0200 Pablo Neira Ayuso wrote: > The following patchset adds infrastructure to augment the Netfilter > flowtable fastpath [1] to support for local network topologies that > combine IP forwarding, bridge and vlan devices. > > A typical scenario that can benefit from this infrastructure is composed > of several VMs connected to bridge ports where the bridge master device > 'br0' has an IP address. A DHCP server is also assumed to be running to > provide connectivity to the VMs. The VMs reach the Internet through > 'br0' as default gateway, which makes the packet enter the IP forwarding > path. Then, netfilter is used to NAT the packets before they leave to > through the wan device. Hi Pablo, I should have looked at this closer yesterday, but I think it warrants a little more review than we can afford right now. Let's take it after the merge window, sorry!
On Thu, Oct 15, 2020 at 12:47:48PM -0700, Jakub Kicinski wrote: > On Thu, 15 Oct 2020 18:30:29 +0200 Pablo Neira Ayuso wrote: > > The following patchset adds infrastructure to augment the Netfilter > > flowtable fastpath [1] to support for local network topologies that > > combine IP forwarding, bridge and vlan devices. > > > > A typical scenario that can benefit from this infrastructure is composed > > of several VMs connected to bridge ports where the bridge master device > > 'br0' has an IP address. A DHCP server is also assumed to be running to > > provide connectivity to the VMs. The VMs reach the Internet through > > 'br0' as default gateway, which makes the packet enter the IP forwarding > > path. Then, netfilter is used to NAT the packets before they leave to > > through the wan device. > > Hi Pablo, I should have looked at this closer yesterday, but I think it > warrants a little more review than we can afford right now. > > Let's take it after the merge window, sorry! I understand, I admit it was a bit late patchset. I have to say that I'm dissapointed. I cannot avoid shaking the feeling that there is always a reason to push back for Netfilter stuff. Probably it's not fair to mention this in this case. It's just a personal perception, so I might be really wrong about it.
Hi, [ This is v2 fixing up the sparse warnings. ] The following patchset adds infrastructure to augment the Netfilter flowtable fastpath [1] to support for local network topologies that combine IP forwarding, bridge and vlan devices. A typical scenario that can benefit from this infrastructure is composed of several VMs connected to bridge ports where the bridge master device 'br0' has an IP address. A DHCP server is also assumed to be running to provide connectivity to the VMs. The VMs reach the Internet through 'br0' as default gateway, which makes the packet enter the IP forwarding path. Then, netfilter is used to NAT the packets before they leave to through the wan device. Something like this: fast path .------------------------. / \ | IP forwarding | | / \ . | br0 eth0 . / \ -- veth1 veth2 . . . ethX ab:cd:ef:ab:cd:ef VM The idea is to accelerate forwarding by building a fast path that takes packets from the ingress path of the bridge port and place them in the egress path of the wan device (and vice versa). Hence, skipping the classic bridge and IP stack paths. Patch #1 adds the transmit path type field to the flow tuple. Two transmit paths are supported so far: the neighbour and the xfrm transmit paths. This patch comes in preparation to add a new direct ethernet transmit path (see patch #7). Patch #2 adds dev_fill_forward_path() and .ndo_fill_forward_path() to netdev_ops. This new function describes the list of netdevice hops to reach a given destination MAC address in the local network topology, e.g. IP forwarding / \ br0 eth0 / \ veth1 veth2 . . . ethX ab:cd:ef:ab:cd:ef where veth1 and veth2 are bridge ports and eth0 provides Internet connectivity. ethX is the interface in the VM which is connected to the veth1 bridge port. Then, for packets going to br0 whose destination MAC address is ab:cd:ef:ab:cd:ef, dev_fill_forward_path() provides the following path: br0 -> veth1. Patch #3 adds .ndo_fill_forward_path for vlan devices, which provides the next device hop via vlan->real_dev. This also annotates the vlan id and protocol. This is useful to know what vlan headers are expected from the ingress device. This also provides information regarding the vlan headers to be pushed before transmission via the egress device. Patch #4 adds .ndo_fill_forward_path for bridge devices, which allows to make lookups to the FDB to locate the next device hop (bridge port) in the forwarding path. Patch #5 updates the flowtable to use the dev_fill_forward_path() infrastructure to obtain the ingress device in the forwarding path. Patch #6 updates the flowtable to use the dev_fill_forward_path() infrastructure to obtain the egress device in the forwarding path. Patch #7 adds the direct ethernet transmit path, which pushes the ethernet header to the packet and send it through dev_queue_xmit(). Patch #8 uses the direct ethernet transmit path (added in the previous patch) to transmit packets to bridge ports - in case dev_fill_forward_path() describes a topology that includes a bridge. Patch #9 updates the flowtable to include the vlan information in the flow tuple for lookups from the ingress path as well as the vlan headers to be pushed into the packet before transmission to the egress device. 802.1q and 802.1ad (q-in-q) are supported. The vlan information is also described by dev_fill_forward_path(). Please, apply. [1] https://www.kernel.org/doc/html/latest/networking/nf_flowtable.html Pablo Neira Ayuso (9): netfilter: flowtable: add xmit path types net: resolve forwarding path from virtual netdevice and HW destination address net: 8021q: resolve forwarding path for vlan devices bridge: resolve forwarding path for bridge devices netfilter: flowtable: use dev_fill_forward_path() to obtain ingress device netfilter: flowtable: use dev_fill_forward_path() to obtain egress device netfilter: flowtable: add direct xmit path netfilter: flowtable: bridge port support netfilter: flowtable: add vlan support include/linux/netdevice.h | 35 ++++ include/net/netfilter/nf_flow_table.h | 41 ++++- net/8021q/vlan_dev.c | 15 ++ net/bridge/br_device.c | 22 +++ net/core/dev.c | 31 ++++ net/netfilter/nf_flow_table_core.c | 27 ++- net/netfilter/nf_flow_table_ip.c | 247 ++++++++++++++++++++++---- net/netfilter/nft_flow_offload.c | 107 ++++++++++- 8 files changed, 484 insertions(+), 41 deletions(-) -- 2.20.1