[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <44132260-2eba-1b92-af75-883a3c4e908c@nvidia.com>
Date: Tue, 18 Oct 2022 17:23:06 +0300
From: Gal Pressman <gal@...dia.com>
To: Muhammad Husaini Zulkifli <muhammad.husaini.zulkifli@...el.com>,
intel-wired-lan@...osl.org
Cc: netdev@...r.kernel.org, kuba@...nel.org, davem@...emloft.net,
edumazet@...gle.com, aravindhan.gunasekaran@...el.com,
richardcochran@...il.com, saeed@...nel.org, leon@...nel.org,
michael.chan@...adcom.com, andy@...yhouse.net,
vinicius.gomes@...el.com
Subject: Re: [PATCH v2 0/5] Add support for DMA timestamp for non-PTP packets
Hello Muhammad,
On 18/10/2022 04:07, Muhammad Husaini Zulkifli wrote:
> 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.
Why would the timestamp be affected by the amount of traffic?
What 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.
Is it per socket?
Will there be a way to know which types of timestamps are going to be
used on queues setup time?
> This patch series also add a new HWTSTAMP_FILTER_DMA_TIMESTAMP receive
> filters. This filter can be configured for devices that support/allow the
> DMA timestamp retrieval on receive side.
So if I understand correctly, to solve the problem you described at the
beginning, you'll disable port timestamp for all incoming packets? ptp
included?
Powered by blists - more mailing lists