[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6571a7f3-3900-44c9-8dcc-a7f3f34a888d@blackwall.org>
Date: Wed, 22 Oct 2025 16:13:13 +0300
From: Nikolay Aleksandrov <razor@...ckwall.org>
To: Daniel Borkmann <daniel@...earbox.net>, netdev@...r.kernel.org
Cc: bpf@...r.kernel.org, kuba@...nel.org, davem@...emloft.net,
pabeni@...hat.com, willemb@...gle.com, sdf@...ichev.me,
john.fastabend@...il.com, martin.lau@...nel.org, jordan@...fe.io,
maciej.fijalkowski@...el.com, magnus.karlsson@...el.com, dw@...idwei.uk,
toke@...hat.com, yangzhenze@...edance.com, wangdongdong.6@...edance.com
Subject: Re: [PATCH net-next v3 11/15] netkit: Add single device mode for
netkit
On 10/20/25 19:23, Daniel Borkmann wrote:
> Add a single device mode for netkit instead of netkit pairs. The primary
> target for the paired devices is to connect network namespaces, of course,
> and support has been implemented in projects like Cilium [0]. For the rxq
> binding the plan is to support two main scenarios related to single device
> mode:
>
> * For the use-case of io_uring zero-copy, the control plane can either
> set up a netkit pair where the peer device can perform rxq binding which
> is then tied to the lifetime of the peer device, or the control plane
> can use a regular netkit pair to connect the hostns to a Pod/container
> and dynamically add/remove rxq bindings through a single device without
> having to interrupt the device pair. In the case of io_uring, the memory
> pool is used as skb non-linear pages, and thus the skb will go its way
> through the regular stack into netkit. Things like the netkit policy when
> no BPF is attached or skb scrubbing etc apply as-is in case the paired
> devices are used, or if the backend memory is tied to the single device
> and traffic goes through a paired device.
>
> * For the use-case of AF_XDP, the control plane needs to use netkit in the
> single device mode. The single device mode currently enforces only a
> pass policy when no BPF is attached, and does not yet support BPF link
> attachments for AF_XDP. skbs sent to that device get dropped at the
> moment. Given AF_XDP operates at a lower layer of the stack tying this
> to the netkit pair did not make sense. In future, the plan is to allow
> BPF at the XDP layer which can: i) process traffic coming from the AF_XDP
> application (e.g. QEMU with AF_XDP backend) to filter egress traffic or
> to push selected egress traffic up to the single netkit device to the
> local stack (e.g. DHCP requests), and ii) vice-versa skbs sent to the
> single netkit into the AF_XDP application (e.g. DHCP replies). Also,
> the control-plane can dynamically add/remove rxq bindings for the single
> netkit device without having to interrupt (e.g. down/up cycle) the main
> netkit pair for the Pod which has traffic going in and out.
>
> Signed-off-by: Daniel Borkmann <daniel@...earbox.net>
> Co-developed-by: David Wei <dw@...idwei.uk>
> Signed-off-by: David Wei <dw@...idwei.uk>
> Reviewed-by: Jordan Rife <jordan@...fe.io>
> Link: https://docs.cilium.io/en/stable/operations/performance/tuning/#netkit-device-mode [0]
> ---
> drivers/net/netkit.c | 108 ++++++++++++++++++++++-------------
> include/uapi/linux/if_link.h | 6 ++
> 2 files changed, 74 insertions(+), 40 deletions(-)
>
Reviewed-by: Nikolay Aleksandrov <razor@...ckwall.org>
Powered by blists - more mailing lists