[P4-dev] on the cloning primitive in the simple switch
ssignorello at ciencias.ulisboa.pt
Sun Jun 23 16:11:56 EDT 2019
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 invoked?
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
/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
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
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.
Thank you in advance for your help and sorry for this a-bit-verbose message,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the P4-dev