samples: net: echo-client: Increase buf count for frdm-k64f

[jukkar]

Increasing the network buffer count for frdm-k64f so that the
device will not run out of memory so easily.

Fixes #7678

Signed-off-by: Jukka Rissanen jukka.rissanen@linux.intel.com

[codecov-io]

Codecov Report

Merging #7775 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #7775   +/-   ##
=======================================
  Coverage   55.01%   55.01%           
=======================================
  Files         483      483           
  Lines       53946    53946           
  Branches    10493    10493           
=======================================
  Hits        29678    29678           
  Misses      19982    19982           
  Partials     4286     4286

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fcc56e3...a7e43e4. Read the comment docs.

[pfalcon]

I'd like to challenge this with #7831 . Apparently, it's not a good way when some developers increase buffers, and other decrease. @jukkar, I encourage you to not workaround the issues by throwing more memory to the fire. That's masking the issues instead of resolving them, and even that starts to fail, as my PR shows.

[pfalcon]

Actually, it seems that with #7678, #7571, #7818 people finally start to put Zephyr's IP stack to some use and spot all the issues with it. As someone experiencing these issues for 2nd year, let me make a case here and give -1, encouraging instead proper analysis and debugging of the underlying issue(s).

(Yeah, I'm just afraid that @nashif will merge this without looking, and we'll miss a chance to draw the core team to these issues for few more months.)

[pfl]

Actually, it seems that with #7678, #7571, #7818 people finally start to put Zephyr's IP stack to some use and spot all the issues with it. As someone experiencing these issues for 2nd year, let me make a case here and give -1, encouraging instead proper analysis and debugging of the underlying issue(s).

(Yeah, I'm just afraid that @nashif will merge this without looking, and we'll miss a chance to draw the core team to these issues for few more months.)

Do you have an analysis on what issues enabling more buffers are hiding? Can you suggest a fix?

[jukkar]

I could not reproduce the issue described in #7678 but as the device seemed to run out of memory the next logical step is to increase amount of memory. I was expecting the reporter to test if this helps his scenario.

Our buffer counts are typically quite small in various configurations even if the device itself has plenty of memory available. I think you are mixing out-of-memory cases and buffer bloat scenarios in various bugs that you started to comment things.

[pfalcon]

@pfl :

Do you have an analysis on what issues enabling more buffers are hiding?

I'm doing analysis on the various aspects of the IP stack working, and share any notes on the problem spots I see, e.g. a recent such comment: #7578 (comment) . Overall, we have many different issues, which interact in unpredictable ways, which complicate both "static" analysis and trying to reproduce (even isolate from others) a particular issue in practice.

Can you suggest a fix?

Unfortunately, no so far. That's why I think it's important that other developers joined forces trying to reproduce and debug such issues, instead of working around by adding more buffers.

[pfalcon]

@jukkar:

I could not reproduce the issue described in #7678 but as the device seemed to run out of memory the next logical step is to increase amount of memory. I was expecting the reporter to test if this helps his scenario.

I added a steps to reproduce #3132 issue (which appears to be just the generic variant of #7678): #3132 (comment) . It's just a single extra step after reproducing #7831 , so I hope you can give it a try.

Our buffer counts are typically quite small in various configurations even if the device itself has plenty of memory available.

I don't see a problem here. We should target the IP stack working reliably with the minimal memory requirements. Devices which have more memory can just benefit for particular applications targeted at them (for example, they could handle more concurrent connections or have higher throughput). But the baseline should be the stack working in the minimum memory requirements, and for many sample-style applications that's 1 receive and 1 transmit packets, couple with fragment space to hold data for those packets. So, we should not increase pkt/netbuf counts, but decrease them, then figure out why it doesn't work as expected, then try to fix it (either by documenting true minimums, or better by making it work with bare minimums, or explicitly error out if not possible).

I think you are mixing out-of-memory cases and buffer bloat scenarios in various bugs that you started to comment things.

I'm mixing up, because there's a whole mixup of issues in the IP stack, and now more people start to see some of them too. Can you please try to reproduce them on your side, that's the first step to untangle the matter.

Given that there was no bright outcomes with #7831, withdrawing my -1 here. If it helped with jukkar's testing, let it be.