mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: netdev-bot+sashiko@kernel.org
To: pepe.schlehofer@gmail.com
Cc: netdev@vger.kernel.org, marcin.s.wojtas@gmail.com,
	andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@kernel.org,
	kuba@kernel.org, pabeni@redhat.com,
	maxime.chevallier@bootlin.com, w@1wt.eu,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v2 5/5] net: mvneta: keep the TX rate limits across open and MTU change
Date: Sat, 07 Nov 2026 01:38:56 +0000	[thread overview]
Message-ID: <179401553657.994134.8119365679563489731@kernel.org> (raw)
In-Reply-To: <20261103125021.70845-6-pepe.schlehofer@gmail.com>

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] The commit message of "net: mvneta: keep the TX rate limits
  across open and MTU change" does not say how the bug was discovered,…

--

net: mvneta: keep the TX rate limits across open and MTU change

This commit stores the mqprio bucket refill value for each rate limited
TX queue. It then programs the rate limits again from
mvneta_start_dev(). Without this, mvneta_txq_hw_init() leaves every
limited queue running at 10.23 Mbit/s after the interface is brought up
again or its MTU is changed.

> Tested on a Turris Omnia (Armada 385) with 1 Mbit/s limits on a
> 100 Mbit/s link. After the link was set down and up, or the MTU was
> changed, each busy TX queue carried about 10 Mbit/s. With this patch it
> stays at about 1 Mbit/s.

[Severity: Low]
This isn't a bug, but the commit message may be missing two statements
that the netdev process now asks for in fixes.

The "Bug fixes" section of Documentation/process/maintainer-netdev.rst
says:

    All bug fixes must state how the issue was discovered and validated,
    and how the fix was tested.

and:

    The testing statement should explain whether the fix was tested
    against the reproducer and against kernel selftests.

The paragraph above names the hardware and gives before and after
numbers from the reproducer, so that part is covered.

It doesn't say how the problem was found, though. The document gives
examples such as "observed on a machine in real use" and "discovered by
manual code inspection". There is also no Reported-by or similar trailer
that would imply it.

It also doesn't say whether kernel selftests were run.

Could the commit message get a sentence on how the issue was found, and
another on whether selftests were run? This requirement was tightened
by the baseline commit f56daaadfecae1 ("docs: netdev: try to force
agents to disclose info for fixes").

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261103125021.70845-1-pepe.schlehofer%40gmail.com

  reply	other threads:[~2026-11-07  1:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-03 12:50 [PATCH net v2 0/5] net: mvneta: fix the TX queue arbitration and the mqprio offload Josef Schlehofer
2026-11-03 12:50 ` [PATCH net v2 1/5] net: mvneta: lift the per-queue TX rate limits Josef Schlehofer
2026-11-03 18:56   ` Maxime Chevallier
2026-11-07  1:38   ` netdev-bot+sashiko
2026-11-03 12:50 ` [PATCH net v2 2/5] net: mvneta: fix the removal of the mqprio offload Josef Schlehofer
2026-11-03 19:00   ` Maxime Chevallier
2026-11-07  1:38   ` netdev-bot+sashiko
2026-11-03 12:50 ` [PATCH net v2 3/5] net: mvneta: serve the TX queues in weighted round robin Josef Schlehofer
2026-11-03 12:50 ` [PATCH net v2 4/5] net: mvneta: unwind a failed mqprio setup Josef Schlehofer
2026-11-03 19:01   ` Maxime Chevallier
2026-11-03 12:50 ` [PATCH net v2 5/5] net: mvneta: keep the TX rate limits across open and MTU change Josef Schlehofer
2026-11-07  1:38   ` netdev-bot+sashiko [this message]
2026-11-03 18:56 ` [PATCH net v2 0/5] net: mvneta: fix the TX queue arbitration and the mqprio offload Maxime Chevallier
2026-11-04 11:33   ` Josef Schlehofer

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=179401553657.994134.8119365679563489731@kernel.org \
    --to=netdev-bot+sashiko@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcin.s.wojtas@gmail.com \
    --cc=maxime.chevallier@bootlin.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pepe.schlehofer@gmail.com \
    --cc=w@1wt.eu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®