Hi there, I was just testing wireguard performance on a new server machine (with lots of cores) and got lower performance than expected. However a lot of kernel processes were spawned only using CPUs up to 20% (but not higher). That got me thinking about a possible cause.
I remembered, that some time ago I noticed a similar behavior for dm-crypt and while investigating further I found this detailed analysis: https://blog.cloudflare.com/speeding-up-linux-disk-encryption/ It showed, that the kernel internal queuing has a huge impact on throughput and latency (and there's a fix/option for that in newer kernel releases, s. end of above blog article (search for "merged")). So I wondered if the wireguard code may face the same challenge? I had a quick look at the code and to me (as a non kernel developer) it looks like it could be worth a try, to adapt and benchmark the changes made for dm-crypt. I hope someone with more knowledge about wireguard / kernel internals can comment on that. (I know wireguard is one of the fastest VPN solutions around, but what if it could be even faster? :-) ) Bye, Marcel
