netdev - Re: [PATCH v7 net-next 2/2] net: airoha: Introduce ethernet support for EN7581 SoC

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: <ZpFBLkYyMXtMgbA8@lore-desk>
Date: Fri, 12 Jul 2024 16:43:58 +0200
From: Lorenzo Bianconi <lorenzo@...nel.org>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, nbd@....name, lorenzo.bianconi83@...il.com,
	davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com,
	conor@...nel.org, linux-arm-kernel@...ts.infradead.org,
	robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
	conor+dt@...nel.org, devicetree@...r.kernel.org,
	catalin.marinas@....com, will@...nel.org, upstream@...oha.com,
	angelogioacchino.delregno@...labora.com,
	benjamin.larsson@...exis.eu, rkannoth@...vell.com,
	sgoutham@...vell.com, andrew@...n.ch, arnd@...db.de,
	horms@...nel.org
Subject: Re: [PATCH v7 net-next 2/2] net: airoha: Introduce ethernet support
 for EN7581 SoC

> On Fri, 12 Jul 2024 15:47:38 +0200 Lorenzo Bianconi wrote:
> > > On Wed, 10 Jul 2024 10:47:41 +0200 Lorenzo Bianconi wrote:  
> > > > Add airoha_eth driver in order to introduce ethernet support for
> > > > Airoha EN7581 SoC available on EN7581 development board (en7581-evb).
> > > > en7581-evb networking architecture is composed by airoha_eth as mac
> > > > controller (cpu port) and a mt7530 dsa based switch.
> > > > EN7581 mac controller is mainly composed by Frame Engine (FE) and
> > > > QoS-DMA (QDMA) modules. FE is used for traffic offloading (just basic
> > > > functionalities are supported now) while QDMA is used for DMA operation
> > > > and QOS functionalities between mac layer and the dsa switch (hw QoS is
> > > > not available yet and it will be added in the future).
> > > > Currently only hw lan features are available, hw wan will be added with
> > > > subsequent patches.  
> > > 
> > > It seems a bit unusual for DSA to have multiple ports, isn't it?
> > > Can you explain how this driver differs from normal DSA a little 
> > > more in the commit message?  
> > 
> > The Airoha eth SoC architecture is similar to mtk_eth_soc one (e.g MT7988a).
> > The FrameEngine (FE) module has multiple GDM ports that are connected to
> > different blocks. Current airoha_eth driver supports just GDM1 that is connected
> > to a MT7530 DSA switch (I have not posted a tiny patch for mt7530 driver yet).
> > In the future we will support even GDM{2,3,4} that will connect to differ
> > phy modues (e.g. 2.5Gbps phy).
> 
> What I'm confused by is the mentioned of DSA. You put the port in the
> descriptor, and there can only be one switch on the other side, right?

do you mean fport in msg1 (airoha_dev_xmit())?

	fport = port->id == 4 ? FE_PSE_PORT_GDM4 : port->id;
	msg1 = FIELD_PREP(QDMA_ETH_TXMSG_FPORT_MASK, fport) |
	       ...

fport refers to the GDM port and not to the dsa user port. Am I missing
something?

> 
> > > > +	q = &eth->q_tx[qid];
> > > > +	if (WARN_ON_ONCE(!q->ndesc))
> > > > +		goto error;
> > > > +
> > > > +	spin_lock_bh(&q->lock);
> > > > +
> > > > +	nr_frags = 1 + sinfo->nr_frags;
> > > > +	if (q->queued + nr_frags > q->ndesc) {
> > > > +		/* not enough space in the queue */
> > > > +		spin_unlock_bh(&q->lock);
> > > > +		return NETDEV_TX_BUSY;  
> > > 
> > > no need to stop the queue?  
> > 
> > reviewing this chunk, I guess we can get rid of it since we already block the
> > txq at the end of airoha_dev_xmit() if we do not have enough space for the next
> > packet:
> > 
> > 	if (q->ndesc - q->queued < q->free_thr)
> > 		netif_tx_stop_queue(txq);
> 
> But @q is shared in your case isn't it? Unless we walk and stop all
> ports this won't save us. Coincidentally not sure how useful BQL can

Oh, right. We can theoretically have a packet from another netdevice for the
same hw queue. I will stop the queue in this case.

> be in a setup like this :( It will have no way to figure out the real
> egress rate given that each netdev only sees a (non-)random sample
> of traffic sharing the queue :(

do you prefer to remove BQL support?

Regards,
Lorenzo

> 
> 

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)