Re: BNX driver problem when mbuf clusters run out

[Beverly Schwartz <bschwart%bbn.com@localhost>]

On Apr 19, 2012, at 8:02 PM, Matt Thomas wrote:

> 
> On Apr 19, 2012, at 4:54 PM, Joerg Sonnenberger wrote:
> 
>> On Thu, Apr 19, 2012 at 07:45:35PM -0400, Beverly Schwartz wrote:
>>> That won't work in this case.  If bnx_get_buf succeeds in getting
>>> an mbuf cluster, it then puts it in the rx ring.  If we haven't
>>> removed the mbuf first, there will be no place to put the new mbuf.
>> 
>> That's circular reasoning. There are three places currently using
>> bnx_get_buf:
>> 
>> bnx_init_rx_chain
>> bnx_rx_intr
>> bnx_tick
>> 
>> The last one can be dropped with the changed semantic, since the RX ring
>> will never be depleted. The rest is solved by properly splitting up the
>> actions into allocating a mbuf cluster for the RX ring, loading a
>> cluster into the RX ring and unloading an already mapped entry.
>> bnx_init_rx_chain wants to the first two in order, bnx_rx_intr wants to
>> alloc, if that works: unload and load new cluster.
> 
> Unfortunately, that can lead to receiver livelock (spend all the time 
> servicing interrupts without making progress).  The best thing to do is pass 
> the packet up the stack and just another packet to the hardware.  Instead use 
> bnx_tick to add mbufs if needed.  This gives the stack a chance to run and 
> hopefully free some mbufs.

I tried that.  And at first, things move along.  But eventually, bnx_rx_intr 
never gets called, because 
if (sblk->status_rx_quick_consumer_index0 != sc->nw_rx_cons)
in bnx_intr always fails.

-Bev