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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CB182C7EE2E for ; Mon, 27 Feb 2023 18:30:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229542AbjB0SaB (ORCPT ); Mon, 27 Feb 2023 13:30:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35898 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229974AbjB0S35 (ORCPT ); Mon, 27 Feb 2023 13:29:57 -0500 Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0EF221A4B1 for ; Mon, 27 Feb 2023 10:29:56 -0800 (PST) Received: by mail-qv1-xf35.google.com with SMTP id f1so5064830qvx.13 for ; Mon, 27 Feb 2023 10:29:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=8gqvdI/sqm54XWkh3DNgmjvQKemViz9xEEbhMbeWe3c=; b=ah1GvW2D49ep0hOqw/mlXtnmomQmxfiSth7nxEOTuMhOFAL99QpKjBLWCq+wH8akJc p0n17L3oxLnHyg17c6g1tVpvAhGVsDDQJ50GuexcKwOglLAInq/DFoZ3q+f1NL4Rn/rb 08yaIH6KD+UisKS28gCNfID2vVt4qUmkz3Y+IO2RW8IyrhoMCJ6t1N0I+QvpdKycKOyU FzjRHlIkeZ0+vUkSNDinURM5kf8TIAjJItUN1cPmoXdFB3AnUcUOk/BQvBHU2AHJr+6Z eQzPi8E4NjFzpwYVOL1EkfNSKOYzIxCyH8BLc8E96SncGuibxJshN1FIwwDixyVhrobg 4Hcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8gqvdI/sqm54XWkh3DNgmjvQKemViz9xEEbhMbeWe3c=; b=gQ5HGZs97FFCEhsARrtpEFANnQIKfnZxTfUgRPpyLq3+qA2fVwIGEvlhlYzBAKugp5 FPKOsV4uxY2LMnDcVHYoTmt+xaUj+IJUsgnPDC0EN89yzNrt7coeiN6gi2b9xKF7nimL CBfPH8YKUqFKnfCh3iGVEemuTUZzGFks8iy4sBB6CVVmjdEI31hTFAMOQaQi37WlL/E3 kSXS991RrSt3yNZ/I4y55uYhPJe0bSWUnxGEOmAqMg/NPG41l+5p0MkXmGnNolpaiTlZ silS1+VUaagACYjq9ktx4bwDDzvskZIblIhd5Hot+nfp7GXQVJtzTBJ22T15ajkaFQj7 YDfg== X-Gm-Message-State: AO0yUKXmbcszuOZ8n03cR/CaApHODTFoJcs0aTDbStBxeYhIGFTKLVbJ 4n4o+s1JgrvGkuECS3dWE9o= X-Google-Smtp-Source: AK7set8JAaa6QqvRhCiFk/ex/Sa1va63Zyjy0oAf4uJqHbWwiCQU/Mns4yyyJOxsM6zeFDkxU6du+w== X-Received: by 2002:a05:6214:2425:b0:56e:c09e:7d6b with SMTP id gy5-20020a056214242500b0056ec09e7d6bmr673722qvb.43.1677522595026; Mon, 27 Feb 2023 10:29:55 -0800 (PST) Received: from vps.qemfd.net (vps.qemfd.net. [173.230.130.29]) by smtp.gmail.com with ESMTPSA id x21-20020a376315000000b007419eb86df0sm5374861qkb.127.2023.02.27.10.29.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Feb 2023 10:29:54 -0800 (PST) Received: from schwarzgerat.orthanc (schwarzgerat.danknet [192.168.128.2]) by vps.qemfd.net (Postfix) with ESMTP id 485D02B426; Mon, 27 Feb 2023 13:29:54 -0500 (EST) Received: by schwarzgerat.orthanc (Postfix, from userid 1000) id 4394B60018D; Mon, 27 Feb 2023 13:29:54 -0500 (EST) Date: Mon, 27 Feb 2023 13:29:54 -0500 From: nick black To: Jakub Kicinski Cc: netdev@vger.kernel.org, Florian Fainelli , "David S. Miller" , Jeffrey Ji , Eric Dumazet , Willem de Bruijn Subject: Re: [PATCH] [net] add rx_otherhost_dropped sysfs entry Message-ID: References: <20230227102339.08ddf3fb@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230227102339.08ddf3fb@kernel.org> Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Jakub Kicinski left as an exercise for the reader: > "All the other stats are there" is not a strong enough reason > to waste memory on all systems. You need to justify the change > based on how important the counter is. I'd prefer to draw a > line on adding the sysfs stats entries. We don't want to have > to invent a new stats struct just to avoid having sysfs entries > for each stat. In that case, I think a comment here is warranted explaining why this stat, out of 24 total, isn't important enough to reproduce in sysfs. I'm not sure what this comment would be: rx_otherhost_dropped certainly seems as useful as, say rx_compressed (only valid on e.g. CSLIP and PPP). If this stat is left out of the sysfs interface, I'm likely to just grab the rtnl_link_stats64 directly via netlink, and forgo the sysfs interface entirely. If, in a modern switched world, I'm receiving many packets destined for other hosts, that's at least as interesting to me as several other classes of RX error. -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe.