On Wed, Jun 4, 2025 at 3:24 PM Akihiko Odaki akihiko.odaki@daynix.com wrote:
On 2025/06/04 10:27, Jason Wang wrote:
On Fri, May 30, 2025 at 12:50 PM Akihiko Odaki akihiko.odaki@daynix.com wrote:
This clarifies a steering eBPF program takes precedence over the other steering algorithms.
Let's give an example on the use case for this.
Signed-off-by: Akihiko Odaki akihiko.odaki@daynix.com
Documentation/networking/tuntap.rst | 7 +++++++ drivers/net/tun.c | 28 +++++++++++++++++----------- include/uapi/linux/if_tun.h | 9 +++++++++ 3 files changed, 33 insertions(+), 11 deletions(-)
diff --git a/Documentation/networking/tuntap.rst b/Documentation/networking/tuntap.rst index 4d7087f727be..86b4ae8caa8a 100644 --- a/Documentation/networking/tuntap.rst +++ b/Documentation/networking/tuntap.rst @@ -206,6 +206,13 @@ enable is true we enable it, otherwise we disable it:: return ioctl(fd, TUNSETQUEUE, (void *)&ifr); }
+3.4 Reference +-------------
+``linux/if_tun.h`` defines the interface described below:
+.. kernel-doc:: include/uapi/linux/if_tun.h
Universal TUN/TAP device driver Frequently Asked Question
diff --git a/drivers/net/tun.c b/drivers/net/tun.c index d8f4d3e996a7..9133ab9ed3f5 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -476,21 +476,29 @@ static u16 tun_automq_select_queue(struct tun_struct *tun, struct sk_buff *skb) return txq; }
-static u16 tun_ebpf_select_queue(struct tun_struct *tun, struct sk_buff *skb) +static bool tun_ebpf_select_queue(struct tun_struct *tun, struct sk_buff *skb,
{ struct tun_prog *prog; u32 numqueues;u16 *ret)
u16 ret = 0;
u32 prog_ret;
prog = rcu_dereference(tun->steering_prog);
if (!prog)
return false; numqueues = READ_ONCE(tun->numqueues);
if (!numqueues)
return 0;
if (!numqueues) {
*ret = 0;
return true;
}
prog = rcu_dereference(tun->steering_prog);
if (prog)
ret = bpf_prog_run_clear_cb(prog->prog, skb);
prog_ret = bpf_prog_run_clear_cb(prog->prog, skb);
if (prog_ret == TUN_STEERINGEBPF_FALLBACK)
return false;
This seems to break the uAPI. So I think we need a new ioctl to enable the behaviour
I assumed it is fine to repurpose one of the 32-bit integer values since 32-bit integer is too big to specify the queue number, but it may not be fine. I don't have a concrete use case either.
Perhaps it is safer to note that TUNSETSTEERINGEBPF takes precedence over TUNSETVNETRSS to allow such an extension in the future (but without implementing one now).
Yes, that's my original point. Let's start from something that is simpler and safer.
Thanks