Thu, Jun 08, 2017 at 08:33:11AM 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. > >Given that I can't really register it sooner than the PCI probe, >how would shortly-before or way-before differ?
Yeah. Pci probe is the limit :) > >Assume you have some userspace daemon monitoring devlink and applying >user-provided configuration. >How could it reliably apply the configuration between devlink registration >and netdevice registeration? You cannot assume that. That is why I suggested devlink config and then a trigger to re-initialize the hw and the netdevices. > >The merit of the udev suggestion was that the sync. point was in userspace, >so user could always make sure that devlink rules apply before netdev state >changes. > >