netdev - RE: [PATCH v1 0/4] Add support for DMA timestamp for non-PTP packets

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]

Date:   Thu, 29 Sep 2022 02:35:29 +0000
From:   "Zulkifli, Muhammad Husaini" <muhammad.husaini.zulkifli@...el.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     "intel-wired-lan@...osl.org" <intel-wired-lan@...osl.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "Gomes, Vinicius" <vinicius.gomes@...el.com>,
        "Gunasekaran, Aravindhan" <aravindhan.gunasekaran@...el.com>,
        "Ahmad Tarmizi, Noor Azura" <noor.azura.ahmad.tarmizi@...el.com>,
        Richard Cochran <richardcochran@...il.com>
Subject: RE: [PATCH v1 0/4] Add support for DMA timestamp for non-PTP packets

Hi Jakub,

Thanks for reviewing. 
Please see my reply in-line.

> -----Original Message-----
> From: Jakub Kicinski <kuba@...nel.org>
> Sent: Wednesday, 28 September, 2022 8:09 AM
> To: Zulkifli, Muhammad Husaini <muhammad.husaini.zulkifli@...el.com>
> Cc: intel-wired-lan@...osl.org; netdev@...r.kernel.org;
> davem@...emloft.net; edumazet@...gle.com; Gomes, Vinicius
> <vinicius.gomes@...el.com>; Gunasekaran, Aravindhan
> <aravindhan.gunasekaran@...el.com>; Ahmad Tarmizi, Noor Azura
> <noor.azura.ahmad.tarmizi@...el.com>; Richard Cochran
> <richardcochran@...il.com>
> Subject: Re: [PATCH v1 0/4] Add support for DMA timestamp for non-PTP
> packets
> 
> On Tue, 27 Sep 2022 21:06:52 +0800 Muhammad Husaini Zulkifli wrote:
> > The HW TX timestamps created by the NIC via socket options can be
> > requested using the current network timestamps generation capability
> > of SOF_TIMESTAMPING_TX_HARDWARE. The most common users of this
> socket
> > flag is PTP, however other packet applications that require tx
> > timestamps might also ask for it.
> >
> > The problem is that, when there is a lot of traffic, there is a high
> > chance that the timestamps for a PTP packet will be lost if both PTP
> > and Non-PTP packets use the same SOF TIMESTAMPING TX HARDWARE
> causing the tx timeout.
> >
> > DMA timestamps through socket options are not currently available to
> > the user. Because if the user wants to, they can configure the
> > hwtstamp config option to use the new introduced DMA Time Stamp flag
> > through the setsockopt().
> >
> > With these additional socket options, users can continue to utilise HW
> > timestamps for PTP while specifying non-PTP packets to use DMA
> > timestamps if the NIC can support them.
> >
> > Any socket application can be use to verify this.
> > TSN Ref SW application is been used for testing by changing as below:
> 
> Very glad to see this being worked on!
> 
> High level tho, are we assuming that the existing HW timestamps are always
> PTP-quality, i.e. captured when SFD crosses the RS layer, or whatnot? I'm
> afraid some NICs already report PCI stamps as the HW ones.

Yes. HW timestamps always can be assume equivalent to PTP quality.
Could you provide additional information regarding SFD crosses the RS layer?
According to what I observed, The HW Timestamps will be requested if the application side 
specifies tx type = HWTSTAMP TX ON and timestamping flags = SOF TIMESTAMPING TX HARDWARE.
So it depends on how the application used it.

> So the existing HW stamps are conceptually of "any" type, if we want to be
> 100% sure NIC actually stamps at the PHY we'd need another tx_type to
> express that.

Yes, you're right. Are you suggesting that we add a new tx_type to specify
Only MAC/PHY timestamp ? Ex. HWTSTAMP_TX_PHY/MAC_ON.
Sorry about the naming here. Just so you know, the DMA timestamp does not
quite match the PTP's level timestamping. The DMA timestamp will be capture when
DMA request to fetch the data from the memory. 

> 
> Same story on the Rx - what do you plan to do there? We'll need to configure
> the filters per type, but that's likely to mean two new filters, because the
> current one gives no guarantee.

Current I225 HW only allow to retrieve the dma time for TX packets only. 
So as of now based on our HW, on RX side we just requesting rx filter to timestamps any incoming packets.
We always allocating additional bytes in the packet buffer for the receive packets for timestamp. 
It is a 1588 PTP level kind of timestamping accuracy here.