Re: [PATCH net-next v5 2/2] net: dsa: mxl862xx: implement bridge offloading

[Daniel Golle <daniel@makrotopia.org>]

On Thu, Mar 19, 2026 at 09:57:42AM +0100, Paolo Abeni wrote:
> On 3/15/26 5:20 PM, Daniel Golle wrote:
> > (struct dsa_switch *ds, int port,
> > +				     struct dsa_bridge bridge,
> > +				     bool *tx_fwd_offload,
> > +				     struct netlink_ext_ack *extack)
> > +{
> > +	struct mxl862xx_priv *priv = ds->priv;
> > +	struct mxl862xx_bridge *mxlbridge;
> > +
> > +	mxlbridge = mxl862xx_find_bridge(ds, bridge);
> > +	if (!mxlbridge) {
> > +		mxlbridge = mxl862xx_allocate_bridge(ds, bridge.num);
> > +		if (IS_ERR(mxlbridge))
> > +			return PTR_ERR(mxlbridge);
> > +	}
> > +
> > +	__set_bit(port, mxlbridge->portmap);
> 
> AFAICS mxl862xx_bridge role is to track the above portmap, which in turn
> looks like a quite generic information which could be easily tracked by
> the DSA core. I'm wondering if it would be useful to move implement
> tracking there, and remove the mxl862xx_bridge entirely.

DSA generally uses unsigned int as port ID, however, 500MB of a bitmap
seems excessive to cover the full 32-bit range. 256-bit would be
more than sufficient (u8 range), or the 128-bit (positive s8 range)
the firmware of MxL862xx also uses...

So what should be the size of the to-be-defined generic DSA portmap?

Or should tracking happen internally using other (dynamic) structures
(eg. link list) and we provide a helper taking a driver-allocated
bitmap and its size as parameters?

The to-be-invented tracking structure should also come with a priv
pointer which can be used by the driver to (in this case) track the
firmware-assigned bridge ID as well.

Alternatively, instead of inventing a new structure, the driver could
iterate over dsa_ports which carries a pointer to dsa_bridge, and we
could just extend dsa_bridge to contain a priv pointer which allows
drivers to track what ever they want together with the DSA bridge.

Let me know what you think.