netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oleksij Rempel <o.rempel@pengutronix.de>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: Richard Cochran <richardcochran@gmail.com>,
	Woojung Huh <woojung.huh@microchip.com>,
	Andrew Lunn <andrew@lunn.ch>,
	Arun.Ramadoss@microchip.com,
	Florian Fainelli <f.fainelli@gmail.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>, Wei Fang <wei.fang@nxp.com>,
	kernel@pengutronix.de, intel-wired-lan@lists.osuosl.org,
	Jakub Kicinski <kuba@kernel.org>,
	UNGLinuxDriver@microchip.com,
	"David S. Miller" <davem@davemloft.net>,
	Heiner Kallweit <hkallweit1@gmail.com>
Subject: Re: [PATCH net-next v4 00/23] net: add EEE support for KSZ9477 and AR8035 with i.MX6
Date: Mon, 6 Feb 2023 19:25:27 +0100	[thread overview]
Message-ID: <20230206182527.GG12366@pengutronix.de> (raw)
In-Reply-To: <20230206141038.vp5pdkjyco6pyosl@skbuf>

On Mon, Feb 06, 2023 at 04:10:38PM +0200, Vladimir Oltean wrote:
> On Mon, Feb 06, 2023 at 06:47:13AM +0100, Oleksij Rempel wrote:
> > On Sat, Feb 04, 2023 at 02:13:32AM +0200, Vladimir Oltean wrote:
> > > On Wed, Feb 01, 2023 at 03:58:22PM +0100, Oleksij Rempel wrote:
> > > > With this patch series we provide EEE control for KSZ9477 family of switches and
> > > > AR8035 with i.MX6 configuration.
> > > > According to my tests, on a system with KSZ8563 switch and 100Mbit idle link,
> > > > we consume 0,192W less power per port if EEE is enabled.
> > > 
> > > What is the code flow through the kernel with EEE? I wasn't able to find
> > > a good explanation about it.
> > > 
> > > Is it advertised by default, if supported? I guess phy_advertise_supported()
> > > does that.
> > 
> > Ack.
> > 
> > > But is that desirable? Doesn't EEE cause undesired latency for MAC-level
> > > PTP timestamping on an otherwise idle link?
> > 
> > Theoretically, MAC controls Low Power Idle states and even with some
> > "Wake" latency should be fully aware of actual ingress and egress time
> > stamps.
> 
> I'm not sure if this is also true with Atheros SmartEEE, where the PHY
> is the one who enters LPI mode and buffers packets until it wakes up?

Yes, you right. With SmartEEE without MAC assistance, PTP will be
broken. At the same time, if MAC is PTP and EEE capable, the same PHY
with SmartEEE disabled should work just fine.

> > Practically, right now I do not have such HW to confirm it. My project
> > is affected by EEE in different ways:
> 
> Doesn't FEC support PTP?

FEC do supports PTP, but do not support EEE on i.MX6/7 variants.

> > - with EEE PTP has too much jitter
> > - without EEE, the devices consumes too much power in standby mode with
> >   WoL enabled. Even switching to 10BaseT less power as 100BaseTX with
> >   EEE would do.
> > 
> > My view is probably biased by my environment - PTP is relatively rare
> > use case. EEE saves power (0,2W+0,2W per link in my case). Summary power
> > saving of all devices is potentially equal to X amount of power plants. 
> > So, EEE should be enabled by default.
> 
> I'm not contesting the value of EEE. Just wondering whether it's best
> for the kernel, rather than user space, to enable it by default.

I woulds say, at the end the switch will decide what functionality will
be advertised. Other nodes should just tell what capabilities they
support.

> > 
> > Beside, flow control (enabled by default) affects PTP in some cases too.
> 
> You are probably talking about the fact that flow control may affect
> end-to-end delay measurements (across switches in a LAN). Yes, but EEE
> (or at least SmartEEE) may affect peer-to-peer delay measurements, which
> I see as worse.

I agree. User space should be notified some how about SmartEEE
functionality. Especially if it is incompatible with some other
functionality like PTP. It took me some time to understand why my PTP sync was
so unstable. SmartEEE was just silently enabled by HW and no EEE related
information was provided to user space.

> > May be ptp4l should warn about this options? We should be able to detect
> > it from user space.
> 
> This isn't necessarily a bad idea, even though it would end up
> renegotiating and losing the link.

My idea was to inform the user, not actively do what ever is needed. It
can conflict with other services or make system administrator scratch the
head without understanding why things magically happen.

> Maybe it would be good to drag Richard Cochran into the discussion too.
> After all he's the one who should agree what should and what shouldn't
> ptp4l be concerned with.

ACK.

