net: ip: Fix the warning in the data path

[krish2718]

Instead of warning for every-packet, warn only once and let user debug the underlying cause.

Fix #49845.

Depends on #93536

[JordanYates]

Put more succinctly, shouldn't the problem at the driver layer that causes the failures and the application layer that continuously keeps trying to send be fixed, rather than making the log output less useful?

[krish2718]

Put more succinctly, shouldn't the problem at the driver layer that causes the failures and the application layer that continuously keeps trying to send be fixed, rather than making the log output less useful?

Absolutely, the entire pipeline as you say is responsible as you say (and IIRC we had the same discussion about lacking stop/start data path in Zephyr), but the specific problem this PR addresses is that, bombarding with prints (Zperf pumping at 50M) doesn't help, esp. you loose any control over the shell, cannot even type in wifi statistics or net stats to debug.

[JordanYates]

Absolutely, the entire pipeline as you say is responsible as you say (and IIRC we had the same discussion about lacking stop/start data path in Zephyr), but the specific problem this PR addresses is that, bombarding with prints (Zperf pumping at 50M) doesn't help, esp. you loose any control over the shell, cannot even type in wifi statistics or net stats to debug.

Can we do something like only printing a warning if at least 1 second has passed since the last warning?

[krish2718]

Absolutely, the entire pipeline as you say is responsible as you say (and IIRC we had the same discussion about lacking stop/start data path in Zephyr), but the specific problem this PR addresses is that, bombarding with prints (Zperf pumping at 50M) doesn't help, esp. you loose any control over the shell, cannot even type in wifi statistics or net stats to debug.

Can we do something like only printing a warning if at least 1 second has passed since the last warning?

Yeah, the rate limiting discussion is in the above comment.

[krish2718]

This is defintiely much better than existing behaviour.

[pdgendt]

The rate limited printing looks very interesting, but should get its own PR IMO.

[krish2718]

The rate limited printing looks very interesting, but should get its own PR IMO.

I thought the same, but this has the context behind need for ratelimited, I can split this PR into two.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud