On Tue, Apr 05, 2016 at 12:04:39AM +0200, Thomas Graf wrote: > On 04/04/16 at 01:00pm, Alexei Starovoitov wrote: > > Exactly. That the most important part of this rfc. > > Right now redirect to different queue, batching, prefetch and tons of > > other code are mising. We have to plan the whole project, so we can > > incrementally add features without breaking abi. > > So new IFLA, xdp_metadata struct and enum for bpf return codes are > > the main things to agree on. > > +1 > This is the most important statement in this thread so far. A plan > that gets us from this RFC series to a functional forwarding engine > with redirect and load/write is essential. [...]
exactly. I think the next step 2 is to figure out the redirect return code and 'rewiring' of the rx dma buffer into tx ring and auto-batching. As this rfc showed even when using standard page alloc/free the peformance is hitting 10Gbps hw limit and not being cpu bounded, so recycling of the pages and avoiding map/unmap will come at step 3. Batching is necessary even for basic redirect, since ringing doorbell for every tx buffer is not an option. > [...] I would really like to see a common set of helpers which > applies to both cls_bpf and phys_dev. Given the existing skb based > helpers cannot be overloaded, at least the phys_dev helpers should > be made to work in cls_bpf context as well to allow for some > portability. Otherwise we'll end up with half a dozen flavours of > BPF which are all incompatible. The helpers can be 'overloaded'. In my upcoming patches for bpf+tracepoints the bpf_perf_event_output() helper is different depending on program type (kprobe vs tracepoint), but logically it looks exactly the same from program point of view and BPF_FUNC_id is reused. So for cls_bpf vs bpf_phys_dev we can have the same bpf_csum_diff() helper which will have different internal implementation depending on program type.
