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: <SJ1PR11MB61800D87C61ADC94C57DB237B8439@SJ1PR11MB6180.namprd11.prod.outlook.com>
Date: Mon, 22 May 2023 03:56:36 +0000
From: "Zulkifli, Muhammad Husaini" <muhammad.husaini.zulkifli@...el.com>
To: Jakub Kicinski <kuba@...nel.org>, 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"
	<netdev@...r.kernel.org>, "glipus@...il.com" <glipus@...il.com>,
	"maxime.chevallier@...tlin.com" <maxime.chevallier@...tlin.com>,
	"vadim.fedorenko@...ux.dev" <vadim.fedorenko@...ux.dev>,
	"richardcochran@...il.com" <richardcochran@...il.com>,
	"gerhard@...leder-embedded.com" <gerhard@...leder-embedded.com>,
	"thomas.petazzoni@...tlin.com" <thomas.petazzoni@...tlin.com>,
	"krzysztof.kozlowski+dt@...aro.org" <krzysztof.kozlowski+dt@...aro.org>,
	"robh+dt@...nel.org" <robh+dt@...nel.org>, "Keller, Jacob E"
	<jacob.e.keller@...el.com>
Subject: RE: [PATCH net-next RFC v4 2/5] net: Expose available time stamping
 layers to user space.

Hi All,

> On Fri, 19 May 2023 16:28:02 +0300 Vladimir Oltean wrote:
> > > 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.
> >
> > So this is circling back to my original question (with emphasis on the
> > last part):
> >
> > | Which drivers provide DMA timestamps, and how do they currently
> > | signal that they do this? Do they do this for all packets that get
> > | timestamped, or for "some"?
> >
> > https://lore.kernel.org/netdev/20230511203646.ihljeknxni77uu5j@skbuf/
> >
> > If only "some" packets (unpredictable which) get DMA timestamps when a
> > MAC timestamp isn't available, what UAPI can satisfactorily describe
> > that? And who would want that?
> 
> The short answer is "I don't know". There's been a lot of talk about time
> stamps due to Swift/BBRv2, but I don't have first hand experience with it.
> That'd require time stamping "all" packets but the precision is really only
> required to be in usec.
> 
> Maybe Muhammad has a clearer use case in mind.

A controller may only support one HW Timestamp (PHY/Port) and one MAC Timestamp 
(DMA Timestamp) for packet timestamp activity. If a PTP packet has used the HW Timestamp (PHY/Port), 
the MAC timestamp can be used for another packet timestamp activity (ex. AF_XDP/AF_PACKET).
If all packets require and use the same HW Timestamp (PHY/Port timestamp) and we send a huge 
amount of traffic for AF_XDP/AF_PACKET, we may discover that some packets are missing the 
timestamp since every packet is attempting to read the same HW Port/PHY Timestamp register. 
You may see the tx_timestamp_timeout from ptp4l also in this scenario. 
Giving the user the choice of selecting MAC or PHY timestamp through the socket options can help 
resolve the above issue if they enable per-packet MAC(DMA) timestamping.

Thanks, 
Husaini