Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

eBPF backend doesn't generate emit in if statement correctly #5026

Open
vbnogueira opened this issue Nov 22, 2024 · 2 comments
Open

eBPF backend doesn't generate emit in if statement correctly #5026

vbnogueira opened this issue Nov 22, 2024 · 2 comments
Labels
bug This behavior is unintended and should be fixed. ebpf Topics related to the eBPF back end p4tc Topics related to the P4-TC back end

Comments

@vbnogueira
Copy link
Contributor

In the eBPF backend, if the user attempts to write an emit inside an if statement in the deparser's apply block, the generated code is semantically different from the original. For example the following snippet:

control IngressDeparserImpl(packet_out packet,
                            out empty_t clone_i2e_meta,
                            out empty_t resubmit_meta,
                            out empty_t normal_meta,
                            inout headers hdr,
                            in metadata meta,
                            in psa_ingress_output_metadata_t istd)
{
    apply {
        if (meta.mymd == 0) {
            packet.emit(hdr.ethernet);
        }


        packet.emit(hdr.ipv4);
    }   
}

Will generate and empty if statement:

if (meta->mymd == 0) { 
;            }

and completely ignore the emit for the ethernet header

Below is the link to a tarball which has both the P4 program used to reproduce the issue and the generated C eBPF file that will illustrate the bug:
emit-bug.tar.gz

The command used to compile was:

./p4c-ebpf --arch psa emit-bug.p4 -o emit-bug.c

I compiled p4c with commit 8273608

@fruffy fruffy added bug This behavior is unintended and should be fixed. ebpf Topics related to the eBPF back end labels Nov 22, 2024
@fruffy
Copy link
Collaborator

fruffy commented Nov 22, 2024

Just a heads-up: the eBPF back end currently does not have an active maintainer who would take on this bug.

@vbnogueira
Copy link
Contributor Author

vbnogueira commented Nov 22, 2024

Just a heads-up: the eBPF back end currently does not have an active maintainer who would take on this bug.

Ohh, I see
From what I understood, the tc backend uses the same deparser code and shares the same bug
So we can make it also a tc backend issue

@jafingerhut jafingerhut added the p4tc Topics related to the P4-TC back end label Nov 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This behavior is unintended and should be fixed. ebpf Topics related to the eBPF back end p4tc Topics related to the P4-TC back end
Projects
None yet
Development

No branches or pull requests

3 participants