--- Steve Shorter <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 28, 2005 at 10:15:55AM -0800, > Matthew Dillon wrote: > > :What kind of "benefits" would be realized > for > > :systems being used primary as a > router/bridge, > > :given that its almost 100% kernel usage? > > : > > :DT > > > > Routing packets doesn't take much cpu > unless you are running a gigabit > > of actual bandwidth (or more). If you > aren't doing anything else with > > the machine then the cheapest AMD XP will > do the job. > > > > We've found the bottle neck for routers is CPU > cycles neccessary to > process NIC hardware interrupts. At least for > OBSD. Interupt mitigation, and > I suppose POLLING on Dragonfly may help but it > isn't supported on all > hardware AFAIK. Polling is pretty dumb with modern NICs, as most have built-in interrupt moderation that does the work of polling without all of the overhead (by generating interrupts with user-definable forced separation). At least Intels do; if others don't then thats enough reason not to use them. Doing 500K pps with a 10K interrupts/second setting is better than you could ever do with polling, and the results quite good. Dealing with the NICs (processing packets, I/Os, etc) is what uses the cycles, and the stack (a bridge machine can do twice as many packets as a "router" for example). For network processing true separation of transmit and receive is probably the only way to realize networking gains for non TCP/UDP operations. Slicing up the stack will only slow things down compared to UP (think of a full-speed relay race against a guy that doesn't get tired...the guy without the hand-offs will always win.) The best you can probably do is match the UP performance; but idealy have a bunch of cpu power left over. So maybe you'd have a UP machine that can do 800K pps and be on the edge of livelock, and a DP machine that can do 750K pps but is still usable at the user level. Danial __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com