Hi,

su, 2025-02-09 kello 22:29 -0500, Willem de Bruijn kirjoitti:

Pauli Virtanen wrote:

quoted

 1.3.2 Timestamp Reporting
 ^^^^^^^^^^^^^^^^^^^^^^^^^

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index bb2b751d274a..3707c9075ae9 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h

@@ -489,10 +489,14 @@ enum {
 
 	/* generate software time stamp when entering packet scheduling */
 	SKBTX_SCHED_TSTAMP = 1 << 6,
+
+	/* generate software time stamp on packet tx completion */
+	SKBTX_COMPLETION_TSTAMP = 1 << 7,
 };
 
 #define SKBTX_ANY_SW_TSTAMP	(SKBTX_SW_TSTAMP    | \
-				 SKBTX_SCHED_TSTAMP)
+				 SKBTX_SCHED_TSTAMP | \
+				 SKBTX_COMPLETION_TSTAMP)

These fields are used in the skb_shared_info tx_flags field.
Which is a very scarce resource. This takes the last available bit.
That is my only possible concern: the opportunity cost.

One alternative here could be:

Make SOF_TIMESTAMPING_TX_COMPLETION available only as a socket option,
and make it emit COMPLETION tstamp exactly for those packets that also
have SOF_TIMESTAMPING_TX_SOFTWARE enabled. User apps can then still
timestamp only selected packets via CMSG, however the choice between
SND and SND+COMPLETION is socket-wide. The API is then less uniform,
but probably usable in practice, although some use cases may not be
interested in the extra SND tstamps.

IIUC, sizeof skb_shared_info cannot be easily changed and I'm not sure
if there is room left there. So if the option of putting it into
protocol-specific skb cb is also out, then I'm not sure what the plan
here should be.

-- 
Pauli Virtanen