PSA egress behavior


I am trying to understand the egress part of the PSA.
So I am using p4-dpdk-target and I have written a simple bounce-back program that switches dst and src mac addresses.
To do that I am parsing the packet headers in the Ingress Parser block and then on the Ingress block, I am switching the fields.

My question comes when I move this procedure from the ingress to the egress blocks: So I am parsing in the Egress Parser block and switching the fields in the Egress block.
Then the fields do not change.

I understand that three different things could happen:

  1. Egress is not used for headers manipulation. (So what is it used for?)
  2. I also have to change some specific metadata. (Which are they?)
  3. This is not the expected behavior, it is a p4-dpdk-target bug.
  4. ???

Thank you!

PSA egress SHOULD be usable for packet modifications.

It is possible that the DPDK back end implementation of PSA does not support this. I can find out and report back here.

If you can publish your P4 program where you tried to modify the packet header in egress, but it failed, to some place with a link here, that may be helpful.

1 Like

You can find the program:

As you can see the ingress and egress blocks are identical (lines 41-43 are commented out)

Thank you!

Hi @kesnar ,

I just wanted to add some (possibly) interesting information. There are some specific design choices in PSA (not related to your current question though) that you might find the answers for if you check the specification. If you already checked it, then sorry!.

D. Appendix: Rationale for design

D.1. Why egress processing?

D.2. No output port change during egress

D.3. Ingress deparser and egress parser


1 Like

I checked with the DPDK developers, and they pointed out that this is actually documented in the README for the DPDK back end to p4c, in this paragraph, which you can find here: p4c/ at main · p4lang/p4c · GitHub

“Currently, programs written for DPDK target should limit the functionality in Ingress blocks, in case non empty Egress blocks are present it will be ignored by default unless Hidden temporary option --enableEgress used. When egress block support gets added to the DPDK target, and compiler can generate separate spec file for non empty ingress and egress blocks then option --enableEgress will be removed.”

I suggested they add a warning or error message if a P4 program is compiled for the DPDK PSA back end, if the egress parser, control, or deparser were “not empty”, and they have added such an item to their list of things to do, to make it more obvious when this occurs.