Speaker
Description
Traditionally the kernel community have introduced new sysctl tunables in places in the code where there is no "one-size-fits-all" answer. With BPF we have the opportunity to make such decision points programmable. A simple example of this is the kernel socket acceptq length, set via a combination of the listen() backlog and somaxconn sysctl. While the traditional advice has been to set this to a very high value to allow for connection bursts, doing so can lead to unacceptable connection latencies for applications, particularly when the application is doing CPU-intensive processing that limits connection acceptance rate. We only drop SYNs when the acceptq is full, but in such cases it would be beneficial to drop earlier to allow the service to recover. Having a BPF program attached could detect such conditions and handle this case by dropping SYNs. Having a dynamic response - potentially informed by wider system state - would be helpful here and in other cases. Investigation of decision points like these for BPF programmability - perhaps via a general sysctl()-centric BPF attachment - would be worth exploring.