P4: open-source programming language for high-performance packet switching(p4.org)
p4.org
P4: open-source programming language for high-performance packet switching
http://p4.org
19 comments
Snabb is a great project. Current P4 support is [0]:
0. https://groups.google.com/d/msg/snabb-devel/GkWONJcuF4E/Tc8P...
a working lexer and parser for the full p4 language (version 1.1: working
release). There are plenty of unit tests, but I'm sure there are
still bugs (not yet a lot of p4 v1.1 code to test out at this point,
most existing p4 code is v1.0 which has some significant differences).
0. https://groups.google.com/d/msg/snabb-devel/GkWONJcuF4E/Tc8P...
I am interested in Snabb and other methods of doing high performance packet processing to help with developing DDOS protection methods that could be implemented without expensive hardware.
If DDOS filtering modules can be written in P4, then they could be used on software switches and maybe even compiled into packet filters that run before packets are processed by the Linux kernel (or compiled into a kernel-bypass module for embedding in an application).
I think we really need to have better support for low-level high performance packet filtering (i.e. before the packet gets to higher levels in the kernel).
With multi-gigabit networking becoming cheaper, we really should have better support for dropping bad traffic.
How about a switch layer that runs in the kernel? Physical NICs and virtual NICs could be handled by the switch layer (programmed using P4 or eBPF). The kernel would only have to handle packets it receives from the virtual NICs. This would allow packet filtering and even some routing to happen without having to go through the kernels network-stack. The software switch layer would work like a data-plane with the kernel as the control-plane (like a lot of hardware routers/switches). If the computer has specialized hardware (smart NICs, co-processors), then the switch logic (P4 code) could be handled in that hardware instead of on the CPU.
If DDOS filtering modules can be written in P4, then they could be used on software switches and maybe even compiled into packet filters that run before packets are processed by the Linux kernel (or compiled into a kernel-bypass module for embedding in an application).
I think we really need to have better support for low-level high performance packet filtering (i.e. before the packet gets to higher levels in the kernel).
With multi-gigabit networking becoming cheaper, we really should have better support for dropping bad traffic.
How about a switch layer that runs in the kernel? Physical NICs and virtual NICs could be handled by the switch layer (programmed using P4 or eBPF). The kernel would only have to handle packets it receives from the virtual NICs. This would allow packet filtering and even some routing to happen without having to go through the kernels network-stack. The software switch layer would work like a data-plane with the kernel as the control-plane (like a lot of hardware routers/switches). If the computer has specialized hardware (smart NICs, co-processors), then the switch logic (P4 code) could be handled in that hardware instead of on the CPU.
> How about a switch layer that runs in the kernel?
That's what openvswitch.ko is doing already. I agree that P4 is interesting also in this perspective: having the compiled P4 blob being ran either by the CPU or, if available, in hardware by a smart NIC.
That's what openvswitch.ko is doing already. I agree that P4 is interesting also in this perspective: having the compiled P4 blob being ran either by the CPU or, if available, in hardware by a smart NIC.
I posted this after reading the various posts regarding Barefoot Networks exiting stealth⁰.
They've (jointly?) developed P4 and have tooling to compile it down to their new switch silicon, Tofino.
Hard to say exactly how impressive all this is considering how price sensitive and competitive merchant silicon is.
They could, for example, have glued a large FPGA to a huge amount of network I/O and then developed a P4 compiler to their FPGA fabric. Who knows?
P4 seems to be attempting to be a CUDA for switching, except more open. Barefoot, I presume, is betting on producing the most efficient, by whatever metric, hardware implementation of it.
⁰https://hn.algolia.com/?query=barefoot%20networks&sort=byDat...
They've (jointly?) developed P4 and have tooling to compile it down to their new switch silicon, Tofino.
Hard to say exactly how impressive all this is considering how price sensitive and competitive merchant silicon is.
They could, for example, have glued a large FPGA to a huge amount of network I/O and then developed a P4 compiler to their FPGA fabric. Who knows?
P4 seems to be attempting to be a CUDA for switching, except more open. Barefoot, I presume, is betting on producing the most efficient, by whatever metric, hardware implementation of it.
⁰https://hn.algolia.com/?query=barefoot%20networks&sort=byDat...
P4 syntax like ACPUL, but ACPUL started up as more generic minimalistic algorithmic language. It can be easy compiled to multiple target VMs & hardware also as P4.
I think how to use ACPUL for Nginx frontend module, but found some issues in network using, like IPv4/v6 addresses formats, strings, etc.
ACPUL is currently using in ACPU iPad IDE (Codea like).
Here is sample code https://github.com/d08ble/acpul-demo/blob/master/dota/contro...
Very interesting possibility is compilation of P4 into BPF:
http://services.geant.net/GTS/Resources/PublishingImages/Pag...
http://openvswitch.org/support/slides/p4.pdf
https://github.com/iovisor/bcc/tree/master/src/cc/frontends/...
http://services.geant.net/GTS/Resources/PublishingImages/Pag...
http://openvswitch.org/support/slides/p4.pdf
https://github.com/iovisor/bcc/tree/master/src/cc/frontends/...
I took a quick look at github, didn't see an option to compile to iptables. That would be an interesting use case for me.
One of the key advantages of p4 is that you don't have to use iptables. Instead p4 would compile down to a binary packet processor in either machine language, something like eBPF, or directly onto a hardware coprocessor on your NIC.
Compiling to iptables would be incredibly slow and miss the advantages. Plus, p4 is more general than iptables so many p4 programs could not be expressed as iptables.
Compiling to iptables would be incredibly slow and miss the advantages. Plus, p4 is more general than iptables so many p4 programs could not be expressed as iptables.
A possibility for it's use is directly in a application then.
For very high performance packet generation and processing the Linux kernel is sub-par because it's extremely complex and general purpose. There is just too much going on.
example:
https://blog.cloudflare.com/kernel-bypass/
For very high performance packet generation and processing the Linux kernel is sub-par because it's extremely complex and general purpose. There is just too much going on.
example:
https://blog.cloudflare.com/kernel-bypass/
There is work going on upstream to allow bypassing the entire network stack in the kernel using eBPF. Kernel bypass techniques though have been the gold standard in performance for quite a while, but they don't work well for container networking, so kernel networking is starting to become more relevant to people who care about performance.
Maybe compile to nftables bytecode instead?
> ... didn't see an option to compile to iptables.
did you mean bpf ?
did you mean bpf ?
Not a great choice in name, considering "P4" is the command line utility/common abbreviation for Perforce SCM
Agreed. We use Perforce at work. I have typed P4 so many times that it will essentially always mean Perforce to me.
For those who don't use P4, imagine if this project were named git (though that might not be as fair since git is much more popular).
For those who don't use P4, imagine if this project were named git (though that might not be as fair since git is much more popular).
I haven't used Perforce for probably 15 years and it was still the first thing that entered my head when I saw the headline.
This is true, but I would hope context should be enough to distinguish between the two in most cases. Could get confusing if one were to use P4 for their P4 repo, though.
Could be even more confusing if Perforce decides to rewrite in P4.
"p4 revert ..."
I think a language like P4 will be great for sharing switching logic. I hope we will see re-usable modules written in P4 that can be shared.
0. https://github.com/esbullington/snabbp4 1. https://github.com/snabbco/snabb