Message-Id: <20201015011630.2399-1-pablo@netfilter.org>
Date:   Thu, 15 Oct 2020 03:16:21 +0200
From:   Pablo Neira Ayuso <pablo@...filter.org>
To:     netfilter-devel@...r.kernel.org
Cc:     davem@...emloft.net, netdev@...r.kernel.org, kuba@...nel.org
Subject: [PATCH net-next 0/9] netfilter: flowtable bridge and vlan enhancements

Hi,

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().

Comments welcome.

[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

Powered by blists - more mailing lists