Messages in this thread | | | Subject | Re: tulip driver in 2.1.11* - 2.1.21 is broken - new driver | From | Andi Kleen <> | Date | 19 Sep 1998 23:12:06 +0200 |
| |
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/
| |