diff options
author | David S. Miller <davem@davemloft.net> | 2021-04-02 14:25:47 -0700 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2021-04-02 14:25:47 -0700 |
commit | 8577dd8a07cc2183e3790aa8f8da3d8c6a87803d (patch) | |
tree | f3190341aa7a8a7ad13abf4d133d44c9cc9c23c7 /drivers/nfc/pn533 | |
parent | 3e8db6365f233a110815a4c34cae5d6ee74b1db8 (diff) | |
parent | 8ed3cefc260e2ef2107cbd9484e4025f60c37bb5 (diff) |
Merge branch 'dpaa2-rx-copybreak'
Ioana Ciornei says:
====================
dpaa2-eth: add rx copybreak support
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
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/nfc/pn533')
0 files changed, 0 insertions, 0 deletions