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 A49F1429E5; Tue, 25 Apr 2023 06:10:15 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2A0B640A7E; Tue, 25 Apr 2023 06:10:15 +0200 (CEST) Received: from mail-vk1-f182.google.com (mail-vk1-f182.google.com [209.85.221.182]) by mails.dpdk.org (Postfix) with ESMTP id 5532A400D7 for ; Tue, 25 Apr 2023 06:10:13 +0200 (CEST) Received: by mail-vk1-f182.google.com with SMTP id 71dfb90a1353d-440445a48c7so2002988e0c.1 for ; Mon, 24 Apr 2023 21:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682395812; x=1684987812; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=MmtiOqp6PQEiWKhVRuqpv8LmslGAWreyGXJKVQuH1TY=; b=Dggx6XpGMlyYMuDTYBqzj+u6h3XKwPQzaBPAoCqEPfSTh4FYYhE1VLA/GN/ZhqwFWS uZ6YD45xlvG74w4e8+wagDT3y/UUpqa60T5BKfBGF3w2sOpfDWBvqnq8lqtBIsAhUTH4 k36sWFMr/1YKN8MMFjeGnFR+OqVlyordrJsviSd5DqvvsWr99UYVUEnDhTd5ap6WQ3/b BGVfG9MmzJp0r4GNj5YI7yf9G+mdM1tNDdxHDQqQ9WzS+ry8N/J4q6649ANmOjVggXf8 MI+ZMh+Y7+3jBKtoWum36ADdYC5uRUBW4v+ZGJKutHE/ATvKzjwIC1oDsTz9npOD/iYe b7Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682395812; x=1684987812; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=MmtiOqp6PQEiWKhVRuqpv8LmslGAWreyGXJKVQuH1TY=; b=Dkf+FMIbhnckioUMJ8xCLDYqtVpj+VV8lWFA1vsIfKtNZT7OqYJIgVJeHIA4gftsUK v2FIHgTI4EEPLMBUXLebqm+KfKNSlc+U4/zyDneOXLTqUJWojRhy92ONRDJLoK9natIx bfvguTCKBvojyqpqOfjuEn/kFNpxGMr86Qjow6B0hsi09zCmNIYV0XkoY3IXbWdHH8si NCfr9os+td/Wrowcn4UsLxEaeCUoL7m4iIaVHMLYxjd0KPqUmnusybGYFSVfvI5odLe3 thMrw6a2/mflnwqVDnlhG/sdZT4Y5C13MDKzHXcqsi9kvfE634QS90x8QysqPxD/XBUZ 7UfA== X-Gm-Message-State: AAQBX9dP72pL5UCdpI4++C18HQfXGaSmTWovDHUHsZqtPn/QywAq3brc 9Vy7RTckOydmU3O2tfN46PAyiwAPVMBETAqb2PQ= X-Google-Smtp-Source: AKy350b1SZF30NAgCFZTKwmJMUcQrcXyr9/jrIZtfK+O3svk8Y6UKfrzCPNcaSVUqBg12xcO5THBayYSFK/LW1Si8OY= X-Received: by 2002:a1f:5642:0:b0:43f:b997:beea with SMTP id k63-20020a1f5642000000b0043fb997beeamr4205406vkb.13.1682395812530; Mon, 24 Apr 2023 21:10:12 -0700 (PDT) MIME-Version: 1.0 References: <20230419095427.563185-1-sivaprasad.tummala@amd.com> <324d5201-da95-f926-5580-f74ca5c09799@amd.com> In-Reply-To: <324d5201-da95-f926-5580-f74ca5c09799@amd.com> From: Jerin Jacob Date: Tue, 25 Apr 2023 09:39:46 +0530 Message-ID: Subject: Re: [RFC PATCH 1/5] eventdev: add power monitoring API on event port To: Ferruh Yigit Cc: Sivaprasad Tummala , david.hunt@intel.com, jerinj@marvell.com, harry.van.haaren@intel.com, dev@dpdk.org, Pavan Nikhilesh , "McDaniel, Timothy" , Shijith Thotton , Hemant Agrawal , Sachin Saxena , =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , Peter Mccarthy , Liang Ma Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Mon, Apr 24, 2023 at 9:36=E2=80=AFPM Ferruh Yigit = wrote: > > On 4/19/2023 11:15 AM, Jerin Jacob wrote: > > On Wed, Apr 19, 2023 at 3:24=E2=80=AFPM Sivaprasad Tummala > > wrote: > >> > >> A new API to allow power monitoring condition on event port to > >> optimize power when no events are arriving on an event port for > >> the worker core to process in an eventdev based pipelined application. > >> > >> Signed-off-by: Sivaprasad Tummala > >> + * > >> + * @param dev_id > >> + * Eventdev id > >> + * @param port_id > >> + * Eventdev port id > >> + * @param pmc > >> + * The pointer to power-optimized monitoring condition structure. > >> + * > >> + * @return > >> + * - 0: Success. > >> + * -ENOTSUP: Operation not supported. > >> + * -EINVAL: Invalid parameters. > >> + * -ENODEV: Invalid device ID. > >> + */ > >> +__rte_experimental > >> +int > >> +rte_event_port_get_monitor_addr(uint8_t dev_id, uint8_t port_id, > >> + struct rte_power_monitor_cond *pmc); > > > > + eventdev driver maintainers > > > > I think, we don't need to expose this application due to applications > > 1)To make applications to be transparent whether power saving is enable= d or not? > > 2)Some HW and Arch already supports power managent in driver and in HW > > (Not using CPU architecture directly) > > > > If so, that will be translated to following, > > a) Add rte_event_port_power_saving_ena_dis(uint8_t dev_id, uint8_t > > port_id, bool ena) for controlling power saving in slowpath. > > b) Create reusable PMD private function based on the CPU architecture > > power saving primitive to cover the PMD don't have native power saving > > support. > > c)Update rte_event_dequeue_burst() burst of PMD callback to use (b). > > > > > > Hi Jerin, Hi Ferruh, > > ethdev approach seems applied here. Understands that. But none of the NIC HW supports power management at HW level like eventdev, so that way for what we are doing for ethdev is a correct abstraction for ethdev. > > In ethdev, 'rte_event_port_get_monitor_addr()' equivalent is > 'rte_eth_get_monitor_addr()'. > > Although 'rte_eth_get_monitor_addr()' is public API, it is currently > only called from Rx/Tx callback functions implemented in the power librar= y. > But I assume intention to make it public is to enable users to implement > their own callback functions that has custom algorithm for the power > management. If there is a use case for customizing with own callback, we can provide th= at. Provided NULL is valid with default algorithm. > > And probably same is true for the 'rte_event_port_get_monitor_addr()'. > > > Also instead of implementing power features for withing PMDs, isn't it > better to have a common eventdev layer for it? We can have rte_evetdev_pmd_* APIs as non-public APIs. My only objection is to NOT introduce _monitor_ APIs at eventdev level, Instead, _monitor_ is one way to do it in SW, So we need higher level of abstraction. > > For the PMDs benefit from HW event manager, just not implementing > .get_monitor_addr() dev_ops will make them free from power related APIs. But application fast path code gets diverged by exposing low level primitiv= es. > > > >