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

Date:   Mon, 7 Feb 2022 14:45:08 +0000
From:   Parav Pandit <parav@...dia.com>
To:     Saeed Mahameed <saeedm@...dia.com>
CC:     Jakub Kicinski <kuba@...nel.org>,
        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


> From: Saeed Mahameed <saeedm@...dia.com>
> Sent: Friday, February 4, 2022 12:47 AM
> 
> On 03 Feb 18:35, Parav Pandit wrote:
> >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>
> >
> 
> 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.
> 

Right. I was thinking to put under single "feature" bucket like above.
Shall we proceed with this UAPI?

> >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?