From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: "Marek Behún" <kabel@kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
netdev@vger.kernel.org, Paolo Abeni <pabeni@redhat.com>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: [PATCH RFC net-next 0/6] net: mvneta: reduce size of TSO header allocation
Date: Mon, 3 Apr 2023 19:29:59 +0100 [thread overview]
Message-ID: <ZCsbJ4nG+So/n9qY@shell.armlinux.org.uk> (raw)
Hi,
With reference to
https://forum.turris.cz/t/random-kernel-exceptions-on-hbl-tos-7-0/18865/
It appears that mvneta attempts an order-6 allocation for the TSO
header memory. While this succeeds early on in the system's life time,
trying order-6 allocations later can result in failure due to memory
fragmentation.
Firstly, the reason it's so large is that we take the number of
transmit descriptors, and allocate a TSO header buffer for each, and
each TSO header is 256 bytes. The driver uses a simple mechanism to
determine the address - it uses the transmit descriptor index as an
index into the TSO header memory.
(The first obvious question is: do there need to be this
many? Won't each TSO header always have at least one bit
of data to go with it? In other words, wouldn't the maximum
number of TSO headers that a ring could accept be the number
of ring entries divided by 2?)
There is no real need for this memory to be an order-6 allocation,
since nothing in hardware requires this buffer to be contiguous.
Therefore, this series splits this order-6 allocation up into 32
order-1 allocations (8k pages on 4k page platforms), each giving
32 TSO headers per page.
In order to do this, these patches:
1) fix a horrible transmit path error-cleanup bug - the existing
code unmaps from the first descriptor that was allocated at
interface bringup, not the first descriptor that the packet
is using, resulting in the wrong descriptors being unmapped.
2) since xdp support was added, we now have buf->type which indicates
what this transmit buffer contains. Use this to mark TSO header
buffers.
3) get rid of IS_TSO_HEADER(), instead using buf->type to determine
whether this transmit buffer needs to be DMA-unmapped.
4) move tso_build_hdr() into mvneta_tso_put_hdr() to keep all the
TSO header building code together.
5) split the TSO header allocation into chunks of order-1 pages.
drivers/net/ethernet/marvell/mvneta.c | 166 +++++++++++++++++++++++-----------
1 file changed, 115 insertions(+), 51 deletions(-)
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
next reply other threads:[~2023-04-03 18:30 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-03 18:29 Russell King (Oracle) [this message]
2023-04-03 18:30 ` [PATCH RFC net-next 1/5] net: mvneta: fix transmit path dma-unmapping on error Russell King (Oracle)
2023-04-04 5:09 ` Eric Dumazet
2023-04-03 18:30 ` [PATCH RFC net-next 2/5] net: mvneta: mark mapped and tso buffers separately Russell King (Oracle)
2023-04-03 18:30 ` [PATCH RFC net-next 3/5] net: mvneta: use buf->type to determine whether to dma-unmap Russell King (Oracle)
2023-04-03 18:30 ` [PATCH RFC net-next 4/5] net: mvneta: move tso_build_hdr() into mvneta_tso_put_hdr() Russell King (Oracle)
2023-04-03 18:30 ` [PATCH RFC net-next 5/5] net: mvneta: allocate TSO header DMA memory in chunks Russell King (Oracle)
2023-04-04 5:11 ` [PATCH RFC net-next 0/6] net: mvneta: reduce size of TSO header allocation Eric Dumazet
2023-04-11 15:50 ` Russell King (Oracle)
2023-04-11 15:53 ` Eric Dumazet
2023-04-11 17:07 ` Marek Behún
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZCsbJ4nG+So/n9qY@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kabel@kernel.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=thomas.petazzoni@bootlin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).