Hi, Is there any way to program a table that will not be associated with a particular action but merely as a method to extend the control of the embedded server. Such a table can be control table (for example setting the counter polling rate) or can be a table that controls a special function.
Assuming that the architecture wants to provide a counter module but the actual setting of a counter require more settings (obviously the counter can provide much more flexible functionality with respect to a simple counter that simply counts bytes and packets).
From a P4 programmer perspective it will be great if the only thing to program is the “counters” attribute of a table. The vendor of such a counter may provide profiles with the default action for counters (bytes and/or packets). However the user should be able to extend the counter functionality by programing these profile tables. Note that the profile table is not an action table. However, for a controller developer the programing of a profile table is similar (same API) and for the server developer the interface to the P4RT is also the same (similar to other table commands).
I wrote a quick P4 program and was able to create such a table with a dummy action. The action (which define the table fields) simply assign the action parameters into the metadata structure that is user define (me) in the V1 model. However, that looks like a hack.
BTW, such type of tables might be used to configure ports that with the current P4 do not have support within the language.
I am not quite sure what you are asking for here. A concrete example of the P4 code for the approach you tried that you consider to be a hack might make things clearer.
A P4 table with no actions would not have any effect at all on how packets are processed, so I’m not sure what you are trying to achieve.
Let assume that I have a port of which I would like to configure its mode to be VRF, VLAN or L3. I also want to be able to set the port speed, loopback mode etc… Currently this is out of the P4 scope however, these type of configurations are essential for any switch.
One option is to create a no action table that can use the current P4RT mechanism of entry insert/modify/delete/lookup and to communicate between the controller and the server.
For port speed, loopback, etc. there are typically other ways outside of the P4Runtime API to configure these things. See this section of the P4Runtime specification “Not in Scope”: P4Runtime Specification
There it says: " The following are not in scope of P4Runtime:
- Runtime control of elements outside the P4 language. For example, architecture-dependent elements such as ports, traffic management, etc. are outside of the P4 language and are thus not covered by P4Runtime. Efforts are underway to standardize the control of these via gNMI and gNOI APIs, using description models defined and maintained by the OpenConfig project [35]. An open source implementation of these APIs is also in progress as part of the Stratum project [37]."
For things like VRF, VLAN, or L3 mode, typically I would expect those things to be implemented in part by how you write your P4 program to process packets, and partly by how the control plane software is written. That is completely within the scope of what the P4Runtime API is intended to enable, but in those cases I would expect the P4 tables that implement those features in the data plane to be actions that DO something, not no-op tables.
Andy, I can see your point. However, I think that it is fairly compilates things if now, due to P4 limitations, one has to use a different technology (gNMI or other) to perform a functionality that every networking device will have.
On a different topic, my understanding is that all objects must be instantiated by the P4 program. For example, counters (direct counters) or meters (direct meters) should be instantiated at the P4 program before being accessed by the controller through the special P4RT messages. Would it be possible to dynamically create a counter object by the controller?
One view is that it complicates things. Another view is that it takes something existing and already standardized to do those functions, and does not reinvent it.
All P4-programmable target devices I am aware of let you take the current P4 program, use a text editor to edit it, and then compile the program again. That is a well supported way to add new objects to the device.
I am not aware of any that would add an object without going through those steps. If you tried to do such a thing, you would need a way to specify under what conditions that counter is updated, yes? If you do not specify that in a P4 program, how would you propose doing it?
One way is to associated a direct counter with a table as it is currently being done. However, counters might be scarce resource and assigning a counter for one table sometimes means that you will not be able to count objects of other tables.
It would be nice to have the ability to design a table with a counter but activate/deactive the counter at runtime. Doing that enables multiple tables to use the same physical counter.
If you are willing to write the P4 program with the capability pre-planned into it, you can use indirect counters shared by multiple tables, and the control plane can decide which tables update it, at which indexes, and which tables do not, on a per-entry basis.
I see.
and how do I read a counter for a specific entry, i.e. which index should I use? I see that the counter index is often associated with a user provided type. Is that mean that to read a counter from an entry I should use the entry key? Is it the driver responsibility to convert the key into an index where the counter can be found?
You can always read an indirect counter at whatever index you want to from the control plane API. If. you assign those indices dynamically to other tables, then it is up to the control plane software to choose them, and keep track of them.
Hmm, let consider a simple case of direct counter in a table.
What should be the index parameter to obtain the value of the counter? Would it be the key of the table?
In the P4Runtime API, yes, direct counters values are associated with their table entry by the key of the entry.
Hi Andy,
so maybe for ports you can use a different non-P4 technology. Now if I need to configure ECMP behavior (regular hash, modulo computation, weighted power of 2, etc…) how do you propose to do that?
Most P4 architectures have an extern called an action selector: v1model, PSA, and TNA at least, that is intended to do exactly that. The one defined by v1model and PSA only explicitly supports ECMP, not WCMP (weighted), if I remember correctly, but may be forgetting the details.
Even if an architecture did not support that, you can build it out of 3 or 4 P4 tables and hash computation logic: p4-guide/README-action-selector-variant-comparison.md at master · jafingerhut/p4-guide · GitHub
With small variations on the P4 code in that last link, you can implement WCMP and other things that are neither ECMP nor WCMP.
PSA definition of ActionSelector: P4~16~ Portable Switch Architecture (PSA)
P4Runtime API definition of messages for configuring action selectors (and a simpler thing called action profiles that all of the above architectures also have): P4Runtime Specification
While the example you provided is nice it is dependent on PSA architecture and is not integral part of P4 (i.e. P4 doesn’t include the key word “implementation” within its table definition).
In my opinion if every architecture will start “inventing” extern the controller code as well as the P4 programs will be incompatible between architecture.
While I fully understand that there will be differences between devices and therefore programs will never be fully compatible, I think that the P4 language primitives should cover as much ground as possible. By defining a keyless configuration table the problem of ECMP configuration becomes trivial.
If you believe you have a useful addition to propose, I suggest that you write up a description of it and show it to others and try to convince them of its value. For example, what the syntax of a P4 program would look like, what its packet processing behavior is, how that packet processing behavior is related to the P4 program, what the control plane API is for that program, i.e. its operations that it supports, and how each operation changes the packet processing behavior.
This can probably be done by creating a seudu_action attribute in a table. This will instruct the compiler to only generate the action fields of the table in the P4Info description. The advantage is that it will create a method to communicate configuration options that are not match and action type. I will talk to other people and see that indeed there is a need for it. Obviously we can always define this attribute as an extern and provide a compiler that can handle this but it might be beneficiary to have a more unified approach.