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. 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 :)
