Tue, Feb 27, 2024 at 02:05:45PM CET, [email protected] wrote: >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.
Do you assume or read it somewhere? I don't see it. I have the same assumption though :)
