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 <[email protected]> Sent: Dec 4, 2018 10:34 AM To: "Vinay G. Pullela" <[email protected]>; [email protected] 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
