diff options
| author | David S. Miller <[email protected]> | 2021-03-24 12:48:40 -0700 |
|---|---|---|
| committer | David S. Miller <[email protected]> | 2021-03-24 12:48:40 -0700 |
| commit | 4b837ad53be2ab100dfaa99dc73a9443a8a2392d (patch) | |
| tree | 0a6f602d4aade56ab7f543c0c7d8fed754170a75 /include | |
| parent | ad248f7761eb9a3ff9ba2a8c93b548600185a938 (diff) | |
| parent | 143490cde5669e0151dff466a7c2cf70e2884fb7 (diff) | |
Merge branch 'netfilter-flowtable'
Pablo Neira Ayuso says:
====================
netfilter: flowtable enhancements
[ This is v2 that includes documentation enhancements, including
existing limitations. This is a rebase on top on net-next. ]
The following patchset augments the Netfilter flowtable fastpath to
support for network topologies that combine IP forwarding, bridge,
classic VLAN devices, bridge VLAN filtering, DSA and PPPoE. This
includes support for the flowtable software and hardware datapaths.
The following pictures provides an example scenario:
fast path!
.------------------------.
/ \
| IP forwarding |
| / \ \/
| br0 wan ..... eth0
. / \ host C
-> veth1 veth2
. switch/router
.
.
eth0
host A
The bridge master device 'br0' has an IP address and a DHCP server is
also assumed to be running to provide connectivity to host A which
reaches the Internet through 'br0' as default gateway. Then, packet
enters the IP forwarding path and Netfilter is used to NAT the packets
before they leave through the wan device.
The general 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 from #1 to #6 add the infrastructure which describes the list of
netdevice hops to reach a given destination MAC address in the local
network topology.
Patch #1 adds dev_fill_forward_path() and .ndo_fill_forward_path() to
netdev_ops.
Patch #2 adds .ndo_fill_forward_path for vlan devices, which provides
the next device hop via vlan->real_dev, the vlan ID and the
protocol.
Patch #3 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 #4 extends bridge .ndo_fill_forward_path to support for bridge VLAN
filtering.
Patch #5 adds .ndo_fill_forward_path for PPPoE devices.
Patch #6 adds .ndo_fill_forward_path for DSA.
Patches from #7 to #14 update the flowtable software datapath:
Patch #7 adds the transmit path type field to the flow tuple. Two transmit
paths are supported so far: the neighbour and the xfrm transmit
paths.
Patch #8 and #9 update the flowtable datapath to use dev_fill_forward_path()
to obtain the real ingress/egress device for the flowtable datapath.
This adds the new ethernet xmit direct path to the flowtable.
Patch #10 adds native flowtable VLAN support (up to 2 VLAN tags) through
dev_fill_forward_path(). The flowtable stores the VLAN id and
protocol in the flow tuple.
Patch #11 adds native flowtable bridge VLAN filter support through
dev_fill_forward_path().
Patch #12 adds native flowtable bridge PPPoE through dev_fill_forward_path().
Patch #13 adds DSA support through dev_fill_forward_path().
Patch #14 extends flowtable selftests to cover for flowtable software
datapath enhancements.
** Patches from #15 to #20 update the flowtable hardware offload datapath:
Patch #15 extends the flowtable hardware offload to support for the
direct ethernet xmit path. This also includes VLAN support.
Patch #16 stores the egress real device in the flow tuple. The software
flowtable datapath uses dev_hard_header() to transmit packets,
hence it might refer to VLAN/DSA/PPPoE software device, not
the real ethernet device.
Patch #17 deals with switchdev PVID hardware offload to skip it on
egress.
Patch #18 adds FLOW_ACTION_PPPOE_PUSH to the flow_offload action API.
Patch #19 extends the flowtable hardware offload to support for PPPoE
Patch #20 adds TC_SETUP_FT support for DSA.
** Patches from #20 to #23: Felix Fietkau adds a new driver which support
hardware offload for the mtk PPE engine through the existing flow
offload API which supports for the flowtable enhancements coming in
this batch.
Patch #24 extends the documentation and describe existing limitations.
Please, apply, thanks.
====================
Signed-off-by: David S. Miller <[email protected]>
Diffstat (limited to 'include')
| -rw-r--r-- | include/linux/netdevice.h | 59 | ||||
| -rw-r--r-- | include/linux/ppp_channel.h | 3 | ||||
| -rw-r--r-- | include/net/flow_offload.h | 4 | ||||
| -rw-r--r-- | include/net/netfilter/nf_flow_table.h | 47 |
4 files changed, 108 insertions, 5 deletions
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index 5fa66db0cb5d..02fa1da8cd22 100644 --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h @@ -848,6 +848,59 @@ typedef u16 (*select_queue_fallback_t)(struct net_device *dev, struct sk_buff *skb, struct net_device *sb_dev); +enum net_device_path_type { + DEV_PATH_ETHERNET = 0, + DEV_PATH_VLAN, + DEV_PATH_BRIDGE, + DEV_PATH_PPPOE, + DEV_PATH_DSA, +}; + +struct net_device_path { + enum net_device_path_type type; + const struct net_device *dev; + union { + struct { + u16 id; + __be16 proto; + u8 h_dest[ETH_ALEN]; + } encap; + struct { + enum { + DEV_PATH_BR_VLAN_KEEP, + DEV_PATH_BR_VLAN_TAG, + DEV_PATH_BR_VLAN_UNTAG, + DEV_PATH_BR_VLAN_UNTAG_HW, + } vlan_mode; + u16 vlan_id; + __be16 vlan_proto; + } bridge; + struct { + int port; + u16 proto; + } dsa; + }; +}; + +#define NET_DEVICE_PATH_STACK_MAX 5 +#define NET_DEVICE_PATH_VLAN_MAX 2 + +struct net_device_path_stack { + int num_paths; + struct net_device_path path[NET_DEVICE_PATH_STACK_MAX]; +}; + +struct net_device_path_ctx { + const struct net_device *dev; + const u8 *daddr; + + int num_vlans; + struct { + u16 id; + __be16 proto; + } vlan[NET_DEVICE_PATH_VLAN_MAX]; +}; + enum tc_setup_type { TC_SETUP_QDISC_MQPRIO, TC_SETUP_CLSU32, @@ -1282,6 +1335,8 @@ struct netdev_net_notifier { * struct net_device *(*ndo_get_peer_dev)(struct net_device *dev); * If a device is paired with a peer device, return the peer instance. * The caller must be under RCU read context. + * int (*ndo_fill_forward_path)(struct net_device_path_ctx *ctx, struct net_device_path *path); + * Get the forwarding path to reach the real device from the HW destination address */ struct net_device_ops { int (*ndo_init)(struct net_device *dev); @@ -1488,6 +1543,8 @@ struct net_device_ops { int (*ndo_tunnel_ctl)(struct net_device *dev, struct ip_tunnel_parm *p, int cmd); struct net_device * (*ndo_get_peer_dev)(struct net_device *dev); + int (*ndo_fill_forward_path)(struct net_device_path_ctx *ctx, + struct net_device_path *path); }; /** @@ -2870,6 +2927,8 @@ void dev_remove_offload(struct packet_offload *po); int dev_get_iflink(const struct net_device *dev); int dev_fill_metadata_dst(struct net_device *dev, struct sk_buff *skb); +int dev_fill_forward_path(const struct net_device *dev, const u8 *daddr, + struct net_device_path_stack *stack); struct net_device *__dev_get_by_flags(struct net *net, unsigned short flags, unsigned short mask); struct net_device *dev_get_by_name(struct net *net, const char *name); diff --git a/include/linux/ppp_channel.h b/include/linux/ppp_channel.h index 98966064ee68..91f9a928344e 100644 --- a/include/linux/ppp_channel.h +++ b/include/linux/ppp_channel.h @@ -28,6 +28,9 @@ struct ppp_channel_ops { int (*start_xmit)(struct ppp_channel *, struct sk_buff *); /* Handle an ioctl call that has come in via /dev/ppp. */ int (*ioctl)(struct ppp_channel *, unsigned int, unsigned long); + int (*fill_forward_path)(struct net_device_path_ctx *, + struct net_device_path *, + const struct ppp_channel *); }; struct ppp_channel { diff --git a/include/net/flow_offload.h b/include/net/flow_offload.h index fde025c57b4f..dc5c1e69cd9f 100644 --- a/include/net/flow_offload.h +++ b/include/net/flow_offload.h @@ -147,6 +147,7 @@ enum flow_action_id { FLOW_ACTION_MPLS_POP, FLOW_ACTION_MPLS_MANGLE, FLOW_ACTION_GATE, + FLOW_ACTION_PPPOE_PUSH, NUM_FLOW_ACTIONS, }; @@ -274,6 +275,9 @@ struct flow_action_entry { u32 num_entries; struct action_gate_entry *entries; } gate; + struct { /* FLOW_ACTION_PPPOE_PUSH */ + u16 sid; + } pppoe; }; struct flow_action_cookie *cookie; /* user defined action cookie */ }; diff --git a/include/net/netfilter/nf_flow_table.h b/include/net/netfilter/nf_flow_table.h index fb165697c8a1..4d991c1e93ef 100644 --- a/include/net/netfilter/nf_flow_table.h +++ b/include/net/netfilter/nf_flow_table.h @@ -89,6 +89,14 @@ enum flow_offload_tuple_dir { }; #define FLOW_OFFLOAD_DIR_MAX IP_CT_DIR_MAX +enum flow_offload_xmit_type { + FLOW_OFFLOAD_XMIT_NEIGH = 0, + FLOW_OFFLOAD_XMIT_XFRM, + FLOW_OFFLOAD_XMIT_DIRECT, +}; + +#define NF_FLOW_TABLE_ENCAP_MAX 2 + struct flow_offload_tuple { union { struct in_addr src_v4; @@ -107,15 +115,28 @@ struct flow_offload_tuple { u8 l3proto; u8 l4proto; + struct { + u16 id; + __be16 proto; + } encap[NF_FLOW_TABLE_ENCAP_MAX]; /* All members above are keys for lookups, see flow_offload_hash(). */ struct { } __hash; - u8 dir; - + u8 dir:2, + xmit_type:2, + encap_num:2, + in_vlan_ingress:2; u16 mtu; - - struct dst_entry *dst_cache; + union { + struct dst_entry *dst_cache; + struct { + u32 ifidx; + u32 hw_ifidx; + u8 h_source[ETH_ALEN]; + u8 h_dest[ETH_ALEN]; + } out; + }; }; struct flow_offload_tuple_rhash { @@ -158,7 +179,23 @@ static inline __s32 nf_flow_timeout_delta(unsigned int timeout) struct nf_flow_route { struct { - struct dst_entry *dst; + struct dst_entry *dst; + struct { + u32 ifindex; + struct { + u16 id; + __be16 proto; + } encap[NF_FLOW_TABLE_ENCAP_MAX]; + u8 num_encaps:2, + ingress_vlans:2; + } in; + struct { + u32 ifindex; + u32 hw_ifindex; + u8 h_source[ETH_ALEN]; + u8 h_dest[ETH_ALEN]; + } out; + enum flow_offload_xmit_type xmit_type; } tuple[FLOW_OFFLOAD_DIR_MAX]; }; |