On Sat, 29 Oct 2016 15:58:55 +0200, Jiri Pirko wrote: > Sat, Oct 29, 2016 at 02:09:32PM CEST, tg...@suug.ch wrote: > >On 10/29/16 at 01:28pm, Jiri Pirko wrote: > >> Sat, Oct 29, 2016 at 01:15:48PM CEST, tg...@suug.ch wrote: > >> >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: > > > >> 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. > > > >[...] > > > >> >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. > > > >> >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.
