<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>thank you for your reply, Andy, here follow some updates on the
      previous points after re-running the same test program over the
      latest bmv2-ss software:</p>
    <p><br>
    </p>
    <p>i) it is still possible to call clone.I2E in the egress and get a
      cloned packet going through the egress pipeline (no parser stage
      as in (ii), see below). The <i>packet_length</i> value of the
      cloned packet is not correct this time, meaning some other
      metadata values may not be set correctly either.<br>
    </p>
    <p><br>
    </p>
    <p>ii) calling clone.I2E , the cloned packet is first parsed again
      and then enters the egress pipeline:</p>
    <p><i>"[14:58:32.551] [bmv2] [D] [thread 31185] [0.1] [cxt 0] Parser
        'parser': end</i></p>
    <p><i>[14:58:32.551] [bmv2] [D] [thread 31187] [0.1] [cxt 0]
        Pipeline 'egress': start"</i><br>
    </p>
    <p><br>
    </p>
    <p>iii) now the switch seems to update almost all the metadata
      values as expected. That is, same <i>packet_length</i> value for
      both original and cloned packets. <i>ingress_global_timestamp</i>
      and <i>egress_global_timestamp </i>values set for the original
      packet, only the latter one for the cloned packet. Yet, the cloned
      packet has lower <i>enq_timestamp</i> and <i>egress_global_timestamp</i>
      values than the original packet.<br>
      <i></i></p>
    <p><br>
    </p>
    <p>Considering the nature of bmv2-ss, I am not sure it would be
      necessary to open an issue for (iii). Then, is the behavior seen
      in (ii) the intended one? <br>
    </p>
    <p>Yet, I see there might be more logical flaws in the execution of
      programs on bvm2-ss with the issue in (i). You may find the simple
      P4 program used for testing in attach. A very simple packet has
      been created and injected through scapy for testing (pkt =
      Ether()/IP()/TCP/' ' ). sswitch_CLI commands are in attach too.<br>
    </p>
    <p><br>
    </p>
    <p>Salvatore<br>
    </p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 24/06/19 03:00, Andy Fingerhut
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAKvLtDZ9DTh5HyMxEg0CU4UY9Xat280c-OFHN_oE7vrOvP2t2A@mail.gmail.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <div dir="ltr">i) While it is true that the intent of the clone
        operations is that I2E is only invoked during ingress
        processing, and E2E is only invoked during egress processing, I
        would not be surprised at all if the latest p4c and
        behavioral-model code give no error if your try to invoke them
        in the wrong places.  There are several kinds of
        specific-to-the-v1model-architecture consistency checks that are
        now made by the v1model-specific parts of p4c, but likely this
        is not one of them, at least not yet.
        <div><br>
        </div>
        <div>ii) If a cloned packet is going through ingress first, that
          sounds like a bug to me.  I do not recall seeing that behavior
          in my testing of clone operations with p4c and
          behavioral-model.  If you have a test case demonstrating this
          (i.e. full P4 program, command used to compile it, any table
          entries you added or other control plane configuration done,
          and a test packet to send in), I could take a look.  I would
          recommend testing your code with the latest versions of p4c
          and behavioral-model, too, just in case something has been
          fixed there since whatever version you have been using, but I
          do not recall any changes made in that area for the last year
          or so.</div>
        <div><br>
        </div>
        <div>iii) I would not be surprised at all if timestamp values
          were 0 for cloned packets, given the current behavioral-model
          code.  You could try filing an issue on the
          p4lang/behavioral-model project and we can find out whether
          that is considered a bug worth fixing, or the expected
          behavior.  It seems to me certainly more useful if
          ingress_timestamp and egress_timestamp were always equal to
          the last time that a packet began ingress/egress processing.</div>
        <div><br>
        </div>
        <div>Similarly for packet_length in a cloned packet.  I would
          not be surprised if for several types of packets (maybe some
          others besides cloned packets, even), that packet_length may
          be 0 given the current behavioral-model implementation.</div>
        <div><br>
        </div>
        <div>I would guess that the issues above are independent of the
          bug that sometimes does not preserve metadata with
          recirculated, resubmitted, and cloned packets.</div>
        <div><br>
        </div>
        <div>iv)  I have not yet tested configuring a clone session of
          simple_switch to be a multicast group id, but I believe
          Antonin Bas has implemented support for that.  I do not know
          if there is a simple_switch_CLI command to enable configuring
          that, or not.  Perhaps it can be configured via the P4Runtime
          API in the simple_switch_grpc process, but might not yet be
          implemented from the Thrift API and/or simple_switch_CLI.</div>
        <div><br>
        </div>
        <div>Andy</div>
        <div><br>
        </div>
        <div><br>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Sun, Jun 23, 2019 at 1:14
          PM Salvatore Signorello <<a
            href="mailto:ssignorello@ciencias.ulisboa.pt"
            moz-do-not-send="true">ssignorello@ciencias.ulisboa.pt</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px
          0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
          <div bgcolor="#FFFFFF">
            <p>Dear all,</p>
            <p>I would need some clarifications about the clone
              primitive behaviors, IngressToEgress (I2E) and
              EgressToEgress (E2E), implemented by the bmv2's simple
              switch. <br>
            </p>
            <p>Caveat: I have been testing the clone primitive in an old
              tutorial's virtual machine, available <a
