2016-03-01 14:37, Stephen Hemminger:
> On Tue, 1 Mar 2016 13:36:39 +0800
> Wang Xiao W <xiao.w.wang at intel.com> wrote:
> > +static int
> > +fm10k_check_ftag(struct rte_devargs *devargs)
> > +{
> > + if (devargs == NULL)
> > + return 0;
> > +
> > + if (strstr(devargs->args, "enable_ftag=1") == NULL)
> > + return 0;
> > +
> > + return 1;
> > +}
>
> It is good to see the DPDK keeping up with the leading edge of hardware
> support.
>
> My issue is that devargs are the Linux module parameters method of
> configuration in the DPDK world. They are an API only a developer
> would love..
>
> 1. It has to be done at boot
For vdev it can be done later.
The devargs can be generalized in the driver model to provide a
configuration interface per device.
> 2. Applications have to rewrite (or expect customer) to pass args
Like said above, if the devargs are correctly implemented, there will
be some API to pass them.
> 3. Can't be changed at runtime
Same point as 1.
> 4. Can't be selected on per device basis.
No. The devargs are args per device.
For PCI, they are currently passed in the whitelist.
> Please find a better way.
Another way would be to extend the configuration structures.
I think it's better to re-think the device configuration and the command line
using some devargs and more functions, ops and structs to configure the really
generic stuff.
This devargs goes in the direction of a flexible configuration, so I'd vote +1.
