From: Vadim Fedorenko <vadim.fedorenko@linux.dev>
To: Michael Chan <michael.chan@broadcom.com>
Cc: Pavan Chebbi <pavan.chebbi@broadcom.com>,
Jakub Kicinski <kuba@kernel.org>,
Andrew Lunn <andrew+netdev@lunn.ch>,
Paolo Abeni <pabeni@redhat.com>,
"David S. Miller" <davem@davemloft.net>,
netdev@vger.kernel.org,
Richard Cochran <richardcochran@gmail.com>
Subject: Re: [PATCH net-next v2 1/2] bnxt_en: cache only 24 bits of hw counter
Date: Fri, 25 Oct 2024 22:53:22 +0100 [thread overview]
Message-ID: <e89385ae-7d77-4890-8c80-b5904ac394b4@linux.dev> (raw)
In-Reply-To: <CACKFLikgQxsYQxkMZdXDusS=0=rZi8g9Fn6-nEnVw+g-hgzf4g@mail.gmail.com>
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.
next prev parent reply other threads:[~2024-10-25 21:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-25 19:47 [PATCH net-next v2 1/2] bnxt_en: cache only 24 bits of hw counter Vadim Fedorenko
2024-10-25 19:47 ` [PATCH net-next v2 2/2] bnxt_en: replace PTP spinlock with seqlock Vadim Fedorenko
2024-10-26 11:23 ` kernel test robot
2024-10-25 21:31 ` [PATCH net-next v2 1/2] bnxt_en: cache only 24 bits of hw counter Michael Chan
2024-10-25 21:53 ` Vadim Fedorenko [this message]
2024-10-25 22:13 ` Michael Chan
2024-10-26 22:20 ` Vadim Fedorenko
2024-10-28 16:18 ` Michael Chan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e89385ae-7d77-4890-8c80-b5904ac394b4@linux.dev \
--to=vadim.fedorenko@linux.dev \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=michael.chan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pavan.chebbi@broadcom.com \
--cc=richardcochran@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.