Hi,
I noticed today with 6.5-rc4 and also on 6.1.42 that I'm getting an
error from an r8152 based dongle (Framework ethernet expansion card).
netif_napi_add_weight() called with weight 256
It seems that this message is likely introduced by
8ded532cd1cbe ("r8152: switch to netif_napi_add_weight()")
which if the card has support_2500full set will program the value to 256:
netif_napi_add_weight(netdev, &tp->napi, r8152_poll,
tp->support_2500full ? 256 : 64);
It's err level from
82dc3c63c692b ("net: introduce NAPI_POLL_WEIGHT")
Why is this considered an error but the driver uses the bigger value?
Should it be downgraded to a warning?
Thanks,
On Mon, 31 Jul 2023 11:02:40 -0500 Limonciello, Mario wrote:
> Hi,
>
> I noticed today with 6.5-rc4 and also on 6.1.42 that I'm getting an
> error from an r8152 based dongle (Framework ethernet expansion card).
>
> netif_napi_add_weight() called with weight 256
>
> It seems that this message is likely introduced by
> 8ded532cd1cbe ("r8152: switch to netif_napi_add_weight()")
>
> which if the card has support_2500full set will program the value to 256:
>
> netif_napi_add_weight(netdev, &tp->napi, r8152_poll,
> tp->support_2500full ? 256 : 64);
>
> It's err level from
> 82dc3c63c692b ("net: introduce NAPI_POLL_WEIGHT")
>
> Why is this considered an error but the driver uses the bigger value?
> Should it be downgraded to a warning?
Could you double check that the warning wasn't there before? The code
added by commit 195aae321c82 ("r8152: support new chips") in 5.13 looks
very much equivalent.
The custom weight is probably due to a misunderstanding. We have 200G
adapters using the standard weight of 64, IDK why 2.5G adapter would
need anything special.
On 7/31/2023 1:13 PM, Jakub Kicinski wrote:
> On Mon, 31 Jul 2023 11:02:40 -0500 Limonciello, Mario wrote:
>> Hi,
>>
>> I noticed today with 6.5-rc4 and also on 6.1.42 that I'm getting an
>> error from an r8152 based dongle (Framework ethernet expansion card).
>>
>> netif_napi_add_weight() called with weight 256
>>
>> It seems that this message is likely introduced by
>> 8ded532cd1cbe ("r8152: switch to netif_napi_add_weight()")
>>
>> which if the card has support_2500full set will program the value to 256:
>>
>> netif_napi_add_weight(netdev, &tp->napi, r8152_poll,
>> tp->support_2500full ? 256 : 64);
>>
>> It's err level from
>> 82dc3c63c692b ("net: introduce NAPI_POLL_WEIGHT")
>>
>> Why is this considered an error but the driver uses the bigger value?
>> Should it be downgraded to a warning?
>
> Could you double check that the warning wasn't there before? The code
> added by commit 195aae321c82 ("r8152: support new chips") in 5.13 looks
> very much equivalent.
Yeah; looking through the history I agree it was probably was there from
the beginning of being introduced.
6.1 is the earliest kernel that is usable with this laptop (for other
reasons).
> The custom weight is probably due to a misunderstanding. We have 200G
> adapters using the standard weight of 64, IDK why 2.5G adapter would
> need anything special.
Perhaps Hayes Wang can comment on this (as the author of 195aae321c82).
On Mon, 31 Jul 2023 13:23:47 -0500
"Limonciello, Mario" <[email protected]> wrote:
> On 7/31/2023 1:13 PM, Jakub Kicinski wrote:
> > On Mon, 31 Jul 2023 11:02:40 -0500 Limonciello, Mario wrote:
> >> Hi,
> >>
> >> I noticed today with 6.5-rc4 and also on 6.1.42 that I'm getting an
> >> error from an r8152 based dongle (Framework ethernet expansion card).
> >>
> >> netif_napi_add_weight() called with weight 256
> >>
> >> It seems that this message is likely introduced by
> >> 8ded532cd1cbe ("r8152: switch to netif_napi_add_weight()")
> >>
> >> which if the card has support_2500full set will program the value to 256:
> >>
> >> netif_napi_add_weight(netdev, &tp->napi, r8152_poll,
> >> tp->support_2500full ? 256 : 64);
> >>
> >> It's err level from
> >> 82dc3c63c692b ("net: introduce NAPI_POLL_WEIGHT")
> >>
> >> Why is this considered an error but the driver uses the bigger value?
> >> Should it be downgraded to a warning?
> >
> > Could you double check that the warning wasn't there before? The code
> > added by commit 195aae321c82 ("r8152: support new chips") in 5.13 looks
> > very much equivalent.
>
> Yeah; looking through the history I agree it was probably was there from
> the beginning of being introduced.
>
> 6.1 is the earliest kernel that is usable with this laptop (for other
> reasons).
>
> > The custom weight is probably due to a misunderstanding. We have 200G
> > adapters using the standard weight of 64, IDK why 2.5G adapter would
> > need anything special.
>
> Perhaps Hayes Wang can comment on this (as the author of 195aae321c82).
>
Large NAPI weights mean that one busy device (DOS attack) can starve the
system. Really doubt that > 64 makes any visible difference in throughput.
Limonciello, Mario <[email protected]>
> Sent: Tuesday, August 1, 2023 2:24 AM
[...]
>
> > The custom weight is probably due to a misunderstanding. We have 200G
> > adapters using the standard weight of 64, IDK why 2.5G adapter would
> > need anything special.
>
> Perhaps Hayes Wang can comment on this (as the author of 195aae321c82).
I test our devices on an Embedded system.
We find the throughput is low.
And it is caused by the weight.
Our NAPI function often uses the whole budget.
Finally, we increase the weight, and the throughput is good.
Best Regards,
Hayes
On Mon, 7 Aug 2023 09:57:15 +0000 Hayes Wang wrote:
> > Perhaps Hayes Wang can comment on this (as the author of 195aae321c82).
>
> I test our devices on an Embedded system.
> We find the throughput is low.
> And it is caused by the weight.
> Our NAPI function often uses the whole budget.
> Finally, we increase the weight, and the throughput is good.
Could it possibly be related to handling of aggregation?
Problem must lay somewhere in USB specifics, since as I said
there are 100Gbps devices running fine with budget of 64.
Jakub Kicinski <[email protected]>
> Sent: Tuesday, August 8, 2023 12:37 AM
[...]
> > I test our devices on an Embedded system.
> > We find the throughput is low.
> > And it is caused by the weight.
> > Our NAPI function often uses the whole budget.
> > Finally, we increase the weight, and the throughput is good.
>
> Could it possibly be related to handling of aggregation?
> Problem must lay somewhere in USB specifics, since as I said
> there are 100Gbps devices running fine with budget of 64.
I think it depends on the platform.
Most of the platforms don't have the same situation.
Besides, I think the platform with 100Gbps device may
have faster CPU than that one which I test.
What would happen, if I set the weight to 256 on the platform
which runs well for the weight of 64?
Doesn't it only influence the slow platform?
Best Regards,
Hayes
On Wed, 9 Aug 2023 13:11:57 +0000 Hayes Wang wrote:
> I think it depends on the platform.
> Most of the platforms don't have the same situation.
> Besides, I think the platform with 100Gbps device may
> have faster CPU than that one which I test.
>
> What would happen, if I set the weight to 256 on the platform
> which runs well for the weight of 64?
> Doesn't it only influence the slow platform?
High weight will cause higher latency for other softirq and RT
processing, it's not a good idea. Even with weight/budget of 64
if there's no higher prio work to do the driver will be polled
again immediately if it consumed the budget and has more packets.
Do you have some actual data on how the device performs with budget
of 64 and 256? And maybe perf traces to show where the difference goes?
Jakub Kicinski <[email protected]>
> Sent: Thursday, August 10, 2023 2:38 AM
[...]
> High weight will cause higher latency for other softirq and RT
> processing, it's not a good idea. Even with weight/budget of 64
> if there's no higher prio work to do the driver will be polled
> again immediately if it consumed the budget and has more packets.
I mean that only the slow platform uses more than 64 budget,
even I set the weight to 256.
That is, for the fast platform, the actual used budget is always less than 64,
even the weight is 256.
> Do you have some actual data on how the device performs with budget
> of 64 and 256? And maybe perf traces to show where the difference goes?
I tested that slow embedded platform many years ago, so I
don't remember the actual data.
I think the difference is more than 400Mbps.
Best Regards,
Hayes