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

On Thu, Mar 19, 2026 at 09:57:42AM +0100, Paolo Abeni wrote:

On 3/15/26 5:20 PM, Daniel Golle wrote:

quoted

(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.