On 07/10/2019 18:12, Lorenz Bauer wrote: > 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. Any reason why you can't have the client patch the eBPF (possibly with libbpf) before supplying the patched object file to the loaderiser? >> 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. Indeed, tail calls don't fit into my scheme, because being a tail-call from the subprogram doesn't make you a tail-call from the dispatcher program. But AIUI tail calls are only in use today in various work-arounds for the lack of proper linking (including dynamic linking). If we supported that, would you still need them? >> 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. No, you didn't (sorry). Toke somewhat implied it, which is what I was responding to there. -Ed
