p4-dev@lists.p4.org

list for questions/discussion of p4 programs and tools

View all threads

Extracting header and parser semantics from P4 code (architecture independent)

RB
Rahul Bothra
Mon, Nov 16, 2020 5:18 PM

Hi,

We want to extract the header and parser information from a P4 source code
to generate packet definitions for Scapy.
We implemented this for v1model specific code by parsing the .json files
produced by the bmv2-ss backend. We are looking to extend this for other
architectures like Tofino (TNA).

We tried the following,

  • One hack is to put the header and parser parts of a TNA code into a
    v1model template and then compile with the bmv2-ss backend, but this is not
    tenable in the long run. FWIW, p4test --validate successfully runs on TNA
    specific code with additional include search path.
  • The output of p4c-graphs has a lot of parser information but misses on
    the header details.
  • The options exposed by bf-p4c and p4lang/p4c frontend don't offer
    anything that dumps the header and parser information

We want to avoid parsing the source code ourselves and still be largely
architecture-independent. Any suggestions?

Thanks

Hi, We want to extract the header and parser information from a P4 source code to generate packet definitions for Scapy. We implemented this for v1model specific code by parsing the .json files produced by the bmv2-ss backend. We are looking to extend this for other architectures like Tofino (TNA). We tried the following, * One hack is to put the header and parser parts of a TNA code into a v1model template and then compile with the bmv2-ss backend, but this is not tenable in the long run. FWIW, `p4test --validate` successfully runs on TNA specific code with additional include search path. * The output of p4c-graphs has a lot of parser information but misses on the header details. * The options exposed by bf-p4c and p4lang/p4c frontend don't offer anything that dumps the header and parser information We want to avoid parsing the source code ourselves and still be largely architecture-independent. Any suggestions? Thanks
MB
Mihai Budiu
Mon, Nov 16, 2020 7:00 PM

I don’t think you can be completely architecture-independent. Some architectures may even have multiple parsers (see the PSA, for example: https://p4.org/p4-spec/docs/PSA.html).

But really the p4c internal representation is not that complicated, the right way to do this is to leverage the open-source compiler. A difficulty is that P4 parsers can intersperse arbitrary computation with parsing (e.g., do arithmetic and use the results in select expressions). So you probably have to build a symbolic interpreter if you want to support arbitrary P4 parsers. You can probably go a long way supporting a subset of the entire P4 language. I can help you understand the compiler representation if you want to do this “the right way”. Take a look at the documents in the docs folder, in particular the compiler-design powerpoint.

Mihai

From: P4-dev p4-dev-bounces@lists.p4.org On Behalf Of Rahul Bothra
Sent: Monday, November 16, 2020 9:19 AM
To: p4-dev@lists.p4.org
Subject: [P4-dev] Extracting header and parser semantics from P4 code (architecture independent)

Hi,

We want to extract the header and parser information from a P4 source code to generate packet definitions for Scapy.
We implemented this for v1model specific code by parsing the .json files produced by the bmv2-ss backend. We are looking to extend this for other architectures like Tofino (TNA).

We tried the following,

  • One hack is to put the header and parser parts of a TNA code into a v1model template and then compile with the bmv2-ss backend, but this is not tenable in the long run. FWIW, p4test --validate successfully runs on TNA specific code with additional include search path.
  • The output of p4c-graphs has a lot of parser information but misses on the header details.
  • The options exposed by bf-p4c and p4lang/p4c frontend don't offer anything that dumps the header and parser information
    We want to avoid parsing the source code ourselves and still be largely architecture-independent. Any suggestions?

Thanks

I don’t think you can be completely architecture-independent. Some architectures may even have multiple parsers (see the PSA, for example: https://p4.org/p4-spec/docs/PSA.html). But really the p4c internal representation is not that complicated, the right way to do this is to leverage the open-source compiler. A difficulty is that P4 parsers can intersperse arbitrary computation with parsing (e.g., do arithmetic and use the results in select expressions). So you probably have to build a symbolic interpreter if you want to support arbitrary P4 parsers. You can probably go a long way supporting a subset of the entire P4 language. I can help you understand the compiler representation if you want to do this “the right way”. Take a look at the documents in the docs folder, in particular the compiler-design powerpoint. Mihai From: P4-dev <p4-dev-bounces@lists.p4.org> On Behalf Of Rahul Bothra Sent: Monday, November 16, 2020 9:19 AM To: p4-dev@lists.p4.org Subject: [P4-dev] Extracting header and parser semantics from P4 code (architecture independent) Hi, We want to extract the header and parser information from a P4 source code to generate packet definitions for Scapy. We implemented this for v1model specific code by parsing the .json files produced by the bmv2-ss backend. We are looking to extend this for other architectures like Tofino (TNA). We tried the following, * One hack is to put the header and parser parts of a TNA code into a v1model template and then compile with the bmv2-ss backend, but this is not tenable in the long run. FWIW, `p4test --validate` successfully runs on TNA specific code with additional include search path. * The output of p4c-graphs has a lot of parser information but misses on the header details. * The options exposed by bf-p4c and p4lang/p4c frontend don't offer anything that dumps the header and parser information We want to avoid parsing the source code ourselves and still be largely architecture-independent. Any suggestions? Thanks