From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9A653C433EF for ; Fri, 10 Dec 2021 00:38:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2DD2B6B0072; Thu, 9 Dec 2021 19:38:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 28AB16B0075; Thu, 9 Dec 2021 19:38:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 17A606B0078; Thu, 9 Dec 2021 19:38:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay028.a.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 090F66B0072 for ; Thu, 9 Dec 2021 19:38:45 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id A1B9020481 for ; Fri, 10 Dec 2021 00:38:34 +0000 (UTC) X-FDA: 78900023748.03.8DC068C Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf29.hostedemail.com (Postfix) with ESMTP id 68B8B120004 for ; Fri, 10 Dec 2021 00:38:33 +0000 (UTC) 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 ams.source.kernel.org (Postfix) with ESMTPS id 269B5B82707; Fri, 10 Dec 2021 00:38:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DB38AC004DD; Fri, 10 Dec 2021 00:38:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1639096710; bh=Sb3LAGXpJbXC+1BbG8AmJEvr07/8fuakDH3zuzWX9pg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Zub1si5/dg2Ji/Dx6iz37BiGzub9k3FsmFJxzfLylBmsjub6Hs+VhLFVIC/C7YQwA bIqxx7zcbaDkL7CJegbi50tMQaPVX0ZIstgp7tp7IKEPayXBSOgzZbOlBkPlneC8C5 dOhtOwIYr3eRh0zut+/hvENLogE/SocpFL+T1C3+Eg8uQzq+fZLnrm+mRzu+zraX7e 7xtkf0K3GoiaFGsOIrsA/CgkX1SW864X/Wc51IRSS2a9BWhVc3TeXCbE2VxJVaE0EL olyTH83wFIk5T8yysomEkS1ACYGwroufDC9N7o6FzAk8XXptYh3VQnc7VyBwQcokeJ wfMtXF328p8Xg== Date: Thu, 9 Dec 2021 16:38:28 -0800 From: Jakub Kicinski To: Justin Iurman Cc: netdev@vger.kernel.org, davem@davemloft.net, dsahern@kernel.org, yoshfuji@linux-ipv6.org, linux-mm@kvack.org, cl@linux.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo kim , akpm@linux-foundation.org, vbabka@suse.cz, Roopa Prabhu , Nikolay Aleksandrov , Andrew Lunn , Stephen Hemminger , Vladimir Oltean , Florian Fainelli , Florian Westphal , Paolo Abeni Subject: Re: [RFC net-next 2/2] ipv6: ioam: Support for Buffer occupancy data field Message-ID: <20211209163828.223815bd@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> In-Reply-To: <1067680364.223350225.1639059024535.JavaMail.zimbra@uliege.be> References: <20211206211758.19057-1-justin.iurman@uliege.be> <20211206161625.55a112bb@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <262812089.220024115.1638878044162.JavaMail.zimbra@uliege.be> <20211207075037.6cda8832@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <1045511371.220520131.1638894949373.JavaMail.zimbra@uliege.be> <20211207090700.55725775@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <1665643630.220612437.1638900313011.JavaMail.zimbra@uliege.be> <20211208141825.3091923c@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <1067680364.223350225.1639059024535.JavaMail.zimbra@uliege.be> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 68B8B120004 X-Stat-Signature: 4y8dab4htj1psr3nawabegkzmc3uyhey Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="Zub1si5/"; spf=pass (imf29.hostedemail.com: domain of kuba@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=kuba@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-HE-Tag: 1639096713-319130 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, 9 Dec 2021 15:10:24 +0100 (CET) Justin Iurman wrote: > > because Linux routers can run a full telemetry stack and all sort > > of advanced SW instrumentation. The use case for reporting kernel > > memory use via IOAM's constrained interface does not seem particularly > > practical since it's not providing a very strong signal on what's > > going on. > > I agree and disagree. I disagree because this value definitely tells you > that something (potentially bad) is going on, when it increases > significantly enough to reach a critical threshold. Basically, we need > more skb's, but oh, the pool is exhausted. OK, not a problem, expand the > pool. Oh wait, no memory left. Why? Is it only due to too much > (temporary?) load? Should I put the blame on the NIC? Is it a memory > issue? Is it something else? Or maybe several issues combined? Well, you > might not know exactly why (though you know there is a problem), which is > also why I agree with you. But, this is also why you have other data > fields available (i.e., detecting a problem might require 2+ symptoms > instead of just one). > > > For switches running Linux the switch ASIC buffer occupancy can be read > > via devlink-sb that'd seem like a better fit for me, but unfortunately > > the devlink calls can sleep so we can't read such device info from the > > datapath. > > Indeed, would be a better fit. I didn't know about this one, thanks for > that. It's a shame it can't be used in this context, though. But, at the > end of the day, we're left with nothing regarding buffer occupancy. So > I'm wondering if "something" is not better than "nothing" in this case. > And, for that, we're back to my previous answer on why I agree and > disagree with what you said about its utility. I think we're on the same page, the main problem is I've not seen anyone use the skbuff_head_cache occupancy as a signal in practice. I'm adding a bunch of people to the CC list, hopefully someone has an opinion one way or the other. Lore link to the full thread, FWIW: https://lore.kernel.org/all/20211206211758.19057-1-justin.iurman@uliege.be/