netdev - Re: [PATCH net-next v5 01/10] devlink: Add permanent config parameter get/set operations

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, 31 Oct 2017 10:00:24 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jakub Kicinski <kubakici@...pl>
Cc:     Steve Lin <steven.lin1@...adcom.com>, netdev@...r.kernel.org,
        jiri@...lanox.com, davem@...emloft.net, michael.chan@...adcom.com,
        linville@...driver.com, gospo@...adcom.com, yuvalm@...lanox.com
Subject: Re: [PATCH net-next v5 01/10] devlink: Add permanent config
 parameter get/set operations

Tue, Oct 31, 2017 at 09:04:18AM CET, kubakici@...pl wrote:
>On Tue, 31 Oct 2017 08:17:30 +0100, Jiri Pirko wrote:
>> Mon, Oct 30, 2017 at 11:12:13PM CET, kubakici@...pl wrote:
>> >On Mon, 30 Oct 2017 18:03:01 +0100, Jiri Pirko wrote:  
>> >I'm not sure what the status of the reconfig trigger patches for mlxsw
>> >is, but we actually may need 3 config sets:
>> > - current/runtime configurable, 
>> > - requiring soft reset of the device/driver reinit;
>> > - requiring hard reset/set on boot.
>> >
>> >Secondly, IMHO calling set/get parameters "permanent" is a bit
>> >backwards.  One device may not be able to change max VF counts or MSIX
>> >allocation without full reinit of PCIe blocks, but for others soft
>> >reset is more than enough.  Port splitting is another example.  For 
>> >NICs port splitting at runtime is usually not a priority in HW/FW
>> >development, so some form of reset is generally required, while
>> >switches can split a port at runtime.  IOW we should define parameters
>> >without assigning them to config sets in the ABI itself.  And also we
>> >should make it in a way which will allow existing parameters to be
>> >reused in permanent/sort reset required/runtime modes.
>> >
>> >Does that make sense?  
>> 
>> "IOW we should define parameters without assigning them to config sets
>> in the ABI itself" - I don't understand what do you mean by this.
>
>OK, whether the setting is permanent or not - is device specific.
>
>I'm basically asking to remove the "PERM" from the names and indicate
>which config set (of the 3 enumerated above) user wants it applied in a
>separate attribute.

Yesh, would be good if driver could indicate which option is of what
type and devlink should expose this information to the user.

But it probably should be flags. Driver may provide possibility to
configure for example VF count as runtime and also permanent option.
User should pass the correct flags along the set message so the driver
knows what to set. Makes sense?