<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">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><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 class="im"><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 class="im"><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 class="im"><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><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><div><br><span class="im"><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><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><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><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 class=""><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></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr">Antonin<br></div></div>
</div></div>