Wed, Nov 02, 2016 at 04:22:50PM CET, john.fastab...@gmail.com wrote: [...]
>>> >>> What is your compilerA? Is that part of tc in user space? Maybe linked >> >> It is something that transforms original p4 source to some intermediate >> form, easy to be processed by in-kernel compilers. >> >> >>> against LLVM lib, for example? If you really want some sw path, can't tc >>> do this transparently from user space instead when it gets a netlink error >>> that it cannot get offloaded (and thus switch internally to f_bpf's loader)? >> >> In real life, user will most probably use p4 for hw programming, but the >> sw fallback will be done in bpf directly. In that case, he would use >> cls_bfp SKIP_HW >> cls_p4 SKIP_SW >> >> But in order to allow cls_p4 offloading to hw, we need in-kernel >> interpreter. That is purpose of compilerB to take agvantage of bpf, but >> the in-kernel interpreter could be implemented differently. >> > >But this is the issue. We openly acknowledge it wont actually be used. >We have multiple user space compilers that generate at least half way >reasonable ebpf code that is being used in real deployments and >works great for testing. This looks like pure overhead to satisfy this >hw/sw parity checkbox and I can't see why anyone would use it or even >maintain it. Looks like a checkbox and I like to avoid useless work that >is likely to bit rot. That's how it works I'm afraid, unless something changed from the last time we discussed this. Without in-kernel implementation, it's a bypass. Dave?
