Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp3976600pxb; Tue, 25 Jan 2022 00:27:06 -0800 (PST) X-Google-Smtp-Source: ABdhPJxCP20cGNNObyePP+EOyx6bs0qKOQzGyD15I/hf5q4TB8+5fNfbf0P2PZVOOYlefS2WkPHh X-Received: by 2002:a17:906:6d95:: with SMTP id h21mr14758983ejt.190.1643099226009; Tue, 25 Jan 2022 00:27:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643099226; cv=none; d=google.com; s=arc-20160816; b=rf7K3reSGLK+s5hiKKGeE5w74qX9kGwMKTXJQNaMteKtLhgGhXyr7Bckz9QpDT2A2r f/j4yXlPq09qkeMrXecdguNOkPY0DeHjVvXtEuoculgdJfgxZI6Xq/kax6/2TM08OFqw Ew9DksAA3xop5IZmK59v7UHFHzA0DuF6Wtrx9a6tijt8xXYrapRqG6SQ1eHCBq805ur1 Rem2FpF0jT1eniSn9DIsXECxOz6iG5HuW2ZcDtz3N6gNm9rEtY7BSF/U/A5d8eBmVdTw ICQMdjqO5iHXEgrYg/Fs3XAQY8awsBOje6UiHWqZFN8buP/T0WYKt4rVNUfIOrTxNAq6 nLsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=EAmIxnTjHCRjIyntKYNZLN3JM4VvBvdxFKUIzswVA/Q=; b=hoUXAYlGRkDUNsNIN5KDiJxgEdyL6I7aUnen8WDI2xDS41R/KR5yNTZkO/7Z/ykFYL Ljhmc8X/USiLjEKIyahH3hG80/BfMAHs8lE2epy2tHZx3uMBgzEsjKfzRfE2gEd/Kg6P oIGSleeoG1BHY0t61FV/Ynk+QLn3jsFAmDzZsYrimvA5VQQAOXX7YyEXzdpXTPOFQ0cK giPXsedfo7vkzUna5uIjSuw+OGarVI0h3SQ4qnMXtkn1RXoTBopIjzP+6pa7dIWn517e 21ohjMhbS4J9LAPih1bUbgWc+dNrc8nMI1bRPojhRHseRpYZsx1xUFQHuYrkRxCljf6i dtWQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=HWK0YOvX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v6si4282113ejk.470.2022.01.25.00.26.41; Tue, 25 Jan 2022 00:27:05 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=HWK0YOvX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S3420949AbiAYCZw (ORCPT + 99 others); Mon, 24 Jan 2022 21:25:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51206 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346497AbiAXTYY (ORCPT ); Mon, 24 Jan 2022 14:24:24 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B102CC0619C0; Mon, 24 Jan 2022 11:11:26 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 4F0F061323; Mon, 24 Jan 2022 19:11:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 15BA8C340E5; Mon, 24 Jan 2022 19:11:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643051485; bh=6lQU0+cS4us3o8O5T5OXmu4m7DtYZh4U7NdVeChhcAo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HWK0YOvXpo4ULzOK8ZKs7Isui5hK7epFnF4r4gpZO7Trt8HbTs52WZMN32qofzyM9 2FQuYyMRRqTh8rgD43pw6XUvcq8ToHKYbChM0ebzmBhOrX0VaDbmgKWH71ZP4QxkBK Dj5XjS6knVcXqNEhmfs0R8EKxTuaSKRHI0LLfLNY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kevin Bracey , Eric Dumazet , Jiri Pirko , Vimalkumar , Jakub Kicinski Subject: [PATCH 4.14 176/186] net_sched: restore "mpu xxx" handling Date: Mon, 24 Jan 2022 19:44:11 +0100 Message-Id: <20220124183942.775221370@linuxfoundation.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220124183937.101330125@linuxfoundation.org> References: <20220124183937.101330125@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Kevin Bracey commit fb80445c438c78b40b547d12b8d56596ce4ccfeb upstream. commit 56b765b79e9a ("htb: improved accuracy at high rates") broke "overhead X", "linklayer atm" and "mpu X" attributes. "overhead X" and "linklayer atm" have already been fixed. This restores the "mpu X" handling, as might be used by DOCSIS or Ethernet shaping: tc class add ... htb rate X overhead 4 mpu 64 The code being fixed is used by htb, tbf and act_police. Cake has its own mpu handling. qdisc_calculate_pkt_len still uses the size table containing values adjusted for mpu by user space. iproute2 tc has always passed mpu into the kernel via a tc_ratespec structure, but the kernel never directly acted on it, merely stored it so that it could be read back by `tc class show`. Rather, tc would generate length-to-time tables that included the mpu (and linklayer) in their construction, and the kernel used those tables. Since v3.7, the tables were no longer used. Along with "mpu", this also broke "overhead" and "linklayer" which were fixed in 01cb71d2d47b ("net_sched: restore "overhead xxx" handling", v3.10) and 8a8e3d84b171 ("net_sched: restore "linklayer atm" handling", v3.11). "overhead" was fixed by simply restoring use of tc_ratespec::overhead - this had originally been used by the kernel but was initially omitted from the new non-table-based calculations. "linklayer" had been handled in the table like "mpu", but the mode was not originally passed in tc_ratespec. The new implementation was made to handle it by getting new versions of tc to pass the mode in an extended tc_ratespec, and for older versions of tc the table contents were analysed at load time to deduce linklayer. As "mpu" has always been given to the kernel in tc_ratespec, accompanying the mpu-based table, we can restore system functionality with no userspace change by making the kernel act on the tc_ratespec value. Fixes: 56b765b79e9a ("htb: improved accuracy at high rates") Signed-off-by: Kevin Bracey Cc: Eric Dumazet Cc: Jiri Pirko Cc: Vimalkumar Link: https://lore.kernel.org/r/20220112170210.1014351-1-kevin@bracey.fi Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman --- include/net/sch_generic.h | 5 +++++ net/sched/sch_generic.c | 1 + 2 files changed, 6 insertions(+) --- a/include/net/sch_generic.h +++ b/include/net/sch_generic.h @@ -885,6 +885,7 @@ struct psched_ratecfg { u64 rate_bytes_ps; /* bytes per second */ u32 mult; u16 overhead; + u16 mpu; u8 linklayer; u8 shift; }; @@ -894,6 +895,9 @@ static inline u64 psched_l2t_ns(const st { len += r->overhead; + if (len < r->mpu) + len = r->mpu; + if (unlikely(r->linklayer == TC_LINKLAYER_ATM)) return ((u64)(DIV_ROUND_UP(len,48)*53) * r->mult) >> r->shift; @@ -916,6 +920,7 @@ static inline void psched_ratecfg_getrat res->rate = min_t(u64, r->rate_bytes_ps, ~0U); res->overhead = r->overhead; + res->mpu = r->mpu; res->linklayer = (r->linklayer & TC_LINKLAYER_MASK); } --- a/net/sched/sch_generic.c +++ b/net/sched/sch_generic.c @@ -1010,6 +1010,7 @@ void psched_ratecfg_precompute(struct ps { memset(r, 0, sizeof(*r)); r->overhead = conf->overhead; + r->mpu = conf->mpu; r->rate_bytes_ps = max_t(u64, conf->rate, rate64); r->linklayer = (conf->linklayer & TC_LINKLAYER_MASK); r->mult = 1;