Guidance on FIFO based usbd_edpt_xfer

[jrahlf]

I was investigating why the current implementation for esp32s3 only achieved up to 550kiB/s transmission instead of the possible 1MB/s (as cdc device).
I noticed, that the current cdc device, does not use the FIFO based API, see here:

tinyusb/src/class/cdc/cdc_device.c

Line 201 in 723e21a

TU_ASSERT( usbd_edpt_xfer(rhport, p_cdc->ep_in, p_cdc->epin_buf, count), 0 );

Does that mean, we are supposed to modify the class drivers, here cdc device, if we want to use the FIFO based API?
Currently, even if dcd_edpt_xfer_fifo were implemented, it would not be called.

[HiFiPhile]

Before trying to use FIFO based API, how did you configure CFG_TUD_CDC_EP_BUFSIZE and CFG_TUD_CDC_TX_BUFSIZE ?

IF that's indeed what you need you can start with #1064

[jrahlf]

Increasing the CFG_TUD_CDC_EP_BUFSIZE definitely helped, see here. I was able to increase transmission bandwidth to 750KiB/s.
CFG_TUD_CDC_TX_BUFSIZE was already quite large - 6kB. Having a large buffer here is not sufficient due to latency problems.
Too bad your PR was never finished. Also it is unfortunate that for high transmission bandwidth this will unnecessarily increase the out endpoint buffer as well.

The other issue I discovered was inefficient usage of the hardware FIFO, but this seems to be resolved in the new dcd_dwc2.c driver already, where it will push as many packets into the FIFO as possible. We need this backported for the dcd_esp32sx asap :D

[HiFiPhile]

In fact you can try dwc2 driver, esp32s3 should be supported

#elif TU_CHECK_MCU(OPT_MCU_ESP32S2, OPT_MCU_ESP32S3)
  #include "dwc2_esp32.h"

#1064 should working as not much thing has changed.

[jrahlf]

If I may, two more questions:

• In the dwc2 driver, it says // It's only possible to write full packets into FIFO. Is this really correct? The last packet will usually not be a full size packet
• I realized that the dwc2 driver fully utilizes the FIFO (good), but does not request large FIFO sizes for IN endpoints (bad for high bandwidth). Why do you not use the previous approach to split the FIFOs between the maximum number of available (or maximum number of needed) IN endpoints?

[HiFiPhile]

The last packet will usually not be a full size packet

I'm not very familiar to dwc2 internal structure, for me it's rather a check to ensure there is enough space in the FIFO to prevent one packet divided by half, than talking about he last packet.

You may reach the original author @duempel for more details.

does not request large FIFO sizes for IN endpoints (bad for high bandwidth)

Fo the moment the need of high bandwidth is rather rare, the stack is not in the phase of performance optimisation. (That's why #1064 was stalled, besides tud_cdc_rx_wanted_cb() can't be implemented with FIFO transfer)

Re-split FIFO each time an endpoint is opened needs some complexe routine which yield little. And ISO endpoints open at runtime so if there are no more FIFO space the driver will fail (the new dcd_edpt_iso_alloc() will help in this case but only supported by uac2 class and stm32_fsdev driver at the moment)