netdev - Re: [PATCH net-next v4] ptp: add Alibaba CIPU PTP clock driver

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: <c00a30af-89b2-400c-8026-8a987be3e3dd@linux.alibaba.com>
Date: Mon, 18 Aug 2025 11:04:46 +0800
From: Wen Gu <guwen@...ux.alibaba.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Jakub Kicinski <kuba@...nel.org>, richardcochran@...il.com,
 andrew+netdev@...n.ch, davem@...emloft.net, edumazet@...gle.com,
 pabeni@...hat.com, xuanzhuo@...ux.alibaba.com, dust.li@...ux.alibaba.com,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 Thomas Gleixner <tglx@...utronix.de>, David Woodhouse <dwmw2@...radead.org>
Subject: Re: [PATCH net-next v4] ptp: add Alibaba CIPU PTP clock driver



On 2025/8/17 23:56, Andrew Lunn wrote:
> On Sun, Aug 17, 2025 at 11:01:23AM +0800, Wen Gu wrote:
>>
>>
>> On 2025/8/16 23:37, Andrew Lunn wrote:
>>>> These sysfs are intended to provide diagnostics and informations.
>>>
>>> Maybe they should be in debugfs if they are just diagnostics? You then
>>> don't need to document them, because they are not ABI.
>>>
>>> 	Andrew
>>
>> Hi Andrew,
>>
>> Thank you for the suggestion.
>>
>> But these sysfs aren't only for developer debugging, some cloud components
>> rely on the statistics to assess the health of PTP clocks or to perform
>> corresponding actions based on the reg values. So I prefer to use the stable
>> sysfs.
> 
> Doesn't this somewhat contradict what you said earlier:
> 
>     These sysfs are intended to provide diagnostics and informations.
>     For users, interacting with this PTP clock works the same way as with other
>     PTP clock, through the exposed chardev.
> 
> So users don't use just the standard chardev, they additionally need
> sysfs.

No, they are not contradictory.

For cloud users, they only need to use standard ptp chardev exposed to do time
operations. This is no different from using any other PTP clock.

The sysfs are used by Alibaba cloud's components that monitor the health and behavior
of the underlay device to ensure SLAs.

> 
> Maybe take a step back. Do what Jakub suggested:
> 
>     Maybe it's just me, but in general I really wish someone stepped up
>     and created a separate subsystem for all these cloud / vm clocks.
>     They have nothing to do with PTP. In my mind PTP clocks are simple
>     HW tickers on which we build all the time related stuff. While this
>     driver reports the base year for the epoch and leap second status
>     via sysfs.
> 
> Talk with the other cloud vendors and define a common set of
> properties, rather than each vendor having their own incompatible set.
> 
> OS 101: the OS is supposed to abstract over the hardware to make
> different hardware all look the same.

IMHO, the abstraction has been done by PTP layer, e.g. struct ptp_clock_info,
struct ptp_clock and ptp_clock_{un}register(). For users, the PTP clock provide by
any vendors should be same in terms of usage, Alibaba Cloud is no exception.

But the specific implementation of underlay varies from ventor to ventor. Some depends
on ptp4l and NIC with IEEE 1588, some offload 1588 work to underlay infra and get
timestamps directly. I think it is difficult to require all vendors to provide the same
underlying attributes. Besides, Even the underlying implementation and properties are
different, it does not affect the user's use of them and the abstraction as PTP clocks.

Thanks!

> 
> 	Andrew