From: Furong Xu <0x1207@gmail.com>
To: Serge Semin <fancer.lancer@gmail.com>
Cc: "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 10:26:27 +0800 [thread overview]
Message-ID: <20240621102627.000060d6@gmail.com> (raw)
In-Reply-To: <e3yzigcfbbkowias54nijvejc36hbcvfgjgbodycka3kfoqqek@46gktho2hwwt>
On Thu, 20 Jun 2024 15:06:57 +0300
Serge Semin <fancer.lancer@gmail.com> wrote:
> Hi Furong
>
> On Thu, Jun 20, 2024 at 04:52:00PM +0800, Furong Xu wrote:
> > DWXGMAC CORE supports a ring length of 65536 descriptors, bump max length
> > from 1024 to 65536
>
> What XGMAC IP-core version are you talking about? The DW XGMAC
> IP-core databooks I have define the upper limit much lesser than that.
>
Hi Serge
Thanks for this information.
I double checked 3.10a and 3.20a, 3.10a do have a limit to 16K,
and 3.20a bump the limit to 64K.
So we need to lower the limit to fit all XGMAC versions. And what about
your advice to set this limit?
> Do you understand that specifying 65K descriptors will cause a huge
> amount of memory consumed, right? Each descriptor is equipped with at
> least 1-page buffer. If QoS/XGMAC SPH is enabled then each descriptor
> is equipped with a second buffer. So 65K-descriptor will cause
> allocation of at least 65536 * (4 * 4) bytes + 65536 * PAGE_SIZE
> bytes. So it's ~256MB for the smallest possible 4K-pages. Not to
> mention that there can be more than one queue, two buffers assigned to
> each descriptor and more than a single page allocated for each buffer
> in case of jumbos. All of that will multiply the basic ~256MB memory
> consumption.
>
Fully agree with you. This patch is trying to make it possible for ethtool
to set a longer descriptor length against XGMAC. All MAC cores still have
512 descriptors allocated by default for both TX and RX, which is defined
by DMA_DEFAULT_TX_SIZE and DMA_DEFAULT_RX_SIZE in
drivers/net/ethernet/stmicro/stmmac/common.h
This patch does not change the default descriptor length for XGMAC core,
but give ethtool a chance to set a bigger value than DMA_MAX_TX_SIZE and
DMA_MAX_RX_SIZE defined in drivers/net/ethernet/stmicro/stmmac/common.h
> Taking all of the above into account, what is the practical reason of
> having so many descriptors allocated? Are you afraid your CPU won't
> keep up with some heavy incoming traffic?
>
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
> Just a note about GMACs. The only GMAC having the ring-length limited
> is DW QoS Eth (v4.x/v5.x). It may have up to 1K descriptors in the
> ring. DW GMAC v3.73a doesn't have the descriptors array length constraint.
> The last descriptor is marked by a special flag TDESC0.21 and
> RDESC1.15, after meeting which the DMA-engine gets back to the first
> descriptor in the ring.
>
> -Serge(y)
>
> >
> > Signed-off-by: Furong Xu <0x1207@gmail.com>
> > ---
> > .../net/ethernet/stmicro/stmmac/dwxgmac2.h | 2 ++
> > .../ethernet/stmicro/stmmac/stmmac_ethtool.c | 24 +++++++++++++++----
> > 2 files changed, 22 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
> > index 6a2c7d22df1e..264f4f876c74 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
> > +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
> > @@ -11,6 +11,8 @@
> >
> > /* Misc */
> > #define XGMAC_JUMBO_LEN 16368
> > +#define XGMAC_DMA_MAX_TX_SIZE 65536
> > +#define XGMAC_DMA_MAX_RX_SIZE 65536
> >
> > /* MAC Registers */
> > #define XGMAC_TX_CONFIG 0x00000000
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> > index 18468c0228f0..3ae465c5a712 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> > @@ -491,9 +491,16 @@ static void stmmac_get_ringparam(struct net_device *netdev,
> > struct netlink_ext_ack *extack)
> > {
> > struct stmmac_priv *priv = netdev_priv(netdev);
>
> > + u32 dma_max_rx_size = DMA_MAX_RX_SIZE;
> > + u32 dma_max_tx_size = DMA_MAX_TX_SIZE;
> >
> > - ring->rx_max_pending = DMA_MAX_RX_SIZE;
> > - ring->tx_max_pending = DMA_MAX_TX_SIZE;
> > + if (priv->plat->has_xgmac) {
> > + dma_max_rx_size = XGMAC_DMA_MAX_RX_SIZE;
> > + dma_max_tx_size = XGMAC_DMA_MAX_TX_SIZE;
> > + }
> > +
> > + ring->rx_max_pending = dma_max_rx_size;
> > + ring->tx_max_pending = dma_max_tx_size;
>
> Do you understand the consequence of this change, right?
> De
>
> > ring->rx_pending = priv->dma_conf.dma_rx_size;
> > ring->tx_pending = priv->dma_conf.dma_tx_size;
> > }
> > @@ -503,12 +510,21 @@ static int stmmac_set_ringparam(struct net_device *netdev,
> > struct kernel_ethtool_ringparam *kernel_ring,
> > struct netlink_ext_ack *extack)
> > {
> > + struct stmmac_priv *priv = netdev_priv(netdev);
> > + u32 dma_max_rx_size = DMA_MAX_RX_SIZE;
> > + u32 dma_max_tx_size = DMA_MAX_TX_SIZE;
> > +
> > + if (priv->plat->has_xgmac) {
> > + dma_max_rx_size = XGMAC_DMA_MAX_RX_SIZE;
> > + dma_max_tx_size = XGMAC_DMA_MAX_TX_SIZE;
> > + }
> > +
> > if (ring->rx_mini_pending || ring->rx_jumbo_pending ||
> > ring->rx_pending < DMA_MIN_RX_SIZE ||
> > - ring->rx_pending > DMA_MAX_RX_SIZE ||
> > + ring->rx_pending > dma_max_rx_size ||
> > !is_power_of_2(ring->rx_pending) ||
> > ring->tx_pending < DMA_MIN_TX_SIZE ||
> > - ring->tx_pending > DMA_MAX_TX_SIZE ||
> > + ring->tx_pending > dma_max_tx_size ||
> > !is_power_of_2(ring->tx_pending))
> > return -EINVAL;
> >
> > --
> > 2.34.1
> >
> >
next prev parent reply other threads:[~2024-06-21 2:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-20 8:52 [PATCH net-next v1] net: stmmac: xgmac: increase length limit of descriptor ring Furong Xu
2024-06-20 12:06 ` Serge Semin
2024-06-21 2:26 ` Furong Xu [this message]
2024-06-21 3:12 ` Andrew Lunn
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=20240621102627.000060d6@gmail.com \
--to=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;
as well as URLs for NNTP newsgroup(s).