[P4-dev] tables ordering in pipeline using "conditionals", "next_tables", ...?

Mihai Budiu mbudiu at vmware.com
Tue Aug 15 13:18:44 EDT 2017

I would like to qualify this explanation; it depends on the meaning of “loops”, or on what you consider nodes in your graph. P4-16 in fact allows one to apply a table instance multiple times, so the graph which has table instances as nodes can have loops. Some targets, such as bmv2, cannot support such graphs, so the compiler for this target will reject such programs. Other targets may support them.


From: Vladimir Gurevich<mailto:vladimir.gurevich at barefootnetworks.com>
Sent: Tuesday, August 15, 2017 10:13
To: Hardik Soni<mailto:hardik.soni at inria.fr>
Cc: p4-dev<mailto:p4-dev at lists.p4.org>
Subject: Re: [P4-dev] tables ordering in pipeline using "conditionals", "next_tables", ...?

Hello Hardik,

I am not sure if you are asking about BMv2 implementation details of P4 in general. Let me answer your question from P4 standpoint.

The match-action algorithm that is representable by P4 controls (not parsers), is, indeed a graph, specifically a DAG, meaning that there are no loops. It is, indeed, the compiler's responsibility to ensure that there are no loops and therefore there is no possibility that next-table pointers will point "backwards". Such graphs are easily and naturally implemented in real hardware pipelines (just execute what you need and ignore the rest).

Another important aspect of the language is the fact that match and action are thought of as separate phases, each taking some amount of time. During the match phase, the abstract machine determines the following 3 things:

  1.  The action that needs to be executed
  2.  The action data for this action
  3.  The next table (pointer)

The actual action is executed during the second phase.

This is why it is so natural to allow conditional execution, based on hit/miss or match result.

For more details you can take a look at the presentations from P4 Developers Day (http://p4.org/wp-content/uploads/2017/05/p4_d2_2017_p4_16_tutorial.pdf<https://urldefense.proofpoint.com/v2/url?u=http-3A__p4.org_wp-2Dcontent_uploads_2017_05_p4-5Fd2-5F2017-5Fp4-5F16-5Ftutorial.pdf&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=tGW6TKXajnoXSyy1S1P4DHGPe8sj54GGvw-b21n7aWg&m=2tAKo3QoShJfZR0a-gUsu_H4cm0q3F_4jVYQzFmnYHo&s=DiFZAssrsp4Fo8hh9Yx8tVvRLKWBvqqGCTxfSskilZw&e=> and http://p4.org/wp-content/uploads/2017/05/p4_d2_2017_programmable_data_plane_at_terabit_speeds.pdf<https://urldefense.proofpoint.com/v2/url?u=http-3A__p4.org_wp-2Dcontent_uploads_2017_05_p4-5Fd2-5F2017-5Fprogrammable-5Fdata-5Fplane-5Fat-5Fterabit-5Fspeeds.pdf&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=tGW6TKXajnoXSyy1S1P4DHGPe8sj54GGvw-b21n7aWg&m=2tAKo3QoShJfZR0a-gUsu_H4cm0q3F_4jVYQzFmnYHo&s=rPlGQZP3fC5KXyvcUz5bXLVb_r7F8cP8Jv_xCj7fV2c&e=>)

Happy hacking,

On Tue, Aug 15, 2017 at 8:59 AM, Hardik Soni <hardik.soni at inria.fr<mailto:hardik.soni at inria.fr>> wrote:

I have a confusion between two constructs.

1) Why next tables are dependent on actions?
    I have attached a screenshot, it shows fragment of .p4 against .json side by side.
    For 3 actions, there are 3 values in "next_tables" tag from line 784 to 786 in .json snippet.
    In lines 1697 to 1713<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_p4lang_behavioral-2Dmodel_blob_master_src_bm-5Fsim_P4Objects.cpp-23L1697&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=tGW6TKXajnoXSyy1S1P4DHGPe8sj54GGvw-b21n7aWg&m=2tAKo3QoShJfZR0a-gUsu_H4cm0q3F_4jVYQzFmnYHo&s=Rat2_ovh_DEyTkZnKGb77Zu9hc78b_V3eCbNbDJJXEs&e=>  of P4Objects.cpp,  why MatchTableAbstract types have next_tables based on actions?
    These actions are not kind of "goto table" semantics.
    It is not really a pipeline if there are next_table options based on actions in one table, its a graph.
    This semantic(control invocation from table) is not specified in the spec of P4-16 dated May 22, 2017 version 1.0.0.
    For example, the idea of having different  next nodes even for __HIT__ and __MISS__  are also not specified.

2) There is apply{...} in .p4 or conditionals in .json, so which order of table arrangement is finally used?
    To me it seems, conditionals have final say.

I went through https://github.com/p4lang/behavioral-model/blob/master/docs/JSON_format.md<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_p4lang_behavioral-2Dmodel_blob_master_docs_JSON-5Fformat.md&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=tGW6TKXajnoXSyy1S1P4DHGPe8sj54GGvw-b21n7aWg&m=2tAKo3QoShJfZR0a-gUsu_H4cm0q3F_4jVYQzFmnYHo&s=xV_t_-2glSCeAnX8rIjFZe4dkXRYOqjzEvJgVHaC1yo&e=> link.
Still, did not understand why two ways to define control flow even if it is a graph?
What is the difference, except the scope at which control transition is programmed?

Best Regards,
Hardik Soni

P4-dev mailing list
P4-dev at lists.p4.org<mailto:P4-dev at lists.p4.org>

Vladimir Gurevich

Barefoot Networks
Technical Lead, Customer Engineering
Email: vag at barefootnetworks.com<mailto:vag at barefootnetworks.com>
Phone: (408) 833-4505

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-dev_lists.p4.org/attachments/20170815/cbc9681f/attachment-0002.html>

More information about the P4-dev mailing list