I think I'd feel more comfortable if I could drop an .rs file into the eBPF dir instead of a .c one. It's already a Rust project! :)
And for some reason I was expecting this to be a kernel-accelerated webserver - if that could be done safely using eBPF that would be amazing!
Also, single-threaded? Forking and sharing an incoming connection queue is basically trivial on Linux, that should be literally just a few lines, even with Rust. Use SO_REUSEPORT and the kernel will do the rest.
FWIW, if you're going to push for io_uring, you should also be pushing kTLS IMO, you'll drastically simplify your design if you can avoid pumping userspace SSL after the handshake.
Pleas think before forking(). Do not follow Apache blindly...
Code, as is today, looks [acording to benchmarks] better then nginx, except one case !
There is fcgi in, right ? So all that additional processes are already started in the backend. If benchmarks are real no need to complicate code before some industry adoption. Of course there can be a branch to check possibilities :)
And forking is complicated and full of surprising traps. Even if they are somewhat "standard" historic Unix traps... Case study: Perl - better don't use fork there even if "threads" are in.
It does leave me wondering about other runtimes that could be used as the go-between though, because at the point of compiling Rust, an approach like Cloudflare's Pingora (https://github.com/cloudflare/pingora) which I've tried using before... in _theory_ should be a 'nicer' solution - just historically awkward when I've tried using it the way that I'd have liked. Wish it were more library-shaped!
I think I'd feel more comfortable if I could drop an .rs file into the eBPF dir instead of a .c one. It's already a Rust project! :)
And for some reason I was expecting this to be a kernel-accelerated webserver - if that could be done safely using eBPF that would be amazing!
Also, single-threaded? Forking and sharing an incoming connection queue is basically trivial on Linux, that should be literally just a few lines, even with Rust. Use SO_REUSEPORT and the kernel will do the rest.
FWIW, if you're going to push for io_uring, you should also be pushing kTLS IMO, you'll drastically simplify your design if you can avoid pumping userspace SSL after the handshake.