Re: ALTQ modifications proposal

> On 22 Jun 2025, at 4:39 PM, Thor Lancelot Simon <[email protected]> wrote:
> 
> On Sun, Jun 22, 2025 at 03:52:30PM +0000, Emmanuel Nyarko wrote:
>> 
>> 
>>> On 22 Jun 2025, at 2:54???PM, Thor Lancelot Simon <[email protected]> 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.

100% agreed Thor.
> 
> 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.

Exactly. I think that is exactly where I am driving to. A pragmatic design change will be beneficial.
I will look into that. 
> 
> 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


Emmanuel