All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin KaFai Lau <martin.lau@linux.dev>
To: Jason Xing <kerneljasonxing@gmail.com>
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
	pabeni@redhat.com, dsahern@kernel.org,
	willemdebruijn.kernel@gmail.com, willemb@google.com,
	ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
	eddyz87@gmail.com, song@kernel.org, yonghong.song@linux.dev,
	john.fastabend@gmail.com, kpsingh@kernel.org, sdf@fomichev.me,
	haoluo@google.com, jolsa@kernel.org, horms@kernel.org,
	bpf@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH bpf-next v7 05/13] net-timestamp: prepare for isolating two modes of SO_TIMESTAMPING
Date: Mon, 3 Feb 2025 15:14:42 -0800	[thread overview]
Message-ID: <3b3e0cdf-9c2b-4423-b638-0a79b238eb93@linux.dev> (raw)
In-Reply-To: <20250128084620.57547-6-kerneljasonxing@gmail.com>

On 1/28/25 12:46 AM, Jason Xing wrote:
> No functional changes here. I add skb_enable_app_tstamp() to test
> if the orig_skb matches the usage of application SO_TIMESTAMPING
> and skb_sw_tstamp_tx() to distinguish the software and hardware

There is no skb_sw_tstamp_tx() in the code. An outdated commit message?

> timestamp when tsflag is SCM_TSTAMP_SND.
> 
> Also, I deliberately distinguish the the software and hardware
> SCM_TSTAMP_SND timestamp by passing 'sw' parameter in order to
> avoid such a case where hardware may go wrong and pass a NULL
> hwstamps, which is even though unlikely to happen. If it really
> happens, bpf prog will finally consider it as a software timestamp.
> It will be hardly recognized. Let's make the timestamping part
> more robust.
> 
> After this patch, I will soon add checks about bpf SO_TIMESTAMPING.

This needs to be updated also. BPF does not use the SO_TIMESTAMPING socket option.

> In this way, we can support two modes parallelly.

s/parallely/in parallel/

