Date: Sat, 24 Feb 2024 23:24:22 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 276890] Getting fq_codel correct on inbound shaping Message-ID: <bug-276890-7501-bsAJcle2El@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-276890-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-276890-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D276890 --- Comment #4 from Dave Taht <dave.taht@gmail.com> --- Assuming I am looking at a correct source tree: http://fxr.watson.org/fxr/source/netpfil/ipfw/dn_sched_fq_codel.c#L330 Logging an overflow event twice, and to the console, while under stress, is= not a good idea. if (mainq->ni.length > schk->cfg.limit) { D("over limit"); 331 /* find first active flow */ 332 for (maxidx =3D 0; maxidx < schk->cfg.flows_cnt; maxi= dx++) 333 if (si->flows[maxidx].active) 334 break; 335 if (maxidx < schk->cfg.flows_cnt) { 336 /* find the largest sub- queue */ 337 for (i =3D maxidx + 1; i < schk->cfg.flows_cn= t; i++)=20 338 if (si->flows[i].active && si->flows[i].stats.length > 339 si->flows[maxidx].stats.lengt= h) 340 maxidx =3D i; 341 codel_drop_head(&si->flows[maxidx], si); 342 D("maxidx =3D %d",maxidx); 343 drop =3D 1; 344 } 345 } I would delete both Ds here. Even then there are two things we ended up doi= ng in the linux version - 1) We added the drop_batch facility (and optimized i= t) to drop up to 64 packets at a time from the head (all but the last - it hel= ps to always deliver at least the last packet in the queue).=20=20 It was *very* expensive under a packet flood to hit this limit, search the = flow list, then drop a single packet. 2) Also merely dropping the packet without also telling the AQM to drop har= der on its own led to persistent hitting of this spot. So we also incremented t= he codel count variable on this drop in the expectation the AQM would eventual= ly catch up. 3) It is possible to keep extra state around to always track the fattest qu= eue (see fq_codel_fast) and eliminate this non-O(1) search, at the cost of trac= king the fattest queue elsewhere. The expectation is that in normal use, this routine is rarely hit. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-276890-7501-bsAJcle2El>