| Message ID | 20210402095532.925929-1-ciorneiioana@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | dpaa2-eth: add rx copybreak support | expand |
Hello: This series was applied to netdev/net-next.git (refs/heads/master): On Fri, 2 Apr 2021 12:55:29 +0300 you wrote: > From: Ioana Ciornei <ioana.ciornei@nxp.com> > > DMA unmapping, allocating a new buffer and DMA mapping it back on the > refill path is really not that efficient. Proper buffer recycling (page > pool, flipping the page and using the other half) cannot be done for > DPAA2 since it's not a ring based controller but it rather deals with > multiple queues which all get their buffers from the same buffer pool on > Rx. > > [...] Here is the summary with links: - [net-next,v2,1/3] dpaa2-eth: rename dpaa2_eth_xdp_release_buf into dpaa2_eth_recycle_buf https://git.kernel.org/netdev/net-next/c/28d137cc8c0b - [net-next,v2,2/3] dpaa2-eth: add rx copybreak support https://git.kernel.org/netdev/net-next/c/50f826999a80 - [net-next,v2,3/3] dpaa2-eth: export the rx copybreak value as an ethtool tunable https://git.kernel.org/netdev/net-next/c/8ed3cefc260e You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
From: Ioana Ciornei <ioana.ciornei@nxp.com> DMA unmapping, allocating a new buffer and DMA mapping it back on the refill path is really not that efficient. Proper buffer recycling (page pool, flipping the page and using the other half) cannot be done for DPAA2 since it's not a ring based controller but it rather deals with multiple queues which all get their buffers from the same buffer pool on Rx. To circumvent these limitations, add support for Rx copybreak in dpaa2-eth. Below you can find a summary of the tests that were run to end up with the default rx copybreak value of 512. A bit about the setup - a LS2088A SoC, 8 x Cortex A72 @ 1.8GHz, IPfwd zero loss test @ 20Gbit/s throughput. I tested multiple frame sizes to get an idea where is the break even point. Here are 2 sets of results, (1) is the baseline and (2) is just allocating a new skb for all frames sizes received (as if the copybreak was even to the MTU). All numbers are in Mpps. 64 128 256 512 640 768 896 (1) 3.23 3.23 3.24 3.21 3.1 2.76 2.71 (2) 3.95 3.88 3.79 3.62 3.3 3.02 2.65 It seems that even for 512 bytes frame sizes it's comfortably better when allocating a new skb. After that, we see diminishing rewards or even worse. Changes in v2: - properly marked dpaa2_eth_copybreak as static Ioana Ciornei (3): dpaa2-eth: rename dpaa2_eth_xdp_release_buf into dpaa2_eth_recycle_buf dpaa2-eth: add rx copybreak support dpaa2-eth: export the rx copybreak value as an ethtool tunable .../net/ethernet/freescale/dpaa2/dpaa2-eth.c | 66 ++++++++++++++----- .../net/ethernet/freescale/dpaa2/dpaa2-eth.h | 10 ++- .../ethernet/freescale/dpaa2/dpaa2-ethtool.c | 40 +++++++++++ 3 files changed, 98 insertions(+), 18 deletions(-)