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] [day] [month] [year] [list]

Message-ID: <PH0PR12MB54818E260064412F2390A2B2DC2E9@PH0PR12MB5481.namprd12.prod.outlook.com>
Date:   Wed, 9 Feb 2022 04:21:14 +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,

> From: Parav Pandit
> Sent: Monday, February 7, 2022 8:15 PM
> 
> > 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?
> 

Can you please review above interface? We would like to enable users.