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.
