Re: ALTQ modifications proposal

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Sun, Jun 22, 2025 at 03:52:30PM +0000, Emmanuel Nyarko wrote:
> 
> 
> > On 22 Jun 2025, at 2:54???PM, Thor Lancelot Simon <tls%panix.com@localhost> wrote:
> > 
> > On Sat, Jun 21, 2025 at 03:19:14PM +0100, David Brownlee wrote:
> >> 
> >> If there really no useful setups which fq-codel could replace?
> >> Including "I need to simulate packet loss and odd bandwidth behaviour
> >> to stress my other systems"?
> > 
> > I use 'tc' at work to simulate WAN conditions when testing a number of
> > Linux-based products.  To my knowledge, the "queueing disciplines" used for
> > this purpose have nothing to do with fq-codel, and it can't replace them.
> > 
> Okay then for use case, i would leave it. The whole plan was to have HFSC + fq codel. 
> one scheduler and one queuing. but then again, i think I will leave it and find another way out.

I think the *ability* to have more than one queueing discipline is important.
Whether all (or most!) of the disciplines we already have should remain,
though, is I think a different question.

To my knowledge, in NetBSD, we don't have anything like Linux's netem
scheduler that I mention above.  But I think we should maintain enough
pluggability that we *could* have that or other enhancements instead of
being locked into HFSC+FQ-Codel and nothing else.  What if someone decides
to implement COBALT or another one of the CoDel derivatives?  There should
be a non-horrible way to plug it in, ideally without even rebooting the
system.

I also think it is worth doing as much as possible to develop some kind of
migration automation or, at least, guidance for existing ALTQ users,
though I think there are not so many.

Thor