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]

Message-ID: <20230517130706.3432203b@kernel.org>
Date: Wed, 17 May 2023 13:07:06 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Andrew Lunn <andrew@...n.ch>
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, 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.

> 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.

For a PHY "always use the point closest to the wire" makes sense.

For DMA we'd have a different set of priorities - precision vs
volume vs 1-step / 2-step; but all from the same clock. I think 
that we may want to defer figuring out selection within a single
clock for now, to make some progress.