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

Andy Fingerhut andy.fingerhut at gmail.com
Tue Aug 15 19:12:36 EDT 2017


Hardik:

My understanding is that the P4_16 v1.0.0 language spec allows a single
control block to call T1.apply() on a table T1 as many times as you want.

The latest versions of behavioral-model and p4c code do not support this.
As Antonin wrote in a comment on this issue [1]: "Internally, control flows
are represented as a table graph, mostly for legacy reasons."

A different bmv2 JSON file format could enable the full generality of the
P4_16 language in this regard, but the existing bmv2 JSON file format
cannot enable this, because in the existing format the next actions for a
table are a property of the table itself.

Andy

[1] https://github.com/p4lang/p4c/issues/457

On Tue, Aug 15, 2017 at 1:43 PM, Hardik Soni <hardik.soni at inria.fr> wrote:

> 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>
> *To: *"Vladimir Gurevich" <vladimir.gurevich at barefootnetworks.com>,
> "Hardik Soni" <hardik.soni at inria.fr>
> *Cc: *"p4-dev" <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 <vladimir.gurevich at barefootnetworks.com>
> *Sent: *Tuesday, August 15, 2017 10:13
> *To: *Hardik Soni <hardik.soni at inria.fr>
> *Cc: *p4-dev <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> 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
>> 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
> Phone: (408) 833-4505
>
>
>
> _______________________________________________
> P4-dev mailing list
> P4-dev at lists.p4.org
> http://lists.p4.org/mailman/listinfo/p4-dev_lists.p4.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-dev_lists.p4.org/attachments/20170815/1bde8067/attachment-0002.html>


More information about the P4-dev mailing list