Currently XDP-Proxy performs rule-based forwarding where a (VIP, port, protocol) maps to a single backend destination, and connection tracking is primarily used to maintain NAT state and flow persistence. There is no mechanism to distribute new flows across a backend pool.
I would like to propose extending the datapath to support L4 load-balancing semantics, where a rule can reference multiple backend endpoints and the XDP program selects a backend only for new connections.
The scheduling and connection tracking(count and state) can remain fully in-datapath.
Active connection counts can be inferred directly from observed TCP lifecycle events (SYN → established → FIN/RST teardown), avoiding reliance on backend-reported metrics or userspace polling.
This keeps backend selection local, bounded, and limited to the new-flow path while preserving the existing fast path for established connections.
I have been experimenting with an XDP load-balancer datapath implementing:
hash-based flow distribution
least-connections (LC) scheduling
weighted least-connections (WLC) scheduling
with TCP state tracking and counter maintenance entirely in XDP.
If this direction aligns with the project goals, I would be interested in working on an upstream implementation.
Prototype datapath for reference:
Before preparing a patch, I would appreciate feedback on whether introducing backend pools and scheduler logic in the datapath fits the intended scope of XDP-Proxy, and any preferences around map design or connection lifetime handling.
Currently XDP-Proxy performs rule-based forwarding where a (VIP, port, protocol) maps to a single backend destination, and connection tracking is primarily used to maintain NAT state and flow persistence. There is no mechanism to distribute new flows across a backend pool.
I would like to propose extending the datapath to support L4 load-balancing semantics, where a rule can reference multiple backend endpoints and the XDP program selects a backend only for new connections.
The scheduling and connection tracking(count and state) can remain fully in-datapath.
Active connection counts can be inferred directly from observed TCP lifecycle events (SYN → established → FIN/RST teardown), avoiding reliance on backend-reported metrics or userspace polling.
This keeps backend selection local, bounded, and limited to the new-flow path while preserving the existing fast path for established connections.
I have been experimenting with an XDP load-balancer datapath implementing:
hash-based flow distribution
least-connections (LC) scheduling
weighted least-connections (WLC) scheduling
with TCP state tracking and counter maintenance entirely in XDP.
If this direction aligns with the project goals, I would be interested in working on an upstream implementation.
Prototype datapath for reference:
Before preparing a patch, I would appreciate feedback on whether introducing backend pools and scheduler logic in the datapath fits the intended scope of XDP-Proxy, and any preferences around map design or connection lifetime handling.