[P4-discuss] Question about PI and PD
vladimir.gurevich at barefootnetworks.com
Sat May 19 14:31:46 EDT 2018
On Fri, May 18, 2018 at 6:34 AM, Douglas Litke <Douglas_Litke at jabil.com>
> I am confused about what is PI and what is PD
> I know PI = Protocol Independent. But what does it do? How is it related
> to P4Runtime (if it is)?
> I understand PD = Protocol Dependent. I assume this is the code that runs
> on the switch, and controls the ASIC. Correct?
The correct way to dis-abbreviate PD and PI is "Program-Dependent" and
"Program-Independent", meaning that in the former case the API changes
every time you change your P4 program, while in the latter it stays the
same. Program dependence (or independence) is a very important property of
an API, but not really an API itself. :)
Historically, however, people would call a particular protocol-dependent
API that was originally designed for P4 as "the" PD API, i.e. the very
important property of the API design became its name and it is reflected in
its function prefix (p4_pd). However, one can easily define many other
program-dependent (ie. PD) APIs, using different naming and calling
conventions to suit someone's tastes/needs.
P4Runtime is a protocol-independent API that is currently being
standardized by the API working group. I think that initially it was
thought of as "the" PI API and that is reflected in the repo name. Again,
it is not difficult to imagine other program-independent APIs being
designed, although the hope is that if everyone agrees on P4Runtime to be
the standard API and it will have all the features that people need, then
everyone's life will become easier :)
The point is that the letter "P" has nothing to do with the word "protocol"
and, especially with the particular protocol used to perform RPC. Both APIs
(or API styles) can be easily RPC-ed using a variety of available RPC
frameworks. Historically, people used Thrift to RPC the above-mentioned PD
API, but they could easily use gRPC instead. Similarly, P4Runtime group
made a decision to use gRPC (not only as the RPC mechanism, but even as the
IDL), but nothing prevents you from using Thrift or some other RPC
framework with P4Runtime if you wish to do so.
Is there a defined interface between the P4Runtime code that decodes the
> messages from the Controller, and the code generated by the P4C that
> controls the ASIC? Or is it all one output?
P4Info is supposed to represent just the high-level aspects of the code
that can be derived from the program itself. It is enough to decode the
messages from the controller. The code that controls the ASIC need to have
all the information in P4Info, plus the backend-specific information. For
example, for a given table, the high-level information is the list of key
fields and their match types, as well as the list of actions and the
names/types of their parameters, whereas the backend specific information
will describe how this table is laid out in the memory, which resources
are being used, the low-level code the action is compiled into, etc. P4Info
can definitely be used separately. Whether or not the backend specific
portion will be including the copy of P4Info or simply referencing it is a
design decision made by the authors of the individual backend.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the P4-discuss