Introduce and explain the terms "group" and "member" in the configuration of action selectors

[jafingerhut]

In a (very small) straw poll of P4Runtime API users at a recent work group meeting, it was unanimous that engineers use the terms "group" and "member" to refer to the entities that are configured in P4Runtime action selectors. I am told that SAI also uses these words to refer to these concepts. P4Runtime API is, I think, a bit unusual in using longer names with "ActionSelector" as only about half of the syllables of the name.

We can still maintain backwards compatibility, but make the spec easier to understand, if we define and use the terms "group" and "member" when explaining the behavior of the relevant P4Runtime messages. This issue proposes doing so.

I am not sure if it would help the clarity, but perhaps having a small table of P4Runtime API message/field names that closely correspond to the concept "group" or "member", and which one they correspond to, would be useful.

Also perhaps nice to justify the extra documentation by adding a reference to any SAI documentation or code that uses these terms.

[jafingerhut]

@matthewtlam @smolkaj FYI

[matthewtlam]

Thanks for opening the issue @jafingerhut. In P4Runtime, the term ActionProfileActionSet is a bit confusing. Introducing the terminology for "groups" and "members" would make things more clear to the average engineer.

Do we ever plan to have a breaking change to rename some of these fields to make things very clear? Or do we always have to makes backwards compatible (question out of curiosity not necessarily requires action)

[jafingerhut]

It really depends on how much value you place on backwards compatibility vs. making breaking changes.

Even though changing such names would not add any new functionality, technically if you adhere to the rules of semantic versioning, renaming these things should cause the P4Runtime API version number to increase its major version number, e.g. 2.0. If folks are willing to break backwards compatibility over this renaming, and bump up the major version number, and ideally also help fix anything in p4lang projects that breaks due to such renaming (probably not a lot, but a few things here and there), my arguments against a breaking change would be less forceful :-)

[jafingerhut]

It really depends on how much value you place on backwards compatibility vs. making breaking changes.

Even though changing such names would not add any new functionality, technically if you adhere to the rules of semantic versioning, renaming these things should cause the P4Runtime API version number to increase its major version number, e.g. 2.0. If folks are willing to break backwards compatibility over this renaming, and bump up the major version number, and ideally also help fix anything in p4lang projects that breaks due to such renaming (probably not a lot, but a few things here and there), my arguments against a breaking change would be less forceful :-)

Oh,and Google definitely uses these messages in their production code. Assuming you have the ability to make a test-only deployment with the names changed, give it a whirl and see if you can determine the blast radius of other things that will need to be updated.

[jafingerhut]

OK, I have re-read today these sections of the P4Runtime spec, and they already use the terms "group" and "member" very consistently throughout:

• 6.4.3. ActionProfile
• 9.2. ActionProfileMember & ActionProfileGroup
• 9.2.1. Action Profile Member Programming
• 9.2.2. Action Profile Group Programming
• 9.2.3. One Shot Action Selector Programming
• 9.2.4. Constraints on action selector programming

I have no recommendations to update anything in those sections.

Unless someone else has any specific recommendations on updates related to this issue they think would be helpful, I think it is reasonable to close this issue without any changes made to the spec.

I may have been confused a bit when jumping into the description of the one-shot message and its behavior, but if you read that after the preceding sections, I found it much easier to understand.

[matthewtlam]

I'm happy to close this. I haven't had a close read until now and I agree

[smolkaj]

Would it be useful to already introduce the colloquial names for all of these in the section titles, e.g. as ActionProfileMember (“member”), ActionProfileGroup (“group”) etc?

But what is the right colloquial term for ActionProfile and ActionSelector? Maybe „group table“ for the latter, although I think that’s slightly off

[smolkaj]

Maybe just “profile” and “selector” to stick to the pattern? And a “group table” is just a table with a “selector”. Wdyt @jafingerhut?

[jafingerhut]

Would it be useful to already introduce the colloquial names for all of these in the section titles, e.g. as ActionProfileMember (“member”), ActionProfileGroup (“group”) etc?

But what is the right colloquial term for ActionProfile and ActionSelector? Maybe „group table“ for the latter, although I think that’s slightly off

I do not know of any widely used names for action profile and action selector.

