[P4-dev] Queries related to primitives in json and bmv2 code

Antonin Bas antonin at barefootnetworks.com
Wed Aug 9 17:15:39 EDT 2017


Q1: It is the job of the compiler to know which operations are available
for a given architecture. Some are always available, they are referred to
as the "core primitives" in the bmv2 JSON documentation (
https://github.com/p4lang/behavioral-model/blob/master/docs/JSON_format.md).
For other operations, the name expected by bmv2 usually matches the name in
the P4 architecture file. This is the case for "truncate" (arch:
https://github.com/p4lang/p4c/blob/master/p4include/v1model.p4#L141, bmv2:
https://github.com/p4lang/behavioral-model/blob/master/targets/simple_switch/primitives.cpp#L339).
This is not the case for "random" (arch) / "modify_field_rng_uniform"
(bmv2). When needed the compiler is responsible for performing the
appropriate mapping. By being consistent when defining the architecture and
implement it in bmv2, one can avoid having to perform this mapping.
Unfortunately v1model.p4 and simple_switch were defined at different times
and diverge slightly.
One important thing to remember is that bmv2 operations cannot "return"
values unlike P4_16 extern methods, so the compiler usually needs to
synthesize an "out" parameter.

Q2: You can look at this file and see that primitives can have any number
of parameters:
https://github.com/p4lang/behavioral-model/blob/master/targets/simple_switch/primitives.cpp

Q3: I think you misunderstood the comment. The comment is an open question
asking whether we should be able to capture all primitive *parameters* as
expressions in an efficient way.

Q4: Yes for "assign". The order of arguments is deterministic for all
primitives btw.

Q5: This information is irrelevant to bmv2 and therefore doesn't appear in
the JSON. bmv2 already "knows" the direction in a way based on the
primitive definition / implementation. For example, in the case of
modify_field (
https://github.com/p4lang/behavioral-model/blob/master/targets/simple_switch/primitives.cpp#L44)
the first parameter is a non-const reference ("out") while the second is a
const reference ("in").
The compiler is also aware of the direction of parameters based on the
primitive / extern method definition (
https://github.com/p4lang/p4c/blob/master/p4include/v1model.p4).

On Wed, Aug 9, 2017 at 7:24 AM, Hardik Soni <hardik.soni at inria.fr> wrote:

> Hello,
>
> ok, I have the answer of Q1 but there is a follow up question.
> I forgot I took the same primitives.cpp as simple_switch.
> There was a separate file primitves.cpp
>
> Q1' : How does compiler know the opcode name of primitives for the target?
>
>  Q5: I need information on direction of parameters for the primitives in
> json or BMV2.
> I meant is there a way  to know if the parameter remains constant in the
> execution of primitive or gets modified.
> Any dirtiest hack would be fine for now.
>
> -Hardik
>
> ------------------------------
>
> *From: *"Hardik Soni" <hardik.soni at inria.fr>
> *To: *"p4-dev" <p4-dev at lists.p4.org>
> *Sent: *Wednesday, 9 August, 2017 3:41:56 PM
> *Subject: *[P4-dev] Queries related to primitives in json and bmv2 code
>
>
> Hello,
>
> Q1. What are the possible "op" values for primitives in context of
> following json snippet?
> I can see the macro, but where is the place where target writers invoke
> the macros?
> Is there a set of basic primitives already defined, lets say for BMV2
> simple switch target?
>
> ...
>
> "primitives" : [
> {
>     "op" : "assign",
>     "parameters" : [
>
>  ...
>
>
>
> Q2. Do primitives always have  two parameters? Left expression and right
> expression?
>
> Following are the two cases of "assign" primitive.
>
>
> Case 1:
>
> {
>     "op" : "assign",
>     "parameters" : [
>     {
>         "type" : "field",
>         "value" : ["ethernet", "srcAddr"]
>     },
>     {
>         "type" : "field",
>         "value" : ["ethernet", "dstAddr"]
>     }
>     ],
>     "source_info" : {
>         "filename" : "./input-p4s/dc.p4",
>         "line" : 231,
>         "column" : 8,
>         "source_fragment" : "hdr.ethernet.srcAddr = hdr.ethernet.dstAddr"
>     }
> },
>
>
>
> Case 2:
>
> {
>     "op" : "assign",
>     "parameters" : [
>     {
>     "type" : "field",
>     "value" : ["ipv4", "ttl"]
>     },
>     {
>         "type" : "expression",
>         "value" : {
>             "type" : "expression",
>             "value" : {
>
>                 "op" : "&",
>
>                 "left" : {
>                     "type" : "expression",
>                     "value" : {
>                         "op" : "+",
>                         "left" : {
>
>                             "type" : "field",
>                             "value" : ["ipv4", "ttl"]
>
>                         },
>                         "right" : {
>                         "type" : "hexstr",
>
>                         "value" : "0xff"
>                         }
>                     }
>
>                 },
>                 "right" : {
>                     "type" : "hexstr",
>                     "value" : "0xff"
>                 }
>             }
>         }
>
>     }
> ],
> "source_info" : {
>     "filename" : "./input-p4s/dc.p4",
>     "line" : 233,
>     "column" : 8,
>     "source_fragment" : "hdr.ipv4.ttl = hdr.ipv4.ttl - 1"
> }
> }
>
>
>
> Q3. In the function  P4Objects::add_primitive_to_action(const Json::Value
> &cfg_primitive, ActionFn *action_fn)
>
>         there is a comment for "expression" type.
>
>  "// TODO(Antonin): should this make the field case (and other) obsolete
>
>   // maybe if we can optimize this case "
>
> For future code, do you think all the primitives can be captured as
> expressions?
>
>
>
> Q4. Can I  always conclude that the first parameter is left side of
> assignment operator and the second parameter is right side, given that
> __"op" : "assign"__?
>
>
>
> 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
>
>
>
> _______________________________________________
> P4-dev mailing list
> P4-dev at lists.p4.org
> http://lists.p4.org/mailman/listinfo/p4-dev_lists.p4.org
>



-- 
Antonin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-dev_lists.p4.org/attachments/20170809/bb1a96ba/attachment-0002.html>


More information about the P4-dev mailing list