> 
> Signed-off-by: Jason Xing <kerneljasonxing@gmail.com>
> ---
>   include/linux/skbuff.h | 13 +++++++------
>   net/core/dev.c         |  2 +-
>   net/core/skbuff.c      | 32 ++++++++++++++++++++++++++++++--
>   net/ipv4/tcp_input.c   |  3 ++-
>   4 files changed, 40 insertions(+), 10 deletions(-)
> 
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index bb2b751d274a..dfc419281cc9 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -39,6 +39,7 @@
>   #include <net/net_debug.h>
>   #include <net/dropreason-core.h>
>   #include <net/netmem.h>
> +#include <uapi/linux/errqueue.h>
>   
>   /**
>    * DOC: skb checksums
> @@ -4533,18 +4534,18 @@ void skb_complete_tx_timestamp(struct sk_buff *skb,
>   
>   void __skb_tstamp_tx(struct sk_buff *orig_skb, const struct sk_buff *ack_skb,
>   		     struct skb_shared_hwtstamps *hwtstamps,
> -		     struct sock *sk, int tstype);
> +		     struct sock *sk, bool sw, int tstype);
>   
>   /**
> - * skb_tstamp_tx - queue clone of skb with send time stamps
> + * skb_tstamp_tx - queue clone of skb with send HARDWARE timestamps
>    * @orig_skb:	the original outgoing packet
>    * @hwtstamps:	hardware time stamps, may be NULL if not available
>    *
>    * If the skb has a socket associated, then this function clones the
>    * skb (thus sharing the actual data and optional structures), stores
> - * the optional hardware time stamping information (if non NULL) or
> - * generates a software time stamp (otherwise), then queues the clone

This line is removed. Does it mean no software timestamp now after this change?

> - * to the error queue of the socket.  Errors are silently ignored.
> + * the optional hardware time stamping information (if non NULL) then
> + * queues the clone to the error queue of the socket.  Errors are
> + * silently ignored.
>    */
>   void skb_tstamp_tx(struct sk_buff *orig_skb,
>   		   struct skb_shared_hwtstamps *hwtstamps);
> @@ -4565,7 +4566,7 @@ static inline void skb_tx_timestamp(struct sk_buff *skb)
>   {
>   	skb_clone_tx_timestamp(skb);
>   	if (skb_shinfo(skb)->tx_flags & SKBTX_SW_TSTAMP)
> -		skb_tstamp_tx(skb, NULL);
> +		__skb_tstamp_tx(skb, NULL, NULL, skb->sk, true, SCM_TSTAMP_SND);
>   }



  reply	other threads:[~2025-02-03 23:15 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-28  8:46 [PATCH bpf-next v7 00/13] net-timestamp: bpf extension to equip applications transparently Jason Xing
2025-01-28  8:46 ` [PATCH bpf-next v7 01/13] net-timestamp: add support for bpf_setsockopt() Jason Xing
2025-01-28  8:46 ` [PATCH bpf-next v7 02/13] net-timestamp: prepare for timestamping callbacks use Jason Xing
2025-01-28  8:46 ` [PATCH bpf-next v7 03/13] bpf: stop unsafely accessing TCP fields in bpf callbacks Jason Xing
2025-01-28  8:46 ` [PATCH bpf-next v7 04/13] bpf: stop calling some sock_op BPF CALLs in new timestamping callbacks Jason Xing
2025-01-28  8:46 ` [PATCH bpf-next v7 05/13] net-timestamp: prepare for isolating two modes of SO_TIMESTAMPING Jason Xing
2025-02-03 23:14   ` Martin KaFai Lau [this message]
2025-02-04  0:18     ` Jason Xing
2025-01-28  8:46 ` [PATCH bpf-next v7 06/13] net-timestamp: support SCM_TSTAMP_SCHED for bpf extension Jason Xing
2025-02-03 23:23   ` Martin KaFai Lau
2025-02-04  0:19     ` Jason Xing
2025-01-28  8:46 ` [PATCH bpf-next v7 07/13] net-timestamp: support sw SCM_TSTAMP_SND " Jason Xing
2025-01-28  8:46 ` [PATCH bpf-next v7 08/13] net-timestamp: support hw " Jason Xing
2025-02-04  0:56   ` Martin KaFai Lau
2025-02-04  1:13     ` Jason Xing
2025-01-28  8:46 ` [PATCH bpf-next v7 09/13] net-timestamp: support SCM_TSTAMP_ACK " Jason Xing
2025-01-28  8:46 ` [PATCH bpf-next v7 10/13] net-timestamp: make TCP tx timestamp bpf extension work Jason Xing
2025-02-04  1:03   ` Martin KaFai Lau
2025-02-04  1:15     ` Jason Xing
2025-01-28  8:46 ` [PATCH bpf-next v7 11/13] net-timestamp: add a new callback in tcp_tx_timestamp() Jason Xing
2025-02-04  1:16   ` Martin KaFai Lau
2025-02-04  1:25     ` Jason Xing
2025-02-04 17:08       ` Willem de Bruijn
2025-02-04 18:09         ` Jason Xing
2025-02-05  3:05           ` Jason Xing
2025-02-05  5:13             ` Jason Xing
2025-02-05 15:20             ` Willem de Bruijn
2025-02-05 15:47               ` Jason Xing
2025-02-05 21:02                 ` Willem de Bruijn
2025-02-06  0:33                   ` Jason Xing
2025-02-06  3:00                     ` Willem de Bruijn
2025-02-06  4:03                       ` Jason Xing
2025-02-06 16:22                         ` Willem de Bruijn
2025-02-07  0:35                           ` Jason Xing
2025-01-28  8:46 ` [PATCH bpf-next v7 12/13] net-timestamp: introduce cgroup lock to avoid affecting non-bpf cases Jason Xing
2025-02-04  1:21   ` Martin KaFai Lau
2025-02-04  1:25     ` Jason Xing
2025-01-28  8:46 ` [PATCH bpf-next v7 13/13] bpf: add simple bpf tests in the tx path for so_timestamping feature Jason Xing
2025-02-04  2:02   ` Martin KaFai Lau
2025-02-04  5:32     ` Jason Xing
2025-02-04  2:27 ` [PATCH bpf-next v7 00/13] net-timestamp: bpf extension to equip applications transparently Martin KaFai Lau
2025-02-04  2:44   ` Jason Xing
2025-02-04 17:11     ` Willem de Bruijn
2025-02-04 18:12       ` Jason Xing
2025-02-04 17:06   ` Willem de Bruijn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3b3e0cdf-9c2b-4423-b638-0a79b238eb93@linux.dev \
    --to=martin.lau@linux.dev \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=eddyz87@gmail.com \
    --cc=edumazet@google.com \
    --cc=haoluo@google.com \
    --cc=horms@kernel.org \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kerneljasonxing@gmail.com \
    --cc=kpsingh@kernel.org \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sdf@fomichev.me \
    --cc=song@kernel.org \
    --cc=willemb@google.com \
    --cc=willemdebruijn.kernel@gmail.com \
    --cc=yonghong.song@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.