altq and multi-core processing

[Beverly Schwartz <bschwart%bbn.com@localhost>]

We've observed a series of unusual problems when we have enabled
mutli-core with two processors.  We are using altq and pdf.

Perusing the altq code, I found this comment in altq_rmclass.c before
the function rmc_restart:

/*  
 * void
 * rmc_restart() - is just a helper routine for rmc_delay_action -- it is
 *      called by the system timer code & is responsible checking if the
 *      class is still sleeping (it might have been restarted as a side
 *      effect of the queue scan on a packet arrival) and, if so, restarting
 *      output for the class.  Inspecting the class state & restarting output
 *      require locking the class structure.  In general the driver is
 *      responsible for locking but this is the only routine that is not
 *      called directly or indirectly from the interface driver so it has
 *      know about system locking conventions.  Under bsd, locking is done
 *      by raising IPL to splnet so that's what's implemented here.  On a
 *      different system this would probably need to be changed.
 *       
 *      Returns:        NONE
 */      

Note the last two sentences:
 *      Under bsd, locking is done
 *      by raising IPL to splnet so that's what's implemented here.  On a
 *      different system this would probably need to be changed.

Looking through the altq code, there appears to be *no* locking done.
The only synchronization that appears to exist is calls to splnet.
While this will work on a single-processor system, I suspect some
of our unusual problems might be caused by contention in altq.  I
haven't dug deep enough to say more than this.

Anybody have any experience with this?

-Bev

---
Beverly Schwartz
BBN Technologies
bschwart%bbn.com@localhost