On Tue, 6 Jun 2017 11:17:57 +0200, Jiri Pirko wrote: > >> >What were your plans with pre-netdev config? > >> > >> We need to pass come initial resource division. Generally the consensus > >> is to have these options exposed through devlink, let the user configure > >> them all and then to have a trigger that would cause driver > >> re-orchestration according to the new values. The flow would look like > >> this: > >> > >> -driver loads with defaults, inits hw and instantiates netdevs > >> -driver exposes config options via devlink > >> -user sets up the options > >> -user pushes the "go" trigger > >> -upon the trigger command, devlink calls the driver re-init callback > >> -driver shuts down the current instances, re-initializes hw, > >> re-instantiates the netdevs > >> > >> Makes sense? > > > >I like the idea of a "go"/apply/reload trigger and extending devlink. > >Do you plan on adding a way to persist the settings? I'm concerned NIC > >users may want to boot into the right mode once it's set, without > >reloads and reconfigs upon boot. Also is there going to be a way to > >query the pending/running config? Sounds like we may want to expose > >three value sets - persistent/default, running and pending/to be > >applied. > > I don't think it is a good idea to introduce any kind of configuration > persistency in HW. I believe that user is the master and he has all > needed info. He can store it persistently, but it is up to him. > > So basicaly during boot, we need the devlink configuration to happen > early on, before the netdevices get configured. udev? Not sure how > exactly to do this. Have to ask around :)
Happy to hear that. Now there is two of us, I'll try again with the marketing dept :)
