Charles M. Hannum wrote:
> >         to migrate to ALTQ gradually, we need to kee if_qflush() until
> >         all the drivers are rewritten.  if_qflush() certainly works for
> >         non-ALTQ drivers (correct me if i'm wrong).
> 
> Okay, that may be.  However, it's quite dangerous to leave an
> interface there that will break if it's used -- and it seems clear
> that people want to ALTQify everything *.

It's my oversight in porting ALTQ onto NetBSD.
if_qflush() in kame/freebsd4 is safe for use with ALTQ.

> >         not sure i understand the concern, but IFQ_PURGE() may be
> >         expanded into ALTQ_PURGE().
> 
> No, it is never `expanded into ALTQ_PURGE()'.  It is expanded into
> some big conditional which *may* do an ALTQ_PURGE().  My point was
> that test could just as well go in if_qflush().  There is no reason to
> have an inlined macro for it at all.  Actually, it's a waste of space.

Defining it as a macro is just for consistency.
ALTQ defines 4 queue operations: enqueue, dequeue, poll, and purge.
The first 3 are defined as macros so that it is more consistent to
define a macro for purge.
(IFQ_PURGE() can simply call if_qflush() on NetBSD but if_qflush() is
static on FreeBSD.)

> * I'll just note that at Nxkxa we found software QoS really wasn't
>   useful for much on `high speed' interfaces because the length of the
>   feedback cycle from the driver to allow more packets to be queued
>   couldn't be reduced enough without causing gaps during full-rate
>   bursts.  Using it strictly for constant-rate bandwidth-limiting
>   worked okay, but that was about it.  But I digress.

Well, software QoS may not be fast enough for a high-speed interface
but it would help if a slower interface exists on the same machine.
A congestion occurs when traffic flows from a fast interface to a slow
interface.

Also, I think you have GbE in mind for "high-speed".
A few years ago, I heard the same argument for fast-ethernet.

-Kenjiro