[RFC] Implement sticky SO_REUSEPORT_LB socket option

[ae]

Summary

This is proof of concept patch that we use to loadbalance many OpenVPN server instances.

OpenVPN is single threaded application and this is becoming a problem when we need to serve many clients. To solve this, we use this patch and also small patch for OpenVPN, that adds setsockopt with SO_REUSEPORT_LB socket option

patch-reuseport_lb1 KBDownload

.

The main idea is to have several OpenVPN server instances that are bound on the single UDP port. Each OpenVPN client have unique address and port that are persistent per a session. The kernel creates a "state" when load balanced socket replies to a new client . States are used to keep track of accordance between clients and servers.

We plan to separate this patch from SO_REUSEPORT_LB option to new SO_REUSEPORT_SLB socket option.

[donner]

Do I understand correctly, that this (heavy) patch works around the deficiencies of an unfit user space program?

[ae]

Yes. But I don't think the patch is heavy. Lets try to look from a different point.
SO_REUSEPORT_LB was introduced in D11003 with several fixes later, it has the same purpose - extend scalability of user space programs, that was used for example by DNS server.
The kernel should provide useful features for applications. Your app can use simple sockets API to send data, but also it can use more productive sendfile(2) syscall, etc.
OpenVPN is free opensource application that is widely used and supports different OSes. When all employee in your company are going work remotely, you can buy some hardware and thousands of licenses or can just use relatively small patch. This patch helps to extend scalability of OpenVPN for us, but it can be used for another apps that we don't use. I'm not forcing to commit it into base system, just share our experience and ask for comments.

[donner]

I'd like to split the functionality of load balancing from terminating.
If you have an TCP/UDP load balancer (i.e. Linux IPVS), you can distribute you load in a very generic way between different physical servers, jails, or processes.
But that's just my feeling to avoid duplicated complexity.