Regards,
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

      parent reply	other threads:[~2023-02-06 18:25 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-01 14:58 [PATCH net-next v4 00/23] net: add EEE support for KSZ9477 and AR8035 with i.MX6 Oleksij Rempel
2023-02-01 14:58 ` [PATCH net-next v4 01/23] net: dsa: microchip: enable EEE support Oleksij Rempel
2023-02-04  0:14   ` Vladimir Oltean
2023-02-01 14:58 ` [PATCH net-next v4 02/23] net: phy: add genphy_c45_read_eee_abilities() function Oleksij Rempel
2023-02-01 17:12   ` Andrew Lunn
2023-02-04  0:54   ` Vladimir Oltean
2023-02-06 10:49     ` Oleksij Rempel
2023-02-06 11:22       ` Vladimir Oltean
2023-02-06 15:42         ` Andrew Lunn
2023-02-01 14:58 ` [PATCH net-next v4 03/23] net: phy: micrel: add ksz9477_get_features() Oleksij Rempel
2023-02-01 14:58 ` [PATCH net-next v4 04/23] net: phy: export phy_check_valid() function Oleksij Rempel
2023-02-01 17:15   ` Andrew Lunn
2023-02-01 14:58 ` [PATCH net-next v4 05/23] net: phy: add genphy_c45_ethtool_get/set_eee() support Oleksij Rempel
2023-02-01 17:20   ` Andrew Lunn
2023-02-01 20:18   ` Jakub Kicinski
2023-02-04  1:11   ` Vladimir Oltean
2023-02-01 14:58 ` [PATCH net-next v4 06/23] net: phy: c22: migrate to genphy_c45_write_eee_adv() Oleksij Rempel
2023-02-01 17:28   ` Andrew Lunn
2023-02-01 14:58 ` [PATCH net-next v4 07/23] net: phy: c45: " Oleksij Rempel
2023-02-01 14:58 ` [PATCH net-next v4 08/23] net: phy: migrate phy_init_eee() to genphy_c45_eee_is_active() Oleksij Rempel
2023-02-01 16:41   ` Andrew Lunn
2023-02-01 14:58 ` [PATCH net-next v4 09/23] net: phy: start using genphy_c45_ethtool_get/set_eee() Oleksij Rempel
2023-02-01 14:58 ` [PATCH net-next v4 10/23] net: phy: add driver specific get/set_eee support Oleksij Rempel
2023-02-01 14:58 ` [PATCH net-next v4 11/23] net: phy: at803x: implement ethtool access to SmartEEE functionality Oleksij Rempel
2023-02-01 14:58 ` [PATCH net-next v4 12/23] net: phy: at803x: ar8035: fix EEE support for half duplex links Oleksij Rempel
2023-02-01 14:58 ` [PATCH net-next v4 13/23] net: phy: add PHY specifica flag to signal SmartEEE support Oleksij Rempel
2023-02-01 14:58 ` [PATCH net-next v4 14/23] net: phy: at803x: add PHY_SMART_EEE flag to AR8035 Oleksij Rempel
2023-02-01 14:58 ` [PATCH net-next v4 15/23] net: phy: add phy_has_smarteee() helper Oleksij Rempel
2023-02-01 14:58 ` [PATCH net-next v4 16/23] net: fec: add support for PHYs with SmartEEE support Oleksij Rempel
2023-02-01 14:58 ` [PATCH net-next v4 17/23] e1000e: replace EEE ethtool helpers to linkmode variants Oleksij Rempel
2023-02-01 14:58 ` [PATCH net-next v4 18/23] igb: " Oleksij Rempel
2023-02-01 14:58 ` [PATCH net-next v4 19/23] igc: " Oleksij Rempel
2023-02-01 14:58 ` [PATCH net-next v4 20/23] tg3: " Oleksij Rempel
2023-02-01 14:58 ` [PATCH net-next v4 21/23] r8152: " Oleksij Rempel
2023-02-01 14:58 ` [PATCH net-next v4 22/23] net: usb: ax88179_178a: " Oleksij Rempel
2023-02-01 14:58 ` [PATCH net-next v4 23/23] net: mdio: drop EEE ethtool helpers in favor " Oleksij Rempel
2023-02-04  0:13 ` [PATCH net-next v4 00/23] net: add EEE support for KSZ9477 and AR8035 with i.MX6 Vladimir Oltean
2023-02-06  5:47   ` Oleksij Rempel
2023-02-06 14:10     ` Vladimir Oltean
2023-02-06 15:39       ` Andrew Lunn
2023-02-06 18:37         ` Oleksij Rempel
2023-02-06 20:21           ` Andrew Lunn
2023-02-06 18:25       ` Oleksij Rempel [this message]

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=20230206182527.GG12366@pengutronix.de \
    --to=o.rempel@pengutronix.de \
    --cc=Arun.Ramadoss@microchip.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=kernel@pengutronix.de \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=richardcochran@gmail.com \
    --cc=vivien.didelot@gmail.com \
    --cc=wei.fang@nxp.com \
    --cc=woojung.huh@microchip.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).