netdev - Re: Hardware Offload discussion WAS(Re: [PATCH net-next v12 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240304121812.450dda4c@kernel.org>
Date: Mon, 4 Mar 2024 12:18:12 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Jamal Hadi Salim <jhs@...atatu.com>
Cc: Tom Herbert <tom@...anda.io>, John Fastabend <john.fastabend@...il.com>,
 "Singhai, Anjali" <anjali.singhai@...el.com>, Paolo Abeni
 <pabeni@...hat.com>, Linux Kernel Network Developers
 <netdev@...r.kernel.org>, "Chatterjee, Deb" <deb.chatterjee@...el.com>,
 "Limaye, Namrata" <namrata.limaye@...el.com>, Marcelo Ricardo Leitner
 <mleitner@...hat.com>, "Shirshyad, Mahesh" <Mahesh.Shirshyad@....com>,
 "Jain, Vipin" <Vipin.Jain@....com>, "Osinski, Tomasz"
 <tomasz.osinski@...el.com>, Jiri Pirko <jiri@...nulli.us>, Cong Wang
 <xiyou.wangcong@...il.com>, "David S . Miller" <davem@...emloft.net>, Eric
 Dumazet <edumazet@...gle.com>, Vlad Buslov <vladbu@...dia.com>, Simon
 Horman <horms@...nel.org>, Khalid Manaa <khalidm@...dia.com>, Toke
 Høiland-Jørgensen <toke@...hat.com>, Daniel Borkmann
 <daniel@...earbox.net>, Victor Nogueira <victor@...atatu.com>, "Tammela,
 Pedro" <pctammela@...atatu.com>, "Daly, Dan" <dan.daly@...el.com>, Andy
 Fingerhut <andy.fingerhut@...il.com>, "Sommers, Chris"
 <chris.sommers@...sight.com>, Matty Kadosh <mattyk@...dia.com>, bpf
 <bpf@...r.kernel.org>
Subject: Re: Hardware Offload discussion WAS(Re: [PATCH net-next v12 00/15]
 Introducing P4TC (series 1)

On Sun, 3 Mar 2024 14:04:11 -0500 Jamal Hadi Salim wrote:
> > At
> > this point in its lifetime, eBPF had far more examples of real world
> > use cases publically available. That being said, there's nothing
> > unique about P4 supporting the network calculator. We could just as
> > easily write this in eBPF (either plain C or P4)  and "offload" it to
> > an ARM core on a SmartNIC.  
> 
> With current port speeds hitting 800gbps you want to use Arm cores as
> your offload engine?;-> Running the generated ebpf on the arm core is
> a valid P4 target.  i.e there is no contradiction.
> Note: P4 is a DSL specialized for datapath definition; it is not a
> competition to ebpf, two different worlds. I see ebpf as an
> infrastructure tool, nothing more.

I wonder how much we're benefiting of calling this thing P4 and how
much we should focus on filling in the tech gaps.
Exactly like you said, BPF is not competition, but neither does 
the kernel "support P4", any more than it supports bpftrace and:

$ git grep --files-with-matches bpftrace
Documentation/bpf/redirect.rst
tools/testing/selftests/bpf/progs/test_xdp_attach_fail.c

Filling in tech gaps would also help DPP, IDK how much DPP is based 
or using P4, neither should I have to care, frankly :S