[P4-dev] on the cloning primitive in the simple switch

Salvatore Signorello ssignorello at ciencias.ulisboa.pt
Sun Jun 23 16:11:56 EDT 2019

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 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 
/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 [2]:

/"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 [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.

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.

[1] https://github.com/p4lang/behavioral-model/issues/667

[2] https://github.com/jafingerhut/p4-guide/tree/master/v1model-special-ops

Thank you in advance for your help and sorry for this a-bit-verbose message,



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-dev_lists.p4.org/attachments/20190623/42404ec1/attachment.html>

More information about the P4-dev mailing list