lkml.org 
[lkml]   [1998]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: tulip driver in 2.1.11* - 2.1.21 is broken - new driver
From
Date
alan@lxorguk.ukuu.org.uk (Alan Cox) writes:

> > > Actually, there is one problem now, which makes this discussion
> > > academic. We stand on the edge now. Seems, it is not widely known
> > > fact, but current Linux CANNOT handle >~100Mbit interfaces.
> >
> > It seems that you're not aware that people are already doing ATM and
> > getting reasonable throughputs (apparently mainly limited by memory
> > bandwidth).
>
> No the problem we have is that the time go in and out of irq handlers
> and net_bh is a per packet constant. At 100Mbit small packet routing
> we cant cope (nor can BSD). At 1Gbit 1500 byte framing Linux routing
> is out (which in a way is fine since PCI is too slow - but PCI wont be
> too slow next year). Jes has accurate data on what 1500->8K packet size
> transitions do to our 1Gbit performance.

Is that true on SMP boxes too?

net_bh is basically

while (queue not empty) {
get packet
higher layers( packet );
}
If one CPU processes the device interrupts and always fills the queue and the
other CPU runs net_bh then it should go without too much overhead. The same
is true on a UP system, because net_bh can be interrupted by devices while the
packets are processed in the higher layers (so when it returns to the loop
there is already a new packet in the queues ready to be processed).

To optimize for this behaviour it might be worth it to add a output flush
check into the net_bh loop. The XMIT_EVERY define in 2.0 suggests that you
once tried that, did you try it with routing and SMP again?

Or do I miss something here?

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:44    [from the cache]
©2003-2011 Jasper Spaans