netdev - 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 for Android: free password hash cracker in your pocket

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

Message-ID: <20240301090020.7c9ebc1d@kernel.org>
Date: Fri, 1 Mar 2024 09:00:20 -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>, mleitner@...hat.com,
 Mahesh.Shirshyad@....com, 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>,
 edumazet@...gle.com, Vlad Buslov <vladbu@...dia.com>, horms@...nel.org,
 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@...il.com, "Sommers, Chris"
 <chris.sommers@...sight.com>, mattyk@...dia.com, bpf@...r.kernel.org
Subject: Re: [PATCH net-next v12 00/15] Introducing P4TC (series 1)

On Thu, 29 Feb 2024 19:00:50 -0800 Tom Herbert wrote:
> > I want to emphasize again these patches are about the P4 s/w pipeline
> > that is intended to work seamlessly with hw offload. If you are
> > interested in h/w offload and want to contribute just show up at the
> > meetings - they are open to all. The current offloadable piece is the
> > match-action tables. The P4 specs may change to include parsers in the
> > future or other objects etc (but not sure why we should discuss this
> > in the thread).
> 
> Pardon my ignorance, but doesn't P4 want to be compiled to a backend
> target? How does going through TC make this seamless?

+1

My intuition is that for offload the device would be programmed at
start-of-day / probe. By loading the compiled P4 from /lib/firmware.
Then the _device_ tells the kernel what tables and parser graph it's
got.

Plus, if we're talking about offloads, aren't we getting back into
the same controversies we had when merging OvS (not that I was around).
The "standalone stack to the side" problem. Some of the tables in the
pipeline may be for routing, not ACLs. Should they be fed from the
routing stack? How is that integration going to work? The parsing
graph feels a bit like global device configuration, not a piece of
functionality that should sit under sub-sub-system in the corner.