3 ms·

I like the idea. 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

I like the idea. 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.

losfair 5mo ago
Hi, thanks! Will implement forking + SO_REUSEPORT. I've been using nftables for things like this so haven't needed it for myself yet :)
- opem 4mo ago
  I wonder how zs_reverse_proxy() + SO_REUSEPORT would perform
- Woodi 4mo ago
  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.
tekacs 4mo ago
I was curious for the same thing, so I quickly (with an agent) threw support for .rs scripts together on my fork: https://github.com/tekacs/zeroserve/commit/b33f261615d20d55b3324e81640b932e04f2050b https://github.com/tekacs/zeroserve/commit/b33f261615d20d55b... 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 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!

losfair 5mo ago

Hi, thanks! Will implement forking + SO_REUSEPORT. I've been using nftables for things like this so haven't needed it for myself yet :)

opem 4mo ago
I wonder how zs_reverse_proxy() + SO_REUSEPORT would perform
Woodi 4mo ago
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.

tekacs 4mo ago

I was curious for the same thing, so I quickly (with an agent) threw support for .rs scripts together on my fork: https://github.com/tekacs/zeroserve/commit/b33f261615d20d55b3324e81640b932e04f2050b https://github.com/tekacs/zeroserve/commit/b33f261615d20d55b... 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 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!