From: Andrew Lunn <andrew@lunn.ch>
To: Furong Xu <0x1207@gmail.com>
Cc: Serge Semin <fancer.lancer@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
Jose Abreu <joabreu@synopsys.com>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Joao Pinto <jpinto@synopsys.com>, Simon Horman <horms@kernel.org>,
netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, xfr@outlook.com, rock.xu@nio.com
Subject: Re: [PATCH net-next v1] net: stmmac: xgmac: increase length limit of descriptor ring
Date: Fri, 21 Jun 2024 05:12:27 +0200 [thread overview]
Message-ID: <788c2744-e1c0-4338-9b86-9119d31841f1@lunn.ch> (raw)
In-Reply-To: <20240621102627.000060d6@gmail.com>
> Heavy incoming traffic on some heavy load system, the max 1024 limit defined
> by DMA_MAX_RX_SIZE in drivers/net/ethernet/stmicro/stmmac/common.h is too
> few to achieve high throughput for XGMAC.
> With this patch, ethtool can set a new length than 1024
Please include some benchmark results to show the improvement.
But at some point, more buffers don't help you. If you are
consistently overloaded, you will still overflow the buffers. So you
might want to look at where is the bottleneck and how do you
prioritise processing packets over whatever else is loading the
system.
Maybe this would help, if the bus is the problem:
https://www.spinics.net/lists/netdev/msg1006370.html
Andrew
next prev parent reply other threads:[~2024-06-21 3:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-20 8:52 Furong Xu
2024-06-20 12:06 ` Serge Semin
2024-06-21 2:26 ` Furong Xu
2024-06-21 3:12 ` Andrew Lunn [this message]
2024-06-20 13:23 ` Andrew Lunn
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=788c2744-e1c0-4338-9b86-9119d31841f1@lunn.ch \
--to=andrew@lunn.ch \
--cc=0x1207@gmail.com \
--cc=alexandre.torgue@foss.st.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fancer.lancer@gmail.com \
--cc=horms@kernel.org \
--cc=joabreu@synopsys.com \
--cc=jpinto@synopsys.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rock.xu@nio.com \
--cc=xfr@outlook.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
all inboxes | Powered by JetHome®