I see Packet loss on a 2116 with moderate load (500MBit/s). I tried to enable l3HW Offload. Anyone seen this error:
/interface/ethernet/switch/print
Columns: NAME, TYPE, L3-HW-OFFLOADING, QOS-HW-OFFLOADING
;;; L3HW init error(3)
0 switch1 Marvell-98DX3255 no no
L2HW Offload is enabled.
ROS 7.14.3 / Firmware 7.14.3 / CCR2116-12G-4S+ / r2
SUP-162860
The packet loss is caused by MPLS enabled. Even without MPLS packets travelling from/through this router and minimal Mappings (31 loopback addresses for VPLS connections terminated at another router) it causes packet drops. Large BGP Tables and MPLS is not usable on a 2116 / ROS V7.14.3.
I wanted to use this router only as backup-path for MPLS Packets, so I could disable MPLS.
Disabling MPLS enables L3HW. So MPLS on CCR2116 is a nogo for now. A small note in Documentation would help a lot 
Yes, MPLS on CCR2xxx si very limited!
A couple years ago we were hoping for hardware offloading of MPLS, but now… we have lost hope, so we are looking at other devices.
It’s a shame. With L3HW Unloading it is a real beast. Very low CPU load with Full BGP Tables. Consistent low latency.
Until the new CCR’s support decent MPLS performance they are “Dead in the water” to me as all of my consulting customers are using MPLS.
The MPLS performance of the CCR2116 is worse than that of the CCR2004-12XS.
I think that currently the best MPLS performance you can get with Mikrotik is around 4Gbps with the CCR2004.
Unless (or until) it’s been fixed, MPLS is limited to a single CPU core in one direction (encapsulation or decapsulation, I forget which) in RouterOS 7. There’s a thread about it on the forums. (I tested it on a pair of 2004’s and posted my results there.)
Since the 2116 has more slower cores than 2004 or 5009, the latter two will handle that function better… for now. Once multi-core en/decapsulation is fixed, and/or HW-offload of MPLS is added, things should improve immensely.
The decapsulation process is tied to a single core. I believe this is because ROS, when detecting that the packet payload is not IP, only performs the hash considering the source and destination MAC addresses, so for a single uplink, it will result in a single output for this hash.
I proposed to support that the MPLS header be included in the hash calculation when the frame payload was MPLS unicast (ethertype 0x8847), so that at least flows with different labels (for example different VPLS or VRFs) could be distributed across different CPUs.