Evaluation of Project 1: Modernizing the P4 Software Switch BMv2

[Dscano]

I’m opening this issue to further discuss the project proposal Project 1: Modernizing the P4 Software Switch BMv2, proposed for P4 GSoC 2026.
@qobilidop @fruffy @matthewtlam

[fruffy]

To summarize, we need to update the text in the project description. The proposed changes are quite aggressive and incompatible with common usage of BMv2. As is, I can't permit most of them. In general we should focus on the "modernization" aspect, less on the Google-style aspect.

Specific points:

Add support for Bazel 8.5.0 to BMv2's simple_switch_grpc. An example P4 repository that uses Bazel is P4Runtime.

This is good, but we have to make sure CMake and Bazel support is equivalent. Before doing this we also should deprecate or remove the autotools we are using.

Absl Integration

We should not needlessly introduce dependencies. We first need to make sure we replace the boost dependencies in the source code library before we add another utility library. absl should also only be used in the simple_switch_grpc segments of the code base.

Flatten the directory structure

We have to take a look what this actually means. Part of the design of BMv2 is to be a framework that can support a variety of architectures. The fact that includes are kept separate from source files is a convention common to many other C++ projects.

Converting textual logs that manually track the packet through the pipeline into a structured and programmatic form (e.g. .proto)

A structured representation is good, but it is not advisable to force protobuf on users.

[qobilidop]

Acknowledged. @fruffy Thanks for your honest feedback! I'll let @matthewtlam know and respond to your concerns.

Also ping @smolkaj @jonathan-dilorenzo @kheradmand in case you have any thoughts. FYI, we are discussing @matthewtlam's GSoC project proposal here:

gsoc/2026/ideas_list.md

Lines 80 to 124 in 976d7a3

	### <a name='project-1'></a> Project 1: Modernizing the P4 Software Switch BMv2 [⤴️](#index)
	**Basic info**
	![diffi-medium] ![size-m]
	- Potential mentors
	- Primary: Matthew Lam
	- Support: Bili Dong
	- Skills
	- Required: Git, C++
	- Preferred: Bazel, P4
	- Discussion thread: Github Issue Tracker, Zulip
	**Alternative qualification task**
	Presently, BMv2 can only be built with CMake. The goal is to modernize BMv2 and get it to build using Bazel 8.5.0 and deploy a Github workflow runs the unit tests for [simple_switch_grpc](https://github.com/p4lang/behavioral-model/tree/main/targets/simple_switch_grpc).
	1. Add support for [Bazel 8.5.0](https://bazel.build/versions/8.5.0/run/build) to BMv2's simple_switch_grpc. An example P4 repository that uses Bazel is [P4Runtime](https://github.com/p4lang/p4runtime).
	2. Create a Github workflow that caches, builds, and runs the unit tests. An example P4 repository that has a Github workflow set up is [P4C](https://github.com/p4lang/p4c/blob/7d367760701056cfa4fe0321f62914c0e79a6214/.github/workflows/ci-bazel.yml).
	Create a PR under https://github.com/p4lang/behavioral-model.
	**Project description**
	BMv2 is a P4-based packet processor that has not been well maintained over the years due to lack of accessibility, slow builds/tests, lack of readability and complexity. One factor contributing towards the lack of accessibility is the difficulty of setting up the project prior to development.
	There are many different enhancements to the repository that can be made including:
	* Extending support for BMv2 to build using Bazel
	* Refactoring BMv2 to use Google style guide (https://google.github.io/styleguide/cppguide.html)
	* Absl Integration
	* Discourage exceptions (use status-based error propagation)
	* Use smart pointer over manual memory
	* Explicit constructors
	* Flatten the directory structure
	* Deprecating unused features
	* Converting textual logs that manually track the packet through the pipeline into a structured and programmatic form (e.g. .proto)
	* Can read more information [here](https://github.com/p4lang/gsoc/blob/main/2025/ideas_list.md#project-2).
	**Expected outcomes**
	* Building BMv2 using Bazel will make it easier to set up, manage dependencies, and faster builds and tests
	* Improving readability of BMv2 and reducing complexity of the repository
	* Structured packet trace outputs supported in BMv2.
	**Resources**
	* BMv2: https://github.com/p4lang/behavioral-model

[matthewtlam]

As discussed with @qobilidop
@fruffy To address comments from #87 (comment)

We wish to extend support for Bazel for BMv2 so we can have multiple builds systems.

• We will also try to improve the current Makefile system to our best effort
• We take ownership over Bazel changes to this repository (we will review PRs related to bazel)

For both Absl integration and the reorganizing directory structure, we decided to not add this to the proposal

• Original plan was to replace some boost libraries with absl to improve performance (e.x. replacing std::hash_map with absl::flat_hash_map). Perhaps, this can be discussed separately

With respect to forcing protobuf

• The goal is to use a structured representation for the packet traces
• The actual solution and design can be discussed (for example, a JSON format or protobuf)

The proposal will be updated accordingly.

cc: @smolkaj, @jonathan-dilorenzo, @kheradmand

[fruffy]

As discussed with @qobilidop @fruffy To address comments from #87 (comment)

We wish to extend support for Bazel for BMv2 so we can have multiple builds systems.

* We will also try to improve the current Makefile system to our best effort

* We take ownership over Bazel changes to this repository (we will review PRs related to bazel)

For both Absl integration and the reorganizing directory structure, we decided to not add this to the proposal

* Original plan was to replace some boost libraries with absl to improve performance (e.x. replacing std::hash_map with absl::flat_hash_map). Perhaps, this can be discussed separately

With respect to forcing protobuf

* The goal is to use a structured representation for the packet traces

* The actual solution and design can be discussed (for example, a JSON format or protobuf)

The proposal will be updated accordingly.

cc: @smolkaj, @jonathan-dilorenzo, @kheradmand

These sound all good to me, thanks! Note that with respect to CMake the requirement is to just make sure things compile and also support the new features you might add.

We also do not necessarily have to use absl:flat_hash_map. There might also be single-header alternatives such as ankerl::unordered_dense or phmap::flat_hash_map. The nice part is that we can swap those out easily at any point.

[jafingerhut]

Regarding a more data-oriented trace output format, I don't have a strong opinion on Protobuf vs. JSON vs. possibly other data formats.

If something like that is done, I am hoping that the proposal would be that either at compile time, or perhaps via command line options, one could enable/disable these things:

• current text log output
• the new data-oriented trace output

If that were done, then when people run it, they could choose between neither, one, or both of the options for trace data, similar to how today they can choose between the text log output being on or off.

[smolkaj]

Note the protobuf supports serialization/deserialization to/from JSON, so no need to chose on or the other — we can have both with no extra cost.