RFC: net: core: Dynamic priority and deferred processing #93341

ClaCodes · 2025-07-18T16:17:54Z

Goal

To enable quality-of-service (QoS) applications, allow to reschedule/defer
the processing of a network packet based on its properties.

Based on: #93298

Future Work

Implement proper infrastructure to enpower application writers to hook in with custom rules for changing packet priorities based on respective properties of the packet at different layers (replace the sample update_priority)
- At layer 2: ptype, src mac, dest mac, vlan-stuff
- At layer 3: src ip, dest ip, protocol
- At layer 4: port
Implement an interuption point between the deconding of the l2 header and the executing of the registered callbacks so that handling of layer 2 (or 3?) protocols may be defereed such as arp for example
Implement an interuption point between the deconding of the l3 header and the handling of udp and tcp etc.

rlubos

Some initial feedback (on the topmost 2 commits).

rlubos · 2025-07-21T12:45:31Z

subsys/net/ip/net_tc.c

+	int priority;
+	int desired_priority;
+
+	thread_priority = tx_tc2thread(tc);


Shouldn't this use rx_tc2thread()? It looks that this function is currently used in the RX context?

Good catch. Fixed.

rlubos · 2025-07-21T13:12:28Z

subsys/net/ip/net_core.c

+		update_priority(pkt);
+
+		if (!being_processed_by_correct_thread(pkt)) {
+			net_queue_rx(net_pkt_iface(pkt), pkt);


If we requeue the packet I think we should quit processing_data() as well? The packet should be picked up by the same function, but on a different thread.

Absolutely. Fixed.

rlubos · 2025-07-21T13:22:10Z

subsys/net/ip/net_core.c

+			net_queue_rx(net_pkt_iface(pkt), pkt);
+		}
+
+	} while (true);


TBH I'm not too fond with this loop approach, it'll add extra processing time for each packet, regardless of whether this TC-requeueing feature is used.

I did this, because there was precedent (again loop).

True, but that was only the case with virtual interfaces (will need @jukkar to get more info on how this worked), now every single packet will need to loop after l2 processing at least.

This is not essential to the RFC. Alternatively could just update priority, conditionally requeue and return NET_OK in-place.

rlubos · 2025-07-21T13:24:17Z

subsys/net/ip/net_core.c

-	default:
-		NET_DBG("Dropping pkt %p", pkt);
+
+		update_priority(pkt);


Plus, I wonder, shouldn't there be a spearate update_priority() function for each layer, by design? Just thinking out loud, but I imagine that after L3 has processed the packet, we shouldn't be using L2-specific rules anymore?

Good catch. Will rethink this.

rlubos · 2025-07-21T13:25:39Z

subsys/net/ip/net_core.c

