netdev - Re: [PATCH net-next v17 12/14] net: ethtool: tsinfo: Add support for reading tsinfo for a specific hwtstamp provider

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: <667b3700-e529-4d2e-9aa1-a738a1d70f0f@intel.com>
Date: Wed, 17 Jul 2024 10:35:20 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: Kory Maincent <kory.maincent@...tlin.com>, Florian Fainelli
	<florian.fainelli@...adcom.com>, Broadcom internal kernel review list
	<bcm-kernel-feedback-list@...adcom.com>, Andrew Lunn <andrew@...n.ch>, Heiner
 Kallweit <hkallweit1@...il.com>, Russell King <linux@...linux.org.uk>, "David
 S. Miller" <davem@...emloft.net>, "Eric Dumazet" <edumazet@...gle.com>, Jakub
 Kicinski <kuba@...nel.org>, "Paolo Abeni" <pabeni@...hat.com>, Richard
 Cochran <richardcochran@...il.com>, "Radu Pirea"
	<radu-nicolae.pirea@....nxp.com>, Jay Vosburgh <j.vosburgh@...il.com>, Andy
 Gospodarek <andy@...yhouse.net>, Nicolas Ferre <nicolas.ferre@...rochip.com>,
	Claudiu Beznea <claudiu.beznea@...on.dev>, Willem de Bruijn
	<willemdebruijn.kernel@...il.com>, Jonathan Corbet <corbet@....net>, Horatiu
 Vultur <horatiu.vultur@...rochip.com>, <UNGLinuxDriver@...rochip.com>, Simon
 Horman <horms@...nel.org>, "Vladimir Oltean" <vladimir.oltean@....com>,
	<donald.hunter@...il.com>, <danieller@...dia.com>, <ecree.xilinx@...il.com>
CC: Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
	<linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>,
	<linux-doc@...r.kernel.org>, Maxime Chevallier
	<maxime.chevallier@...tlin.com>, Rahul Rameshbabu <rrameshbabu@...dia.com>,
	Willem de Bruijn <willemb@...gle.com>, Shannon Nelson
	<shannon.nelson@....com>, Alexandra Winter <wintera@...ux.ibm.com>
Subject: Re: [PATCH net-next v17 12/14] net: ethtool: tsinfo: Add support for
 reading tsinfo for a specific hwtstamp provider



On 7/9/2024 6:53 AM, Kory Maincent wrote:
> Either the MAC or the PHY can provide hwtstamp, so we should be able to
> read the tsinfo for any hwtstamp provider.
> 
> Enhance 'get' command to retrieve tsinfo of hwtstamp providers within a
> network topology.
> 
> Add support for a specific dump command to retrieve all hwtstamp
> providers within the network topology, with added functionality for
> filtered dump to target a single interface.
> 
> Signed-off-by: Kory Maincent <kory.maincent@...tlin.com>
> ---
> 
> Pointer attached_dev is used to know if the phy is on the net topology.
> This might not be enough and might need Maxime Chevallier link topology
> patch series:
> https://lore.kernel.org/netdev/20240213150431.1796171-1-maxime.chevallier@bootlin.com/
> 

Reviewed-by: Jacob Keller <jacob.e.keller@...el.com>

One thing which applies more broadly to the whole series, but I see the
focus right now is on selecting between NETDEV and PHYLIB.

For ice (E800 series) hardware, the timestamps are captured by the PHY,
but its not managed by phylib, its managed by firmware. In our case we
would obviously report NETDEV in this case. The hardware only has one
timestamp point and the fact that it happens at the PHY layer is not
relevant since you can't select or change it.

There are some future plans in the work for hardware based on the ixgbe
driver which could timestamp at either the MAC or PHY (with varying
trade-offs in precision vs what can be timestamped), and (perhaps
unfortunately), the PHY would likely not manageable by phylib.

There is also the possibility of something like DMA or completion
timestamps which are distinct from MAC timestamps. But again can have
varying trade offs.

I'm hopeful this work can be extended somehow to enable selection
between the different mechanisms, even when the kernel device being
represented is the same netdev.