[P4-dev] Question: How the behavioral model is born?

Wu, Xiaoban Xiaoban_Wu at student.uml.edu
Fri Jun 24 16:44:05 EDT 2016


Dear Antonin,


Thanks so much for your detailed explanations. Now I have a much more clear vision of the behavioral models.


I just tried the command "p4c-behavioral", it gave me a lot of C files, and I can somehow feel the connection between the .p4 file and the .c files by checking the names of some variables.


Please forgive my curiosity, I have not taken any courses about compiler, but now I am very interested in how to convert the P4 files into C files. Could you please give me some advises on this? Like, which part of the source codes of the p4c-behavioral could give me a good start? I think I will spend some time on digging into the source codes.


Thank you very much for your help.


All the best,

Xiaoban

________________________________
From: Antonin Bas <antonin at barefootnetworks.com>
Sent: Friday, June 24, 2016 2:19:34 PM
To: Wu, Xiaoban
Cc: p4-dev at lists.p4.org
Subject: Re: Question: How the behavioral model is born?

Hi Xiaoban,

Welcome to the P4 community.
The current behavioral-model is actually the second switch model to be open-sourced on p4lang (hence the name "bmv2"). The first version (p4c-behavioral: https://github.com/p4lang/p4c-behavioral), which is being deprecated, worked in a totally different way. p4c-behavioral was a P4 compiler backend, which would generate C code for each P4 program (much like C code can be compiled to assembly by C compilers). This C code would then be compiled to an executable using gcc. So for each P4 program, we would have a new executable. There were some advantages to this approach but in the end we decided to adopt a different paradigm and we started working on bmv2, for the reasons mentioned in the bmv2 README (https://github.com/p4lang/behavioral-model#why-did-we-need-bmv2-). bmv2 is a "static" model, i.e. we have a single executable which can load any P4 program and adjust its forwarding behavior accordingly. In a sense, bmv2 is more of a "P4 interpreter".

The bmv2 workflow is quite simple really, which is why it is very convenient for people wishing to experiment with P4. The P4 program is first compiled to a JSON representation by p4c-bm (https://github.com/p4lang/p4c-bm). This JSON is then loaded into bmv2 and data structures are initialized to achieve the desired switching behavior. I am attaching the slides for the bmv2 talk I gave at the last P4 workshop. The P4 -> JSON compilation is really straightforward and the p4c-bm codebase is actually very small.

Note that P4 has the ambition of being used to program the dataplane of many different networking targets. All these targets can have different architectures (how many match-action pipelines? is there a multicast engine? how do the checksum units work?). This is important when designing a P4 behavioral model. Do you want to use a specific architecture or do you want to try to be as generic as possible? The strength of bmv2 is that it is target-independent. Therefore bmv2 is actually a C++ library which can be used to implement many P4-programmable targets. The behavioral-model repository comes with 3 targets (https://github.com/p4lang/behavioral-model/tree/master/targets). The most important one by far is the simple_switch target. It is the most widely-used and tries to implement the abstract switch model described in the original P4 spec. The other two targets (simple_router, l2_switch) are just meant as examples; they both implement much fewer features than simple_switch (e.g. simple_router has a single match-action pipeline). Each target implementation is meant to be linked to the bmv2 library to obtain one executable. This executable can then run all P4 programs compatible with the target's architecture.

I am pretty certain that other P4 software switches will appear in the months / years to come. I also assume that most will be based on the p4c-behavioral "design" (i.e. C code generated from P4, and not a static model like bmv2). The P4-OVS work is one such example.
It is actually pretty trivial to write a simple behavioral model which supports only a subset of P4 features (e.g. no variable-length fields, no stateful objects, only exact-match tables...), so if it's something you are interested in, I encourage you to write your own. p4c-bm (https://github.com/p4lang/p4c-bm/tree/master/p4c_bm) is a good example of a P4 compiler backend, built on top of the open-sourced P4 HLIR. You can take inspiration from it to generate your own behavioral-model code.

Best,

Antonin

On Thu, Jun 23, 2016 at 7:52 PM, Wu, Xiaoban <Xiaoban_Wu at student.uml.edu<mailto:Xiaoban_Wu at student.uml.edu>> wrote:

Dear Antonin,


I am a beginner to P4, instead of figuring out how to use the behavior model, I am more interested in how to create a behavioral model by myself. Basically, I mean I want to be a potential developer of P4 if I can, though I know I have a long road to go.


I know one possible way to figure this out is by checking every configure.ac<http://configure.ac> files, but since I am newbie to autoconf, automake and libtool, it probably will cost me a lot of time before I can see the picture. Hence I need you to give me some direct points.


For example, for the behavioral model "copy_to_cpu", how can the "copy_to_cpu.p4" be compiled and linked with the necessary libraries, so that finally we could have an executable behavioral model? And in general, how are the .p4 files compiled? Some detailed explanations will be great to me.


Look forward to your reply and thank you very much for your help.


All the best,

Xiaoban



--
Antonin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-dev_lists.p4.org/attachments/20160624/f978fd3c/attachment-0002.html>


More information about the P4-dev mailing list