On 30.03.2019 19:06, David Miller wrote: > From: Heiner Kallweit <hkallwe...@gmail.com> > Date: Sat, 30 Mar 2019 17:13:24 +0100 > >> It was reported that re-introducing ASPM, in combination with RX >> interrupt coalescing, results in significantly increased packet >> latency, see [0]. Disabling ASPM or RX interrupt coalescing fixes >> the issue. Therefore change the driver's default to disable RX >> interrupt coalescing. Users still have the option to enable RX >> coalescing via ethtool. >> >> [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925496 >> >> Fixes: a99790bf5c7f ("r8169: Reinstate ASPM Support") >> Reported-by: Mike Crowe <m...@mcrowe.com> >> Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> > > Applied and queued up for -stable. > > Frankly, I think we were better off with ASPM disabled. But I know > a lot of people find that unacceptable. > Yes, I can hear the notebook owners scream already, and complain about reduced battery runtime. It would help to have an opt-in option for ASPM. But a module parameter for it is discouraged, and I see no other acceptable way to control ASPM on the chip side. I could misuse some ethtool callback or add a new tunable. But controlling a PCI feature through ethtool doesn't sound too nice. Maybe I could add a sysfs attribute.
> This chip has some many quirks/warts when ASPM is enabled, look how > long it took us to A) get ASPM enabled reasonably and B) discover > this bug. >
