Mike Gerdts writes: > Does this imply that there should be some requirement for ensuring > that the new architecture is able to effectively use multiple threads?
Unless the underlying driver delivers inbound packets on separate threads, I don't see how anything can be done here. It's not as though fanning out packets in the middle and then gathering them back together (and dealing with all the locking issues that raises) is anything like "cheap." It's almost certainly more expensive than just processing the filters. And if the underlying driver does deliver packets on separate interrupts, then there's nothing we can do here to add any goodness to that existing separation. So, I don't see what would be added here. I'd like to be proven wrong (do you have a concrete design to propose), but I don't see it. If we had network stream processors in the front end, we could talk about compiling the filtering rules into some sort of common language for them, but that's not on the table. -- James Carlson, KISS Network <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
