Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp3106547pxb; Fri, 4 Feb 2022 01:10:17 -0800 (PST) X-Google-Smtp-Source: ABdhPJxNvzTppHlpsPnXIAi1acuqC2uA7lZPIsm2+HTEukMwkFYpl0R4WgvZlOvsOhfWqa0Z738i X-Received: by 2002:a17:902:e545:: with SMTP id n5mr2006903plf.160.1643965817606; Fri, 04 Feb 2022 01:10:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643965817; cv=none; d=google.com; s=arc-20160816; b=kgEXi4IcnOSOBKEEITvvdpLwdNQELT1e4JE7JINu2BeilMUBYwCZ08NMNat4VnPVPB o5Vetft0ZLO3FoTTfttIaxJ+pEXpY/MuKLbmEqcKQAAXkTTw6jh0VFM1NSllzBJHX9CS +oiX+9R5Wj5er39wUFJ+QUXxd3WiUwJeElQp78N/T331kXBMh6Xtn/uIMb4WPhbUNf15 MzmuEVSilDySPQxKZwGSp+VdehynXO6XGZj3w3Bii56QMNv+0MWQYu5Xh+vlPHH7eE9y n88i7+Vee1Sk8QZeiSBmpDALrFMS0A5xenUQajfBuQtqVIL1xdKKbWRqxPpETbhWxP7f Re0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=XBGRpY4EYuR3O3b4bGpJhit2W+9NQ1/WWR6LD7flcEM=; b=0P+z8QpE8Pn8v9MRk7cJsN7XLRDXz1JiFXeavRPy11aFyn106x48HjpDe83EVMaXYq Mz4jT3cTSwZj+sMfBpz1A5VRK6i2BcCq/IW4djrU4DIeg3tFPwIt/pjTBnfeK628vm77 PcwXMs9UG838vvH9e8Zgaf80oA1UVsCdOb/UuyrECO6Y33givf22u/TIJgSTEyFr6+yP E1xICztP1PW26WrukiFUyHtJL6I9t6OxU+9tkOISg9+eTH+C0kOdmf3u8GCdPFSKt5CL OvNjJPl8MfrDbDQe3OxJRB61mGJqxMPMvePgZEj2rbc4cXFC6KUZiCvxXopQBhjVGTMx SxAA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=N9WGFcik; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s65si1345240pgc.301.2022.02.04.01.10.05; Fri, 04 Feb 2022 01:10:17 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=N9WGFcik; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1353777AbiBCTeb (ORCPT + 99 others); Thu, 3 Feb 2022 14:34:31 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44706 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1353787AbiBCTe3 (ORCPT ); Thu, 3 Feb 2022 14:34:29 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 319D6C061401; Thu, 3 Feb 2022 11:34:29 -0800 (PST) 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 dfw.source.kernel.org (Postfix) with ESMTPS id C485761986; Thu, 3 Feb 2022 19:34:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DA739C340EB; Thu, 3 Feb 2022 19:34:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643916868; bh=utBZ91xC68wf/1RW1HInTpjbO0Sz/IMNNgG3iiovr04=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=N9WGFcikIUFZYmrx0VZQ4hASyFON91A7LZEo9gPiqjcGNQk5M871vBVy1EDZ9lur2 pyE5Ej3sPpL+PfAiFCtGFzry3fZa3q1VDoRo/WEiP3fEsfB+50ZmuAR1OK0dpxWR1v ZknSjQBMNQ2dcPVGkGF/0jElu0sRhs2/rlR+mOiHZnZZgEKlxawYvx1YS5r6AGZ0il Sco59xry+Xjof7qNWEjX8zIjpJ4+U8Bh4PGkzOrYr5NsAkNLxaMy281dowgIMtwpUs ZuOVACG0NIXjR3lwCP3aGdO/EQPxZQy9HzH2lj25mSRDxZVP01MbGzQP6afpToNGyk aI3uwybVmgk2Q== Date: Thu, 3 Feb 2022 11:34:26 -0800 From: Jakub Kicinski To: Eric Dumazet Cc: Jeffrey Ji , "David S . Miller" , Brian Vazquez , LKML , netdev , jeffreyji Subject: Re: [PATCH v6 net-next] net-core: add InMacErrors counter Message-ID: <20220203113426.49c70285@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> In-Reply-To: References: <20220201222845.3640041-1-jeffreyji@google.com> <20220202205916.58f4a592@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 3 Feb 2022 10:13:59 -0800 Eric Dumazet wrote: > > I had another thing and this still doesn't sit completely well > > with me :( > > > > Shouldn't we count those drops as skb->dev->rx_dropped? > > Commonly NICs will do such filtering and if I got it right > > in struct rtnl_link_stats64 kdoc - report them as rx_dropped. > > It'd be inconsistent if on a physical interface we count > > these as rx_dropped and on SW interface (or with promisc enabled > > etc.) in the SNMP counters. > > I like to see skb->dev->rx_dropped as a fallback-catch-all bucket > for all cases we do not already have a more specific counter. Indeed, it's a fallback so counting relatively common events like unicast filtering into generic "drops" feels wrong. I heard complaints that this is non-intuitive and makes debug harder in the past. > > Or we can add a new link stat that NICs can use as well. > > Yes, this could be done, but we have to be careful about not hitting > a single cache line, for the cases we receive floods of such messages > on multiqueue NIC. > (The single atomic in dev->rx_dropped) is suffering from this issue btw) Even more of a reason to bite the bullet and move from the atomic counters to pcpu stats? > > In fact I'm not sure this is really a IP AKA L3 statistic, > > it's the L2 address that doesn't match. > > > > > > If everyone disagrees - should we at least rename the MIB counter > > similarly to the drop reason? Experience shows that users call for > > help when they see counters with Error in their name, I'd vote for > > IpExtInDropOtherhost or some such. The statistic should also be > > documented in Documentation/networking/snmp_counter.rst