On Tue, Nov 26, 2019 at 12:35:14PM -0800, Jakub Kicinski wrote: > > I'd appreciate if others could chime in. The performance improvements are quite appealing. In general offloading from higher layers into lower layers is necessary long term. But the approach taken by patches 15 and 17 is a dead end. I don't see how it can ever catch up with the pace of bpf development. As presented this approach works for the most basic programs and simple maps. No line info, no BTF, no debuggability. There are no tail_calls either. I don't think I've seen a single production XDP program that doesn't use tail calls. Static and dynamic linking is coming. Wraping one bpf feature at a time with virtio api is never going to be complete. How FDs are going to be passed back? OBJ_GET_INFO_BY_FD ? OBJ_PIN/GET ? Where bpffs is going to live ? Any realistic XDP application will be using a lot more than single self contained XDP prog with hash and array maps. It feels that the whole sys_bpf needs to be forwarded as a whole from guest into host. In case of true hw offload the host is managing HW. So it doesn't forward syscalls into the driver. The offload from guest into host is different. BPF can be seen as a resource that host provides and guest kernel plus qemu would be forwarding requests between guest user space and host kernel. Like sys_bpf(BPF_MAP_CREATE) can passthrough into the host directly. The FD that hosts sees would need a corresponding mirror FD in the guest. There are still questions about bpffs paths, but the main issue of one-feature-at-a-time will be addressed in such approach. There could be other solutions, of course.
