> > right, so more fragmentation-assembly increases the CPU load,
> > no surprise there.
> damn, i have a mtu of 1500 and i dont quite see abt what frag/reassembly
> are you talking about while the problems start to pop out on _256_ bytes
> large packets (yes 256+smth like 32 or more)
Its nothing to do with reassembly. My guess is that the irq handling or the
other driver locks on the ISA driver are holding off the sound.
> look: we have 2.0 serving NIC interrupts more efficintly than 2.4, and you
> say that we even dont need to know _why_ its so!?
Oh thats easy. 2.0 performs like crap on SMP boxes.
The newer code is intended to do sensible things for NE2K drivers however so
I am curious what is fouling up. It even goes to the trouble to avoid
disabling all interrupts during a transmit event.
What might be interesting would be to edit 8390.c and change
/* Mask interrupts from the ethercard.
SMP: We have to grab the lock here otherwise the IRQ handler
on another CPU can flip window and race the IRQ mask set. We end
up trashing the mcast filter not disabling irqs if we dont lock
*/
spin_lock_irqsave(&ei_local->page_lock, flags);
outb_p(0x00, e8390_base + EN0_IMR);
spin_unlock_irqrestore(&ei_local->page_lock, flags);
to use
/* this is the missing spin_trylock_irqsave longhand.. */
save_flags(flags);
__cli();
if(!spin_trylock(&ei_local->page_lock))
{
restore_flags(flags);
return 1;
}
outb_p(0x00, e8390_base + EN0_IMR);
spin_unlock_irqrestore(&ei_local->page_lock, flags);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Dec 15 2001 - 21:00:15 EST