[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1aef421ad72317b0adb12fecbd705aa2d2eced75.camel@redhat.com>
Date: Tue, 21 Nov 2023 10:04:50 +0100
From: Paolo Abeni <pabeni@...hat.com>
To: Jiri Pirko <jiri@...nulli.us>, "Zhang, Xuejun" <xuejun.zhang@...el.com>
Cc: netdev@...r.kernel.org, anthony.l.nguyen@...el.com,
intel-wired-lan@...ts.osuosl.org, qi.z.zhang@...el.com, Jakub Kicinski
<kuba@...nel.org>, Wenjun Wu <wenjun1.wu@...el.com>, maxtram95@...il.com,
"Chittim, Madhu" <madhu.chittim@...el.com>, "Samudrala, Sridhar"
<sridhar.samudrala@...el.com>
Subject: Re: [Intel-wired-lan] [PATCH iwl-next v4 0/5] iavf: Add devlink and
devlink rate support'
On Fri, 2023-11-17 at 12:21 +0100, Jiri Pirko wrote:
> Fri, Nov 17, 2023 at 06:52:49AM CET, xuejun.zhang@...el.com wrote:
> > Hello Jiri & Jakub,
> >
> > Thanks for looking into our last patch with devlink API. Really appreciate
> > your candid review.
> >
> > Following your suggestion, we have looked into 3 tc offload options to
> > support queue rate limiting
> >
> > #1 mq + matchall + police
>
> This looks most suitable. Why it would not work?
AFAICS, it should work, but it does not look the most suitable to me:
beyond splitting a "simple" task in separate entities, it poses a
constraint on the classification performed on the egress device.
Suppose the admin wants to limit the egress bandwidth on the given tx
queue _and_ do some application specific packet classification and
actions. That would not be possible right?
Thanks!
Paolo
Powered by blists - more mailing lists