Re: [PATCH v4 net-next 1/8] net: Add skb->mono_delivery_time to distinguish mono delivery_time from (rcv) timestamp

[Daniel Borkmann <daniel@iogearbox.net>]

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?