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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Tue, 2 Apr 2024 19:13:36 -0400
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Toke Høiland-Jørgensen <toke@...hat.com>
Cc: netdev@...r.kernel.org, deb.chatterjee@...el.com, anjali.singhai@...el.com, 
	namrata.limaye@...el.com, tom@...anda.io, mleitner@...hat.com, 
	Mahesh.Shirshyad@....com, Vipin.Jain@....com, tomasz.osinski@...el.com, 
	jiri@...nulli.us, xiyou.wangcong@...il.com, davem@...emloft.net, 
	edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com, vladbu@...dia.com, 
	horms@...nel.org, khalidm@...dia.com, daniel@...earbox.net, 
	victor@...atatu.com, pctammela@...atatu.com, dan.daly@...el.com, 
	andy.fingerhut@...il.com, chris.sommers@...sight.com, mattyk@...dia.com, 
	bpf@...r.kernel.org
Subject: Re: [PATCH net-next v13 00/15] Introducing P4TC (series 1)

On Tue, Apr 2, 2024 at 5:43 PM Toke Høiland-Jørgensen <toke@...hat.com> wrote:
>
> Jamal Hadi Salim <jhs@...atatu.com> 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@...hat.com>
>

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