DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Ilya Maximets <i.maximets@samsung.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	Thomas Monjalon <thomas@monjalon.net>
Cc: "ovs-dev@openvswitch.org" <ovs-dev@openvswitch.org>,
	Konstantin Ananyev <konstantin.ananyev@intel.com>,
	"Stokes, Ian" <ian.stokes@intel.com>,
	Kevin Traynor <ktraynor@redhat.com>,
	Ophir Munk <ophirmu@mellanox.com>,
	Shahaf Shuler <shahafs@mellanox.com>,
	Eelco Chaudron <echaudro@redhat.com>
Subject: Re: [dpdk-dev] Direct using of 'rte_eth_devices' in DPDK apps.
Date: Fri, 16 Nov 2018 09:30:23 +0000	[thread overview]
Message-ID: <5bb61eff-3364-fb72-27d5-3aece424eee2@intel.com> (raw)
In-Reply-To: <70d58383-da8b-4c15-a8c4-f6f853268486@samsung.com>

On 11/16/2018 8:42 AM, Ilya Maximets wrote:
> Hi,
> While discussing the ways to enable DPDK 18.11 new features in OVS
> there was suggestions to use 'rte_eth_devices[]' array directly.
> But this array is marked as '@internal' and also it located in
> the internal header 'lib/librte_ethdev/rte_ethdev_core.h' with the
> following disclaimer:
> 
> /**
>  * @file
>  *
>  * RTE Ethernet Device internal header.
>  *
>  * This header contains internal data types. But they are still part of the
>  * public API because they are used by inline functions in the published API.
>  *
>  * Applications should not use these directly.
>  *
>  */
> 
> From the other hand, test-pmd and some example apps in DPDK source
> tree are using this array for various reasons.
> 
> So, is it OK to use this array directly or not?
> 
> In general we need to change the API, i.e. make 'rte_eth_devices' part
> of a public API. Or change the test-pmd and example apps to stop
> using it.
> 
> One more related question: Is it OK to access internal device
> stuff using 'device' pointer obtained by 'rte_eth_dev_info'?
> This looks really dangerous. It's unclear why pointers like this
> exposed to user.
> 
> Thoughts?

Agreed that applications shouldn't access 'rte_eth_devices' directly, they
should use handler (port_id) to access devices. Only drivers are allowed to
access these data structure directly.

Because of inline functions we are not able to completely hide these from
applications, and preferring inline functions for performance. Moving these data
structures to their own header and marking as internal was to clarify the
intended usage for them.

I support to clean testpmd and sample applications to prevent using internal
data structures.

> 
> Best regards, Ilya Maximets.
> 

      parent reply	other threads:[~2018-11-16  9:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20181116084233eucas1p2ae806fd36b2fa1ea77d1a450facb0922@eucas1p2.samsung.com>
2018-11-16  8:42 ` Ilya Maximets
2018-11-16  9:29   ` Thomas Monjalon
2018-11-16  9:51     ` Ananyev, Konstantin
2018-11-16 14:16       ` Wiles, Keith
2018-11-16 14:19       ` Wiles, Keith
2018-11-16  9:30   ` Ferruh Yigit [this message]

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=5bb61eff-3364-fb72-27d5-3aece424eee2@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=dev@dpdk.org \
    --cc=echaudro@redhat.com \
    --cc=i.maximets@samsung.com \
    --cc=ian.stokes@intel.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=ktraynor@redhat.com \
    --cc=ophirmu@mellanox.com \
    --cc=ovs-dev@openvswitch.org \
    --cc=shahafs@mellanox.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 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).