STRUCT VIRTCHNL_PTP_CAPS(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– struct virtchnl_ptp_caps(9) πŸ’–

okay bestie, welcome to the Kernel API Manual section β€” this one's about struct virtchnl_ptp_caps, and it's honestly kinda iconic once you get past the acronym soup 🌸


✨ NAME ✨

struct virtchnl_ptp_caps β€” literally just Defines the PTP caps available to the VF. that's it, that's the whole vibe πŸŽ€


✨ SYNOPSIS ✨

struct virtchnl_ptp_caps {
    u32 caps;
    u8 rsvd[44];
 };

like, two fields. two. and somehow a whole negotiation protocol lives in there πŸ’…


✨ Members ✨

  • caps β€” okay so on send, the VF sets what capabilities it requests (like, this is the VF shooting its shot 🫢). On reply, the PF indicates what has actually been enabled for this VF. and here's the important part, no cap: The PF shall not set bits which were not requested by the VF. the PF cannot just gift you features you never asked for, that's not how this works ✨
  • rsvd β€” Reserved bits for future extension. it's giving "we saved you a seat at the table" πŸŽ€

✨ Description ✨

okay so this is the structure that defines the PTP capabilities available to the VF. the flow is: the VF sends VIRTCHNL_OP_1588_PTP_GET_CAPS, and it must fill in the ptp_caps field indicating what capabilities it is requesting. then the PF will respond with the same message, with the virtchnl_ptp_caps structure indicating what is enabled for the VF. it's a whole back-and-forth, a little conversation, a negotiation era πŸ˜­πŸ’–

Now let's talk about the cap flags, because these matter:

VIRTCHNL_1588_PTP_CAP_RX_TSTAMP indicates that the VF receive queues have receive timestamps enabled in the flexible descriptors. but β€” and this is the catch, lowkey important β€” this requires a VF to also negotiate to enable advanced flexible descriptors in the receive path instead of the default legacy descriptor format. so like, you can't just take the timestamp cap and run, you gotta do the descriptor negotiation too, iykyk πŸ¦‹

VIRTCHNL_1588_PTP_CAP_READ_PHC indicates that the VF may read the PHC time via the VIRTCHNL_OP_1588_PTP_GET_TIME command. clock reading privileges, unlocked πŸ”₯

and now the future-proofing paragraph, bestie, don't skip it: 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. like, please actually check those reserved fields are zero, your future self will thank you πŸ™ˆ

✨ SEE ALSO ✨


and that's the page, bestie πŸ§šπŸ’œ this absolute gem lives in ./include/linux/net/intel and it's dated October 2026 β€” go read it again when you forget, it's literally right there β­πŸ‘‘

πŸ“¦ where this page comes from