All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <edumazet@google.com>
To: Kevin Bracey <kevin@bracey.fi>
Cc: netdev <netdev@vger.kernel.org>, Jakub Kicinski <kuba@kernel.org>,
	Jiri Pirko <jiri@resnulli.us>, Vimalkumar <j.vimal@gmail.com>
Subject: Re: [PATCH net-next v2] net_sched: restore "mpu xxx" handling
Date: Wed, 12 Jan 2022 09:08:40 -0800	[thread overview]
Message-ID: <CANn89iJiAGD11qe9edmzsf0Sf9Wb7nc6o6zscO=4KOwkRv1gRQ@mail.gmail.com> (raw)
In-Reply-To: <20220112170210.1014351-1-kevin@bracey.fi>

On Wed, Jan 12, 2022 at 9:02 AM Kevin Bracey <kevin@bracey.fi> wrote:
>
> commit 56b765b79e9a ("htb: improved accuracy at high rates") broke
> "overhead X", "linklayer atm" and "mpu X" attributes.
>
> "overhead X" and "linklayer atm" have already been fixed. This restores
> the "mpu X" handling, as might be used by DOCSIS or Ethernet shaping:
>
>     tc class add ... htb rate X overhead 4 mpu 64
>
> The code being fixed is used by htb, tbf and act_police. Cake has its
> own mpu handling. qdisc_calculate_pkt_len still uses the size table
> containing values adjusted for mpu by user space.
>
> iproute2 tc has always passed mpu into the kernel via a tc_ratespec
> structure, but the kernel never directly acted on it, merely stored it
> so that it could be read back by `tc class show`.
>
> Rather, tc would generate length-to-time tables that included the mpu
> (and linklayer) in their construction, and the kernel used those tables.
>
> Since v3.7, the tables were no longer used. Along with "mpu", this also
> broke "overhead" and "linklayer" which were fixed in 01cb71d2d47b
> ("net_sched: restore "overhead xxx" handling", v3.10) and 8a8e3d84b171
> ("net_sched: restore "linklayer atm" handling", v3.11).
>
> "overhead" was fixed by simply restoring use of tc_ratespec::overhead -
> this had originally been used by the kernel but was initially omitted
> from the new non-table-based calculations.
>
> "linklayer" had been handled in the table like "mpu", but the mode was
> not originally passed in tc_ratespec. The new implementation was made to
> handle it by getting new versions of tc to pass the mode in an extended
> tc_ratespec, and for older versions of tc the table contents were analysed
> at load time to deduce linklayer.
>
> As "mpu" has always been given to the kernel in tc_ratespec,
> accompanying the mpu-based table, we can restore system functionality
> with no userspace change by making the kernel act on the tc_ratespec
> value.
>
> Fixes: 56b765b79e9a ("htb: improved accuracy at high rates")
> Signed-off-by: Kevin Bracey <kevin@bracey.fi>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Jiri Pirko <jiri@resnulli.us>
> Cc: Vimalkumar <j.vimal@gmail.com>

Thanks for the nice changelog.

I do have a question related to HTB offload.

Is this mpu attribute considered there ?

Thanks.

  reply	other threads:[~2022-01-12 17:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-12 17:02 [PATCH net-next v2] net_sched: restore "mpu xxx" handling Kevin Bracey
2022-01-12 17:08 ` Eric Dumazet [this message]
2022-01-12 17:31   ` Kevin Bracey
2022-01-13 19:08     ` Jakub Kicinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CANn89iJiAGD11qe9edmzsf0Sf9Wb7nc6o6zscO=4KOwkRv1gRQ@mail.gmail.com' \
    --to=edumazet@google.com \
    --cc=j.vimal@gmail.com \
    --cc=jiri@resnulli.us \
    --cc=kevin@bracey.fi \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.