Where is the original p4 source code for recirc.json

[jinxie0731]

Hi,

I can find a recirc. json file in the folder of targets/simple.switch/tests/testdata/. I guess the corresponding p4 source code file should be recirc.p4 which is located in the same folder, but when I tried to recompile this file with command " p4c --target bmv2 --arch v1model ./recirc.p4", I got the following error:

./recirc.p4(16):syntax error, unexpected {, expecting ( header_type intrinsic_metadata_t { ^ [--Werror=overlimit] error: 1 errors encountered, aborting compilation

So how can I recompile and get recirc. json, please help with this, thank you very much!

[jafingerhut]

This test program is old enough that it is written in an older version of the P4 language called P4_14, whereas the current version is P4_16. They are quite different languages syntax-wise, i.e. neither is a subset of the other.

Try adding the command line options --std p4-14 to the command line you have tried, mentioned in the issue.

Also note that if you do this, it might be that the file recirc.json produced may be different than the one checked into the behavioral-model repo, because the p4c source code has been enhanced noticeably since 2019 when the checked-in recirc.json was created. Hopefully they should be functionally equivalent to each other, but depending on how different they are textually, that might not be easy to determine quickly.

[jinxie0731]

Yes, that makes sense, the last modification for recirc.p4 seems like "Thu Feb 14 15:43:17 2019 -080". I failed to build it even with p4-14 option, here is the log:

p4c --target bmv2 --arch v1model --std p4-14 ./recirc.p4 ./recirc.p4(20): [--Werror=not-found] error: mcast_hash: no such field in standard_metadata mcast_hash : 16; ^^^^^^^^^^ ./recirc.p4(21): [--Werror=not-found] error: lf_field_list: no such field in standard_metadata lf_field_list: 32; ^^^^^^^^^^^^^ ./recirc.p4(23): [--Werror=not-found] error: resubmit_flag: no such field in standard_metadata resubmit_flag : 16; ^^^^^^^^^^^^^ ./recirc.p4(24): [--Werror=not-found] error: recirculate_flag: no such field in standard_metadata recirculate_flag : 16; ^^^^^^^^^^^^^^^^ [--Werror=overlimit] error: 4 errors encountered, aborting compilation

[jafingerhut]

I tried commenting out those 4 metadata fields in recirc.p4, and the compilation produced a recirc.json file that was very similar, but not identical, to the one that is checked in.

Realize that the recirc.p4 was compiled to recirc.json with a version of p4c from 2019, so if you were able to go back to a 2019 version of p4c, build it from source code, and use that to compile recirc.p4, it would probably produce the same recirc.json file that is checked in, but I would not recommend trying to build that older version of p4c from source code, unless you enjoy solving build command sequence puzzles with older versions of Ubuntu Linux.

Out of curiosity, what is your reason for wanting to build recirc.p4 from source code?

[jinxie0731]

Yes, actually I am trying to figure out how BMv2 converts descriptions in JSON files into corresponding resources (e.g. PHV), and then further statistics will be conducted on the utilization and waste of resources to see if fine tuning can be performed.

I want to start with a simple P4 source file, while the JSON file compiled from the exercises in tutorial repo seems to be much more complicated. Currently, recirc.P4 is what I want, so ...

Do I have a better choice? Thank you in advance.

[jafingerhut]

BMv2 has no reason to convert its input into PHV resources, as there are no PHV resources in BMv2. At least, not Tofino-like PHV resources. There is a software data structure that holds all header fields in memory. I am not aware of anything in BMv2 that tries to optimize this memory use, since memory is plentiful in a general purpose CPU, and BMv2 has few performance optimizations.

If you want the simplest JSON file you can get, I would recommend a P4 program that parses only an Ethernet header, and no other headers, and does one table lookup that does an exact match on one of those header fields, with a single action that sets the output port, in ingress. Egress is empty.

[jinxie0731]

@jafingerhut , Thank you very much for your great suggestion, I'm clear now and I'm going to close this topic.

[jinxie0731]

@jafingerhut

You raised another topic that I am curious about. Since BMv2 has already parsed the JSON input file into data structures including parser, deparser and pipeline etc., I'm thinking it is a good start from these data structures to ultimately output machine codes which can be executed by specific hardware (e.g. Tofino as you mentioned previously). It seems that BMv2 is a pure P4 software simulator, which is very different from the hardware. Raise Hardware that follows the v1model architecture as example , their parsers, match action units, and parsers are actually driven by instructions (e.g. VLIW instructions), In these instructions, it may be necessary to fill in resource information, for example, the extracting offset of phv that a hdr field is going to be extracted to.

[jafingerhut]

@jafingerhut

You raised another topic that I am curious about. Since BMv2 has already parsed the JSON input file into data structures including parser, deparser and pipeline etc., I'm thinking it is a good start from these data structures to ultimately output machine codes which can be executed by specific hardware (e.g. Tofino as you mentioned previously). It seems that BMv2 is a pure P4 software simulator, which is very different from the hardware. Raise Hardware that follows the v1model architecture as example , their parsers, match action units, and parsers are actually driven by instructions (e.g. VLIW instructions), In these instructions, it may be necessary to fill in resource information, for example, the extracting offset of phv that a hdr field is going to be extracted to.

It is definitely true that the BMv2-JSON file read by BMv2 is not directly usable in any hardware target that I am aware of, nor was it intended to be.

I could imagine that perhaps some designers responsible for a hardware target might choose to start from the BMv2-JSON file and transform that into something suitable to configure the hardware, but I am not aware of anyone that has chosen to do so. If they have an actual hardware target, they typically have customers and a budget large enough to hire a full time compiler engineer, or several, and they choose to create a new back end for the p4c compiler that starts with the in-memory IR (intermediate representation) data structures, and does calculations and optimizations on those to create the hardware confgiuration for that target.