From: Mateusz Polchlopek <mateusz.polchlopek@intel.com>
To: intel-wired-lan@lists.osuosl.org
Cc: Jacob Keller <jacob.e.keller@intel.com>,
netdev@vger.kernel.org, Rahul Rameshbabu <rrameshbabu@nvidia.com>,
Wojciech Drewek <wojciech.drewek@intel.com>,
Mateusz Polchlopek <mateusz.polchlopek@intel.com>
Subject: [Intel-wired-lan] [PATCH iwl-next v6 01/12] virtchnl: add support for enabling PTP on iAVF
Date: Tue, 28 May 2024 07:22:50 -0400 [thread overview]
Message-ID: <20240528112301.5374-2-mateusz.polchlopek@intel.com> (raw)
In-Reply-To: <20240528112301.5374-1-mateusz.polchlopek@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
Add support for allowing a VF to enable PTP feature - Rx timestamps
The new capability is gated by VIRTCHNL_VF_CAP_PTP, which must be
set by the VF to request access to the new operations. In addition, the
VIRTCHNL_OP_1588_PTP_CAPS command is used to determine the specific
capabilities available to the VF.
This support includes the following additional capabilities:
* Rx timestamps enabled in the Rx queues (when using flexible advanced
descriptors)
* Read access to PHC time over virtchnl using
VIRTCHNL_OP_1588_PTP_GET_TIME
Extra space is reserved in most structures to allow for future
extension (like set clock, Tx timestamps). Additional opcode numbers
are reserved and space in the virtchnl_ptp_caps structure is
specifically set aside for this.
Additionally, each structure has some space reserved for future
extensions to allow some flexibility.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
Reviewed-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>
Signed-off-by: Mateusz Polchlopek <mateusz.polchlopek@intel.com>
---
include/linux/avf/virtchnl.h | 66 ++++++++++++++++++++++++++++++++++++
1 file changed, 66 insertions(+)
diff --git a/include/linux/avf/virtchnl.h b/include/linux/avf/virtchnl.h
index 8e177b67e82f..5003d29e3f5b 100644
--- a/include/linux/avf/virtchnl.h
+++ b/include/linux/avf/virtchnl.h
@@ -151,6 +151,9 @@ enum virtchnl_ops {
VIRTCHNL_OP_DISABLE_VLAN_STRIPPING_V2 = 55,
VIRTCHNL_OP_ENABLE_VLAN_INSERTION_V2 = 56,
VIRTCHNL_OP_DISABLE_VLAN_INSERTION_V2 = 57,
+ /* opcode 58 and 59 are reserved */
+ VIRTCHNL_OP_1588_PTP_GET_CAPS = 60,
+ VIRTCHNL_OP_1588_PTP_GET_TIME = 61,
VIRTCHNL_OP_MAX,
};
@@ -260,6 +263,7 @@ VIRTCHNL_CHECK_STRUCT_LEN(16, virtchnl_vsi_resource);
#define VIRTCHNL_VF_OFFLOAD_RX_FLEX_DESC BIT(26)
#define VIRTCHNL_VF_OFFLOAD_ADV_RSS_PF BIT(27)
#define VIRTCHNL_VF_OFFLOAD_FDIR_PF BIT(28)
+#define VIRTCHNL_VF_CAP_PTP BIT(31)
#define VF_BASE_MODE_OFFLOADS (VIRTCHNL_VF_OFFLOAD_L2 | \
VIRTCHNL_VF_OFFLOAD_VLAN | \
@@ -1405,6 +1409,62 @@ struct virtchnl_fdir_del {
VIRTCHNL_CHECK_STRUCT_LEN(12, virtchnl_fdir_del);
+#define VIRTCHNL_1588_PTP_CAP_RX_TSTAMP BIT(1)
+#define VIRTCHNL_1588_PTP_CAP_READ_PHC BIT(2)
+
+/**
+ * struct virtchnl_ptp_caps
+ *
+ * Structure that defines the PTP capabilities available to the VF. The VF
+ * sends VIRTCHNL_OP_1588_PTP_GET_CAPS, and must fill in the ptp_caps field
+ * indicating what capabilities it is requesting. The PF will respond with the
+ * same message with the virtchnl_ptp_caps structure indicating what is
+ * enabled for the VF.
+ *
+ * @caps: On send, VF sets what capabilities it requests. On reply, PF
+ * indicates what has been enabled for this VF. The PF shall not set
+ * bits which were not requested by the VF.
+ * @rsvd: Reserved bits for future extension.
+ *
+ * PTP capabilities
+ *
+ * VIRTCHNL_1588_PTP_CAP_RX_TSTAMP indicates that the VF receive queues have
+ * receive timestamps enabled in the flexible descriptors. Note that this
+ * requires a VF to also negotiate to enable advanced flexible descriptors in
+ * the receive path instead of the default legacy descriptor format.
+ *
+ * VIRTCHNL_1588_PTP_CAP_READ_PHC indicates that the VF may read the PHC time
+ * via the VIRTCHNL_OP_1588_PTP_GET_TIME command.
+ *
+ * Note that in the future, additional capability flags may be added which
+ * indicate additional extended support. All fields marked as reserved by this
+ * header will be set to zero. VF implementations should verify this to ensure
+ * that future extensions do not break compatibility.
+ */
+struct virtchnl_ptp_caps {
+ u32 caps;
+ u8 rsvd[44];
+};
+VIRTCHNL_CHECK_STRUCT_LEN(48, virtchnl_ptp_caps);
+
+/**
+ * struct virtchnl_phc_time
+ * @time: PHC time in nanoseconds
+ * @rsvd: Reserved for future extension
+ *
+ * Structure received with VIRTCHNL_OP_1588_PTP_GET_TIME. Contains the 64bits
+ * of PHC clock time in * nanoseconds.
+ *
+ * VIRTCHNL_OP_1588_PTP_GET_TIME may be sent to request the current time of
+ * the PHC. This op is available in case direct access via the PHC registers
+ * is not available.
+ */
+struct virtchnl_phc_time {
+ u64 time;
+ u8 rsvd[8];
+};
+VIRTCHNL_CHECK_STRUCT_LEN(16, virtchnl_phc_time);
+
#define __vss_byone(p, member, count, old) \
(struct_size(p, member, count) + (old - 1 - struct_size(p, member, 0)))
@@ -1626,6 +1686,12 @@ virtchnl_vc_validate_vf_msg(struct virtchnl_version_info *ver, u32 v_opcode,
case VIRTCHNL_OP_DISABLE_VLAN_INSERTION_V2:
valid_len = sizeof(struct virtchnl_vlan_setting);
break;
+ case VIRTCHNL_OP_1588_PTP_GET_CAPS:
+ valid_len = sizeof(struct virtchnl_ptp_caps);
+ break;
+ case VIRTCHNL_OP_1588_PTP_GET_TIME:
+ valid_len = sizeof(struct virtchnl_phc_time);
+ break;
/* These are always errors coming from the VF. */
case VIRTCHNL_OP_EVENT:
case VIRTCHNL_OP_UNKNOWN:
--
2.38.1
next prev parent reply other threads:[~2024-05-28 11:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-28 11:22 [Intel-wired-lan] [PATCH iwl-next v6 00/12] Add support for Rx timestamping for both ice and iavf drivers Mateusz Polchlopek
2024-05-28 11:22 ` Mateusz Polchlopek [this message]
2024-05-28 11:22 ` [Intel-wired-lan] [PATCH iwl-next v6 02/12] ice: support Rx timestamp on flex descriptor Mateusz Polchlopek
2024-05-28 11:22 ` [Intel-wired-lan] [PATCH iwl-next v6 03/12] virtchnl: add enumeration for the rxdid format Mateusz Polchlopek
2024-05-28 11:22 ` [Intel-wired-lan] [PATCH iwl-next v6 04/12] iavf: add support for negotiating flexible RXDID format Mateusz Polchlopek
2024-05-28 11:22 ` [Intel-wired-lan] [PATCH iwl-next v6 05/12] iavf: negotiate PTP capabilities Mateusz Polchlopek
2024-05-28 11:22 ` [Intel-wired-lan] [PATCH iwl-next v6 06/12] iavf: add initial framework for registering PTP clock Mateusz Polchlopek
2024-05-28 11:22 ` [Intel-wired-lan] [PATCH iwl-next v6 07/12] iavf: add support for indirect access to PHC time Mateusz Polchlopek
2024-05-28 11:22 ` [Intel-wired-lan] [PATCH iwl-next v6 08/12] iavf: periodically cache " Mateusz Polchlopek
2024-05-28 11:22 ` [Intel-wired-lan] [PATCH iwl-next v6 09/12] iavf: refactor iavf_clean_rx_irq to support legacy and flex descriptors Mateusz Polchlopek
2024-05-28 11:22 ` [Intel-wired-lan] [PATCH iwl-next v6 10/12] iavf: Implement checking DD desc field Mateusz Polchlopek
2024-05-28 11:23 ` [Intel-wired-lan] [PATCH iwl-next v6 11/12] iavf: handle SIOCSHWTSTAMP and SIOCGHWTSTAMP Mateusz Polchlopek
2024-05-28 20:00 ` Jakub Kicinski
2024-05-28 23:54 ` Keller, Jacob E
2024-05-29 13:12 ` Mateusz Polchlopek
2024-05-28 11:23 ` [Intel-wired-lan] [PATCH iwl-next v6 12/12] iavf: add support for Rx timestamps to hotpath Mateusz Polchlopek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240528112301.5374-2-mateusz.polchlopek@intel.com \
--to=mateusz.polchlopek@intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jacob.e.keller@intel.com \
--cc=netdev@vger.kernel.org \
--cc=rrameshbabu@nvidia.com \
--cc=wojciech.drewek@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox