Date:   Thu, 8 Jun 2017 08:38:45 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     "Mintz, Yuval" <Yuval.Mintz@...ium.com>
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

Thu, Jun 08, 2017 at 08:33:11AM CEST, Yuval.Mintz@...ium.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.
>
>

Powered by blists - more mailing lists