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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bae82fe3-56da-49df-94b6-1e2998f86503@intel.com>
Date: Mon, 16 Oct 2023 16:03:13 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: Jakub Kicinski <kuba@...nel.org>, Köry Maincent
	<kory.maincent@...tlin.com>
CC: Andrew Lunn <andrew@...n.ch>, Florian Fainelli
	<florian.fainelli@...adcom.com>, <netdev@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-doc@...r.kernel.org>, Thomas Petazzoni
	<thomas.petazzoni@...tlin.com>, "David S . Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
	"Jonathan Corbet" <corbet@....net>, Jay Vosburgh <j.vosburgh@...il.com>, Andy
 Gospodarek <andy@...yhouse.net>, Nicolas Ferre <nicolas.ferre@...rochip.com>,
	"Claudiu Beznea" <claudiu.beznea@...on.dev>, Horatiu Vultur
	<horatiu.vultur@...rochip.com>, <UNGLinuxDriver@...rochip.com>, "Broadcom
 internal kernel review list" <bcm-kernel-feedback-list@...adcom.com>, "Heiner
 Kallweit" <hkallweit1@...il.com>, Russell King <linux@...linux.org.uk>,
	Richard Cochran <richardcochran@...il.com>, Radu Pirea
	<radu-nicolae.pirea@....nxp.com>, Willem de Bruijn
	<willemdebruijn.kernel@...il.com>, Vladimir Oltean <vladimir.oltean@....com>,
	Michael Walle <michael@...le.cc>, Maxime Chevallier
	<maxime.chevallier@...tlin.com>
Subject: Re: [PATCH net-next v5 08/16] net: ethtool: Add a command to expose
 current time stamping layer



On 10/16/2023 10:03 AM, Jakub Kicinski wrote:
> On Mon, 16 Oct 2023 18:23:07 +0200 Köry Maincent wrote:
>>> What's the reason for timestamp precision differences?
>>> My understanding so far was the the differences come from:
>>>  1. different stamping device (i.e. separate "piece of silicon",
>>>     accessed over a different bus, with different PHC etc.)
>>>  2. different stamping point (MAC vs DMA)
>>>
>>> I don't think any "integrated" device would support stamps which
>>> differ under category 1.  
>>
>> It was a case reported by Maxime on v3:
>> https://lore.kernel.org/netdev/20230324112541.0b3dd38a@pc-7.home/ 
> 
> IMHO this talks about how clock control/disciplining works which
> is a somewhat independent topic of timestamping.

The thread in question mentions that the device has two modes, one which
has higher precision for the timestamps, and one which has better
precision on frequency adjustments. I don't know the details for why the
hardware has this behavior, but being able to switch between the two
timestamp modes has value as described by the thread.

I'm not sure how to represent that in such an API because both modes
seem to capture the timestamp at the MAC.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