From: Matteo Croce <mcroce@linux.microsoft.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>,
Eric Dumazet <eric.dumazet@gmail.com>,
Thierry Reding <thierry.reding@gmail.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-riscv@lists.infradead.org,
Giuseppe Cavallaro <peppe.cavallaro@st.com>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
"David S. Miller" <davem@davemloft.net>,
Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Drew Fustini <drew@beagleboard.org>,
Emil Renner Berthing <kernel@esmil.dk>,
Jon Hunter <jonathanh@nvidia.com>, Will Deacon <will@kernel.org>
Subject: Re: [PATCH net-next] stmmac: align RX buffers
Date: Tue, 17 Aug 2021 02:01:57 +0200 [thread overview]
Message-ID: <20210817020157.3b9d015e@linux.microsoft.com> (raw)
In-Reply-To: <20210816081208.522ac47c@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
On Mon, 16 Aug 2021 08:12:08 -0700
Jakub Kicinski <kuba@kernel.org> wrote:
> On Thu, 12 Aug 2021 12:05:38 +0100 Marc Zyngier wrote:
> > > A possible fix, which takes in account also the XDP headroom for
> > > stmmac_rx_buf1_len() only could be (only compile tested, I don't
> > > have the hardware now):
> >
> > However, this doesn't fix my issue. I still get all sort of
> > corruption. Probably stmmac_rx_buf2_len() also need adjusting (it
> > has a similar logic as its buf1 counterpart...)
> >
> > Unless you can fix it very quickly, and given that we're towards the
> > end of the cycle, I'd be more comfortable if we reverted this patch.
>
> Any luck investigating this one? The rc6 announcement sounds like
> there may not be that many more rc releases for 5.14.
Hi Jackub.
Unfortunately I have only a device with stmmac, and it works fine with
the patch. It seems that not all hardware suffers from this issue.
Also, using NET_IP_ALIGN on RX is a common pattern, I think that any
ethernet device is doing the same to align the IPv4 header.
Anyway, I asked for two tests on the affected device:
1. Change NET_IP_ALIGN with 8, to see if the DMA has problems in
receiving to a non word aligned address
2. load a nop XDP program (I provided one), to see if the problem is
already there when XDP is used
I doubt that changing also stmmac_rx_buf2_len would help,
but it's worth a try, here is a patch:
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 7b8404a21544..73d1f0ec66ff 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -93,7 +93,7 @@ static int tc = TC_DEFAULT;
module_param(tc, int, 0644);
MODULE_PARM_DESC(tc, "DMA threshold control value");
-#define DEFAULT_BUFSIZE 1536
+#define DEFAULT_BUFSIZE 1536 + XDP_PACKET_HEADROOM + NET_IP_ALIGN
static int buf_sz = DEFAULT_BUFSIZE;
module_param(buf_sz, int, 0644);
MODULE_PARM_DESC(buf_sz, "DMA buffer size");
@@ -4508,12 +4508,12 @@ static unsigned int stmmac_rx_buf1_len(struct stmmac_priv *priv,
/* First descriptor, not last descriptor and not split header */
if (status & rx_not_ls)
- return priv->dma_buf_sz;
+ return priv->dma_buf_sz - stmmac_rx_offset(priv);
plen = stmmac_get_rx_frame_len(priv, p, coe);
/* First descriptor and last descriptor and not split header */
- return min_t(unsigned int, priv->dma_buf_sz, plen);
+ return min_t(unsigned int, priv->dma_buf_sz - stmmac_rx_offset(priv), plen);
}
static unsigned int stmmac_rx_buf2_len(struct stmmac_priv *priv,
@@ -4529,12 +4529,12 @@ static unsigned int stmmac_rx_buf2_len(struct stmmac_priv *priv,
/* Not last descriptor */
if (status & rx_not_ls)
- return priv->dma_buf_sz;
+ return priv->dma_buf_sz - stmmac_rx_offset(priv);
plen = stmmac_get_rx_frame_len(priv, p, coe);
/* Last descriptor */
- return plen - len;
+ return plen - len - stmmac_rx_offset(priv);
}
static int stmmac_xdp_xmit_xdpf(struct stmmac_priv *priv, int queue,
Regards,
--
per aspera ad upstream
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Matteo Croce <mcroce@linux.microsoft.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>,
Eric Dumazet <eric.dumazet@gmail.com>,
Thierry Reding <thierry.reding@gmail.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-riscv@lists.infradead.org,
Giuseppe Cavallaro <peppe.cavallaro@st.com>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
"David S. Miller" <davem@davemloft.net>,
Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Drew Fustini <drew@beagleboard.org>,
Emil Renner Berthing <kernel@esmil.dk>,
Jon Hunter <jonathanh@nvidia.com>, Will Deacon <will@kernel.org>
Subject: Re: [PATCH net-next] stmmac: align RX buffers
Date: Tue, 17 Aug 2021 02:01:57 +0200 [thread overview]
Message-ID: <20210817020157.3b9d015e@linux.microsoft.com> (raw)
In-Reply-To: <20210816081208.522ac47c@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
On Mon, 16 Aug 2021 08:12:08 -0700
Jakub Kicinski <kuba@kernel.org> wrote:
> On Thu, 12 Aug 2021 12:05:38 +0100 Marc Zyngier wrote:
> > > A possible fix, which takes in account also the XDP headroom for
> > > stmmac_rx_buf1_len() only could be (only compile tested, I don't
> > > have the hardware now):
> >
> > However, this doesn't fix my issue. I still get all sort of
> > corruption. Probably stmmac_rx_buf2_len() also need adjusting (it
> > has a similar logic as its buf1 counterpart...)
> >
> > Unless you can fix it very quickly, and given that we're towards the
> > end of the cycle, I'd be more comfortable if we reverted this patch.
>
> Any luck investigating this one? The rc6 announcement sounds like
> there may not be that many more rc releases for 5.14.
Hi Jackub.
Unfortunately I have only a device with stmmac, and it works fine with
the patch. It seems that not all hardware suffers from this issue.
Also, using NET_IP_ALIGN on RX is a common pattern, I think that any
ethernet device is doing the same to align the IPv4 header.
Anyway, I asked for two tests on the affected device:
1. Change NET_IP_ALIGN with 8, to see if the DMA has problems in
receiving to a non word aligned address
2. load a nop XDP program (I provided one), to see if the problem is
already there when XDP is used
I doubt that changing also stmmac_rx_buf2_len would help,
but it's worth a try, here is a patch:
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 7b8404a21544..73d1f0ec66ff 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -93,7 +93,7 @@ static int tc = TC_DEFAULT;
module_param(tc, int, 0644);
MODULE_PARM_DESC(tc, "DMA threshold control value");
-#define DEFAULT_BUFSIZE 1536
+#define DEFAULT_BUFSIZE 1536 + XDP_PACKET_HEADROOM + NET_IP_ALIGN
static int buf_sz = DEFAULT_BUFSIZE;
module_param(buf_sz, int, 0644);
MODULE_PARM_DESC(buf_sz, "DMA buffer size");
@@ -4508,12 +4508,12 @@ static unsigned int stmmac_rx_buf1_len(struct stmmac_priv *priv,
/* First descriptor, not last descriptor and not split header */
if (status & rx_not_ls)
- return priv->dma_buf_sz;
+ return priv->dma_buf_sz - stmmac_rx_offset(priv);
plen = stmmac_get_rx_frame_len(priv, p, coe);
/* First descriptor and last descriptor and not split header */
- return min_t(unsigned int, priv->dma_buf_sz, plen);
+ return min_t(unsigned int, priv->dma_buf_sz - stmmac_rx_offset(priv), plen);
}
static unsigned int stmmac_rx_buf2_len(struct stmmac_priv *priv,
@@ -4529,12 +4529,12 @@ static unsigned int stmmac_rx_buf2_len(struct stmmac_priv *priv,
/* Not last descriptor */
if (status & rx_not_ls)
- return priv->dma_buf_sz;
+ return priv->dma_buf_sz - stmmac_rx_offset(priv);
plen = stmmac_get_rx_frame_len(priv, p, coe);
/* Last descriptor */
- return plen - len;
+ return plen - len - stmmac_rx_offset(priv);
}
static int stmmac_xdp_xmit_xdpf(struct stmmac_priv *priv, int queue,
Regards,
--
per aspera ad upstream
next prev parent reply other threads:[~2021-08-17 0:02 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-14 2:25 [PATCH net-next] stmmac: align RX buffers Matteo Croce
2021-06-14 2:25 ` Matteo Croce
2021-06-14 19:51 ` David Miller
2021-06-14 19:51 ` David Miller
2021-06-14 23:21 ` Matteo Croce
2021-06-14 23:21 ` Matteo Croce
2021-06-15 17:28 ` David Miller
2021-06-15 17:28 ` David Miller
2021-06-15 17:30 ` patchwork-bot+netdevbpf
2021-06-15 17:30 ` patchwork-bot+netdevbpf
2021-08-10 19:07 ` Marc Zyngier
2021-08-10 19:07 ` Marc Zyngier
2021-08-11 10:28 ` Thierry Reding
2021-08-11 10:28 ` Thierry Reding
2021-08-11 12:53 ` Eric Dumazet
2021-08-11 12:53 ` Eric Dumazet
2021-08-11 14:16 ` Marc Zyngier
2021-08-11 14:16 ` Marc Zyngier
2021-08-12 8:48 ` Eric Dumazet
2021-08-12 8:48 ` Eric Dumazet
2021-08-12 10:18 ` Matteo Croce
2021-08-12 10:18 ` Matteo Croce
2021-08-12 11:05 ` Marc Zyngier
2021-08-12 11:05 ` Marc Zyngier
2021-08-12 11:18 ` Matteo Croce
2021-08-12 11:18 ` Matteo Croce
2021-08-19 16:29 ` Marc Zyngier
2021-08-19 16:29 ` Marc Zyngier
2021-08-20 10:37 ` Matteo Croce
2021-08-20 10:37 ` Matteo Croce
2021-08-20 16:26 ` Marc Zyngier
2021-08-20 16:26 ` Marc Zyngier
2021-08-20 16:38 ` Matteo Croce
2021-08-20 16:38 ` Matteo Croce
2021-08-20 17:09 ` Marc Zyngier
2021-08-20 17:09 ` Marc Zyngier
2021-08-20 17:14 ` Matteo Croce
2021-08-20 17:14 ` Matteo Croce
2021-08-20 17:24 ` Marc Zyngier
2021-08-20 17:24 ` Marc Zyngier
2021-08-20 17:35 ` Matteo Croce
2021-08-20 17:35 ` Matteo Croce
2021-08-20 17:51 ` Marc Zyngier
2021-08-20 17:51 ` Marc Zyngier
2021-08-20 17:56 ` Matteo Croce
2021-08-20 17:56 ` Matteo Croce
2021-08-20 18:05 ` Matteo Croce
2021-08-20 18:05 ` Matteo Croce
2021-08-20 18:14 ` Marc Zyngier
2021-08-20 18:14 ` Marc Zyngier
2021-08-20 18:09 ` Marc Zyngier
2021-08-20 18:09 ` Marc Zyngier
2021-08-20 18:14 ` Matteo Croce
2021-08-20 18:14 ` Matteo Croce
2021-08-20 18:41 ` Marc Zyngier
2021-08-20 18:41 ` Marc Zyngier
2021-08-16 15:12 ` Jakub Kicinski
2021-08-16 15:12 ` Jakub Kicinski
2021-08-17 0:01 ` Matteo Croce [this message]
2021-08-17 0:01 ` Matteo Croce
2021-08-19 15:26 ` Marc Zyngier
2021-08-19 15:26 ` Marc Zyngier
2021-08-11 10:41 ` Thierry Reding
2021-08-11 10:41 ` Thierry Reding
2021-08-11 10:56 ` Joakim Zhang
2021-08-11 10:56 ` Joakim Zhang
2021-08-11 13:23 ` Marc Zyngier
2021-08-11 13:23 ` Marc Zyngier
2021-08-12 14:29 ` Thierry Reding
2021-08-12 14:29 ` Thierry Reding
2021-08-12 15:26 ` Marc Zyngier
2021-08-12 15:26 ` Marc Zyngier
2021-08-13 14:44 ` Thierry Reding
2021-08-13 14:44 ` Thierry Reding
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=20210817020157.3b9d015e@linux.microsoft.com \
--to=mcroce@linux.microsoft.com \
--cc=alexandre.torgue@foss.st.com \
--cc=davem@davemloft.net \
--cc=drew@beagleboard.org \
--cc=eric.dumazet@gmail.com \
--cc=jonathanh@nvidia.com \
--cc=kernel@esmil.dk \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=maz@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=peppe.cavallaro@st.com \
--cc=thierry.reding@gmail.com \
--cc=will@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.