netdev - Re: [PATCH net-next 00/16] nfp: ctrl vNIC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 6 Jun 2017 13:20:43 +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

Tue, Jun 06, 2017 at 11:35:08AM 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....