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

[Thomas Monjalon]

03/08/2017 18:15, Stephen Hemminger:
> On Thu, 3 Aug 2017 14:21:38 +0100
> Bruce Richardson <bruce.richardson at intel.com> wrote:
> 
> > 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.
> 
> My 2c. No.
> 
> Short answer:
> Ioctl's were a bad idea in Unix (per Dennis Ritchie et al) and are now
> despised by Linux kernel developers. They provide an unstructured, unsecured,
> back door for device driver abuse. Try to get a new driver in Linux with
> a unique ioctl, and it will be hard to get accepted.
> 
> Long answer:
> So far every device specific feature has fit into ethdev model. Doing ioctl
> is admitting "it is too hard to be general, we need need an out". For something
> that is a flag, it should fit into existing config model; ignoring silly ABI constraints.
> For a real feature (think flow direction), we want a first class API for that.
> For a wart, then devargs will do.
> 
> Give a good example of something that should be an ioctl. Don't build the
> API first and then let it get cluttered.

I agree with Stephen.

And please do not forget that ioctl still requires an API:
the argument that you put in ioctl is the API of the feature.
So it is the same thing as defining a new function.

The real debate is to decide if we want to continue adding more
control path features in DPDK or focus on Rx/Tx.
But this discussion would be better lead with some examples/requests.