From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A6823C636D3 for ; Mon, 6 Feb 2023 19:56:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 226E1402B5; Mon, 6 Feb 2023 19:56:45 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 226E1402B5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osuosl.org; s=default; t=1675713405; bh=q4C3R0SUhN6gd7AbggrXx+HLn10iW8gY48d24Emzk78=; h=Date:From:To:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc:From; b=wwDFK6a/0F6ByP87navHGr9oEnHhhGE12HILvpMpTKNShmOYgRca2UvvvVUAnhS+x 96AcDLeAmpfqYZOWbS7+WA9DMd4TJbfjyTecgZx32NHi2VjZJWsd3alUFxAxnsM3c0 uB/GaYggJQh//A+dHl9oAP7C7Jm8C7vAHbTFZPPm8qOukrmmNLQj+gHfvflcwZ4yNv fytZ75MFRd3dv9VZn/EEiyBWl7STDnA8meg0vK2XdSlGlgPVaB4K2IPw9SigUNSuiA qX07FrAFnXjhvLvO19jyrqoPNQtjmrkHn4OKFMD8wULyUWCfr7MIGprxTKQJ7i0tWb +SKmTAwTQ586g== X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q_JpE-Pn2qpn; Mon, 6 Feb 2023 19:56:43 +0000 (UTC) Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by smtp4.osuosl.org (Postfix) with ESMTP id C2D4B402EC; Mon, 6 Feb 2023 19:56:42 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org C2D4B402EC Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by ash.osuosl.org (Postfix) with ESMTP id ACCDD1BF2CD for ; Mon, 6 Feb 2023 18:25:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 8D361416C6 for ; Mon, 6 Feb 2023 18:25:41 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 8D361416C6 X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3qaUQyrraBF for ; Mon, 6 Feb 2023 18:25:40 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 159024167E Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by smtp4.osuosl.org (Postfix) with ESMTPS id 159024167E for ; Mon, 6 Feb 2023 18:25:40 +0000 (UTC) Received: from ptx.hi.pengutronix.de ([2001:67c:670:100:1d::c0]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pP6BF-0004zk-9u; Mon, 06 Feb 2023 19:25:29 +0100 Received: from ore by ptx.hi.pengutronix.de with local (Exim 4.92) (envelope-from ) id 1pP6BD-0000gG-2J; Mon, 06 Feb 2023 19:25:27 +0100 Date: Mon, 6 Feb 2023 19:25:27 +0100 From: Oleksij Rempel To: Vladimir Oltean Message-ID: <20230206182527.GG12366@pengutronix.de> References: <20230201145845.2312060-1-o.rempel@pengutronix.de> <20230204001332.dd4oq4nxqzmuhmb2@skbuf> <20230206054713.GD12366@pengutronix.de> <20230206141038.vp5pdkjyco6pyosl@skbuf> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230206141038.vp5pdkjyco6pyosl@skbuf> X-Sent-From: Pengutronix Hildesheim X-URL: http://www.pengutronix.de/ X-Accept-Language: de,en X-Accept-Content-Type: text/plain User-Agent: Mutt/1.10.1 (2018-07-13) X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c0 X-SA-Exim-Mail-From: ore@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: intel-wired-lan@lists.osuosl.org X-Mailman-Approved-At: Mon, 06 Feb 2023 19:56:41 +0000 Subject: Re: [Intel-wired-lan] [PATCH net-next v4 00/23] net: add EEE support for KSZ9477 and AR8035 with i.MX6 X-BeenThere: intel-wired-lan@osuosl.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Wired Ethernet Linux Kernel Driver Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Woojung Huh , Andrew Lunn , Arun.Ramadoss@microchip.com, Florian Fainelli , "David S. Miller" , netdev@vger.kernel.org, Richard Cochran , linux-kernel@vger.kernel.org, UNGLinuxDriver@microchip.com, Eric Dumazet , Wei Fang , kernel@pengutronix.de, Jakub Kicinski , intel-wired-lan@lists.osuosl.org, Paolo Abeni , Vivien Didelot , Heiner Kallweit Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-wired-lan-bounces@osuosl.org Sender: "Intel-wired-lan" 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 | _______________________________________________ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan