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

Hardik Soni hardik.soni at inria.fr
Wed Aug 16 09:33:56 EDT 2017


Thanks Mihai for clarifying from the perspective of the language. 

-Hardik 

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

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

> 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

> ----- Original Message -----

> > 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) 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/20170816/6e9ae1f9/attachment-0002.html>


More information about the P4-dev mailing list