From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 237141B915 for ; Fri, 9 Jun 2023 17:16:16 +0000 (UTC) Received: from vps0.lunn.ch (vps0.lunn.ch [156.67.10.101]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 81097E4A; Fri, 9 Jun 2023 10:16:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=fJHuQ8zacvpe7ZvXvHuaj0SxXvb3ZjOuhHjQXHcZ+tc=; b=mBz5wKWg4QpH7XJ7Um49Ge35eK 21DL30tvw1vdJEcJM4x7mEM3JRl7ClTuABp7L1eX3yXFf7YfJEZgfRS7KujAduEaLEAQb0DXL6X67 EUHo0181Ghca2uYi9fsz+QAV9TD8dPenVCHeaOxSPTVnGDFHgF+zUq+Psc0aMlyjd478=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1q7fiW-00FMuM-A0; Fri, 09 Jun 2023 19:16:04 +0200 Date: Fri, 9 Jun 2023 19:16:04 +0200 From: Andrew Lunn To: Alexis =?iso-8859-1?Q?Lothor=E9?= Cc: Florian Fainelli , Vladimir Oltean , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Thomas Petazzoni , paul.arola@telus.com, scott.roberts@telus.com Subject: Re: [PATCH net-next 2/2] net: dsa: mv88e6xxx: implement egress tbf qdisc for 6393x family Message-ID: <176f073a-b5ab-4d8a-8850-fcd8eff65aa7@lunn.ch> References: <20230609141812.297521-1-alexis.lothore@bootlin.com> <20230609141812.297521-3-alexis.lothore@bootlin.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net > Yes, I can do that (or maybe -EINVAL to match Vladimir's comment ?). I think > it's worth mentioning that I encountered an issue regarding those values during > tests: I use tc program to set the tbf, and I observed that tc does not even > reach kernel to set the qdisc if we pass no burst/latency value OR if we set it > to 0. So tc enforces right on userspace side non-zero value for those > parameters, and I have passed random values and ignored them on kernel side. That is not good. Please take a look around and see if any other driver offloads TBF, and what they do with burst. > Checking available doc about tc-tbf makes me feel like that indeed a TBF qdisc > command without burst or latency value makes no sense, except my use case can > not have such values. That's what I struggled a bit to find a proper qdisc to > match hardware cap. I may fallback to a custom netlink program to improve testing. We don't really want a custom application, since we want users to use TC to set this up. Looking at the 6390 datasheet, Queue Counter Registers, mode 8 gives the number of egress buffers for a port. You could validate that the switch has at least the requested number of buffers assigned to the port? There is quite a bit you can configure, so maybe there is a way to influence the number of buffers, so you can actually implement the burst parameter? Andrew