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

Mihai Budiu mbudiu at vmware.com
Tue Aug 15 16:55:00 EDT 2017


The semantics of P4-16 is similar to other imperative languages such as C: there is a “program counter” that points to the next statement. table.apply() is just an expression similar to a function call; applying a table does not influence the control-flow of the enclosing control; the result of the table.apply can be used an a switch statement or in an if statement if desired.

There is one exception: an exit statement in an action will terminate the current control.

There is no notion of “next table” in P4-16, but there is a notion of “next statement”.

Mihai

From: Hardik Soni [mailto:hardik.soni at inria.fr]
Sent: Tuesday, August 15, 2017 1:44 PM
To: Mihai Budiu <mbudiu at vmware.com>
Cc: Vladimir Gurevich <vladimir.gurevich at barefootnetworks.com>; p4-dev <p4-dev at lists.p4.org>; Antonin Bas <antonin at barefootnetworks.com>
Subject: Re: [P4-dev] tables ordering in pipeline using "conditionals", "next_tables", ...?

Mihai and Vladimir,
Can you confirm my understanding from P4-16's perspective?
P4-16 allows to apply same table twice.
The table transitions(control flows) are not programmed within the table using hit-miss concept or action.
I don't see such a provision in the spec of P4-16 dated May 22, 2017 version 1.0.0, unless target provides a special action.
Only, apply{...} block, programs the table transition.
Here, there is no possibility of programming a loop or cycle, however can have multiple :.apply" calls from the same table instance.
Am I right?

Now from perspective of realizing it in hardware or software.

Vladimir,
If a target provides action (or primitive in the terminology of BMV2) to transit to other table,  the table having this "special" ability gets involved in control flow programming.
Things become complicated and applying same table twice means possibility of having cycle.
Yes, I agree match and actions are separate stages. But, attaching control flow(table transitions) with actions may create a problem of having cycles.

In follwing,
"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.

From P4-16 language perspective, I do not see benefit of attaching "3. The next table(pointer)" with action execution.

Thanks for sharing the links, I could not attend the meet and later forgot to check if ppts are available or not.
In future, I might be interested in knowing more details of tofino hardware, to see if outcome my work can use this.

Antonin,
Now related to BMV2 code, I want to know following.
If "conditionals" and "next_states" both are setting the states, which would be used?
If my above understanding of P4-16 spec is right(that tables do not take part in control flow programming via action),
is it sufficient to keep the *next_node  in ControlFlowNode class and strictly making it pipeline with possibility of multiple ".apply" of  the same table?
Yes, I agree change in compiler will be needed, it need to generate something in "conditionals" tag in absence of "if expression" in apply{...} block with direct t.apply calls.
I am not raising any issue, just trying to understand BMv2 code and p4-16 clearly so I can correctly extend BMV2 for my work.
My problem is table-transitions can be programmed two ways with current BMV2, I can take either of the way and follow it.

Thanks in advance folks.

PS.
I really appreciate your replies, knowing some of my questions could be already discussed topics in the past and some code questions might be unnecessary, if I spend more time with code.
As, I am in absolute hurry can not experiment everything, I am asking some code-related questions on dev forum.

-Hardik

________________________________
From: "Mihai Budiu" <mbudiu at vmware.com<mailto:mbudiu at vmware.com>>
To: "Vladimir Gurevich" <vladimir.gurevich at barefootnetworks.com<mailto:vladimir.gurevich at barefootnetworks.com>>, "Hardik Soni" <hardik.soni at inria.fr<mailto:hardik.soni at inria.fr>>
Cc: "p4-dev" <p4-dev at lists.p4.org<mailto:p4-dev at lists.p4.org>>
Sent: Tuesday, 15 August, 2017 7:18:44 PM
Subject: RE: [P4-dev] tables ordering in pipeline using "conditionals", "next_tables", ...?

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.

Mihai

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,
Vladimir



On Tue, Aug 15, 2017 at 8:59 AM, Hardik Soni <hardik.soni at inria.fr<mailto: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://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>
http://lists.p4.org/mailman/listinfo/p4-dev_lists.p4.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.p4.org_mailman_listinfo_p4-2Ddev-5Flists.p4.org&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=tGW6TKXajnoXSyy1S1P4DHGPe8sj54GGvw-b21n7aWg&m=2tAKo3QoShJfZR0a-gUsu_H4cm0q3F_4jVYQzFmnYHo&s=_l_2vE_TFTrQ-VqeniXApTc7_acFY9n0J26dxKxJhnc&e=>



--
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/14fd92f3/attachment-0002.html>


More information about the P4-dev mailing list