netdev - Re: [PATCH net-next v3 3/5] eth: fbnic: add RX packets timestamping support

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: <a8f04d66-5ed5-42e1-9a5a-8cb097769410@intel.com>
Date: Mon, 7 Oct 2024 16:51:21 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: Vadim Fedorenko <vadim.fedorenko@...ux.dev>, Vadim Fedorenko
	<vadfed@...a.com>, Jakub Kicinski <kuba@...nel.org>, David Ahern
	<dsahern@...nel.org>, Paolo Abeni <pabeni@...hat.com>, "David S. Miller"
	<davem@...emloft.net>, Alexander Duyck <alexanderduyck@...com>
CC: <netdev@...r.kernel.org>, Richard Cochran <richardcochran@...il.com>
Subject: Re: [PATCH net-next v3 3/5] eth: fbnic: add RX packets timestamping
 support



On 10/7/2024 3:26 AM, Vadim Fedorenko wrote:
> On 05/10/2024 00:18, Jacob Keller wrote:
>> Is there any benefit to implementing anything other than
>> HWTSTAMP_FILTER_ALL?
>>
>> Those are typically considered legacy with the primary reason being to
>> support hardware which does not support timestamping all frames.
>>
>> I suppose if you have measurement that supporting them is valuable (i.e.
>> because of performance impact on timestamping all frames?) it makes
>> sense to support. But otherwise I'm not sure its worth the extra complexity.
>>
>> Upgrading the filtering modes to HWTSTAMP_FILTER_ALL is acceptable and
>> is done by a few drivers.
> 
> Even though the hardware is able to timestamp TX packets at line rate,
> we would like to avoid having 2x times more interrupts for the cases
> when we don't need all packets to be timestamped. And as it mentioned
> in the comment, we don't have very precise HW filters, but we would like
> to avoid timestamping TCP packets when TCP is the most used one on the
> host.

Tx timestamps don't use the filters in the first place. The filter only
applies to Rx timestamps. You should only initiate a Tx timestamp when
requested, which will generally not be the case for TCP.

Are you saying that Rx timestamps generate interrupts?