Message-ID: <6f6f4487-1c5d-de4e-0c79-452128deae0c@nvidia.com>
Date:   Thu, 29 Sep 2022 17:46:04 +0300
From:   Gal Pressman <gal@...dia.com>
To:     Jakub Kicinski <kuba@...nel.org>,
        "Zulkifli, Muhammad Husaini" <muhammad.husaini.zulkifli@...el.com>
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>,
        Saeed Mahameed <saeed@...nel.org>,
        "leon@...nel.org" <leon@...nel.org>,
        Michael Chan <michael.chan@...adcom.com>,
        Andy Gospodarek <andy@...yhouse.net>
Subject: Re: [PATCH v1 0/4] Add support for DMA timestamp for non-PTP packets

On 29/09/2022 16:56, Jakub Kicinski wrote:
> On Thu, 29 Sep 2022 02:35:29 +0000 Zulkifli, Muhammad Husaini wrote:
>>> 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?
> I mean true PTP timestamps, rather than captured somewhere in the NIC
> pipeline or at the DMA engine.
>
>> 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.
> Perhaps we can call them HWTSTAMP_TX_PTP_* ? Was the general time
> stamping requirement specified in IEEE 1588 or 802.1 (AS?)? 
>
> Both MAC and PHY can provide the time stamps IIUC, so picking one of
> those will not be entirely fortunate. In fact perhaps embedded folks
> will use this opportunity to disambiguate the two..
>
>> 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.
> I see. I think datacenter NICs can provide DMA stamps for Rx as well.
> Intel, Mellanox, Broadcom folks, could you confirm if your NIC can do Rx
> DMA stamps?

What exactly do you mean by DMA stamps?

Our NIC supports two modes of operation (both TX/RX):
- CQE timestamp (I think that's what you call DMA timestamp), where the
timestamp is written when the completion is being written/generated.
- Port timestamp (MAC timestamp), where the timstamp is written when the
packet is being sent to the wire, or received from the wire. This
doesn't account for the time the packet spent inside the NIC pipeline.

So I believe the answer to your question is yes :).

Powered by blists - more mailing lists