From: "Mattias Rönnblom" <hofors@lysator.liu.se>
To: "dev@dpdk.org" <dev@dpdk.org>
Cc: Jerin Jacob <jerinjacobk@gmail.com>,
Peter Nilsson <peter.j.nilsson@ericsson.com>,
svante.jarvstrat@ericsson.com,
Harry van Haaren <harry.van.haaren@intel.com>,
Abdullah Sevincer <abdullah.sevincer@intel.com>
Subject: Eventdev dequeue-enqueue event correlation
Date: Mon, 23 Oct 2023 18:10:54 +0200 [thread overview]
Message-ID: <b8ecae07-99ee-4e18-b531-30a557bfc5b2@lysator.liu.se> (raw)
Hi.
Consider an Eventdev app using atomic-type scheduling doing something like:
struct rte_event events[3];
rte_event_dequeue_burst(dev_id, port_id, events, 3, 0);
/* Assume three events were dequeued, and the application decides
* it's best off to processing event 0 and 2 consecutively */
process(&events[0]);
process(&events[2]);
events[0].queue_id++;
events[0].op = RTE_EVENT_OP_FORWARD;
events[2].queue_id++;
events[2].op = RTE_EVENT_OP_FORWARD;
rte_event_enqueue_burst(dev_id, port_id, &events[0], 1);
rte_event_enqueue_burst(dev_id, port_id, &events[2], 1);
process(&events[1]);
events[1].queue_id++;
events[1].op = RTE_EVENT_OP_FORWARD;
rte_event_enqueue_burst(dev_id, port_id, &events[1], 1);
If one would just read the Eventdev API spec, they might expect this to
work (especially since impl_opaque hints as potentially be useful for
the purpose of identifying events).
However, on certain event devices, it doesn't (and maybe rightly so). If
event 0 and 2 belongs to the same flow (queue id + flow id pair), and
event 1 belongs to some other, then this other flow would be "unlocked"
at the point of the second enqueue operation (and thus be processed on
some other core, in parallel). The first flow would still be needlessly
"locked".
Such event devices require the order of the enqueued events to be the
same as the dequeued events, using RTE_EVENT_OP_RELEASE type events as
"fillers" for dropped events.
Am I missing something in the Eventdev API documentation?
Could an event device use the impl_opaque field to track the identity of
an event (and thus relax ordering requirements) and still be complaint
toward the API?
What happens if a RTE_EVENT_OP_NEW event is inserted into the mix of
OP_FORWARD and OP_RELEASE type events being enqueued? Again I'm not
clear on what the API says, if anything.
Regards,
Mattias
next reply other threads:[~2023-10-23 16:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-23 16:10 Mattias Rönnblom [this message]
2023-10-24 8:10 ` Bruce Richardson
2023-10-24 9:10 ` Bruce Richardson
2023-10-25 7:40 ` Mattias Rönnblom
2023-10-25 12:29 ` Bruce Richardson
2024-01-16 14:58 ` Bruce Richardson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b8ecae07-99ee-4e18-b531-30a557bfc5b2@lysator.liu.se \
--to=hofors@lysator.liu.se \
--cc=abdullah.sevincer@intel.com \
--cc=dev@dpdk.org \
--cc=harry.van.haaren@intel.com \
--cc=jerinjacobk@gmail.com \
--cc=peter.j.nilsson@ericsson.com \
--cc=svante.jarvstrat@ericsson.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).