Fastd Performance Tweaking using MMSG API #2019
Labels
0. type: enhancement
The changeset is an enhancement
9. meta: upstream issue
Issue pertains to an upstream project
I did this already about a year ago, but not to forget this, I will document it here.
Currently fastd needs one syscall per packet to obtain/deliver a single packet from/to the kernel. The idea is to avoid this by obtaining and delivering multiple packages per syscall. Unfortunately using recvmmsg and sendmmsg only works for regular sockets, but not for tun/tap files in the current linux kernel.
It is not very complex to enable these syscalls for tun/tap files in the kernel, because internally the tun file is already accessible as socket (see patch below). However, this patch only works if tun is hardlinked into the kernel (as we are doing it in gluon).
Results:
I do not exactly remember which test hardware I used, but if I remember correctly, it was a TPLink 1043v3. However the exact throughput values are not that relevant. The relative throughput increase is significant. The BUFCNT column indicates how many packets were sent/received in one syscall.
Patches:
Fastd Patches: https://github.com/lemoer/fastd/commits/master
Linux Patch:
Discussion
Of course, it would not be a good idea to track/maintain such a downstream patch to the linux kernel. But to upstream it, somebody should pick this and have a look whether the patch could be done in such a way that it also works if tun is not hardlinked. I already tried to do this, but unfortunately my kernel hacking skills are not sufficient enough at the moment.
The text was updated successfully, but these errors were encountered: