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: <PH0PR12MB548176ED1E1B5ED1EF2BB88EDC519@PH0PR12MB5481.namprd12.prod.outlook.com>
Date:   Tue, 11 Jan 2022 18:26:16 +0000
From:   Parav Pandit <parav@...dia.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     Sunil Sudhakar Rani <sunrani@...dia.com>,
        Saeed Mahameed <saeedm@...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: Jakub Kicinski <kuba@...nel.org>
> Sent: Tuesday, January 11, 2022 11:50 PM
> 
> On Tue, 11 Jan 2022 16:57:54 +0000 Parav Pandit wrote:
> > > > What shortcomings do you see in the finer granular approach we
> > > > want to go to enable/disable On a per feature basis instead of global
> knob?
> > >
> > > I was replying to Saeed so I assumed some context which you probably
> lack.
> > > Granular approach is indeed better, what I was referring to when I
> > > said "prefer an API as created by this patch" was having an
> > > dedicated devlink op, instead of the use of devlink params.
> >
> > This discussed got paused in yet another year-end holidays. :)
> > Resuming now and refreshing everyone's cache.
> >
> > We need to set/clear the capabilities of the function before deploying such
> function.
> > As you suggested we discussed the granular approach and at present we
> have following features to on/off.
> >
> > Generic features:
> > 1. ipsec offload
> 
> Why is ipsec offload a trusted feature?
>
It isn't trusted feature. The scope in few weeks got expanded from trusted to more granular at controlling capabilities.
One that came up was ipsec or other offloads that consumes more device resources.
 
> > 2. ptp device
> 
> Makes sense.
> 
> > Device specific:
> > 1. sw steering
> 
> No idea what that is/entails.
> 
:) it the device specific knob.

> > 2. physical port counters query
> 
> Still don't know why VF needs to know phy counters.
>
A prometheous kind of monitoring software wants to monitor the physical port counters, running in a container.
Such container doesn't have direct access to the PF or physical representor.
Just for sake of monitoring counters, user doesn't want to run the monitoring container in root net ns.
 
> > It was implicit that a driver API callback addition for both types of features is
> not good.
> > Devlink port function params enables to achieve both generic and device
> specific features.
> > Shall we proceed with port function params? What do you think?
> 
> I already addressed this. I don't like devlink params. They muddy the water
> between vendor specific gunk and bona fide Linux uAPI. Build a normal
> dedicated API.
For sure we prefer the bona fide Linux uAPI for standard features.
But internal knobs of how to do steering etc, is something not generic enough.
May be only those quirks live in the port function params and rest in standard uAPIs?