netdev - Re: [net v2] net: ethernet: mtk_eth_soc: handle dma buffer size soc specific

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <kbzsne4rm4232w44ph3a3hbpgr3th4xvnxazdq3fblnbamrloo@uvs3jyftecma>
Date: Mon, 27 May 2024 17:13:42 +0100
From: Daniel Golle <daniel@...rotopia.org>
To: Sunil Kovvuri Goutham <sgoutham@...vell.com>
Cc: Sam Shih <Sam.Shih@...iatek.com>, 
	SkyLake Huang <SkyLake.Huang@...iatek.com>, Steven Liu <steven.liu@...iatek.com>, 
	Frank Wunderlich <linux@...web.de>, Felix Fietkau <nbd@....name>, Sean Wang <sean.wang@...iatek.com>, 
	Mark Lee <Mark-MC.Lee@...iatek.com>, Lorenzo Bianconi <lorenzo@...nel.org>, 
	"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	Matthias Brugger <matthias.bgg@...il.com>, 
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>, Frank Wunderlich <frank-w@...lic-files.de>, 
	John Crispin <john@...ozen.org>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, 
	"linux-mediatek@...ts.infradead.org" <linux-mediatek@...ts.infradead.org>
Subject: Re: [net v2] net: ethernet: mtk_eth_soc: handle dma buffer size soc
 specific

On Mon, May 27, 2024 at 03:55:55PM GMT, Sunil Kovvuri Goutham wrote:
> 
> 
> > -----Original Message-----
> > From: Frank Wunderlich <linux@...web.de>
> > Sent: Monday, May 27, 2024 7:52 PM
> > To: Felix Fietkau <nbd@....name>; Sean Wang <sean.wang@...iatek.com>;
> > Mark Lee <Mark-MC.Lee@...iatek.com>; Lorenzo Bianconi
> > <lorenzo@...nel.org>; David S. Miller <davem@...emloft.net>; Eric Dumazet
> > <edumazet@...gle.com>; Jakub Kicinski <kuba@...nel.org>; Paolo Abeni
> > <pabeni@...hat.com>; Matthias Brugger <matthias.bgg@...il.com>;
> > AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
> > Cc: Frank Wunderlich <frank-w@...lic-files.de>; John Crispin
> > <john@...ozen.org>; netdev@...r.kernel.org; linux-kernel@...r.kernel.org;
> > linux-arm-kernel@...ts.infradead.org; linux-mediatek@...ts.infradead.org;
> > Daniel Golle <daniel@...rotopia.org>
> > Subject: [net v2] net: ethernet: mtk_eth_soc: handle dma buffer size soc specific
> > 
> > From: Frank Wunderlich <frank-w@...lic-files.de>
> > 
> > The mainline MTK ethernet driver suffers long time from rarly but annoying tx
> > queue timeouts. We think that this is caused by fixed dma sizes hardcoded for
> > all SoCs.
> > 
> > Use the dma-size implementation from SDK in a per SoC manner.
> > 
> > Fixes: 656e705243fd ("net-next: mediatek: add support for MT7623
> > ethernet")
> > Suggested-by: Daniel Golle <daniel@...rotopia.org>
> > Signed-off-by: Frank Wunderlich <frank-w@...lic-files.de>
> 
> ..............
> > 
> > diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > index cae46290a7ae..f1ff1be73926 100644
> > --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> 
> .............
> > @@ -1142,40 +1142,46 @@ static int mtk_init_fq_dma(struct mtk_eth *eth)
> >  						       cnt * soc->tx.desc_size,
> >  						       &eth->phy_scratch_ring,
> >  						       GFP_KERNEL);
> 
> ..............
> > -	for (i = 0; i < cnt; i++) {
> > -		dma_addr_t addr = dma_addr + i * MTK_QDMA_PAGE_SIZE;
> > -		struct mtk_tx_dma_v2 *txd;
> > +		dma_addr = dma_map_single(eth->dma_dev,
> > +					  eth->scratch_head[j], len *
> > MTK_QDMA_PAGE_SIZE,
> > +					  DMA_FROM_DEVICE);
> > 
> 
> As per commit msg, the fix is for transmit queue timeouts.
> But the DMA buffer changes seems for receive pkts.
> Can you please elaborate the connection here.

*I guess* the memory window used for both, TX and RX DMA descriptors
needs to be wisely split to not risk TX queue overruns, depending on the
SoC speed and without hurting RX performance...

Maybe someone inside MediaTek (I've added to Cc now) and more familiar
with the design can elaborate in more detail.