memory management in network stack

[eric at cls.usask.ca (Eric Norum)]

Patrick Doyle wrote:
> 
> 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.

Yeah, the netdemo code does panic when sendto returns an error.  I wrote it this way because I was using netdemo to stress the network code and it was easier to put a debugger breakpoint on rtems_panic.  Getting an application level panic like this is not really a problem so I guess the calls to rtems_panic should be replaced with calls to printf followed by a return or break as appropriate.

> 
> 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.
> 

The panic from the network code complaining about the inability to expand the network memory pool is showing that more memory needs to be set aside for use by the network stack.  It would be nice if this condition didn't result in a panic, but (1) this is not easy to change without making lots of changes to the BSD code (which makes tracking changes in the BSD code much more difficult) and (2) memory is cheap :-)

-- 
Eric Norum                                 eric at cls.usask.ca
Saskatchewan Accelerator Laboratory        Phone: (306) 966-6308
University of Saskatchewan                 FAX:   (306) 966-6058
Saskatoon, Canada.