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

Vladimir Gurevich vladimir.gurevich at barefootnetworks.com
Tue Aug 15 13:12:28 EDT 2017

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 and

Happy hacking,

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

> Hello,
> 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://github.com/p4lang/behavioral-model/blob/master/src/bm_sim/P4Objects.cpp#L1697>
> 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 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
> http://lists.p4.org/mailman/listinfo/p4-dev_lists.p4.org

*Vladimir Gurevich*

*Barefoot Networks*
*Technical Lead, Customer Engineering*
Email: 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/f2b3dae1/attachment-0002.html>

More information about the P4-dev mailing list