waiting for mbuf cluster message

Torsten Landschoff torsten.landschoff at nambition.com
Thu Dec 20 20:42:37 UTC 2007


Hi Joel,

Joel Sherrill wrote:
> What are the causes that can lead to
> this message from m_clalloc in
> rtems_glue.c
>
>   printf ("Still waiting for mbuf cluster.\n");
>   
This can happen if
a) you are out of mbuf clusters
b) somebody damaged the data structures managing the mbuf clusters
> I recall there are some things the
> application can do to make the mbuf
> cluster problem better and worse.
>   
I managed to configure only a single mbuf cluster which is the worst
thing you can do: Data that an application sends is buffered in those
clusters until an acknowledge is received for that data. Now, having
only a single cluster (which was already used), there was no cluster
left to receive the reply.

IOW: If you are sending data and your peer is slow to reply, you might
run out of mbuf clusters. I am not sure how to limit the number of mbuf
clusters to use for outgoing data. When all mbuf clusters are used with
non-acked outgoing packets, your TCP/IP stack is toast.
> Are there things I can do to help figure
> out where the clusters are going?  Any
> data structures to dump?
>   
Have a look at "extern struct mbstat mbstat" declared in mbuf.h. It
keeps track of free clusters, clusters used etc.
Apart from checking out who calls m_clalloc, I have no idea how to find
out where they are going apart from being used up for outgoing TCP buffers.

Perhaps this is already of some help. I could gather some more
information if needed, but I'll have to get some stuff done first. :)

This mail reminds me that I'll have to ask my boss again if I can attend
to the RTEMS class at embedded brains in munich. Would be great to attend.

Greetings from Germany,

  Torsten



--
Torsten Landschoff | Embedded software and FPGA development
nAmbition GmbH     | Tatzberg 47, 01307 Dresden
                   | HRB NR. 23095 b. Amtsgericht Dresden
Geschäftsführung   | Dr. J. Struckmeier, F. Pelzer, René M. Schretzmann
Beiratsvorsitz     | Dr. Gregor Kampwerth




More information about the users mailing list