From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 53847A0A0A; Fri, 26 Mar 2021 16:37:30 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C4E42140F05; Fri, 26 Mar 2021 16:37:29 +0100 (CET) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mails.dpdk.org (Postfix) with ESMTP id CFC2140685 for <dev@dpdk.org>; Fri, 26 Mar 2021 16:37:27 +0100 (CET) IronPort-SDR: MBsg4uu5W0cRE0N+waWM2P5Pp2vcrcUp2STEku9vUyzymriPjNO1dDYhqpewefokekHdqJpvqz m5MOTtL/aEIg== X-IronPort-AV: E=McAfee;i="6000,8403,9935"; a="190610244" X-IronPort-AV: E=Sophos;i="5.81,280,1610438400"; d="scan'208";a="190610244" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Mar 2021 08:37:26 -0700 IronPort-SDR: v1/1+kLy2E7/2y7Fm7vIgrzd7lgG6RF1TxbbUXFLmhZRP1IXnG6BPeKqW18G3Dy5Xt1hFylwxM 8trlmpa3CHtQ== X-IronPort-AV: E=Sophos;i="5.81,280,1610438400"; d="scan'208";a="375520787" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.231.99]) ([10.213.231.99]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Mar 2021 08:37:23 -0700 To: Thomas Monjalon <thomas@monjalon.net> Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>, dev@dpdk.org, Rosen Xu <rosen.xu@intel.com>, Hemant Agrawal <hemant.agrawal@nxp.com>, Sachin Saxena <sachin.saxena@oss.nxp.com>, Jingjing Wu <jingjing.wu@intel.com>, Beilei Xing <beilei.xing@intel.com>, Qiming Yang <qiming.yang@intel.com>, Qi Zhang <qi.z.zhang@intel.com>, Jeff Guo <jia.guo@intel.com>, Haiyue Wang <haiyue.wang@intel.com> References: <20210311221742.3750589-1-thomas@monjalon.net> <325e1d27-3729-0768-fc0d-ef89c1db9cf5@oktetlabs.ru> <27e1324b-886a-7e26-3215-08a10daf679e@intel.com> <272955377.2llAV7lm0X@thomas> From: Ferruh Yigit <ferruh.yigit@intel.com> X-User: ferruhy Message-ID: <4d61a941-5262-7da3-bed8-12cc360e5f59@intel.com> Date: Fri, 26 Mar 2021 15:37:19 +0000 MIME-Version: 1.0 In-Reply-To: <272955377.2llAV7lm0X@thomas> 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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> On 3/25/2021 10:20 AM, Thomas Monjalon wrote: > 25/03/2021 11:00, Ferruh Yigit: >> On 3/25/2021 5:53 AM, Andrew Rybchenko wrote: >>> On 3/24/21 11:00 PM, Thomas Monjalon wrote: >>>> 24/03/2021 19:08, Ferruh Yigit: >>>>> 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 <thomas@monjalon.net> >>>>>> Acked-by: Rosen Xu <rosen.xu@intel.com> >>>>>> Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com> >>>>>> --- >>>>>> 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? >>>> >>>> The benefit is to progressively remove rte_eth_ctrl.h. >>>> I want it to disappear. >>>> >>> >>> +1 >>> >> >> This is just hiding its usage, the patch is not making it less used as a step >> forward to remove it. > > Yes you're right. The only step forward is esthetic: > hiding something which should be removed. > And maybe some of these files don't need the include at all. > >> But anyway I guess it doesn't worth spending more time to discuss it ... > > Feel free to reject if you feel it is not a good step. > What do you think doing exact opposite, remove "#include <rte_eth_ctrl.h>" from 'rte_ethdev.h', and include 'rte_eth_ctrl.h' explicitly where ever it is required, this can make more clear what components use the 'rte_eth_ctrl.h' and why, which may help clearing them to remove the header. Plus it highlights if a new PMD wants to use the header, we can catch it easier. When I tried above approach, it highlighted that not only drivers, libraries also using this header, 'librte_ehtdev' & 'librte_flow_classify'. And for 'ethdev', the structs defined in the 'rte_eth_ctrl.h' are part of public structs, so it is hard to remove them. Some PMD specific APIs also needs 'rte_eth_ctrl.h' header, but that is hidden because of the implicit include, but again some structs in the 'rte_eth_ctrl.h' are part of public APIs (although they are experimental). Also, it turned out that same required headers in the drivers are hidden because of this implicit include in 'rte_ethdev.h', I will send a fix for it soon.