njv4567

Hey good question...trust me i wish they were eBPF ASICs :p. So we have a general purpose Compute engine, it is a processor in the same way ARMs/X86’s etc are BUT it has an instruction set which is optimized for networking, and as well as a ton of threads also has a giant amount of registers. These teo properties mean that mapping bpf bytecode (effectively a networking ISA) to our assembler (also a networking ISA) is relatively simple...if you are interested check out the code from our upstream JIT in the Linux kernel. That will show you how the whole thing fits together :)

Yeah-i showed a couple of things with regards to latency in the report...i also posted another graph on my very empty twitter (@viljoen_nic). We get massive improvements, especially in the tail latency cases, due to not passing across PCIe. If there is anything specific you want let me know and i will see what we can do!

So I believe at the moment we allocate about 1GB of on card DRAM backed storage for lookups, but the chip supports way more DRAM (8GB) and there are other larger chips that can support way more even (up to 24GB). But we have focused on this guy for now :).

Hey Man! Thanks for the comment. Yeah, maybe i assumed that not this many people would who werent already familiar would see this :)

The NFP is our many core processor with 72 cores (50 used for BPF) each of those cores has 8 threads which are cooperatively multithreaded. The whole chip is about 12-14W.

This chip gets used on our NICs and works with our upstream kernel driver, which contains the JIT, and that is what does the offload work. Check our our videos from Netdev 1.2 and Netdev 2.2 if you are interested!