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

[Thomas Monjalon <thomas@monjalon.net>]

04/08/2017 11:59, Chilikin, Andrey:
> > 03/08/2017 18:15, Stephen Hemminger:
> > > On Thu, 3 Aug 2017 14:21:38 +0100
> > > Bruce Richardson <bruce.richardson@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.
> 
> In addition to what Bruce mentioned above, anything that requires dynamic re-configuration at run time would be a good example:
> * Internal resources partitioning, for example, RX buffers allocation for different traffic classes/flow types, depending on the load
> * Mapping user priorities from different sources (VLAN's PCP bits, IP DSCP, MPLS Exp) to traffic classes
> * Dynamic queue regions allocation for traffic classes
> * Dynamic statistics allocation
> * Dynamic flow types configuration depending on loaded parser profile

Why should it be device-specific?
If capabilities are well advertised, it could be generic.