Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp2046556pxu; Tue, 24 Nov 2020 15:46:12 -0800 (PST) X-Google-Smtp-Source: ABdhPJypMQxgaDLD0R+uazX/7b+WQmVJICZaafRjHy2VDZ5Mxm4wKof0pkS7QoDwns4lEZdq99lK X-Received: by 2002:a17:906:f84f:: with SMTP id ks15mr751568ejb.337.1606261572635; Tue, 24 Nov 2020 15:46:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606261572; cv=none; d=google.com; s=arc-20160816; b=PnUcRPAsN2aqNQ+zZ3f/LDATuHSAC01zEndv4pNAonVKUvHp7v+zVCMXALMH2rVAe8 BRuS3T2/x7Jup3SSOwbsogdLl2M9/NtsdcmBq1rFkRyyXGFtjv0ol02k9Hl2drJ3iTqc UBKS5Kr7yHzx8y0qwEZIfuBWbTOGAb5k5Ay5R2Pvf3T8SnwnVss5WxleN/Ggy3nbCkrM auwkJgkFxGiHWBublVOBKQMP7o9xMQ25/31mK5BFpfqtqtKp/JQOZ4uGJwJHLpyXtC4V 1GPCGt/7oZZ2MAHX4CCP+TwLaX76XWcVV/1y3Nz2sjMjcLz998KQR5Syh32lzaCxV8jB zV3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version; bh=xTNng4Sls+2aq1edhseBskqFCVcvtP9sFZIewHsiDIU=; b=X44IsBDuIvZI4bI/l+G9ha3R4CgoC1vh6pPR73Y3zW+KcOmFjwL5ySzlmtWKPaqP+c sbIeZG6fPXKD/B4SDPqm4WEXkq2eTQ2VE2T4QdT92FxDDuuEmMcPqkHKsW3t+6XySwAm 67VKPvpg2BJnGEe8+2keMJgm2mrymkMtMzAiT8o0LgBCnhDeu2oqy+gJKD6tbGuTYjn3 WWuehTuDEAQCzE9McVntosjRTP0C5H8ieHpg8cMmjBv85Omm9evsQp6AlnU2dLumLvhe 17H2ptTV81tg0dATInwRjZhceDtslAUdD7BMYIhtP8ObhB8gWTr7TwZdwnlXiC672Xlg 6qCw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id go10si204846ejc.656.2020.11.24.15.45.49; Tue, 24 Nov 2020 15:46:12 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390751AbgKXRRh convert rfc822-to-8bit (ORCPT + 99 others); Tue, 24 Nov 2020 12:17:37 -0500 Received: from youngberry.canonical.com ([91.189.89.112]:33465 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390245AbgKXRRg (ORCPT ); Tue, 24 Nov 2020 12:17:36 -0500 Received: from mail-pg1-f200.google.com ([209.85.215.200]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1khbwc-00011n-0P for linux-kernel@vger.kernel.org; Tue, 24 Nov 2020 17:17:34 +0000 Received: by mail-pg1-f200.google.com with SMTP id t1so15469911pgo.23 for ; Tue, 24 Nov 2020 09:17:33 -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:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VRMiJUNLgr9M7h46m/eHssvcueu9oqfWJ7ck5ke8IpY=; b=b0wENxHmK7sYoTbBvC8SynRN7mo7UNvaFq/xAZXU1XjqV8QBzokJhau4ZSDgSvsTtK al9RWluiGMlDK3ChAus5qJdXVUtvFZKYB7lGfkX9GeTn8TDsagQyxrGPjd4Z+BJk9YAD 4N2x1mh/ErEyjZYVxJWvNgHFQ6L0r+HddqN71dazBahBcelp3Z8ASfkUlvIqL5BDy1Dj ICKTrkcWX9rysEc2OYoni/5IdWEqb4sDNob1Z7mAhmjO1LlT3iLrKMjrwWw4wo+pwkxB JY+QDYFblpk6GxdEdGalCbJlQR3O/8mmK5V34L5MtXW6nzeNeRP1AdtEcg+zgCnNKi8K 8/Ig== X-Gm-Message-State: AOAM533CFYVUSM/GnG02RU41BU8hwagAwBdxyLMjjZobBh54Lolql6Lt SV9x8p56DYl9ORcaVSx1dX5Rr4zQxgSLlz9LthnHoyZ+EzVrfFqwyOeqNM5WjFH8GsgfVL/F7mC batUcdlEGuFUFxZ7qJ0tj6bMSKmOlfA/+VQkDgSzr9A== X-Received: by 2002:a05:6a00:794:b029:197:e418:ac4d with SMTP id g20-20020a056a000794b0290197e418ac4dmr4887488pfu.47.1606238252494; Tue, 24 Nov 2020 09:17:32 -0800 (PST) X-Received: by 2002:a05:6a00:794:b029:197:e418:ac4d with SMTP id g20-20020a056a000794b0290197e418ac4dmr4887455pfu.47.1606238252111; Tue, 24 Nov 2020 09:17:32 -0800 (PST) Received: from [192.168.1.208] (220-133-187-190.HINET-IP.hinet.net. [220.133.187.190]) by smtp.gmail.com with ESMTPSA id o132sm14969443pfg.100.2020.11.24.09.17.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Nov 2020 09:17:31 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) Subject: Re: [PATCH] e1000e: Assign DPM_FLAG_SMART_SUSPEND and DPM_FLAG_MAY_SKIP_RESUME to speed up s2ram From: Kai-Heng Feng In-Reply-To: <20201124153221.11265-1-yu.c.chen@intel.com> Date: Wed, 25 Nov 2020 01:17:28 +0800 Cc: "Rafael J. Wysocki" , Len Brown , Tony Nguyen , Jesse Brandeburg , "moderated list:INTEL ETHERNET DRIVERS" , Linux PM list , open list , Sasha Neftin , Jeff Kirsher Content-Transfer-Encoding: 8BIT Message-Id: <8BA4D1E1-DACF-4E84-A5B8-75A7CEA65F98@canonical.com> References: <20201124153221.11265-1-yu.c.chen@intel.com> To: Chen Yu X-Mailer: Apple Mail (2.3654.20.0.2.21) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Yu, > On Nov 24, 2020, at 23:32, Chen Yu wrote: > > The NIC is put in runtime suspend status when there is no wire connected. > As a result, it is safe to keep this NIC in runtime suspended during s2ram > because the system does not rely on the NIC plug event nor WOL to wake up > the system. Unlike the s2idle, s2ram does not need to manipulate S0ix settings > during suspend. Please see below for the reason why I explicitly disable direct-complete in the driver. > > This patch assigns DPM_FLAG_SMART_SUSPEND and DPM_FLAG_MAY_SKIP_RESUME > to the e1000e driver so that the s2ram could skip the .suspend_late(), > .suspend_noirq() and .resume_noirq() .resume_early() when possible. > Also skip .suspend() and .resume() if dev_pm_skip_suspend() and > dev_pm_skip_resume() return true, so as to speed up the s2ram. If we really want direct-complete here, maybe always set current WoL setting in runtime suspend routine? > > Signed-off-by: Chen Yu > --- > drivers/base/power/main.c | 2 ++ > drivers/net/ethernet/intel/e1000e/netdev.c | 14 +++++++++++++- > 2 files changed, 15 insertions(+), 1 deletion(-) > > diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c > index c7ac49042cee..9cd8abba8612 100644 > --- a/drivers/base/power/main.c > +++ b/drivers/base/power/main.c > @@ -580,6 +580,7 @@ bool dev_pm_skip_resume(struct device *dev) > > return !dev->power.must_resume; > } > +EXPORT_SYMBOL_GPL(dev_pm_skip_resume); I don't think it's a good idea to use this predicate out side of PM core, must_resume may change during suspend process. > > /** > * device_resume_noirq - Execute a "noirq resume" callback for given device. > @@ -2010,3 +2011,4 @@ bool dev_pm_skip_suspend(struct device *dev) > return dev_pm_test_driver_flags(dev, DPM_FLAG_SMART_SUSPEND) && > pm_runtime_status_suspended(dev); > } > +EXPORT_SYMBOL_GPL(dev_pm_skip_suspend); > diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c > index b30f00891c03..d79fddabc553 100644 > --- a/drivers/net/ethernet/intel/e1000e/netdev.c > +++ b/drivers/net/ethernet/intel/e1000e/netdev.c > @@ -6965,6 +6965,14 @@ static __maybe_unused int e1000e_pm_suspend(struct device *dev) > struct e1000_hw *hw = &adapter->hw; > int rc; > > + /* Runtime suspended means that there is no wired connection > + * and it has nothing to do with WOL that, we don't need to > + * adjust the WOL settings. So it is safe to put NIC in > + * runtime suspend while doing system suspend. > + */ What about plugging ethernet cable and using WoL after system is suspended? Commit "e1000e: Exclude device from suspend direct complete optimization" was to address that scenario. > + if (dev_pm_skip_suspend(dev)) > + return 0; > + > e1000e_flush_lpic(pdev); > > e1000e_pm_freeze(dev); > @@ -6989,6 +6997,9 @@ static __maybe_unused int e1000e_pm_resume(struct device *dev) > struct e1000_hw *hw = &adapter->hw; > int rc; > > + if (dev_pm_skip_resume(dev)) > + return 0; > + > /* Introduce S0ix implementation */ > if (hw->mac.type >= e1000_pch_cnp && > !e1000e_check_me(hw->adapter->pdev->device)) > @@ -7665,7 +7676,8 @@ static int e1000_probe(struct pci_dev *pdev, const struct pci_device_id *ent) > > e1000_print_device_info(adapter); > > - dev_pm_set_driver_flags(&pdev->dev, DPM_FLAG_NO_DIRECT_COMPLETE); > + dev_pm_set_driver_flags(&pdev->dev, DPM_FLAG_NO_DIRECT_COMPLETE | > + DPM_FLAG_SMART_SUSPEND | DPM_FLAG_MAY_SKIP_RESUME); > > if (pci_dev_run_wake(pdev) && hw->mac.type < e1000_pch_cnp) > pm_runtime_put_noidle(&pdev->dev); Also, most e1000e device on modern platforms doesn't runtime suspend at all after commit "e1000e: Disable runtime PM on CNP+". Kai-Heng > -- > 2.25.1 >