So before anyone gets excited about using this, XDP has to be enabled at the driver level to work, because basically is allows you to write your own program to handle incoming packets from the driver, taking the kernel out as the middle man. The list of supported drivers is small:
I’m actually working on porting XDP into the Xen net front end driver to see if I can’t get something like this working in AWS. If I do it, I’ll likely post an example about it here:
How are the licenses? React and Zstandard had licenses that drove away a lot of heavy users (basically anyone who had an active legal department) - and were re-licensed without the onerous patent constraints after an apparent exodus of users (the public outcry seemed to make no difference, but the exodus did).
An interesting idea to load balance at L4 so as not to terminate the TCP sessions (for speed). Normally this constrains the network rather as you can't route the output packets normally after that (they need to be routed to a vLAN) but encapsulating with IPIP means the load balancer output can go straight back into the normal routing layer.
Not constraining the output of the load balancer to a single vLAN really helps for larger networks.
Reading the readme I see they've made every effort to process the packets as little as possible to it seems likely that this will run at line speed.
For L4 the main competitor is LVS which scales pretty well in my experience but probably not as well as this.
What is RSS in this context, ? My guess is that it's not this RSS https://en.wikipedia.org/wiki/RSS because I do not see how/why you should need any rule at L4 to maintain compatibility with an XML based protocol.
What is the difference with IPVS kernel module in Linux? Both are layer 4 load balancers and IPVS has come a long time and is proven to be good. Any performance comparisons available?
IPVS cannot be dynamic like XDP can, which can be powered by a reactive bpf program. XDP bypasses every kernel function and basically takes over packet processing at the driver level, so the performance tends to be pretty good. Julia Evans wrote a blog post and has some performance numbers at the bottom of her post:
https://jvns.ca/blog/2017/04/07/xdp-bpf-tutorial/
This doesn't really replace something like haproxy. In the diagrams, the "real" servers that they are load balancing to are L7 load balancers like HAProxy (using https://github.com/facebook/proxygen most likely)
The problem this solves is is when you are using haproxy but need redundancy or a single server is no longer capable of handling the load and you need to scale out to 2+ servers.
You could run 4 haproxy servers and use round robin DNS to load balance between them, but as they say, this has the problem of:
> compared to DNS it doesn't need to wait for TTL to redirect traffic from failed L7 lb.
Many people likely use anycast/ECMP for this case, but that has the other issue they mention:
> compared to anycast-based solution, L4 lbs are more resilient to the networking related issues (which triggers mass ECMP reshuffle)/ enable better handling of adding/removing of L7 lbs from the pool as well as provide better support for unequal load balancing.
> The problem this solves is is when you are using haproxy but need redundancy or a single server is no longer capable of handling the load and you need to scale out to 2+ servers.
Please describe how HAProxy running in l4 mode is a solution to this problem.
haproxy terminates tcp session. ipvs/katran does not. the whole purpose of ipvs/katran is to scale out layer of load balancers, which terminates tcp (transport in general) sessions. so tl;dr ipvs/katran solving the problem of scaling out "haproxy/nginx/varnish/w/e else" layer
HAProxy and network layer load balancers are very different kind of beasts. HAProxy requires, for example, you to return your traffic via HAProxy which can make HAProxy a bottleneck, requests are usually smaller than responses. HAProxy will also require you to terminate your connections which will make you lose your source IP address if you cannot get it using proxy protocol.
There are also various other benefits, but network layer balancers do have their own share of downsides as well. Like you need to have pretty big control over your infra in order to use them (generally speaking it's not feasible to use them in public clouds), configuration is more complex, they won't do TLS for you etc.
It still requires you to terminate the connection on HAProxy. None of the things I mentioned are affected (you lose source IP without proxy protocol, return traffic must pass thru HAProxy, you can do TLS).
http://prototype-kernel.readthedocs.io/en/latest/networking/...
I’m actually working on porting XDP into the Xen net front end driver to see if I can’t get something like this working in AWS. If I do it, I’ll likely post an example about it here:
https://github.com/newtools/ebpf
As an aside cloudflare is using that repo for an XDP load balancer as well.