Add ActionSelectionMode and SizeSemantics to ActionProfileActionSet in P4Runtime.

[angelazhang8]

Motivation

Our switches currently support per-group hash modes and resource usage modes. We are currently not leveraging this capability. This P4 API change allows for more granular control of the WCMP implementation in GPINS.

Summary of changes

Add BucketSelectionMode (with modes DEFAULT_MODE_DETERMINED_BY_ACTION_SELECTOR, HASH, and RANDOM) and SizeSemantics (with modes DEFAULT_SIZE_DETERMINED_BY_ACTION_SELECTOR, SUM_OF_WEIGHTS, and SUM_OF_MEMBERS) to ActionProfileActionSet in p4runtime.proto.

[chrispsommers]

@angelazhang8 Thanks for your submission. Could you please add a description, including summary of changes and a motivation for this? Will you be able to present this to us in the WG meeting on Friday 8/8/25?

[matthewtlam]

Please update the docs/v1/P4Runtime-Spec.adoc accordingly with the restrictions, expected behavior, etc. You can run the lint tool using ./tools/asciidoclint.py to format the spec.

Also please use the script ./codegen/update.sh to update the GoLang, Python and Rust versions as specified https://github.com/p4lang/p4runtime?tab=readme-ov-file#detailed-processes

[angelazhang8]

@angelazhang8 Thanks for your submission. Could you please add a description, including summary of changes and a motivation for this? Will you be able to present this to us in the WG meeting on Friday 8/8/25?

Done. Yes, I am planning to present this in the WG meeting tomorrow.

[angelazhang8]

@jafingerhut Can you also PTAL? Thanks!

[jonathan-dilorenzo]

Will defer to @jafingerhut and @chrispsommers on if we wwant to add for 1.5 or 1.4.2 (or whatever). This should be a non-breaking change as designed.

[jonathan-dilorenzo]

@jafingerhut and @chrispsommers, we internally don't currently have a use-case, but we would be totally amenable to adding these same knobs to ActionProfileGroups for feature parity (since otherwise the selector seems to become more expressive which is a bit odd imo).

[jonathan-dilorenzo]

In SAI, there's a per-group hash algorithm attribute, which one can set to SAI_HASH_ALGORITHM_RANDOM to get the random behavior specified here. I'm not aware of switches that allow you to otherwise set arbitrary hash algorithms per group (though they may exist), but we use NONE to pick the default per-switch hash algorithm.

Still looking at the SUM_OF_WEIGHTS vs SUM_OF_MEMBERS, but I suspect it comes from these SAI group types. Perhaps the as-of-yet-undefined WCMP type is the one we use for SUM_OF_MEMBERS and have not yet upstreamed.

[jonathan-dilorenzo]

@jafingerhut, @verios-google, @matthewtlam, and @chrispsommers, can we lock in the current proto (possibly with some additional comments)? Or any concerns with the naming?

Edit: So, I just realized that we need the proto submitted here before we can move forward internally too (since we have external repositories depending on this). We can try to make quick progress on the prose if you'd like? Or maybe we can even do something dumb and submit the proto without prose (or with imperfect prose) saying that the prose is coming by next meeting? If so, we would commit to making all the necessary improvements.

[jafingerhut]

@jafingerhut, @verios-google, @matthewtlam, and @chrispsommers, can we lock in the current proto (possibly with some additional comments)? Or any concerns with the naming?

Edit: So, I just realized that we need the proto submitted here before we can move forward internally too (since we have external repositories depending on this). We can try to make quick progress on the prose if you'd like? Or maybe we can even do something dumb and submit the proto without prose (or with imperfect prose) saying that the prose is coming by next meeting? If so, we would commit to making all the necessary improvements.

On the .proto file changes alone, I have no objections to the current names. The most important thing is that they are explained clearly in some section of the specification before the next spec release, preferably with exactly what names they correspond to in the SAI APIs, with links to relevant SAI documentation. I think it is fine for those details NOT to be in the .proto file, but only in the P4Runtime specification document.

[matthewtlam]

Besides my small NITs, everything LGTM. Approving early, but should fix the issue with one of the BUILDs failing though

[jonathan-dilorenzo]

@jafingerhut, for the SUM_OF_MEMBERS that corresponds to an as-of-yet not upstreamed (but in the process of being upstreamed) SAI attribute (SAI_NEXT_HOP_GROUP_ATTR_NATIVE_WCMP). So I'm not sure we can say anything useful there yet.

[jonathan-dilorenzo]

@jafingerhut and @angelazhang8, wdyt about separating out the proto PR from the spec PR so that we can keep leaving comments on the spec part without blocking on it?

[chrispsommers]

I am OK with approving the .proto now and even leaving the spec a little bit WIP, but let's create an issue to update the spec in a timely manner. We can bump it all to 1.5.1 then? I believe in progress.

[jafingerhut]

SInce some of the comments here are about the spec, not the .proto file, perhaps leave this issue as it is now, and create a new one for the .proto file change by itself that can proceed faster?

[jonathan-dilorenzo]

This is great! Thanks Angela! Mostly small comments, so marking approved.

[matthewtlam]

@angelazhang8 Please add a comment about the new fields added to the ActionProfile message.

EDIT: my bad, it seems the website is not updated with the latest changes from the spec as I see you've already updated it

[chrispsommers]

@angelazhang8 It seems like you need to fix the signoff problem, there is a procedure to amend the commits, follow the DCO link

[jonathan-dilorenzo]

LGTM and ready to merge from my perspective. @chrispsommers and @jafingerhut.