There are two uses cases for use of P4-Ansible software.
- Code reuse.
- Upgrade network node in the field.
Code Reuse
P4 as a programming language does not support code reuse. Adding a new header requires changing code in many places. More details regarding shortcomings are available in slides 6-9 here.
Upgrade in Field
The promise of P4 is to have a customer change the switch (or p4-enabled network node) data plane in the field. For brevity, rest of this note uses the term switch but the node could be a smartNIC or another type of node. If the switch runs vendor code, how does the customer merge his/her P4 code with vendor's? An operator upgrades a switch several times during the lifetime of the switch. The customer also runs feature set A on 100 switches and feature set B on another 100. Each set uses customer P4 programs merged with vendor’s. How is any operator running the network unless a tool exists to automatically merge customer’s P4 program with any version of vendor’s P4 program with different feature sets?
This is where a tool comes in, provided by the switch vendor. The tool facilitates merging customer and vendor P4 programs. The first tool, called daPIPE, is released by Cisco for trials. Our P4-Ansible is second.
A simple example use of our tool merges a small Video RTP TWC P4-16, say, customer program, with large NPB P4-16, say, vendor program. Our tool automatically merges the two programs and creates a new P4 program which is compiled with Tofino compiler. The compiled output has been tested on Tofino to work. Similar to Cisco daPIPE, our tool exposes some vendor P4 program information to customer to help write a P4 program - it is information such as parser states names, data structures, and names of P4 objects such as parser, control, and deparser. All vendor P4 code cannot stay hidden because a simple use case fails to merge customer and vendor programs. The example adds new a tunnel type. After decapsulation, somewhere at the beginning of ingress, you want the rest of pipeline to execute on the decapsulated packet. How do you integrate with code that you can't see?
A comparison of the two tools is included below.
| Cisco (daPIPE) | MNK (P4-Ansible) | Comments |
| Supports only P4-14 | Supports only P4-16 | MNK helps customer translate P4-14 to P4-16. Open to adding P4-14 on customer request. |
| Single parser and deparser | Multiple parsers and deparsers | P4-14 uses single parser and deparser. P4-16 PSA models uses two of each. One asic model uses 5 parsers and 2 deparsers making merging complex. P4-14 is a frozen language spec, while P4-16 is adding features and evolving the language. |
| Supports Tofino | Supports Tofino, Spectrum from Mellanox, Pensando asic, and softswitch v1model | |
| Does not support all P4 programs | Supports any P4 program | |
| Supports only Cisco switch | Supports any P4-enabled node | |
| Supports incremental program merging | Supports incremental and forklift upgrade merging | An Arista network switch has shipped to Microsoft Azure cloud with support for 256K VTEP. This switch has a Tofino asic using all stages. There is no room left on the asic for any incremental P4 program merging. This switch requires a forklift upgrade to remove some existing features and add new ones. P4-Ansible has automated the forklift upgrade once a user provides what feature(s) to remove and add. |
Details
See details here