> On 6/28/25 11:47 AM, Lorenzo Bianconi wrote:
> >> On Fri, Jun 27, 2025 at 02:45:28PM +0200, Lorenzo Bianconi wrote:
> >>> Introduce SW acceleration for IPIP tunnels in the netfilter flowtable
> >>> infrastructure.
> >>> IPIP SW acceleration can be tested running the following scenario where
> >>> the traffic is forwarded between two NICs (eth0 and eth1) and an IPIP
> >>> tunnel is used to access a remote site (using eth1 as the underlay device):
> >>>
> >>> ETH0 -- TUN0 <==> ETH1 -- [IP network] -- TUN1 (192.168.100.2)
> >>>
> >>> $ip addr show
> >>> 6: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
> >>> link/ether 00:00:22:33:11:55 brd ff:ff:ff:ff:ff:ff
> >>> inet 192.168.0.2/24 scope global eth0
> >>> valid_lft forever preferred_lft forever
> >>> 7: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
> >>> link/ether 00:11:22:33:11:55 brd ff:ff:ff:ff:ff:ff
> >>> inet 192.168.1.1/24 scope global eth1
> >>> valid_lft forever preferred_lft forever
> >>> 8: tun0@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1480 qdisc noqueue state UNKNOWN group default qlen 1000
> >>> link/ipip 192.168.1.1 peer 192.168.1.2
> >>> inet 192.168.100.1/24 scope global tun0
> >>> valid_lft forever preferred_lft forever
> >>>
> >>> $ip route show
> >>> default via 192.168.100.2 dev tun0
> >>> 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.2
> >>> 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1
> >>> 192.168.100.0/24 dev tun0 proto kernel scope link src 192.168.100.1
> >>>
> >>> $nft list ruleset
> >>> table inet filter {
> >>> flowtable ft {
> >>> hook ingress priority filter
> >>> devices = { eth0, eth1 }
> >>> }
> >>>
> >>> chain forward {
> >>> type filter hook forward priority filter; policy accept;
> >>> meta l4proto { tcp, udp } flow add @ft
> >>> }
> >>> }
> >>
> >> Is there a proof that this accelerates forwarding?
> >
> > I reproduced the scenario described above using veths (something similar to
> > what is done in nft_flowtable.sh) and I got the following results:
> >
> > - flowtable configured as above between the two router interfaces
> > - TCP stream between client and server going via the IPIP tunnel
> > - TCP stream transmitted into the IPIP tunnel:
> > - net-next: ~41Gbps
> > - net-next + IPIP flowtbale support: ~40Gbps
> > - TCP stream received from the IPIP tunnel:
> > - net-next: ~35Gbps
> > - net-next + IPIP flowtbale support: ~49Gbps
> >
> >>
> >>> Signed-off-by: Lorenzo Bianconi <lorenzo@xxxxxxxxxx>
> >>> ---
> >>> net/ipv4/ipip.c | 21 +++++++++++++++++++++
> >>> net/netfilter/nf_flow_table_ip.c | 28 ++++++++++++++++++++++++++--
> >>> 2 files changed, 47 insertions(+), 2 deletions(-)
> >>>
> >
> > [...]
> >
> >>> static bool nf_flow_skb_encap_protocol(struct sk_buff *skb, __be16 proto,
> >>> u32 *offset)
> >>> {
> >>> struct vlan_ethhdr *veth;
> >>> __be16 inner_proto;
> >>> + u16 size;
> >>>
> >>> switch (skb->protocol) {
> >>> + case htons(ETH_P_IP):
> >>> + if (nf_flow_ip4_encap_proto(skb, &size))
> >>> + *offset += size;
> >>
> >> This is blindly skipping the outer IP header.
> >
> > Do you mean we are supposed to validate the outer IP header performing the
> > sanity checks done in nf_flow_tuple_ip()?
>
> Yes.
ack
>
> Note that we could always obtain a possibly considerably tput
> improvement stripping required validation ;)
I have been proactive and I added the sanity checks done in nf_flow_tuple_ip()
and I got ~ the same results.
>
> I guess this should go via the netfilter tree, please adjust the patch
> prefix accordingly.
ack
>
> Also why IP over IP specifically? I guess other kind of encapsulations
> may benefit from similar path and are more ubiquitous.
this is just the first step, I want to add IPv6 counterpart too.
Regards,
Lorenzo
>
>
> /P
>
Attachment:
signature.asc
Description: PGP signature
