On Thu, Mar 03, 2011 at 03:52:54PM +0100, Manuel Guesdon wrote: > Of course and s/OpenBSD/FreeBSD/ may help too but none of these proposals > seems very constructive.
If you think that you'd be better served by FreeBSD, please go ahead and use that instead. > >| I think we already mentioned it that you will always see Ierr. The > >| question is if the box is able to forward more then 150kpps. > > Yes that's one a the questions. We can divide it into 3 questions: > 1) is the limitation comes from hardware ? > 2) is the limitation comes from OpenBSD ? > 3) is the limitation comes from the way OpenBSD exploit hardware. > > 1) Except if someone explain by a+b why the hardware can't forward this > rate, I'm keep thinking it can do it (otherwise I don't see reason to sell > quad 1Gbps nic). Are you suggesting that because you have a quad-port gig nic, your box should be able to do 6 *million* packets per second? By that logic my 5-port Soekris net4801 should be able to handle 740kpps. (for reference, the net4801 does about 3kpps with 4.9) > I'm ok to hear that I've purchased crappy motherboard card > or nic (but I'd like to understand why they are crappy). It has nothing to do with hardware crappiness, it has to do with your expectations. Your box should certainly be able to fill a few of your gig ports with 1500byte packets, but there is no way it'll handle a full 4 gigabits / second of TCP syn packets. > I've spent days and days making tests, searches, reading kernel source > code and so on because I think it's interesting for the community to > find where the problem come from and how to solve it (if possible). If > finally the answer is that OpenBSD (or may be any other OS) can't > forward more than 150kpps without losing 1 to 20 pps with this > hardware, I'll live with it. Are you actually complaining about 1 to 20 errors per second? That's 0.01% packet loss, welcome to ethernet. You will not see this change by switching to different hardware or OS. It /is/ possible that something is wrong with your box and you could be getting a slightly higher throughput. But don't expect that we'll make it handle 2 million PPS any time soon. > But as we've already seen that increasing int/s improve performances > (for good or bad reason), I keep thinking there's something to improve > or fix but I may be wrong. There are MANY more "performance" considerations than just pps: latency, interactive/userland performance under load, how the system responds once it is overloaded, etc. We're not going to sacrifice all these just to get a higher pps number. However, don't bother just telling us "there's something to improve". We've working on this for years, we've already made huge improvements, and we're always looking for more. Perhaps the biggest limitation on modern hardware is that we can't split the packet handling across multiple CPUs, but your "input" provides exactly ZERO help with changing that.
