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

[Jiri Pirko <jiri@resnulli.us>]

Tue, Jan 11, 2022 at 07:20:05PM CET, kuba@kernel.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?