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

Hardik Soni hardik.soni at inria.fr
Wed Aug 16 09:35:44 EDT 2017


Thanks Andy.. 

-Hardik 

----- Original Message -----

> From: "Andy Fingerhut" <andy.fingerhut at gmail.com>
> To: "Hardik Soni" <hardik.soni at inria.fr>
> Cc: "Mihai Budiu" <mbudiu at vmware.com>, "p4-dev" <p4-dev at lists.p4.org>
> Sent: Wednesday, 16 August, 2017 1:12:36 AM
> Subject: Re: [P4-dev] tables ordering in pipeline using "conditionals",
> "next_tables", ...?

> 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
> > 
> 
> > > Sent: Tuesday, August 15, 2017 10:13
> > 
> 
> > > To: Hardik Soni
> > 
> 
> > > Cc: p4-dev
> > 
> 
> > > 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
> > > and
> > > http://p4.org/wp-content/uploads/2017/05/p4_d2_2017_programmable_data_plane_at_terabit_speeds.pdf
> > > )
> > 
> 

> > > 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 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) T here 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
> > 
> 

> > _______________________________________________
> 
> > 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/20170816/ee0e4e98/attachment-0002.html>


More information about the P4-dev mailing list