On 08/16, Stanislav Fomichev wrote: > On 08/15, Jakub Kicinski wrote: > > On Thu, 15 Aug 2019 08:21:00 -0700, Stanislav Fomichev wrote: > > > On 08/15, Toshiaki Makita wrote: > > > > On 2019/08/15 2:07, Stanislav Fomichev wrote: > > > > > On 08/13, Toshiaki Makita wrote: > > > > > > * Implementation > > > > > > > > > > > > xdp_flow makes use of UMH to load an eBPF program for XDP, similar to > > > > > > bpfilter. The difference is that xdp_flow does not generate the eBPF > > > > > > program dynamically but a prebuilt program is embedded in UMH. This is > > > > > > mainly because flow insertion is considerably frequent. If we generate > > > > > > and load an eBPF program on each insertion of a flow, the latency of the > > > > > > first packet of ping in above test will incease, which I want to avoid. > > > > > Can this be instead implemented with a new hook that will be called > > > > > for TC events? This hook can write to perf event buffer and control > > > > > plane will insert/remove/modify flow tables in the BPF maps (contol > > > > > plane will also install xdp program). > > > > > > > > > > Why do we need UMH? What am I missing? > > > > > > > > So you suggest doing everything in xdp_flow kmod? > > > You probably don't even need xdp_flow kmod. Add new tc "offload" mode > > > (bypass) that dumps every command via netlink (or calls the BPF hook > > > where you can dump it into perf event buffer) and then read that info > > > from userspace and install xdp programs and modify flow tables. > > > I don't think you need any kernel changes besides that stream > > > of data from the kernel about qdisc/tc flow creation/removal/etc. > > > > There's a certain allure in bringing the in-kernel BPF translation > > infrastructure forward. OTOH from system architecture perspective IMHO > > it does seem like a task best handed in user space. bpfilter can replace > > iptables completely, here we're looking at an acceleration relatively > > loosely coupled with flower. > Even for bpfilter I would've solved it using something similar: > iptables bypass + redirect iptables netlink requests to some > userspace helper that was registered to be iptables compatibility > manager. And then, again, it becomes a purely userspace problem. Oh, wait, isn't iptables kernel api is setsockopt/getsockopt? With the new cgroup hooks you can now try to do bpfilter completely in BPF 🤯 > The issue with UMH is that the helper has to be statically compiled > from the kernel tree, which means we can't bring in any dependencies > (stuff like libkefir you mentioned below). > > But I digress :-) > > > FWIW Quentin spent some time working on a universal flow rule to BPF > > translation library: > > > > https://github.com/Netronome/libkefir > > > > A lot remains to be done there, but flower front end is one of the > > targets. A library can be tuned for any application, without a > > dependency on flower uAPI. > > > > > But, I haven't looked at the series deeply, so I might be missing > > > something :-) > > > > I don't think you are :)
