All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Arınç ÜNAL" <arinc.unal@arinc9.com>
To: Florian Fainelli <f.fainelli@gmail.com>,
	Daniel Golle <daniel@makrotopia.org>,
	Andrew Lunn <andrew@lunn.ch>
Cc: "DENG Qingfang" <dqfext@gmail.com>,
	"Sean Wang" <sean.wang@mediatek.com>,
	"Vladimir Oltean" <olteanv@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"AngeloGioacchino Del Regno"
	<angelogioacchino.delregno@collabora.com>,
	"René van Dorst" <opensource@vdorst.com>,
	"Russell King" <linux@armlinux.org.uk>,
	"SkyLake Huang" <SkyLake.Huang@mediatek.com>,
	"Heiner Kallweit" <hkallweit1@gmail.com>,
	"Bartel Eerdekens" <bartel.eerdekens@constell8.be>,
	mithat.guner@xeront.com, erkin.bozoglu@xeront.com,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org
Subject: Re: [PATCH 0/3] Fix EEE support for MT7531 and MT7988 SoC switch
Date: Sun, 24 Mar 2024 12:47:08 +0300	[thread overview]
Message-ID: <5a4c0436-cd78-419f-af14-9c4e0c0435e3@arinc9.com> (raw)
In-Reply-To: <11b2a4d1-66d8-4bcf-b1a8-20a635b99cc4@gmail.com>

On 21/03/2024 18:31, Florian Fainelli wrote:
> On 3/21/24 09:09, Arınç ÜNAL wrote:
>> I have started testing MT7531 with EEE enabled and immediately experienced
>> frames that wouldn't egress the switch or improperly received on the link
>> partner.
>>
>> SoC MAC       <-EEE off-> MT7531 P6 MAC (acting as PHY)
>> MT7531 P0 MAC <-EEE on -> MT7531 P0 PHY
>> MT7531 P0 PHY <-EEE on -> Computer connected with twisted pair
> 
> OK, so this is intended to describe that the SoC's Ethernet MAC link to the integrated switch did not use EEE only the user-facing ports. That makes sense because it's all digital logic and you are not going to be seeing much power saving from having EEE enabled between the SoC's Ethernet MAC and CPU port of the switch, that said, however, I wonder if this has an impact on any form of flow control within the switch that is reacting to LPI and you need EEE to be enabled end-to-end?

I've tested pinging between my computers with EEE enabled interfaces. The
behaviour is identical.

> 
>>
>> I've tested pinging from the SoC's CPU. Packet capturing on the twisted
>> pair computer showed very few frames were being received.
>>
>> # ping 192.168.2.2
>> PING 192.168.2.2 (192.168.2.2): 56 data bytes
>> 64 bytes from 192.168.2.2: seq=36 ttl=64 time=0.486 ms
>> ^C
>> --- 192.168.2.2 ping statistics ---
>> 64 packets transmitted, 1 packets received, 98% packet loss
>> round-trip min/avg/max = 0.486/0.486/0.486 ms
>>
>> It seems there's less loss when frames are passed more frequently.
> 
> That would point to an issue getting in and out of LPI, do you see these packet losses even with different LPI timeouts?

The NICs on my computers don't seem to allow changing the tx-lpi and
tx-timer options.

Computer 1 (Intel I219-V, driver: e1000e):

$ sudo ethtool --set-eee eno1 tx-timer 15
netlink error: Invalid argument

$ sudo ethtool --show-eee eno1
EEE settings for eno1:
	EEE status: enabled - active
	Tx LPI: 17 (us)
	Supported EEE link modes:  100baseT/Full
	                           1000baseT/Full
	Advertised EEE link modes:  100baseT/Full
	                            1000baseT/Full
	Link partner advertised EEE link modes:  100baseT/Full
	                                         1000baseT/Full

Computer 2 (Realtek RTL8111H, driver: r8169):

$ sudo ethtool --set-eee eno1 tx-lpi on

$ sudo ethtool --show-eee eno1
EEE settings for eno1:
	EEE status: enabled - active
	Tx LPI: disabled
	Supported EEE link modes:  100baseT/Full
	                           1000baseT/Full
	Advertised EEE link modes:  100baseT/Full
	                            1000baseT/Full
	Link partner advertised EEE link modes:  100baseT/Full
	                                         1000baseT/Full

I've tested with switch ports interfaces' tx-timer from 0 to 40, same
tx-timer for both interfaces. Loss is still there.

I suppose the MT7531 switch PHYs need calibration for EEE that is currently
missing from the mediatek-ge driver.

Arınç

  reply	other threads:[~2024-03-24  9:47 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <=?utf-8?q?=3C20240318-for-net-mt7530-fix-eee-for-mt7531-mt7988-v?=>
2024-03-19 18:25 ` [PATCH 0/3] Fix EEE support for MT7531 and MT7988 SoC switch Daniel Golle
2024-03-19 18:25   ` Daniel Golle
2024-03-19 18:46   ` Arınç ÜNAL
2024-03-19 19:38     ` Andrew Lunn
2024-03-19 19:38       ` Andrew Lunn
2024-03-19 20:04       ` Arınç ÜNAL
2024-03-19 20:26       ` Daniel Golle
2024-03-19 20:26         ` Daniel Golle
2024-03-19 21:16         ` Arınç ÜNAL
2024-03-19 21:31         ` Florian Fainelli
2024-03-19 21:31           ` Florian Fainelli
2024-03-21 16:09           ` Arınç ÜNAL
2024-03-21 16:31             ` Florian Fainelli
2024-03-21 16:31               ` Florian Fainelli
2024-03-24  9:47               ` Arınç ÜNAL [this message]
2024-03-24 11:39                 ` Russell King (Oracle)
2024-03-24 11:39                   ` Russell King (Oracle)
2024-03-24 11:45                   ` Arınç ÜNAL
     [not found] <65f7f17d.050a0220.3c75a.cde3SMTPIN_ADDED_BROKEN@mx.google.com>
2024-03-18 12:57 ` Florian Fainelli
2024-03-18 12:57   ` Florian Fainelli
2024-03-18 14:03   ` Arınç ÜNAL
2024-03-18 18:01     ` Konstantin Ryabitsev
2024-03-18 18:01       ` Konstantin Ryabitsev
2024-03-19 16:03       ` Konstantin Ryabitsev
2024-03-19 16:03         ` Konstantin Ryabitsev
2024-03-19 18:31         ` Arınç ÜNAL
2024-03-18  7:46 Arınç ÜNAL via B4 Relay
2024-03-18  7:46 ` Arınç ÜNAL via B4 Relay
  -- strict thread matches above, loose matches on Subject: below --
2024-03-18  7:46 Arınç ÜNAL
2024-03-20  8:10 ` Arınç ÜNAL
2024-03-20 11:08   ` Daniel Golle
2024-03-20 11:08     ` Daniel Golle
2024-03-20 15:03     ` Arınç ÜNAL

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=5a4c0436-cd78-419f-af14-9c4e0c0435e3@arinc9.com \
    --to=arinc.unal@arinc9.com \
    --cc=SkyLake.Huang@mediatek.com \
    --cc=andrew@lunn.ch \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=bartel.eerdekens@constell8.be \
    --cc=daniel@makrotopia.org \
    --cc=davem@davemloft.net \
    --cc=dqfext@gmail.com \
    --cc=edumazet@google.com \
    --cc=erkin.bozoglu@xeront.com \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=matthias.bgg@gmail.com \
    --cc=mithat.guner@xeront.com \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=opensource@vdorst.com \
    --cc=pabeni@redhat.com \
    --cc=sean.wang@mediatek.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.