Re: [PATCH] net: tuntap: add ioctl() TUNGETQUEUEINDX to fetch queue index

From: Randy Li
Date: Thu Aug 01 2024 - 15:53:13 EST



On 2024/8/1 22:17, Willem de Bruijn wrote:
Randy Li wrote:
On 2024/8/1 21:04, Willem de Bruijn wrote:
Randy Li wrote:
On 2024/8/1 05:57, Willem de Bruijn wrote:
nits:

- INDX->INDEX. It's correct in the code
- prefix networking patches with the target tree: PATCH net-next
I see.
Randy Li wrote:
On 2024/7/31 22:12, Willem de Bruijn wrote:
Randy Li wrote:
We need the queue index in qdisc mapping rule. There is no way to
fetch that.
In which command exactly?
That is for sch_multiq, here is an example

tc qdisc add dev  tun0 root handle 1: multiq

tc filter add dev tun0 parent 1: protocol ip prio 1 u32 match ip dst
172.16.10.1 action skbedit queue_mapping 0
tc filter add dev tun0 parent 1: protocol ip prio 1 u32 match ip dst
172.16.10.20 action skbedit queue_mapping 1

tc filter add dev tun0 parent 1: protocol ip prio 1 u32 match ip dst
172.16.10.10 action skbedit queue_mapping 2
If using an IFF_MULTI_QUEUE tun device, packets are automatically
load balanced across the multiple queues, in tun_select_queue.

If you want more explicit queue selection than by rxhash, tun
supports TUNSETSTEERINGEBPF.
I know this eBPF thing. But I am newbie to eBPF as well I didn't figure
out how to config eBPF dynamically.
Lack of experience with an existing interface is insufficient reason
to introduce another interface, of course.
tc(8) was old interfaces but doesn't have the sufficient info here to
complete its work.
tc is maintained.

I think eBPF didn't work in all the platforms? JIT doesn't sound like a
good solution for embeded platform.

Some VPS providers doesn't offer new enough kernel supporting eBPF is
another problem here, it is far more easy that just patching an old
kernel with this.
We don't add duplicative features because they are easier to
cherry-pick to old kernels.
I was trying to say the tc(8) or netlink solution sound more suitable for general deploying.
Anyway, I would learn into it while I would still send out the v2 of
this patch. I would figure out whether eBPF could solve all the problem
here.
Most importantly, why do you need a fixed mapping of IP address to
queue? Can you explain why relying on the standard rx_hash based
mapping is not sufficient for your workload?

Server

  |

  |------ tun subnet (e.x. 172.16.10.0/24) ------- peer A (172.16.10.1)

|------ peer B (172.16.10.3)

|------  peer C (172.16.10.20)

I am not even sure the rx_hash could work here, the server here acts as a router or gateway, I don't know how to filter the connection from the external interface based on rx_hash. Besides, VPN application didn't operate on the socket() itself.

I think this question is about why I do the filter in the kernel not the userspace?

It would be much more easy to the dispatch work in kernel, I only need to watch the established peer with the help of epoll(). Kernel could drop all the unwanted packets. Besides, if I do the filter/dispatcher work in the userspace, it would need to copy the packet's data to the userspace first, even decide its fate by reading a few bytes from its beginning offset. I think we can avoid such a cost.