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 for Android: free password hash cracker in your pocket

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

Message-ID: <20230511150902.57d9a437@kernel.org>
Date: Thu, 11 May 2023 15:09:02 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: "Russell King (Oracle)" <linux@...linux.org.uk>, Andrew Lunn
 <andrew@...n.ch>, 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 Fri, 12 May 2023 00:02:37 +0300 Vladimir Oltean wrote:
> > Surely that is equivalent to MAC timestamping? Whether the MAC
> > places it in a DMA descriptor, or whether it places it in some
> > auxiliary information along with the packet is surely irrelevant,
> > because the MAC has to have the timestamp available to it in some
> > manner. Where it ends up is just a function of implementation surely?
> > 
> > I'm just wondering what this would mean for mvpp2, where the
> > timestamps are in the descriptors. If we have a "DMA timestamp"
> > is that a "DMA timestamp" or a "MAC timestamp"? The timestamp comes
> > from the MAC in this case.  
> 
> No, a MAC timestamp carried through a DMA descriptor is still a MAC
> timestamp (better said: timestamp taken at the MAC).

Right. The method of communicating the TS and where TS is taken 
are theoretically unrelated (in practice DMA timestamp not in
a descriptor is likely pointless).

> DMA timestamps probably have to do with this igc patch set, which I
> admit to not having had the patience to follow along all the way and
> understand what is its status and if it was ever accepted in that form,
> or a different form, or if Vinicius' work for multiple in-flight TX

Exactly, think Tx. For Rx hauling the TS in metadata from PHY/MAC to
descriptor is easy. For Tx device will buffer the packet so the DMA
completion happens before the packet actually left onto the wire.

Which is not to say that some devices may not generate the Rx timestamp
when the packet is DMA'ed out of laziness, too.

> timestamps is an alternate solution to the same problem as DMA
> timestamps, or whatever:
> https://lore.kernel.org/netdev/20221018010733.4765-1-muhammad.husaini.zulkifli@intel.com/

What I was thinking was:

 - PHY - per spec, at the RS layer
 - MAC - "close to the wire" in the MAC, specifically the pipeline
   delay (PHY stamp vs MAC stamp) should be constant for all packets;
   there must be no variable-time buffering and (for Tx) the time
   stamping must be past the stage of the pipeline affected by pause
   frames
 - DMA - worst quality, variable delay timestamp, usually taken when
   packets DMA descriptors (Rx or completion) are being written

With these definitions MAC and PHY timestamps are pretty similar
from the perspective of accuracy.