usb: device_next: class: cdc_acm: throughput improvements (low hanging fruit) #99838
+31
−6
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.



Do not artificially limit the size of the USB request to the endpoint size, as this forces multiple round trips through the CDC ACM class implementation when the TX FIFO is larger than the endpoint size. The USB stack handles packetizing to the maximum endpoint size. The maximum allocation size is limited to prevent starving other USB users.
When a custom pool is used for CDC ACM, allow the buffer sizes to be configured in Kconfig.
Throughput testing on a nRF52840DK with
CONFIG_UDC_BUF_POOL_SIZE=1024shows a throughput increase from ~1.7 Mbps to ~2.7 Mbps.Steps towards improving the issue of #99779, but this is only the absolute lowest hanging fruit).
Throughput tested on the reproducer steps from the linked issue.
The limit of
CONFIG_UDC_BUF_POOL_SIZE / 4was picked out of thin air as a reasonable default, happy to hear arguments against.