On 7/19/2018 4:49 AM, Jakub Kicinski wrote:

On Wed, 18 Jul 2018 18:01:01 -0700, Saeed Mahameed wrote:

quoted

+static const struct devlink_param mlx5_devlink_params[] = {
+	DEVLINK_PARAM_DRIVER(MLX5_DEVLINK_PARAM_ID_CONGESTION_ACTION,
+			     "congestion_action",
+			     DEVLINK_PARAM_TYPE_U8,
+			     BIT(DEVLINK_PARAM_CMODE_RUNTIME),
+			     mlx5_devlink_get_congestion_action,
+			     mlx5_devlink_set_congestion_action, NULL),
+	DEVLINK_PARAM_DRIVER(MLX5_DEVLINK_PARAM_ID_CONGESTION_MODE,
+			     "congestion_mode",
+			     DEVLINK_PARAM_TYPE_U8,
+			     BIT(DEVLINK_PARAM_CMODE_RUNTIME),
+			     mlx5_devlink_get_congestion_mode,
+			     mlx5_devlink_set_congestion_mode, NULL),
+};

The devlink params haven't been upstream even for a full cycle and
already you guys are starting to use them to configure standard
features like queuing.

We developed the devlink params in order to support non-standard 
configuration only. And for non-standard, there are generic and vendor 
specific options.
The queuing model is a standard. However here we are configuring the 
outbound PCIe buffers on the receive path from NIC port toward the 
host(s) in Single / MultiHost environment.
(You can see the driver processing based on this param as part of the RX 
patch for the marked option here https://patchwork.ozlabs.org/patch/945998/)

I know your HW is not capable of doing full RED offload, it's a
snowflake. 

The algorithm which is applied here for the drop option is not the core 
of this feature.

You tell us you're doing custom DCB configuration hacks on
one side (previous argument we had) and custom devlink parameter
configuration hacks on PCIe.

Perhaps the idea that we're trying to use the existing Linux APIs for
HW configuration only applies to forwarding behaviour.

Hopefully I explained above well why it is not related.