Doubt on the replacement of the deprecated clone3() function

5 views
Skip to first unread message

Sergio Gutiérrez

unread,
Oct 19, 2022, 1:22:12 AM10/19/22
to p4-...@lists.p4.org

Dear all.

I am building an example program based on the code available in the ngsdn-tutorial. This code uses the clone3() function for the action clone_to_cpu(). According to this post (https://github.com/jafingerhut/p4-guide/blob/master/v1model-special-ops/README.md), reporting changes on the P4 bmv2 backend, the clone3() function is deprecated and should be replaced by clone_preserving_field_list()

In my implementation, I am defining the local_metadata_t struct as follows, using the @field_list annotation:

struct local_metadata_t {
       @field_list(0)
       port_num_t ingress_port;
}

Later, my clone_to_cpu() action definition looks like this

action clone_to_cpu() {
       //clone3(CloneType.I2E, CPU_CLONE_SESSION_ID, { standard_metadata.ingress_port });
       local_metadata.ingress_port = standard_metadata.ingress_port;
       clone_preserving_field_list(CloneType.I2E, CPU_CLONE_SESSION_ID,0);
   }

I am compiling my program with a fresh installation of p4c, compiled from sources. When executing the program, it does not seem to behave as expected. However, when compiling the program with the p4c docker image used in the ngsdn-tutorial, the program works fine.

Is there something I am missing in the invocation of clone_preserving_field_list?

My idea is having a development environment not dependent on docker images but instead having all the tools installed in a base installation of the operating system.

Thanks in advance for any hint you can provide me.

Kind regards.

-- 
Sergio Gutiérrez, Ph.D.

Andy Fingerhut

unread,
Oct 19, 2022, 8:38:29 PM10/19/22
to Sergio Gutiérrez, p4-...@lists.p4.org
Yes, clone3 is deprecated, and clone_preserving_field_list is the recommended replacement.

Yes, the parameters you are using to the call look correct to me.

"When executing the program, it does not seem to behave as expected."  If you could narrow down this unexpectedness to a single packet that behaves differently than you want, and what table entries were installed in the P4 program at the time, and even better the output of the simple_switch log file that was produced while processing the packet that is behaving not as you expect, that would help others to debug the issue.

I realize that what I am asking for might not be easy to obtain, but without more details, it is difficult for me to guess what might be going wrong.

Andy


--
You received this message because you are subscribed to the Google Groups "p4-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to p4-dev+un...@lists.p4.org.
To view this discussion on the web visit https://groups.google.com/a/lists.p4.org/d/msgid/p4-dev/8c9d25f8-4ef4-ebe4-e6b6-94e4bbf12a94%40gmail.com.

William Fisher

unread,
Oct 21, 2022, 3:58:55 PM10/21/22
to p4-dev, andy.fi...@gmail.com, p4-...@lists.p4.org, sag...@gmail.com
I have an implementation of main.p4 from the ngsdn-tutorial that seems to work (using clone_preserving_field_list). You could try diff'ing it with yours.


I had to preserve `ingress_port` so it would be available in the assignment to `hdr.cpu_in.ingress_port` in EgressPipeImpl.

-Bill

Sergio Gutierrez

unread,
Oct 21, 2022, 5:53:08 PM10/21/22
to William Fisher, p4-dev, andy.fi...@gmail.com
Thanks William and Andy for your indications.

Taking advantage of the file that William shared, I could detect my problem. I was omitting the assignment of the ingress_port field of the local_metadata structure in the start state of the parser (Line 223 of William's code). By adjusting that, I could fix my problem and now it works fine.

Thanks again for your help and attention.

Best regards,
--
Sergio Gutiérrez
Reply all
Reply to author
Forward
0 new messages