You don't need a container that will let you shell into it like @taoyou published to make it work. My
far more stripped-down container will do this with a bit of care.
Follow all instructions up to the "add" point, then say instead:
/container
add remote-image=tangentsoft/iperf3:latest interface=veth1 cmd="-c192.168.1.10"
start 0
Immediately after hitting Enter on the third line, you should then see the router connect to the "iperf3 -s" box. This is why I didn't bother to enable "logging=yes" on the container; the successful feedback output is on the server side.
The key to making this work is to "cuddle" the -c and host options. If you put a space between them, RouterOS's bare-bones container engine isn't smart enough to parse it as two separate options and pass them as such into the container, causing iperf3's command line parser to yell about being unable to parse your request.
If you go down this path, beware that for every distinct test target IP, you will have to instantiate a new container since the "add" command bakes the IP into the instantiated container.
Also, because RouterOS doesn't cache container images like a full-featured container engine does, this means the command above will pull from Docker Hub each time before the test runs. For a few tests, this is fine, but if you're going to do this a lot, you might run into rate limiting. Copying iperf3.tar as in my docs and running from that may then be advisable.
Beware that, as @mkx says, this will not be a speed demon, giving results that aren't all that helpful. I tested this on an RB4011 which normally reports 3.4 Gbit/sec to a 10GbE client PC for a regular "forward" test, but when I had that same router act as a client to that same PC running "iperf3 -s", it only got up to an average of 1.53 Gbit/sec. Because of the cmd argument parsing weakness in RouterOS, I couldn't add iperf3's -R option to reverse the test.
Still, this does suggest an alternate workaround. Instead of setting the RouterOS box up as a client, set it up as a server per the instructions linked above, then say on the client:
$ iperf3 -R -c 192.168.88.2
…where 192.168.88.2 is your router's veth1 IP address. In my no-NAT scheme, a .1 router can have a .2 address like this. Now the iperf3 client connects to the server but then makes the server send packets back to the client, giving the desired effect without changing the container. My test results here went up to 2.51 Gbit/sec in -R mode, a far more plausible result for this setup.
