From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 0CCF84303C; Sat, 12 Aug 2023 07:52:52 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DA9A9410FA; Sat, 12 Aug 2023 07:52:51 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id 444B940151 for ; Sat, 12 Aug 2023 07:52:51 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id B711B5B49 for ; Sat, 12 Aug 2023 07:52:50 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 939DA5C3A; Sat, 12 Aug 2023 07:52:50 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=ALL_TRUSTED, AWL, NICE_REPLY_A autolearn=disabled version=3.4.6 X-Spam-Score: -1.9 Received: from [192.168.1.59] (h-62-63-215-114.A163.priv.bahnhof.se [62.63.215.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 133EB56F5; Sat, 12 Aug 2023 07:52:48 +0200 (CEST) Message-ID: <6c943950-b239-f47a-8c91-66ebeded5a6d@lysator.liu.se> Date: Sat, 12 Aug 2023 07:52:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [EXT] Re: [RFC 0/3] Introduce event link profiles To: Pavan Nikhilesh Bhagavatula , Jerin Jacob Kollanukkaran , Shijith Thotton , "timothy.mcdaniel@intel.com" , "hemant.agrawal@nxp.com" , "sachin.saxena@nxp.com" , "mattias.ronnblom@ericsson.com" , "liangma@liangbit.com" , "peter.mccarthy@intel.com" , "harry.van.haaren@intel.com" , "erik.g.carrillo@intel.com" , "abhinandan.gujjar@intel.com" , "s.v.naga.harish.k@intel.com" , "anatoly.burakov@intel.com" Cc: "dev@dpdk.org" References: <20230809142617.6482-1-pbhagavatula@marvell.com> Content-Language: en-US From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On 2023-08-10 07:17, Pavan Nikhilesh Bhagavatula wrote: >> On 2023-08-09 16:26, pbhagavatula@marvell.com wrote: >>> From: Pavan Nikhilesh >>> >>> 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 >>>