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: <YeE/RfKb0bxQmJOq@nanopsycho>
Date:   Fri, 14 Jan 2022 10:15:49 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Parav Pandit <parav@...dia.com>,
        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

Tue, Jan 11, 2022 at 07:20:05PM CET, kuba@...nel.org wrote:
>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?
>
>> 2. ptp device
>
>Makes sense.
>
>> Device specific:
>> 1. sw steering
>
>No idea what that is/entails.
>
>> 2. physical port counters query
>
>Still don't know why VF needs to know phy counters.
>
>> 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.

Well, that is indeed true. But on the other hand, what is the alternative
solution? There are still going to be things wich are generic and driver-
specific. Params or no params. Or do you say we need some new well
defined enum-based api for generic stuff and driver-speficic will just
go to params?