Why is ble_rx_thread priority cooperative?

[loquat]

ble_rx_thread(SystemWrokq or recv_workq_bt) is cooperative priorities thread in nrf connect SDK

I want to know why.

Also, can I change the priority of the thread to preemption?
(I want to perform device driver processing with a higher priority thread)

Can it be solved by specifying BT_RECV_BLOCKING?

[Amanda Hsieh]

Hi,

I cannot find any information regarding ble_rx_thread, SystemWrokq, or recv_workq_bt. Could you elaborate in more detail on what those mean or where you see them? Any docs or links? Thanks. 

Regards,
Amanda H. 

[loquat]

ble_rx_thread / recv_workq_bt is
zephyr/subsys/bluetooth/host/hci_core.c
#if defined(CONFIG_BT_RECV_WORKQ_BT)
static struct k_work_q bt_workq;
static K_KERNEL_STACK_DEFINE(rx_thread_stack, CONFIG_BT_RX_STACK_SIZE);

SystemWrokq is
Zephyr's System Workqueue

And, it's priority is defined,
bt_workq:
K_PRIO_COOP(CONFIG_BT_RX_PRIO) // cooperative priority

System Workqueue:
zephyr/subsys/bluetooth/Kconfig
# The Bluetooth subsystem requires the system workqueue to execute at
# a cooperative priority.
config SYSTEM_WORKQUEUE_PRIORITY
    range -256 -1

What I want to do is run a thread that takes precedence over bluetooth.

[Amanda Hsieh]

Hi,

From the team:

You can't change it. It's pretty much a kludge because the host is not thread-safe. https://github.com/zephyrproject-rtos/zephyr/issues/52364 is created to track the issue for the TX thread, but the changes made to address that will probably also allow the RX thread to run in a preemptive priority.

This is not going to get fixed fast, it's going to be at least a year, but no promise for the schedule. 

The OP can't get what you want basically, since once the TX or RX threads have started processing something, they lock the scheduler (effectively, since they're coop threads) until they have done processing it and yield to other threads. Maybe the device driver processing can be done in a low-prio IRQ?

Regards, 
Amanda H.

[loquat]

OK.Thanks.