All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
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>
Subject: Re: [dpdk-dev] [PATCH v3 2/2] drivers/net: remove explicit include of legacy filtering
Date: Fri, 26 Mar 2021 15:37:19 +0000	[thread overview]
Message-ID: <4d61a941-5262-7da3-bed8-12cc360e5f59@intel.com> (raw)
In-Reply-To: <272955377.2llAV7lm0X@thomas>

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.


  reply	other threads:[~2021-03-26 15:37 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-11 22:17 [dpdk-dev] [PATCH 0/2] ethdev: remove some use of legacy filtering interface Thomas Monjalon
2021-03-11 22:17 ` [dpdk-dev] [PATCH 1/2] ethdev: replace callback getting filter operations Thomas Monjalon
2021-03-12  1:44   ` Wang, Haiyue
2021-03-12  8:22     ` Thomas Monjalon
2021-03-12  8:25       ` Andrew Rybchenko
2021-03-12  8:40         ` Wang, Haiyue
2021-03-12  7:09   ` Andrew Rybchenko
2021-03-12  8:26     ` Thomas Monjalon
2021-03-11 22:17 ` [dpdk-dev] [PATCH 2/2] drivers/net: remove explicit include of legacy filtering Thomas Monjalon
2021-03-12  1:21   ` Xu, Rosen
2021-03-12 17:46 ` [dpdk-dev] [PATCH v2 0/2] ethdev: remove some use of legacy filtering interface Thomas Monjalon
2021-03-12 17:46   ` [dpdk-dev] [PATCH v2 1/2] ethdev: replace callback getting filter operations Thomas Monjalon
2021-03-12 19:14     ` Ajit Khaparde
2021-03-13  4:16     ` Wang, Haiyue
2021-03-15  3:05     ` Xu, Rosen
2021-03-15  7:18     ` Andrew Rybchenko
2021-03-15  7:54       ` Thomas Monjalon
2021-03-15  8:43         ` Andrew Rybchenko
2021-03-15  8:55           ` Thomas Monjalon
2021-03-15  9:08             ` Andrew Rybchenko
2021-03-15  9:15               ` Thomas Monjalon
2021-03-19 18:12                 ` Thomas Monjalon
2021-03-20  7:54                   ` Andrew Rybchenko
2021-03-20 10:38                     ` Thomas Monjalon
2021-03-15  7:22     ` Hemant Agrawal
2021-03-12 17:46   ` [dpdk-dev] [PATCH v2 2/2] drivers/net: remove explicit include of legacy filtering Thomas Monjalon
2021-03-15  7:19     ` Hemant Agrawal
2021-03-21  8:59 ` [dpdk-dev] [PATCH v3 0/2] ethdev: remove some use " Thomas Monjalon
2021-03-21  9:00   ` [dpdk-dev] [PATCH v3 1/2] ethdev: replace callback getting filter operations Thomas Monjalon
2021-03-21  9:08     ` Andrew Rybchenko
2021-03-24 18:05     ` Ferruh Yigit
2021-03-26 17:41       ` Ferruh Yigit
2021-03-29 20:56     ` Matan Azrad
2021-03-21  9:00   ` [dpdk-dev] [PATCH v3 2/2] drivers/net: remove explicit include of legacy filtering Thomas Monjalon
2021-03-24 18:08     ` Ferruh Yigit
2021-03-24 20:00       ` Thomas Monjalon
2021-03-25  5:53         ` Andrew Rybchenko
2021-03-25 10:00           ` Ferruh Yigit
2021-03-25 10:20             ` Thomas Monjalon
2021-03-26 15:37               ` Ferruh Yigit [this message]
2021-03-26 21:45                 ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4d61a941-5262-7da3-bed8-12cc360e5f59@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=beilei.xing@intel.com \
    --cc=dev@dpdk.org \
    --cc=haiyue.wang@intel.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=jia.guo@intel.com \
    --cc=jingjing.wu@intel.com \
    --cc=qi.z.zhang@intel.com \
    --cc=qiming.yang@intel.com \
    --cc=rosen.xu@intel.com \
    --cc=sachin.saxena@oss.nxp.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.