Note that thanks to AES-NI vectorization (an example of hw acceleration I was referring to) it reaches more than 16Gps/core on the same test on Icelake.
Those numbers can grow up to 50% for big packets (1500-bytes and higher).
With a high performance stack, IPsec (and Wireguard for that matter) workloads are limited by crypto performance, not packet processing performance, and the perf difference between IPsec with AES-256-GCM and Wireguard is basically the perf difference of AES-256-GCM vs Chacha20-Poly1305 of your platform.
Yes. But VPP also supports Wireguard, and when doing apple-to-apple comparisons, the performance difference between Wireguard vs IPsec AES-256-GCM is close to 2x. See https://fosdem.org/2021/schedule/event/sdn_calicovpp/attachm... slides 23 and 26: 5Gbps of Wireguard vs 9.5Gbps of IPsec.
And the main reason is the cipher: one is hw-assisted (AES-NI on x86), the other is not.
Again, I do think Wireguard is nice because it is a clean sheet design with good choices and it "just works". However when I hear "Wireguard is faster than IPsec" it is not true in my experience, and can be easily explain by the cipher choice.
Note that thanks to AES-NI vectorization (an example of hw acceleration I was referring to) it reaches more than 16Gps/core on the same test on Icelake.
Those numbers can grow up to 50% for big packets (1500-bytes and higher).
With a high performance stack, IPsec (and Wireguard for that matter) workloads are limited by crypto performance, not packet processing performance, and the perf difference between IPsec with AES-256-GCM and Wireguard is basically the perf difference of AES-256-GCM vs Chacha20-Poly1305 of your platform.