Regarding the TOH, these models are:
But the hardware is quite different, and so is the price...
On Amazon-US and -CA the Banana Pi BPI-R3 is listed for 100-145 US$. But that's the naked board w/o a case or a psu, even w/o antennas. These will cost you extra...
So in the "good arm router" department there is IMHO the turris omnia, but it fails on the "cheap" requirement. Its dual core arm a9 @1.6 GHz is surprisingly "punchy" for a CPU core introduced in 2007..., currently arm a72 seems to be an all around better CPU (a53 or even a55 cores need to come a significantly higher frequency as these cores are, arm's marketing not withstanding, simply not as performant/Hz as the a9*).
For a long time MIPS ruled the market for low-end/-cost router SoCs, but MIPS has not really been offering newer CPU cores that attracted market attention, so IMHO the MIPS routers are slowly dying out... router-SoCs have a surprisingly long staying power and are sold for quite some time, so you can still get relative recent MIPS routers, but these are getting rarer while arm based SoCs are slowly taking over, in the budget bin, however I would assume that MIPS still has an edge over arm.
*) These are more power-efficient in-order cores, while a9/a72 are out-of-order more performant cores (that is have higher instructions per cycle), but once you push the in-order cores to equal performance (by increasing the frequency) to the out-of-order cores there will be little power-saving left...
Supported by OpenWrt? No. Not all Banana Pi boards are intended to be used in routers. The Banana Pi BPI-R2, BPI-R64, and BPI-R3 are the three boards that are well supported by OpenWrt. The BPI-R3 is the newest and best.
You would likely need addon Wi-fi cards for either the BPI-R2 or BPI-R64. I would highly recommend the BPI-R3 as the best option for you. You can find it in kit form on Ali Express that comes with the board, case, power supply, and antennae.
Your statements are not accurate enough because you are comparing an ancient architecture (ARM v7) with a modern one (ARM v8).
A7/A9/Krait etc are built on the ARMv7 architecture and supports only 32-bit instruction set.
A53/A55/A72 etc are bult on the ARMv8 architecture and supports 64-bit and 32-bit instructions
Also note that ARMv8 architecture compared to ARMv7 has many advantages:
For detailed information feel free to refer to:
"Raw" performance could be compared via "DMIPS/MHz" column in the table from the link above.
However, "raw" performance does not take into account all of the improvements above such as SIMD (NEON) and Cryptography Extension (CE).
ARM Architecture DMIPS/MHz
ARMv7 Cortex A7 1.9
ARMv7 Cortex A9 2.5
ARMv7 Krait 300 3.39
ARMv7 Cortex A15 3.5 - 4.01
ARMv8 Cortex A53 2.24
ARMv8 Cortex A55 2.65
ARMv8 Cortex A57 4.8
ARMv8 Cortex A72 6.3 - 7.3
ARMv8 Cortex A73 7.4 - 8.5
PS: Item (1) has been corrected. Thanks for pointing me the error.
Fair enough, if you need new instructions not available in a9 you need a different CPU, no remind me, which instructions are you missing for your OpenWrt router?
This is true, but IMHO beyond the point, as 32bit CPUs work just fine for a router, especially one that has considerably less memory than 4GB.
But unless your version of OpenWrt actually uses these they are pretty much dead silicon.
Don't get me wrong, I am not trying to convince people to stay on a9, it is more that I want them to avoid clunkers like a53 and a55...
I think this is one of those measures that serve well to sort a set of items into a ascending/descending series, but that tells not very much about actual performance during use as a router.
LOL
CE boosts AES performance up to 25x:
CE boosts OpenVPN throughput up to 5x (unfortunately, OpenVPN is incapable to utilize more than 1 core):
But you can keep recommending A9 as a "punchy" choice 
i am sorry for my ignorance, aparently i confused one of those with other i saw in a forum here, it looked exactly like that one i mentioned
Yes, but if your router does not use AES this capability buys you exactly nothing...
Well, so riddle me this, will these instructions actually help the new generation of the VPNs, aka Wireguard, which uses ChaCha20 instead of AES?
And I will if I think it is a good match (or a better match than a53/a55) for the discussed use case. I certainly am more impressed by beefy general performance than by a few choice instructions that mostly help with benchmarks, or in the rare case that the software intended to be run on a device actually can profit from those instructions. But the OP's requests did not read like that to me.
Feel free to prefer a53/a55 if they are better suited to your use cases.
I'm stating the obvious, but... People might be more in agreement in this discussion if functions of "router" was defined. People sometimes also use these same devices as a L2 switch, VPN node, firewall, media server, Docker host, WIFI AP, etc. and not just routing IP over Ethernet. ... and at ever increasing bandwidth. As @moeller0 mentioned, "use case" matters. 
i would like to have a all in one road warrior * just travel and connect * router, switch, wifi ap, vpn server client, and vpn obfuscation server, openvpn 256 or 512 over shadow sock or any other kind of censorship circunvention, also firewall that is my use case model, and that is why i am asking here to the experts what could be fine, aparently banana router is very suitable
You had marked this a solved, so I was aiming my post at the slightly diverged dialog.
But, I will suggest to you that you also include parameters like bandwidth for each service, bandwidth needed for VPN, encryption type/algorithm to be supported and how much growth for the future for each item, that you are willing to pay for now.
Hopefully others can continue to recommend based on these updated criteria.
a legacy for the ones stepping behind our path!
I'm afraid I don't agree. I have both the BPI-R2, based on the MT7623 which is a 1.4GHz ARM Cortex-A7 (successor to the A9) board, and the BPI-R64, based on the Mt7622 which is a 1.35GHz ARM Cortex-A53 board. The 64-bit A53 board gets almost exactly twice the integer performance per core as the 32-bit board, at essentially the same clock frequency.
My version of OpenWrt does. For example...
...Wireguard on Linux uses the existing crypto-api, which makes use of NEON. From lsmod on my BPI-R64:
chacha_neon 20480 1 libchacha20poly1305
poly1305_neon 20480 1 libchacha20poly1305
Also wireguard isn't the only new generation of crypto being used. For example, I use Syncthing on my main router as the hub for all my devices' file sync. Syncthing uses several primitives, including AES and chacha20, which both see a major boost on the A53.
The A9 is not a poor CPU. I use my MT7623-based device as a client bridge in my office, and it is also a decent little file server for my LAN. But single-core performance is important, as generally this will be the rate-limiting link due to interrupt handling. And at twice the performance-per-megahertz, my main house router's A53 is a major asset.
In any case, I think this discussion may be a little distracting for the OP.
you can all feel free to discuss here, if you want, until mod closes this thread, any information will be deemed as useful, have fun
The a7 was the sucessor of the a5 and was suceeded itself by the a53, this is from ythe power optimised in-order branch of the arm A family, so not representative of the out-of-order a9. Sure inside the power efficient branch successive designs improve upon each other, but that does not really change the point that within each generation the performance cores like a9, a15, a72 generally make short work out of the efficiency cores, and often the performanco cores still are not outmatched by the next generation efficiency cores. Like a9 often being better or equal to a53...
Well, great for your use case then. And then I agree decent choice. But the argument was about AES instructions....
ADDITION: a9 also has NEON units (and a7 might as well), so not sure this is relevant for the original a9 versus a53/55 discussion.
And now imagine you would actually compare a9 instead of your a7 with the a53 and you would not see a doubling of the integer performance.
Gentlemen, I am out of this discussion, I said what I wanted to convey, and I feel this is a waste of all of our time.
Regarding A53 cores, I found it interesting that running the coremark benchmark (an available openwrt package) on my EA8500 (1.4 GHz ipq8064 Krait 32 bit dual core - ARM A15 based) yielded 5715 Coremark for 4.08 Cm/MHz, but my Belkin RT3200 (1.35GHz MT7622 Arm A53 64 bit dual core) yielded only 4677 Coremark for 3.46 Cm/MHz. I concluded my old EA8500 wasn't showing too much age ;-).
Ah, one more example of arm's performance cores holding their own against the next generation efficiency cores
That is however not all that surprising given the different primary goals of these two lines of CPU's. And this also does not make the efficiency cores bad CPUs... but it does show that 'newer must be better' is a tad too simplistic to judge relative performance of arm-based router SoCs, at least without benchmarking one's own relevant use-cases.
RockPro64 with an external NIC works very well in general and gives you a bit more options about what distro you want to run and plenty of performance. It's been ages since I tried OpenWrt but it should be fine on that platform too (images are available).
With a dual a72 and a quad a53 this will offer adequate performance for 1 Gbps links (completely side-stepping our performance versus efficiency core discussion, simply by offering both efficiency AND performance cores from the same generation, as well as both neon simd (which a9 also offers) and cryptography extensions...) and a real PCIe slot to allow adding more ethernet ports easily via a NIC.
Would you please not to mislead people by putting the Cortex-A9 NEON and the Cortex-A53 NEON in the same row. NEON on a Cortex-A9 is able to execute only 64 bits at a time, while NEON on Cortex-A53 can execute 128 bits at a time.
Moreover, it is not even a fact that your target (mvebu/cortex-9) is compiled against the NEON instruction set.
Could you share with us the output of the following command:
lsmod | grep neon