Trying to sum up the main points of the discussion. Two main issues:
1) Allowing to load an XDP/eBPF program what use return codes not compatible with the drivers. 2) Default dropping at this level make is hard to debug / no-metrics. To solve issue #1, I proposed defining a fallback semantics. I guess, people didn't like that semantics. The only other solution I see, is to NOT-allow programs to be loaded if they want to use return-codes/features not supported by the driver, e.g reject XDP programs. Given we cannot automatic deduct used return codes (if prog is table driven) then we need some kind of versioning or feature codes. Could this be modeled after NIC "features"? I guess this could also help HW offload engines, if eBPF programs register/annotate their needed capabilities upfront? For issue #2 (default drop): If the solution for issue #1 is to only loaded compatible programs, then I agree that unknown return code should default to drop. For debug-ability, it should be easy to extend the call bpf_warn_invalid_xdp_action() to log more information for debugging purposes. Which for performance/DoS reasons should be off by default. -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat Author of http://www.iptv-analyzer.org LinkedIn: http://www.linkedin.com/in/brouer
