Re: [ECOS] Problem with IP Stack ...

[Andrew Lunn <andrew dot lunn at ascom dot ch>]

> What we found is that at the time when the clusters suddenly jump, the number of
> MBUFs is also increasing. There seems to be a loss of 36 clusters. After the
> first time the free clusters go to 0 they never go above 27. 36 + 27 gives 63
> which is the total number of available clusters. Does that mean anything to
> anybody of you?
> 

> In addition to the lost clusters we also lose 72 MBUFs (36 x 2). Could it be
> that MBUFs that for some reason never get free'ed are `holding' clusters?

Yes. In the network stack a cluster is always associated to a
mbuf. Basically, an mbuf is a smaller buffer. It can hold somewhere
around 90 bytes of data. If you need to store more data, you associate
a cluster to the mbuf and put the data into the cluster and not the
mbuf. So, if you loose an mbuf and a cluster is attached to the mbuf,
you loose the attached cluster as well.

> It is also strange that, although the (indicated) MBUFs increase
> from 0 to 72, the (indicated) pool memory does not decrease ???

? I don't follow. Take this as an example...

> Network stack mbuf stats:
>    mbufs 75, clusters 63, free clusters 24
>    Failed to get 0 times
>    Waited to get 0 times
>    Drained queues to get 331 times
> Misc mpool: total   65520, free   62400, max free block 61780
> Mbufs pool: total   65408, free   55680, blocksize  128
> Clust pool: total  131072, free       0, blocksize 2048

(65408 - 55680) / 128 = 76. 

So there is a discrepancy of 1, but that could of been allocated
between the two prints?

Now, 36 does seem like an important number. Look at the data
structures in your driver. Does this number pop up anywhere?

You have still not told us your platform, ethernet device, or which
stack. It makes is much harder for us to go looking for 36 in the
code.

        Andrew

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss