Date: Sun, 31 Aug 2014 22:05:11 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Alfred Perlstein <alfred@freebsd.org> Cc: Gleb Smirnoff <glebius@FreeBSD.org>, freebsd-arch@freebsd.org Subject: Re: script(2) [was: [CFT/review] new sendfile(2)] Message-ID: <2770.1409522711@critter.freebsd.dk> In-Reply-To: <540382E2.3040004@freebsd.org> References: <20140529102054.GX50679@FreeBSD.org> <20140729232404.GF43962@funkthat.com> <20140831165022.GE7693@FreeBSD.org> <540382E2.3040004@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--------
In message <540382E2.3040004@freebsd.org>, Alfred Perlstein writes:
Can I inject an old idea whose time may finally have arrived ?
The basic thing we are trying to do here is to avoid userland/kernel
context-switches, because they are so expensive.
This is a very old problem, the TTY line-disciplines, PCAP, accept
filters and sendfile are all hacks that try to "optimize" specific
use-cases.
Imagine we instead define a byte-code-engine which interprets a
string of commands, sort of like the pcap filtering engine already
does. The corresponding syscall would be "follow_the_script(2)"
The first set of commands in the language would be a sensible
subset of syscalls and library functions
open file
close file
accept()
read()
write()
memcpy()
...
All of these functions works *exactly* the same as they would have
in userland, arguments mean exactly the same etc.
The value of this facility explodes as we add smarter commands which
can do stuff we would normally have to return to userland for:
if {...} else {...}
for(;;) {...}
do {...} while()
move bytes (directly) from fd to fd (optional: in the background)
read at least N bytes
write with timeout
interpret [bl]e{8,16,32,64} at address
search for pattern X
By suitably defining commands in the bytecode, pretty much all of
sendfile and accept-filters can be implemented using
this facility instead.
PCAP and ldisc are probably to entrenched to be worth the bother,
and neither are not relevant in typical network server usage.
One reason I think this ideas time as come is that the current
proposal for HTTP/2.0 is a mess, and will be very hard to implement
to anything approaching wire-speed without such a facility.
And yes, if we go far enough, you can basically push an entire
static-content HTTP/1.1 server into the kernel that way...
Of course the language has to be safe to execute in the kernel:
Hard boundary checks, copyin/copyout and all that, but that is
not rocket science: PCAP solved it ages ago.
And it's really not that hard to implement...
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2770.1409522711>