[PATCH v3 1/2] event/sw: fix ordering corruption with op release

[Jerin Jacob]

On Mon, Oct 2, 2023 at 11:36 PM Harry van Haaren
<harry.van.haaren at intel.com> wrote:
>
> This commit changes the logic in the scheduler to always
> reset reorder-buffer (and QID/FID) entries when writing
> them. This avoids stale ROB/QID/FID data re-use, which
> previously caused ordering issues.
>
> Before this commit, release events left the history-list
> in an inconsistent state, and future events with op type of
> forward could be incorrectly reordered.
>
> There was a partial fix previously committed which is now
> being resolved for all cases in a more general way, hence
> the two fixlines here.
>
> Fixes: 2e516d18dc01 ("event/sw: fix events mis-identified as needing reorder")
> Fixes: 617995dfc5b2 ("event/sw: add scheduling logic")
> Cc: stable at dpdk.org
>
> Suggested-by: Bruce Richardson <bruce.richardson at intel.com>
> Signed-off-by: Harry van Haaren <harry.van.haaren at intel.com>
> Acked-by: Bruce Richardson <bruce.richardson at intel.com>


Series applied to dpdk-next-net-eventdev/for-main. Thanks


>
> ---
>
> v3:
> - Fixup whitespace and line wrapping suggestions (Bruce)
> - Add Fixes lines (Bruce)
> - Cc stable, as this is a functionality bugfix
> - Including Ack from v2, as no significant code changes
>
> v2:
> - Rework fix to simpler suggestion (Bruce)
> - Respin patchset to "apply order" (Bruce)
> ---
>  drivers/event/sw/sw_evdev_scheduler.c | 13 ++++++++-----
>  1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/event/sw/sw_evdev_scheduler.c b/drivers/event/sw/sw_evdev_scheduler.c
> index de6ed21643..cc652815e4 100644
> --- a/drivers/event/sw/sw_evdev_scheduler.c
> +++ b/drivers/event/sw/sw_evdev_scheduler.c
> @@ -90,8 +90,10 @@ sw_schedule_atomic_to_cq(struct sw_evdev *sw, struct sw_qid * const qid,
>                 sw->cq_ring_space[cq]--;
>
>                 int head = (p->hist_head++ & (SW_PORT_HIST_LIST-1));
> -               p->hist_list[head].fid = flow_id;
> -               p->hist_list[head].qid = qid_id;
> +               p->hist_list[head] = (struct sw_hist_list_entry) {
> +                       .qid = qid_id,
> +                       .fid = flow_id,
> +               };
>
>                 p->stats.tx_pkts++;
>                 qid->stats.tx_pkts++;
> @@ -162,8 +164,10 @@ sw_schedule_parallel_to_cq(struct sw_evdev *sw, struct sw_qid * const qid,
>                 qid->stats.tx_pkts++;
>
>                 const int head = (p->hist_head & (SW_PORT_HIST_LIST-1));
> -               p->hist_list[head].fid = SW_HASH_FLOWID(qe->flow_id);
> -               p->hist_list[head].qid = qid_id;
> +               p->hist_list[head] = (struct sw_hist_list_entry) {
> +                       .qid = qid_id,
> +                       .fid = SW_HASH_FLOWID(qe->flow_id),
> +               };
>
>                 if (keep_order)
>                         rob_ring_dequeue(qid->reorder_buffer_freelist,
> @@ -419,7 +423,6 @@ __pull_port_lb(struct sw_evdev *sw, uint32_t port_id, int allow_reorder)
>                                 struct reorder_buffer_entry *rob_entry =
>                                                 hist_entry->rob_entry;
>
> -                               hist_entry->rob_entry = NULL;
>                                 /* Although fragmentation not currently
>                                  * supported by eventdev API, we support it
>                                  * here. Open: How do we alert the user that
> --
> 2.34.1
>