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 7B3BFC433F5 for ; Tue, 7 Dec 2021 00:16:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 102CF6B0087; Mon, 6 Dec 2021 19:16:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0B38B6B0088; Mon, 6 Dec 2021 19:16:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EBE3D6B0089; Mon, 6 Dec 2021 19:16:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0093.hostedemail.com [216.40.44.93]) by kanga.kvack.org (Postfix) with ESMTP id DD0986B0087 for ; Mon, 6 Dec 2021 19:16:40 -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 A0B048249980 for ; Tue, 7 Dec 2021 00:16:30 +0000 (UTC) X-FDA: 78889081740.18.9766CD1 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf27.hostedemail.com (Postfix) with ESMTP id 23ECE700009B for ; Tue, 7 Dec 2021 00:16:29 +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 48D1BB81616; Tue, 7 Dec 2021 00:16:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9DCAAC004DD; Tue, 7 Dec 2021 00:16:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1638836187; bh=ciIFGHp3Vk2kFf/+PUEjEQ4ngbZLvWXxYi/dHbqk3k8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=h8rRCmCqKdoNfAwzurutCjozLRptHDGzg7A2uCUxo5DrlkTW9JoxTkvWmEWUb0dwg b+lXJbX7H4JXN7N5ZUpTxi0URdBKzDgrKcW635o/9OwgjZzRON1ZyANX3RLuvpSbkO I+ID4ZBvZDNblZlXkzY9ffAQfi6fgqCoMx5pDwKBjtNj4CNMUyV/FMdu2oc5v1Tqv2 M0/EXGBtz1QJX1EvMzwbSDlWVPuPmdGty0YwbEB+Y+/RhjLB6QG+T9OjfkoOHJx1AL 6JjnjdoLqHxXFsl4CQqBZpQGMraSeySQLB2Nptao1wYvmeFwyJrCfj5j/dtBuVkFVe rEQ2W2tOOhsmA== Date: Mon, 6 Dec 2021 16:16:25 -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@lge.com, akpm@linux-foundation.org, vbabka@suse.cz Subject: Re: [RFC net-next 2/2] ipv6: ioam: Support for Buffer occupancy data field Message-ID: <20211206161625.55a112bb@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> In-Reply-To: <20211206211758.19057-3-justin.iurman@uliege.be> References: <20211206211758.19057-1-justin.iurman@uliege.be> <20211206211758.19057-3-justin.iurman@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: 23ECE700009B X-Stat-Signature: jozuioe4g3oxjma6kiaje77tthg7o1g8 Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=h8rRCmCq; spf=pass (imf27.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: 1638836189-533003 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 Mon, 6 Dec 2021 22:17:58 +0100 Justin Iurman wrote: > This patch is an attempt to support the buffer occupancy in IOAM trace > data fields. Any feedback is appreciated, or any other idea if this one > is not correct. > > The draft [1] says the following: > > The "buffer occupancy" field is a 4-octet unsigned integer field. > This field indicates the current status of the occupancy of the > common buffer pool used by a set of queues. The units of this field > are implementation specific. Hence, the units are interpreted within > the context of an IOAM-Namespace and/or node-id if used. The authors > acknowledge that in some operational cases there is a need for the > units to be consistent across a packet path through the network, > hence it is recommended for implementations to use standard units > such as Bytes. > > An existing function (i.e., get_slabinfo) is used to retrieve info about > skbuff_head_cache. For that, both the prototype of get_slabinfo and > struct definition of slabinfo were moved from mm/slab.h to > include/linux/slab.h. Any objection on this? > > 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 > > Thoughts? Implementing the standard is one thing but how useful is this in practice?