Re: [PATCH net-next 1/2] devlink: Add support to set port function as trusted

[Saeed Mahameed <saeedm@nvidia.com>]

On 03 Feb 18:35, Parav Pandit wrote:
>Hi Jakub, Saeed,
>
>> From: Saeed Mahameed <saeedm@nvidia.com>
>> Sent: Thursday, January 20, 2022 6:11 AM
>
>> >And _right_ amount of X bytes specific for sw_steering was not very clear.
>> >Hence the on/off resource knob looked more doable and abtract.
>> >
>> >I do agree you and Saeed that instead of port function param, port function
>> resource is more suitable here even though its bool.
>> >
>>
>> I believe flexibility can be achieved with some FW message? Parav can you
>> investigate ? To be clear here the knob must be specific to sw_steering
>> exposed as memory resource.
>>
>I investigated this further with hw and fw teams.
>The memory resource allocator doesn't understand the resource type for page allocation.
>And even if somehow it is extended, when the pages are freed, they are returned to the common pool cache instead of returning immediately to the driver. We will miss the efficiency gained with the caching and reusing these pages for other functions and for other resource types too.
>This cache efficiency is far more important for speed of resource allocation.
>
>And additionally, it is after all boolean feature to enable/disable a functionality.
>So I suggest, how about we do something like below?
>It is similar to ethtool -k option, but applicable at the HV PF side to enable/disable a feature for the functions.
>
>$ devlink port function feature set ptp/ipsec/tlsoffload on/off
>$ devlink port function feature set device_specific_feature1 on/off
>
>$ devlink port show
>pci/0000:06:00.0/1: type eth netdev eth0 flavour pcivf pfnum 0 vfnum 0
>  function:
>    hw_addr 00:00:00:00:00:00
>    feature:
>      tlsoffload <on/off>
>      ipsec <on/off>
>      ptp <on/off>
>      device_specific_feature1 <on/off>
>

Given the HW limitation of differentiating between memory allocated for
different resources, and after a second though about the fact that most of
ConnectX resources are mapped to ICM memory which is managed by FW,
although it would've been very useful to manager resources this way,
such architecture is very specific to ConnectX and might not suite other
vendors, so explicit API as the above sounds like a better compromise, 
but I would put device_specific_feature(s) into a separate category/list

basically you are looking for:

1) ethtool -k equivalent for devlink
2) ethtool --show-priv-flags equivalent for devlink

I think that's reasonable.

>This enables having well defined features per function and odd device specific feature.
>It also doesn't overload the device on doing accounting pages for boolean functionality.
>Does it look reasonable?