I have a query on the differences between PSA and PISA architectures as they seem to be very similar. I would like to know the exact architectures of both and their specific functions as I believe different sources state slightly different answers, especially whether deparsers are present before or after the traffic manager in PISA.
The sources which I referred to:
Hauser, F., Häberle, M., Merling, D., Lindner, S., Gurevich, V., Zeiger, F., … & Menth, M. (2023). A survey on data plane programming with p4: Fundamentals, advances, and applied research.Journal of Network and Computer Applications , 212 , 103561.
PISA: Figure 5, Figure 6 and PSA: Figure 17 in the above mentioned paper.
PSA was developed and published later than PISA, and had as one of its goals to be precise, and include most or all of the details visible to a P4 developer that you would want in order to answer questions like “what does multicast replication do, and what packets show up in egress as a result?” and “what does cloning/mirroring do, and what packets show up in egress as a result, with all of its headers and contents, down to the last bit?”
If I recall correctly (I haven’t re-read the source you mention by Hauser et al recently), PISA, by contrast, is described at a higher level, with fewer details, and is not sufficiently detailed to answer those kinds of questions. This is not a criticism of PISA – it was written with a different purpose in mind. Those details would have been a distraction from the purpose of the paper.
TNA was initially developed as a proprietary architecture by Barefoot and later Intel (after acquiring Barefoot), with its details very well fleshed out, but only given to people who had signed an NDA (Non-Disclosure Agreement), and not published in more detail until 2021, here: Open-Tofino/PUBLIC_Tofino-Native-Arch.pdf at master · barefootnetworks/Open-Tofino · GitHub
The Tofino ASICs always had a hardware deparser before the traffic manager, but the P4_14 language plus architecture did its best to hide its existence from the P4 developer, with the P4_14 compiler for Tofino configuring the ingress deparser hardware so that the P4 developer often would not need to know of its existence.
The short and quick answer to your question is that PSA is a P4_16 architecture, while PISA is not.
Let me elaborate on this a little further.
The word architecture has a lot of different meanings and connotations, which might be confusing, indeed. Therefore, P4_16 specification uses two qualified (and, therefore, more precise) terms:
In my classes I prefer to use the term P4_16 architecture to make it even more specific, but all these three terms can be used interchangeably.
The specification clearly states that:
It then goes on describing the details (e.g. what extern objects are) and the specific P4_16 constructs P4_16 that can be used to formally describe those interfaces.
The P4_16 language spec includes a sample P4_16 architecture, called “Very Simple Switch Architecture” to illustrate the necessary points.
PSA, PNA, v1model, TNA, T2NA and a number of others are all P4_16 architectures, with the formally defined interfaces, coded in P4_16 language. There are even targets (at least I am aware of one) that allow the users to define their own custom P4_16 architectures!
On the other hand, the term PISA was created long before P4_16 was even defined and represents an earlier attempt to describe the basic principles behind data plane programmability, which include the following main concepts:
The concept of pipeline processing
The concept of packet headers (including the concept of header validity)
The concept of packet metadata
The concept of a programmable header and metadata bus, that carries headers and metadata between the pipeline stages
The concept of a programmable parser that converts the received data stream into its parsed representation (a set of headers)
The concept of match-action tables and programmable match-action pipeline, where headers and metadata can be manipulated
The concept of a programmable deparser that emits the headers in a certain order and prepends them to the payload
In other words, PISA is a lot less specific and does not describe any specific target per se.
If we use our regular computers as analogy, PISA will be analogous to “von Neumann architecture” that describes the basic principles of building a computer with the program stored in the same memory and indistinguishable from the data or the “Harvard architecture” (where the program and data memories are separate).
In fact, there are other ways to perform high-speed packet processing besides what PISA describes. For example, there are that targets employ a programmable packet header editor instead of a deparser. In those targets, packet headers cannot be modified in the match-action pipeline; instead during the packet processing those targets generate a set (or a sequence) of special instructions for the editor that will perform the required header transformations. Other targets do separate match and action (that are tied together in PISA). While PISA implicitly allows execution of multiple match-action tables in parallel, other architectures explicitly describe multiple parallel matches, often followed by a “resolution” and then by an action (actions).
Expressing the abovementioned approaches is possible in P4_16 even today, but is not as “natural” compared to expressing the processing performed by a “pure” PISA pipeline; typically it requires the programmer to use a specific coding discipline/style. As the language develops futher, new mechanisms might be added to it ti support other processing architectures more naturally.