memory management in network stack

[wpd at delcomsys.com (Patrick Doyle)]

I was playing with the netdemo code a few weeks ago and I ran into a
similar type of problem, although the error message was quite
different.  The basic problem was that the transmitUdp test attempted to
provide data to the TCP/IP layer more quickly than it could handle and
eventually the call to 'sendto()' would fail with 'errno' set to
'ENOBUFS'.  When I fixed the call to 'sendto()' to check for this error
and to retry, it worked fine.  My recollection is that the panic
occurred in my user code (that is to say, in the netdemo code, not in
the kernel code).  I never saw the message that you printed out below.

It occurs to me, not having seen the rtems-19990426 release, that
somebody may have been playing in the memory allocation code of the
TCP/IP stack and that this is new behavior.  Hmm... this probably
doesn't help you at all, but I guess I'll post it anyway.

--wpd

Jay Kulpinski wrote:
> 
> After upgrading from rtems-4.0.0/newlib-1.8.0/egcs-1.1b to
> rtems-19990426/newlib-1.8.1/binutils-2.9.1 I discovered a
> problem with memory management in the network stack.  Whenever
> I run netdemo now, the transmitUdp test will panic with this
> message:
> 
>         RTEMS: Network mbuf space can not be enlarged after
>         rtems_bsdnet_initialize() has returned.  Enlarge the
>         initial mbuf/cluster size in rtems_bsdnet_config.
> 
> I believe this is occurring now because the code runs faster
> thanks to the new PowerPC assembly IP checksum routine and
> possibly better optimization from egcs.  The processor now
> can get ahead of the network and try to queue up more packets
> than the fixed-size network buffers can handle.  In the
> sosend function, MCLGET(m, M_WAIT) should block waiting for the
> transmit driver task to free up mbuf clusters before continuing,
> but instead it panics down in kmem_malloc.  Enlarging the
> mbuf/cluster size as indicated in the message will not solve
> the problem if there is enough transmit data to overrun the
> buffers.
> 
> I'm still mulling over possible solutions to this, but I
> thought I'd put this up for discussion now in case anyone
> has any particular insight they'd like to share.