> On 21 Jun 2025, at 2:19 PM, David Brownlee <a...@absd.org> wrote:
>
> On Thu, 19 Jun 2025 at 01:25, Emmanuel Nyarko <emmankoko...@gmail.com> wrote:
>>
>>> On 18 Jun 2025, at 6:54 PM, Emmanuel Dreyfus <m...@netbsd.org> wrote:
>>>
>>> On Wed, Jun 18, 2025 at 03:11:30PM +0000, Emmanuel Nyarko wrote:
>>>> 1. Remove all the existing disciplines (openBSD has taken this step
>>>> already)
>>>
>>> That will break the setups of long-time users.
>>>
>>> But if fq-codel is able to replace all existing disciplines, perhaps
>>> you could keep the existing configuration keywords for other disciplines,
>>> and use them to configure fq-codel to emulate the old disciplines.
>>
>> sadly, that doesn’t look possible. Fq-codel is just three params(IRC) and
>> the rest are a lot for a single queue.
>
> 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"?
>
> If so, I think there are two aspects to "replace everything with fq-codel":
>
> - Can existing configuration syntax recognised and mapped to fq-codel
> (likely with a run-time warning), which could be done in one of two
> ways
> - Map each existing discipline to a given default fq-codel config
> - As above, but take some subset of the params to adjust fq-codel
> (very much only a subset)
>
> Given the above, would there be any significant functional regressions
> in any existing ALTQ installations were converted to fq-codel?
>
> Thanks
>
> David
https://undeadly.org/cgi?action=article;sid=20140419151959
this is what OpenBSD has done, i looked into it kind of was convincing me
enough.
But then, i can actually leave the old ones and add fq-codel separtely on a
different design so we can easily modularize and also become easily extensible
in other modular systems.(maybe would be a hard one) but I would look into it.
Emmanuel
