Tue, Feb 27, 2024 at 03:37:00AM CET, [email protected] wrote: >On Sun, 25 Feb 2024 08:18:00 +0100 Jiri Pirko wrote: >> >Do you recall any specific param that got rejected from mlx5? >> >Y'all were allowed to add the eq sizing params, which I think >> >is not going to be mlx5-only for long. Otherwise I only remember >> >cases where I'd try to push people to use the resource API, which >> >IMO is better for setting limits and delegating resources. >> >> I don't have anything solid in mind, I would have to look it up. But >> there is certainly quite big amount of uncertainties among my >> colleagues to jundge is some param would or would not be acceptable to >> you. That's why I believe it would save a lot of people time to write >> the policy down in details, with examples, etc. Could you please? > >How about this? (BTW took me half an hour to write, just in case >you're wondering) > >diff --git a/Documentation/networking/devlink/devlink-params.rst >b/Documentation/networking/devlink/devlink-params.rst >index 4e01dc32bc08..f1eef6d065be 100644 >--- a/Documentation/networking/devlink/devlink-params.rst >+++ b/Documentation/networking/devlink/devlink-params.rst >@@ -9,10 +9,12 @@ level device functionality. Since devlink can operate at the >device-wide > level, it can be used to provide configuration that may affect multiple > ports on a single device. > >-This document describes a number of generic parameters that are supported >-across multiple drivers. Each driver is also free to add their own >-parameters. Each driver must document the specific parameters they support, >-whether generic or not. >+There are two categories of devlink parameters - generic parameters >+and device-specific quirks. Generic devlink parameters are configuration >+knobs which don't fit into any larger API, but are supported across multiple >+drivers. This document describes a number of generic parameters. >+Each driver can also add its own parameters, which are documented in driver >+specific files. > > Configuration modes > =================== >@@ -137,3 +139,32 @@ own name. > * - ``event_eq_size`` > - u32 > - Control the size of asynchronous control events EQ. >+ >+Adding new params >+================= >+ >+Addition of new devlink params is carefully scrutinized upstream. >+More complete APIs (in devlink, ethtool, netdev etc.) are always preferred, >+devlink params should never be used in their place e.g. to allow easier >+delivery via out-of-tree modules, or to save development time. >+ >+devlink parameters must always be thoroughly documented, both from technical >+perspective (to allow meaningful upstream review), and from user perspective >+(to allow users to make informed decisions). >+ >+The requirements above should make it obvious that any "automatic" / >+"pass-through" registration of devlink parameters, based on strings >+read from the device, will not be accepted. >+ >+There are two broad categories of devlink params which had been accepted >+in the past: >+ >+ - device-specific configuration knobs, which cannot be inferred from >+ other device configuration. Note that the author is expected to study >+ other drivers to make sure that the configuration is in fact unique >+ to the implementation. >+ >+ - configuration which must be set at device initialization time. >+ Allowing user to enable features at runtime is always preferable >+ but in reality most devices allow certain features to be enabled/disabled >+ only by changing configuration stored in NVM.
Looks like most of the generic params does not fit either of these 2 categories. Did you mean these 2 categories for driver specific?
