Tue, Jun 06, 2017 at 11:35:08AM CEST, yuval.mi...@cavium.com 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 :) > >Thinking about use cases where we'd want information available at probe time, >it might have been even better to have it separated from the netdevice, >e.g., providing clients with node to configure (generic?) information on top of >their PCI nodes.
Yuval, devlink is separated from the netdevices....
