[Click] RX Overruns with eepro100cd

[Barry Gowan]

I tried --enable-greedy and it didn't help but thanks
for the suggestion anyway.

 --- Chip Coldwell <coldwell at mazunetworks.com> wrote:
> On Fri, 1 Aug 2003, Barry Gowan wrote:
> > 
> > So _dev->rx_refill() blocks while a memory access
> on
> > the card is done to refill the ring buffer in the
> > driver.
> 
> I'm not sure if I could call this "blocking", since
> there's no wait
> queue or sleeping process involved, although I
> suppose in principle
> the kclick kernel thread could get pre-empted during
> this operation if
> there's a timer interrupt.  I think the kclick
> priority is high enough
> that it would always be rescheduled, though.
> 
> > So is there nothing I can change to improve this
> > situation? If I had a faster PCI bus would I get a
> > better result? Or is it just down to the eepro100
> NIC
> > being too busy to serve the memory fast enough?
> 
> Click will sometimes explicitly call the OS
> scheduler.  You can find
> the logic in RouterThread::driver, where it will
> alternate between
> calls to "run_tasks" (run the Click tasks) and
> "run_os" (call the OS
> scheduler).  We rely on run_tasks to call
> PollDevice::run_task which
> in turn calls _dev->rx_refill, so if the Click
> scheduler decides to
> call the OS scheduler instead that introduces an
> unpredictable amount
> of delay between successive calls to _dev->rx_refill
> and can lead to
> overruns.  If you have an SMP computer with Click
> configured to use
> just one CPU, then you can use the "--enable-greedy"
> configure option
> to eliminate the calls to the OS scheduler from
> within the Click
> scheduler.  Basically this gives one CPU to the OS
> and one to Click,
> and my experience has been that Click performance is
> greatly improved.
> 
> > When I replace the eepro100 with e1000 NICs, the
> same
> > test runs fine. I guess this is because whatever
> DMA
> > that _dev->rx_refill() triggers runs faster on the
> > e1000 hardware than the eepro100. Have I got this
> > analysis correct?
> 
> In the case of the E1000, one register write per
> sk_buff is required
> (those are writes across the PCI bus).  I haven't
> looked at the
> eepro100 driver, but it might be using more bus
> transfers, which would
> impact performance.
> 
> Chip
> 
> -- 
> 
> Charles M. "Chip" Coldwell
> "Turn on, log in, tune out."
>  

________________________________________________________________________
Want to chat instantly with your online friends?  Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/