An action profile is simply a method of using indirection through an intermediate table, which you can easily replace in a P4 program with two separate tables, as described here: https://github.com/jafingerhut/p4-guide/blob/master/action-profile-and-selector/README-action-profile.md

An action selector seems to me to have been, at the time the name was some time 2014-2016, simply a generalization for the kinds of ways that ECMP was implemented in switches for decades. I say generalized because action selectors can have P4 actions that make them do things that have nothing to do with the ECMP feature. There are several variations on how they can be implemented in P4 with 3-4 tables, as detailed here: https://github.com/jafingerhut/p4-guide/blob/master/action-profile-and-selector/README-action-selector-variant-comparison.md (note that all of those implementations are variations of an action selector that selects a member via a hash function -- implementations that do stateful things like round robin or based on measured traffic load or other kinds of feedback are noticeably more involved).

[smolkaj]

Thanks @jafingerhut.

An action profile is simply a method of using indirection through an intermediate table, which you can easily replace in a P4 program with two separate tables, as described here:

Do you have any historical context on why we decided to bake it into P4 as a separate concept?
By the way, SAI and thus SAI P4 has a ton of this indirection, but we model that using separate tables rather than action selectors, just like you suggest.

[jafingerhut]

Thanks @jafingerhut.

An action profile is simply a method of using indirection through an intermediate table, which you can easily replace in a P4 program with two separate tables, as described here:

Do you have any historical context on why we decided to bake it into P4 as a separate concept? By the way, SAI and thus SAI P4 has a ton of this indirection, but we model that using separate tables rather than action selectors, just like you suggest.

I have a guess, but take it only as a guess. I defer to @vgurevich @ChrisDodd @grg @hanw for what they know on this topic.

Tofino hardware had the capability, within a single Tofino stage, to do a table lookup plus action selector in a single stage, because they knew ECMP and the corresponding L2 feature (often called one of port channel, LAG, or a few other names) would be required, and implementing that over 3 separate stages would have been too costly in the longest path dependency chain in common P4 programs. Having a special extern for an action selector was a good choice for several reasons, one of which was that without it, you would have to have the P4 compiler recognize a very specific pattern of dependent table lookups plus hash function in order for it to know when to use that hardware capability.

Once you have that, an action profile is a relatively simple but useful subset of that functionality, so why not?

[vgurevich]

@smolkaj ,

Do you have any historical context on why we decided to bake it into P4 as a separate concept? By the way, SAI and thus SAI P4 has a ton of this indirection, but we model that using separate tables rather than action selectors, just like you suggest.

This is a "trick" question that has an interesting answer.

First, it is important to establish that ActionProfile extern is not "baked" into P4. It is not a part of P4 Language specification and though it appears there, it is used just for the illustration purposes. From P4 language standpoint, ActionProfile is just a regular extern, supported on some architectures (e.g. v1model, TNA, etc., often not exactly the same way, because it is not standardized across them) and completely absent on others. Therefore, the premise of the question is not quite correct.

Second, we can not help but notice, that ActionProfle is a part of P4Runtime Specification (which is probably what you were actually referring to in the question above). Why there is a disconnect? It's a very good question, but I suspect that the answer is that at the time of writing the spec, the authors of it were not separating the core P4 language from the v1model P4 architecture. Otherwise, P4Runtime (especially P4Info parts) would look very differently (e.g. closer to the "generic table" proposal) from the very beginning. In fact, this is precisely the reason that hinders P4Runtime adoption among vendors that use different P4 architectures (starting with Barefoot/Intel who was contributing to the spec, but went with a different API).

As for why ActionProfile made itself into v1model, the answer is very simple. v1model was designed as a transitional architecture from P4_14 to P4_16 and P4_14 was designed with Tofino in mind and heavily influenced by the specifics of Tofino hardware. This is one of the reasons why P4_16 replaced P4_14.

If you are interested in the details of Tofino hardware related to this functionality (beyond @jafingerhut's explanation), they are described in the online class ICA-XFG-203: Action profiles, selectors, and traffic distribution

Happy hacking,
Vladimir

[smolkaj]

Thank you both for the history lesson, this was both very educational and very interesting :) Much appreciated!