From: Ferruh Yigit <ferruh.yigit@intel.com>
To: "Zapolski, MarcinX A" <marcinx.a.zapolski@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: Jerin Jacob <jerin.jacob@caviumnetworks.com>,
"Laatz, Kevin" <kevin.laatz@intel.com>
Subject: Re: [dpdk-dev] [RFC 19.11 v2 1/3] ethdev: hide key ethdev structures from public API
Date: Mon, 9 Sep 2019 11:24:27 +0100 [thread overview]
Message-ID: <3a8e2412-12a0-7f18-1380-a50e5807373c@intel.com> (raw)
In-Reply-To: <51FEE37A1339864DB0A4E34597F561E30D5D6AB2@HASMSX113.ger.corp.intel.com>
On 9/9/2019 11:02 AM, Zapolski, MarcinX A wrote:
>> -----Original Message-----
>> From: Yigit, Ferruh
>> Sent: Monday, September 9, 2019 12:00 PM
>> To: Zapolski, MarcinX A <marcinx.a.zapolski@intel.com>; dev@dpdk.org
>> Subject: Re: [dpdk-dev] [RFC 19.11 v2 1/3] ethdev: hide key ethdev
>> structures from public API
>>
>> On 9/9/2019 9:07 AM, Zapolski, MarcinX A wrote:
>>>> -----Original Message-----
>>>> From: Yigit, Ferruh
>>>> Sent: Friday, September 6, 2019 4:38 PM
>>>> To: Zapolski, MarcinX A <marcinx.a.zapolski@intel.com>; dev@dpdk.org
>>>> Subject: Re: [dpdk-dev] [RFC 19.11 v2 1/3] ethdev: hide key ethdev
>>>> structures from public API
>>>>
>>>> On 9/6/2019 2:18 PM, Marcin Zapolski wrote:
>>>>> Split rte_eth_dev structure to two parts: head that is available for
>>>>> user applications, and rest which is DPDK internal.
>>>>> Make an array of pointers to rte_eth_dev structures available for
>>>>> user applications.
>>>>>
>>>>> Signed-off-by: Marcin Zapolski <marcinx.a.zapolski@intel.com>
>>>>
>>>> <...>
>>>>
>>>>> diff --git a/lib/librte_bitratestats/rte_bitrate.c
>>>>> b/lib/librte_bitratestats/rte_bitrate.c
>>>>> index 639e47547..82d469514 100644
>>>>> --- a/lib/librte_bitratestats/rte_bitrate.c
>>>>> +++ b/lib/librte_bitratestats/rte_bitrate.c
>>>>> @@ -3,7 +3,7 @@
>>>>> */
>>>>>
>>>>> #include <rte_common.h>
>>>>> -#include <rte_ethdev.h>
>>>>> +#include <rte_ethdev_driver.h>
>>>>
>>>> This is in the library, not sure if libraries should include the
>>>> header file for the drivers, can you please explain why this change is
>> needed?
>>>>
>>> It is needed to make rte_eth_dev structure available. But yes, I agree that
>> it will be more appropriate to include rte_ethdev.h and rte_ethdev_core.h
>> separately. I probably wanted less includes, silly me.
>>>> <...>
>>>>
>>>>> @@ -6,6 +6,7 @@
>>>>> #define _RTE_ETHDEV_PROFILE_H_
>>>>>
>>>>> #include "rte_ethdev.h"
>>>>> +#include "rte_ethdev_core.h"
>>>>>
>>>>> /**
>>>>> * Initialization of the Ethernet device profiling.
>>>>> diff --git a/lib/librte_ethdev/rte_ethdev.c
>>>>> b/lib/librte_ethdev/rte_ethdev.c index 17d183e1f..5c6cc640a 100644
>>>>> --- a/lib/librte_ethdev/rte_ethdev.c
>>>>> +++ b/lib/librte_ethdev/rte_ethdev.c
>>>>> @@ -40,6 +40,7 @@
>>>>>
>>>>> #include "rte_ether.h"
>>>>> #include "rte_ethdev.h"
>>>>> +#include "rte_ethdev_core.h"
>>>>> #include "rte_ethdev_driver.h"
>>>>> #include "ethdev_profile.h"
>>>>> #include "ethdev_private.h"
>>>>
>>>> I was hoping "rte_ethdev_core.h" can be removed completely by
>>>> distributing its content to "ethdev_private.h", "rte_ethdev_driver.h"
>>>> and perhaps even to "rte_ethdev.h".
>>>>
>>>> Can you please explain what prevents removing "rte_ethdev_core.h"?
>>> I could rename it to rte_ethdev_private. There is just rte_eth_dev and
>> rte_eth_dev_data left in it.
>>>
>>
>> I think drivers access to both 'rte_eth_dev' and 'rte_eth_dev_data' so can't
>> move them to 'ethdev_private.h' why not move it to 'rte_ethdev_driver.h'?
>
> Because the libraries use them as well.
>
These are 'librte_ethdev' library internal data, I think other libraries
shouldn't access them directly.
As far as I can see,
librte_eventdev => rte_eth_dev_data
librte_eventdev => rte_eth_dev
librte_telemetry => rte_eth_dev
Can you see any other library accessing 'rte_eth_dev' and 'rte_eth_dev_data' ?
I am not sure about 'eventdev', specially because of the Rx/Tx adapters of it,
perhaps they can include the "rte_ethdev_driver.h", cc'ed Jerin.
I didn't check the telemetry code, but I assume it can be fixed too, but for now
"rte_ethdev_driver.h" can be included to highlight something is wrong there.
And related "ethdev_private.h", as far as I understand it is not private to all
libraries, it is private to the ethdev library, which means only should be used
to share the definitions withing ethdev library .c files. So no other library
should include it.
next prev parent reply other threads:[~2019-09-09 10:24 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-30 12:49 [dpdk-dev] [RFC 19.11 0/2] Hide DPDK internal struct " Marcin Zapolski
2019-07-30 12:49 ` [dpdk-dev] [RFC 19.11 1/2] ethdev: make DPDK core functions non-inline Marcin Zapolski
2019-07-30 15:01 ` Jerin Jacob Kollanukkaran
2019-07-30 15:32 ` Bruce Richardson
2019-07-30 15:25 ` Stephen Hemminger
2019-07-30 15:33 ` Bruce Richardson
2019-07-30 15:54 ` Stephen Hemminger
2019-07-30 16:04 ` Wiles, Keith
2019-07-30 16:11 ` Bruce Richardson
2019-07-30 16:23 ` Stephen Hemminger
2019-07-30 12:49 ` [dpdk-dev] [RFC 19.11 2/2] ethdev: hide DPDK internal struct from public API Marcin Zapolski
2019-07-30 14:53 ` Ferruh Yigit
2019-09-06 13:18 ` [dpdk-dev] [RFC 19.11 v2 0/3] Hide " Marcin Zapolski
2019-09-06 14:00 ` Bruce Richardson
2019-09-06 13:18 ` [dpdk-dev] [RFC 19.11 v2 1/3] ethdev: hide key ethdev structures " Marcin Zapolski
2019-09-06 14:37 ` Ferruh Yigit
2019-09-09 8:07 ` Zapolski, MarcinX A
2019-09-09 9:59 ` Ferruh Yigit
2019-09-09 10:02 ` Zapolski, MarcinX A
2019-09-09 10:24 ` Ferruh Yigit [this message]
2019-09-09 11:41 ` Zapolski, MarcinX A
2019-09-14 10:34 ` Jerin Jacob
2019-09-06 17:24 ` Stephen Hemminger
2019-09-09 9:01 ` Zapolski, MarcinX A
2019-09-10 9:59 ` Zapolski, MarcinX A
2019-09-10 10:06 ` Bruce Richardson
2019-09-10 10:13 ` Zapolski, MarcinX A
2019-09-10 12:19 ` Bruce Richardson
2019-09-10 12:22 ` Zapolski, MarcinX A
2019-09-06 13:18 ` [dpdk-dev] [RFC 19.11 v2 2/3] i40e: make driver compatible with changes in ethdev Marcin Zapolski
2019-09-06 13:18 ` [dpdk-dev] [RFC 19.11 v2 3/3] ixgbe: " Marcin Zapolski
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=3a8e2412-12a0-7f18-1380-a50e5807373c@intel.com \
--to=ferruh.yigit@intel.com \
--cc=dev@dpdk.org \
--cc=jerin.jacob@caviumnetworks.com \
--cc=kevin.laatz@intel.com \
--cc=marcinx.a.zapolski@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).