[P4-dev] on the cloning primitive in the simple switch
andy.fingerhut at gmail.com
Sun Jun 23 22:00:46 EDT 2019
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.
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
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.
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
I would guess that the issues above are independent of the bug that
sometimes does not preserve metadata with recirculated, resubmitted, and
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.
On Sun, Jun 23, 2019 at 1:14 PM Salvatore Signorello <
ssignorello at ciencias.ulisboa.pt> wrote:
> Dear all,
> I would need some clarifications about the clone primitive behaviors,
> IngressToEgress (I2E) and EgressToEgress (E2E), implemented by the bmv2's
> simple switch.
> Caveat: I have been testing the clone primitive in an old tutorial's
> virtual machine, available here
> So, the compiler tool-chain and the target itself I am using are not the
> very latest versions.
> Follow my questions:
> 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
> 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 *enq_timestamp* std metadata values,
> the cloned packet enters the traffic manager first.
> iii) standard metadata values: I am bit surprised by the metadata
> *ingress_global_timestamp*/*egress_global_timestamp* and *packet_length*
> 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?
> Somewhere in :
> *"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."*
> does it relate to my last question? Which kind of metadata (standard or
> user-defined) does that warning refer to?
> 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 , 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.
> 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.
> 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.
>  https://github.com/p4lang/behavioral-model/issues/667
> Thank you in advance for your help and sorry for this a-bit-verbose
> P4-dev mailing list
> P4-dev at lists.p4.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the P4-dev