Action profile and selector specification

[samar-abdi]

No description provided.

[antoninbas]

I think a diagram would be very useful to explain how action profiles / action selectors work. It is hard to convey by text alone.

[antoninbas]

I don't think this is relevant to dataplane behavior. This is one possible runtime API, but there are many others. Member entries can be identified by switch-assigned handles for example. I would also not mention any "controller" entity as it ties PSA to a SDN deployment.

[antoninbas]

the "controller-assigned id" is an abstract entity that may completely ignored by the dataplane

[antoninbas]

this is also very implementation-specific

[jafingerhut]

Figures sound like a good idea to me, if they can clearly show what is going on.

Would anyone besides me find it clarifying to have an explanation like the one at the link below for how action_profile's can be implemented, and used as a mental model for how they work?

https://github.com/jafingerhut/p4-guide/blob/master/action-profile-and-selector/README-action-profile.md

I can try writing a similar one for action selectors, too.

[jafingerhut]

@samar-abdi It isn't clear to me whether your additions cover the ability for an action_selector to 'point at' a group, and also optionally to directly 'point at' a member, without going through a group. See this issue for an example: p4lang/behavioral-model#438

[samar-abdi]

I think this sentence clarifies this capability:

"An action selector instance contains member entries consisting of action
specifications. Additionally, it may contain group entries that are defined
as a collection of member entries. .."

I will add figures to clarify this further.

[samar-abdi]

Also, the subsequent para clarifies the "pointing" capability:

"When a packet matches a table entry at runtime, the controller-assigned
+id of the action profile member or group is read. The id is used to look-up
+the member or group entry in the action selector. If the id belongs to a member,
+then the corresponding action specification is applied. However, if the id
+belongs to a group, a dynamic selection algorithm is used to
+determine the id of the member from the group, and the action specification
+corresponding to that member is applied. The dynamic selection algorithm is passed
+as a parameter to the action selector constructor..."

[jafingerhut]

In addition to a proposed 'specification' for forwarding behavior of a PSA table with implementation action_profile(), I have added to the document at the link I gave earlier a proposed way of specifying the forwarding behavior of a PSA table with implementation action_selector(). You can follow the link in an earlier comment and scroll down to the 'action_selector' section, or use the link below to go straight to that part of the document:

https://github.com/jafingerhut/p4-guide/blob/master/action-profile-and-selector/README-action-profile.md#action_selector

@antoninbas @samar-abdi @jnfoster I would appreciate any corrections or comments on that description, if you have a chance to read it over.

In particular, it seems to be the case that the implementation action_profile() and action_selector() tables in both P4_14 and P4_16 PSA are not features that one cannot implement without them, but are simply a shorter way to specify a particular kind of forwarding behavior. Does that sound correct?

[samar-abdi]

Thanks @jafingerhut for putting this together. Your interpretation looks right. Here is my input on some of your notes:
Note 1: TBD: Should T_group_size be X bits wide?
There is currently no limit on group size. However, there is a limit on total number of members in the action selector. P4Runtime also requires a limit on the number of members in a group to be specified when inserting or modifying the group. This limit should be <= the selector max size. Perhaps we should put a limit on the number of groups as part of the action_selector specification.

Note 3: TBD: What should the size of table T_group_to_member_id be? The same value N as for table T_member_id_to_action?
Since we can share members across groups, in the worst case we can have max_members * max_groups entries. Again, we should specify max_groups in action_selector.

Note 5: TBD: Are there any other ways intended to be implemented for calculating 'T_member_of_group' other than as a deterministic function of values of the fields of T's key with match_kind 'selector'?
No use case to the best of my knowledge. Although, I suppose one could use random selection and not specify a selector field at all! It would be odd to send packets out to random ports.

[mihaibudiu]

Action profiles do not add functionality to the language, but they impact resource consumption and the control-plane. For example, with action profiles you can atomically change multiple actions in a table.

[jafingerhut]

@mbudiu-vmw The implementation of action profiles that I wrote, using two P4 tables, also reduces resource consumption (vs. having many table entries with duplicated storage of the same action + action parameters). It also enables a single member to be modified atomically, shared by all of the keys that 'point to it'. I would bet $1 that it is probably exactly what some implementation use 'under the hood' for a table with implementation action_profile().

I am not proposing that we eliminate action_profile() and action_selector() from the PSA spec. I am trying to make them less mysterious to a newcomer.

[mihaibudiu]

Yes, but you still have to update two tables when you insert or delete entries, which you can do atomically to in the case of real action selectors. This is a control-plane difference.

[jafingerhut]

@mbudiu-vmw Can you give an example of the kind of control plane operation that is possible to make atomic with real action selectors, that you believe cannot be done atomically with the multi-table implementation?

[mihaibudiu]

I don't know what the control-plane operations are for action selectors; it is part of a separate spec, which I don't know if it is final.

If the only operations are action insertion/deletion this probably can be made to look atomic for the data-plane by carefully updating to the two tables in the "right" order.

For the general case think "databases": in databases if you need to do multiple operations atomically (across one or multiple tables) you need some form of transactions, which I don't know if the P4-16 control plane will provide. I am guessing that the control-plane will attempt to promise that any one operation will be atomic (as seen by the data-plane), but cannot promise that combinations of operations will be.

[antoninbas]

It's really not a matter of atomic operations or resource utilization. I believe the main goal is to simplify the P4 program and expose a familiar (think OpenFlow maybe) group / member abstraction to the application through the runtime APIs.
There can be some subtleties with resource utilization. For example, in the case of a multi-stage action pipeline, a table & its action profile can fit in the same stage, if there is some special hardware support for action profile / selector, while the 2 table solution would probably end up using 2 stages (there is a match dependency between the 2 tables).

[antoninbas]

@jafingerhut I think you captured the logical view of action profile / selector correctly in your document.

[jafingerhut]

What should be said about tables that have both an action_profile() or action_selector() implementation, and the "default_action" table property?

For example, when I try to compile this program: https://github.com/jafingerhut/p4-guide/blob/master/action-profile-and-selector/action-profile.p4

using a recent version of p4c-bm2-ss, it gives the following warnings:

action-profile.p4(136): warning: Target does not support default_action for t1 (due to action profiles)
    table t1 {
          ^^
action-profile.p4(147): warning: Target does not support default_action for t2 (due to action profiles)
    table t2 {
          ^^

Is that some fundamental limitation on all implementations of such tables? If so, why? (I don't see yet why it would be.)

Or is it just an implementation restriction currently in bmv2, and it should be straightforward for PSA implementations to have default actions for such tables?

[antoninbas]

@jafingerhut That's a great question that needs to be resolved.
In bmv2, indirect match tables (which have an action_profile or action_selector implementation attribute) use an indirect default, i.e. in the case of a miss, we pick up a default member or a default group. This default member / group can be programmed at runtime.
This conflicts with P4_16, which specifies that all tables have a classic default action. If we decide that there is no value in the ability to have a default indirect member / group, then we can remove that functionality in bmv2 & P4Runtime in the long term.
I'm personally unsure about which option makes more sense.

[samar-abdi]

The feedback from PSA is to disallow specifying a default action for tables with action profile and action selector implementation. So, if the table is not hit, the action will default to NoAction. We will note this in the PSA specification.

This requires change to p4c in that the implementation and default action attributes cannot co-exist in the table.