netdev - Re: [PATCH net-next v5 08/16] net: ethtool: Add a command to expose current time stamping layer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20231016182307.18c5dcf1@kmaincent-XPS-13-7390>
Date: Mon, 16 Oct 2023 18:23:07 +0200
From: Köry Maincent <kory.maincent@...tlin.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Andrew Lunn <andrew@...n.ch>, Florian Fainelli
 <florian.fainelli@...adcom.com>, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org, Thomas Petazzoni
 <thomas.petazzoni@...tlin.com>, "David S . Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
 Jonathan Corbet <corbet@....net>, Jay Vosburgh <j.vosburgh@...il.com>, Andy
 Gospodarek <andy@...yhouse.net>, Nicolas Ferre
 <nicolas.ferre@...rochip.com>, Claudiu Beznea <claudiu.beznea@...on.dev>,
 Horatiu Vultur <horatiu.vultur@...rochip.com>,
 UNGLinuxDriver@...rochip.com, Broadcom internal kernel review list
 <bcm-kernel-feedback-list@...adcom.com>, Heiner Kallweit
 <hkallweit1@...il.com>, Russell King <linux@...linux.org.uk>, Richard
 Cochran <richardcochran@...il.com>, Radu Pirea
 <radu-nicolae.pirea@....nxp.com>, Willem de Bruijn
 <willemdebruijn.kernel@...il.com>, Vladimir Oltean
 <vladimir.oltean@....com>, Michael Walle <michael@...le.cc>, Jacob Keller
 <jacob.e.keller@...el.com>, Maxime Chevallier
 <maxime.chevallier@...tlin.com>
Subject: Re: [PATCH net-next v5 08/16] net: ethtool: Add a command to expose
 current time stamping layer

On Mon, 16 Oct 2023 08:43:46 -0700
Jakub Kicinski <kuba@...nel.org> wrote:

> On Mon, 16 Oct 2023 17:00:27 +0200 Köry Maincent wrote:
> > On Mon, 16 Oct 2023 07:22:04 -0700
> > Jakub Kicinski <kuba@...nel.org> wrote:  
>
> > Ok, but there might be quality difference in case of several timestamp
> > configuration done in the MAC. Like the timestamping precision vs frequency
> > precision. In that case how ethtool would tell the driver to switch between
> > them?  
> 
> What's the reason for timestamp precision differences?
> My understanding so far was the the differences come from:
>  1. different stamping device (i.e. separate "piece of silicon",
>     accessed over a different bus, with different PHC etc.)
>  2. different stamping point (MAC vs DMA)
> 
> I don't think any "integrated" device would support stamps which
> differ under category 1.

It was a case reported by Maxime on v3:
https://lore.kernel.org/netdev/20230324112541.0b3dd38a@pc-7.home/ 

> > My solution could work for this case by simply adding new values to the
> > enum:
> > 
> > enum {
> > 	NETDEV_TIMESTAMPING = (1 << 0),
> > 	PHYLIB_TIMESTAMPING = (1 << 1),
> > 	MAC_TS_PRECISION = (1 << 2)|(1 << 0),
> > 	MAC_FREQ_PRECISION = (2 << 2)|(1 << 0),
> > }
> > 
> > Automatically Linux will go through the netdev implementation and could pass
> > the enum value to the netdev driver.  
> 
> We can add multiple fields to netlink. Why use the magic encoding?

To simplify the Linux code to go under either netdev or phylib implementation
without needing describing all the enum possibility in the condition:
if (ts_layer & PHYLIB_TIMESTAMPING)
...
if (ts_layer & NETDEV_TIMESTAMPING)
...

We also could add "is_phylib" and "is_netdev" functions with a simple switch
case in it, but we have to be careful to always update these functions when new
enum values will appear.

> 
> > > But there is a big difference between MAC/PHY and DMA which would
> > > both fall under NETDEV?    
> > 
> > Currently there is no DMA timestamping support right?  
> 
> Kinda. Some devices pass DMA stamps as "HW stamps", and pretend they
> are "good enough". But yes, there's no distinction at API level.

Ok. I did suppose this when writing my last reply.

> > In that case we will have MAC and DMA under netdev and PHY under phylib and
> > we won't have to do anything more than this timestamping management patch: 
> > https://lore.kernel.org/netdev/20231009155138.86458-14-kory.maincent@bootlin.com/
> >  
> 
> Maybe we should start with a doc describing what APIs are at play,
> what questions they answer, and what hard use cases we have.
> 
> I'm not opposed to the ethool API reporting just the differences
> from my point 1. (in the first paragraph). But then we shouldn't
> call that "layer", IMO, but device or source or such.

I am open to change the naming to fit the best for our current and future usage.
If we take into account the Maxime case of several timestamps on a device then
maybe source could work.