@@ -836,6 +836,9 @@ attribute-sets:
-
name: tx-err
type: uint
+ -
+ name: tx-onestep-pkts-unconfirmed
+ type: uint
-
name: tsinfo
attr-cnt-name: __ethtool-a-tsinfo-cnt
@@ -1266,11 +1266,17 @@ would be empty (no bit set).
Additional hardware timestamping statistics response contents:
- ===================================== ====== ===================================
- ``ETHTOOL_A_TS_STAT_TX_PKTS`` uint Packets with Tx HW timestamps
- ``ETHTOOL_A_TS_STAT_TX_LOST`` uint Tx HW timestamp not arrived count
- ``ETHTOOL_A_TS_STAT_TX_ERR`` uint HW error request Tx timestamp count
- ===================================== ====== ===================================
+ ================================================== ====== =====================
+ ``ETHTOOL_A_TS_STAT_TX_PKTS`` uint Packets with Tx
+ HW timestamps
+ ``ETHTOOL_A_TS_STAT_TX_LOST`` uint Tx HW timestamp
+ not arrived count
+ ``ETHTOOL_A_TS_STAT_TX_ERR`` uint HW error request
+ Tx timestamp count
+ ``ETHTOOL_A_TS_STAT_TX_ONESTEP_PKTS_UNCONFIRMED`` uint Packets with one-step
+ HW TX timestamps with
+ unconfirmed delivery
+ ================================================== ====== =====================
CABLE_TEST
==========
@@ -529,6 +529,12 @@ struct ethtool_rmon_stats {
/**
* struct ethtool_ts_stats - HW timestamping statistics
* @pkts: Number of packets successfully timestamped by the hardware.
+ * @onestep_pkts_unconfirmed: Number of PTP packets with one-step TX
+ * timestamping that were sent, but for which the
+ * device offers no confirmation whether they made
+ * it onto the wire and the timestamp was inserted
+ * in the originTimestamp or correctionField, or
+ * not.
* @lost: Number of hardware timestamping requests where the timestamping
* information from the hardware never arrived for submission with
* the skb.
@@ -541,6 +547,7 @@ struct ethtool_rmon_stats {
struct ethtool_ts_stats {
struct_group(tx_stats,
u64 pkts;
+ u64 onestep_pkts_unconfirmed;
u64 lost;
u64 err;
);
@@ -380,6 +380,7 @@ enum {
ETHTOOL_A_TS_STAT_TX_PKTS,
ETHTOOL_A_TS_STAT_TX_LOST,
ETHTOOL_A_TS_STAT_TX_ERR,
+ ETHTOOL_A_TS_STAT_TX_ONESTEP_PKTS_UNCONFIRMED,
__ETHTOOL_A_TS_STAT_CNT,
ETHTOOL_A_TS_STAT_MAX = (__ETHTOOL_A_TS_STAT_CNT - 1)
@@ -116,6 +116,8 @@ static int tsinfo_put_stats(struct sk_buff *skb,
if (tsinfo_put_stat(skb, stats->tx_stats.pkts,
ETHTOOL_A_TS_STAT_TX_PKTS) ||
+ tsinfo_put_stat(skb, stats->tx_stats.onestep_pkts_unconfirmed,
+ ETHTOOL_A_TS_STAT_TX_ONESTEP_PKTS_UNCONFIRMED) ||
tsinfo_put_stat(skb, stats->tx_stats.lost,
ETHTOOL_A_TS_STAT_TX_LOST) ||
tsinfo_put_stat(skb, stats->tx_stats.err,
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> --- Documentation/netlink/specs/ethtool.yaml | 3 +++ Documentation/networking/ethtool-netlink.rst | 16 +++++++++++----- include/linux/ethtool.h | 7 +++++++ include/uapi/linux/ethtool_netlink_generated.h | 1 + net/ethtool/tsinfo.c | 2 ++ 5 files changed, 24 insertions(+), 5 deletions(-)