cpf_ran.p4 exit statements for v1model use

[hesingh]

I see one exit statement below:

https://github.com/P4ELTE/use_cases/blob/master/p4-16/bst/cpf_ran.p4#L170

The exit statement causes exit out of RANIngress control. But the RANIngressDeparser still runs and emits the packet. Sorry, I don't understand if the packet is dropped, the deparser should not emit anything.

[jafingerhut]

An exit statement in a P4 control means that the enclosing control is immediately exited. It is up to the definition of the architecture whether other parsers or controls are executed on the packet later.

In TNA, the ingress deparser control is always executed on a packet after the ingress control is finished executing, regardless of whether the ingress control finishes by executing an exit statement, or some other means.

Whether a packet is dropped or not depends upon the values of TNA output metadata field values when the ingress control is finished executing.

[gpz76]

Hi Hemant, There are 4 exit statements in RANIngress. 2 of them are called after calling drop() which sets the corresponding metadata to drop the packet in the deparser. 2 of them are called when all actions are done and we need to send the packet to a specified port – set by the send() action. I don’t see a problem here. If you do, please specify the exact line number. Thx! From: Hemant Singh ***@***.***> Sent: Sunday, June 6, 2021 8:35 PM To: P4ELTE/use_cases ***@***.***> Cc: Subscribed ***@***.***> Subject: [P4ELTE/use_cases] cpf_ran.p4 exit statements for v1model use (#3) I see one exit statement below: https://github.com/P4ELTE/use_cases/blob/master/p4-16/bst/cpf_ran.p4#L170<https://protect2.fireeye.com/v1/url?k=6b8fc0a4-3414f9a1-6b8f803f-86d2114eab2f-a8f4d6fc8d685149&q=1&e=8605bb2e-206e-40bd-8bb1-09570354a665&u=https%3A%2F%2Fgithub.com%2FP4ELTE%2Fuse_cases%2Fblob%2Fmaster%2Fp4-16%2Fbst%2Fcpf_ran.p4%23L170> The exit statement causes exit out of RANIngress control. But the RANIngressDeparser still runs and emits the packet. Sorry, I don't understand if the packet is dropped, the deparser should not emit anything. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<https://protect2.fireeye.com/v1/url?k=329edc96-6d05e593-329e9c0d-86d2114eab2f-01fcc8f50bcf1552&q=1&e=8605bb2e-206e-40bd-8bb1-09570354a665&u=https%3A%2F%2Fgithub.com%2FP4ELTE%2Fuse_cases%2Fissues%2F3>, or unsubscribe<https://protect2.fireeye.com/v1/url?k=698b28f9-361011fc-698b6862-86d2114eab2f-ff2dfdc6ded529ac&q=1&e=8605bb2e-206e-40bd-8bb1-09570354a665&u=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FADLHW72TFXTPLYHU2WD4FKLTRO5WTANCNFSM46GHS6SA>.

[hesingh]

If the v1model.p4 is used for cpf_ran.p4, this model has no metadata in deparser. So the deparser has no means to check if 'meta.drop == 1' and the deparser emits the hdr. v1model P4 code should invalidate all headers in hdr for drop case and then the deparser won't emit anything.

[jafingerhut]

@hesingh In v1model in BMv2 at least (which is the only v1model architecture implementation I know of), if the packet is dropped in ingress, the deparser never executes. It doesn't get enqueued in the traffic manager, even.

[hesingh]

Wow, @jafingerhut I didn't know that. thanks. We can close this issue.