> -----Original Message-----
> From: Robin Jarry <[email protected]>
> Sent: Tuesday, May 19, 2026 3:43 PM
> To: [email protected]; Jerin Jacob <[email protected]>; Kiran Kumar
> Kokkilagadda <[email protected]>; Nithin Kumar Dabilpuram
> <[email protected]>; Zhirun Yan <[email protected]>
> Cc: Vladimir Medvedkin <[email protected]>; Christophe Fontaine
> <[email protected]>; David Marchand <[email protected]>;
> Konstantin Ananyev <[email protected]>; Maxime Leroy
> <[email protected]>
> Subject: [EXTERNAL] [PATCH dpdk] graph: replace circular buffer with priority-
> based bitmap scheduling
>
> Replace the FIFO circular buffer used to track pending nodes with a bitmap and
> a priority-sorted schedule table. Each node can now have a scheduling priority
> (int16_t, default 0, lower value means visited first). Source nodes are
> forced to
> INT16_MIN
> > Replace the FIFO circular buffer used to track pending nodes with
> a bitmap and a priority-sorted schedule table. Each node can now have
> a scheduling priority (int16_t, default 0, lower value means visited
> first). Source nodes are forced to INT16_MIN so they always run first.
>
> At graph creation time, nodes are sorted by (priority, id) and assigned
> a bit position (sched_idx). During the walk, a bitmap tracks which nodes
> have pending objects. Scanning from the lowest bit naturally visits
> nodes in priority order.
>
> This improves batching in fan-out-then-converge topologies. When
> eth_input classifies packets to both mpls_input and ipv4_input, the old
> FIFO order could process ipv4_input before mpls_input, causing
> ipv4_input to be visited twice (once before and once after the MPLS
> label is popped). With mpls_input at a higher priority (lower value), it
> runs first and its output accumulates in ipv4_input which is then
> visited only once with all packets.
>
> The bitmap set operation is idempotent (OR on an already-set bit is
> a no-op) which removes the need for the idx == 0 guards that the
> circular buffer required to avoid duplicate enqueue.
Some high-level comments:
1)What will be the performance overhead for graph walk. Try
app/test/test_graph_perf.c and l3fwd_graph
2)If priorities are same, Does it have similar performance with existing code?
3)Does it have any effect on packet ordering on egress.i.e for a given flow
ingress order != egress order
If there is performance regression we may need to consider new
RTE_GRAPH_MODEL_XXXXX to enable this feature
