Describe the bug

When using the SMP client at a high baud rate (1M baud), I observed the SMP server sending data but the SMP client failing to receive it.

For the custom mcumgr group I was using, the client retried the request, but since the server had already sent the data it was no longer available on the server and was lost. This took days to track down. Early on I tried increasing CONFIG_UART_MCUMGR_RX_BUF_SIZE but it was unclear that I needed to increase CONFIG_UART_MCUMGR_RX_BUF_COUNT since my buffer size was 4x my MTU and I already had 2 buffers. Increasing the buffer count to 4 resolved this behavior.

This would have been traceable in minutes had there been warning logs associated with the dropped data. I will open a PR to resolve this issue.

Regression

• This is a regression.

Steps to reproduce

This is not easy to reproduce. Here is the general approach:

1. Configure SMP server on one chip and SMP client on another chip using the Serial transport
2. Configure UARTs as interrupt-driven on both chips at 1M (or higher)
3. Configure the client to have a system load high enough that the uarts interrupt is not immediately serviced
4. Configure an SMP group that sends data to the client from a fifo upon request
5. When buffer slabs are exhausted, SMP fragments will be silently dropped

Relevant log output

Impact

Functional Limitation – Some features not working as expected, but system usable.

Environment

• Linux
• Zephyr SDK 0.17.0
• v4.0.99-ncs1-2

Additional Context

No response