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 508A1C433EF for ; Tue, 7 Dec 2021 15:51:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AFA646B0096; Tue, 7 Dec 2021 10:50:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AA95F6B0098; Tue, 7 Dec 2021 10:50:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 971EF6B0099; Tue, 7 Dec 2021 10:50:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0231.hostedemail.com [216.40.44.231]) by kanga.kvack.org (Postfix) with ESMTP id 8ADE76B0096 for ; Tue, 7 Dec 2021 10:50:51 -0500 (EST) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 500A48249980 for ; Tue, 7 Dec 2021 15:50:41 +0000 (UTC) X-FDA: 78891435882.18.28B3AFA Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf03.hostedemail.com (Postfix) with ESMTP id DFA1820009 for ; Tue, 7 Dec 2021 15:50:40 +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 ED054B81852; Tue, 7 Dec 2021 15:50:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4E036C341C1; Tue, 7 Dec 2021 15:50:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1638892238; bh=vv7gsTKN6ixW9H1cANn0Y9rohZru9cc1fkVEMi05VTk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=N8XB4Wm4ecqjVwJU7U4Z8SthwWspUtqyWWyYU3q5YWZtBvctstN8z2KZkNWZdcWql tbS82IUxDfhzXg699V1ZoI+gELAc7xQOTVmI6Afijt+WTtRCfanGuLEms9VL7x843B BSZr6rhEhDVIMIJtIkYKdkNbs8Rl4ppw7je4m8tHB6MUusNhxUOofEaVDyd3G52gAC WzbzzcUGaJck/o/YvbXWzh7k/9Tyd+/kFJJ2HX3enV3qq/GfLYygrjYB/WZS/wjKhf rM2JwxvAKIi7da08dv3RuYEuGum7dGeFi2ec8wdO1/3kg9JI3aLAwUTaXh6ZTDUqNT 5fLNgdx+VOcyA== Date: Tue, 7 Dec 2021 07:50:37 -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 Subject: Re: [RFC net-next 2/2] ipv6: ioam: Support for Buffer occupancy data field Message-ID: <20211207075037.6cda8832@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> In-Reply-To: <262812089.220024115.1638878044162.JavaMail.zimbra@uliege.be> References: <20211206211758.19057-1-justin.iurman@uliege.be> <20211206211758.19057-3-justin.iurman@uliege.be> <20211206161625.55a112bb@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <262812089.220024115.1638878044162.JavaMail.zimbra@uliege.be> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: DFA1820009 X-Stat-Signature: d53rohsjd6mcwskt3qet4rgkp8rrkxot Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=N8XB4Wm4; spf=pass (imf03.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: 1638892240-474389 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 Tue, 7 Dec 2021 12:54:04 +0100 (CET) Justin Iurman wrote: > >> The function kmem_cache_size is used to retrieve the size of a slab > >> object. Note that it returns the "object_size" field, not the "size" > >> field. If needed, a new function (e.g., kmem_cache_full_size) could be > >> added to return the "size" field. To match the definition from the > >> draft, the number of bytes is computed as follows: > >> > >> slabinfo.active_objs * size > > > > Implementing the standard is one thing but how useful is this > > in practice? > > IMHO, very useful. To be honest, if I were to implement only a few data > fields, these two would be both included. Take the example of CLT [1] > where the queue length data field is used to detect low-level issues > from inside a L5-7 distributed tracing tool. And this is just one > example among many others. The queue length data field is very specific > to TX queues, but we could also use the buffer occupancy data field to > detect more global loads on a node. Actually, the goal for operators > running their IOAM domain is to quickly detect a problem along a path > and react accordingly (human or automatic action). For example, if you > monitor TX queues along a path and detect an increasing queue on a > router, you could choose to, e.g., rebalance its queues. With the > buffer occupancy, you could detect high-loaded nodes in general and, > e.g., rebalance traffic to another branch. Again, this is just one > example among others. Apart from more accurate ECMPs, you could for > instance deploy a smart (micro)service selection based on different > metrics, etc. > > [1] https://github.com/Advanced-Observability/cross-layer-telemetry Ack, my question was more about whether the metric as implemented provides the best signal. Since the slab cache scales dynamically (AFAIU) it's not really a big deal if it's full as long as there's memory available on the system.