First we create a portable bytecode in order to run executable code in a hardware-independent way.<p>Then we create hardware to run that bytecode.<p>(No criticism intended to the author, I guess the goal is just to have fun).
A NIC company Netronome has had something like this (i.e. running physically on the NIC) as a product for a couple of years now. They have a NIC with lots of proprietary cores that with eBPF can be made to run user code.<p>To be useful for capture it needed an extra feature, ability to grab a synchronized hardware time counter value, and deliver to a user-space buffer. Writing to user space memory, for kernel bypass, at least once was an underdeveloped eBPF feature; don't know its current condition.
This is really cool. I wonder about whether or not putting the ISA itself directly in hardware is the right path forward, versus "virtualizing" it and compiling the bytecode again down to (yet another) architecture. It's a much better fit for hardware than a lot of "virtual" ISAs, though. There are some reasons you might do this, but then again, reasons not to. Netronome uses this virtual approach instead of baking eBPF into their processors, from my cursory understanding. An advantage of that is agility; FPGAs are only so agile compared to a software compiler and on top of that new evolving features have impacts on things like clock frequency, testing, etc.<p>Beyond that there are also some big "what ifs" about eBPF; for example the fact it just uses the underlying Linux kernel memory model for concurrency. Maybe this is good. Maybe this is bad. I don't know. But it has a big impact on the underlying design of the memory subsystem for any real design. Intuitively I want to say the concurrency abstractions in eBPF should have always been much, much higher level from the start for reasons like this (for example, maybe it would have just been easier to flat-out introduce the concept of transactions, if you're already going to write a verifier to check every incoming program. This is much more difficult than what the verifier does today, but it's also a very well explored one and makes the machine memory model irrelevant. It's not the kind of stuff kernel developers do or think about, though...) But it's not, so it's still definitely something to think about. Do alternative vendors handle this already if they offload programs?<p>There is also the current state we're in where "what is a valid eBPF program" mostly just comes down to "whatever the Linux kernel says is a valid eBPF program", so you can probably get into situations where code emitted by Clang will work in one of the two, and not the another (note: you can <i>already</i> get into situations where Clang will emit code from valid input that the kernel then rejects, so this probably isn't a very difficult example to construct.) This project already has some differences in ABI versus Linux, though, so...<p>Overall this is still a really cool project, though. You'd have to do something like this to answer all the above, and it bills itself as an experiment. You could still have a lot of fun with this even ignoring all that. And it doesn't use Verilog. 10/10.