On 2/27/24 13:17, Jiri Pirko wrote:
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)
Thank you!
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
re Jiri: Generic ones are described here.
+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.
What if it would not be unique, should they then proceed to add generic
(other word would be "common") param, and make the other driver/s use
it? Without deprecating the old method ofc.
What about knob being vendor specific, but given vendor has multiple,
very similar drivers? (ugh)
+
+ - 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?
If you mean the two paragraphs above (both started by "-"), this is for
vendor specific knobs, and reads fine.
