Waiting for mbufs

[Till Straumann]

Here's the output of rtems_bsdnet_show_mbuf_stats()

The 'free' after 'clusters' shows you the number of
free clusters (which should in your case be 0 since
you get the 'Still waiting for mbuf cluster' message.

The 'free' in the 3rd line gives you the number of
free mbufs (which is not of interest here).

If you have enough memory, you can simply increase
the memory set aside for mbuf clusters in your bsdnet
configuration table.

************ MBUF STATISTICS ************
mbufs:1440    clusters: 175    free: 143
drops:   0       waits:   0  drains:   0
       free:1406          data:33          header:1           socket:0 

        pcb:0           rtable:0           htable:0           atable:0 

     soname:0           soopts:0           ftable:0           rights:0 

     ifaddr:0          control:0          oobdata:0


-- Till

Chris Johns wrote:
> gregory.menke at gsfc.nasa.gov wrote:
> 
>> Is there a task-id sensitivity built into the stack?  When I had 2
>> daemons per unit, the mbuf problem didn't occur.  I'm kind of
>> wondering if it could be some kind of effect related to
>> event_receive/semaphore timing.  Calling
>> rtems_bsdnet_show_mbuf_stats() shows 400+ mbufs free.  Any hints are
>> appreciated.
> 
> 
> How many clusters do you have and how many are pending in the drivers (I 
> am assuming the device supports scatter/gather operation) ?
> 
> The mbuf stat command lists the clusters as well as the numbre free. 
> Clusters are different to mbufs.
> 
> If you run short or are running low, the two task design will allow a 
> driver to block, and let the other run. The other running receive task 
> can receive data, pass to the stack some clusters which are freed, 
> releasing the blocked recieve task. In a single task design the second 
> card cannot service its receive chain so you block.
> 
> You could use a NO_WAIT design with scatter/gather hardware where low 
> cluster counts result in less receive buffers queued in hardware. If you 
> run out the MAC should report missed receives but what is received is 
> passed to the stack in a timely manner.
>