[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20220113110801.7c1a6347@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
Date: Thu, 13 Jan 2022 11:08:01 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Kevin Bracey <kevin@...cey.fi>
Cc: Eric Dumazet <edumazet@...gle.com>,
netdev <netdev@...r.kernel.org>, Jiri Pirko <jiri@...nulli.us>,
Vimalkumar <j.vimal@...il.com>, maximmi@...dia.com
Subject: Re: [PATCH net-next v2] net_sched: restore "mpu xxx" handling
On Wed, 12 Jan 2022 19:31:54 +0200 Kevin Bracey wrote:
> On 12/01/2022 19:08, Eric Dumazet wrote:
> > On Wed, Jan 12, 2022 at 9:02 AM Kevin Bracey <kevin@...cey.fi> wrote:
> >> commit 56b765b79e9a ("htb: improved accuracy at high rates") broke
> >> "overhead X", "linklayer atm" and "mpu X" attributes.
Applied, thanks!
> > Thanks for the nice changelog.
> >
> > I do have a question related to HTB offload.
> >
> > Is this mpu attribute considered there ?
>
> I had not considered that. None of these 3 adjustment parameters are
> passed to its setup - tc_htb_qopt_offload merely contains u64 rate and ceil.
>
> Dealing with that looks like it might be a bit fiddly. htb_change_class
> would need reordering. It appears the software case permits parameter
> changing and it is ordered on that basis, but the offload locks in
> parameters on creation.
>
> But in principle, tc_htb_qopt_offload could contain a pair of
> psched_ratecfg rather than a pair of u64s, and then offload would have
> all the adjustment information.
CC Maxim, offload should at least be rejected if user request
unsupported params.
Powered by blists - more mailing lists