On Tue, Jun 04, 2024 at 09:13:55AM -0400, Mateusz Polchlopek wrote: > From: Jacob Keller <[email protected]> > > Implement support for reading the PHC time indirectly via the > VIRTCHNL_OP_1588_PTP_GET_TIME operation. > > Based on some simple tests with ftrace, the latency of the indirect > clock access appears to be about ~110 microseconds. This is due to the > cost of preparing a message to send over the virtchnl queue. > > This is expected, due to the increased jitter caused by sending messages > over virtchnl. It is not easy to control the precise time that the > message is sent by the VF, or the time that the message is responded to > by the PF, or the time that the message sent from the PF is received by > the VF. > > For sending the request, note that many PTP related operations will > require sending of VIRTCHNL messages. Instead of adding a separate AQ > flag and storage for each operation, setup a simple queue mechanism for > queuing up virtchnl messages. > > Each message will be converted to a iavf_ptp_aq_cmd structure which ends > with a flexible array member. A single AQ flag is added for processing > messages from this queue. In principle this could be extended to handle > arbitrary virtchnl messages. For now it is kept to PTP-specific as the > need is primarily for handling PTP-related commands. > > Use this to implement .gettimex64 using the indirect method via the > virtchnl command. The response from the PF is processed and stored into > the cached_phc_time. A wait queue is used to allow the PTP clock gettime > request to sleep until the message is sent from the PF. > > Signed-off-by: Jacob Keller <[email protected]> > Reviewed-by: Wojciech Drewek <[email protected]> > Reviewed-by: Rahul Rameshbabu <[email protected]> > Signed-off-by: Mateusz Polchlopek <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
