Re: dev.bce.X.com_no_buffers increasing and packet loss

From: Pyun YongHyeon <pyunyh_at_gmail.com>
Date: Tue, 9 Mar 2010 13:40:13 -0800
On Tue, Mar 09, 2010 at 01:31:55PM -0800, David Christensen wrote:
> > > > patch can fix the RX issue you're suffering from. Anyway, 
> > would you 
> > > > give it try the patch at the following URL?
> > > > http://people.freebsd.org/~yongari/bce/bce.20100305.diff
> > > > The patch was generated against CURRENT and you may see a message 
> > > > like "Disabling COAL_NOW timedout!" during interface up. You can 
> > > > ignore that message.
> > > 
> > > It's been running for about 1:23 on the patched driver.  I'm still 
> > > seeing the com_no_buffers increase:
> > > 
> > > [firewall2.jnb1] ~ # sysctl dev.bce |grep com_no_buffers
> > > dev.bce.0.com_no_buffers: 5642
> > > dev.bce.1.com_no_buffers: 497
> > > dev.bce.2.com_no_buffers: 6260612
> > > dev.bce.3.com_no_buffers: 4871338
> > > 
> > 
> > Still have no idea why these counters are increasing here.
> > Actually the counter is read from scratch pad of completion 
> > processor. The datasheet does not even document the counter.
> > Maybe david know better what's happening here(CCed).
> > 
> > > Interupt rate is down now, at about 3500 per second per interface.
> > > 
> > > Interestingly setting net.inet.ip.fastforwarding=0 reduces CPU 
> > > consumption from 25% to 9% and less packet loss.
> 
> The com_no_buffers statistic comes from firmware and indicates how
> many times a valid frame was received but could not be placed into
> the receive chain because there were no available RX buffers.  The
> firmware will then drop the frame but that dropped frame won't be
> reflected in any of the hardware based statistics.
> 

Yeah, but the question is why bce(4) has no available RX buffers.
The system has a lot of available mbufs so I don't see the root
cause here.

> Dave
Received on Tue Mar 09 2010 - 20:40:19 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:01 UTC