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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <PH0PR12MB5481901FE559D9911BCE9548DC289@PH0PR12MB5481.namprd12.prod.outlook.com>
Date:   Thu, 3 Feb 2022 18:35:54 +0000
From:   Parav Pandit <parav@...dia.com>
To:     Saeed Mahameed <saeedm@...dia.com>,
        Jakub Kicinski <kuba@...nel.org>
CC:     Saeed Mahameed <saeed@...nel.org>,
        Sunil Sudhakar Rani <sunrani@...dia.com>,
        Jiri Pirko <jiri@...dia.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        Bodong Wang <bodong@...dia.com>
Subject: RE: [PATCH net-next 1/2] devlink: Add support to set port function as
 trusted

Hi Jakub, Saeed,

> From: Saeed Mahameed <saeedm@...dia.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>

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?