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:
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

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

Reply via email to