On 09/21/16 at 07:19am, Tom Herbert wrote: > certain design that because of constraints on one kernel interface. As > a kernel developer I want flexibility on how we design and implement > things!
Perfectly valid argument. I reviewed your ILA changes and did not object to them. > I think there are two questions that this patch set poses for the > community wrt XDP: > > #1: Should we allow alternate code to run in XDP other than BPF? > #2: If #1 is true what is the best way to implement that? > > If the answer to #1 is "no" then the answer to #2 is irrelevant. So > with this RFC I'm hoping we can come the agreement on questions #1. I'm not opposed to running non-BPF code at XDP. I'm against adding a linked list of hook consumers. Would anyone require to run XDP-BPF in combination ILA? Or XDP-BPF in combination with a potential XDP-nftables? We don't know yet I guess. Maybe exclusive access to the hook for one consumer as selected by the user is good enough. If that is not good enough: BPF (and potentially nftables in the future) could provide means to perform a selection process where a helper call can run another XDP prog or return a verdict to trigger another XDP prog. Definitely more flexible and faster than a linear list doing if, else if, else if, else if, ...
