bce(4) - com_no_buffers (Again)

[David Christensen]

> > Failure to allocate a new buffer should cause the driver to
> > drop the received frame and reuse the buffer, not lock up the
> > system.  Are you seeing the lockup come from bce(4) or does
> > it come from somewhere else due to the dropped data?
> >
> >
> 
> The lockup is not from the NIC as such, the systems have the appearance
> of locking up as home directories are on NFS and the user information
> is
> stored in a remote LDAP server.   When the system starts to drop frames
> due to lack of 9k memory regions it tends to last for a few minutes
> (when it is really bad) and stop all traffic into the system.  This
> appears to the average user as a complete system pause.
> 

Ack.

>
> I am under the impression that the best solution is to tune the RX ring
> so that flow control can be disabled but I not sure I could do this.
> 

Are small frames common in the actual failing case or are they 
restricted to your test case?  At least one of the Broadcom
Linux drivers addresses this issue by copying frames < 128 bytes
to a standard size buffer, saving the jumbo buffer allocation 
and DMA mapping operation.  If small frames are at the root of 
your problem then I think this would be a better solution than 
allocating more 9KB blocks by increasing the ring size. 

Dave