netdev - Re: [PATCH net-next v2 1/2] bnxt_en: cache only 24 bits of hw counter

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: <e89385ae-7d77-4890-8c80-b5904ac394b4@linux.dev>
Date: Fri, 25 Oct 2024 22:53:22 +0100
From: Vadim Fedorenko <vadim.fedorenko@...ux.dev>
To: Michael Chan <michael.chan@...adcom.com>
Cc: Pavan Chebbi <pavan.chebbi@...adcom.com>, Jakub Kicinski
 <kuba@...nel.org>, Andrew Lunn <andrew+netdev@...n.ch>,
 Paolo Abeni <pabeni@...hat.com>, "David S. Miller" <davem@...emloft.net>,
 netdev@...r.kernel.org, Richard Cochran <richardcochran@...il.com>
Subject: Re: [PATCH net-next v2 1/2] bnxt_en: cache only 24 bits of hw counter

On 25/10/2024 22:31, Michael Chan wrote:
> On Fri, Oct 25, 2024 at 12:48 PM Vadim Fedorenko <vadfed@...a.com> wrote:
>>
>> This hardware can provide only 48 bits of cycle counter. We can leave
>> only 24 bits in the cache to extend RX timestamps from 32 bits to 48
>> bits. This make cache writes atomic even on 32 bit platforms and we can
>> simply use READ_ONCE()/WRITE_ONCE() pair and remove spinlock. The
>> configuration structure will be also reduced by 4 bytes.
> 
> ptp->old_time serves 2 purposes: to cache the upper 16 bits of the HW
> counter and for rollover check.  With this patch reducing
> ptp->old_time to 24 bits, we now use the upper 16 bits for the cache
> and the next 8 bits for the rollover check.  I think this will work.
> But since the field is now 32-bit, why not use the full 32 bits
> instead of 24 bits?  Thanks.

As you confirmed that the HW has 48 bits of cycle counter, we have to
cache 16 bits only. The other 8 bits are used for the rollover check. We 
can even use less bits for it. What is the use for another 8 bits? With
this patch the rollover will happen every ~16 ms, but will be caught
even till ~4s. If we will cache upper 32 bits, the rollover will happen
every 64us and we will have to update cache value more often. But at the
same time it will not bring any value, because the upper limit will 
still be ~4s. That's why I don't see any benefits of using all 32 bits.