Re: [PATCH v8 bpf-next 00/14] mvneta: introduce XDP multi-buffer support
From: Jesper Dangaard Brouer <hidden>
Date: 2021-04-18 16:18:24
Also in:
bpf
On Fri, 16 Apr 2021 16:27:18 +0200 Magnus Karlsson [off-list ref] wrote:
On Thu, Apr 8, 2021 at 2:51 PM Lorenzo Bianconi [off-list ref] wrote:quoted
This series introduce XDP multi-buffer support. The mvneta driver is the first to support these new "non-linear" xdp_{buff,frame}. Reviewers please focus on how these new types of xdp_{buff,frame} packets traverse the different layers and the layout design. It is on purpose that BPF-helpers are kept simple, as we don't want to expose the internal layout to allow later changes. For now, to keep the design simple and to maintain performance, the XDP BPF-prog (still) only have access to the first-buffer. It is left for later (another patchset) to add payload access across multiple buffers. This patchset should still allow for these future extensions. The goal is to lift the XDP MTU restriction that comes with XDP, but maintain same performance as before.
[...]
quoted
[0] https://netdevconf.info/0x14/session.html?talk-the-path-to-tcp-4k-mtu-and-rx-zerocopy [1] https://github.com/xdp-project/xdp-project/blob/master/areas/core/xdp-multi-buffer01-design.org [2] https://netdevconf.info/0x14/session.html?tutorial-add-XDP-support-to-a-NIC-driver (XDPmulti-buffers section)Took your patches for a test run with the AF_XDP sample xdpsock on an i40e card and the throughput degradation is between 2 to 6% depending on the setup and microbenchmark within xdpsock that is executed. And this is without sending any multi frame packets. Just single frame ones. Tirtha made changes to the i40e driver to support this new interface so that is being included in the measurements.
Could you please share Tirtha's i40e support patch with me? I would like to reproduce these results in my testlab, in-order to figure out where the throughput degradation comes from.
What performance do you see with the mvneta card? How much are we willing to pay for this feature when it is not being used or can we in some way selectively turn it on only when needed?
Well, as Daniel says performance wise we require close to /zero/ additional overhead, especially as you state this happens when sending a single frame, which is a base case that we must not slowdown. -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer