Closed CommitThis closed 4 years ago
Without getting into too many details, the implementation of the multicast engine for bmv2 would have been influenced by the multicast design of the Barefoot Tofino ASIC. I actually do not remember what purpose serves the L2 entries as it seems there is a direct mapping between L1 and L2 entries.
I would recommend switching over to P4Runtime rather than keep using the Thrift bindings. The Thrift API is not portable (specific to bmv2) and should be considered in "maintenance mode". The P4Runtime multicast API may also make more sense to you. Unfortunately some features (register reads / writes) are still missing from the P4Runtime bmv2 implementation.
Thanks @antoninbas, no need for detail in that case.
Sorry @antoninbas, I had another question, if using the P4runtime, are you still able to respond to digest messages?
I am not sure what "respond to digest messages" mean, but P4Runtime supports streaming digets messages from the switch to the client, and provides the ability for the client to "ack" these messages to the switch. The acknowledgement mechanism is used to avoid sending duplicates to the client.
This is implemented as part of the P4Runtime implementation for bmv2.
I meant receive digest messages and take some action upon receipt thereof; to that extent I believe you have answered my question, thankyou!
This is probably a bit in the weeds somewhat but I've been using the Thrift API to control the Behavioral Model /
simple_switch
programmatically, rather than use the runtime CLI. I had a question regarding the structures when using the multicast group commands.After creating some nodes & groups and associating them using the
pre_lag
binding, the group information has a structure like this:I was wondering why the L1 and L2 handles are separate (or why they are called as they are), and why the L1 handle didn't include the ports as well as the
rid
.Thanks in advance.