<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Hi Chang,<br>
      <br>
      Yes, in my understanding lazy parsing is more than what resubmit
      can do. For example, imagine a situtation when your p4 program
      parses ethernet and IPv4 headers, but the tables applied to the
      current incoming packet only contains "reads" for some ethernet
      fields. In this case the IPv4 header does not take part in the
      decision making at all. My view that the ability of lazy parsing
      belongs to compiler, but could be allowed by the specification. As
      far as I know, the current specification may allow this kind of
      lazy parsing. According to the discussion with our industrial
      partner (a large vendor, but I have not had the permission to name
      it yet), thier OpenFlow switch does the parsing in a lazy fashion.
      Actually, the parsing always stops as soon as the given
      table-lookup can be performed. <br>
      <br>
      Besides these, we have further questions related to the example
      compiler. There are some predefined "magic" numbers in the current
      l2switch p4 programs, e.g. digest-receiver 1024 is used for mac
      learning. What is the long-term plan with these numbers, since
      they seems to be target specific values? Is it not the case that
      reduces the portability of a p4 program?<br>
      <br>
      Thanks for you reply in advance!<br>
      <br>
      Best,<br>
      Sandor<br>
      <br>
      <br>
      2015.06.19. 2:39 keltezéssel, Changhoon Kim írta:<br>
    </div>
    <blockquote
cite="mid:CAELGGhR5qi0_Hc2ZNUMcgZ=-+NuZKp65+=taqha+VMM3895gUw@mail.gmail.com"
      type="cite">
      <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 moz-do-not-send="true"
                  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 moz-do-not-send="true"
                            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
                            moz-do-not-send="true"
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
                            moz-do-not-send="true"
                            href="https://github.com/p4lang/switchapi"
                            target="_blank">https://github.com/p4lang/switchapi</a>)
                          complements the switch P4 program (<a
                            moz-do-not-send="true"
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 moz-do-not-send="true"
                                href="http://lakis.web.elte.hu"
                                rel="noreferrer" target="_blank">http://lakis.web.elte.hu</a><br>
                              Phone: <a moz-do-not-send="true"
                                href="tel:%2B36%201%20372%202869"
                                value="+3613722869" target="_blank">+36
                                1 372 2869</a> /<br>
                              Cell: <a moz-do-not-send="true"
                                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 moz-do-not-send="true" href="mailto:P4-dev@p4.org">P4-dev@p4.org</a><br>
                Listinfo - <a moz-do-not-send="true"
                  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 moz-do-not-send="true"
                  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>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Sándor Laki, PhD
Assistant Professor
Department of Information Systems
Eötvös Loránd University
Pázmány Péter stny. 1/C
H-1117, Budapest, Hungary
Room 2.506
Web: <a class="moz-txt-link-freetext" href="http://lakis.web.elte.hu">http://lakis.web.elte.hu</a>
Phone: +36 1 372 2869 / 8477
Cell: +36 70 374 2646 </pre>
  </body>
</html>