> -----Original Message-----
> From: Richard Cochran <richardcoch...@gmail.com>
> Sent: Wednesday, July 07, 2021 4:29 PM
> To: Keller, Jacob E <jacob.e.kel...@intel.com>
> Cc: linuxptp-devel@lists.sourceforge.net
> Subject: Re: [Linuxptp-devel] tx_timestamp_timeout default
>
> On Wed, Jul 07, 2021 at 10:22:59PM +0000, Keller, Jacob E wrote:
> > I am wondering if there would be support for either (a) increasing
> > the default timeout, or (b) adding something to the PTP get
> > capabilities for indicating a sort of default timeout for the
> > device, and if it's not set in the config then the default timeout
> > is used?
>
> I wouldn't mind increasing the default.
>
> I doubt capabilities would help, because much depends on the system
> being used. We really should replace "work" with the kthread in the
> drivers, and then tell people to give the kthreads sched_fifo using
> chrt.
>
> Thanks,
> Richard
I implemented this as a kthread in the ice driver, and I am hoping to get some
time to fix the other Intel drivers.
Note that ice did not use the ptp do_aux_work kthread because of needing to
handle multiple ports simultaneously across multiple PFs (the clock is shared
across all PFs, so they don't all have access to the do_aux_work function which
is only controlled by a single PF which allocated the clock).
Either way, I found that whether I used a kthread or not I was unable to avoid
the timeout issue with ice hardware because the delay is caused by the method
we must use to access the Tx timestamps :( 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.
Ok. I'll propose a patch to increase the default.
Thanks,
Jake
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
