<div dir="ltr"><div>Hi Peter,<br><br></div>Thanks for your email. Please see comments inline:<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 23, 2015 at 11:53 AM, Peter Newman (petenewm) <span dir="ltr"><<a href="mailto:petenewm@cisco.com" target="_blank">petenewm@cisco.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I am working on a parser in P4. I noticed the following minor issues with the compiler:<br>
<br>
<br>
Compiler crashes if you have a cycle in the parse graph. It enters an infinite recursion at line 448 in p4_tables.py:<br>
<br>
xconds = exclusive_conditions.Solver(hlir)<br>
<br>
You can prevent this behavior if you set the optimize flag to false in the call to build(). I didn’t look at what optimization it is trying to do but it doesn’t seem to affect my parser.<br>
<br>
I did notice the comment a few lines later: "# I am being lazy, and this is all tentative anyway” so I guess this feature is still under active development. It might be better to check for a cycle before executing the optimization.<br></blockquote><div><br></div><div>What kind of cycle do you have in your P4 program? This MPLS parser (<a href="https://github.com/p4lang/p4factory/blob/master/targets/switch/p4src/includes/parser.p4#L147">https://github.com/p4lang/p4factory/blob/master/targets/switch/p4src/includes/parser.p4#L147</a>) has a cycle (you can extract up to 3 MPLS headers) and is handled correctly by the compiler. More generally, it is okay to have a cycle so long as you are extracting to a tag stack. I can't think of a use case where this would not be the case, which is why I would be interested in seeing your P4 program.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
The HLIR spec defines a p4_expression to contain references to objects of type: None, int, p4_header_instance or p4_field. The compiler actually gives type str instead of p4_header_instance or p4_field. The string contains the name of the field.<br></blockquote><div><br></div><div>At which stage do you observe strings? The resolve_names function (<a href="https://github.com/p4lang/p4-hlir/blob/master/p4_hlir/hlir/p4_expressions.py#L64">https://github.com/p4lang/p4-hlir/blob/master/p4_hlir/hlir/p4_expressions.py#L64</a>) should have been called at some point and take care of this.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
In a variable length packet header the compiler checks the max_length field but interprets this field as being specified in bits whereas the HLIR spec defines it to be specified in bytes.<br></blockquote><div><br></div><div>Wasn't this be fixed by this commit: <a href="https://github.com/p4lang/p4-hlir/commit/72f20169a25619e6cc318254b952886a26e25972">https://github.com/p4lang/p4-hlir/commit/72f20169a25619e6cc318254b952886a26e25972</a> ?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
Just thought I’d document these observations before I forget them.<br>
<br>
—Peter<br>
<br>
<br>
_______________________________________________<br>
P4-dev mailing list<br>
<a href="mailto:P4-dev@p4.org">P4-dev@p4.org</a><br>
Listinfo - <a href="http://mail.p4.org/mailman/listinfo/p4-dev_p4.org" rel="noreferrer" target="_blank">http://mail.p4.org/mailman/listinfo/p4-dev_p4.org</a><br>
Archives - <a href="http://mail.p4.org/pipermail/p4-dev_p4.org/" rel="noreferrer" target="_blank">http://mail.p4.org/pipermail/p4-dev_p4.org/</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr">Antonin<br></div></div>
</div></div>