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 for Android: free password hash cracker in your pocket

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

Date:   Tue, 6 Jun 2017 09:35:08 +0000
From:   "Mintz, Yuval" <Yuval.Mintz@...ium.com>
To:     Jiri Pirko <jiri@...nulli.us>, Jakub Kicinski <kubakici@...pl>
CC:     "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.