double check me on this

[joel at OARcorp.com (joel at OARcorp.com)]

On Tue, 18 May 1999, Jay Kulpinski wrote:

> >
> >
> > I looked over a diff of the network stack from 4.0.0 until now and came
> > across a change I made to sys/mbuf.h.  In the original code, they used
> > names like "m" as macro parameters.  I changed all macro parameters to
> > _XXX to avoid naming conflicts.  If I messed up, I could have broken
> > something.  Here is a sample from the diff:
> >
> > 316,317c319,320
> > < #define       MH_ALIGN(m, len) \
> > <       { (m)->m_data += (MHLEN - (len)) &~ (sizeof(long) - 1); }
> > ---
> > > #define       MH_ALIGN(_m, _len) \
> > >       { (_m)->m_data += (MHLEN - (_len)) &~ (sizeof(long) - 1); }
> >
> > If you can double check me on this change, I would appreciate it.  All you
> > should have to do is diff sys/mbuf.h from 4.0.0 to the one in 19990426 and
> > make sure I did the substitutions right.  
> >
> > I doubt I broke anything but it does not hurt to check.
> 
> I did already run a recursive diff of libnetworking and didn't find 
> anything that looked like a problem.  I thought all of the 
> "m" to "_m" and similar changes were okay.  Inserting code to delay
> the transmitUdp sufficiently "fixes" the problem and allows all
> of the packets to go out.  

Personally, I would think that blocking for resources would be OK on a
send.  But I don't know how that compares to UNIX's behavior.  

> I also compiled my net device driver without any optimization (but not
> the whole network stack) to try to eliminated problems with volatility
> in the compilation, but the problem still occurred.

The CPU optimized checksum routines can make a big throughput difference.
It could have just tripped the balance.  The driver is likely bound to the
HW speed for register/memory access so optimization won't help much.

> I'll be trying to use a counting semaphore to keep track of 
> busy clusters.  I'll have to wait for this old creaky Pentium 90
> to finish first.  I hope this won't violate any internet RFCs
> or anything.

I don't know if it will but I can't see the counting semaphore hurting
unless it negatively impacts interrupts.  But most of the network
processing is done at the task level so it should be fine.  Unless it
violates an RFC.

--joel
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985