On 04/10/2019 09:09, Toke Høiland-Jørgensen wrote: > Having the mechanism be in-kernel makes solving these problems a lot > easier, because the kernel can be responsible for state management, and > it can enforce the chain call execution logic. I would argue this isn't mechanism, but rather policy, because the mechanism we already have is sufficient to express the policy. Enforcement is easily dealt with: you just don't give people the caps/ perms to load XDP programs directly, so the only way they can do it is via your loader (which you give them a socket or dbus or something to talk to). (Whereas your chain map doesn't really 'enforce' anything; anyone who can add themselves to the chain can also remove others.) Then state inspection happens by querying the loader; if we assume that the distro provided the central loader, then they can also include the query in their standard system-dump tools. Dynamic changes would just mean compiling a new dispatcher, then atomically replacing the old prog with the new (which we can already do), since the central loader daemon knows the call graph and can make changed versions easily. Centralisation is something that happens normally in userspace; just count how many daemons your favourite init system runs to administer system resources and multiplex requests. Probably we'd end up with one or two standard loaders and interfaces to them. In any case, it seems like XDP users in userspace still need to communicate with each other in order to update the chain map (which seems to rely on knowing where one's own program fits into it); you suggest they might communicate through the chain map itself, and then veer off into the weeds of finding race-free ways of doing that. This seems (to me) needlessly complex. Incidentally, there's also a performance advantage to an eBPF dispatcher, because it means the calls to the individual programs can be JITted and therefore be direct, whereas an in-kernel data-driven dispatcher has to use indirect calls (*waves at spectre*). > The fact that Lorenz et al are interested in this feature (even though > they are essentially already doing what you suggested, by having a > centralised daemon to manage all XDP programs), tells me that having > kernel support for this is the right thing to do. Maybe Lorenz could describe what he sees as the difficulties with the centralised daemon approach. In what ways is his current "xdpd" solution unsatisfactory? -Ed
