RFC: net: core: Dynamic priority and deferred processing #93341
Conversation
Store the flag in the packet meta-data so that processing may be deferred if necessary. Signed-off-by: Cla Mattia Galliard <clamattia@gmail.com>
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 <clamattia@gmail.com>
Specify the socket type, when inputing a packet into a packet-socket. Signed-off-by: Cla Mattia Galliard <clamattia@gmail.com>
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 <clamattia@gmail.com>
ClaCodes
force-pushed
the
feature/delay_processing
branch
2 times, most recently
from
9247b83 to
47301bb
Compare
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 <clamattia@gmail.com>
ClaCodes
force-pushed
the
feature/delay_processing
branch
from
47301bb to
26d64cc
Compare
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 <clamattia@gmail.com>
ClaCodes
force-pushed
the
feature/delay_processing
branch
from
26d64cc to
a4849f5
Compare
|
| int priority; | ||
| int desired_priority; | ||
|
|
||
| thread_priority = tx_tc2thread(tc); |
There was a problem hiding this comment.
Shouldn't this use rx_tc2thread()? It looks that this function is currently used in the RX context?
| update_priority(pkt); | ||
|
|
||
| if (!being_processed_by_correct_thread(pkt)) { | ||
| net_queue_rx(net_pkt_iface(pkt), pkt); |
There was a problem hiding this comment.
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.
| net_queue_rx(net_pkt_iface(pkt), pkt); | ||
| } | ||
|
|
||
| } while (true); |
There was a problem hiding this comment.
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.
| default: | ||
| NET_DBG("Dropping pkt %p", pkt); | ||
|
|
||
| update_priority(pkt); |
There was a problem hiding this comment.
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?
| @@ -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; | |||
There was a problem hiding this comment.
I don't think packet-socket processing would require to recalculate the packet priority?
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
update_priority)udpandtcpetc.