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. >