On Wed, Oct 9, 2019 at 12:12 PM Samudrala, Sridhar
[off-list ref] wrote:

quoted

quoted

    34.57%  xdpsock          xdpsock           [.] main
    17.19%  ksoftirqd/1      [kernel.vmlinux]  [k] ___bpf_prog_run
    13.12%  xdpsock          [kernel.vmlinux]  [k] ___bpf_prog_run

That must be a bad joke.
The whole patch set is based on comparing native code to interpreter?!
It's pretty awesome that interpreter is only 1.5x slower than native x86.
Just turn the JIT on.

Thanks Alexei for pointing out that i didn't have JIT on.
When i turn it on, the performance improvement is a more modest 1.5x
with rxdrop and 1.2x with l2fwd.

I want to see perf reports back to back with proper performance analysis.

quoted

Obvious Nack to the patch set.

Will update the patchset with the right performance data and address
feedback from Bjorn.
Hope you are not totally against direct XDP approach as it does provide
value when an AF_XDP socket is bound to a queue and a HW filter can
direct packets targeted for that queue.

I used to be in favor of providing "prog bypass" for af_xdp,
because of anecdotal evidence that it will make af_xdp faster.
Now seeing the numbers and the way they were collected
I'm against such bypass.
I want to see hard proof that trivial bpf prog is actually slowing things down
before reviewing any new patch sets.