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

[Vadim Fedorenko <vadim.fedorenko@linux.dev>]

On 25/10/2024 23:13, Michael Chan wrote:
> On Fri, Oct 25, 2024 at 2:53 PM Vadim Fedorenko
> <vadim.fedorenko@linux.dev> wrote:
>>
>> On 25/10/2024 22:31, Michael Chan wrote:
>>> On Fri, Oct 25, 2024 at 12:48 PM Vadim Fedorenko <vadfed@meta.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.
> 
> I agree the extra bits have no value other than to fill the 32-bit
> field.  But it should not affect the frequency of caching
> ptp->old_time.  It should be updated in bnxt_ptp_ts_aux_work() at a
> fixed interval (1 second).

Ok, BNXT_LO_TIMER_MASK/BNXT_HI_TIMER_MASK use 24 bits only. I don't see
any reason to keep more bits out of 48 bit of counter and I tried to be
consistent across the code. It doesn't matter in terms of performance
should we shift 16 or 24 bits. But because there will be another version
(I forgot to remove one variable), I can change the code to fill 32-bit
field if you insist.