Why are there reserved multicast group IDs?

[jonathan-dilorenzo]

We just ran into the "Group id value is too high" error in BMv2 while running some of our testing and I was confused since we were still within the 16-bits that V1Model advertises.

I think what's happening is that it's splitting half the group space for clone sessions and half of them for multicast groups? But I wanted to confirm before I make any changes related to the reserved groups (or our own internal code).

PI/proto/frontend/src/pre_mc_mgr.h

Lines 79 to 82 in 5689c91

	// user-defined multicast group ids must be in the range
	// ]0,first_reserved_group[; ideally this should be configurable based on the
	// target.
	static constexpr GroupId first_reserved_group_id() { return 1 << 15; }

[jonathan-dilorenzo]

@antoninbas probably knows the details if you see this, but I suspect I can just shrink it internally ;).

[antoninbas]

When a cloning session is created with multiple ports, a multicast group is implicitly created by bmv2 for implementation purposes. It uses a multicast group ID from that reserved range, so it doesn't let you use that range for your own multicast groups to avoid conflicts.

I guess ideally bmv2 would switch to using 32-bit multicast group IDs internally, which would let you use the full 16-bit range for P4Runtime multicast groups.

[jonathan-dilorenzo]

Makes sense! Thanks Antonin!

I'll look at increasing the internal size then (though at somewhat low priority, since we separately added the obvious workaround of "use smaller group IDs" ;)).

[jafingerhut]

It appears that with the current implementation, simply increasing the constant value returned by first_reserved_group_id() toa value like (65536 - 256) would enable you to use that many multicast group ids, and up to 256 clone session ids with multicast replication.

That said, if you think more than 64K multicast group ids would be useful long term, Antonin's suggestion has longer applicability.

[jonathan-dilorenzo]

True. I'm just worried about breaking other people's uses of the server. While if I make it 32 bits and reserve 31 bits each probably it'll "just work" ;)