[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZOcBEt59zHW9qHhT@nanopsycho>
Date: Thu, 24 Aug 2023 09:04:50 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: "Zhang, Xuejun" <xuejun.zhang@...el.com>
Cc: Jakub Kicinski <kuba@...nel.org>, Wenjun Wu <wenjun1.wu@...el.com>,
intel-wired-lan@...ts.osuosl.org, netdev@...r.kernel.org,
madhu.chittim@...el.com, qi.z.zhang@...el.com,
anthony.l.nguyen@...el.com
Subject: Re: [PATCH iwl-next v4 0/5] iavf: Add devlink and devlink rate
support'
Wed, Aug 23, 2023 at 09:13:34PM CEST, xuejun.zhang@...el.com wrote:
>
>On 8/22/2023 8:34 AM, Jiri Pirko wrote:
>> Tue, Aug 22, 2023 at 05:12:55PM CEST,kuba@...nel.org wrote:
>> > On Tue, 22 Aug 2023 08:12:28 +0200 Jiri Pirko wrote:
>> > > NACK! Port function is there to configure the VF/SF from the eswitch
>> > > side. Yet you use it for the configureation of the actual VF, which is
>> > > clear misuse. Please don't
>> > Stating where they are supposed to configure the rate would be helpful.
>> TC?
>
>Our implementation is an extension to this commit 42c2eb6b1f43 ice: Implement
>devlink-rate API).
>
>We are setting the Tx max & share rates of individual queues in a VF using
>the devlink rate API.
>
>Here we are using DEVLINK_PORT_FLAVOUR_VIRTUAL as the attribute for the port
>to distinguish it from being eswitch.
I understand, that is a wrong object. So again, you should use
"function" subobject of devlink port to configure "the other side of the
wire", that means the function related to a eswitch port. Here, you are
doing it for the VF directly, which is wrong. If you need some rate
limiting to be configured on an actual VF, use what you use for any
other nic. Offload TC.
Powered by blists - more mailing lists