> I think this should handle the unlink case you mention, however perhaps you
> have identified a genuine bug. If you have more info or a sample config / app
> that easily demonstrates the issue that would help reproduce/debug here?
Hi Harry,
The bug report includes a simple test application for demonstrating the issue.
I've done some further digging and the following simple patch seems to fix the
issue of events ending up in wrong ports.
diff --git a/drivers/event/sw/sw_evdev_scheduler.c
b/drivers/event/sw/sw_evdev_scheduler.c
index 8a2c9d4f9..57298345d 100644
--- a/drivers/event/sw/sw_evdev_scheduler.c
+++ b/drivers/event/sw/sw_evdev_scheduler.c
@@ -79,9 +79,11 @@ sw_schedule_atomic_to_cq(struct sw_evdev *sw, struct sw_qid
* const qid,
int cq = fid->cq;
if (cq < 0) {
- uint32_t cq_idx = qid->cq_next_tx++;
- if (qid->cq_next_tx == qid->cq_num_mapped_cqs)
+ uint32_t cq_idx;
+ if (qid->cq_next_tx >= qid->cq_num_mapped_cqs)
qid->cq_next_tx = 0;
+ cq_idx = qid->cq_next_tx++;
+
cq = qid->cq_map[cq_idx];
/* find least used */
@@ -168,9 +170,11 @@ sw_schedule_parallel_to_cq(struct sw_evdev *sw, struct
sw_qid * const qid,
do {
if (++cq_check_count > qid->cq_num_mapped_cqs)
goto exit;
- cq = qid->cq_map[cq_idx];
- if (++cq_idx == qid->cq_num_mapped_cqs)
+
+ if (cq_idx >= qid->cq_num_mapped_cqs)
cq_idx = 0;
+ cq = qid->cq_map[cq_idx++];
+
} while (rte_event_ring_free_count(
sw->ports[cq].cq_worker_ring) == 0 ||
sw->ports[cq].inflights == SW_PORT_HIST_LIST);
@@ -251,6 +255,9 @@ sw_schedule_qid_to_cq(struct sw_evdev *sw)
if (iq_num >= SW_IQS_MAX)
continue;
+ if (qid->cq_num_mapped_cqs == 0)
+ continue;
+
uint32_t pkts_done = 0;
uint32_t count = iq_ring_count(qid->iq[iq_num]);
However, events from atomic/ordered queues may still end up getting stuck when
unlinking (scheduled back to unlinked port). In case of atomic queues the
problem seems to be related to (struct sw_fid_t *)fid->cq fields being invalid.
With ordered queues events get stuck in reorder buffer.
-Matias
