netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Heiner Kallweit <hkallweit1@gmail.com>
Cc: Frederick Lawler <fred@fredlawl.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	David Miller <davem@davemloft.net>,
	Realtek linux nic maintainers <nic_swsd@realtek.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Rajat Jain <rajatja@google.com>
Subject: Re: [PATCH net] r8169: switch off ASPM by default and add sysfs attribute to control ASPM
Date: Fri, 5 Apr 2019 14:10:24 -0500	[thread overview]
Message-ID: <20190405191024.GD26522@google.com> (raw)
In-Reply-To: <b8787012-0928-e613-bbf6-4de3e462f055@gmail.com>

On Wed, Apr 03, 2019 at 07:45:29PM +0200, Heiner Kallweit wrote:
> On 03.04.2019 15:14, Bjorn Helgaas wrote:
> > On Wed, Apr 03, 2019 at 07:53:40AM +0200, Heiner Kallweit wrote:
> >> On 02.04.2019 23:57, Bjorn Helgaas wrote:
> >>> On Tue, Apr 02, 2019 at 10:41:20PM +0200, Heiner Kallweit wrote:
> >>>> On 02.04.2019 22:16, Florian Fainelli wrote:
> >>>>> On 4/2/19 12:55 PM, Heiner Kallweit wrote:
> >>>>>> There are numerous reports about different problems caused by
> >>>>>> ASPM incompatibilities between certain network chip versions
> >>>>>> and board chipsets. On the other hand on (especially mobile)
> >>>>>> systems where ASPM works properly it can significantly
> >>>>>> contribute to power-saving and increased battery runtime.
> >>>>>> One problem so far to make ASPM configurable was to find an
> >>>>>> acceptable way of configuration (e.g. module parameters are
> >>>>>> discouraged for that purpose).

> >>>>>> +Certain combinations of network chip versions and board
> >>>>>> +chipsets result in increased packet latency, PCIe errors, or
> >>>>>> +significantly reduced network performance. Therefore ASPM is
> >>>>>> +off by default. On the other hand ASPM can significantly
> >>>>>> +contribute to power-saving and thus increased battery runtime
> >>>>>> +on notebooks.

> > That said, I think Frederick has already started working on a plan
> > for the PCI core to expose sysfs files to manage ASPM.  This is
> > similar to the link_state files enabled by CONFIG_PCIEASPM_DEBUG,
> > but it will be always enabled and probably structured slightly
> > differently.  The idea is that this would be generic and would not
> > require any driver support.

> Frederick, is there anything you could share already? Or any timeline?
> Based on Bjorns info what seems to be best to me:
> 1. Disable ASPM for r8169 on stable (back to 4.19).
> 2. Once the generic ASPM sysfs attributes are available, reenable ASPM
>    for r8169 in net-next.

This is out of my wheelhouse, but even with a generic sysfs knob, it
doesn't sound like a good idea to me to enable ASPM by default for
r8169 if we think it's unreliable on any significant fraction of
machines.

Users of those unreliable machines will see poor performance, PCIe
errors, etc, and they won't have a clue about how to fix them.

To me it sounds better to leave ASPM disabled by default for r8169,
then incrementally whitelist systems that are known to work.  Users
will have poor battery life, but at least things will work reliably.

Bjorn

  parent reply	other threads:[~2019-04-05 19:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-02 19:55 [PATCH net] r8169: switch off ASPM by default and add sysfs attribute to control ASPM Heiner Kallweit
2019-04-02 20:16 ` Florian Fainelli
2019-04-02 20:41   ` Heiner Kallweit
2019-04-02 21:08     ` Rajat Jain
2019-04-02 21:25       ` Heiner Kallweit
2019-04-02 21:57     ` Bjorn Helgaas
2019-04-03  5:53       ` Heiner Kallweit
2019-04-03 13:14         ` Bjorn Helgaas
2019-04-03 17:45           ` Heiner Kallweit
2019-04-03 19:18             ` Frederick Lawler
2019-04-03 20:10               ` Heiner Kallweit
2019-04-05 19:10             ` Bjorn Helgaas [this message]
2019-04-05 19:28               ` Heiner Kallweit
2019-04-09 17:32                 ` Heiner Kallweit
2019-04-09 18:20                   ` Bjorn Helgaas
2019-04-09 18:27                     ` Heiner Kallweit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190405191024.GD26522@google.com \
    --to=helgaas@kernel.org \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=fred@fredlawl.com \
    --cc=hkallweit1@gmail.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nic_swsd@realtek.com \
    --cc=rajatja@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).