Randy Li wrote:
On 2024/8/1 22:17, Willem de Bruijn wrote:A custom mapping function is exactly the purpose of TUNSETSTEERINGEBPF.
Randy Li wrote:I was trying to say the tc(8) or netlink solution sound more suitable
On 2024/8/1 21:04, Willem de Bruijn wrote:tc is maintained.
Randy Li wrote:tc(8) was old interfaces but doesn't have the sufficient info here to
On 2024/8/1 05:57, Willem de Bruijn wrote:Lack of experience with an existing interface is insufficient reason
nits:I see.
- INDX->INDEX. It's correct in the code
- prefix networking patches with the target tree: PATCH net-next
Randy Li wrote:I know this eBPF thing. But I am newbie to eBPF as well I didn't figure
On 2024/7/31 22:12, Willem de Bruijn wrote:If using an IFF_MULTI_QUEUE tun device, packets are automatically
Randy Li wrote:That is for sch_multiq, here is an example
We need the queue index in qdisc mapping rule. There is no way toIn which command exactly?
fetch that.
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
load balanced across the multiple queues, in tun_select_queue.
If you want more explicit queue selection than by rxhash, tun
supports TUNSETSTEERINGEBPF.
out how to config eBPF dynamically.
to introduce another interface, of course.
complete its work.
I think eBPF didn't work in all the platforms? JIT doesn't sound like aWe don't add duplicative features because they are easier to
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.
cherry-pick to old kernels.
for general deploying.
ServerAnyway, I would learn into it while I would still send out the v2 ofMost importantly, why do you need a fixed mapping of IP address to
this patch. I would figure out whether eBPF could solve all the problem
here.
queue? Can you explain why relying on the standard rx_hash based
mapping is not sufficient for your workload?
|
|------ 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.
Please take a look at that. It's a lot more elegant than going through
userspace and then inserting individual tc skbedit filters.
See SKF_AD_QUEUE for classic BPF and __sk_buff queue_mapping for eBPF.