Detail questions on 2025 project 3: BMv2 with all possible output packets

[jafingerhut]

https://github.com/p4lang/gsoc/blob/main/2025/ideas_list.md#-project-3-bmv2-with-all-possible-output-packets-%EF%B8%8F

So I can see the desire and use for a feature like this. I was curious about how general you were hoping this would be.

For example, what if a P4 program has 3 action selectors in series, where each decision is based on a different hash function than the other ones, so they are effectively "independent"? If there were M choices for the first, N choices for the second, and P choices for the third, and each such choice resulted in exactly one output packet, would you expect to get M*N*P output sets from such a program? It is of course possible there would be less than that, e.g. some choices of the first action selector might cause the 2nd and 3rd action selector to be used, while other choices of the first action select might cause the 2nd and/or 3rd action selector to be skipped, e.g. due to if conditions containing variables that are modified by the 1st action selector action.

Besides output packets, there can also be counter, meter, and register side effects while processing a packet, and these could be either the same for different action selector choices, or in general they can be different depending upon the action selector choice.

Are you thinking that you want the P4 register initial state to be the same for each packet output set, i.e. first calculate output packet set 1, then reset all registers back to the way before output packet set 1 was determined, then calculate output packet set 2, etc.?

Or should output packet set 2's contents be determined based on the register values that are present after output packet set 1 is determined? In general, the register side effects, and the output of the packets, could depend very significantly on the order that the action selector choices are chosen while determining the output packet sets.

One could also imagine limiting the project scope so that no P4 register arrays are supported in a program using this new feature, to simplify the implementation.

[qobilidop]

Ping @jonathan-dilorenzo who proposes this project.

[jonathan-dilorenzo]

Good questions. I was indeed precisely hoping that they would be independent, resulting in M*N*P outputs (barring duplicates or situations like what you describe). I suppose in an ideal solution you could even say that certain action selectors were dependent on each other, but for that, you'd ideally fully model the hash function instead resulting in just 1 possible output for that selector.

I don't quite recall to what extent BMv2 models various state atm (like counters etc), but yes, it gets more complex the more you take that into account. I think you'd definitely want to start from the initial state with every packet possibility, but then ideally you'd need to have all possible new states as well as all possible outputs (connected correctly). But since it's not pure at that point, the user would need some way to pick the state to collapse to after each packet (or perhaps the mode can also say "ignore this and pick the first state").

Agreed that an initial implementation should ignore state entirely, ideally with default checks making sure that this still resulted in correct functionality as per your suggestion at the end.

[jafingerhut]

BMv2 today implements counter, meter, and register state fully, for P4 programs that use them.

Obviously if a P4 program had none of those things, there would be no state to "reset" between calculation of different packet output sets.