(Tom Herbert, SiPanda CTO, March 31, 2021)
So you might ask “why is SiPanda rethinking the network datapath?” Great question, and the reason is simple – the network programming solutions available to network engineers today are designed for specific narrow use cases, are often proprietary, and are difficult to learn and use. These solutions were not designed to provide a familiar, extensible and rich programming environment that network engineers at hyperscalers and cloud service providers can easily use to implement policies and capabilities.
A recent effort to address this is the P4 programming language and programming environment, which was designed to address packet processing at the L2-L3 layer in network switches and routers. Some of P4’s innovations include declarative representation for a protocol parser (as opposed to an imperative representation), as well as using a constrained program structure to make hardware acceleration feasible. However, P4 has several shortcomings as a potential solution to program the end-to-end (L2-L7) datapath:
P4’s specialized syntax and narrow semantics were designed for L2-L3 processing, and it is missing important constructs needed for network datapath programming at higher layer (L4-L7) protocols. For instance, it is not possible to implement a TCP stack in P4, as that requires state and TLV processing which are not supported in P4.
P4 is a completely new language and environment, and requires new programming skills and tools to develop and debug code. Given that most existing networking code is in C/C++, adopting P4 requires engineers on staff that are skilled in P4 language to either write new code or convert existing C/C++ code to P4.
While P4 was designed to be target-independent, its implementation is limited by the underlying architecture, and the code that is written must match the underlying architecture. For instance, P4 was designed to run on the V1 switch model, and its performance on non-V1 compliant architectures can be impacted, a problem made worse by the lack of automatic mapping from P4 to the underlying machine.
A P4 program that is targeted to one vendor’s hardware may not work on another vendor's hardware. For example, P4 supports includes methods to support custom hardware specific requirements, however this makes P4 less portable
Clearly, P4 brings a number of innovations to network programming, especially for L2-L3 processing. However, even with these innovations in mind, we need to ask the pertinent question: Is a new programming language necessary to achieve the desired effect? The answer is NO. Our next blogs will delve into this, and what the alternatives are for organizations that have to worry about all the levels of the network stack.
Comments