netdev - Re: [PATCH RFC net-next] net: phy: add Marvell PHY PTP support [multicast/DSA issues]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y/6Cxf6EAAg22GOL@shell.armlinux.org.uk>
Date:   Tue, 28 Feb 2023 22:40:05 +0000
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Richard Cochran <richardcochran@...il.com>,
        Köry Maincent <kory.maincent@...tlin.com>,
        andrew@...n.ch, davem@...emloft.net, f.fainelli@...il.com,
        hkallweit1@...il.com, netdev@...r.kernel.org,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Maxime Chevallier <maxime.chevallier@...tlin.com>
Subject: Re: [PATCH RFC net-next] net: phy: add Marvell PHY PTP support
 [multicast/DSA issues]

On Tue, Feb 28, 2023 at 02:26:48PM -0800, Jakub Kicinski wrote:
> On Tue, 28 Feb 2023 16:27:10 +0000 Russell King (Oracle) wrote:
> > > 5. other?  
> > 
> > Another possible solution to this would be to introduce a rating for
> > each PTP clock in a similar way that we do for the kernel's
> > clocksources, and the one with the highest rating becomes the default. 
> 
> Why not ethtool? Sorry if I'm missing something obvious..

If we make the "default" fixed, such as "we always default to PHY"
then merge Marvell PHY PTP support, then on Macchiatobin, we will
end up switching from the current mvpp2-based PTP support to using
the inferior PHY PTP support, resulting in a loss of precision
and accuracy. That's a regression.

So, while we generally want PHY PTP support to be the default,
there are legitimate reasons for wanting in some circumstances
for the MAC to be the default.

The problem with an ethtool control is it's an extra step that
the user has to do to restore the accuracy that they had under
today's kernels, and I don't think that's something that they
should be involved in doing.

Providing controls to userspace is all very well _if_ there is
a way for users to make sensible decisions - which means giving
them information such as "on this hardware, MAC PTP is preferable
because it has better accuracy and precision, but on some other
hardware, PHY PTP is preferable" and such a document would get
very very long.

IMHO, it's better if the kernel automatically selects a sensible
default _and_ gives the user the ability to override it e.g. via
ethtool.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!