On Mon, 7 Oct 2019 at 17:43, Edward Cree <ecree@xxxxxxxxxxxxxx> wrote: > > I might be being naïve, but it doesn't sound more painful than is normal > for userland. I mean, what operations have you got- > * create/destroy map (maybe, see above) > * load prog (pass it an fd from which it can read an ELF, and more fds > for the maps it uses. Everything else, e.g. BTFs, can just live in the > ELF.) > * destroy prog > * bind prog to hook (admittedly there's a long list of hooks, but this is > only to cover the XDP ones, so basically we just have to specify > interface and generic/driver/hw) > -that doesn't seem like it presents great difficulties? Sure, but this is the simplest, not necessarily realistic use case. There is a reason that libbpf has the API it has. For example, we patch our eBPF before loading it. I'm sure there are other complications, which is why I prefer to keep loading my own programs. > No, I'm talking about doing a linker step (using the 'full-blown calls' > _within_ an eBPF program that Alexei added a few months back) before the > program is submitted to the kernel. So the BPF_CALL|BPF_PSEUDO_CALL insn > gets JITed to a direct call. Ah, I see. I'm not sure whether this restriction has been lifted, but those calls are incompatible with tail calls. So we wouldn't be able to use this. > OK, but in that case xdpd isn't evidence that the "loader" approach doesn't > work, so I still think it should be tried before we go to the lengths of > pushing something into the kernel (that we then have to maintain forever). Maybe this came across the wrong way, I never said it is. Merely that it's the status quo we'd like to move away from. If we can achieve that in userspace, great. Lorenz -- Lorenz Bauer | Systems Engineer 6th Floor, County Hall/The Riverside Building, SE1 7PB, UK www.cloudflare.com
