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=-13.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 2E6CAC433C1 for ; Wed, 24 Mar 2021 18:08:51 +0000 (UTC) Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by mail.kernel.org (Postfix) with ESMTP id 9DAFB61A1C for ; Wed, 24 Mar 2021 18:08:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9DAFB61A1C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 895DC140F9A; Wed, 24 Mar 2021 19:08:49 +0100 (CET) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mails.dpdk.org (Postfix) with ESMTP id D6924140F92 for ; Wed, 24 Mar 2021 19:08:47 +0100 (CET) IronPort-SDR: T21qUw26BORG9Qy+tBiPNfTm99ujaH+vhYDW1ZLU8taUvm3UxMRlgllYh1HeqVT/AG5EdUy9Gp 7QOlpvuqnusQ== X-IronPort-AV: E=McAfee;i="6000,8403,9933"; a="187456013" X-IronPort-AV: E=Sophos;i="5.81,275,1610438400"; d="scan'208";a="187456013" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Mar 2021 11:08:46 -0700 IronPort-SDR: 3jSfrVZHW03cTyrvSJQ7EJvyEmrrkpaJKmggkmURJJGQQh5EdNOT455xpmnhy0wM/1BCoGre7h wPfWbgesvmdQ== X-IronPort-AV: E=Sophos;i="5.81,275,1610438400"; d="scan'208";a="408960643" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.252.28.141]) ([10.252.28.141]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Mar 2021 11:08:44 -0700 To: Thomas Monjalon , dev@dpdk.org Cc: Rosen Xu , Hemant Agrawal , Sachin Saxena , Jingjing Wu , Beilei Xing , Qiming Yang , Qi Zhang , Jeff Guo , Haiyue Wang References: <20210311221742.3750589-1-thomas@monjalon.net> <20210321090002.595744-1-thomas@monjalon.net> <20210321090002.595744-3-thomas@monjalon.net> From: Ferruh Yigit X-User: ferruhy Message-ID: Date: Wed, 24 Mar 2021 18:08:43 +0000 MIME-Version: 1.0 In-Reply-To: <20210321090002.595744-3-thomas@monjalon.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v3 2/2] drivers/net: remove explicit include of legacy filtering X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 3/21/2021 9:00 AM, Thomas Monjalon wrote: > The header file rte_eth_ctrl.h should not be needed because > this legacy filtering API is completely replaced with the rte_flow API. > However some definitions from this file are still used by some drivers, > but such usage is already covered by an implicit include via rte_ethdev.h. > > Signed-off-by: Thomas Monjalon > Acked-by: Rosen Xu > Acked-by: Hemant Agrawal > --- > drivers/net/dpaa2/dpaa2_ptp.c | 1 - > drivers/net/iavf/iavf_hash.c | 1 - > drivers/net/ice/ice_acl_filter.c | 1 - > drivers/net/ice/ice_hash.c | 1 - > drivers/net/ice/ice_switch_filter.c | 1 - > drivers/net/igc/igc_filter.h | 1 - > drivers/net/ipn3ke/ipn3ke_flow.c | 1 - Although this will work, if the above drives are using the defines from the header file, isn't it better to include it explicitly? What is the benefit of including the header implicitly?