> >> >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.
