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. > DaveReceived 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