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 636064301D; Wed, 9 Aug 2023 21:45:19 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EE5E440DFB; Wed, 9 Aug 2023 21:45:18 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id 1CA0B40DDB for ; Wed, 9 Aug 2023 21:45:17 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 9329F1596 for ; Wed, 9 Aug 2023 21:45:16 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 91D9C1246; Wed, 9 Aug 2023 21:45:16 +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=-3.5 required=5.0 tests=ALL_TRUSTED, AWL, NICE_REPLY_A autolearn=disabled version=3.4.6 X-Spam-Score: -3.5 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 24E481245; Wed, 9 Aug 2023 21:45:12 +0200 (CEST) Message-ID: Date: Wed, 9 Aug 2023 21:45:12 +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: [RFC 0/3] Introduce event link profiles To: pbhagavatula@marvell.com, jerinj@marvell.com, sthotton@marvell.com, 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: <20230809142617.6482-1-pbhagavatula@marvell.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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-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. > 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? > 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 >