[PSA] Ability to program flows with direct actions in tables with action_selector implementation

[samar-abdi]

Tables with action_selector implementation can only be programmed with table entries that point to an action profile member or group. However, some use-cases require performing a direct action, such as setting a metadata field, in conjunction with performing a group action, such as setting the next hop.

In a P4 table (T) with selector implementation (S), the actions attribute defines the set of actions that can be used for instantiating an action profile member, which can then be programmed in S. It would be useful to program a table entry in T with a direct action as well as a member or group in S.

For example:

action_selector (...) as;
table foo {
key = {....}
actions = {bar;}
selector_actions = {baz;} <---- new table attribute to define actions programmable in selector.
implementation = as;
}

The API would allow programming table entry in foo with bar action and a member in as with baz action.

Thoughts??

[jafingerhut]

Just so I understand, it seems like with no changes from the current PSA spec, it is possible to achieve the desired effect by having action baz call action bar, except then action baz must take all of bar's parameters as parameters of its own, and pass them through to bar?

[samar-abdi]

@jafingerhut
Yes, that is exactly right. With the additional constraint that all of bar's parameters will be the same for all baz members in a group.

[jafingerhut]

Are you aware that it is straightforward to use 3 normal P4 tables and a Hash extern to implement the same behavior as an action selector? See this document for one way to do it (there are other variations, too): https://github.com/jafingerhut/p4-guide/blob/master/action-profile-and-selector/README-action-profile.md

If you choose to implement functionality using pieces like that, it becomes pretty easy to see how to add variations like you are suggesting here.

I'm not saying "no, what you ask about cannot be added to PSA". I am pointing out an alternative, in case it is not added to PSA.

[samar-abdi]

@jafingerhut
Yes, I am aware. Essentially, group ID can be a piece of metadata set by the first table and matched on a subsequent table. The issue is that it requires writing the P4 program in a way that makes it difficult
(a) to compile to fixed function devices.
(b) for the switch software to translate P4 flows into corresponding TCAM rule in HW.

[cc10512]

At the Dec 20 meeting we decided to punt on supporting this feature.