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:   Thu, 8 Jun 2017 07:38:53 +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

Wed, Jun 07, 2017 at 07:48:08PM 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.