href="https://drive.google.com/uc?id=1f22-DYlUV33DsR88_MeMb4s7-1NX_ams&export=download"
                target="_blank" moz-do-not-send="true">here</a>. So, the
              compiler tool-chain and the target itself I am using are
              not the very latest versions.<br>
            </p>
            <p><br>
            </p>
            <p>Follow my questions:<br>
            </p>
            <p>i) scope of the primitive: I thought I2E and E2E were
              meant to be only invoked respectively in the ingress
              pipeline and in the egress one. However, for example, I
              can invoke clone.I2E in the egress and get a clone of the
              packet injected back at the beginning of the egress
              pipeline. First, is this last behavior intended? Then,
              should not there be some sort of restriction about blocks
              of your program where these primitives can be invoked?<br>
            </p>
            <p><br>
            </p>
            <p>ii) I2E behavior: when clone.I2E is called within the
              ingress pipeline, the cloned packet goes again through the
              ingress pipeline (according to the switch's log) and then
              through the egress, while the original packet enters the
              egress pipeline too. Is this the expected behavior? One
              more minor thing, according to the respective <i>enq_timestamp</i>
              std metadata values, the cloned packet enters the traffic
              manager first.</p>
            <p><br>
            </p>
            <p>iii) standard metadata values:  I am bit surprised by the
              metadata <i>ingress_global_timestamp</i>/<i>egress_global_timestamp</i>
              and <i>packet_length</i>  values in cloned packets. The
              former is always zero, whether I would expected to see the
              timestamp of either the original packet at ingress or of
              the cloned one at egress. The latter holds a value which
              does not correspond to the actual packet size. Are both
              behaviors intended?</p>
            <p>Somewhere in [2]: <br>
            </p>
            <p><i>"Then you may find that the metadata field values are
                not preserved. The current implementation for preserving
                such metadata field values is very fragile, and
                effectively it sometimes works by accident, not by
                design."</i></p>
            <p>does it relate to my last question? Which kind of
              metadata (standard or user-defined) does that warning
              refer to?<br>
            </p>
            <p><br>
            </p>
            <p>iv) options for cloning multiple packets: it looks like a
              session id can be only be associated to a single port (or
              to a multicast group as mentioned in one related thread on
              github [1], though not tested by me yet). In fact, a new
              assignment through the mirroring_add command overwrites
              the previously assigned port. That would mean that to
              clone a packet multiple times, every time a cloned
              instance of the packet going through the program should
              re-call the clone primitive. Am I correct? That would
              imply that to generate and customize N (with N greater
              than two) copies of a packet, the multicast "could be a
              much better fit". I know this last statement sounds a bit
              obscure. Indeed, I am still trying to figure out which
              could be the implications of one choice over the other.
              So, any hint on this would be very much appreciated. <br>
            </p>
            <p><br>
            </p>
            <p>I have used a very simple program to test the above
              behaviors. In my program, I call an action invoking the
              clone primitive in the different control blocks , ingress
              and egress. Then, I create and use a single clone's
              session id, connected to a switch's output port at
              run-time through the mirroring_add command.</p>
            <p><br>
            </p>
            <p>Finally, I am already aware of the two following threads
              on github, however, please feel free to refer to them (or
              to specific parts therein) if you realize that I might be
              missing something from there.</p>
            <p>[1] <a
                class="gmail-m_-5834468257048915571moz-txt-link-freetext"
href="https://github.com/p4lang/behavioral-model/issues/667"
                target="_blank" moz-do-not-send="true">https://github.com/p4lang/behavioral-model/issues/667</a></p>
            <p>[2] <a
                class="gmail-m_-5834468257048915571moz-txt-link-freetext"
href="https://github.com/jafingerhut/p4-guide/tree/master/v1model-special-ops"
                target="_blank" moz-do-not-send="true">https://github.com/jafingerhut/p4-guide/tree/master/v1model-special-ops</a><br>
            </p>
            <p><br>
            </p>
            <p><br>
            </p>
            <p>Thank you in advance for your help and sorry for this
              a-bit-verbose message,<br>
            </p>
            <p>regards,</p>
            <p>Salvatore<br>
            </p>
          </div>
          _______________________________________________<br>
          P4-dev mailing list<br>
          <a href="mailto:P4-dev@lists.p4.org" target="_blank"
            moz-do-not-send="true">P4-dev@lists.p4.org</a><br>
          <a
            href="http://lists.p4.org/mailman/listinfo/p4-dev_lists.p4.org"
            rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.p4.org/mailman/listinfo/p4-dev_lists.p4.org</a><br>
        </blockquote>
      </div>
    </blockquote>
  </body>
</html>