netdev - Let's do P4

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-next>] [day] [month] [year] [list]

Message-ID: <20161029075328.GB1692@nanopsycho.orion>
Date:   Sat, 29 Oct 2016 09:53:28 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     netdev@...r.kernel.org
Cc:     davem@...emloft.net, tgraf@...g.ch, jhs@...atatu.com,
        roopa@...ulusnetworks.com, john.fastabend@...il.com,
        jakub.kicinski@...ronome.com, simon.horman@...ronome.com,
        ast@...nel.org, daniel@...earbox.net, prem@...efootnetworks.com,
        hannes@...essinduktion.org, jbenc@...hat.com, tom@...bertland.com,
        mattyk@...lanox.com, idosch@...lanox.com, eladr@...lanox.com,
        yotamg@...lanox.com, nogahf@...lanox.com, ogerlitz@...lanox.com,
        linville@...driver.com, andy@...yhouse.net, f.fainelli@...il.com,
        dsa@...ulusnetworks.com, vivien.didelot@...oirfairelinux.com,
        andrew@...n.ch, ivecera@...hat.com
Subject: Let's do P4

Hi all.

The network world is divided into 2 general types of hw:
1) network ASICs - network specific silicon, containing things like TCAM
   These ASICs are suitable to be programmed by P4.
2) network processors - basically a general purpose CPUs
   These processors are suitable to be programmed by eBPF.

I believe that by now, the most people came to a conclusion that it is
very difficult to handle both types by either P4 or eBPF. And since
eBPF is part of the kernel, I would like to introduce P4 into kernel
as well. Here's a plan:

1) Define P4 intermediate representation
   I cannot imagine loading P4 program (c-like syntax text file) into
   kernel as is. That means that as the first step, we need find some
   intermediate representation. I can imagine someting in a form of AST,
   call it "p4ast". I don't really know how to do this exactly though,
   it's just an idea.

   In the end there would be a userspace precompiler for this:
   $ makep4ast example.p4 example.ast

2) Implement p4ast in-kernel interpreter 
   A kernel module which takes a p4ast and emulates the pipeline.
   This can be implemented from scratch. Or, p4ast could be compiled
   to eBPF. I know there are already couple of p4>eBPF compilers.
   Not sure how feasible it would be to put this compiler in kernel.

3) Expose the p4ast in-kernel interpreter to userspace
   As the easiest way I see in to introduce a new TC classifier cls_p4.

   This can work in a very similar way cls_bpf is:
   $ tc filter add dev eth0 ingress p4 da ast example.ast

   The TC cls_p4 will be also used for runtime table manipulation.

4) Offload p4ast programs into hardware
   The same p4ast program representation will be passed down
   to drivers via existing TC offloading way - ndo_setup_tc.
   Drivers will then parse it and setup the hardware
   accordingly. Driver will also have possibility to error out
   in case it does not support some requested feature.

Thoughts? Ideas?

Thanks,
	Jiri