so the user-space side needs to process those packets quickly otherwise they are simply dropped.

This seems a good fix to me for the problem (mentioned elsewhere) that "more and more stuff gets crammed into the fast path until the fast path becomes the new slow path".

Have something like this, which by default does nothing. Then it's up to the user to put stuff into it, with the constraint that if too much goes in, packets get dropped at random because the buffers fill. Probably the main use of this would be to fight DDoS, because there you don't really care. By killing bad packets as fast as you can, you increase the chances of the good packets getting through, and you rely on TCP to cope with the packets you didn't intend to drop.

But the devs no longer need to worry about "the fast path becoming the slow path" - this would definitely be for sysadmins to tweak with the simple constraint that you can have heavy traffic, or complex rules, but if you have both then packets will start getting dropped at random. Their pick.

Cheers,
Wol