My system runs 2 concurrent connections, one as a central and one as a peripheral. I am trying to get better throughput.
Initially, I had a problem where the central role would not resume when it had the opportunity to:

From the figure we can see that while CI "A" was block because we were active with the other connection (where we are peripheral). However, there was plenty of time to handle the CI "B" (where we are central).
I found that `CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT` defaults to 7.5 ms, meaning that regardless of the amount of data sent the peripheral connection will always allocate itself 7.5 ms of time - thus blocking CI "B".
When I reduce `CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT` to the minimum (2.5 ms). I get CI "B" back. However, the problem then becomes that the peripheral connection will be limited to only 2.5 ms of time, regardless of how much data it can send.

Reading through the scheduling documentation (https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.2.0/nrfxlib/softdevice_controller/doc/scheduling.html):
"The time is extended one packet pair at a time until the maximum extend time is reached." seems to indicate that the time allocated to a CI should be dynamic. However, it seems that it is solely dictated by `CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT` in the case of a peripheral connection.
Is there any way to actually have the scheduling be dynamic, so there is not a fixed hit to the other connection (regardless of lack of data) but also still allows more data to be sent when there is more data available?

v2.2.0, nRF5340