[strongSwan-dev] StrongSwan 5.6.3, Netlink performance issue as responder.

[Thor Simon]

This seems like a...highly questionable design.  Almost as if someone did a software implementation modeled on the limitations of some particular piece of hardware (indeed, I think I've probably worked with that hardware...).

Any reason to think the kernel maintainers would not be receptive to a more general and functional hash or tree implementation here?
________________________________
From: Tobias Brunner <tobias at strongswan.org>
Sent: Dec 4, 2018 10:34 AM
To: "Vinay G. Pullela" <vpullela at parallelwireless.com>; dev at lists.strongswan.org
Subject: Re: [strongSwan-dev] StrongSwan 5.6.3; Netlink performance issue as responder.

Hi Vinay,

> Are you talking about the below parameters

Yes.

> Is the Limit 8 for the policy table set in kernel?

Yes.

> What are the best values for the Hash to get to at least 100K tunnels at
>  200tunnels/sec.

It doesn't depend on the number of SAs, but the negotiated traffic
selectors and what parts of the addresses you want the kernel to hash.
It will do so if the network prefixes configured in a policy's selector
(src/dst) are *both* equal or larger than the respective thresholds.
So with the IPv4 example you gave, only policies that have a local net
mask (src for OUT policies, dst for IN/FWD policies) between /16 and /32
*and* a remote net mask of exactly /32 will be hashed.  All others are
stored in the overflow list.

> And other kernel buffer parameters needs to be set from below list?

I don't think so.

Regards,
Tobias