On Wed, Oct 10, 2007 at 11:44:05AM -0700, Ted Unangst wrote: > On 10/9/07, Douglas A. Tutty <[EMAIL PROTECTED]> wrote: > > Why is this? Is there a security reason why the kernel is > > single-thread; is it OBSD resource limitations (no developer time, no > > hardware, etc); is it not enough interest yet? > > the stack runs entirely as interrupts. if there were a thread, we > could add another, but going from 0 to 1 is more work than 1 to 2. > > networking workloads do not always divide up among CPUs nicely. > assuming the code is written, just turning 2 or more CPUs loose on a > stream of packets is likely to result in reordering, which is bad. to > avoid reordering, you need lots of queueing, which hurts performance > and drives up latency. the problem is unfortunately not as simple as > add a lock here, a thread there, and presto.
Right, I see that multiple threads dealing with one interface would be a problem, but if you had a box with several interfaces, couldn't a mult-threaded stack work? Yes, I agree that 1 to 2 threads is totally different than 2 to n. I'm just concerned with what I perceive as two converging trends: 1) the trend for hardware per-interface bandwidth to increase; 2) the slowing of advances in single-processor speed. We're getting multiple cores on a chip and multiple chips on a board, and multiple interfaces on a box. What is the answer when the primary to-the-world interface is faster than the OBSD firewall can handle on a single CPU? Doug.
