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!
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 :).
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!
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 :)
“NFP” is for “Network Flow Processors”, the micro-engines and related architecture that we use at Netronome on the SmartNICs, and on which we run offloaded eBPF programs. By extension, it often relates to the cards themselves.
Also see Poettering's blog for how you can do very cool access control things via systemd taking advantage of EBPF:
http://0pointer.net/blog/ip-accounting-and-access-lists-with...
He talks about all this in the context of "NFP" offload but then never explains what this device is.
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!
How do you handle buffering? Any challenges with processing new headers/encapsulation schemes, or is it flexible in that regard?
[ Edit: Nevermind, found the data sheet: https://www.netronome.com/media/documents/PB_NFP-4000.pdf ]
One remaining question - how big is the space allocated to lookups/LPM?
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 :).
Any benchmarks data?
How many flows/stat does it keep track? What are the additional latency, etc?
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!
what instruction set are the cores? or are they eBPF ASICs essentially? :D
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 :)
where can I find this code?
“NFP” is for “Network Flow Processors”, the micro-engines and related architecture that we use at Netronome on the SmartNICs, and on which we run offloaded eBPF programs. By extension, it often relates to the cards themselves.
how does this new bpfilter + iptables compares with firewalld?
firewalld is just a management daemon with a dbus intrerface. nothing stops it from using iptables, nftables or bpfilter