About hardware bonding support in switch chip

b0207191 · May 30, 2025, 7:32am

In the OpenWRT system, support for bonding is implemented through kmod-bonding, luci-proto-bonding, and proto-bonding, including both static and dynamic bonding. However, if the device includes a switch chip, there doesn't seem to be any logic for configuring hardware aggregation in these components. Is this an oversight?

brada4 · May 30, 2025, 8:50am

Please post output of

ubus call system board

from your OpenWrt device

stragies · May 30, 2025, 8:55am

I would also like to know more about this. AFAIK, all the Realtek switch platforms have broken LAG. Last status update regarding that topic seems to be this post: Support for RTL838x based managed switches - #3002 by janh

Also not sure, if any other DSA platforms have functional HW offloading capabilities. Anybody here that can enlighten both(all) of us with the current state of affairs regarding Trunking/Bonding/LAG?

EDIT: QCA8k seems to support bonding, but QCA8K is not (yet?) afaik used in OpenWrt, because it causes performance regressions. Also, some Marvell switches seem to support LAG in Linux upstream, but I'm not sure, if OpenWrt also supports enabling HW offload for those, and on which devices compatible Marvell switches are used.

bmork · May 31, 2025, 12:49pm

This is part of the Linux kernel infrastructure. No logic is needed in userspace. If the drivers implement hardware offloading, then it will be used automatically.

See

for a description of the design.

The OpenWrt realtek target drivers implement offloading for some LAG types for example:

github.com/openwrt/openwrt

target/linux/realtek/files-6.6/drivers/net/dsa/rtl83xx/dsa.c

main


      
          
          	if (priv->r->enable_mcast_flood && (flags.mask & BR_MCAST_FLOOD))
          		priv->r->enable_mcast_flood(port, !!(flags.val & BR_MCAST_FLOOD));
          
          	if (priv->r->enable_bcast_flood && (flags.mask & BR_BCAST_FLOOD))
          		priv->r->enable_bcast_flood(port, !!(flags.val & BR_BCAST_FLOOD));
          
          	return 0;
          }
          
          static bool rtl83xx_lag_can_offload(struct dsa_switch *ds,
          				      struct net_device *lag,
          				      struct netdev_lag_upper_info *info)
          {
          	int id;
          
          	id = dsa_lag_id(ds->dst, lag);
          	if (id < 0 || id >= ds->num_lag_ids)
          		return false;
          
          	if (info->tx_type != NETDEV_LAG_TX_TYPE_HASH) {

b0207191 · May 31, 2025, 12:56pm

Yes, especially in situations where LACP support is required, the gsw mode cannot support all layer2 protocols; the dsa mode must be used instead. Therefore, the original swconfig is no longer usable. Within the dsa framework, there are operation functions related to LAG integration in the dsa_switch_ops structure. However, it is not clear whether the switch chip manufacturers provide support in their drivers.

b0207191 · May 31, 2025, 1:05pm

Well, I took another look at the explanation of LAG integration in the DSA documentation, and my understanding of this section is that it refers to the bonding of CPU ports on the switch chip to the host, rather than the bonding of user ports on the switch chip. So, the meaning of aggregation here is different: one is used to increase the bandwidth for management purposes, and the other is to enhance the bandwidth for forwarding. I'm not sure if my understanding of this part of DSA is correct, and if there are any mistakes, please point them out, thank you.

bmork · May 31, 2025, 2:34pm

I don't think there's any difference as seen from the switch hardware/driver. Bonding is bonding whether the other end of the link is a local CPU with multiple macs or a remote server with multiple nics or another switch.

b0207191 · May 31, 2025, 2:45pm

I’ll attempt to explain my views on the differences between software aggregation and hardware aggregation. In Linux, what I call software aggregation, the aggregation is handled by the operating system. In contrast, aggregation within the switching chip, which I refer to as hardware aggregation, is managed by the hardware itself. Assuming the system is under the DSA (Distributed Switch Architecture) framework, the aggregation algorithms in Linux are designed with server scenarios in mind, such as the balance-rr algorithm, active-backup algorithm, and broadcast algorithm. On the other hand, the aggregation algorithms in switching chips are tailored for forwarding scenarios, and thus are mainly based on IP, MAC, and port information. Alright, this is a bit off-topic, let’s get back to the differences between software and hardware aggregation. Under the DSA architecture, if the kernel selects a physical port from the bond interface based on its own hashing algorithm to send a packet, it’s not guaranteed that the packet will ultimately be sent out through that physical port, because the switching chip will recalculate based on its own hashing algorithm and choose the port for sending. This means that for device management packet transmission, or for software forwarding in a parallel switching chip structure, there needs to be a certain level of synchronization between software aggregation and hardware aggregation.

bmork · May 31, 2025, 3:12pm

I'm not sure I understand what you mean. But switches can usually only offload L2/L3/L4 hashing (or a subset). Any balancing or active-backup is out of the question. If you want hardware bonding then you must configure a supported mode.

As you can see from the realtek dsa driver I pointed to, it supports L2 or L2+L3 hashing only.