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 2EC04A04B5; Mon, 11 Jan 2021 09:44:29 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E5D5E140CBB; Mon, 11 Jan 2021 09:44:28 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mails.dpdk.org (Postfix) with ESMTP id C9205140CB8 for ; Mon, 11 Jan 2021 09:44:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1610354666; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Mbi00mGAwHoNWzfPkQkb+G97KyY0yDYeVuzmW5Ft0Rs=; b=UxupPzI2rbgwuYIvDYyDpwHzOwU9S37uZZJgnJbEXAJh4Cj/G6REJ7vW77YwOntBdXvr84 4R6lhxgNxx8bxg+K19WoC9bjsTC0Mny+Arb34XEx8gDFB5wIBIUO9MpOBZ6kc1jujOqoMy HggrJ+PW/OAz5Wj02Ifq2h1GvX5jE/A= Received: from mail-vs1-f72.google.com (mail-vs1-f72.google.com [209.85.217.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-338-Td3rUtmvPh2R5PTVv5UjLw-1; Mon, 11 Jan 2021 03:44:22 -0500 X-MC-Unique: Td3rUtmvPh2R5PTVv5UjLw-1 Received: by mail-vs1-f72.google.com with SMTP id y12so4309461vsq.21 for ; Mon, 11 Jan 2021 00:44:22 -0800 (PST) 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=Mbi00mGAwHoNWzfPkQkb+G97KyY0yDYeVuzmW5Ft0Rs=; b=WqbV4Zknad7vonwnnaNclLQaMFDh7Y7wlGowaCwKpjUW7/TZ6/nRgnb5sJRU+e/ZPw kAPPh7HqaTBJMIud7z565jgv9hT9AMw9oeGwheBJv444aFneTzGWWYNMYrTf93PvGXvQ Zk+RCYKlWJa5y2fGa4jyMKdYa5yDVYFPBq/z4v+cY/DXbH4EgjbEztlkDu+XAdhcvXS2 MWqbz6XGqGa33/nXh4Vle+h/YR5UNMlHs2AAkzWfaC4OXjogp/LS9UH7ULdNqXv2tLI+ zGoohTdyzLvuI7Y4OnKd4Y4/oH/F+IgSLPiz4P9VB5Be3qqmGxJimPXwhTEWRimn70tm ApLw== X-Gm-Message-State: AOAM531Sb7jCoUccOkPnsBVH783E705cTNEW3lb0Vq+Ahx7fmTRW17RQ 7TlyONBkrdmz+psnaR1HhMwZ7bpa3TCczALRmpN2GglWCaKn4acHSPRAZ9KoxDBrxASATO9qy6N HmRkKH4ODpbkR9MZlRfU= X-Received: by 2002:a1f:cec1:: with SMTP id e184mr12050934vkg.17.1610354662104; Mon, 11 Jan 2021 00:44:22 -0800 (PST) X-Google-Smtp-Source: ABdhPJyXHu7ZSIxHigqk0mTPqUtzjD6/pJFATHqvWlLh0TG+aixus4jlyqCZRbm3OpdCCRBnicIuaqCbyhgvCFTkdMM= X-Received: by 2002:a1f:cec1:: with SMTP id e184mr12050923vkg.17.1610354661901; Mon, 11 Jan 2021 00:44:21 -0800 (PST) MIME-Version: 1.0 References: <1604315406-27669-1-git-send-email-liang.j.ma@intel.com> In-Reply-To: From: David Marchand Date: Mon, 11 Jan 2021 09:44:10 +0100 Message-ID: To: "Burakov, Anatoly" Cc: dev , Thomas Monjalon , "Ananyev, Konstantin" , Gage Eads , Timothy McDaniel , David Hunt , Bruce Richardson , chris.macnamara@intel.com, Ray Kinsella , "Yigit, Ferruh" Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v12 00/11] Add PMD power management 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 Sender: "dev" On Fri, Jan 8, 2021 at 5:42 PM Burakov, Anatoly wrote: > > On 17-Dec-20 4:12 PM, David Marchand wrote: > > On Thu, Dec 17, 2020 at 3:06 PM Anatoly Burakov > > wrote: > >> > >> This patchset proposes a simple API for Ethernet drivers to cause the > >> CPU to enter a power-optimized state while waiting for packets to > >> arrive. This is achieved through cooperation with the NIC driver that > >> will allow us to know address of wake up event, and wait for writes on > >> it. > >> > >> On IA, this is achieved through using UMONITOR/UMWAIT instructions. They > >> are used in their raw opcode form because there is no widespread > >> compiler support for them yet. Still, the API is made generic enough to > >> hopefully support other architectures, if they happen to implement > >> similar instructions. > >> > >> To achieve power savings, there is a very simple mechanism used: we're > >> counting empty polls, and if a certain threshold is reached, we get the > >> address of next RX ring descriptor from the NIC driver, arm the > >> monitoring hardware, and enter a power-optimized state. We will then > >> wake up when either a timeout happens, or a write happens (or generally > >> whenever CPU feels like waking up - this is platform-specific), and > >> proceed as normal. The empty poll counter is reset whenever we actually > >> get packets, so we only go to sleep when we know nothing is going on. > >> The mechanism is generic which can be used for any write back > >> descriptor. > >> > >> This patchset also introduces a few changes into existing power > >> management-related intrinsics, namely to provide a native way of waking > >> up a sleeping core without application being responsible for it, as well > >> as general robustness improvements. There's quite a bit of locking going > >> on, but these locks are per-thread and very little (if any) contention > >> is expected, so the performance impact shouldn't be that bad (and in any > >> case the locking happens when we're about to sleep anyway, not on a > >> hotpath). > >> > >> Why are we putting it into ethdev as opposed to leaving this up to the > >> application? Our customers specifically requested a way to do it wit > >> minimal changes to the application code. The current approach allows to > >> just flip a switch and automatically have power savings. > >> > >> - Only 1:1 core to queue mapping is supported, meaning that each lcore > >> must at most handle RX on a single queue > >> - Support 3 type policies. Monitor/Pause/Frequency Scaling > >> - Power management is enabled per-queue > >> - The API doesn't extend to other device types > > > > Fyi, ovsrobot Travis being KO, you probably missed that GHA CI caught this: > > https://github.com/ovsrobot/dpdk/runs/1571056574?check_suite_focus=true#step:13:16082 > > > > We will have to put an exception on driver only ABI. > > > > > > Why does aarch64 build fail there? The functions in question are in the > version map file, but the build complains that they aren't. >From what I can see, this series puts rte_power_* symbols in a .h. So it will be seen as symbols exported by any library including such a header. The check then complains about this as it sees exported symbols unknown of the library version.map. -- David Marchand