Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp4959530ybc; Fri, 15 Nov 2019 12:40:41 -0800 (PST) X-Google-Smtp-Source: APXvYqwf2ry9nsKjhwS3Ib3a46l6WMiNexkHvoTI82DPcEqaX0eC03jE61EHsPZj70ahJ+pTQry0 X-Received: by 2002:a17:906:ecb8:: with SMTP id qh24mr3497849ejb.174.1573850441549; Fri, 15 Nov 2019 12:40:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573850441; cv=none; d=google.com; s=arc-20160816; b=VyUWe5kgDSvm/Rq5WcdBAr03IlGRC4DkTQkiabN39UOO3vT/VsHEUOAxwVntCTT4ta IEtYxcnM3JaeNenGbphRLtbJZLFZsII5bcYD7GsQX4kfkbBBOlc2S+rtE3jRXDFzgACo v3RBt0sbMwVEBpK56uOdM80efIA/kQuRNwbxTkiNt+CJW5CktAPWVI0erZE06I5WhAU3 6PuyHlzTz/ExzBy2t34K75UGu0/oWayAodMDyTHZqDEa4og83pigJmv+mbCzTddiHMLY Ok2GCv8KoaNNyc6XqrrPTXpa9HtQ2OVUaq9rbzLnmuq4+xD73W12CX6VZqZ1MLjaiTM3 CHUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=sTcLhwvIMhlqP/s/7QCSwHIRuZ9rOIYUpZfr1zzirzY=; b=LKUlkjDHy2yFRPo6jbQeCh0ICdWlqZ+VBwNA1Qi3DAMrDbrmO+lmSfPkXu1SB+RXOt RY0ejunl+kNTDpJRRZgaEkkY/K7DLOb+oazHpYPznSvFLV6K8UCgz3a3sxBMGfFBxBas upxPi1+iqPvLr6GMA0e6XL6jfll/IMXM66AE0Yg9AcYZxFpO2kT3wQ+5EcybOZkJtqu6 xVUsGTc6z9tLLVspd0Zwx4eXVSk43nYTWk1GGthLpSIjMuNAzIEOPH9MFBYDJt3MTy8j MjoOSnZOKVfDnZpcKAEw+EdFGUHVVmIPdJYgDVCqicpfDOMmidbt5StAMMt9GExU2/aR caJQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="cvgK/nC3"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e48si7935436ede.207.2019.11.15.12.40.16; Fri, 15 Nov 2019 12:40:41 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="cvgK/nC3"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726818AbfKOUiw (ORCPT + 99 others); Fri, 15 Nov 2019 15:38:52 -0500 Received: from mail-ed1-f68.google.com ([209.85.208.68]:44684 "EHLO mail-ed1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726549AbfKOUiw (ORCPT ); Fri, 15 Nov 2019 15:38:52 -0500 Received: by mail-ed1-f68.google.com with SMTP id a67so8458664edf.11; Fri, 15 Nov 2019 12:38:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sTcLhwvIMhlqP/s/7QCSwHIRuZ9rOIYUpZfr1zzirzY=; b=cvgK/nC3KBowcn7VWNctBq67Zjhrogzf+pKX091gF8wMMklXrkKkxC/qh+L8sjxbkb jlzFGtSrgPj4RqO7s2+vYId1X3oV7PbtcRJRsTFxRCN5QpKsxcHGD020t8u3/myjhD6v TeNKrw3p8HMXimZkoIZLpkO57Pg0vUvHr7WuVBuk3EjLezIettb6kLUV//ogvqPdHogn fcAOW7iyOyPIMtfMA2zIpjqaiGFXAlvPy6etcoeXR9FhZFjk/YlG5oG9rFC5OQEwr0HM 46yNdS4wj2C9y8Xd2V38RaGcY26nCEsDIdpPok0hiMH2631bTfp+4iN3h9VPKcnGviG0 X0SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sTcLhwvIMhlqP/s/7QCSwHIRuZ9rOIYUpZfr1zzirzY=; b=EGDlK4Bi5zcoiYmzzaQAI5lPVI8bfBaDQSMzPeS81ETKqnXCJIHtDLxVc97NsVVZ8m uiepHI2c9YMGbLSCmaCJcnCLRAjTJFbZ5k1a5iXZGBmmgllLrYxibaQ08e6FZI3UFcMe GDIuam2KS9QtOP7ybDz/hfe51/2iSoaSNx39H4I+Ek7DMf1MC8k5Zw4kyzQBxp7yBEbF Sl0OtZ53l+uW4Al2H6ZxhhwKU9SRVru4wuN1XON13HH21wCYix1OxrXg47DO0wocN+OY XsYWugIHwuTt3L/W/a/9jOxrOWaN6xSXrFxkGdUoaanjfisr3MFIC86MDKpeiNsHV7y8 Q+BA== X-Gm-Message-State: APjAAAVcE1zOeQysSdDJrOp4uPpoPR3wAn+ELl9f/wBGTh4uMpPdFgXR ux7gCJ3BR++wwGKxTtl855eHVsn6hXI59qF5sKg= X-Received: by 2002:a17:906:d210:: with SMTP id w16mr3708950ejz.86.1573850328320; Fri, 15 Nov 2019 12:38:48 -0800 (PST) MIME-Version: 1.0 References: <20191115015607.11291-1-ivan.khoronzhuk@linaro.org> In-Reply-To: <20191115015607.11291-1-ivan.khoronzhuk@linaro.org> From: Vladimir Oltean Date: Fri, 15 Nov 2019 22:38:37 +0200 Message-ID: Subject: Re: [net-next PATCH] taprio: don't reject same mqprio settings To: Ivan Khoronzhuk Cc: netdev , "David S. Miller" , Vinicius Costa Gomes , Jamal Hadi Salim , Cong Wang , Jiri Pirko , lkml Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 15 Nov 2019 at 03:58, Ivan Khoronzhuk wrote: > > The taprio qdisc allows to set mqprio setting but only once. In case > if mqprio settings are provided next time the error is returned as > it's not allowed to change traffic class mapping in-flignt and that > is normal. But if configuration is absolutely the same - no need to > return error. It allows to provide same command couple times, > changing only base time for instance, or changing only scheds maps, > but leaving mqprio setting w/o modification. It more corresponds the > message: "Changing the traffic mapping of a running schedule is not > supported", so reject mqprio if it's really changed. > > Signed-off-by: Ivan Khoronzhuk > --- Reviewed-by: Vladimir Oltean Tested-by: Vladimir Oltean I would even kindly suggest a tag: Fixes: a3d43c0d56f1 ("taprio: Add support adding an admin schedule") since the patch is doing nothing but making the tc-taprio command idempotent, aka running it 10 times in a row produces the same result. Previously, it would have worked the first time but failed the rest of 9 times, which is catastrophic for any sort of scripted environments. It should have behaved like this from the beginning. The problem is that it conflicts trivially with 9c66d1564676 ("taprio: Add support for hardware offloading"), which made its appearance in 5.4. It's up to you if you want to rebase this on top of 5.4 as well, for the stable trees. > net/sched/sch_taprio.c | 24 ++++++++++++++++++++++++ > 1 file changed, 24 insertions(+) > > diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c > index 7cd68628c637..bd844f2cbf7a 100644 > --- a/net/sched/sch_taprio.c > +++ b/net/sched/sch_taprio.c > @@ -1347,6 +1347,26 @@ static int taprio_parse_clockid(struct Qdisc *sch, struct nlattr **tb, > return err; > } > > +static int taprio_mqprio_cmp(struct net_device *dev, > + struct tc_mqprio_qopt *mqprio) > +{ > + int i; > + > + if (mqprio->num_tc != dev->num_tc) > + return -1; > + > + for (i = 0; i < mqprio->num_tc; i++) > + if (dev->tc_to_txq[i].count != mqprio->count[i] || > + dev->tc_to_txq[i].offset != mqprio->offset[i]) > + return -1; > + > + for (i = 0; i < TC_BITMASK + 1; i++) Huh, odd, I wonder what's wrong with <= these days. I do see it's being used like that in 2 more places in the code, so let's opt for consistency. > + if (dev->prio_tc_map[i] != mqprio->prio_tc_map[i]) > + return -1; > + > + return 0; > +} > + > static int taprio_change(struct Qdisc *sch, struct nlattr *opt, > struct netlink_ext_ack *extack) > { > @@ -1398,6 +1418,10 @@ static int taprio_change(struct Qdisc *sch, struct nlattr *opt, > admin = rcu_dereference(q->admin_sched); > rcu_read_unlock(); > > + /* no changes - no new mqprio settings */ > + if (mqprio && !taprio_mqprio_cmp(dev, mqprio)) > + mqprio = NULL; > + > if (mqprio && (oper || admin)) { > NL_SET_ERR_MSG(extack, "Changing the traffic mapping of a running schedule is not supported"); > err = -ENOTSUPP; > -- > 2.20.1 >