> -----Original Message-----
> From: Hal Murray <halmur...@sonic.net>
> Sent: Wednesday, July 07, 2021 8:48 PM
> To: Keller, Jacob E <jacob.e.kel...@intel.com>
> Cc: Richard Cochran <richardcoch...@gmail.com>; linuxptp-
> de...@lists.sourceforge.net; Hal Murray <halmur...@sonic.net>
> Subject: Re: [Linuxptp-devel] tx_timestamp_timeout default
>
>
> jacob.e.kel...@intel.com said:
> > We get into the kthread function within a few hundred usec or less, and then
> > the firmware read takes a long time, sometimes over 2 milliseconds.
>
> Why is it taking so long?
>
It's not entirely clear.
> How long does it take when things go well? Is there anything complicated
> going on with a "firmware read"?
>
We have to send an admin queue command to firmware, which then reads the
register, and then replies back.
> Is there a software lock, maybe because some other code is using related
> hardware resources? Is the thread not getting scheduled?
>
I captured time using trace_printk in the function after the lock was acquired
and we were consistently <200 usec to get to the point of sending the command
to firmware. Unfortunately, firmware response time is slow and can take up to a
couple msec to respond.
On E822 devices it's not as significant problem because we're able to read the
PHY register using a separate mechanism that isn't mediated by firmware.
I'm not sure how to debug what's going on in firmware.
> --
> These are my opinions. I hate spam.
>
>
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
