From: Jakub Kicinski <kuba@kernel.org>
Sent: Wednesday, January 12, 2022 1:27 AM

On Tue, 11 Jan 2022 19:39:37 +0000 Parav Pandit wrote:

quoted

quoted

From: Jakub Kicinski <kuba@kernel.org>
Sent: Wednesday, January 12, 2022 12:54 AM

On Tue, 11 Jan 2022 18:26:16 +0000 Parav Pandit wrote:

quoted

It isn't trusted feature. The scope in few weeks got expanded from
trusted to more granular at controlling capabilities. One that
came up was ipsec or other offloads that consumes more device

resources.

quoted

quoted

That's what I thought. Resource control is different than
privileges, and requires a different API.

It's the capability that is turned on/off.
A device is composed based on what is needed. ipsec offload is not always

needed.

quoted

Its counter intuitive to expose some low level hardware resource to disable

ipsec indirectly.

quoted

So it is better to do as capability/param rather than some resource.
It is capability is more than just resource.

Wouldn't there be some limitation on the number of SAs or max throughput or
such to limit on VF hogging the entire crypto path?

The fairness among VFs is present via the QoS knobs. Hence it doesn't hogg the entire crypto path.
 

I was expecting such a knob, and then turning it to 0 would effectively remove
the capability (FW can completely hide it or driver ignore it).

quoted

quoted

quoted

A prometheous kind of monitoring software wants to monitor the
physical port counters, running in a container. Such container
doesn't have direct access to the PF or physical representor. Just
for sake of monitoring counters, user doesn't want to run the
monitoring container in root net ns.

Containerizing monitors seems very counter-intuitive to me.

May be. But it is in use at [1] for a long time now.

[1] docker run -p 9090:9090 prom/prometheus

How is it "in use" if we haven't merged the patch to enable it? :) What does it
monitor? PHYs port does not include east-west traffic, exposing just the PHYs
stats seems like a half measure.

Containerized monitors are in use by running in monitor in same net ns of the PF having full access to the PF.
The monitor is interested in physical port counters related to link transitions, link errors, buffer overruns etc.

quoted

quoted

quoted

For sure we prefer the bona fide Linux uAPI for standard features.
But internal knobs of how to do steering etc, is something not
generic enough. May be only those quirks live in the port function
params and rest in standard uAPIs?

Something talks to that steering API, and it's not netdev. So please
don't push problems which are not ours onto us.

Not sure I follow you.
Netdev of a mlx5 function talks to the driver internal steering API in
addition to other drivers operating this mlx5 function.

But there is no such thing as "steering API" in netdev. We can expose the
functionality we do have, if say PTP requires some steering then enabling PTP
implies the required steering is enabled. "steering API"
as an entity is meaningless to a netdev user.

It is the internal mlx5 implementation of how to do steering, triggered by netdev ndo's and other devices callback.
There are multiple options on how steering is done.
Such as sw_steering or dev managed steering.
There is already a control knob to choose sw vs dev steering as devlink param on the PF at [1].
This [1] device specific param is only limited to PF. For VFs, HV need to enable/disable this capability on selected VF.
API wise nothing drastic is getting added here, it's only on different object. (instead of device, it is port function).

[1] https://www.kernel.org/doc/html/v5.8/networking/device_drivers/mellanox/mlx5.html#devlink-parameters