From: Vadim Fedorenko <vadim.fedorenko@linux.dev>
To: Pavan Chebbi <pavan.chebbi@broadcom.com>,
Kamil Zaripov <zaripov-kamil@avride.ai>
Cc: netdev@vger.kernel.org, Michael Chan <michael.chan@broadcom.com>,
Andrew Gospodarek <andrew.gospodarek@broadcom.com>
Subject: Re: bnxt_en: Incorrect tx timestamp report
Date: Thu, 20 Mar 2025 16:26:23 +0000 [thread overview]
Message-ID: <1dc9d113-b4c8-4fd0-8ebc-e4125a0816ee@linux.dev> (raw)
In-Reply-To: <CALs4sv3DtyBSqx0v_FHFUPrB+w7GOsheNOEa0pm6N4xNf-4JUA@mail.gmail.com>
On 20/03/2025 15:56, Pavan Chebbi wrote:
> On Thu, Mar 20, 2025 at 8:07 PM Kamil Zaripov <zaripov-kamil@avride.ai> wrote:
>>
>> Hi all,
>>
>> I've encountered a bug in the bnxt_en driver and I am unsure about the correct approach to fix it. Every 2^48 nanoseconds (or roughly 78.19 hours) there is a probability that the hardware timestamp for a sent packet may deviate by either 2^48 nanoseconds less or 2^47 nanoseconds more compared to the actual time.
>>
>> This issue likely occurs within the bnxt_async_event_process function when handling the ASYNC_EVENT_CMPL_EVENT_ID_PHC_UPDATE event. It appears that the payload of this event contains bits 48–63 of the PHC timer counter. During event handling, this function reads bits 0–47 of the same counter to combine them and subsequently updates the cycle_last field within the struct timecounter. The relevant code can be found here:
>> https://elixir.bootlin.com/linux/v6.13.7/source/drivers/net/ethernet/broadcom/bnxt/bnxt.c#L2829-L2833
>>
>> The issue arises if bits 48–63 of the PHC counter increment by 1 between sending the ASYNC_EVENT_CMPL_EVENT_ID_PHC_UPDATE event and its actual handling by the driver. In such a case, cycle_last becomes approximately 2^48 nanoseconds behind the real-time value.
>>
>> A possibly related issue involves the BCM57502 network card, which seemingly possesses only a single PHC device. However, the bnxt_en driver creates four PHC Linux devices when operating in quad-port mode. Consequently, clock synchronization daemons like phc2sys attempt to independently synchronize the system clock to each of these four PHC clocks. This scenario can lead to unstable synchronization and might also trigger additional ASYNC_EVENT_CMPL_EVENT_ID_PHC_UPDATE events.
>>
>> Given these issues, I have two questions:
>>
>> 1. Would it be beneficial to modify the bnxt_en driver to create only a single PHC Linux device for network cards that physically have only one PHC?
>
> It's not clear to me if you are facing this issue when the PHC is
> shared between multiple hosts or if you are running a single host NIC.
> In the cases where a PHC is shared across multiple hosts, the driver
> identifies such a configuration and switches to non-real time PHC
> access mode.
> https://web.git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/drivers/net/ethernet/broadcom/bnxt?id=85036aee1938d65da4be6ae1bc7e5e7e30b567b9
> If you are using a configuration like the multi host, can you please
> make sure you have this patch?
>
> Let me know if you are not in the multi-host config. Do post the
> ethtool -i output to help know the firmware version.
AFAIU, the setup is single host, but multi port NIC, which exports
several PTP devices, all of them are using RTC mode. But as HW has
single physical PHC, it's not possible to properly discipline all
of PTP devices in parallel. I think mlx5 was adjusted to export only
single PHC device for multi-port configuration because of the very same
reasons.
next prev parent reply other threads:[~2025-03-20 16:26 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-20 14:35 bnxt_en: Incorrect tx timestamp report Kamil Zaripov
2025-03-20 14:48 ` Andrew Lunn
[not found] ` <CAGtf3ibFAidzpFKm1o5zmZF3Neu8MgdXp_n_Wt+mv8M9YZhhug@mail.gmail.com>
2025-03-20 15:14 ` Kamil Zaripov
2025-03-20 16:21 ` Vadim Fedorenko
2025-03-20 15:56 ` Pavan Chebbi
2025-03-20 16:21 ` Kamil Zaripov
2025-03-20 16:26 ` Vadim Fedorenko [this message]
2025-03-20 17:11 ` Jacob Keller
2025-03-21 15:17 ` Kamil Zaripov
2025-03-21 17:33 ` Michael Chan
2025-03-24 15:04 ` Pavan Chebbi
2025-03-25 10:13 ` Kamil Zaripov
2025-03-25 10:41 ` Vadim Fedorenko
2025-03-25 12:24 ` Pavan Chebbi
2025-03-26 13:50 ` Kamil Zaripov
2025-03-26 20:31 ` Jacob Keller
2025-03-27 13:16 ` Pavan Chebbi
2025-04-01 20:17 ` Keller, Jacob E
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=1dc9d113-b4c8-4fd0-8ebc-e4125a0816ee@linux.dev \
--to=vadim.fedorenko@linux.dev \
--cc=andrew.gospodarek@broadcom.com \
--cc=michael.chan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=pavan.chebbi@broadcom.com \
--cc=zaripov-kamil@avride.ai \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).