Hello,
I am going deeper through P4 but now I am confused with the words. Can someone explain to me the difference between “p4_16”, “V1Model”, “PISA”, and “bmv2”?
Thanks,
Sara
1 Like
Hi @sarahshakeri,
I give you first a very brief summary here in case you do not want to go through all the post (TL;DR):
-
P4_16 or P416 is the latest version of the language (previously P414) and it makes significant changes from P414. See Section 3.2 of P416 spec. Both versions are still used but P416 is considerably more popular and widely adopted. I think P414 will probably stop being used in the following years.
-
The V1Model is the architecture commonly used with the BMv2 Simple Switch. It defines the programmable structure of the pipeline. There is a direct relationship between the blocks you see in Fig.3 and the code you write for that particular achitecture. Check the P4 code when programming the BMv2 Simple Switch listed in the extended description.
-
BMv2 is the abstract switch model (a framework) and lets users implement a target on top of it, like the Simple Switch or the one for PSA (see bmv2 and simple switch info here).
-
PISA (Protocol Independent Switch Architecture) is a single pipeline forwarding architecture. I think this concept is related to the times that P414 was the main language version. When referring to PISA, you often see a picture like this:
Fig.1 PISA- The P416 language version (this is a perception more than a fact) seems to have put the PISA term aside. P416 also required the “architecture” concept (like V1Model) so the concept of PISA made more sense to how you define the pipeline when talking about P414-programmable targets. Now, some devices have adopted P416 and defined the device architecture pipeline following a similar procedure, like the V1Model or PSA. I remember I programmed a Netronome NIC using P414, and they adopted the V1Model architecture later on along with the P416 language.
In a more detailed fashion…
As mentioned, P4_16 or P416 is the 2016 language specification that came after P414, if you check the second spec sentence: This document provides a precise definition of the P416 language, which is the 2016 revision of the P4 language (...). The main changes are well described by the latest P416 specification, see:
Compared to P414, the earlier version of the language, P416 makes a number of significant, backwards-incompatible changes to the syntax and semantics of the language. (…) a large number of language features have been eliminated from the language and moved into libraries including counters, checksum units, meters, etc.
Hence, the language has been transformed from a complex language (more than 70 keywords) into a relatively small core language (less than 40 keywords, shown in Section B) accompanied by a library of fundamental constructs that are needed for writing most P4.
The v1.1 version of P4 introduced a language construct called extern (…). Many constructs defined in the v1.1 language specification will thus be transformed into such library elements (including constructs that have been eliminated from the language, such as counters and meters). Some of these extern objects are expected to be standardized, and they will be in the scope of a future document describing a standard library of P4 elements. In this document we provide several examples of extern constructs. P416 also introduces and repurposes some v1.1 language constructs for describing the programmable parts of an architecture. These language constructs are: parser, state, control, and package.
One important goal of the P416 language revision is to provide a stable language definition. (…)
Please check P416 v1.2.2 specification at this link, and navigate to Section 3.2 to read more details. Although, I recommend a general review (particularly of the first informative section) just to become more familiar with all terms.
A good summary/figure is this one from the same spec I mentioned Fig3, Section 3.2):
Fig.2 P414 to P416
Now, you also asked about BMv2 and the V1Model (to be fair I have seen them written like bmv2 and v1model, not sure about the standard way to name them). Since we talked about P416 and architectures, the Section 4 of the spec gives you a very good explanation about it. In general terms, when you have a switch you need to define which parts are programmable, and make an organization of those blocks. Check the package P4 code of a switch targeted to the BMv2 Simple Switch that uses the V1Model:
V1Switch(
MyParser(),
MyVerifyChecksum(),
MyIngress(),
MyEgress(),
MyComputeChecksum(),
MyDeparser()
) main;
What is a package? From the spec, taken from an example in the document (Section 5.1):
/**
* Top-level package declaration - must be instantiated by user.
* The arguments to the package indicate blocks that
* must be instantiated by the user.
* @param <H> user-defined type of the headers processed.
*/
package VSS<H>(Parser<H> p,
Pipe<H> map,
Deparser<H> d);
Fig.3 V1Model (P4 org)
For example, if you need to let users program how packets are parsed, it makes sense to define an independent block that handles all the code that relates to packet parsing. Generally, each target (or device) will let users do more or less in the parser block, as it depends on device or target resources. For instance, you might be able to parse a particular amount of X bytes in a P4-based NIC but Z bytes in a P4-based ASIC (switch). Another example would be the support for variable size headers in a parser, which will differ from target to target. Therefore, you are able to define a parser when programming any target, it just depends on “how much” you can do on each of them. The discrepancy of capabilities applies to any programmable block (like Ingress or Egress) of the switch, not only the parser.
The relationship of BMv2 and V1Model relates to the Simple Switch term too. You can relate all concepts as this figure does:
Fig.4 Concepts
As you see, the BMv2 framework offers the resources to implement a particular target (like the Simple Switch target, also referred to as simple_switch). The Simple Switch target is not the only target you can implement because you can use the BMv2 framework to implement another switch, like the one based on the PSA architecture (psa_switch). You can find some information in the third paragraph of this Github page. When I try to relate these concepts to a physical P4 target, you can think of BMv2 as the hardware of a switch. Without memory you cannot implement a target that supports register (although plenty of functionalities rely on it). Then you need the code that “defines” the switch, like developers programmed the Simple Switch. Ideally, if you have the hardware that includes memories, you could “implement” both a target that supports registers and one that does not (switch_with_registers vs switch_without_registers). You will also need an architecture for it, because you need to define an interface, so people can program it.
Apart from the obvious relationship of BMv2, V1Model and the Simple Switch, the V1Model seems to be a transition from how switches were programmed with P414 (this is also mentioned here). You can also see a clear similarity between how PISA is visually described and how the V1Model architecture is depicted. See the figures below and compare them:
Fig. 5 PISA (Barefoot, 2013)
Fig. 6 PISA (Cascaval and Daly)
Fig. 7 V1Model (P4 org)
If anyone sees any error so far, feel free to clarify it and I will correct the post.
Cheers,
12 Likes
@ederolla Perhaps we should get you co-authoring a P4 book!
3 Likes
This is also a great idea for the Learn page on the p4.org website. I added a reference to this thread in a new section on terminology. See Learn « P4 – Language Consortium
Thanks for the idea @sarahshakeri !!
2 Likes
Hi,
@andyfingerhut I am a little overwhelmead by that sentence.
At least I hope the post helps to clarify the terms @judysnow.
Again, anything that is not precise or correct just let me know and I will modify it.
Cheers,
1 Like
Thank you all for your complete reply. It really helps.
1 Like
@ederollora Hi, I have a question. According to your description above, BMV2 now provides resources to implement the architecture of V1model, but BMV2 is actually a software switch. Can I provide real hardware to implement the architecture of V1model? If yes, can I use the P4C compiler directly? Do I need to add a new backend?
In general, if you want to compile P4 code to a hardware target device, you need a P4 compiler with support fo that particular target device. Most often such a P4 compiler is provided by the vendor of that hardware device.
Hi,
Basically, what @andyfingerhut told you is pretty much it, to be honest.
As you see, from my point of view, bmv2 can be (to some extent) compared to a hardware target. This example is pretty clear with the Netronome SmartNIC (Agilio). And, FYI, last news I got is that this target was deprecated (correct me if anyone knows better) while other similar devices like the NetFPGA or Pensando DSC should still be supported.
I remember that I started programming the Netronome SmartNIC with P4_14. They later supported the same device to be programmed in P4_16 and they supported the V1Model-like architecture. I cannot remember if they supported v1model.p4 as is with all externs. I believe that not all externs were supported but I am not sure. So, I guess, it was like a V1Model lite architecture. The controls blocks I believe were the same (Parser, VerifyChecksum, etc.).
You probably need a new backend because your target is inherently different to a software switch. Therefore, your hardware target might or not support the same architecture and externs in v1model.p4 but the backend (p4c-bm2-ss) is probably not compiling to the same target code that is supported by both a your hardware and the BMv2 Simple Switch software switch. However, I guess you could always create a hardeare device that accepted the same backend as bmv2 Simple Switch and the v1model.p4 (as is). I am not sure if this is a recommended idea, though.
Cheers,
Thanks a lot for your reply. @ederollora @andyfingerhut
Hello there,
If I understood correctly, the PISA arch does not have Egress Deparser?
Thanks
Certainly there is none explicitly in the figures labeled “PISA” shown earlier in this discussion thread.
I have not recently read any of the presentations or articles where those PISA figures appeared, but I suspect that the lack of a deparser in those figures might simply be due to the PISA figures having less detail in them.
1 Like
Thank you, Andy. I found a more detailed graph in this paper, which shows the egress deparser in the architecture figure.