@@ -71,39 +71,39 @@ static inline enum net_verdict process_data(struct net_pkt *pkt)
 	if (!net_pkt_is_raw_processed(pkt)) {
 		net_pkt_set_raw_processed(pkt, true);
 		net_packet_socket_input(pkt, ETH_P_ALL, SOCK_RAW);
+		return NET_CONTINUE;


I don't think packet-socket processing would require to recalculate the packet priority?

ClaCodes · 2025-07-24T16:49:56Z

@rlubos
I reverted along the lines of discussion.
Note that, if we go with the current approach of the RFC, we would have to add the snippet to multiple places:

+               update_priority_l2(pkt);
+               if (!being_processed_by_correct_thread(pkt)) {
+                       net_queue_rx(net_pkt_iface(pkt), pkt);
+                       return NET_OK;
+               }

For example after extracting the l2-header but before: STRUCT_SECTION_FOREACH(net_l3_register, l3) { such that for example arp packets can be offloaded on to another traffic class queue.
and after ip-header processing etc ...

I believe, that a loop and a if-else-chain or a switch would be more readable. Presumably the added computation cost is negligible?

void process_data(struct net_pkt *pkt)
{
    // switch would only work if raw packet sockets not needed for loop back etc.
    switch (pkt->step) {
    case STEP_1:
        do_step_1();
        return NET_CONTINUE;
    case STEP_2:
        do_step_2();
        return NET_CONTINUE;
    case STEP_3:
        do_step_3();
        return NET_CONTINUE;
        // ...
    }
}

void processing_data(struct net_pkt *pkt)
{
    enum net_verdict verdict = NET_CONTINUE;
    do {
        verdict = process_data(pkt);
        if (verdict != NET_CONTINUE) {
            break;
        }
        update_prio(pkt, pkt->step);
        if (!on_correct_thread(pkt)) {
            net_queue_rx(pkt);
            verdict = NET_OK;
        }
    } while (verdict == NET_CONTINUE);
    // ... unref
}

If we do not do this, it will be very hard to follow at which point the processing can be interrupted and then recontinued later. This may be an easy source of bugs.

Store the flag in the packet meta-data so that processing may be deferred if necessary. Signed-off-by: Cla Mattia Galliard <[email protected]>

Use the l2_processed-flag to decide whether a network packet needs to be processed by an L2-handler. This could be used in the future to requeue packets for later processing by a different traffic class queue. Signed-off-by: Cla Mattia Galliard <[email protected]>

Specify the socket type, when inputting a packet into a packet-socket. Signed-off-by: Cla Mattia Galliard <[email protected]>

When handling packets for inputing into packet-sockets, unconditionally forward them, so that they may be handled by the rest of the network stack after. Signed-off-by: Cla Mattia Galliard <[email protected]>

Store a flag about which layer has already processed a packet in its meta information. This enables deferred processing of it. Signed-off-by: Cla Mattia Galliard <[email protected]>

ClaCodes · 2025-08-16T09:03:38Z

Rebased

Note: contains all commits from #93246 and adds two commit

To enable quality-of-service (QoS) applications, allow to reschedule/defer the processing of a network packet based on its properties. This means, that processing can be offloaded to tc-queue-threads with different priorities. Signed-off-by: Cla Mattia Galliard <[email protected]>

sonarqubecloud · 2025-08-16T09:39:28Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
1.6% Duplication on New Code

See analysis details on SonarQube Cloud

rlubos

I think packet rescheduling logic turned out pretty straightforward and looks fine, however I think we need to think on how would the priority updating look like in practice.

rlubos · 2025-08-18T09:40:50Z

subsys/net/ip/net_tc.c

@@ -235,6 +235,21 @@ static uint8_t rx_tc2thread(uint8_t tc)
 }
 #endif

+bool net_tc_rx_is_current_thread(uint8_t tc)


Just wondering if we'd need a dummy stub for the function for the case when NET_TC_RX_COUNT <= 1, the packet won't be rescheduled in such case anyway, not sure how well the compiler will optimize that.

rlubos · 2025-08-18T09:46:50Z

subsys/net/ip/net_core.c

+	/* This is just an example.
+	 * Similar infrastructure with custom application rules like
+	 * net_pkt_filter could be established
+	 */


I think we need to start thinking on how such infrastructure to update packet priorities should look like, I think the application should be able to register a function to update priorities? Should it be done globally or at per-interface basis? Perhaps such function should become part of struct net_if_api?

zephyrbot added the area: Networking label Jul 18, 2025

zephyrbot requested review from jukkar, pdgendt, rlubos and ssharks July 18, 2025 16:18

zephyrbot assigned rlubos and jukkar Jul 18, 2025

ClaCodes force-pushed the feature/delay_processing branch 4 times, most recently from 26d64cc to a4849f5 Compare July 19, 2025 12:37

rlubos reviewed Jul 21, 2025

View reviewed changes

ClaCodes force-pushed the feature/delay_processing branch 5 times, most recently from c5f9c6c to 9bd6ae9 Compare July 24, 2025 16:36

ClaCodes force-pushed the feature/delay_processing branch from 9bd6ae9 to d88b7ac Compare July 25, 2025 05:56

ClaCodes added 5 commits August 16, 2025 10:51

net: pkt: Store is_loopback info in packet meta-data

c92a113

Store the flag in the packet meta-data so that processing may be deferred if necessary. Signed-off-by: Cla Mattia Galliard <[email protected]>

net: socket: Specify the packet socket-type, when inputting

8052e23

Specify the socket type, when inputting a packet into a packet-socket. Signed-off-by: Cla Mattia Galliard <[email protected]>

net: connection: Unconditionally forward into packet sockets

485333e

When handling packets for inputing into packet-sockets, unconditionally forward them, so that they may be handled by the rest of the network stack after. Signed-off-by: Cla Mattia Galliard <[email protected]>

net: pkt: Store meta-information of processing in the net_pkt

d0663f1

Store a flag about which layer has already processed a packet in its meta information. This enables deferred processing of it. Signed-off-by: Cla Mattia Galliard <[email protected]>

ClaCodes force-pushed the feature/delay_processing branch from d88b7ac to 80f5552 Compare August 16, 2025 09:03

ClaCodes mentioned this pull request Aug 16, 2025

net_pkt: Store meta-information of processing in the net_pkt #93298

Closed

ClaCodes force-pushed the feature/delay_processing branch from 80f5552 to a69163e Compare August 16, 2025 09:35

ClaCodes requested a review from rlubos August 16, 2025 09:37

rlubos reviewed Aug 18, 2025

View reviewed changes

RFC: net: core: Dynamic priority and deferred processing #93341

Are you sure you want to change the base?

RFC: net: core: Dynamic priority and deferred processing #93341

Uh oh!

Conversation

ClaCodes commented Jul 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Goal

Future Work

Uh oh!

rlubos left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ClaCodes commented Jul 24, 2025

Uh oh!

ClaCodes commented Aug 16, 2025

Uh oh!

sonarqubecloud bot commented Aug 16, 2025

Quality Gate passed

Uh oh!

rlubos left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ClaCodes commented Jul 18, 2025 •

edited

Loading