From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com [209.85.210.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 347ED3B2A4 for ; Tue, 11 Aug 2020 11:48:36 -0400 (EDT) Received: by mail-pf1-f169.google.com with SMTP id a79so7822404pfa.8 for ; Tue, 11 Aug 2020 08:48:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HAB4WFuu7/sHHtr1zYXud8vKMNUWzXDYTyZsWR95gBw=; b=UzgpIJxcwQgnVTtLYCDLxFrb8f5kKrw/QZpGseCIuqFyHMV8OPsGQHCZNUboYtM73g ZwaR0MLKjkV1FIQyAPeGcKxqdirs3Ngg+diZ49aCIw+QfSX8txFuSvBFUkq381q0f9W6 VvT0nmVGk5wMUumcLEJ7slKXD7AWOEY+5dPRrwXhyEOlazriL3+u8Ad6C6rn9LTnWGJK v9mqZeetyHGW1UvwvytCrj8RtYB37qE6ubb+Szd+McmRWE2IBAmzaDO2Y0ix1Xz7LqoJ bWqzUBgKrcmCBKGsSNvDetuMRwOehvqrc0jnQmYbd0S+7jDERXampJnhhO6k91sU9/Ua eCnA== X-Gm-Message-State: AOAM532LoY8Gpkqj+yn8YMlG73FRzN7et8Tg5jPltxbo8YOpKHQ073F8 K+nBf/XqBy5MALgheJkOOza/z8IcRIA= X-Google-Smtp-Source: ABdhPJzN07FCVnMhVbCZg5pNnh626nGjH/LvZGZBlRT1GBxQtDYgVqhQe+3T2NqSlFJ5T49VlAsTpQ== X-Received: by 2002:a63:4b0c:: with SMTP id y12mr1214508pga.199.1597160915318; Tue, 11 Aug 2020 08:48:35 -0700 (PDT) Received: from [192.168.130.24] (52-119-118-48.PUBLIC.monkeybrains.net. [52.119.118.48]) by smtp.gmail.com with ESMTPSA id d17sm3240021pjr.40.2020.08.11.08.48.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Aug 2020 08:48:34 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Simon Barber X-Priority: 3 In-Reply-To: Date: Tue, 11 Aug 2020 08:48:33 -0700 Cc: tomh@tomh.org, bloat@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <225a9c89-ac76-f21e-1450-5deeb3cd23eb@tomh.org> To: Jonathan Morton X-Mailer: Apple Mail (2.3608.80.23.2.2) Subject: Re: [Bloat] How about a topical LWN article on demonstrating the real-world goodness of CAKE? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 15:48:36 -0000 I=E2=80=99ve had good success adding GRO into the mix to reduce CPU = usage for WiFi APs with complex forwarding rules. The recent Qualcomm = chipsets and proprietary drivers support some parts of GRO and TSO in = firmware which helps. The kernel=E2=80=99s software GSO function = doesn=E2=80=99t work well for this purpose - it reallocates new skbs for = headers for all the packets it GSOs - but if you reused the existing = space in the skbs for headers, even software GSO could probably be quite = fast. I=E2=80=99ve yet to explore GRO by aggregate but it feels like a natural = fit since the wireless packets arrive in aggregates of up to a few 100 = frames, to GRO them together into one. Simon > On Aug 9, 2020, at 2:35 PM, Jonathan Morton = wrote: >=20 >> Are the risks and tradeoffs well enough understood (and visible = enough=20 >> for troubleshooting) to recommend broader deployment? >>=20 >> I recently gave openwrt a try on some hardware that I ultimately=20 >> concluded was insufficient for the job. Fairly soon after changing = out=20 >> my access point, I started getting complaints of Wi-Fi dropping in my=20= >> household, especially when someone was trying to videoconference. I=20= >> discovered that my AP was spontaneously rebooting, and the box was=20 >> getting hot. >=20 > Most CPE devices these days rely on hardware accelerated packet = forwarding to achieve their published specs. That's all about taking = packets in one side and pushing them out the other as quickly as = possible, with only minimal support from the CPU (likely, new = connections get a NAT/firewall lookup, that's all). It has the = advantages of speed and power efficiency, but unfortunately it is also = incompatible with our debloating efforts. So debloated CPE will tend to = run hotter and with lower peak throughput, which may be noticeable to = cable and fibre users; VDSL (FTTC) users might have service of 80Mbps or = less where this effect is less likely to matter. >=20 > It sounds like that AP had a very marginal thermal design which caused = the hardware to overheat as soon as the CPU was under significant load, = which it can easily be when a shaper and AQM are running on it at high = throughput. The cure is to use better designed hardware, though you = could also contemplate breaking the case open to cure the thermal = problem directly. There are some known reliable models which could be = collected into a list. As a rule of thumb, the ones based on ARM cores = are likely to be designed with CPU performance more in mind than those = with MIPS. >=20 > Cake has some features which can be used to support explicit = classification and (de)prioritisation of traffic via firewall marking = rules, either by rewriting the Diffserv field or by associating metadata = with packets within the network stack (fwmark). This can be very useful = for pushing Bittorrent or WinUpdate swarm traffic out of the way. But = for most situations, the default flow-isolating behaviour already works = pretty well, especially for ensuring that one computer's network load = has only a bounded effect on any other. We can discuss that in more = detail if that would be helpful. > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat