forked from mirrors/linux
6a128cdf19
For packets with two-step timestamp requests, the hardware timestamp comes back to the driver through a confirmation mechanism of sorts, which allows the driver to confidently bump the successful "pkts" counter. For one-step PTP, the NIC is supposed to autonomously insert its hardware TX timestamp in the packet headers while simultaneously transmitting it. There may be a confirmation that this was done successfully, or there may not. None of the current drivers which implement ethtool_ops :: get_ts_stats() also support HWTSTAMP_TX_ONESTEP_SYNC or HWTSTAMP_TX_ONESTEP_SYNC, so it is a bit unclear which model to follow. But there are NICs, such as DSA, where there is no transmit confirmation at all. Here, it would be wrong / misleading to increment the successful "pkts" counter, because one-step PTP packets can be dropped on TX just like any other packets. So introduce a special counter which signifies "yes, an attempt was made, but we don't know whether it also exited the port or not". I expect that for one-step PTP packets where a confirmation is available, the "pkts" counter would be bumped. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Jakub Kicinski <kuba@kernel.org> Link: https://patch.msgid.link/20250116104628.123555-2-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|---|---|---|
| .. | ||
| devlink.yaml | ||
| dpll.yaml | ||
| ethtool.yaml | ||
| fou.yaml | ||
| handshake.yaml | ||
| mptcp_pm.yaml | ||
| net_shaper.yaml | ||
| netdev.yaml | ||
| nfsd.yaml | ||
| nftables.yaml | ||
| nlctrl.yaml | ||
| ovs_datapath.yaml | ||
| ovs_flow.yaml | ||
| ovs_vport.yaml | ||
| rt_addr.yaml | ||
| rt_link.yaml | ||
| rt_neigh.yaml | ||
| rt_route.yaml | ||
| rt_rule.yaml | ||
| tc.yaml | ||
| tcp_metrics.yaml | ||
| team.yaml | ||