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]

Message-ID: <BLUPR0701MB200425BE49D0578371379A138DC80@BLUPR0701MB2004.namprd07.prod.outlook.com>
Date:   Wed, 7 Jun 2017 17:48:08 +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?

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.