Jamal Hadi Salim <jhs@xxxxxxxxxxxx> writes: > This is the first patchset of two. In this patch we are submitting 15 which > cover the minimal viable P4 PNA architecture. > Please, if you want to discuss a slightly tangential subject like offload or > even your politics then start another thread with a different subject line. > The way you do it is to change the subject line to for example > "<Your New Subject here> (WAS: <original subject line here>)". > > In this cover letter i am restoring text i took out in V10 which stated "our > requirements". > > Martin, please look at patch 14 again. The bpf selftests for kfuncs is > sloted for series 2. Paolo, please take a look at 1, 3, 6 for the changes > you suggested. Marcelo, because we made changes to patch 14, I have > removed your reviewed-by. Can you please take another look at that patch? > > __Description of these Patches__ > > These Patches are constrained entirely within the TC domain with very tiny > changes made in patch 1-5. eBPF is used as an infrastructure component for > the software datapath and no changes are made to any eBPF code, only kfuncs > are introduced in patch 14. > > Patch #1 adds infrastructure for per-netns P4 actions that can be created on > as need basis for the P4 program requirement. This patch makes a small > incision into act_api. Patches 2-4 are minimalist enablers for P4TC and have > no effect on the classical tc action (example patch#2 just increases the size > of the action names from 16->64B). > Patch 5 adds infrastructure support for preallocation of dynamic actions > needed for P4. > > The core P4TC code implements several P4 objects. > 1) Patch #6 introduces P4 data types which are consumed by the rest of the > code > 2) Patch #7 introduces the templating API. i.e. CRUD commands for templates > 3) Patch #8 introduces the concept of templating Pipelines. i.e CRUD > commands for P4 pipelines. > 4) Patch #9 introduces the action templates and associated CRUD commands. > 5) Patch #10 introduce the action runtime infrastructure. > 6) Patch #11 introduces the concept of P4 table templates and associated > CRUD commands for tables. > 7) Patch #12 introduces runtime table entry infra and associated CU > commands. > 8) Patch #13 introduces runtime table entry infra and associated RD > commands. > 9) Patch #14 introduces interaction of eBPF to P4TC tables via kfunc. > 10) Patch #15 introduces the TC classifier P4 used at runtime. > > There are a few more patches not in this patchset that deal with externs, > test cases, etc. Unfortunately I don't have the bandwidth to review these in details ATM, but I think it makes sense to have P4 be a conceptual entity in TC, and using eBPF as the infrastructure to execute the programs. So, on that conceptual level only: Acked-by: Toke Høiland-Jørgensen <toke@xxxxxxxxxx> [...] > To summarize in presence of eBPF: The debugging idea is probably still > alive. One could dump, with proper tooling(bpftool for example), the > loaded eBPF code and be able to check for differences. But this is not the > interesting part. > The concept of going back from whats in the kernel to P4 is a lot more > difficult to implement mostly due to scoping of DSL vs general purpose. It > may be lost. We have been discussing ways to use BTF and embedding > annotations in the eBPF code and binary but more thought is required and we > welcome suggestions. One thought on this: I don't believe there's any strict requirement that the source lines in the "BTF lineinfo" information has to be C source code. So if the P4 compiler can relate the generated BPF instructions back to the original P4, couldn't it just embed the P4 program itself (in some suitable syntax) as the lineinfo? -Toke
