Blog

I was talking to a friend on their options for a multi-vendor strategy. He said, “it is like mixing water and oil”, talking about supporting common interfaces to multiple vendors. For the record, I am biased towards both P4 and NPL, possibly building the first ASIC based P4 switch on Doppler, and having contributed to NPL made me connect with both. I delved into minute details of both languages and architectures. There are practical challenges and opportunities in bringing these languages together.

P4 has come a long way from the early days where the majority of the platforms supported were x86, FPGA, network processor based and only few were ASIC based. With Cisco adopting P4 for their Silicon One, and possibly moving away from C from its previous programmable architectures, P4 can further its claim to be the multi-vendor language for all programmable pipelines. However there are improvements needed for a wider adoption and standardization. For example, Match-Action tables are an elevation of PISA architecture that may not map to other architectures. There is tremendous value in improving and standardizing P4, especially on Broadcom platforms that lead the market with silicon innovation and merchant silicon.

NPL was created to build efficient pipelines and for faster innovation cycles, apart from marketing reasons. How hardware primitives are abstracted, disaggregated and not relying on a single universal primitive (Match-Action table), makes NPL implementations more efficient. NPL is also an open language that was shared with many industry stakeholders regularly. Some of these concepts can be adopted by the wider community.

For supporting multiple architectures as part of a multi-vendor strategy, there are two main choices. First, P4 can be enhanced to support a wider set of architectures. Second, higher level frameworks will subsume P4, NPL and other languages below. Other choices like translations are intermediate solutions that do not provide a complete alternative. In both these cases the primitives, abstractions and programming models of multiple device architectures need to be compared, contrasted and rationalized to prevent ending up with siloed solutions.

For enhancing P4, there are low hanging fruits that we can get started with very quickly, for Eg. multi-lookup tables. Be warned that this is not for the faint of the heart to drive this all the way to adoption. One of my mentors a while back said something like “when elephants are dancing, ants should stay away”. Driving adoption and dealing with bigger forces of the market is not easy unless you are one of the elephants or there is “Telecom” in your company name.

Building Frameworks to subsume P4 and NPL are an easier hill to climb but may take a much longer time. Frameworks do solve the broader scope of adoption problem beyond the specification of packet pipeline, to include runtime interface, SDKs, modularity etc. It is possible and is more likely that everyone builds their own frameworks for dealing with multiple architectures and perpetuate the silos.

Whatever is your approach to multi-vendor support, evaluating the primitives, abstractions and programming models is very important at this stage to prevent siloed solutions. Tools and automation are the key to the multi-vendor journey.

Keep watching this space for more on the topic.