On Wed, Oct 10, 2007 at 11:44:05AM -0700, Ted Unangst wrote:
quoted text
> On 10/9/07, Douglas A. Tutty <dtutty@porchlight.ca> wrote:
 
quoted text
> > 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.