netdev - Re: [PATCH nf-next 0/8] netfilter: make nf_flowtable lifetime differ from container struct

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 24 Nov 2023 11:48:09 +0100
From: Toke Høiland-Jørgensen <toke@...e.dk>
To: Pablo Neira Ayuso <pablo@...filter.org>, Florian Westphal <fw@...len.de>
Cc: netfilter-devel@...r.kernel.org, lorenzo@...nel.org, netdev@...r.kernel.org
Subject: Re: [PATCH nf-next 0/8] netfilter: make nf_flowtable lifetime
 differ from container struct

> My understand is that XDP is all about programmibility, if user
> decides to go for XDP then simply fully implement the fast path is the
> XDP framework? I know of software already does so and they are
> perfectly fine with this approach.

Yes, you can do that. But if you're reimplementing everything anyway,
why bother with XDP at all? Might as well go with DPDK and full bypass
then.

The benefit of XDP as a data path is the integration with the kernel
infrastructure: we have robust implementations of a bunch of protocols,
a control plane API that works with a bunch of userspace utilities
(e.g., routing daemons), and lots of data battle-tested data structures
for various things (e.g., the routing table fib). With XDP, you can use
this infrastructure in a pick-and-choose manner and implement your fast
path using just the features you care about for your use case, gaining
performance while still using the kernel path for the slow path to get
full functionality.

The first example of this paradigm was the bpf_fib_lookup() helper. With
this you can accelerate the forwarding fast path and still have the
kernel stack handle neighbour lookup, etc. Adding flowtable lookup
support is a natural extension of this, adding another integration point
you can use for a more complete forwarding acceleration, while still
integrating with the rest of the stack.

This was the "making XDP a magical go faster button" thing I was talking
about at Netconf (and again at Netdevconf), BTW: we should work towards
making XDP a complete (forwarding) acceleration solution, so we can
replace all the crappy hardware "fast path" and kernel bypass
implementations in the world :)

-Toke