[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f320213f-7b1a-4a7b-9e0c-94168ca187db@redhat.com>
Date: Fri, 16 Aug 2024 10:52:58 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Jiri Pirko <jiri@...nulli.us>
Cc: netdev@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>,
Madhu Chittim <madhu.chittim@...el.com>,
Sridhar Samudrala <sridhar.samudrala@...el.com>,
Simon Horman <horms@...nel.org>, John Fastabend <john.fastabend@...il.com>,
Sunil Kovvuri Goutham <sgoutham@...vell.com>,
Jamal Hadi Salim <jhs@...atatu.com>
Subject: Re: [PATCH v3 03/12] net-shapers: implement NL get operation
On 8/14/24 10:37, Jiri Pirko wrote:
> Tue, Aug 13, 2024 at 05:17:12PM CEST, pabeni@...hat.com wrote:
>> On 8/1/24 15:42, Jiri Pirko wrote:
>> [...]
>>>> int net_shaper_nl_get_doit(struct sk_buff *skb, struct genl_info *info)
>>>> {
>>>> - return -EOPNOTSUPP;
>>>> + struct net_shaper_info *shaper;
>>>> + struct net_device *dev;
>>>> + struct sk_buff *msg;
>>>> + u32 handle;
>>>> + int ret;
>>>> +
>>>> + ret = fetch_dev(info, &dev);
>>>
>>> This is quite net_device centric. Devlink rate shaper should be
>>> eventually visible throught this api as well, won't they? How do you
>>> imagine that?
>>
>> I'm unsure we are on the same page. Do you foresee this to replace and
>> obsoleted the existing devlink rate API? It was not our so far.
>
> Driver-api-wise, yes. I believe that was the goal, to have drivers to
> implement one rate api.
I initially underlooked at this point, I'm sorry.
Re-reading this I think we are not on the same page.
The net_shaper_ops are per network device operations: they are aimed
(also) at consolidating network device shaping related callbacks, but
they can't operate on non-network device objects (devlink port).
Cheers,
Paolo
Powered by blists - more mailing lists