[PATCH net v2] net: macb: rate limit netdev error info print in the data path

[PATCH net v2] net: macb: rate limit netdev error info print in the data path

[taozj888]

From: taozijin <taozj888@163.com>

Now the MACB ethernet driver print the netdev error information
directly by netdev_err(), which would lead to a large number of
error information print if there was a significant number of
error or just jumbo packets exceeding the MTU received when booting.
For example, it would print a large number of:

macb PHYT0036:00 eth0: not whole frame pointed by descriptor
macb PHYT0036:00 eth0: not whole frame pointed by descriptor
...

in gem_rx() by received a large number of packets without
RX_EOF flag set, especially with unknown packet
type that would penetrate the hardware offload for the IP packets.

The unlimited prints here would greatly bother and delay
the system booting process unless the source stop sending
packets since they occupy the console output bandwidth and
other processes have to wait for the completion of printing those
messages.

So rate limit the netdev error information print in the receive
and transmit data path.

Fixes: 89e5785fc8a6 ("[PATCH] Atmel MACB ethernet driver")
Cc: stable@vger.kernel.org

Signed-off-by: Zijin Tao <taozj888@163.com>
---
 drivers/net/ethernet/cadence/macb_main.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 8e5c034dc3a4..ca60960bec36 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -1617,16 +1617,16 @@ static int gem_rx(struct macb_queue *queue, struct napi_struct *napi,
 		count++;
 
 		if (!(ctrl & MACB_BIT(RX_SOF) && ctrl & MACB_BIT(RX_EOF))) {
-			netdev_err(bp->netdev,
-				   "not whole frame pointed by descriptor\n");
+			if (net_ratelimit())
+				netdev_err(bp->netdev, "not whole frame pointed by descriptor\n");
 			bp->netdev->stats.rx_dropped++;
 			queue->stats.rx_dropped++;
 			break;
 		}
 		skb = queue->rx_skbuff[entry];
 		if (unlikely(!skb)) {
-			netdev_err(bp->netdev,
-				   "inconsistent Rx descriptor chain\n");
+			if (net_ratelimit())
+				netdev_err(bp->netdev, "inconsistent Rx descriptor chain\n");
 			bp->netdev->stats.rx_dropped++;
 			queue->stats.rx_dropped++;
 			break;
@@ -1829,7 +1829,8 @@ static int macb_rx(struct macb_queue *queue, struct napi_struct *napi,
 		unsigned long flags;
 		u32 ctrl;
 
-		netdev_err(bp->netdev, "RX queue corruption: reset it\n");
+		if (net_ratelimit())
+			netdev_err(bp->netdev, "RX queue corruption: reset it\n");
 
 		spin_lock_irqsave(&bp->lock, flags);
 
@@ -2102,7 +2103,8 @@ static int macb_interrupt_misc(struct macb_queue *queue, u32 status)
 
 	if (status & MACB_BIT(HRESP)) {
 		queue_work(system_bh_wq, &bp->hresp_err_bh_work);
-		netdev_err(netdev, "DMA bus error: HRESP not OK\n");
+		if (net_ratelimit())
+			netdev_err(netdev, "DMA bus error: HRESP not OK\n");
 		macb_queue_isr_clear(bp, queue, MACB_BIT(HRESP));
 	}
 
-- 
2.34.1

Re: [PATCH net v2] net: macb: rate limit netdev error info print in the data path

[Nicolai Buchwitz]

Hi Zijin

On 30.9.2026 13:35, taozj888@163.com wrote:
> From: taozijin <taozj888@163.com>
> 
> Now the MACB ethernet driver print the netdev error information
> directly by netdev_err(), which would lead to a large number of
> error information print if there was a significant number of
> error or just jumbo packets exceeding the MTU received when booting.
> For example, it would print a large number of:
> 
> macb PHYT0036:00 eth0: not whole frame pointed by descriptor
> macb PHYT0036:00 eth0: not whole frame pointed by descriptor
> ...

Out of interest: Is this a Phytium vendor kernel?

> 
> in gem_rx() by received a large number of packets without
> RX_EOF flag set, especially with unknown packet
> type that would penetrate the hardware offload for the IP packets.
> 
> The unlimited prints here would greatly bother and delay
> the system booting process unless the source stop sending
> packets since they occupy the console output bandwidth and
> other processes have to wait for the completion of printing those
> messages.
> 
> So rate limit the netdev error information print in the receive
> and transmit data path.
> 
> Fixes: 89e5785fc8a6 ("[PATCH] Atmel MACB ethernet driver")

IMHO the correct tag is 4df95131ea80 ("net/macb: change RX path for 
GEM")?
At least the gem_rx() messages were introduced here.

> Cc: stable@vger.kernel.org
> 

Drop the blank line as otherwise tooling might get confused and doesn't
get all tags correctly.

> Signed-off-by: Zijin Tao <taozj888@163.com>
> ---
>  drivers/net/ethernet/cadence/macb_main.c | 14 ++++++++------
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/ethernet/cadence/macb_main.c 
> b/drivers/net/ethernet/cadence/macb_main.c
> index 8e5c034dc3a4..ca60960bec36 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c
> @@ -1617,16 +1617,16 @@ static int gem_rx(struct macb_queue *queue, 
> struct napi_struct *napi,
>  		count++;
> 
>  		if (!(ctrl & MACB_BIT(RX_SOF) && ctrl & MACB_BIT(RX_EOF))) {
> -			netdev_err(bp->netdev,
> -				   "not whole frame pointed by descriptor\n");
> +			if (net_ratelimit())
> +				netdev_err(bp->netdev, "not whole frame pointed by descriptor\n");

This will just hide the error message, but the split/drop is still 
present.
How about limiting JML in macb_init_hw() properly?

         if ((bp->caps & MACB_CAPS_JUMBO) && bp->jumbo_max_len) {
                 u32 jml = bp->rx_buffer_size - NET_IP_ALIGN + 
ETH_FCS_LEN;
                 gem_writel(bp, JML, min(jml, bp->jumbo_max_len));
         }

The code above is untested, so probably needs further tweaking. An 
alternative could
be to handle the split frames in gem_rx() correctly.

> [...]

Thanks,
Nicolai

Re: [PATCH net v2] net: macb: rate limit netdev error info print in the data path

[Théo Lebrun]

Hello Nicolai,

On Fri Oct 2, 2026 at 12:10 PM CEST, Nicolai Buchwitz wrote:
> On 30.9.2026 13:35, taozj888@163.com wrote:
>> From: taozijin <taozj888@163.com>
>> 
>> Now the MACB ethernet driver print the netdev error information
>> directly by netdev_err(), which would lead to a large number of
>> error information print if there was a significant number of
>> error or just jumbo packets exceeding the MTU received when booting.
>> For example, it would print a large number of:
>> 
>> macb PHYT0036:00 eth0: not whole frame pointed by descriptor
>> macb PHYT0036:00 eth0: not whole frame pointed by descriptor
>> ...
>
> Out of interest: Is this a Phytium vendor kernel?

I looked in the past so I'll answer: yes!

Internet search gives one worthy result: a 2025 series to DPDK adding
MACB support. Some extracts about the exact string match and also how
they support ACPI or OF and no other platform apparently.

#define OF_PHYTIUM_GEM1P0_MAC	"cdns,phytium-gem-1.0"	/* Phytium 1.0 MAC */
#define OF_PHYTIUM_GEM2P0_MAC	"cdns,phytium-gem-2.0"	/* Phytium 2.0 MAC */
#define ACPI_PHYTIUM_GEM1P0_MAC	"PHYT0036"	/* Phytium 1.0  MAC */

static int macb_get_dev_type(struct rte_eth_dev *dev)
{
	// ...

	if (!strcmp(dev_type, OF_PHYTIUM_GEM1P0_MAC) ||
	    !strcmp(dev_type, ACPI_PHYTIUM_GEM1P0_MAC)) {
		priv->dev_type = DEV_TYPE_PHYTIUM_GEM1P0_MAC;
	} else if (!strcmp(dev_type, OF_PHYTIUM_GEM2P0_MAC)) {
		priv->dev_type = DEV_TYPE_PHYTIUM_GEM2P0_MAC;
	} else {
		MACB_LOG(ERR, "Unsupported device type: %s.", dev_type);
		ret = -EINVAL;
	}

	// ...
}

@Zijin: do you have any other Linux MACB patches for it to work?

>> in gem_rx() by received a large number of packets without
>> RX_EOF flag set, especially with unknown packet
>> type that would penetrate the hardware offload for the IP packets.
>> 
>> The unlimited prints here would greatly bother and delay
>> the system booting process unless the source stop sending
>> packets since they occupy the console output bandwidth and
>> other processes have to wait for the completion of printing those
>> messages.
>> 
>> So rate limit the netdev error information print in the receive
>> and transmit data path.
>> 
>> Fixes: 89e5785fc8a6 ("[PATCH] Atmel MACB ethernet driver")
>
> IMHO the correct tag is 4df95131ea80 ("net/macb: change RX path for 
> GEM")?
> At least the gem_rx() messages were introduced here.

The patch used to touch macb_start_xmit(), which explains why I told
Zijin to target the initial commit on previous revision.

@Zijin: where is the V2 changelog? Each new revision must list (below
the fold line for single patches) their exhaustive list of changes
compared to the previous revision.

https://www.kernel.org/doc/html/latest/process/submitting-patches.html#respond-to-review-comments
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#the-canonical-patch-format

>> Cc: stable@vger.kernel.org
>> 
>
> Drop the blank line as otherwise tooling might get confused and doesn't
> get all tags correctly.
>
>> Signed-off-by: Zijin Tao <taozj888@163.com>
>> ---
>>  drivers/net/ethernet/cadence/macb_main.c | 14 ++++++++------
>>  1 file changed, 8 insertions(+), 6 deletions(-)
>> 
>> diff --git a/drivers/net/ethernet/cadence/macb_main.c 
>> b/drivers/net/ethernet/cadence/macb_main.c
>> index 8e5c034dc3a4..ca60960bec36 100644
>> --- a/drivers/net/ethernet/cadence/macb_main.c
>> +++ b/drivers/net/ethernet/cadence/macb_main.c
>> @@ -1617,16 +1617,16 @@ static int gem_rx(struct macb_queue *queue, 
>> struct napi_struct *napi,
>>  		count++;
>> 
>>  		if (!(ctrl & MACB_BIT(RX_SOF) && ctrl & MACB_BIT(RX_EOF))) {
>> -			netdev_err(bp->netdev,
>> -				   "not whole frame pointed by descriptor\n");
>> +			if (net_ratelimit())
>> +				netdev_err(bp->netdev, "not whole frame pointed by descriptor\n");
>
> This will just hide the error message, but the split/drop is still 
> present.
> How about limiting JML in macb_init_hw() properly?
>
>          if ((bp->caps & MACB_CAPS_JUMBO) && bp->jumbo_max_len) {
>                  u32 jml = bp->rx_buffer_size - NET_IP_ALIGN + 
> ETH_FCS_LEN;
>                  gem_writel(bp, JML, min(jml, bp->jumbo_max_len));
>          }
>
> The code above is untested, so probably needs further tweaking. An 
> alternative could
> be to handle the split frames in gem_rx() correctly.

I agree with you but to clarify for Zijin: if you do this then it should
be a separate patch as changes are pretty unrelated.

Thanks,

--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH net v2] net: macb: rate limit netdev error info print in the data path

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 2 potential
issue(s) to consider.

Critical: 0 · High: 1 · Medium: 0 · Low: 1

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [High] The fix does not cover what its commit message claims.
- [Low] The author identity "taozijin <taozj888@163.com>" does not match
  the Signed-off-by trailer "Zijin Tao <taozj888@163.com>".

--

net: macb: rate limit netdev error info print in the data path

This patch wraps four netdev_err() calls in the macb driver with
net_ratelimit(). Two are in gem_rx(), one is the RX queue corruption
message in macb_rx(), and one is the HRESP DMA bus error in
macb_interrupt_misc(). The goal is to stop console floods at boot when
many bad or oversized frames arrive.

> Fixes: 89e5785fc8a6 ("[PATCH] Atmel MACB ethernet driver")
> Cc: stable@vger.kernel.org
>
> Signed-off-by: Zijin Tao <taozj888@163.com>

[Severity: Low]
This isn't a bug, but the name in the Author line does not match the
name in the Signed-off-by. The email address is the same:

  Author: taozijin <taozj888@163.com>
  Signed-off-by: Zijin Tao <taozj888@163.com>

checkpatch.pl reports this as FROM_SIGN_OFF_MISMATCH.

Also, a blank line separates the Fixes: and Cc: tags from the
Signed-off-by, so they don't form a single trailer block.

> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
> index 8e5c034dc3a48..ca60960bec362 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c

[ ... ]

> @@ -2102,7 +2103,8 @@ static int macb_interrupt_misc(struct macb_queue *queue, u32 status)
>  
>  	if (status & MACB_BIT(HRESP)) {
>  		queue_work(system_bh_wq, &bp->hresp_err_bh_work);
> -		netdev_err(netdev, "DMA bus error: HRESP not OK\n");
> +		if (net_ratelimit())
> +			netdev_err(netdev, "DMA bus error: HRESP not OK\n");
>  		macb_queue_isr_clear(bp, queue, MACB_BIT(HRESP));
>  	}

[Severity: High]
The commit message says:

  So rate limit the netdev error information print in the receive
  and transmit data path.

Does the patch match that description? The only non-RX print it
converts is this HRESP one in macb_interrupt_misc(). That is a DMA bus
error interrupt, not the transmit data path. No TX data path print
seems to be rate limited.

Several prints of the same kind in macb_main.c look like they are still
unlimited. at91ether_interrupt() runs in hard IRQ context and still
does:

	if (intstatus & MACB_BIT(ISR_ROVR))
		netdev_err(netdev, "ROVR error\n");

at91ether_open() enables ISR_ROVR. A line rate flood from a link peer
would cause exactly this RX overrun, which is the scenario in the commit
message. macb_interrupt_misc() handles the same bit by only incrementing
hw_stats rx_overruns.

gem_rx_refill() runs at the end of every gem_rx() poll and still has:

	if (unlikely(!skb)) {
		netdev_err(bp->netdev,
			   "Unable to allocate sk_buff\n");
		break;
	}

Under memory pressure, would this log again on every poll, right next
to the gem_rx() prints that are now rate limited?

On the TX side, these still print without a limit:

  macb_tx_map():
	netdev_err(bp->netdev, "TX DMA map failed\n");

  macb_start_xmit():
	netdev_err(bp->netdev, "Error - LSO headers fragmented!!!\n");
	/* if this is required, would need to copy to single buffer */
	return NETDEV_TX_BUSY;

  at91ether_start_xmit():
	netdev_err(netdev, "%s: DMA mapping error\n", __func__);
	...
	netdev_err(netdev, "%s called, but device is busy!\n",
		   __func__);
	return NETDEV_TX_BUSY;

  macb_tx_error_task():
	netdev_err(bp->netdev,
		   "BUG: TX buffers exhausted mid-frame\n");

The comment in macb_tx_error_task() says that last print is meant to be
loud, so it may be fine to leave as is.

For the two paths that return NETDEV_TX_BUSY, won't the qdisc requeue
the same skb and print the message again on every retry?

This is tagged for stable. Should the remaining RX, IRQ and TX data path
sites be converted too? Or should the commit message only describe the
RX and HRESP prints this patch changes?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260930113520.392025-1-taozj888%40163.com

Re:Re: [PATCH net v2] net: macb: rate limit netdev error info print in the data path

[taozj888]

Hello Theo, Nicolai:

Please see answer inline.

Thanks,

Zijin Tao




At 2026-10-02 20:08:03, "Théo Lebrun" <theo.lebrun@bootlin.com> wrote:
>Hello Nicolai,
>
>On Fri Oct 2, 2026 at 12:10 PM CEST, Nicolai Buchwitz wrote:
>> On 30.9.2026 13:35, taozj888@163.com wrote:
>>> From: taozijin <taozj888@163.com>
>>> 
>>> Now the MACB ethernet driver print the netdev error information
>>> directly by netdev_err(), which would lead to a large number of
>>> error information print if there was a significant number of
>>> error or just jumbo packets exceeding the MTU received when booting.
>>> For example, it would print a large number of:
>>> 
>>> macb PHYT0036:00 eth0: not whole frame pointed by descriptor
>>> macb PHYT0036:00 eth0: not whole frame pointed by descriptor
>>> ...
>>
>> Out of interest: Is this a Phytium vendor kernel?
>
>I looked in the past so I'll answer: yes!
>
>Internet search gives one worthy result: a 2025 series to DPDK adding
>MACB support. Some extracts about the exact string match and also how
>they support ACPI or OF and no other platform apparently.
>
>#define OF_PHYTIUM_GEM1P0_MAC	"cdns,phytium-gem-1.0"	/* Phytium 1.0 MAC */
>#define OF_PHYTIUM_GEM2P0_MAC	"cdns,phytium-gem-2.0"	/* Phytium 2.0 MAC */
>#define ACPI_PHYTIUM_GEM1P0_MAC	"PHYT0036"	/* Phytium 1.0  MAC */
>
>static int macb_get_dev_type(struct rte_eth_dev *dev)
>{
>	// ...
>
>	if (!strcmp(dev_type, OF_PHYTIUM_GEM1P0_MAC) ||
>	    !strcmp(dev_type, ACPI_PHYTIUM_GEM1P0_MAC)) {
>		priv->dev_type = DEV_TYPE_PHYTIUM_GEM1P0_MAC;
>	} else if (!strcmp(dev_type, OF_PHYTIUM_GEM2P0_MAC)) {
>		priv->dev_type = DEV_TYPE_PHYTIUM_GEM2P0_MAC;
>	} else {
>		MACB_LOG(ERR, "Unsupported device type: %s.", dev_type);
>		ret = -EINVAL;
>	}
>
>	// ...
>}
>
>@Zijin: do you have any other Linux MACB patches for it to work?

No, I have no other patches for Linux MACB except the current one.


>
>>> in gem_rx() by received a large number of packets without
>>> RX_EOF flag set, especially with unknown packet
>>> type that would penetrate the hardware offload for the IP packets.
>>> 
>>> The unlimited prints here would greatly bother and delay
>>> the system booting process unless the source stop sending
>>> packets since they occupy the console output bandwidth and
>>> other processes have to wait for the completion of printing those
>>> messages.
>>> 
>>> So rate limit the netdev error information print in the receive
>>> and transmit data path.
>>> 
>>> Fixes: 89e5785fc8a6 ("[PATCH] Atmel MACB ethernet driver")
>>
>> IMHO the correct tag is 4df95131ea80 ("net/macb: change RX path for 
>> GEM")?
>> At least the gem_rx() messages were introduced here.
>
>The patch used to touch macb_start_xmit(), which explains why I told
>Zijin to target the initial commit on previous revision.
>
OK, I will still use the initial commit indicated by Theo.

>@Zijin: where is the V2 changelog? Each new revision must list (below
>the fold line for single patches) their exhaustive list of changes
>compared to the previous revision.

Sorry for missing the V2 changelog. I will add it in the V3 patch.

>
>https://www.kernel.org/doc/html/latest/process/submitting-patches.html#respond-to-review-comments
>https://www.kernel.org/doc/html/latest/process/submitting-patches.html#the-canonical-patch-format
>
>>> Cc: stable@vger.kernel.org
>>> 
>>
>> Drop the blank line as otherwise tooling might get confused and doesn't
>> get all tags correctly.

OK, I will take care of it in the V3 patch.

>>
>>> Signed-off-by: Zijin Tao <taozj888@163.com>
>>> ---
>>>  drivers/net/ethernet/cadence/macb_main.c | 14 ++++++++------
>>>  1 file changed, 8 insertions(+), 6 deletions(-)
>>> 
>>> diff --git a/drivers/net/ethernet/cadence/macb_main.c 
>>> b/drivers/net/ethernet/cadence/macb_main.c
>>> index 8e5c034dc3a4..ca60960bec36 100644
>>> --- a/drivers/net/ethernet/cadence/macb_main.c
>>> +++ b/drivers/net/ethernet/cadence/macb_main.c
>>> @@ -1617,16 +1617,16 @@ static int gem_rx(struct macb_queue *queue, 
>>> struct napi_struct *napi,
>>>  		count++;
>>> 
>>>  		if (!(ctrl & MACB_BIT(RX_SOF) && ctrl & MACB_BIT(RX_EOF))) {
>>> -			netdev_err(bp->netdev,
>>> -				   "not whole frame pointed by descriptor\n");
>>> +			if (net_ratelimit())
>>> +				netdev_err(bp->netdev, "not whole frame pointed by descriptor\n");
>>
>> This will just hide the error message, but the split/drop is still 
>> present.
>> How about limiting JML in macb_init_hw() properly?
>>
>>          if ((bp->caps & MACB_CAPS_JUMBO) && bp->jumbo_max_len) {
>>                  u32 jml = bp->rx_buffer_size - NET_IP_ALIGN + 
>> ETH_FCS_LEN;
>>                  gem_writel(bp, JML, min(jml, bp->jumbo_max_len));
>>          }
>>
>> The code above is untested, so probably needs further tweaking. An 
>> alternative could
>> be to handle the split frames in gem_rx() correctly.
>
>I agree with you but to clarify for Zijin: if you do this then it should
>be a separate patch as changes are pretty unrelated.

Yes, with your experience in this area, maybe a separate patch for it is preferred.
I think the error reported is not just related the Jumbo frame, but the jumbo frame
would trigger the error. So rate limit printing this kind of msg is needed but not
totally hide those msgs.  


>
>Thanks,
>
>--
>Théo Lebrun, Bootlin
>Embedded Linux and Kernel engineering
>https://bootlin.com

Re: [PATCH net v2] net: macb: rate limit netdev error info print in the data path

[Nicolai Buchwitz]

Hi

On 4.10.2026 15:40, taozj888 wrote:
> Hello Theo, Nicolai:
> 
> Please see answer inline.

> [...]

>>>> Fixes: 89e5785fc8a6 ("[PATCH] Atmel MACB ethernet driver")
>>> 
>>> IMHO the correct tag is 4df95131ea80 ("net/macb: change RX path for
>>> GEM")?
>>> At least the gem_rx() messages were introduced here.
>> 
>> The patch used to touch macb_start_xmit(), which explains why I told
>> Zijin to target the initial commit on previous revision.
>> 
> OK, I will still use the initial commit indicated by Theo.

Please re-read Théo's reply: he only suggested the initial
because v1 also touched macb_start_xmit(). v2 doesn't anymore,
89e5785fc8a6 is no longer the right target. Please use:

Fixes: 4df95131ea80 ("net/macb: change RX path for GEM")

> [...]

>>> This will just hide the error message, but the split/drop is still
>>> present.
>>> How about limiting JML in macb_init_hw() properly?
>>> 
>>>          if ((bp->caps & MACB_CAPS_JUMBO) && bp->jumbo_max_len) {
>>>                  u32 jml = bp->rx_buffer_size - NET_IP_ALIGN +
>>> ETH_FCS_LEN;
>>>                  gem_writel(bp, JML, min(jml, bp->jumbo_max_len));
>>>          }
>>> 
>>> The code above is untested, so probably needs further tweaking. An
>>> alternative could
>>> be to handle the split frames in gem_rx() correctly.
>> 
>> I agree with you but to clarify for Zijin: if you do this then it 
>> should
>> be a separate patch as changes are pretty unrelated.
> 
> Yes, with your experience in this area, maybe a separate patch for it 
> is preferred.
> I think the error reported is not just related the Jumbo frame, but the 
> jumbo frame
> would trigger the error. So rate limit printing this kind of msg is 
> needed but not
> totally hide those msgs.

Which other cases do you have in mind?

Rate limiting the message in this patch is fine with me. I can look
into the JML patch separately, or you can give it a try.

> [...]

Thanks,
Nicolai