It looks like ethtool can support querying a link to find out what kind of time-stamping capabilities it has with the -T option.
> ethtool -T enp1s0
Time stamping parameters for enp1s0:
Capabilities:
hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE)
software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE)
hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE)
software-receive (SOF_TIMESTAMPING_RX_SOFTWARE)
software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
off (HWTSTAMP_TX_OFF)
on (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
none (HWTSTAMP_FILTER_NONE)
all (HWTSTAMP_FILTER_ALL)
The results of this query could then be used in setsockopt to enable these capabilities when using sendmsg and recvmsg and then parsing the control message that gets returned to get timestamps of userspace, kernel, and hardware. Enabling these options would work with https://pkg.go.dev/github.com/mdlayher/socket as long as Recvmsg and Sendmsg are used and there is a utility function for assisting in parsing the control message, but this is outside the scope of this issue.
Would you be open to adding support for this query? I propose something along the lines of:
// TimestampInfo holds the decoded response from `ethtool -T`
// NOTE: I am not suggesting that this is the struct we should use, but
// it is similar to how I have a working version already.
type TimestampInfo struct {
HardwareRx bool
HardwareTx bool
SoftwareRx bool
SoftwareTx bool
SoftwareSystem bool
HardwareRaw bool
PTPClockIndex int
}
// TimestampingInfo essentiall does `ethtool -T DEV` and decodes the response into *TimestampInfo
func (c *Client) TimestampingInfo(ifi Interface) (*TimestampInfo, error) {
// TBD
}Additional References:
It looks like
ethtoolcan support querying a link to find out what kind of time-stamping capabilities it has with the-Toption.The results of this query could then be used in
setsockoptto enable these capabilities when usingsendmsgandrecvmsgand then parsing the control message that gets returned to get timestamps of userspace, kernel, and hardware. Enabling these options would work with https://pkg.go.dev/github.com/mdlayher/socket as long asRecvmsgandSendmsgare used and there is a utility function for assisting in parsing the control message, but this is outside the scope of this issue.Would you be open to adding support for this query? I propose something along the lines of:
Additional References: