Re: [PATCH net-next v13 00/15] Introducing P4TC (series 1)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Apr 2, 2024 at 5:43 PM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote:
>
> 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>
>

Thanks Toke!

> [...]
>
> > 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?

I like it. Note, we do generate the P4 code embedded as comments in
the eBPF code today.
We'll look into it ;->

cheers,
jamal





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux