Wed, Oct 18, 2017 at 03:22:03PM CEST, steven.l...@broadcom.com wrote: >On Wed, Oct 18, 2017 at 9:01 AM, Jiri Pirko <j...@resnulli.us> wrote: >> Wed, Oct 18, 2017 at 02:39:42PM CEST, steven.l...@broadcom.com wrote: >>>On Wed, Oct 18, 2017 at 3:31 AM, Jiri Pirko <j...@resnulli.us> wrote: >>>> >>>> You need to split the config option to those that are per-port and to >>>> those that are per-asic. For each family, you have to use ither >>>> devlink_port of devlink handle. Also, you need to split into those that are >>>> permanent and to those who are teporary (until reset). I think you might >>>> need some flags for that. >>>> >>> >>>All these are permanent; none are temporary - that's (partially) why >>>we consider these to be devlink/device parameters rather than a >>>netdev/ethtool thing, since they take effect after the next reset and >>>before any drivers are loaded (i.e. the card uses these parameters for >>>its default/startup configuration). >> >> Understood. But I think that this iface should be capable to serve the >> options of non-permanent as well. Or this could be 2 separate interfaces >> with 2 separate cmd pair. Thoughts? >> > >I would prefer to keep this command for permanent config only, and use >a separate command for transient configuration. I think that >transient device configuration should be tackled in the separate >discussion that was started in the RFC version of this patchset, >related to moving ethtool ops to devlink/netlink. > >I think that's a separate topic that requires a little more thought >and discussion, but really isn't that related to this current patchset >for permanent device configuration. What do you think?
Makes sense. Then you need to clearly mark the cmds with "permanent" keyword in name and enhance the description.
