There's always a problem when passing between zones with different speeds ... in particular when traffic is passing from faster towards slower speed. The device which spans the two zones has to buffer data and different devices do it with various success. MT seems to be among the worst and it seems that device type is not the biggest factor. Working implementation of flow control should help a lot, but MT default seems to be "off" (check /interface/ethernet, settings rx-flow-control and tx-flow-control are per port), but it should be enabled on both link partners and in particular on the faster side.

The question is why MT disables flow control by default...

I cannot tell difference when it comes to CPU usage on RB5009. Both before and after disabling HW offload it's ~30% when transferring between WAN and LAN @ 2Gbit speed.

But I wonder if your case falls into same category as other cases in this thread. Others are using RB5009 as switch between 2.5GbE and 1GbE ports where both ports are members of same bridge and HW offload can kick in. If 2.5GbE port is used as WAN, then it's usually off-bridge and L2 HW offload doesn't work.

I am one of these "others" as well I connect to ISP using SFP module ...

 1   H ;;; Ether4
       interface=LAN-WiFi bridge=bridge priority=0x80 path-cost=10 internal-path-cost=10 edge=auto 
       point-to-point=auto learn=auto horizon=none hw=yes auto-isolate=no restricted-role=no restricted-tcn=no pvid=1 
       frame-types=admit-all ingress-filtering=yes unknown-unicast-flood=yes unknown-multicast-flood=yes
       broadcast-flood=yes tag-stacking=no bpdu-guard=no trusted=no multicast-router=temporary-query fast-leave=no
 ...
  6   H ;;; Ether1
       interface=LAN-2.5G bridge=bridge priority=0x80 path-cost=10 internal-path-cost=10 edge=auto
       point-to-point=auto learn=auto horizon=none hw=yes auto-isolate=no restricted-role=no restricted-tcn=no pvid=1
       frame-types=admit-all ingress-filtering=yes unknown-unicast-flood=yes unknown-multicast-flood=yes
       broadcast-flood=yes tag-stacking=no bpdu-guard=no trusted=no multicast-router=temporary-query fast-leave=no

 7   H ;;; Ethers 7 and 8
       interface=LAN-Bond bridge=bridge priority=0x80 path-cost=10 internal-path-cost=10 edge=no-discover
       point-to-point=auto learn=auto horizon=none hw=yes auto-isolate=no restricted-role=no restricted-tcn=no pvid=1
       frame-types=admit-all ingress-filtering=yes unknown-unicast-flood=yes unknown-multicast-flood=yes
       broadcast-flood=yes tag-stacking=no bpdu-guard=no trusted=no multicast-router=temporary-query fast-leave=no

There are some things you can do to alleviate the issue: 1) Enable flow control on both devices

2) Disable the hardware offloading for the high speed port

Also with this - its recommended to set multi-queue-ethernet-default for all interfaces in this case - even those that are offloaded

> /queue/tree/print
Flags: X - disabled, I - invalid
 0   name="queue-upload" parent=WAN-SFP packet-mark=no-mark limit-at=0 queue=my-cake priority=8 max-limit=100M
     burst-limit=0 burst-threshold=0 burst-time=0s bucket-size=0.001

 1   name="queue-download" parent=bridge packet-mark=no-mark limit-at=0 queue=my-cake priority=8 max-limit=1100M
     burst-limit=0 burst-threshold=0 burst-time=0s bucket-size=0.001

Yes, cake queue will be overridden - however in my experience Cake is not necessary at such high speeds inside a LAN.

You only need cake on the WAN interface then

> /queue/tree/print
Flags: X - disabled, I - invalid
 0   name="queue-upload" parent=WAN-SFP packet-mark=no-mark limit-at=0 queue=my-cake priority=8 max-limit=100M
     burst-limit=0 burst-threshold=0 burst-time=0s bucket-size=0.001

 1   name="queue-download" parent=bridge packet-mark=no-mark limit-at=0 queue=my-cake priority=8 max-limit=1100M
     burst-limit=0 burst-threshold=0 burst-time=0s bucket-size=0.001

 packet-mark=no-mark

We are talking about interface queues - not trees - do not confuse them - its entirely different !

Note: improvement from only-hardware-queue and multi-queue-ethernet-default is present only when there is no "/queue tree" entry with paticular interface as a parent.

When you change port speeds between interfaces the switch chip hardware does not have high enough buffers to help with the flow as one port is faster than the other - hence the problems you are facing. This is a common issue with most switch chips in general.

There are somethings you can do to alleviate the issue.
1) Enable flow control on both devices - this is good but can cause other problems for low latency application requirements as it will pause the port for ALL traffic on the port when its needed.
2) Disable the hardware offloading for the high speed port - essentially forcing the packets to go through the CPU when that port is involved. This is good if you have fast path enabled otherwise your CPU will get saturated really fast. Also with this - its recommended to set multi-queue-ethernet-default for all interfaces in this case - even those that are offloaded - as any intercommunication with the high speed port can cause some TX drops on the port - this interface queue type will help solve this. This method is the most preferable - only if CPU allows it.