From: Oleksij Rempel <o.rempel@pengutronix.de>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>,
Jose Abreu <joabreu@synopsys.com>,
"David S. Miller" <davem@davemloft.net>,
Heiner Kallweit <hkallweit1@gmail.com>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Woojung Huh <woojung.huh@microchip.com>,
Arun Ramadoss <arun.ramadoss@microchip.com>,
Richard Cochran <richardcochran@gmail.com>,
Russell King <linux@armlinux.org.uk>,
kernel@pengutronix.de, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, UNGLinuxDriver@microchip.com,
linux-stm32@st-md-mailman.stormreply.com
Subject: Re: [PATCH net-next v1 2/4] net: phy: micrel: lan8841: set default PTP latency values
Date: Wed, 17 Apr 2024 22:12:52 +0200 [thread overview]
Message-ID: <ZiAtREiqPuvXkB4S@pengutronix.de> (raw)
In-Reply-To: <c8e3f5d0-832b-4ab1-a65f-52f983ff110a@lunn.ch>
On Wed, Apr 17, 2024 at 08:39:54PM +0200, Andrew Lunn wrote:
> On Wed, Apr 17, 2024 at 06:43:14PM +0200, Oleksij Rempel wrote:
> > Set default PTP latency values to provide realistic path delay
> > measurements and reflecting internal PHY latency asymetry.
> >
> > This values are based on ptp4l measurements for the path delay against
> > identical PHY as link partner and latency asymmetry extracted from
> > documented SOF Latency values of this PHY.
> >
> > Documented SOF Latency values are:
> > TX 138ns/RX 430ns @ 1000Mbps
> > TX 140ns/RX 615ns @ 100Mbps (fixed latency mode)
> > TX 140ns/RX 488-524ns @ 100Mbps (variable latency mode)
> > TX 654ns/227-2577ns @ 10Mbps
Here is a typo 2277-2577ns
> Does Half Duplex vs Full Duplex make a difference here?
Yes, Half Duplex will be even less predictable. It would make no sense to
use it for the time sync.
> > +static int lan8841_ptp_latency_init(struct phy_device *phydev)
> > +{
> > + int ret;
> > +
> > + ret = phy_write_mmd(phydev, KSZ9131RN_MMD_COMMON_CTRL_REG,
> > + LAN8841_PTP_RX_LATENCY_10M,
> > + LAN8841_PTP_RX_LATENCY_10M_VAL);
> > + if (ret)
> > + return ret;
> > +
> > + ret = phy_write_mmd(phydev, KSZ9131RN_MMD_COMMON_CTRL_REG,
> > + LAN8841_PTP_TX_LATENCY_10M,
> > + LAN8841_PTP_TX_LATENCY_10M_VAL);
> > + if (ret)
> > + return ret;
> > +
> > + ret = phy_write_mmd(phydev, KSZ9131RN_MMD_COMMON_CTRL_REG,
> > + LAN8841_PTP_RX_LATENCY_100M,
> > + LAN8841_PTP_RX_LATENCY_100M_VAL);
> > + if (ret)
> > + return ret;
> > +
> > + ret = phy_write_mmd(phydev, KSZ9131RN_MMD_COMMON_CTRL_REG,
> > + LAN8841_PTP_TX_LATENCY_100M,
> > + LAN8841_PTP_TX_LATENCY_100M_VAL);
> > + if (ret)
> > + return ret;
> > +
> > + ret = phy_write_mmd(phydev, KSZ9131RN_MMD_COMMON_CTRL_REG,
> > + LAN8841_PTP_RX_LATENCY_1000M,
> > + LAN8841_PTP_RX_LATENCY_1000M_VAL);
> > + if (ret)
> > + return ret;
> > +
> > + return phy_write_mmd(phydev, KSZ9131RN_MMD_COMMON_CTRL_REG,
> > + LAN8841_PTP_TX_LATENCY_1000M,
> > + LAN8841_PTP_TX_LATENCY_1000M_VAL);
> > +}
>
> What affect does this have on systems which have already applied
> adjustments in user space to correct for this? Will this cause
> regressions for such systems?
Yes.
> I know Richard has rejected changes like this in the past.
In this case I would need to extend the ethtool interface. The driver
should provide recommended values and the user space can optionally
read them and optionally write them to the HW.
Get Recommended TimeSync Data Path Delays
Command Name: ETHTOOL_G_TS_DELAYS_RECOMMENDED
Description: This command retrieves the recommended TimeSync data path
delays for transmit and receive paths, typically based on the interface
type and link speed. This values are not stable.
Get Currently Active TimeSync Data Path Delays
Command Name: ETHTOOL_G_TS_DELAYS_ACTIVE
Description: This command retrieves the currently active TimeSync data path
delays that are being applied by the PHY. This is useful for real-time
diagnostics and monitoring.
Set Currently Active TimeSync Data Path Delays
Command Name: ETHTOOL_S_TS_DELAYS_ACTIVE
Description: This command sets the currently active TimeSync data path
delays. This would allow the system administrator or the network management
system to manually adjust the TimeSync delays to either align them with the
recommended values or to tweak them for specific network conditions or
compliance requirements.
What do you think about this?
Should the delay value be bound to the link mode or only to the speed?
What if we have multiple components with delays? SoC/MAC specific delays,
interface converters RGMII to xMII, etc? Should the ethtool interface provide
summ of all delays in the chain, or we need to have access to each separately?
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 |
next prev parent reply other threads:[~2024-04-17 20:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-17 16:43 [PATCH net-next v1 0/4] add support for TimeSync path delays Oleksij Rempel
2024-04-17 16:43 ` [PATCH net-next v1 1/4] net: phy: Add TimeSync delay query support to PHYlib API Oleksij Rempel
2024-04-17 18:33 ` Andrew Lunn
2024-04-17 18:48 ` Woojung.Huh
2024-04-17 16:43 ` [PATCH net-next v1 2/4] net: phy: micrel: lan8841: set default PTP latency values Oleksij Rempel
2024-04-17 18:39 ` Andrew Lunn
2024-04-17 20:12 ` Oleksij Rempel [this message]
2024-04-17 20:23 ` Andrew Lunn
2024-04-19 6:46 ` Richard Cochran
2024-04-23 7:07 ` Oleksij Rempel
2024-04-24 6:10 ` Richard Cochran
2024-04-17 16:43 ` [PATCH net-next v1 3/4] net: phy: realtek: provide TimeSync data path delays for RTL8211E Oleksij Rempel
2024-04-18 5:39 ` kernel test robot
2024-04-17 16:43 ` [PATCH net-next v1 4/4] net: stmmac: use delays reported by the PHY driver to correct MAC propagation delay Oleksij Rempel
2024-04-17 19:13 ` Serge Semin
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=ZiAtREiqPuvXkB4S@pengutronix.de \
--to=o.rempel@pengutronix.de \
--cc=UNGLinuxDriver@microchip.com \
--cc=alexandre.torgue@foss.st.com \
--cc=andrew@lunn.ch \
--cc=arun.ramadoss@microchip.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=joabreu@synopsys.com \
--cc=kernel@pengutronix.de \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=linux@armlinux.org.uk \
--cc=mcoquelin.stm32@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=richardcochran@gmail.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 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.