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 4D4BFC433F5 for ; Tue, 21 Dec 2021 17:23:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BD4FB6B008C; Tue, 21 Dec 2021 12:23:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B83E66B0095; Tue, 21 Dec 2021 12:23:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A4BE46B0098; Tue, 21 Dec 2021 12:23:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0024.hostedemail.com [216.40.44.24]) by kanga.kvack.org (Postfix) with ESMTP id 96B036B008C for ; Tue, 21 Dec 2021 12:23:42 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 5B4F81807CAD2 for ; Tue, 21 Dec 2021 17:23:42 +0000 (UTC) X-FDA: 78942473484.10.6581AEB Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) by imf17.hostedemail.com (Postfix) with ESMTP id 28BB94002F for ; Tue, 21 Dec 2021 17:23:30 +0000 (UTC) Received: by mail-ed1-f50.google.com with SMTP id b13so26284336edd.8 for ; Tue, 21 Dec 2021 09:23:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=TALeJ4Y3TKvr4ta7ys0FgNoMCgdw5uQtbZ7yHc4Nyvs=; b=VeGPHtbzXDOVXl8Iq7OptXrLF/RVT4Tbn7HLlv4L4ICVyglKt/GV7K9L1NBHlO5UZV tKxVvDWrgBjIEvsE7HnPjlHZfaPZuGmcCx8xyPXqWG1HVBbDQeZTEVAzx+64B7YllXYL DHcnzfIhf7AJbN/D8u1Aomg297cg4QRy4c2SwY/7T1NbXcrtGk5CrvrIRWFsBhGiPZEL XFWmgbpAO2MscKzZS8mpVI/+vVkoYLlQxFOhdd0Flp+KdbUGZWhsnF65Hwz4nnlT7DiQ h0IeqrGb396Iw5sMkxU3NQHoK8eCnoFCGCk08dTIclX+kMMBcaAd2hP5ow+6yCvFWyOB +cdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=TALeJ4Y3TKvr4ta7ys0FgNoMCgdw5uQtbZ7yHc4Nyvs=; b=OzL7nrQrX6xEuxoxgMVskzRngEEgLooH3M+p4Ed6CAadunWrhLEdiXKYEiKkutZlTX fWB+c1X2AtWsRV6KxpQ6h/dNrD3smFrZkiKqSJURkOw9PDhuCwVyRXugulbT5Onl6e+U AHVEZnbzo7Vcp1fakRRUnWFO3qoB9wvyMOa3zavDjZAoeU5EQa+jKACWvfN266NesVp4 BXY0DpApdvSYZXF2Isotj1YLFblr/sWTqCzSHADElbS2ZD3RCMSMHCoWCi7cUeAkjhRD NBt2GL45vzFl2PnjtvyZGnq3Xj0ve502MwpuK85y5TEYMhG2XTAp3mM5HaUifNQviqv7 YRjA== X-Gm-Message-State: AOAM533QajrXzM+BhUDaNYKwGFtB+/i8zIkGN3wSVkcdv3nfuvjuC+8L hLfkfHTatFT5eSlVTxfp55lhHFFWkDE= X-Google-Smtp-Source: ABdhPJwJmypeXaQ8MelSoMa2Ucq3Q5LlNuH0Rvly3+Pkeb4+7z4Ee6xrxqB289Cm36AXa3pu/SEo6g== X-Received: by 2002:a17:906:974a:: with SMTP id o10mr3448517ejy.226.1640107420297; Tue, 21 Dec 2021 09:23:40 -0800 (PST) Received: from skbuf ([188.26.56.205]) by smtp.gmail.com with ESMTPSA id ga36sm473763ejc.200.2021.12.21.09.23.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Dec 2021 09:23:39 -0800 (PST) Date: Tue, 21 Dec 2021 19:23:37 +0200 From: Vladimir Oltean To: Justin Iurman Cc: Jakub Kicinski , 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 , Florian Fainelli , Florian Westphal , Paolo Abeni Subject: Re: [RFC net-next 2/2] ipv6: ioam: Support for Buffer occupancy data field Message-ID: <20211221172337.kvqlkf3jqx2uqclm@skbuf> References: <20211206211758.19057-1-justin.iurman@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> <20211209163828.223815bd@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <1065685246.241690721.1640106399663.JavaMail.zimbra@uliege.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1065685246.241690721.1640106399663.JavaMail.zimbra@uliege.be> X-Stat-Signature: rd314wt7ch9ew7ysw7ekhjcg4qx7kmwm X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 28BB94002F Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=VeGPHtbz; spf=pass (imf17.hostedemail.com: domain of olteanv@gmail.com designates 209.85.208.50 as permitted sender) smtp.mailfrom=olteanv@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1640107410-887485 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000086, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Dec 21, 2021 at 06:06:39PM +0100, Justin Iurman wrote: > On Dec 10, 2021, at 1:38 AM, Jakub Kicinski kuba@kernel.org wrote: > > [...] > > 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. > > It looks like we won't have more opinions on that, unfortunately. > > @Jakub - Should I submit it as a PATCH and see if we receive more > feedback there? I know nothing about OAM and therefore did not want to comment, but I think the point raised about the metric you propose being irrelevant in the context of offloaded data paths is quite important. The "devlink-sb" proposal was dismissed very quickly on grounds of requiring sleepable context, is that a deal breaker, and if it is, why? Not only offloaded interfaces like switches/routers can report buffer occupancy. Plain NICs also have buffer pools, DMA RX/TX rings, MAC FIFOs, etc, that could indicate congestion or otherwise high load. Maybe slab information could be relevant, for lack of a better option, on virtual interfaces, but if they're physical, why limit ourselves on reporting that? The IETF draft you present says "This field indicates the current status of the occupancy of the common buffer pool used by a set of queues." It appears to me that we could try to get a reporting that has better granularity (per interface, per queue) than just something based on skbuff_head_cache. What if someone will need that finer granularity in the future.