[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <eda6a7b5-8ac7-4602-ba4d-ab102e2a8005@intel.com>
Date: Wed, 26 Mar 2025 13:31:59 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: Kamil Zaripov <zaripov-kamil@...ide.ai>, Vadim Fedorenko
<vadim.fedorenko@...ux.dev>
CC: Michael Chan <michael.chan@...adcom.com>, Pavan Chebbi
<pavan.chebbi@...adcom.com>, Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: bnxt_en: Incorrect tx timestamp report
On 3/26/2025 6:50 AM, Kamil Zaripov wrote:
>
>
>> On 25 Mar 2025, at 12:41, Vadim Fedorenko <vadim.fedorenko@...ux.dev> wrote:
>>
>> On 25/03/2025 10:13, Kamil Zaripov wrote:
>>>
>>> I guess I don’t understand how does it work. Am I right that if userspace program changes frequency of PHC devices 0,1,2,3 (one for each port present in NIC) driver will send PHC frequency change 4 times but firmware will drop 3 of these frequency change commands and will pick up only one? How can I understand which PHC will actually represent adjustable clock and which one is phony?
>>
>> It can be any of PHC devices, mostly the first to try to adjust will be used.
>
> I believe that randomly selecting one of the PHC clock to control actual PHC in NIC and directing commands received on other clocks to the /dev/null is quite unexpected behavior for the userspace applications.
>
At the very least this should somehow be predictable. Better would be
for software to manage this and report only one PHC to userspace, with
each netdev reporting the PHC associated via get_ts_info
Powered by blists - more mailing lists