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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5A7F9C4320A for ; Thu, 2 Sep 2021 06:49:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3E16C60FC0 for ; Thu, 2 Sep 2021 06:49:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242040AbhIBGuF (ORCPT ); Thu, 2 Sep 2021 02:50:05 -0400 Received: from new3-smtp.messagingengine.com ([66.111.4.229]:54529 "EHLO new3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239077AbhIBGt4 (ORCPT ); Thu, 2 Sep 2021 02:49:56 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id 82F4E580CA8; Thu, 2 Sep 2021 02:48:57 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 02 Sep 2021 02:48:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=wLdsoF jidL1GAMNupKB6KhdOpkiskgoBwwDwzSeYQJg=; b=X5a10OTpqNQL2LtwJEYgun hRNRyZeZ0dvKiM9QNZHSPBOOHGM4X+YdeimS+wIRuxJOSYGfL7xj3Laj4CtaUQqk k0oMoH/2QhK+x/UQm1Gk4+6SQYbLbR1/WiHxkQ5T0OuiFddooGqB9JAFnoqassrx hEEFSQVWSSCkOrAg0w2PCwGO227gKnZx7dB3frRYf7zOa1oSrhrklPFBdwixKFD3 rns3/cwAlnqDwqnPlxWqkr/L5OEze2Qvy32Xt3pLqyGx8snvrOpqWwKBEK1qwVw7 UrWZkbFwfWqB5l2zOfcCoFwOiRKxXZjFabPj3dXU4OH7Mh6YxjnaSE0SaHKknh/Q == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddruddvgedguddufecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepkfguohcu ufgthhhimhhmvghluceoihguohhstghhsehiughoshgthhdrohhrgheqnecuggftrfgrth htvghrnheptdffkeekfeduffevgeeujeffjefhtefgueeugfevtdeiheduueeukefhudeh leetnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepih guohhstghhsehiughoshgthhdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 2 Sep 2021 02:48:55 -0400 (EDT) Date: Thu, 2 Sep 2021 09:48:51 +0300 From: Ido Schimmel To: Jamal Hadi Salim Cc: Boris Sukholitko , netdev@vger.kernel.org, Jiri Pirko , Cong Wang , "David S . Miller" , Jakub Kicinski , Vladimir Oltean , Vadym Kochan , Ilya Lifshits , tom Herbert , Felipe Magno de Almeida , Pedro Tammela Subject: Re: [PATCH net-next] net/sched: cls_flower: Add orig_ethtype Message-ID: References: <20210830080800.18591-1-boris.sukholitko@broadcom.com> <20210831120440.GA4641@noodle> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, Aug 31, 2021 at 09:18:16AM -0400, Jamal Hadi Salim wrote: > You have _not_ been unlucky - it is a design issue with flow dissector > and the wrapping around flower. Just waiting to happen for more > other use cases.. I agree. I think the fundamental problem is that flower does not set 'FLOW_DISSECTOR_F_STOP_AT_ENCAP' and simply lets the flow dissector parse as deep as possible. For example, 'dst_ip' will match on the inner most destination IP which is not intuitive and probably different than what most hardware implementations do. This behavior is also very error prone because it means that if the kernel learns to dissect a new tunnel protocol, filters can be suddenly broken (match on outer field now matches on inner field). I don't think that changing the default behavior is a solution as it can break user space. Maybe adding a 'stop_encap' flag to flower that user space will have to set?