Implementing new switch architecture on BMV2

[rupok-saha]

I am trying to implement new hardware architecture on bmv2. Though in some places the documentation says, bmv2 is redesigned to support new architectures I have not found any documentation on how to implement that.

Can anyone please give some concrete idea on what are the steps to implement a new architecture on bmv2. Is there any documentation?

[antoninbas]

Implementing a new architecture with bmv2 is pretty straightforward. Although there is no step-by-step documentation, there are a couple examples under the targets/ directory (https://github.com/p4lang/behavioral-model/tree/master/targets). The simple_switch target implements the v1model P4 architecture (the names are different mostly for historical reasons), while the psa_switch target implements the PSA P4 architecture.

The major difficulty when you want to support a new architecture with bmv2 is to add compiler support. The p4lang/p4c backend currently supports both v1model (simple_switch) and PSA (psa_switch), although PSA support is still a work in progress: https://github.com/p4lang/p4c/tree/master/backends/bmv2. The backend is required to produce a JSON file (https://github.com/p4lang/behavioral-model/blob/master/docs/JSON_format.md) from the input P4 code. The JSON file will be "interpreted" by your bmv2 binary (simple_switch, psa_switch or your own if you implement support for a new architecture in bmv2) and the file must match your architecture definition. For example, if your architecture expects 2 controls ("ingress" and "egress"), the JSON file must define these 2 controls. It can be pretty daunting to add support for your own architecture to the p4lang/p4c compiler backend for bmv2. If you only want to make some small changes to v1model / simple_switch, such as add your new extern type, then things are not as bad. Adding your own extern type to simple_switch can be done with as little as 20 lines of code, and very few changes (if any) to the compiler.

[drobinkent]

1. Can you give some hint for where to look at for producing json? My ultimate goal is high level synthesis of new data plane architectures. So, I want to explore if it is possible to generate those JSONs from a given architecture.
2. Is it possible to modify the components (P4 control blocks) of an architecture? Example: scheduling algorithm of simple_switch. Can I modify the scheduling algorithm behavior or add new algorithm support without handling those JSONs. Or changing the multicast behavior of simple_switch. Any hints about these kind of things?

[antoninbas]

1. The link I shared earlier (https://github.com/p4lang/p4c/tree/master/backends/bmv2) is the compiler code that is in charge of generating the JSON. The code is split into a "common" directory (doesn't depend on the architecture) and architecture-specific directories ("simple_switch" and "psa_switch").

2. It depends on what you are trying to do. If you just want to add some extra standard metadata fields that can be set in the "ingress" control and will influence packet scheduling, then you don't need to worry about the JSON or the compiler code. You can probably just edit v1model to add your new fields to the standard_metadata struct. Then you can edit the bmv2 simple_switch C++ code to read the value of these new fields after the ingress control has been applied. What you do with the read values is up to you. You can add your own traffic manager block to https://github.com/p4lang/behavioral-model/blob/master/include/bm/bm_sim/queueing.h and start using it in simple_switch. When you enqueue a packet, you can provide the required parameters based on the values read from your new standard metadata fields. Changing the multicast behavior will require you to modify the existing implementation used by simple_switch (https://github.com/p4lang/behavioral-model/blob/master/src/bm_sim/simple_pre_lag.cpp) or add your own (you'll have to worry about runtime APIs). But once more, you will not have to worry about modifying compiler code. If you need to add new top-level control blocks (in addition to "ingress" & "egress"), then you will need to change the bmv2 backend compiler code, but it should not be too difficult.

[saberrey]

hi antoninbas,
I'am new in c++, and I want to add some schedule function in simple_switch_grpc target, here are two question:
1、What tool do you use to see the BMV2 source code? I crazy in using Clion, I can't import the project correctly for maybe Clion only support Cmake project?
2、I can't find where the simple_switch read the field in standard_metadata, Would you please show me one example ?

[ArifulIslamPreence]

Hello,
I have started working on bmv2 switches and overall dataplane programming recently. I was wondering, where are the tables of the switch stored? Is it in the TCAM memory or the SRAM memory?
Thanks.

[jafingerhut]

@ArifulIslamPreence bmv2 switches are software, executed as user space processes running on Linux or macOS (or any other operating system on which you can get it to compile and run, but those two operating systems are best supported), on general purposes CPUs such as x86 family CPUs made by Intel and AMD.

When running there, the P4 tables are stored in system DRAM, with a little bit of it cached in on-chip SRAM which constitutes the L1, L2, and/or L3 caches of the general purpose CPU, just as any other data structures stored in the memory of a user space process do.

Such systems typically have no TCAM at all.