Re: [PATCH net-next RFC v4 2/5] net: Expose available time stamping layers to user space.

Richard Cochran
2023-09-04T17:47:06Z

On Mon, Sep 04, 2023 at 05:22:45PM +0200, Köry Maincent wrote:
> Hello I am resuming my work on selectable timestamping layers.
>
> On Wed, 17 May 2023 13:07:06 -0700
> Jakub Kicinski <kuba@kernel.org> wrote:
>
> > On Wed, 17 May 2023 21:46:43 +0200 Andrew Lunn wrote:
> > > As i said in an earlier thread, with a bit of a stretch, there could
> > > be 7 places to take time stamps in the system. We need some sort of
> > > identifier to indicate which of these stampers to use.
> > >
> > > Is clock ID unique? In a switch, i think there could be multiple
> > > stampers, one per MAC port, sharing one clock? So you actually need
> > > more than a clock ID.

Let's not mix things up. A clock ID identifies a dynamic posix clock,
just like the name suggests. A clock is a device that supports
operations like gettime and settime.

A given clock might or might not generate time stamps.

The time stamp API is completely separate.

> > Clock ID is a bit vague too, granted, but in practice clock ID should
> > correspond to the driver fairly well? My thinking was - use clock ID
> > to select the (silicon) device, use a different attribute to select
> > the stamping point.

I've never heard of a device that has different time stamping points.
If one ever appeared, then it ought to present two interfaces.

> > IOW try to use the existing attribute before inventing a new one.
>
> What do you think of using the clock ID to select the timestamp layer, and add
> a ts_layer field in ts_info that will describe the timestamp layer. This allow
> to have more information than the vague clock ID. We set it in the driver.
> With it, we could easily add new layers different than simple mac and phy.
> I am currently working on this implementation.

I think you should model the layers explicitly.

Thanks,
Richard