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. 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
