Hello,
The documentation says:

With HW-offloaded bonding interfaces, the built-in switch chip will always use Layer2+Layer3+Layer4 for a transmit hash policy, changing the transmit hash policy manually will have no effect

On Linux, I can only select: layer2, layer2+3 or layer3+4.

What value of xmit_hash_policy should be set from the side of the bond in Linux?

Thanks

I might be wrong, but AFAIK Tx hash policies don't have to be exactly the same on both sides. Receiver should gladly accept frames through any of bond members (when frames target bond's active MAC address), it's only Tx that matters to distribute traffic accross all active bond members.

When you think of it: in most cases L2 doesn't play a big role when looking from host's side, number of used MAC addresses will be low (in most cases single unless we're talking about VM hypervisor) and most of time there will be single L3 address per L2 address (also true for most VM deployments). Meaning most of time L3+L4 will have same effect as L2+L3+L4. The only exception in most deployments will be where traffic from gateway is in play where L2 address will be the one of gateway device while L3 will be one of many remote addresses (in which case using L2 as part of Tx hash makes even less of a difference). There are other border line exceptions, one is when ethernet frames carry L3 protocol other than IP/IPv6 (most of bonding drivers/devices implement only IP and IPv6 so L3/L4 information can't be used for those frames).

Hello,
The documentation says:

With HW-offloaded bonding interfaces, the built-in switch chip will always use Layer2+Layer3+Layer4 for a transmit hash policy, changing the transmit hash policy manually will have no effect

On Linux, I can only select: layer2, layer2+3 or layer3+4.

What value of xmit_hash_policy should be set from the side of the bond in Linux?

Thanks

For MikroTik devices that support bridge hardware offloading e.g. CRS3xx, the document means that any transmit-hash-policy value can be selected and have no effect because the switch chip does not take that value into account. The switch chip has predefined value i.e. layer 2+3+4 for the transmit-hash-policy.

For my testing, MikroTik devices that use CPU to process the bonding take a transmit-hash-policy that is specified manually via WinBox/WebFig. The testing result is that the 802.3ad mode provides traffic into only one bonding member regardless of layer 2, layer 2+3. Note that the layer 3+4 is not fully complatible for the 802.3ad mode by its standard. However MikroTik devices with switch chip supported balance outgoing traffic at all bonding members for the 802.3ad mode. It means that no matter what layer number is set, the switch chip has it own way to do the transmit-hash-policy but the MikroTik document shows the layer 2+3+4.
I still wonder the layer 2+3+4. How the transmit-hash-policy works? I tried to think about sources and destinations (MAC+IP+Port) but it seems that it should work only one bonding members instead of balancing all bonding members. Note that I used the Bandwidth Test tool to see the traffic flowing through the bonding member interfaces. My hardware is CRS326 (ethernet switch) and hap ac2 (router) with RouterOS 7.6rc3. Hopefully it helps.

As you observed, none of hashing policies will use more than one bond member for transmitting frames belonging to single L4 connection. The one notable exception is Round Robin. Which can cause its share of problems (similar to processing packets by firewall in multi-threaded manner) and is thus not part of standard 803.2ad Tx hashing policies suite.