>it performs under load. pf will barf on many real >networks pushing a lot less than you think, >depending on the complexity of the ruleset.
Well, personally if I had that much packet load, I'd buy a dedicated system designed to do that. >> cos you should first avoid entering the kernel >> anyway as much as you can. >Ah, from the mouths of babes (or people who live >in tiny caves)! Actually I work in a rather large bank and I write trading systems. These are line of business applications that help us make money. >If your network is pushing 300-500K pps its nice >to have a firewall or security device or router >that can handle it. And those filtering/network So - are you wittering about packet shuffling or not? I guess I have a view of this stuff as base infrastructure. It has to work, but its not business specific and it only affects the bottom line when its broken. Reliability is more important than performance. Performance and features are not differentiators for our internal efficiency *or* to our customer relationships. One of *BSD's biggest PR problems over the years has been a tendency for arrogant 'network professionals' to suggest that the network is the Most Important Thing. But its only there to support users in their day-to-day tasks, and that means bespoke line of business software and (to a lesser extent) personal productivity stuff. What's more important - email? web? FTP? routing? Or order management, inventory management, and last but probably not least, payroll? >That is the "Wall" for people who are on real >networks. You could always count on the wall In my experience, on 'real networks' we deploy specialised kit. Really, who the hell cares? Most businesses with a big enough LAN environment to need such high performance (and modern systems are pretty fast) will not look to deploy a general purpose OS with no support organisation on off the shelf hardware to do that sort of task anyway. But being a better system on 8- and 16-core systems for dynamic web apps and database tasks, that's a big deal, and a major issue is business continuity - so using this sort of commodity hardware effectively and supporting split clusters and async replicatiobn *is* really important. So's net boot and cluster management in HPC grids, though I suspect that my own industry sector is more focussed on that than most outside of R&D. As for yoru assertions that the routing etc has to be essentially single threaded - well, take a look inside the OpenSolaris network stack. Really - *why* do you care about this wall you go on about? Who is impacted by it, in practice? And how important is it compared to decent application performance with Java, Mono and Python? James
