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

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]

Date: Wed, 17 May 2023 21:46:43 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Vladimir Oltean <vladimir.oltean@....com>,
	"Russell King (Oracle)" <linux@...linux.org.uk>,
	Köry Maincent <kory.maincent@...tlin.com>,
	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.

On Wed, May 17, 2023 at 12:19:25PM -0700, Jakub Kicinski wrote:
> On Fri, 12 May 2023 10:38:52 -0700 Jakub Kicinski wrote:
> > On Fri, 12 May 2023 13:29:11 +0300 Vladimir Oltean wrote:
> > > On Thu, May 11, 2023 at 04:16:25PM -0700, Jakub Kicinski wrote:  
> > > > Oh, you should tell me, maybe off-list then. 'Cause I don't know any.    
> > > 
> > > I hope the examples given in private will make you reconsider the
> > > validity of my argument about DMA timestamps.  
> > 
> > I may have lost track of what the argument is. There are devices
> > which will provide a DMA stamp for Tx and Rx. We need an API that'll
> > inform the user about it. 
> > 
> > To be clear I'm talking about drivers which are already in the tree,
> > not opening the door for some shoddy new HW in.
> 
> It dawned on me while reading a phylink discussion that I may have
> misunderstood the meaning of the MAC vs PHY time stamp sources.
> By the standard - stamping happens under the MAC, so MAC is 
> the "right" place to stamp, not the PHY. And there can be multiple 
> PHYs technically? Are we just using the MAC vs PHY thing as an
> implementation aid, to know which driver to send the request to?
> 
> Shouldn't we use the clock ID instead?

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.

Also, 'By the standard - stamping happens under the MAC'. Which MAC?
There can be multple MAC's in the pipeline. MACSEC and rate adaptation
in the PHY are often implemented by the PHY having a MAC
reconstituting the frame from the bitstream and putting it into a
queue. Rate adaptation can then be performed by the PHY by sending
pause frames to the 'primary' MAC to slow it down. MACSEC in the PHY
takes frames in the queues and if they match a filter they get
encrypted. The PHY then takes the frame out of the queue and passes
them to a second MAC in the PHY which creates a bitstream and then to
a 'PHY' to generate signals for the line.

In this sort of setup, you obviously don't want the 'primary' MAC
doing the stamping. You want the MAC nearest to the line, or better
still the 'PHY' within the PHY just before the line.

      Andrew