Re: [PATCH v2 0/5] Add support for DMA timestamp for non-PTP packets

[Jakub Kicinski <kuba@kernel.org>]

On Thu, 20 Oct 2022 02:16:25 +0000 Zulkifli, Muhammad Husaini wrote:
> > On Tue, 18 Oct 2022 09:07:28 +0800 Muhammad Husaini Zulkifli wrote:  
> > > v1 -> v2:
> > > 	- Move to the end for the new enum.
> > > 	- Add new HWTSTAMP_FILTER_DMA_TIMESTAMP receive filters.  
> > 
> > Did you address my feedback? How do we know if existing
> > HWTSTAMP_FILTER_ALL is PHC quality of DMA?  
> 
> I apologize if I didn't respond to your feedback. If I recall properly, you agreed to only
>  use the flag rather than creating a new tx type as a result of below conversation. 
> https://lore.kernel.org/all/20220930074016.295cbfab@kernel.org/

My bad, I wasn't very clear. I meant to agree that if you prefer we can
forgo adding a new tx_type, and depend on SOF_TIMESTAMPING_TX_* to
advertise the capabilities and request particular type. But
SOF_TIMESTAMPING_TX_* should still not assume that SOF_TIMESTAMPING_TX_HARDWARE 
is guaranteed to be measured close to the wire.

I was just looking at some mlx5 patches from last night:
https://lore.kernel.org/all/20221019063813.802772-5-saeed@kernel.org/
and if you look around you'll see that they advertise hardware
timestamps but AFAIU only packets they match to be PTP will go on 
the special queue that gets real close-to-wire time:
https://elixir.bootlin.com/linux/v6.1-rc1/source/drivers/net/ethernet/mellanox/mlx5/core/en/selq.c#L247
If application requests a HW stamp on a non-PTP packet (NTP? custom
proto?), or PTP is running on a custom UDP port, or simply the FW/HW
does not support this feature (mlx5 supports at least a decade's worth
of HW generations) - the application will get a DMA stamp.

Same for Rx - close-to-wire stamps may be more expensive for the NIC
and some modern TCP congestion control algos (BBRv2, Swift) need
HW timestamps of all packets but are okay with DMA stamps.

So we need:
 1) clear disambiguation when time stamps are *really* taken
    close-to-the-wire (CTW);
 2) ability to configure Rx to provide CTW stamps for PTP/NTP
    frames and DMA stamps for all the rest for congestion control.

I think extending the documentation in:
  Documentation/networking/timestamping.rst
to explain the API you're adding and how it will allow the above cases
to be satisfied will be a good start.