Re: ALTQ modifications proposal

David Brownlee <[email protected]>
Newsgroups gmane.os.netbsd.devel.network,gmane.os.netbsd.devel.kernel
Message-ID <CAGN_6pbL-UzhA7t2bh=kkJ1r=VkVgJWGVqXmoMaGh2H+LwOq_g@mail.gmail.com>
On Thu, 19 Jun 2025 at 01:25, Emmanuel Nyarko <[email protected]> wrote:
>
> > On 18 Jun 2025, at 6:54 PM, Emmanuel Dreyfus <[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.