[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230904172245.1fa149fd@kmaincent-XPS-13-7390>
Date: Mon, 4 Sep 2023 17:22:45 +0200
From: Köry Maincent <kory.maincent@...tlin.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Andrew Lunn <andrew@...n.ch>, Vladimir Oltean <vladimir.oltean@....com>,
"Russell King (Oracle)" <linux@...linux.org.uk>, netdev@...r.kernel.org,
glipus@...il.com, maxime.chevallier@...tlin.com, vadim.fedorenko@...ux.dev,
richardcochran@...il.com, gerhard@...leder-embedded.com,
thomas.petazzoni@...tlin.com, krzysztof.kozlowski+dt@...aro.org,
robh+dt@...nel.org
Subject: Re: [PATCH net-next RFC v4 2/5] net: Expose available time stamping
layers to user space.
Hello I am resuming my work on selectable timestamping layers.
On Wed, 17 May 2023 13:07:06 -0700
Jakub Kicinski <kuba@...nel.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.
>
> 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.
>
> 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.
Powered by blists - more mailing lists