Look, I know what I am talking about. I have an apu that does what I said using negligible cpu load. And there is nothing fancy with it.
Sent from ProtonMail Mobile On Sat, Nov 4, 2017 at 17:53, Chris Cappuccio <ch...@nmedia.net> wrote: > Rupert Gallagher [r...@protonmail.com] wrote: > > You seem to say that > handling larger packets is a feature of having limited CPU. I disagree. > > Rupert, I'm saying that a slower CPU can process less packets per second. The > important measurement is packets-per-second. The APU has plenty of memory > bandwidth to handle large volumes of data. For adequate CPU power, you have > to either lower the cost of processing (make software better/more efficient) > or you have to distribute the cost across the 4 cores of the APU2 (make > software execution parallel). > > The same traffic level, with 1500 byte > packets generates 6 times more packets per second than that traffic level > with 9000 bytes packets. > > You divided 9000 by 1500 without mistakes. > Congratulations. > The point was clearly lost on you. > > There is ongoing > work to improve the network stack performance on boxes like the APU2 (which > have 4 cores). You will see improvements. If you want it better today, you > need a faster box. Chris > > The apu2c4 is fast enough to saturate its Intel > 1Gbits/sec link. It has three of those. If you connect all three to the > switch, you get 3Gbps shy. No need for a faster box. You rather need a faster > switch, class 7 S-FTP wires (better than class 6), and 2.5Gbps lan cards for > clients. No, you don't need any of that. You have no idea what you are > talking about. The APU requires software crafted to evenly distribute > PER-PACKET PROCESSING cost across multiple cores. That is what is happening > in OpenBSD today. It has been happening for years, and it is getting closer > to becoming a reality with OpenBSD + APU2, as well as other > chipsets/platforms. For a couple years now, we've had interrupts processed by > one core, PF on another, and other parts of the kernel on a third core. But > to accelerate packet processing alone, we need interrupts handled on multiple > cores, PF processing handled on multiple cores. This is hard work. By the > way, what I'm describing is the general-purpose OS approach towads this > problem. If you want to turn computer hardware into routers with little other > concern, the go-to platform is DPDK + VPP. It is something like an order of > magnitude faster than any general purpose OS (OpenBSD, Linux) at packet > pushing. > https://www.reddit.com/r/networking/comments/6upchy/can_a_bsd_system_replicate_the_performance_of/dlvdq2e/ > Chris
