Re: [PATCH v4 net-next 1/7] ptp: Add ioctls for PHC timestamps with quality attributes

On 2026-07-28 11:10:31+03:00, Carolina Jubran wrote:
> On 16/07/2026 21:14, Jacob Keller wrote:
> 
> > 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.