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

[Jakub Kicinski <kuba@kernel.org>]

On Mon, 4 Sep 2023 10:47:00 -0700 Richard Cochran wrote:
> > > 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.

Maybe we should try to enumerate the use cases, I don't remember now
but I think the concern was that there may be multiple PHYs?

(Using [] to denote a single device)

#0    integrated NIC: [DMA MAC PHY]
#1       "Linux" NIC: [DMA MAC][PHY]
#2   DSA switch trap: [DMA MAC][MAC PHY]
#3 DSA switch switch: [PHY MAC  MAC PHY]
#4   DSA distributed: [PHY MAC][MAC PHY]

All these should be fine with netdev + layer, IIUC.