Re: [PATCH v4 net-next 1/7] ptp: Add ioctls for PHC timestamps with quality attributes
From: Arthur Kiyanovski <akiyano@amazon.com>
Date: 2026-07-29 00:27:14
Also in:
linux-doc, linux-kselftest
On 2026-07-28 11:10:31+03:00, Carolina Jubran wrote:
On 16/07/2026 21:14, Jacob Keller wrote:quoted
On 7/16/2026 1:09 AM, Arthur Kiyanovski wrote: Right. Absolutely. I don't think that should change this patch series. Its just a thought that we might want to tackle this at some point as the ioctl interface is clearly reaching its limits. Makes sense. Leave it up to userspace to coordinate and combine relevant data from the device/driver and the daemons together. Ok.That assumes host userspace knows about the synchronizer. That is not always true. On a DPU/SmartNIC, linuxptp may run on the device side while the host has no visibility into that process. There is then nothing for host userspace to coordinate with, and no way to learn the clock quality. What should happen in that case? Would it make sense to also allow userspace to set these attributes?
That case is actually the primary motivation for this interface, not a gap. When the synchronizer runs device-side (DPU/SmartNIC), the device knows its own sync quality and reports it to the host through these read-side attributes — no host daemon to coordinate with; the host just reads error_bound/status/timescale. ENA is exactly this: the device computes the bound, the host reads it. Letting userspace set these attributes is a separate feature (a host daemon publishing quality to other host readers of the same PHC). It doesn't help the DPU case and raises shared-clock questions (authority, permissions, races), so I'd keep this series read-only and explore a set-side path as a follow-up if there's demand.