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 438F9A0A02;
	Fri, 26 Mar 2021 22:45:28 +0100 (CET)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id BD798140DC2;
	Fri, 26 Mar 2021 22:45:27 +0100 (CET)
Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com
 [66.111.4.229]) by mails.dpdk.org (Postfix) with ESMTP id 96A8640685
 for <dev@dpdk.org>; Fri, 26 Mar 2021 22:45:26 +0100 (CET)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
 by mailnew.nyi.internal (Postfix) with ESMTP id 4FC29580578;
 Fri, 26 Mar 2021 17:45:23 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
 by compute1.internal (MEProxy); Fri, 26 Mar 2021 17:45:23 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=
 from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding:content-type; s=fm3; bh=
 RjCxAvjg+lSY5uYdlQtsu0x7cONWD+WoiMJnk6Dc0q0=; b=czWa0TWIwqcqG+WJ
 1biGllITMh6sB+9waYuKc6mRwk4jvq41ZWq5iWcUyV63S9DyAoEnMJJf7nEPBBTT
 R0k4WL8gyqtthWFk7kwPZpgs9viC4E7NYgdPQMbzkQpEMgv/GUpnJ+TcwFNdhwMO
 RAlpUcD1LQ9idEWXhyxzWs2IRJFdPxc3oIURcgB+twCNZ/BuZq0/6sheMBzrRHqN
 5HmZ25C5RP9ofVZAQTFqwZLfxUksgETcqZ7Tk2eQ7zOgRCwrzR5+Wv4g3gt+gq/z
 2sx1gug4ixYUQ8tybnXjgGTZEt2ocYctMoiaJSQVFMqzlQkECroq2okVSIZ2Nx/5
 +7az7A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-transfer-encoding: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=fm2; bh=RjCxAvjg+lSY5uYdlQtsu0x7cONWD+WoiMJnk6Dc0
 q0=; b=HsBo9FWwlG7+0lnqYK2t1zSrvJuTpIMTvUn7jwL0CxvZvIakz18296YJ2
 UAfGtoPQ9nZNS9iI1ZWWsZno82G61lxmhk/1+8HWXuc4j4LEZ7hI3fy+AJgEQYTE
 Fgtkf8CVO8SpeWrXDLyHz0kNYehPK3DP0s8igU4W+YqorjnJ+an6inbTMUkzz6m/
 FqNl0yv+Q53QoquWyuMbrhswmtZRfSw/WWdCn1h7iKQFqc2LyS2q8TDWNsZzANI0
 zvUpzeO208dPR1baAdWSM+a+9Y/OoRQ/EytLyygGT5lMzLW6augPH308RwllqeC9
 ig8nYYdmR4T/42/EDTB02ZYpZpu7g==
X-ME-Sender: <xms:8lVeYD9Bfq-r1LGeV-SYIYw1lNZbU4hmw6wDhK5AKaxOU-Eq5ukATw>
 <xme:8lVeYHW9TmM2-qX_MJ9-bZ2Cm0lKiFkPgu_I7EimFM1YLDXiIWNzSxASxeMeJjOU8
 aAFsKwer0D0Kym08w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudehvddgudehjecutefuodetggdotefrod
 ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh
 necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd
 enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm
 rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc
 ggtffrrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdej
 ueeiiedvffegheenucfkphepvddriedrledvrddvheenucevlhhushhtvghrufhiiigvpe
 dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhn
 vght
X-ME-Proxy: <xmx:8lVeYOrDArOOwrPTceUnnPLG0YDal-dKRl11gALpGdp6Qu2HZcyRLw>
 <xmx:8lVeYJlkds_zDevkOhNDR8wQRB4BBQt8FyYAtOu5X8_0tFBWAGSxqw>
 <xmx:8lVeYO1ov5PACHXT8ShwSCf-pj99wjXGF13KfUD7tLOk38H1VK7nCw>
 <xmx:81VeYK236HcZ_J1XnC_3s0bq8r3Z7PAhFb6-fZasV46ZhRsi9JvJEg>
Received: from xps.localnet (apoitiers-654-1-21-25.w2-6.abo.wanadoo.fr
 [2.6.92.25])
 by mail.messagingengine.com (Postfix) with ESMTPA id 382E1108005F;
 Fri, 26 Mar 2021 17:45:20 -0400 (EDT)
From: Thomas Monjalon <thomas@monjalon.net>
To: Ferruh Yigit <ferruh.yigit@intel.com>
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>
Date: Fri, 26 Mar 2021 22:45:14 +0100
Message-ID: <5172427.nD0jqgIutm@thomas>
In-Reply-To: <4d61a941-5262-7da3-bed8-12cc360e5f59@intel.com>
References: <20210311221742.3750589-1-thomas@monjalon.net>
 <272955377.2llAV7lm0X@thomas>
 <4d61a941-5262-7da3-bed8-12cc360e5f59@intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
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>

26/03/2021 16:37, Ferruh Yigit:
> 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.

OK thanks