On 2/11/22 8:12 AM, Martin KaFai Lau wrote:
[...]
The current use case is to keep the TCP mono delivery_time (EDT) and
to be used with sch_fq. A later patch will also allow tc-bpf@ingress
to read and change the mono delivery_time.
In the future, another bit (e.g. skb->user_delivery_time) can be added
[...]
---
include/linux/skbuff.h | 13 +++++++++++++
net/bridge/netfilter/nf_conntrack_bridge.c | 5 +++--
net/ipv4/ip_output.c | 7 +++++--
net/ipv4/tcp_output.c | 16 +++++++++-------
net/ipv6/ip6_output.c | 5 +++--
net/ipv6/netfilter.c | 5 +++--
net/ipv6/tcp_ipv6.c | 2 +-
7 files changed, 37 insertions(+), 16 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index a5adbf6b51e8..32c793de3801 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -747,6 +747,10 @@ typedef unsigned char *sk_buff_data_t;
* @dst_pending_confirm: need to confirm neighbour
* @decrypted: Decrypted SKB
* @slow_gro: state present at GRO time, slower prepare step required
+ * @mono_delivery_time: When set, skb->tstamp has the
+ * delivery_time in mono clock base (i.e. EDT). Otherwise, the
+ * skb->tstamp has the (rcv) timestamp at ingress and
+ * delivery_time at egress.
* @napi_id: id of the NAPI struct this skb came from
* @sender_cpu: (aka @napi_id) source CPU in XPS
* @secmark: security marking
@@ -917,6 +921,7 @@ struct sk_buff {
__u8 decrypted:1;
#endif
__u8 slow_gro:1;
+ __u8 mono_delivery_time:1;
Don't you also need to extend sch_fq to treat any non-mono_delivery_time marked
skb similar as if it hadn't been marked with a delivery time?
