On Wed, Oct 9, 2019 at 12:12 PM Samudrala, Sridhar <sridhar.samudrala@xxxxxxxxx> wrote: > >> 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. > > > > 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.
