Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp4146930pxb; Sat, 5 Feb 2022 05:08:02 -0800 (PST) X-Google-Smtp-Source: ABdhPJziXLJt1arev1gYPulkr5pFtmXeIcmJbgDUJDf1/Vjy9modoqqqnxqNbaUoLh0MGB6bdJN+ X-Received: by 2002:a05:6a00:1508:: with SMTP id q8mr7789939pfu.3.1644066481690; Sat, 05 Feb 2022 05:08:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644066481; cv=none; d=google.com; s=arc-20160816; b=sp+6+ANncu0Q/XVAdztQwyHG1WZXYGF5yldyu/2fWiV+egqVAFzQzECm1ITTSGIrCY TWnlesbPdR6oRy4PG5QoZd4fD9TtEiZ4Mvgm5a6kq31l+oIJpJUo5W9XxNVUiulNwXo1 sKaxmOoNBuAVnJ6rE8Rxn2rOcsXvzmru0WydR7gzapoNz+6iATjemNQG/mFaDdCisg29 UpjsgzHkQW5wtw4EPJq0OPtFSAhDhjfpZzHnR9cHhWZZYXCYR9VSM+exe8z9T5xrqMsm nVUlcCR6yjjjNpvLw3uGbJ4sfhn75HrFzqledM0v+AlmUrFViYIVISFd8La0cnH7axna liAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=Wh1/UBhsxQfAyZPiDn6haF7FMvKbR0Cv+cjxuxp0Kkk=; b=HP4ACFw62CeqmfhIj/tQ/h99upJKEXCjaKfqNj+GMsx1amWxVonIuJNv5XmZzphJz0 06YCfsK1iOxZprMLdiM7V012l6g9d62Hxv7IHFPBX+9wONUchNWkKYQyjgZM0TGHjc8+ drCWivle1MyTok/QcIJCsRT9qDx30cGMPNf27YwEO91ljLuCkIrAenrHJ1jqGW4dl/jg ygxEwx9gk82xoA4gzz0pd9qgvmDPA/YMlLEba3GxmzDidMxPmzaEZ3poIsTLhWgeZ8jU 3/xVyY7oXJepXG9nNDCl5wKzRbicRJao2f0Luj/5Ht8pK9/AxkjqXno05DQ4yQldDdxr /L1w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=SxjlFK6E; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n13si12468062pjt.18.2022.02.05.05.07.47; Sat, 05 Feb 2022 05:08:01 -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=@google.com header.s=20210112 header.b=SxjlFK6E; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1353284AbiBCSOT (ORCPT + 99 others); Thu, 3 Feb 2022 13:14:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54370 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1353173AbiBCSOL (ORCPT ); Thu, 3 Feb 2022 13:14:11 -0500 Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 88A65C06173B for ; Thu, 3 Feb 2022 10:14:11 -0800 (PST) Received: by mail-yb1-xb36.google.com with SMTP id g14so11431447ybs.8 for ; Thu, 03 Feb 2022 10:14:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Wh1/UBhsxQfAyZPiDn6haF7FMvKbR0Cv+cjxuxp0Kkk=; b=SxjlFK6E6+hOvZ/ebXzmpB43cqVC4bK8dIHkyGbzPyH4oMrYiMicy8q813/QFXfqJ4 QQv8t1AVV6OTvvI0dd7hk2JjqcCldLDvsVWJKH3NArGmSXGTOPEc0MvgbX7gNHKN5tOB G5ZHCGLjmKfExbFWDT91pAhRKujxwkU02dxaJW0z7DZR68PgPkjn8Mnbto6BddNI/T2W yJldLw7Em/Yjg31egGVgHHWEnqb0euiMBlSfaBI2T6+9WAnmXMvI9ZI0EuwlOaS2iIP0 ZTc0vHh+cr0tOY7RbeNN46nv0CxC0MfYEOHEglMTtoeLGjWhbHb4aLp3vZ+dP2seHFHF fGlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Wh1/UBhsxQfAyZPiDn6haF7FMvKbR0Cv+cjxuxp0Kkk=; b=AXv1phh8Sqb7/a8Fm+DkUu3TEtoF+zXgaBqUASR48IRT7atg6JwO0pAn5jazxTae+9 EvKFO/k3TKpZMHwSSC4KgX6IjMziluYSpYdyQKvD90ku3mTFdNGZjPcrtcCOd0THoXL3 3+T4NB8n2UdFLGIhPGRFCUIktImF/TWJr47R83cbklpQKz1Kc98543zmh/Kr89YLkJ06 MSpGbtmG5TCJWGXKauIsMhOxU19k5z9cdM0LhM5E4BTw0yicpfMSv9ljbXrxhOHCo0vd J1rbhm6g9BypDAPd085Xc25VgBeNqsmzWGfr5PGt2qynqJziUGR/rz12/YIDNet6psqL FVzg== X-Gm-Message-State: AOAM53333hQzSL+239zO0nBpP6i/AYhqD864Txei3UnZgdbkDF7lWi0j DXs85fkEWjU5GR5LzwCWCli/n4vWPD2t6m/3oHu4lQ== X-Received: by 2002:a81:9808:: with SMTP id p8mr5244856ywg.531.1643912050354; Thu, 03 Feb 2022 10:14:10 -0800 (PST) MIME-Version: 1.0 References: <20220201222845.3640041-1-jeffreyji@google.com> <20220202205916.58f4a592@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> In-Reply-To: <20220202205916.58f4a592@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> From: Eric Dumazet Date: Thu, 3 Feb 2022 10:13:59 -0800 Message-ID: Subject: Re: [PATCH v6 net-next] net-core: add InMacErrors counter To: Jakub Kicinski Cc: Jeffrey Ji , "David S . Miller" , Brian Vazquez , LKML , netdev , jeffreyji Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 2, 2022 at 8:59 PM Jakub Kicinski wrote: > > On Tue, 1 Feb 2022 22:28:45 +0000 Jeffrey Ji wrote: > > From: jeffreyji > > > > Increment InMacErrors counter when packet dropped due to incorrect dest > > MAC addr. > > > > An example when this drop can occur is when manually crafting raw > > packets that will be consumed by a user space application via a tap > > device. For testing purposes local traffic was generated using trafgen > > for the client and netcat to start a server > > > > example output from nstat: > > \~# nstat -a | grep InMac > > Ip6InMacErrors 0 0.0 > > IpExtInMacErrors 1 0.0 > > 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. > 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) > > 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