> On 22 Jun 2025, at 4:39 PM, Thor Lancelot Simon <t...@panix.com> 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 <t...@panix.com> 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
