From: Jakub Kicinski <kuba@kernel.org>
Sent: Friday, January 14, 2022 10:12 AM

On Thu, 13 Jan 2022 03:37:47 +0000 Parav Pandit wrote:

quoted

quoted

quoted

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

the entire crypto path.

Could you please fix your email client? It's incorrectly wrapping the quotes and
at the same time not wrapping your replies at all. :( What client is this?

I will fix the client.
 

quoted

quoted

Why do you want to disable it, then?

Each enabled feature consumes
(a) driver level memory resource such as querying ip sec capabilities
and more later,
(b) time in querying those capabilities,

These are on the VM's side, it's not hypervisors responsibility to help the client
by stripping features.

HV is composing the device before giving it to the VM.
VM can always disable certain feature if it doesn't want to use by ethtool or other means.
But here we are discussing about offering/not offering the feature to the VF from HV.
HV can choose to not offer certain features based on some instruction received from orchestration.

quoted

(c) device level initialization in supporting this capability

So for light weight devices which doesn't need it we want to keep it disabled.

You need to explain this better. We are pretty far from "trust"
settings, which are about privilege and not breaking isolation.

We split the abstract trust to more granular settings, some related to privilege and some to capabilities.
 

"device level initialization" tells me nothing.

Above one belongs to capabilities bucket. Sw_steering belongs to trust bucket.
 

quoted

quoted

quoted

It is the internal mlx5 implementation of how to do steering,
triggered by

netdev ndo's and other devices callback.

quoted

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].

quoted

This [1] device specific param is only limited to PF. For VFs, HV
need to

enable/disable this capability on selected VF.

quoted

API wise nothing drastic is getting added here, it's only on different

object.

quoted

quoted

(instead of device, it is port function).

quoted

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

Ah, that thing. IIRC this was added for TC offloads, VFs don't own
the eswitch so what rules are they inserting to require "high
insertion rate"? My suspicion is that since it's not TC it'd be
mostly for the "DR" feature you have hence my comment on it not being

netdev.

quoted

No it is limited to tc offloads.
A VF netdev inserts flow steering rss rules on nic rx table.
This also uses the same smfs/dmfs when a VF is capable to do so.

Given the above are you concerned about privilege or also just resources use
here? Do VFs have SMFS today?

Privilege.
VFs have SMFS today, but by default it is disabled. The proposed knob will enable it.