Wed, Jun 07, 2017 at 07:48:08PM 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.... > >Separate from the netdevices, yes. But I think it's still a networking >facility. >I.e., would it make sense creating devlink nodes for PCI devices?
True that devlink is placed in net/core. But from the very beginning, it was designed to be multipurpose. So not only for net devices, but for any device where is is suitable. > >Anyway, I don't think there's any *strong* need for what I was asking for; >It's simply that I was thinking of qed where there's quite a bit going on >during the pci probe, and thought how re-doing it can be avoided. You can (should) register devlink early on way before netdevs.
