netdev - Re: [PATCH net-next v16 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]

Date: Tue, 11 Jun 2024 07:21:07 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Jamal Hadi Salim <jhs@...atatu.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, tomasz.osinski@...el.com,
 jiri@...nulli.us, xiyou.wangcong@...il.com, davem@...emloft.net,
 edumazet@...gle.com, pabeni@...hat.com, vladbu@...dia.com,
 horms@...nel.org, khalidm@...dia.com, toke@...hat.com, victor@...atatu.com,
 pctammela@...atatu.com, Vipin.Jain@....com, dan.daly@...el.com,
 andy.fingerhut@...il.com, chris.sommers@...sight.com, mattyk@...dia.com,
 bpf@...r.kernel.org, Jonathan Corbet <corbet@....net>
Subject: Re: [PATCH net-next v16  00/15] Introducing P4TC (series 1)

Since the inevitable LWN article has been written, let me put more
detail into what I already mentioned here:

https://lore.kernel.org/all/20240301090020.7c9ebc1d@kernel.org/

for the benefit of non-networking people.

On Wed, 10 Apr 2024 10:01:26 -0400 Jamal Hadi Salim wrote:
> P4TC builds on top of many years of Linux TC experiences of a netlink
> control path interface coupled with a software datapath with an equivalent
> offloadable hardware datapath.

The point of having SW datapath is to provide a blueprint for the
behavior. This is completely moot for P4 which comes as a standard.

Besides we already have 5 (or more) flow offloads, we don't need
a 6th, completely disconnected from the existing ones. Leaving
users guessing which one to use, and how they interact.

In my opinion, reasonable way to implement programmable parser for
Linux is:

 1. User writes their parser in whatever DSL they want
 2. User compiles the parser in user space
   2.1 Compiler embeds a representation of the graph in the blob
 3. User puts the blob in /lib/firmware
 4. devlink dev $dev reload action parser-fetch $filename
 5. devlink loads the file, parses it to extract the representation
    from 2.1, and passes the blob to the driver
   5.1 driver/fw reinitializes the HW parser
   5.2 user can inspect the graph by dumping the common representation
       from 2.1 (via something like devlink dpipe, perhaps)
 6. The parser tables are annotated with Linux offload targets (routes,
    classic ntuple, nftables, flower etc.) with some tables being left
    as "raw"* (* better name would be great)
 7. ethtool ntuple is extended to support insertion of arbitrary rules
    into the "raw" tables
 8. The other tables can only be inserted into using the subsystem they
    are annotated for

This builds on how some devices _already_ operate. Gives the benefits
of expressing parser information and ability to insert rules for
uncommon protocols also for devices which are not programmable.
And it uses ethtool ntuple, which SW people actually want to use.

Before the tin foil hats gather - we have no use for any of this at
Meta, I'm not trying to twist the design to fit the use cases of big
bad hyperscalers.