Threading priorities

Updated: October 28, 2024

There are a couple of ways that you can change the priority of the threads responsible for receiving packets from the hardware.

You can pass the rx_prio_pulse option to the stack to set the default thread priority. For example:

io-pkt-v4-hc -ptcpip rx_pulse_prio=50

This makes all the receive threads run at priority 50. The current default for these threads is priority 21.

The second mechanism lets you change the priority on a per-interface basis. This is an option passed to the driver and, as such, is supported only if the driver supports it. When the driver registers for its receive interrupt, it can specify a priority for the pulse that is returned from the ISR. This pulse priority is what the thread will use when running. Here's some sample code for my_board:

if ((rc = interrupt_entry_init(&my_board->inter_rx, 0, NULL,
    cfg->priority)) != EOK) {
        log(LOG_ERR, "%s(): interrupt_entry_init(rx) failed: %d",
           __FUNCTION__, rc);
        my_board_destroy(my_board, 9);
                return rc;
}
Note: Driver-specific thread priorities are assigned on a per-interface basis. The stack normally creates one thread per CPU to allow the stack to scale appropriately in terms of performance on an SMP system. Once you use an interface-specific parameter with multiple interfaces, you must get the stack to create one thread per interface in order to have that option picked up and used properly by the stack. This is handled with the -t option to the stack.

For example, to have the stack start up and receive packets on one interface at priority 20 and on a second interface at priority 50 on a single-processor system, you would use the following command-line options:

io-pkt-v4-hc -t2 -d my_board syspage=1,priority=20,pci=0 \
-dmy_board syspage=1,priority=50,pci=1

If you've specified a per-interface priority, and there are more interfaces than threads, the stack sends a warning to slogger2. If there are insufficient threads present, the per-interface priority is ignored (but the rx_pulse_prio option is still honored).

The actual options for setting the priority and selecting an individual card depend on the device driver; see the driver documentation for specific option information.