On Sat, 29 Oct 2016 15:58:55 +0200, Jiri Pirko wrote:

Sat, Oct 29, 2016 at 02:09:32PM CEST, tgraf@suug.ch wrote:

quoted

On 10/29/16 at 01:28pm, Jiri Pirko wrote:  

quoted

Sat, Oct 29, 2016 at 01:15:48PM CEST, tgraf@suug.ch wrote:  

quoted

So given the SKIP_SW flag, the in-kernel compiler is optional anyway.
Why even risk including a possibly incomplete compiler? Older kernels
must be capable of running along newer hardware as long as eBPF can
represent the software path. Having to upgrade to latest and greatest
kernels is not an option for most people so they would simply have to
fall back to SKIP_SW and do it in user space anyway.  

The thing is, if we needo to offload something, it needs to be
implemented in kernel first. Also, I believe that it is good to have
in-kernel p4 engine for testing and development purposes.  

You lost me now :-) In an earlier email you said:
 

quoted

It can be the other way around. The p4>ebpf compiler won't be complete
at the beginning so it is possible that HW could provide more features.
I don't think it is a problem. With SKIP_SW and SKIP_HW flags in TC,
the user can set different program to each. I think in real life, that
would be the most common case anyway.  

If you allow to SKIP_SW and set different programs each to address
this, then how is this any different.

I completely agree that kernel must be able to provide the same
functionality as HW with optional additional capabilities on top so
the HW can always bail out and punt to SW.

[...]
 

quoted

quoted

I'm not seeing how either of them is more or less variable. The main
difference is whether to require configuring a single cls with both
p4ast + bpf or two separate cls, one for each. I'd prefer the single
cls approach simply because it is cleaner wither regard to offload
directly off bpf vs off p4ast.  

That's the bundle that you asked me to forget earlier in this email? :)  

I thought you referred to the "store in same object file" as bundle.
I don't really care about that. What I care about is a single way to
configure this that works for both ASIC and non-ASIC hardware.
 

quoted

quoted

My main point is to not include a IR to eBPF compiler in the kernel
and let user space handle this instead.  

It we do it as you describe, we would be using 2 different APIs for
offloaded and non-offloaded path. I don't believe it is acceptable as
the offloaded features has to have kernel implementation. Therefore, I
believe that p4ast as a kernel API is the only possible option.  

Yes, the kernel has the SW implementation in eBPF. I thought that is
what you propose as well. The only difference is whether to generate
that eBPF in kernel or user space.

Not sure I understand the multiple APIs point for offload vs
non-offload. There is a single API: tc. Both models require the user
to provide additional metadata to allow programming ASIC HW: p4ast
IR or whatever we agree on.  

If you do p4>ebpf in userspace, you have 2 apis:
1) to setup sw (in-kernel) p4 datapath, you push bpf.o to kernel
2) to setup hw p4 datapath, you push program.p4ast to kernel

Those are 2 apis. Both wrapped up by TC, but still 2 apis.

What I believe is correct is to have one api:
1) to setup sw (in-kernel) p4 datapath, you push program.p4ast to kernel
2) to setup hw p4 datapath, you push program.p4ast to kernel

In case of 1), the program.p4ast will be either interpreted by new p4
interpreter, of translated to bpf and interpreted by that. But this
translation code is part of kernel.

Option 3) use a well structured subset of eBPF as user space ABI ;)

In all seriousness, user space already has to have some knowledge about
the underlaying hardware today with different vendors picking different
TC classifiers for offload.  So I humbly agree that 2 APIs may be
acceptable here.