You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.typeTimestampInfostruct {
HardwareRxboolHardwareTxboolSoftwareRxboolSoftwareTxboolSoftwareSystemboolHardwareRawboolPTPClockIndexint
}
// TimestampingInfo essentiall does `ethtool -T DEV` and decodes the response into *TimestampInfofunc (c*Client) TimestampingInfo(ifiInterface) (*TimestampInfo, error) {
// TBD
}
It looks like
ethtool
can support querying a link to find out what kind of time-stamping capabilities it has with the-T
option.The results of this query could then be used in
setsockopt
to enable these capabilities when usingsendmsg
andrecvmsg
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 asRecvmsg
andSendmsg
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:
Additional References:
The text was updated successfully, but these errors were encountered: