<div dir="ltr">Hi Sandor,<div><br></div><div>Regarding your question about lazy parsing (a.k.a. incremental parsing), have you considered using the "resubmit" primitive action? I got the impression that what you intend to do via lazy parsing is probably something more than what resubmit can do, but it'd be helpful to hear your thoughts on that. If you truly want to introduce parsing logic anywhere in the match-action pipeline, then I think it's more fundamental a topic that requires flexibility in the "P4 abstract forwarding model (Fig 1)".</div><div><br></div><div>I believe some folks in the P4 community are interested in evolving the language spec so P4 could embrace architectural differences of various underlying targets. </div><div><br></div><div>-- Chang</div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 16, 2015 at 10:10 AM, Antonin Bas <span dir="ltr"><<a href="mailto:antonin@barefootnetworks.com" target="_blank">antonin@barefootnetworks.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I just realized that I hit reply instead of reply-all when I answered a few days ago. Here was my answer to Sandor:<br><br>----------<br><br><div>Hi Sandor,<br><br></div>Please see answer inline:<br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Fri, Jun 12, 2015 at 5:24 AM, Sandor Laki <span dir="ltr"><<a href="mailto:lakis@elte.hu" target="_blank">lakis@elte.hu</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">Dear Antonin, All,<br>
<br>
If I understand correctly, non-standard intrinsic metadata is always target specific. Is there any description on how this kind of metadata can be used with the current p4 compiler?<br>
For example in l2_switch target there is an intrinsic_matadata_t with four fields. For example, if field lf_field_list is removed from the definition, the compiler crashes. However, in the p4 program this field is not modified or read at all. So, the question is if it is a bug or a normal behavior (meaning that the intrinsic metadata definition is determined by the target and cannot be changed by the developer). I think this problem is mostly related to l2 programs using core functionalities of the underlying hardware.<br></blockquote></span><div><br><div class="gmail_quote">Yes this metadata is target specific. The 
behavioral model assumes the existence of certain 
intrinsic metadata fields in order to support some features. In the 
l2_switch program, the metadata is defined as:<span><br><span style="color:rgb(0,0,0)"><br></span><pre><span style="color:rgb(0,0,0)">header_type intrinsic_metadata_t {
    fields {
        eg_mcast_group : 4;
        replication_id : 4;
        lag_hash : 16;
        lf_field_list: 32;
    }
}</span></pre><span style="color:rgb(0,0,0)">The first 3 fields are needed to do multicast, the last one is needed to do learning.</span><span style="color:rgb(0,0,0)"><br></span></span></div><span><div class="gmail_quote">Even
 though lf_field_list is not explicitly modified in the P4 program, it 
will be used when the generate_digest action primitive is called.<br></div></span><span><div class="gmail_quote">We are looking into ways to improve this.<br></div>Note
 that if you don't find the metadata field names to your liking, you can
 change them by editing the dictionary values (not the keys) in this 
metadata file: <a href="https://github.com/p4lang/p4c-behavioral/blob/master/p4c_bm/meta_config.json" target="_blank">https://github.com/p4lang/p4c-behavioral/blob/master/p4c_bm/meta_config.json</a></span><span style="color:rgb(0,0,0)"><br> </span></div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Another question is that do we understand correctly that according to the specification parsing phase can be done in a lazy way, resulting that some headers are parsed on-demand based on the tables (matching rules) to be applied. In the current implementation of most of the switches uses lazy parsing.<br>
<br></blockquote></span><div><br><span><div class="gmail_quote">Are you referring to a specific part of the spec?<br></div>If
 some headers show up in the parser definition but are not used in any 
match-action tables, you could in theory skip them during the parsing 
(while making sure that they are handled correctly by the deparser). 
However, this is a target specific optimization and the behavioral model
 does no such thing.</span><br> </div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
My last question is related to the interface of the switch. Do you plan to provide a standardized way - e.g. something like that is used by openflow between switches and controllers?<br></blockquote></span><div><br><div>The high-level semantic library (<a href="https://github.com/p4lang/switchapi" target="_blank">https://github.com/p4lang/switchapi</a>) complements the switch P4 program (<a href="https://github.com/p4lang/p4factory/tree/master/targets/switch/p4src" target="_blank">https://github.com/p4lang/p4factory/tree/master/targets/switch/p4src</a>).<br></div><div>We are also looking into OpenFlow and SAI (Switch Abstraction Interface) compatibility.</div><div> <br></div><div>Best regards,<br><br></div>Antonin<br> <br></div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Thank you in advance!<br>
<br>
Best,<br>
Sandor<span><font color="#888888"><br>
<br>
-- <br>
Sándor Laki<br>
Department of Information Systems<br>
Eötvös Loránd University<br>
Pázmány Péter stny. 1/C<br>
H-1117, Budapest, Hungary<br>
Room 2.506<br>
Web: <a href="http://lakis.web.elte.hu" rel="noreferrer" target="_blank">http://lakis.web.elte.hu</a><br>
Phone: <a href="tel:%2B36%201%20372%202869" value="+3613722869" target="_blank">+36 1 372 2869</a> /<br>
Cell: <a href="tel:%2B36%2070%20374%202646" value="+36703742646" target="_blank">+36 70 374 2646</a><br>
<br>
</font></span></blockquote></span></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><br>-- <br><div><div dir="ltr">Antonin<br></div></div>
</font></span></div></div>
<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></div></div></div>