netdev - Re: 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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 1 Nov 2016 07:57:05 -0400
From:   Jamal Hadi Salim <jhs@...atatu.com>
To:     Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org
Cc:     davem@...emloft.net, tgraf@...g.ch, 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: Re: Let's do P4


I am in travel mode so havent read the huge blast of
emails (and i am probably taking this email out of
the already discussed topics). I will try to catchup later.

Simple question (same chat I had with Prem at netdev1.2):
What is it that can be expressed by P4 that cant be expressed
with the (userspace) tc grammar? If any i would say the diff
is very small.
Is there something we need to add to kernel tc that will complete
the policy graph needed to express a P4 context?
Essentially if one can express the tc policies with p4 DSL then
that could become another frontend to tc (and a p4 component could
be implemented in classic tc action/classifier or ebpf).

I think trying to express p4 at the coarse granularity it offers
using ebpf is challenging.

cheers,
jamal

On 16-10-29 03:53 AM, Jiri Pirko wrote:
> 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
>