netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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!

             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).