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

[taozj888]

Hi Nicolai:


Please see my answer inline.


Thank you,
Zijin Tao

At 2026-10-04 22:06:24, "Nicolai Buchwitz" <nb@xxxxxxxxxxx> wrote:
>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")

>


OK, I will use the commit id 4df95131ea80 instead in my next patch. 

>> [...]
>
>>>> 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.
>

>> [...]


Currently I have not direct cases here, but for some tough network environmets,
there may be some error pkts received, especially for our customed HW/SW network requirement
which may trigger this kind of message. 
But limiting the JML receive upper limit from HW is still valuable, perhaps it still need more
tests.


Thanks for your >
>Thanks,

>Nicolai