I recently learned about FreeBSD's accept_filter socket option which can allow a worker process to avoid context switching by, for example, waiting until a full HTTP request is received with accf_http:
This is a filter to be placed on a socket that will be using accept() to receive incoming HTTP connections.
It prevents the application from receiving the connected descriptor via accept() until either a full HTTP/1.0 or HTTP/1.1 HEAD or GET request has been buffered by the kernel.
If something other than a HTTP/1.0 or HTTP/1.1 HEAD or GET request is received the kernel will allow the application to receive the connection descriptor via accept().
The utility of accf_http is such that a server will not have to context switch several times before performing the initial parsing of the request. This effectively reduces the amount of required CPU utilization to handle incoming requests by keeping active processes in preforking servers such as Apache low and reducing the size of the file descriptor set that needs to be managed by interfaces such as select(), poll() or kevent() based servers.
My gut feeling is that on modern hardware, serving traffic to clients on high-speed connections (cable modem/DSL speeds or better) this may be a micro-optimization. Given that accf_http can't be used for HTTPS or HTTP/2 connections and accf_data just waits for the first byte, I don't see much advantage here. Maybe they'd save one or two context switches?
Are there any recent (post-2015 maybe?) benchmarks about how much FreeBSD's accept_filter can actually improve performance or throughput/concurrency?
accept_filter