Re: [dpdk-dev] [RFC] ethdev: add ioctl-like API to control device specific features

[Bruce Richardson <bruce.richardson@intel.com>]

On Thu, Aug 03, 2017 at 01:21:35PM +0100, Chilikin, Andrey wrote:
> To control some device-specific features public device-specific functions
> rte_pmd_*.h are used.
> 
> But this solution requires applications to distinguish devices at runtime
> and, depending on the device type, call corresponding device-specific
> functions even if functions' parameters are the same.
> 
> IOCTL-like API can be added to ethdev instead of public device-specific
> functions to address the following:
> 
> * allow more usable support of features across a range of NIC from
>   one vendor, but not others
> * allow features to be implemented by multiple NIC drivers without
>   relying on a critical mass to get the functionality in ethdev
> * there are a large number of possible device specific functions, and
>   creating individual APIs for each one is not a good solution
> * IOCTLs are a proven method for solving this problem in other areas,
>   i.e. OS kernels.
> 
> Control requests for this API will be globally defined at ethdev level, so
> an application will use single API call to control different devices from
> one/multiple vendors.
> 
> API call may look like as a classic ioctl with an extra parameter for
> argument length for better sanity checks:
> 
> int
> rte_eth_dev_ioctl(uint16_t port, uint64_t ctl, void *argp,
>         unsigned arg_length);
> 
> Regards,
> Andrey

I think we need to start putting in IOCTLs for ethdevs, much as I hate
to admit it, since I dislike IOCTLs and other functions with opaque
arguments! Having driver specific functions I don't think will scale
well as each vendor tries to expose as much of their driver specific
functionality as possible.

One other additional example: I discovered just this week another issue
with driver specific functions and testpmd, when I was working on the
meson build rework.

* With shared libraries, when we do "ninja install" we want our DPDK
  libs moved to e.g. /usr/local/lib, but the drivers moved to a separate
  driver folder, so that they can be automatically loaded from that
  single location by DPDK apps [== CONFIG_RTE_EAL_PMD_PATH].
* However, testpmd, as well as using the drivers as plugins, uses
  driver-specific functions, which means that it explicitly links
  against the pmd .so files.
* Those driver .so files are not in with the other libraries, so ld.so
  does not find the pmd, and the installed testpmd fails to run due to
  missing library dependencies.
* The workaround is to add the drivers path to the ld load path, but we
  should not require ld library path changes just to get DPDK apps to
  work.

Using ioctls instead of driver-specific functions would solve this.

My 2c.

Regards,
/Bruce

PS: Following discussion on-list, this probably should be discussed at a
tech board meeting, to close it out.