Re: [ECOS] Two TCP/IP stack issues...

[Grant Edwards <grante at visi dot com>]

On Tue, Apr 11, 2000 at 03:10:56PM -0600, Gary Thomas wrote:

> Ah the joys of importing old code :-)

Yup. ;)

> Indeed, the correct solution will need to use proper kernel
> synchronizers. We'll need to look at this more closely to
> determine a proper solution.
> 
> The things to think about are:
>  * Do we need a single synchronizer or one per socket buf?

On a heavy-duty system with lots of network traffic, having a
single, global mutex for sb structures would probably cause a
noticable performance hit.  For systems like mine that
generally only have one or two sockets open, a single mutex
probably won't slow things down any.

I'd lean towards doing whatever's simplest, then worrying about
performance issues later (if there are, in fact, performance
issues later).

>  * If more than one will be used:
>    * how do they get allocated?  part of the socketbuf itself?
>    * how are they initialized?  destroyed?

I haven't looked at the socketbuf stuff in enough detail to
have an opinion on that just yet.

>  * Are there other such critical data structures, similarly "protected"?

Good question.  Anything messing with the mbuf pool (allocating
or freeing an mbuf) probably needs to be looked at, especially
since this is (I think) also called from a DSR context when a
packet is received.

> > Second, tcp_echo 
> > ----------------
[...]
> > When running the tcp_echo program with the default task
> > priorities, there are long pauses in IP traffic (1 to 10
> > seconds).  Sometimes things clog up long enough that we run out
> > of mbufs and panic. If the priorities are changed to
> > 
> >#define IDLE_THREAD_PRIORITY     CYGPKG_NET_THREAD_PRIORITY+3
> >#define LOAD_THREAD_PRIORITY     CYGPKG_NET_THREAD_PRIORITY+1
> >#define MAIN_THREAD_PRIORITY     CYGPKG_NET_THREAD_PRIORITY-0
> > 
> > then data flows smoothly, and things never back up by more than
> > one ethernet packet.
> > 
> > Having the main thread priority at the old, higher level
> > (CYGPKG_NET_THREAD_PRIORITY-2) appears to prevent the network
> > task from running and processing incoming packets.  
> > 
> > 
> > Q: Why can't the network task run when the main thread is
> >    blocked on a read()?
> 
> This one may be related or not, it's not immediately clear.
> 
> I suggest that we solve problem #1 and see where that leads.

That sounds like a plan to me.  My application development
effort is not currently being delayed by either of these since
setting application priority == network priority seems to fix
both.

I would guess that using the queueing scheduler, disabling
timeslicing, and having all user tasks that do network stuff
run at the same priority as the network task will provide
something like the "single-thread of execution until we
explicitly do something to block" environment from which the
TCP/IP code was borrowed. 

Oh, except maybe for conflicts between DSRs and user tasks...

> > I don't know if these two situations are related or not, but
> > I'd like to take a shot at trying to fix them -- any clues
> > anybody would care to lend would be appreciated.
> 
> I appreciate your care looking into these problems.  Remember
> that this is "beta" code - we ourselves are sure that bugs
> remain.  

Certainly. 

> That said, a cooperative effort in finding good solutions seems
> to be a track that will benefit us all.

I've currently got a couple other things to do (But don't we
all -- I'm trying to package up some of my stuff as .epk
files). 

So if somebody more familiar with the code than I wants to work
on it, I'd be more than happy to keep my fingers out of the
pie.  :)

-- 
Grant Edwards
grante@visi.com