Re: XDP and AF_XDP performance comparison

["Toke Høiland-Jørgensen" <toke@redhat.com>]

Federico Parola <federico.parola@polito.it> writes:

> Dear all,
> I would like to share with this community a draft I recently wrote [1] 
> on the performance comparison of XDP and AF_XDP packet processing.
> In the paper we found some interesting and unexpected results 
> (especially related to the impact of addressed memory on the performance 
> of the two technologies) and tried to envision a combined use of the two 
> technologies, especially to tackle the poor performance of re-injecting 
> packets into the kernel from user space to leverage the TCP/IP stack.
> Any comment and suggestion from this community or any type of joint 
> work/collaboration would be very appreciated.

Hi Federico

Thank you for the link! All in all I thought it was a nicely done
performance comparison.

One thing that might be interesting would be to do the same comparison
on a different driver. A lot of the performance details you're
discovering in this paper boils down to details about how the driver
data path is implemented. For instance, it's an Intel-specific thing
that there's a whole separate path for zero-copy AF_XDP. Any plans to
replicate the study using, say, an mlx5-based NIC?

Also, a couple of comments on details:

- The performance delta you show in Figure 9 where AF_XDP is faster at
  hair-pin forwarding than XDP was a bit puzzling; the two applications
  should basically be doing the same thing. It seems to be because the
  i40e driver converts the xdp_buff struct to an xdp_frame before
  transmitting it out the interface again:

  https://elixir.bootlin.com/linux/latest/source/drivers/net/ethernet/intel/i40e/i40e_txrx.c#L2280

- It's interesting that userspace seems to handle scattered memory
  accesses over a large range better than kernel-space. It would be
  interesting to know why; you mention you're leaving this to future
  studies, any plans of following up and trying to figure this out? :)


Finally, since you seem to have your tests packaged up nicely, do you
think it would be possible to take (some of) them and turn them into a
kind of "performance CI" test suite, that can be run automatically, or
semi-automatically to catch future performance regressions in the XDP
stack? Such a test suite would be pretty great to have so we can avoid
the "death by a thousand paper cuts" type of gradual performance
degradation as we add new features...

-Toke