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
