I haven’t ran any solid benchmarks, but I did run a generic speedtest from my laptop through the SN2010 and it hit ~9.2 Gbps, which is about the limit of my ISP, and certainly more than I’d expect from an Intel C2558. In any case, the CPU load on the switch didn’t change noticeably while running it. That does include EVPN and VXLAN, so that part’s working fine.
I haven’t really tried running an local containers, but they should just work up to the limit of the CPU, RAM, and x8 PCIe 3.0 link between the ASIC and CPU. This is all just a semi-normal part of the kernel, and traffic that the ASIC can’t handle on its own gets shunted to the CPU. Without that, BGP and OSPF wouldn’t work, so it wouldn’t be much of a switch.
The mlxsw wiki has a bunch of extra documentation on what this can do and how to accomplish it. They have docs on QoS, ACLs, multicast routing, and queue configuration. Basically, it all just uses the usual Linux tools (ip, tc, devlink, etc), but there are limitations on which options the hardware supports, and it’ll report an error if you try to configure something it can’t do, so you shouldn’t end up with a “that was a nice option, shame it dropped your performance by 99.9%” situation. So there’s a good chance that we’ll need to add documentation and maybe a few extra flags, but in general I’d expect VyOS’s current tools to mostly just work. Probably except for firewalling and NAT – VyOS uses nftables, and mlxsw only has limited hardware support for filters via tc.
Pim walked through a SN2700 with generic Debian a while ago; it’s slightly different hardware with slightly different limitations (you can’t split QSFP ports 4 ways on it without losing access to a second QSFP!), but it should be pretty similar in most ways.
The same article points out how you can see offloaded vs total packet counters. You have to enable collection via ip stats set dev swpXX l3_stats on, and then ip stats reports the total traffic broken down in various subgroups:
$ ip stats show dev swp21
11: swp21: group afstats subgroup mpls
RX: bytes packets errors dropped noroute
0 0 0 0 0
TX: bytes packets errors dropped
0 0 0 0
11: swp21: group link
RX: bytes packets errors dropped missed mcast
6703643222 9873147 0 1 0 1033786
TX: bytes packets errors dropped carrier collsns
10053668536 8735942 0 0 0 0
11: swp21: group offload subgroup l3_stats on used on
RX: bytes packets errors dropped mcast
2273685327 1469229 0 0 35
TX: bytes packets errors dropped
3794133812 2515254 0 0
11: swp21: group offload subgroup hw_stats_info
l3_stats on used on
11: swp21: group offload subgroup cpu_hit
RX: bytes packets errors dropped missed mcast
265401814 2420326 0 0 0 0
TX: bytes packets errors dropped carrier collsns
48769798 529321 0 0 0 0
11: swp21: group xstats_slave subgroup bond suite 802.3ad
11: swp21: group xstats subgroup bond suite 802.3ad
11: swp21: group xstats_slave subgroup bridge suite mcast
11: swp21: group xstats_slave subgroup bridge suite stp
11: swp21: group xstats subgroup bridge suite mcast
11: swp21: group xstats subgroup bridge suite stp
I didn’t turn l3_stats on immediately, so these numbers may not add up. VyOS should probably enable them by default, and show interface should be able to report them, but that’s code for another day, and in any case not critical for getting this working in the first place.
Thanks for spotting the typo; I’ll patch it into the upstream PR.