From: "Mattias Rönnblom" <hofors@lysator.liu.se>
To: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>,
Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
Shijith Thotton <sthotton@marvell.com>,
"timothy.mcdaniel@intel.com" <timothy.mcdaniel@intel.com>,
"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
"sachin.saxena@nxp.com" <sachin.saxena@nxp.com>,
"mattias.ronnblom@ericsson.com" <mattias.ronnblom@ericsson.com>,
"liangma@liangbit.com" <liangma@liangbit.com>,
"peter.mccarthy@intel.com" <peter.mccarthy@intel.com>,
"harry.van.haaren@intel.com" <harry.van.haaren@intel.com>,
"erik.g.carrillo@intel.com" <erik.g.carrillo@intel.com>,
"abhinandan.gujjar@intel.com" <abhinandan.gujjar@intel.com>,
"s.v.naga.harish.k@intel.com" <s.v.naga.harish.k@intel.com>,
"anatoly.burakov@intel.com" <anatoly.burakov@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [EXT] Re: [RFC 0/3] Introduce event link profiles
Date: Sat, 12 Aug 2023 07:52:48 +0200 [thread overview]
Message-ID: <6c943950-b239-f47a-8c91-66ebeded5a6d@lysator.liu.se> (raw)
In-Reply-To: <PH0PR18MB408649761598CB48592D252FDE13A@PH0PR18MB4086.namprd18.prod.outlook.com>
On 2023-08-10 07:17, Pavan Nikhilesh Bhagavatula wrote:
>> On 2023-08-09 16:26, pbhagavatula@marvell.com wrote:
>>> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
>>>
>>> A collection of event queues linked to an event port can be associated
>>> with unique identifier called as a profile, multiple such profiles can
>>> be configured based on the event device capability using the function
>>> `rte_event_port_link_with_profile` which takes arguments similar to
>>> `rte_event_port_link` in addition to the profile identifier.
>>>
>>
>> What is the overall goal with this new API? What problems does it intend
>> to solve, that the old one doesn't.
>
> Linking and unlinking currently has huge overhead and when it needs to be done
> in fastpath, we have to wait for unlinks to complete and handle other corner cases.
>
OK, so this API change is specific to some particular hardware? Is this
true for some other event devices? That "huge overhead" goes to "simple
function call" for unlinking+linking, provided the target configuration
is known in advance.
What is the overall use case?
> This patch set solves it by avoiding linking/unlinking altogether in fastpath by
> preconfigured set of link profiles out of which only one would be active and can
> be changed in fastpath with a simple function call. There is no link/unlink waiting for
> unlink overhead.
>
>>
>>> The maximum link profiles that are supported by an event device is
>>> advertised through the structure member
>>> `rte_event_dev_info::max_profiles_per_port`.
>>>
>>> By default, event ports are configured to use the link profile 0 on
>>> initialization.
>>>
>>> Once multiple link profiles are set up and the event device is started, the
>>> application can use the function `rte_event_port_change_profile` to
>> change
>>> the currently active profile on an event port. This effects the next
>>> `rte_event_dequeue_burst` call, where the event queues associated with
>> the
>>> newly active link profile will participate in scheduling.
>>>
>>> Rudementary work flow would something like:
>>>
>>> Config path:
>>>
>>> uint8_t lowQ[4] = {4, 5, 6, 7};
>>> uint8_t highQ[4] = {0, 1, 2, 3};
>>>
>>> if (rte_event_dev_info.max_profiles_per_port < 2)
>>> return -ENOTSUP;
>>>
>>> rte_event_port_link_with_profile(0, 0, highQ, NULL, 4, 0);
>>> rte_event_port_link_with_profile(0, 0, lowQ, NULL, 4, 1);
>>>
>>> Worker path:
>>>
>>> empty_high_deq = 0;
>>> empty_low_deq = 0;
>>> is_low_deq = 0;
>>> while (1) {
>>> deq = rte_event_dequeue_burst(0, 0, &ev, 1, 0);
>>> if (deq == 0) {
>>> /**
>>> * Change link profile based on work activity on current
>>> * active profile
>>> */
>>> if (is_low_deq) {
>>> empty_low_deq++;
>>> if (empty_low_deq == MAX_LOW_RETRY) {
>>> rte_event_port_change_profile(0, 0, 0);
>>> is_low_deq = 0;
>>> empty_low_deq = 0;
>>> }
>>> continue;
>>> }
>>>
>>> if (empty_high_deq == MAX_HIGH_RETRY) {
>>> rte_event_port_change_profile(0, 0, 1);
>>> is_low_deq = 1;
>>> empty_high_deq = 0;
>>> }
>>> continue;
>>> }
>>>
>>> // Process the event received.
>>>
>>> if (is_low_deq++ == MAX_LOW_EVENTS) {
>>> rte_event_port_change_profile(0, 0, 0);
>>> is_low_deq = 0;
>>> }
>>> }
>>>
>>
>> This thing looks like the application is asked to do work scheduling.
>> That doesn't sound right. That's the job of the work scheduler (i.e.,
>> the event device).
>>
>> If this thing is merely a matter of changing what queues are linked to
>> which ports, wouldn't a new call:
>> rte_event_port_link_modify()
>> suffice?
>
>
> Some applications divide their available lcores into multiple types of
> workers which each work on a unique set of event queues, application might
> need to modify the worker ratio based on various parameters at run time
> without a lot of overhead.
>
> Modifying links wouldn’t work because we might want to restore previous links
> based on the new traffic pattern etc.,.
>
>>
>>> An application could use heuristic data of load/activity of a given event
>>> port and change its active profile to adapt to the traffic pattern.
>>>
>>> An unlink function `rte_event_port_unlink_with_profile` is provided to
>>> modify the links associated to a profile, and
>>> `rte_event_port_links_get_with_profile` can be used to retrieve the links
>>> associated with a profile.
>>>
>>> Pavan Nikhilesh (3):
>>> eventdev: introduce link profiles
>>> event/cnxk: implement event link profiles
>>> test/event: add event link profile test
>>>
>>> app/test/test_eventdev.c | 110 ++++++++++
>>> config/rte_config.h | 1 +
>>> doc/guides/eventdevs/cnxk.rst | 1 +
>>> doc/guides/prog_guide/eventdev.rst | 58 ++++++
>>> drivers/common/cnxk/roc_nix_inl_dev.c | 4 +-
>>> drivers/common/cnxk/roc_sso.c | 18 +-
>>> drivers/common/cnxk/roc_sso.h | 8 +-
>>> drivers/common/cnxk/roc_sso_priv.h | 4 +-
>>> drivers/event/cnxk/cn10k_eventdev.c | 45 ++--
>>> drivers/event/cnxk/cn10k_worker.c | 11 +
>>> drivers/event/cnxk/cn10k_worker.h | 1 +
>>> drivers/event/cnxk/cn9k_eventdev.c | 72 ++++---
>>> drivers/event/cnxk/cn9k_worker.c | 22 ++
>>> drivers/event/cnxk/cn9k_worker.h | 2 +
>>> drivers/event/cnxk/cnxk_eventdev.c | 34 ++--
>>> drivers/event/cnxk/cnxk_eventdev.h | 10 +-
>>> drivers/event/dlb2/dlb2.c | 1 +
>>> drivers/event/dpaa/dpaa_eventdev.c | 1 +
>>> drivers/event/dpaa2/dpaa2_eventdev.c | 2 +-
>>> drivers/event/dsw/dsw_evdev.c | 1 +
>>> drivers/event/octeontx/ssovf_evdev.c | 2 +-
>>> drivers/event/opdl/opdl_evdev.c | 1 +
>>> drivers/event/skeleton/skeleton_eventdev.c | 1 +
>>> drivers/event/sw/sw_evdev.c | 1 +
>>> lib/eventdev/eventdev_pmd.h | 59 +++++-
>>> lib/eventdev/eventdev_private.c | 9 +
>>> lib/eventdev/eventdev_trace.h | 22 ++
>>> lib/eventdev/eventdev_trace_points.c | 6 +
>>> lib/eventdev/rte_eventdev.c | 146 ++++++++++---
>>> lib/eventdev/rte_eventdev.h | 226 +++++++++++++++++++++
>>> lib/eventdev/rte_eventdev_core.h | 4 +
>>> lib/eventdev/rte_eventdev_trace_fp.h | 8 +
>>> lib/eventdev/version.map | 5 +
>>> 33 files changed, 788 insertions(+), 108 deletions(-)
>>>
>>> --
>>> 2.25.1
>>>
next prev parent reply other threads:[~2023-08-12 5:52 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-09 14:26 pbhagavatula
2023-08-09 14:26 ` [RFC 1/3] eventdev: introduce " pbhagavatula
2023-08-18 10:27 ` Jerin Jacob
2023-08-09 14:26 ` [RFC 2/3] event/cnxk: implement event " pbhagavatula
2023-08-09 14:26 ` [RFC 3/3] test/event: add event link profile test pbhagavatula
2023-08-09 19:45 ` [RFC 0/3] Introduce event link profiles Mattias Rönnblom
2023-08-10 5:17 ` [EXT] " Pavan Nikhilesh Bhagavatula
2023-08-12 5:52 ` Mattias Rönnblom [this message]
2023-08-14 11:29 ` Pavan Nikhilesh Bhagavatula
2023-08-25 18:44 ` [PATCH " pbhagavatula
2023-08-25 18:44 ` [PATCH 1/3] eventdev: introduce " pbhagavatula
2023-08-25 18:44 ` [PATCH 2/3] event/cnxk: implement event " pbhagavatula
2023-08-25 18:44 ` [PATCH 3/3] test/event: add event link profile test pbhagavatula
2023-08-31 20:44 ` [PATCH v2 0/3] Introduce event link profiles pbhagavatula
2023-08-31 20:44 ` [PATCH v2 1/3] eventdev: introduce " pbhagavatula
2023-09-20 4:22 ` Jerin Jacob
2023-08-31 20:44 ` [PATCH v2 2/3] event/cnxk: implement event " pbhagavatula
2023-08-31 20:44 ` [PATCH v2 3/3] test/event: add event link profile test pbhagavatula
2023-09-21 10:28 ` [PATCH v3 0/3] Introduce event link profiles pbhagavatula
2023-09-21 10:28 ` [PATCH v3 1/3] eventdev: introduce " pbhagavatula
2023-09-27 15:23 ` Jerin Jacob
2023-09-21 10:28 ` [PATCH v3 2/3] event/cnxk: implement event " pbhagavatula
2023-09-27 15:29 ` Jerin Jacob
2023-09-21 10:28 ` [PATCH v3 3/3] test/event: add event link profile test pbhagavatula
2023-09-27 14:56 ` [PATCH v3 0/3] Introduce event link profiles Jerin Jacob
2023-09-28 10:12 ` [PATCH v4 " pbhagavatula
2023-09-28 10:12 ` [PATCH v4 1/3] eventdev: introduce " pbhagavatula
2023-10-03 6:55 ` Jerin Jacob
2023-09-28 10:12 ` [PATCH v4 2/3] event/cnxk: implement event " pbhagavatula
2023-09-28 10:12 ` [PATCH v4 3/3] test/event: add event link profile test pbhagavatula
2023-09-28 14:45 ` [PATCH v4 0/3] Introduce event link profiles Jerin Jacob
2023-09-29 9:27 ` [EXT] " Pavan Nikhilesh Bhagavatula
2023-10-03 7:51 ` [PATCH v5 " pbhagavatula
2023-10-03 7:51 ` [PATCH v5 1/3] eventdev: introduce " pbhagavatula
2023-10-03 7:51 ` [PATCH v5 2/3] event/cnxk: implement event " pbhagavatula
2023-10-03 7:51 ` [PATCH v5 3/3] test/event: add event link profile test pbhagavatula
2023-10-03 9:47 ` [PATCH v6 0/3] Introduce event link profiles pbhagavatula
2023-10-03 9:47 ` [PATCH v6 1/3] eventdev: introduce " pbhagavatula
2023-10-03 9:47 ` [PATCH v6 2/3] event/cnxk: implement event " pbhagavatula
2023-10-03 9:47 ` [PATCH v6 3/3] test/event: add event link profile test pbhagavatula
2023-10-03 10:36 ` [PATCH v6 0/3] Introduce event link profiles Jerin Jacob
2023-10-03 14:12 ` Bruce Richardson
2023-10-03 15:17 ` Jerin Jacob
2023-10-03 15:32 ` [EXT] " Pavan Nikhilesh Bhagavatula
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=6c943950-b239-f47a-8c91-66ebeded5a6d@lysator.liu.se \
--to=hofors@lysator.liu.se \
--cc=abhinandan.gujjar@intel.com \
--cc=anatoly.burakov@intel.com \
--cc=dev@dpdk.org \
--cc=erik.g.carrillo@intel.com \
--cc=harry.van.haaren@intel.com \
--cc=hemant.agrawal@nxp.com \
--cc=jerinj@marvell.com \
--cc=liangma@liangbit.com \
--cc=mattias.ronnblom@ericsson.com \
--cc=pbhagavatula@marvell.com \
--cc=peter.mccarthy@intel.com \
--cc=s.v.naga.harish.k@intel.com \
--cc=sachin.saxena@nxp.com \
--cc=sthotton@marvell.com \
--cc=timothy.mcdaniel@intel.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).