Re:Re: [PATCH net v4] net: macb: rate limit netdev error info print in the data path
From: taozj888
Date: Wed Oct 14 2026 - 04:51:01 EST
Hi Theo:
Sorry for having missed important things.
I would like to append some explanations here.
Please see my answer inline.
Thanks,
Zijin Tao
At 2026-10-14 01:55:03, "Théo Lebrun" <theo.lebrun@xxxxxxxxxxx> wrote:
>Hello Zijin,
>
> - I'll stop replying inline because you seem to be having issues with
> your mailer. Please fix it to ease the discussion.
>
> See here how your email looks:
> https://lore.kernel.org/netdev/63731290.3f0c.1a1198fe993.Coremail.taozj888@xxxxxxx/
>
> - Your V4 commit message says "Fixes: 89e5785fc8a6" but that is wrong
> with the current patch, it shold use 4df95131ea80. I don't
> understand why you are talking about the changelog at the same time,
> this is unrelated.
>
Yes, I made a mistake in V4 commit message with an oversight, it should use 4df95131ea80, so
I just revised it to 4df95131ea80 in the V5 patch, and I will use it in possible later patches.
> - You skipped over explaining why your dropped the start_xmit diff.
>
>I'll have to stop reviewing if you skip over parts of the messages.
>I gave you a TLDR and you skipped over the first bulletpoint.
>
Sorry, I forgot to make an explanation here, maybe due to an omission.
Now I would like to amend it:
Actually when I started to rate limit the error messages in the data path, I saw
the netdev_err message print in both the gem_rx_refill and at91ether_start_xmit,
and I knew they are also in the data path.
But for the following reasons I just omitted adding rate limits for them:
1. For the netdev_err in the gem_rx_refill, there is a "unlikely(!skb)" to check if
the skb is NULL which is a rare case, so I think it's not so needed to add a
rate limit here;
2. For the netdev_err in the at91ether_start_xmit, I think it belongs to another vendor
which I am not familiar with, and I didn't know how popular it was used, even I was not authorized to
change it with my will also.
If you think it's better or needed to add a rate limit for them, I would like to do it in later possible
patches.
Would you please give your opinion here?
>Thanks,
>
>--
>Théo Lebrun, Bootlin
>Embedded Linux and Kernel engineering
>https://bootlin.com
>
>text:
>Mime-Version: 1.0
>Content-Transfer-Encoding: quoted-printable
>Content-Type: text/plain; charset=UTF-8
>Date: Thu, 08 Oct 2026 14:59:55 +0200
>Message-Id: <DLZH4LPJ36YW.1CP7RL0J77DHN@xxxxxxxxxxx>
>Subject: Re: [PATCH net v4] net: macb: rate limit netdev error info print in
> the data path
>Cc: <stable@xxxxxxxxxxxxxxx>, "Conor Dooley" <conor.dooley@xxxxxxxxxxxxx>,
> "Andrew Lunn" <andrew+netdev@xxxxxxx>, "David S. Miller"
> <davem@xxxxxxxxxxxxx>, "Eric Dumazet" <edumazet@xxxxxxxxxx>, "Jakub
> Kicinski" <kuba@xxxxxxxxxx>, "Paolo Abeni" <pabeni@xxxxxxxxxx>, "Jeff
> Garzik" <jeff@xxxxxxxxxx>, "Haavard Skinnemoen" <hskinnemoen@xxxxxxxxx>,
> "open list:NETWORKING DRIVERS" <netdev@xxxxxxxxxxxxxxx>, "open list"
> <linux-kernel@xxxxxxxxxxxxxxx>
>To: "taozj888" <taozj888@xxxxxxx>
>From: =?utf-8?q?Théo_Lebrun?= <theo.lebrun@xxxxxxxxxxx>
>X-Mailer: aerc 0.22.0-0-gc2f86b7abde3
>References: <20261007053211.572073-1-taozj888@xxxxxxx>
> <DLYI3O7PFN94.V7VH3HSLKEMD@xxxxxxxxxxx>
> <63731290.3f0c.1a1198fe993.Coremail.taozj888@xxxxxxx>
>In-Reply-To: <63731290.3f0c.1a1198fe993.Coremail.taozj888@xxxxxxx>
>X-TUID: tHkCkOndXaQQ
>
>Hello Zijin,
>
> - I'll stop replying inline because you seem to be having issues with
> your mailer. Please fix it to ease the discussion.
>
> See here how your email looks:
> https://lore.kernel.org/netdev/63731290.3f0c.1a1198fe993.Coremail.taozj888@xxxxxxx/
>
> - Your V4 commit message says "Fixes: 89e5785fc8a6" but that is wrong
> with the current patch, it shold use 4df95131ea80. I don't
> understand why you are talking about the changelog at the same time,
> this is unrelated.
>
> - You skipped over explaining why your dropped the start_xmit diff.
>
>I'll have to stop reviewing if you skip over parts of the messages.
>I gave you a TLDR and you skipped over the first bulletpoint.
>
>Thanks,
>
>--
>Théo Lebrun, Bootlin
>Embedded Linux and Kernel engineering
>https://bootlin.com