Date:   Thu, 8 Jun 2017 06:33:11 +0000
From:   "Mintz, Yuval" <Yuval.Mintz@...ium.com>
To:     Jiri Pirko <jiri@...nulli.us>
CC:     Jakub Kicinski <kubakici@...pl>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "oss-drivers@...ronome.com" <oss-drivers@...ronome.com>
Subject: RE: [PATCH net-next 00/16] nfp: ctrl vNIC

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

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?

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.

Powered by blists - more mailing lists