Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp917136pxp; Wed, 16 Mar 2022 21:13:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzZrYD0NAg45jaL5/ojiqqHVL00T8QbjANyQIOpjKwpAXfH4QDjSmPr/XHvQtrXGFLsGDTh X-Received: by 2002:a17:90a:db12:b0:1be:eb72:a63b with SMTP id g18-20020a17090adb1200b001beeb72a63bmr13819953pjv.94.1647490433333; Wed, 16 Mar 2022 21:13:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647490433; cv=none; d=google.com; s=arc-20160816; b=JnONQzQc0Ba4x/KxFNZiFBkfI3cZ+yLu3NT4e7w9HwubtmLTH3XJzU+8nSm3yESXgn QCW+mMsgUn/wl5EQkEdOzhJ2u9bnqEaqUJu2yrOITMD1k5/EpSSQDRfE7gPL1n0i6WvT FSsJiMBgvfY8Dq+PID7hCOA42kg9jdwKnnG6+Ps6/Fmg2Wp0cYAt6QaYOS/QteCdHp2b sgpGux/I8NBqlOjg8x39JADXEnDBDEZb2yaPuclxeIajHhOxOIV5yjP+mtXUMuFODhPS cnTMipeXIojuX/kx5eqkOQ/Vp1E41pkZfC5XBrg+gZOMrzJs4FXWy83N2c5OWNxqRo/u sifg== 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=0NfiqyGYI/G5XYzb6aotJBMCLDugWnL2hbOj4YnTkrM=; b=zvOhFMCtD7h2BUwVfz6jnskI5WA0v3hbZXsd+zWkSqWwzhtWGz/vj4+CDR7BbJ8t3E nPPUEOAOoluM7OO1CMfgFRbrcZSOPWYkqS7KSLacrCvsoC00U9Q44tP76RL+FLxFnKEO +/X8HvJOe5gHzZLLXVHSnEvruu+nIO4djhmHPAeyY+UKrJgRVM8j8DdOTpOmJtWV0eaL qXsbSOHlUi9VlrK1nvnhvzAHBE13/H5hKbLHYK08CuzvOOMbtmX7meuJJDiJuWYx2Lkd HVrC+xI183L2IWGXFYOtNpRU8fHG5vWWQNejvObwekIqYRCYXgsfZa+9hOePFEB06/ep I/GA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="ESx3M/er"; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id w9-20020a17090a4f4900b001bd14e03091si1262180pjl.105.2022.03.16.21.13.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Mar 2022 21:13:53 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="ESx3M/er"; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 41D0DBAB81; Wed, 16 Mar 2022 20:51:53 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351829AbiCPE5M (ORCPT + 99 others); Wed, 16 Mar 2022 00:57:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33122 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234922AbiCPE5L (ORCPT ); Wed, 16 Mar 2022 00:57:11 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A673A5FF0D; Tue, 15 Mar 2022 21:55:57 -0700 (PDT) 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 5F75FB8175E; Wed, 16 Mar 2022 04:55:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 75408C340E9; Wed, 16 Mar 2022 04:55:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1647406555; bh=amkWBYQoEwRz3FDvhPf8X9F8qTN+mM47tSuGPEtpbPk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ESx3M/er7eLXhFBiE/SnfJLRmSA54LFudzjuAe1Jix7ADi95LTX261Mrk0ZcCjZQe JKlPJOiiheZZTXP+bPsr43fWSUu0hhb/uZY98ftPyGH+L5iG6L9ON8qbu17GJiXy+0 PxYcBLPawsoDsZKXIt4Ir3/ftHCRbb6TWZZOOHMHphn5tTaufQIj6srVwGXIplEiEP IoraDRzLtG2R92G4JHLMXxcjI9kTvSMClQGLQ2yLfTLThKFRBSb7yZTCSOft1BKCQa KN6oFgt3gJuuLyQuMY2yohuWtQ0xgWITM/ClNiuGw8zd0iOGOfl0z/LDH5hx+DY3ul butZYo8yajmlw== Date: Tue, 15 Mar 2022 21:55:53 -0700 From: Jakub Kicinski To: David Ahern Cc: menglong8.dong@gmail.com, rostedt@goodmis.org, mingo@redhat.com, xeb@mail.ru, davem@davemloft.net, yoshfuji@linux-ipv6.org, imagedong@tencent.com, edumazet@google.com, kafai@fb.com, talalahmad@google.com, keescook@chromium.org, alobakin@pm.me, flyingpeng@tencent.com, mengensun@tencent.com, dongli.zhang@oracle.com, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Biao Jiang Subject: Re: [PATCH net-next 1/3] net: gre_demux: add skb drop reasons to gre_rcv() Message-ID: <20220315215553.676a5d24@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> In-Reply-To: References: <20220314133312.336653-1-imagedong@tencent.com> <20220314133312.336653-2-imagedong@tencent.com> <20220315200847.68c2efee@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 15 Mar 2022 21:49:01 -0600 David Ahern wrote: > >> ver = skb->data[1]&0x7f; > >> - if (ver >= GREPROTO_MAX) > >> + if (ver >= GREPROTO_MAX) { > >> + reason = SKB_DROP_REASON_GRE_VERSION; > > > > TBH I'm still not sure what level of granularity we should be shooting > > for with the reasons. I'd throw all unexpected header values into one > > bucket, not go for a reason per field, per protocol. But as I'm said > > I'm not sure myself, so we can keep what you have.. > > I have stated before I do not believe every single drop point in the > kernel needs a unique reason code. This is overkill. The reason augments > information we already have -- the IP from kfree_skb tracepoint. That's certainly true. I wonder if there is a systematic way of approaching these additions that'd help us picking the points were we add reasons less of a judgment call.