[2025 Project 2] Why is the BMv2 event logger capability not enough for packet trace?

[qobilidop]

Context: https://github.com/p4lang/gsoc/blob/main/2025/ideas_list.md Project 2

As @antoninbas pointed out in the email:

Note that project 2 sounds quite similar to an existing capability of bmv2: https://github.com/p4lang/behavioral-model/blob/main/include/bm/bm_sim/event_logger.h. Messages can be generated for "key" events and "streamed" over multiple possible transports. So I hope this capability can be studied first and then refined instead of building a brand new alternative.

@matthewtlam @jonathan-dilorenzo Any thoughts on this?

[matthewtlam]

@antoninbas My understanding to this project would be creating a class to parse and organize the event logger's messages as a packet trace class. I believe the goal is to not have to manually go through all the BMv2 logs as a user

@jonathan-dilorenzo correct me if I am wrong

[antoninbas]

@matthewtlam there are console text logs and then there are structured event logs. The project idea is only referring to the former, while I referred to the latter in my comment above. Unlike the "console" logs, event logs are only generated for key events such as table lookups. In my mind, the project should be about improving this existing mechanism, e.g. by adding the ability to generate these event messages in Protobuf format.

[jonathan-dilorenzo]

@kheradmandG and @angelazhang8 would be the experts here as they parsed the logs to construct Protobuf packet traces internally. I'd have to see an example of the structured event logs to know if that's what they're parsing or if it's the console logs.

If we use the console logs, then it's likely just because we didn't know about the structured event logs and should use them instead. Agreed that a natural direction for the project would be to update the structured event log to also produce (or maybe instead produce, with some parameter controlling it) a Protobuf representation.