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

Add --xdp2tc compiler flag for eBPF backend #3187

Merged
merged 5 commits into from
Apr 8, 2022
Merged

Conversation

osinstom
Copy link
Contributor

@osinstom osinstom commented Apr 7, 2022

This PR makes the XDP2TC mode configurable. The XDP2TC mode determines how the metadata (containing original EtherType) is passed from XDP up to TC. This is needed because we discovered that the default meta mode using bpf_xdp_adjust_meta() is not supported by some NIC drivers. In such a case, the entire PSA implementation for eBPF does not work. This PR adds two alternative modes: head and cpumap that can be used to work around the NIC limitations.

osinstom and others added 2 commits April 7, 2022 19:15
Co-authored-by: Mateusz Kossakowski <mateusz.kossakowski@orange.com>
Co-authored-by: Jan Palimąka <jan.palimaka@orange.com>
}
return true;
},
"[psa only] Select the mode used to pass metadata from XDP to TC.");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs a longer description, no one will guess the possible choices.

metadata. In this mode, the helper must be invoked twice - in the XDP helper program to append the metadata and in
the TC Ingress to strip the metadata out of a packet. We also introduce the third mode - `cpumap`, which is an experimental features and should be used carefully.
The `cpumap` assumes that the single CPU core handles a packet in the run-to-completion mode from XDP up to the TC layer
(in other words, for a given packet, the CPU core running the TC program is the same as the one for XDP). If the above
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wonder whether you can check this somehow dynamically and abort if it's not true.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really. We could check if, for instance, RPS/RFS is enabled, but still a P4 program may be compiled on a remote machine (other than the one where a compiled eBPF program is deployed).

@osinstom
Copy link
Contributor Author

osinstom commented Apr 8, 2022

@mbudiu-vmw I've fixed cpplint and synced with main to avoid Fedora build issues. Should be ready to merge.

@mihaibudiu mihaibudiu merged commit ab8a4e7 into p4lang:main Apr 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants