[P4-dev] filling tables

Mihai Budiu mbudiu at barefootnetworks.com
Tue Jul 21 13:39:20 EDT 2015


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.
- 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.
- 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.
- 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.

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

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

Mihai

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

>  Hi all,
>
> first, thank you for the feedback, later, more inline
>
> best,
> Salvatore
> 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?
>
>
> Best,
> Sandor
>
> 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.
>
>
>
> Haoyu
>
>
>
>   *From:* P4-dev [mailto:p4-dev-bounces at p4.org <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
> *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{
>     reads{
>         protocol1.fieldA : exact;
>         protocol2.fieldB : exact;
>     }
>     actions{
>         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,
> best,
> Salvatore
>
>
>
>
> _______________________________________________
> P4-dev mailing listP4-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 / 8477
> Cell: +36 70 374 2646
>
>
>
> _______________________________________________
> P4-dev mailing list
> 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/ab5d8b9c/attachment-0001.html>


More information about the P4-dev mailing list