[strongSwan] Problem with pcrypt

[Noel Kuntze]

You use ethtool to configure the number of queues and echo to set the interrupts of the queues to the CPUs,
as well as mapping what core works on what queue.

Here's a list of resources for you to read:

https://www.kernel.org/doc/Documentation/networking/scaling.txt
https://www.kernel.org/doc/Documentation/IRQ-affinity.txt
https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/aes-ipsec-performance-linux-paper.pdf <- for showing how fast you can go
https://blogs.dropbox.com/tech/2017/09/optimizing-web-servers-for-high-throughput-and-low-latency/ <- shows some general performance knobs
https://access.redhat.com/articles/65410
https://access.redhat.com/sites/default/files/attachments/20150325_network_performance_tuning.pdf

If you have a lot of clients*, play with the bits in the spdh_thresh section of the strongswan.conf configuration.
*CHILD_SAs
Generally, AES-GCM with some good (EC)DHE group is fine. AES-GCM can be completely hardware accelerated using AES-NI.

There is an example cipher suite on the SecurityRecommendations page.

Kind regards

Noel

On 15.09.2017 20:15, Sven Anders wrote:
> Am 15.09.2017 um 19:27 schrieb Noel Kuntze:
>> Hi,
>>
>> I guess ksoftirqd is rotating and kworker, too? If that's the case, you're suffering from
>> an extremely disadvantageous distribution of ESP packets.
> 
> Hmmm. I did not see all CPUs are saturated. Only two CPUs are under load and the soft-irqs are
> under 5%. kworker is under 5% too.
> 
>> You need to set the number of RX and TX queues on the card to the number of cores and
>> use RSS to distribute the SAs correctly over all queues. Bind one RX and one TX queue to one core each.
> 
> What tool to I use for this?
> 
>>  Then use AES based ciphers, so you can use AES-NI. You can then get line speed per CHILD_SA.
>>
>> Pcrypt has some overhead due to synchronisation, so if your setup's performance problem is not caused
>> by cipher execution time, pcrypt will not improve the situation.
> 
> What bothers me is, that the throughput is decreasing. I can accept the due to synchronisation the
> throughput is not increasing, but decreasing?
> 
>> Use aes128gcm8. aes256gcm16 causes unnecessary overhead and costs more performance.
> 
> Which ciphers do you suggest/recommend?
> Do you know a working configuration that I can use as a reference?
> 
>> Disabling replay protection does not improve performance.
> 
> Ok, I did read about this in some posting, so I tried this too.
> 
> 
> Regards
>  Sven Anders
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170915/275b0f63/attachment.sig>