On 2020-12-02 05:46, Alexei Starovoitov wrote: [...]
Sorry I don't like this check at all. It's too fragile. It will work for one hard coded program. It may work for something more real, but will break with minimal changes to the prog or llvm changes. How are we going to explain that fragility to users?
[...]
I haven't looked through all possible paths, but it feels very dangerous. The stack growth is big. Calling xsk_rcv from preempt_disabled and recursively calling into another bpf prog? That violates all stack checks we have in the verifier.
Fair points, and thanks for pointing them out. If the robustness (your first point) is improved, say via proper indirect jump support, the stack usage will still be a concern.
I see plenty of cons and not a single pro in this patch. 5% improvement for micro benchmark? That's hardly a justification.
It's indeed a ubench, and something that is mostly beneficial to AF_XDP. I'll go back to the drawing board and make sure the cons/pro balance is improved. Thanks for the feedback! Björn
