You’re still mixing two separate concepts: IPv6 and point-to-point testing. The published benchmark numbers give the total bidirectional throughput in all ports simultaneously. Even when/if MikroTik does add hardware IPv6 acceleration, these routers still will not give 100% of the published numbers for point-to-point tests, as in your initial iperf3 results. RFC2544 ≠ iperf3.
AGAIN^3, this is not the goal of this topic because it’s not about technical stuff but benchmark tests results on the website, but since you are the third one to ask me the configuration, here it is, it can’t be more basic:
$ ssh admin@fdc6:5e2d:f8a3:2::1 /export
admin@fdc6:5e2d:f8a3:2::1's password:
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip hotspot profile
set [ find default=yes ] html-directory=hotspot
/port
set 0 name=serial0
/ip neighbor discovery-settings
set discover-interface-list=none protocol=""
/ip address
add address=172.16.1.1/24 interface=ether2 network=172.16.1.0
add address=172.16.2.1/24 interface=ether3 network=172.16.2.0
/ipv6 address
add address=fdc6:5e2d:f8a3:1::1 interface=ether2
add address=fdc6:5e2d:f8a3:2::1 interface=ether3
/system note
set show-at-login=no
/system routerboard settings
set auto-upgrade=yes
/tool mac-server
set allowed-interface-list=none
/tool mac-server mac-winbox
set allowed-interface-list=none
I did test with “iperf3 -P 10” (10 connections), same result. Single core with 100% usage.
iperf3 IPv4 => ~line rate with 1Gb/s port
$ iperf3 -P10 -c 172.16.1.42 | grep SUM
[SUM] 0.00-1.00 sec 124 MBytes 1.04 Gbits/sec 765
[SUM] 1.00-2.00 sec 111 MBytes 932 Mbits/sec 336
[SUM] 2.00-3.00 sec 112 MBytes 941 Mbits/sec 211
[SUM] 3.00-4.00 sec 111 MBytes 933 Mbits/sec 435
[SUM] 4.00-5.00 sec 112 MBytes 936 Mbits/sec 304
[SUM] 5.00-6.00 sec 111 MBytes 929 Mbits/sec 251
[SUM] 6.00-7.00 sec 111 MBytes 930 Mbits/sec 301
[SUM] 7.00-8.00 sec 111 MBytes 935 Mbits/sec 341
[SUM] 8.00-9.00 sec 112 MBytes 939 Mbits/sec 256
[SUM] 9.00-10.00 sec 112 MBytes 938 Mbits/sec 286
[SUM] 0.00-10.00 sec 1.10 GBytes 945 Mbits/sec 3486 sender
[SUM] 0.00-10.03 sec 1.09 GBytes 931 Mbits/sec receiver
iperf3 IPv6 => 474Mb/s
$ iperf3 -P10 -c fdc6:5e2d:f8a3:1::42 | grep SUM
[SUM] 0.00-1.00 sec 59.6 MBytes 500 Mbits/sec 850
[SUM] 1.00-2.00 sec 56.9 MBytes 477 Mbits/sec 632
[SUM] 2.00-3.00 sec 56.8 MBytes 477 Mbits/sec 601
[SUM] 3.00-4.00 sec 56.8 MBytes 477 Mbits/sec 611
[SUM] 4.00-5.00 sec 56.8 MBytes 477 Mbits/sec 557
[SUM] 5.00-6.00 sec 56.6 MBytes 475 Mbits/sec 676
[SUM] 6.00-7.00 sec 56.3 MBytes 472 Mbits/sec 622
[SUM] 7.00-8.00 sec 57.2 MBytes 480 Mbits/sec 702
[SUM] 8.00-9.00 sec 56.8 MBytes 477 Mbits/sec 666
[SUM] 9.00-10.00 sec 56.7 MBytes 476 Mbits/sec 683
[SUM] 0.00-10.00 sec 570 MBytes 479 Mbits/sec 6600 sender
[SUM] 0.00-10.03 sec 567 MBytes 474 Mbits/sec receiver
iperf3 IPv6, 10 parallels connections, bidirectional
$ iperf3 -P10 --bidir -c fdc6:5e2d:f8a3:1::42 | grep '0.00-10.00' | grep SUM
[SUM][TX-C] 0.00-10.00 sec 436 MBytes 366 Mbits/sec 4476 sender
[SUM][RX-C] 0.00-10.00 sec 253 MBytes 212 Mbits/sec 4569 sender
And there is not even a single stateless filter rule…
This is the result on 2 physical ports, since the router have 5 ports, I could connect the 2 other ones and run the same test on those ports in parallels too, but since the bidir already divided the throughput by 2, I let you guess the result…
Also, you are not the first one to tell me about RFC2544 used by Mikrotik. As written in the RFC5181, quote:
The benchmarking methodologies defined in RFC 2544 are IP version independent.
Since it’s not mention anywhere the IP version used for the test, so the test results are also IP version independent, right? (No)
Not exactly. You tested with 10 streams, but only one connection. Well, at least only one port. Since all 10 streams go from same single port to another same single port, they are all routed by the same core. Try running two iperf servers and two iperf clients with different ports. You will see two cores used, this time.
Yes, I forgot they didn’t mention IPv4 or IPv6 on the RFC2544. Sorry.
When I last checked iperf behaviour with wireshark, using parallel streams did establish appropriate connections (client side these used distinct port numbers). So from this aspect router should be able to utilize several CPU cores to do the routing. However, it could well be that routing engine uses some trivial hashing function to determine which core should deal with each packet and which doesn’t work well with IPv6 headers.
One example would be: take TCP or UDP packet, use bytes 12-23 (zero-based; which in IPv4 covers source IPv4 address, destination IPv4 address, source port number and destination port number), calculate some trivial hash. In IPv6 this doesn’t work because bytes 12-23 only cover 3 quarters of source IPv6 address (the least significant bits at least) which will be exactly the same for all connections from certain host regardless destination address and/or port numbers. Now I’m not saying that my example is how ROS works, it would be easy enough to check it … but one would really need a few source machines and a few destination machines to outplay probability for core selection procedure to come up with same selection … and see if in this case more than one CPU core gets utilized. This issue doesn’t itch me enough to bother with testing 
Anyway, these issues clearly show lack of commitment for IPv6 from Mikrotik’s side and that’s a pitty.
DPDK/VPP and hardware-offloaded XDP can filter/drop/process packets at 100Gbps on commodity hardware including arm64. I know Fortune 500 companies doing this internally.
Will MikroTik do this? Nope, they will stick with the current code they have along with all the problems that come with it, because their enterprise customers aren’t demanding XDP/DPDK/VPP hard enough.
Solution for you and me? Move to NOSes that supports DPDK/VPP/XDP.
Nobody actually requires XDP or DPDK or VPP or any other acronym. What enterprise customers require is certain performance level (at certain price tag) and they don’t give a shit how any particular vendor reaches that level.
Now, does Mikrotik want to enter the 100Gbps routing segment? It seems that they aren’t so their current technology portfolio seems to suffice. And if MT’s strategists don’t mind the business segment you’re talking about, there’s no input from customers (including their largest customers) that will change that in the short term.
They should be. And they should be software version independent as well.
As they clearly are not, the test results should mention the conditions of the test: the RouterOS version that was used, and the IP version of traffic.
I can’t understand why it is so hard to add that, and why they (Normis) keep iterating “the test results are for the RouterOS version the device was released with” (with that in itself mentioned nowhere)…
Yeah keep telling yourself that, good luck, have fun.
FYI: IPv6 FastTrack just went final!
http://forum.mikrotik.com/t/feature-request-ipv6-fasttrack/149315/1