From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id B588FA04DD; Wed, 28 Oct 2020 18:02:24 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 350A25928; Wed, 28 Oct 2020 18:02:23 +0100 (CET) Received: from mail-oi1-f193.google.com (mail-oi1-f193.google.com [209.85.167.193]) by dpdk.org (Postfix) with ESMTP id 6F80556A3 for ; Wed, 28 Oct 2020 18:02:21 +0100 (CET) Received: by mail-oi1-f193.google.com with SMTP id k65so251659oih.8 for ; Wed, 28 Oct 2020 10:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UuvNYtZZ3k3IK7551ktTN/PrnP1JjSR0RoUDPNhCcTU=; b=UUkCmqZacUUdZaXesxjitzrf/16vMNvlCzSk0/5OEUt6U50SSnJ9v4DZwueIYssLG+ W0/TUPl3USgsxB28393xq4oi/OK58+w+JOJm9krd3zbM18wjOu5ExAAn8QBM4INnmFvz tdlDDiDZxbMABTRThFljmtg/BS2So+mmV90Mo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UuvNYtZZ3k3IK7551ktTN/PrnP1JjSR0RoUDPNhCcTU=; b=d1ooK5ZyuOAXsbJRZ98rvvd8QYBeKvWRN1PrStEcwkhR4+eTU1hl6ctCLzsyxYSvLE ZBPUGF7Ln5S6RYRs6nmsgeKEY1iJADWhyJdQ90N3oTOCkM28AZ1IZex4D4cON8fwHAlW OnCYrOCbolX9xRsQykpiRojik7MRFS/xoRsDCUQ3tdoCbSxUY6tC1JjypaJEObXC0Rs5 VpKOXOjR7ZY9LDR17rd4q/OO/KYhSyaKUYIhjun7dm1SWnSB64fHUOyBdxYsXyjZQnE8 UtNGS7I7mst0L1efiA7yLPf/x5eKl4VynA7JKGT225SB1OSkVl1ytLyr9MynXt2fF3dy 5Png== X-Gm-Message-State: AOAM531w6Fz2hrZysgcrnsP7nl7hV1G1LdlLKbYtVcBvix3Cj+hQW6YI Gs5JeNduIVbJ2pC7b4x7VWku7He7YF/XrZi9a1DlWw== X-Google-Smtp-Source: ABdhPJxKIjlLD926EAeTaMsG7iwW+H9ntW5/rGqdgoTzD8X4h8BC+03ciF3n5Z9tE1CCz2R1WIjJnAKFDg6IPSofzv0= X-Received: by 2002:aca:d447:: with SMTP id l68mr261617oig.168.1603904539230; Wed, 28 Oct 2020 10:02:19 -0700 (PDT) MIME-Version: 1.0 References: <1603494392-7181-1-git-send-email-liang.j.ma@intel.com> <20201028133507.GC29706@sivswdev09.ir.intel.com> <2373759.1G5EZAqFcn@thomas> <20201028164735.GG29706@sivswdev09.ir.intel.com> In-Reply-To: <20201028164735.GG29706@sivswdev09.ir.intel.com> From: Ajit Khaparde Date: Wed, 28 Oct 2020 10:02:03 -0700 Message-ID: To: "Liang, Ma" Cc: Jerin Jacob , "Ananyev, Konstantin" , Thomas Monjalon , dpdk-dev , "Ruifeng Wang (Arm Technology China)" , "Wang, Haiyue" , "Richardson, Bruce" , "Hunt, David" , Neil Horman , "McDaniel, Timothy" , "Eads, Gage" , Marcin Wojtas , Guy Tzalik , Harman Kalra , John Daley , "Wei Hu (Xavier" , Ziyang Xuan , "matan@nvidia.com" , Yong Wang , "david.marchand@redhat.com" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v10 0/9] Add PMD power mgmt X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, Oct 28, 2020 at 9:47 AM Liang, Ma wrote: > > On 28 Oct 21:27, Jerin Jacob wrote: > > On Wed, Oct 28, 2020 at 9:19 PM Ananyev, Konstantin > > wrote: > > > > > > > > 28/10/2020 14:49, Jerin Jacob: > > > > > > > > > On Wed, Oct 28, 2020 at 7:05 PM Liang, Ma wrote: > > > > > > > > > > > > > > > > > > > > Hi Thomas, > > > > > > > > > > I think I addressed all of the questions in relation to V9. I don't think I can solve the issue of a generic API on my own. From the > > > > > > > > Community Call last week Jerin also said that a generic was investigated but that a single solution wasn't feasible. > > > > > > > > > > > > > > > > > > I think, From the architecture point of view, the specific > > > > > > > > > functionally of UMONITOR may not be abstracted. > > > > > > > > > But from the ethdev callback point of view, Can it be abstracted in > > > > > > > > > such a way that packet notification available through > > > > > > > > > checking interrupt status register or ring descriptor location, etc by > > > > > > > > > the driver. Use that callback as a notification mechanism rather > > > > > > > > > than defining a memory-based scheme that UMONITOR expects? or similar > > > > > > > > > thoughts on abstraction. > > > > > > > > > > > > > > I think there is probably some sort of misunderstanding. > > > > > > > This API is not about providing acync notification when next packet arrives. > > > > > > > This is about to putting core to sleep till some event (or timeout) happens. > > > > > > > From my perspective the closest analogy: cond_timedwait(). > > > > > > > So we need PMD to tell us what will be the address of the condition variable > > > > > > > we should sleep on. > > > > > > > > > > > > > > > I agree with Jerin. > > > > > > > > The ethdev API is the blocking problem. > > > > > > > > First problem: it is not well explained in doxygen. > > > > > > > > Second problem: it is probably not generic enough (if we understand it well) > > > > > > > > > > > > > > It is an address to sleep(/wakeup) on, plus expected value. > > > > > > > Honestly, I can't think-up of anything even more generic then that. > > > > > > > If you guys have something particular in mind - please share. > > > > > > > > > > > > Current PMD callback: > > > > > > typedef int (*eth_get_wake_addr_t)(void *rxq, volatile void > > > > > > **tail_desc_addr, + uint64_t *expected, uint64_t *mask, uint8_t > > > > > > *data_sz); > > > > > > > > > > > > Can we make it as > > > > > > typedef void (*core_sleep_t)(void *rxq) > > > > > > > > > > > > if we do such abstraction and "move the polling on memory by HW/CPU" > > > > > > to the driver using a helper function then > > > > > > I can think of abstracting in some way in all PMDs. > > > > > > > > > > Ok I see, thanks for explanation. > > > > > From my perspective main disadvantage of such approach - > > > > > it can't be extended easily. > > > > > If/when will have an ability for core to sleep/wake-up on multiple events > > > > > (multiple addresses) will have to either rework that API again. > > > > > > > > I think, we can enumerate the policies and pass the associated > > > > structures as input to the driver. > > > > > > What I am trying to say: with that API we will not be able to wait > > > for events from multiple devices (HW queues). > > > I.E. something like that: > > > > > > get_wake_addr(port=X, ..., &addr[0], ...); > > > get_wake_addr(port=Y,..., &addr[1],...); > > > wait_on_multi(addr, 2); > > > > > > wouldn't be possible. > > > > I see. But the current implementation dictates the only queue bound to > > a core. Right? > Current implementation only support 1:1 queue/core mapping is because of > the limitation of umwait/umonitor which can not work with multiple address > range. However, for other scheme like PASUE/Freq Scale have no such limitation. > The proposed API itself doesn't limit the 1:1 queue/core mapping. The PMD would not know if it is 1:1 queue/core or any other shared scheme. So the intelligence and decision making is best left to the application. I think PMD and the underlying hardware does not need to know what kind of power management scheme is implemented. IMHO the original API which provides the address, value and mask should suffice. Any other callback or handshake between PMD and application may be an overkill. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Note: core_sleep_t can take some more arguments such as enumerated > > > > > > policy if something more needs to be pushed to the driver. > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This API is experimental and other vendor support can be added as needed. If there are any other open issue let me know? > > > > > > > > > > > > > > > > Being experimental is not an excuse to throw something > > > > > > > > which is not satisfying. > > > > > > > > > > > > > > > > > > > > > > >