[P4-dev] filling tables

Haoyu song haoyu.song at huawei.com
Tue Jul 21 15:03:59 EDT 2015

Hi Mihai,

I don’t understand why it becomes a principle of P4 design to no perform any expensive operations. If we aim to extend P4 to be able to handle data path functions more than simple forwarding, expensive operations seem inevitable. Some platforms (e.g. CPU, SNP) are especially good at that without suffering on performance.

MAC learning is just a known example. Since we are working on a protocol independent dataplane, there may be many other applications requiring such a feature in the future. So at the language level, we should seriously consider to support it.

More questions and comments are inline.

From: P4-dev [mailto:p4-dev-bounces at p4.org] On Behalf Of Mihai Budiu
Sent: Tuesday, July 21, 2015 10:39 AM
To: Salvatore Signorello
Cc: p4-dev at p4.org
Subject: Re: [P4-dev] filling tables

This problem is more complicated than it may look at first sight - at least in its full generality.
Today table updates in P4 are only allowed from the control plane. One principle behing the P4 design is that the dataplane cannot perform any expensive operations. Here is why allowing table updates from the dataplane may be difficult:

- at the P4 level tables do not just contain keys and values, they map keys to actions. So you need a way to construct actions at runtime. The action encoding is not specified by P4. You cannot just stick some bits together and write them in an array.

P4 has predefined all possible actions for a table, right? So why do you still need to construct actions at runtime? Why can’t you just use the action as a parameter of insertion operation?

- while insertion in a hash-table can be a constant-time operation, insertion in a TCAM can require reshufling potentially all entries. This is not a constant-time operation.

This is true. It means the app developer should never use this feature blindly but it doesn’t mean we should ban this feature.

- the control-plane may want to perform additional validation on the actions in a table. So perhaps not any combination of action parameters is legal.

I’m not sure I understand this argument. The P4 program needs to be validated and tested before being deployed, right?

- insertion in a table can fail dynamically - if the table is "full". The error handling code for this case may be very complex, and it may not be implementable in the dataplane.

Functions such as MAC learning are always done in dataplane in conventional networks. How are these exceptions handled there could also be applied here.

So it looks to me like the use of registers is a much better way to handle this kind of "dataplane learning".

I’d like to learn how registers can help to solve this problem.

One could conceive a form of associative memory registers, but some of these issues would have to be addressed in that case as well.


On Tue, Jul 21, 2015 at 3:58 AM, Salvatore Signorello <salvatore.signorello at uni.lu<mailto:salvatore.signorello at uni.lu>> wrote:
Hi all,

first, thank you for the feedback, later, more inline

On Mon, 2015-07-20 at 22:55 +0200, Sandor Laki wrote:
Hi Salvatore, All,

We faced similar problem when were working on a mac learning example, discussed earlier on the dev-list. Unfortunately, the current specification does not handle data plane driven table fill and update. For example, the mac learning can be done similarly to OpenFlow, using two tables (e.g. smac and dmac). As far as I know, the only thing you can do is to generate a digest and hand it to a control process running on the same switch. Of course, this is not as efficient as a data-plane-driven solution, not mentioning aspects like target independence.
Sandor, the case you've reported outlines a similar issue except some differences/nuances. I highlight such differences/nuances in the following, just cause I think those might sharp the definition of a new construct to be included into the next language specification.
Follows something inspired by theory. Honestly I don't know if things change a lot in practical implementations. Hence, please point me wrong, if I'm mistaken. The MAC learning is a multistep process. So the control flow is influenced by both  frame fields and port/switch's status. Moreover, the match+insertion is performed using different header fields (although containing similar information, i.e., MAC addresses) depending on the first hit/miss (to dmac).
Instead in the scenario I'm working on, the match/insertion always pertains the same field (or combination of fields) and it does happen in one step.

Well, you would say, what does matter? I don't know with certainty, but I've quickly figured out the following about the two options Chang has suggested:

- [Introduce a special property of a table] You mark a table with a property, so that, for example, a miss will produce a table insertion behind the scenes without any explicit action call. A "plain" (of course we might also think of a more complex construct)  solution of such kind doesn't apply well to the MAC learning, cause a) the behavior depends on the switch state as well, b) the table-key to later introduce differs from the one you've just used to match.

- [New language constructs that trigger data-plane-based entry insertion and update] This second option sounds more parameters-friendly. So, for example, we might have some primitive actions accepting header fields as parameters and this might solve the fields mismatch. Also, the rule insertion and the table definition might steer the control flow to the appropriate action as to solve the multi-step issue.

Any further thoughts on this?


2015.07.20. 20:04 keltezéssel, Haoyu song írta:
I agree such active data-path features are very useful and should be considered to add in P4 specification.


From: P4-dev [mailto:p4-dev-bounces at p4.org] On Behalf Of Salvatore Signorello
Sent: Monday, July 20, 2015 7:05 AM
To: p4-dev at p4.org<mailto:p4-dev at p4.org>
Subject: [P4-dev] filling tables

Hi all,

I wonder if there is  a "data-plane"-driven  way to fill/update tables. For example, it could be possible for a match (and so for a packet) to generate a table insertion/update in this way:

table xyz{
        protocol1.fieldA : exact;
        protocol2.fieldB : exact;
        addEntry; // for example, called the first time the pair {protocol1.fieldA,protocol2.fieldB} has been seen
        modifyEntry; // from the 2nd packet on, to keep trace of some other information

I would need this to implement a stateful forwarding behavior. Is there any way to express such behavior through the current language specification?

Remark: I don't want to use registers, cause I would rather have an associative facility (key, value) such as a table.

Thank you in advance for any hint,


P4-dev mailing list

P4-dev at p4.org<mailto:P4-dev at p4.org>

Listinfo - http://mail.p4.org/mailman/listinfo/p4-dev_p4.org

Archives - http://mail.p4.org/pipermail/p4-dev_p4.org/


Sándor Laki

Department of Information Systems

Eötvös Loránd University

Pázmány Péter stny. 1/C

H-1117, Budapest, Hungary

Room 2.506

Web: http://lakis.web.elte.hu

Phone: +36 1 372 2869<tel:%2B36%201%20372%202869> / 8477

Cell: +36 70 374 2646<tel:%2B36%2070%20374%202646>

P4-dev mailing list
P4-dev at p4.org<mailto:P4-dev at p4.org>
Listinfo - http://mail.p4.org/mailman/listinfo/p4-dev_p4.org
Archives - http://mail.p4.org/pipermail/p4-dev_p4.org/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-dev_lists.p4.org/attachments/20150721/923c3c12/attachment-0001.html>

More information about the P4-dev mailing list