[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
Date (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?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:44    [W:0.133 / U:3.680 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site