On Tue, Jun 25, 2019 at 1:02 AM Sudarsana Reddy Kalluru <skall...@marvell.com> wrote: > > Thanks for your changes and time on this. In general time-latching happens in > couple or more milliseconds (even in some 100s of usec) under the normal > traffic conditions. With this approach, there's a possibility that every > packet has to wait for atleast 50ms for the timestamping. This in turn > affects the wait-queue (of packets to be timestamped) at hardware as next TS > recording happens only after the register is freed/read. And also, it incurs > some latency for the ptp applications. > > PTP thread is consuming time may be due to the debug messages in this error > path, which you are planning address already (thanks!!). > "Also, I've dropped the PTP "outstanding, etc" messages to debug-level, > they're quite flooding my log. > Do you see cpu hog even after removing this message? In such case we may need > to think of other alternatives such as sleep for 1 ms. > Just for the info, the approach continuous-poll-for-timestamp() is used ixgbe > driver (ixgbe_ptp_tx_hwtstamp_work()) as well. >
Thanks again for the good insights Sudarsana! I'll do some experiments dropping all messages and checking if the ptp thread is still consuming a lot of CPU (I believe so). In this case, I'll rework the approach by starting the delays in 1ms to avoid impacting the HW wait-queue and causing delays in ptp applications. Cheers, Guilherme
