From nobody Sat Feb 24 23:24:22 2024 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Tj2yZ6SRtz5BpRL for ; Sat, 24 Feb 2024 23:24:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Tj2yZ5Qfvz4hwB for ; Sat, 24 Feb 2024 23:24:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1708817062; a=rsa-sha256; cv=none; b=aUUsxyfyAmptKruDYGN4J0R8q9AyL9DkSCdZiaOjwYUHMJj65zmJlDXY0l/H6YovQrmGCT aSRSoZamIw3LJRdB3G0xuwHkdO2xPtvmNa2Q6GFAreZkW1ZXOvmAbyBKJdCnNk76iwrcgq avqJ56Cxb/ZbcPl32XjLRB+LNZyETsjBaCzxDVaicT2J2pHIOaYyIXbv9nAC9TPERX5lRw IbYS0AyT1cN3bIwXZ0NcGZpZIzcBYkMskSJlUbsxkFKF59b0DfhVHy79r93fLLL6H9SVDW y8xlznI3ghEKjJ7aXRxqkRgeDACzqqrNtDT0YWs/TSQtKPqxbMJ1d+7yraRGNQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1708817062; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=f6ovtUmTiOmzQEEhKQ4RW+Q/AAKL2UQHexSxj5Ri2x8=; b=JFJRj4P0J53Mlf5qxyEvZJVPmxIOIuwKNUG8LsTPAYHXt260g/UgPWw8DmHYFqPz2uUu6h Kj2Zi3/cziqGP38anMW+2MyQw1YHRsliWKzIHmyR4lGiRQqJ1PHg2OHgqfDIM4SgL1LAxB e5cNSSoOCN2nEcU5QkQ+lSooB80NurTI6A5Jzab49qjdy3T1Gwaqxq5Nm3EaLwH+EuVedT FLuEl8X+cXVHNmVx2LR9rEzln4nzCndSathAUEpvZO1j1eQ7KAceb/IIBLsyk9oLdN0LPZ o2Q5zHHaHI2RPNB+d8/DKnraktsxos+HZwaudQaeAX8ZU9xa7jTa+LV1fGuAMg== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Tj2yZ4Tp9zKg2 for ; Sat, 24 Feb 2024 23:24:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 41ONOMR0041839 for ; Sat, 24 Feb 2024 23:24:22 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 41ONOMmR041838 for net@FreeBSD.org; Sat, 24 Feb 2024 23:24:22 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 276890] Getting fq_codel correct on inbound shaping Date: Sat, 24 Feb 2024 23:24:22 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: dave.taht@gmail.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D276890 --- Comment #4 from Dave Taht --- 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.=