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

[Lorenzo Bianconi <lorenzo@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3190 bytes --]

> 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

> 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]