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, bpf@vger.kernel.org,
netdev@vger.kernel.org, Jason Xing <kernelxing@tencent.com>
Subject: Re: [PATCH net-next v4 06/11] net-timestamp: support SCM_TSTAMP_ACK for bpf extension
Date: Thu, 12 Dec 2024 14:36:11 -0800 [thread overview]
Message-ID: <6ccdc72c-f21c-4b02-aba3-b70363e58982@linux.dev> (raw)
In-Reply-To: <20241207173803.90744-7-kerneljasonxing@gmail.com>
On 12/7/24 9:37 AM, Jason Xing wrote:
> From: Jason Xing <kernelxing@tencent.com>
>
> Handle the ACK timestamp case. Actually testing SKBTX_BPF flag
> can work, but we need to Introduce a new txstamp_ack_bpf to avoid
> cache line misses in tcp_ack_tstamp().
>
> Signed-off-by: Jason Xing <kernelxing@tencent.com>
> ---
> include/net/tcp.h | 3 ++-
> include/uapi/linux/bpf.h | 5 +++++
> net/core/skbuff.c | 9 ++++++---
> net/ipv4/tcp_input.c | 3 ++-
> net/ipv4/tcp_output.c | 5 +++++
> tools/include/uapi/linux/bpf.h | 5 +++++
> 6 files changed, 25 insertions(+), 5 deletions(-)
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index e9b37b76e894..8e5103d3c6b9 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -959,9 +959,10 @@ struct tcp_skb_cb {
> __u8 sacked; /* State flags for SACK. */
> __u8 ip_dsfield; /* IPv4 tos or IPv6 dsfield */
> __u8 txstamp_ack:1, /* Record TX timestamp for ack? */
> + txstamp_ack_bpf:1, /* ack timestamp for bpf use */
After quickly peeking at patch 8, I realize that the new txstamp_ack_bpf bit is
not needed. SKBTX_BPF bit (in skb_shinfo(skb)->tx_flags) and the txstamp_ack_bpf
are always set together. Then only use the SKBTX_BPF bit should be as good.
> eor:1, /* Is skb MSG_EOR marked? */
> has_rxtstamp:1, /* SKB has a RX timestamp */
> - unused:5;
> + unused:4;
> __u32 ack_seq; /* Sequence number ACK'd */
> union {
> struct {
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index a6d761f07f67..a0aff1b4eb61 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -7032,6 +7032,11 @@ enum {
> * feature is on. It indicates the
> * recorded timestamp.
> */
> + BPF_SOCK_OPS_TS_ACK_OPT_CB, /* Called when all the skbs are
> + * acknowledged when SO_TIMESTAMPING
> + * feature is on. It indicates the
> + * recorded timestamp.
> + */
> };
>
> /* List of TCP states. There is a build check in net/ipv4/tcp.c to detect
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 73b15d6277f7..48b0c71e9522 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -5553,6 +5553,9 @@ static void __skb_tstamp_tx_bpf(struct sock *sk, struct sk_buff *skb, int tstype
> case SCM_TSTAMP_SND:
> op = BPF_SOCK_OPS_TS_SW_OPT_CB;
> break;
> + case SCM_TSTAMP_ACK:
> + op = BPF_SOCK_OPS_TS_ACK_OPT_CB;
> + break;
> default:
> return;
> }
> @@ -5632,9 +5635,9 @@ static bool skb_tstamp_is_set(const struct sk_buff *skb, int tstype, bool bpf_mo
> return true;
> return false;
> case SCM_TSTAMP_ACK:
> - if (TCP_SKB_CB(skb)->txstamp_ack)
> - return true;
> - return false;
> + flag = bpf_mode ? TCP_SKB_CB(skb)->txstamp_ack_bpf :
> + TCP_SKB_CB(skb)->txstamp_ack;
> + return !!flag;
> }
>
> return false;
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index 5bdf13ac26ef..82bb26f5b214 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -3321,7 +3321,8 @@ static void tcp_ack_tstamp(struct sock *sk, struct sk_buff *skb,
> const struct skb_shared_info *shinfo;
>
> /* Avoid cache line misses to get skb_shinfo() and shinfo->tx_flags */
> - if (likely(!TCP_SKB_CB(skb)->txstamp_ack))
> + if (likely(!TCP_SKB_CB(skb)->txstamp_ack &&
> + !TCP_SKB_CB(skb)->txstamp_ack_bpf))
Change the test here to:
if (likely(!TCP_SKB_CB(skb)->txstamp_ack &&
!(skb_shinfo(skb)->tx_flags & SKBTX_BPF)))
Does it make sense?
next prev parent reply other threads:[~2024-12-12 22:36 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-07 17:37 [PATCH net-next v4 00/11] net-timestamp: bpf extension to equip applications transparently Jason Xing
2024-12-07 17:37 ` [PATCH net-next v4 01/11] net-timestamp: add support for bpf_setsockopt() Jason Xing
2024-12-09 4:28 ` kernel test robot
2024-12-09 4:31 ` kernel test robot
2024-12-12 19:34 ` Martin KaFai Lau
2024-12-13 14:12 ` Jason Xing
2024-12-07 17:37 ` [PATCH net-next v4 02/11] net-timestamp: prepare for bpf prog use Jason Xing
2024-12-11 2:02 ` Martin KaFai Lau
2024-12-11 9:17 ` Jason Xing
2024-12-13 1:41 ` Martin KaFai Lau
2024-12-13 14:42 ` Jason Xing
2024-12-13 22:26 ` Martin KaFai Lau
2024-12-13 23:56 ` Jason Xing
2024-12-07 17:37 ` [PATCH net-next v4 03/11] net-timestamp: reorganize in skb_tstamp_tx_output() Jason Xing
2024-12-09 14:37 ` Willem de Bruijn
2024-12-09 14:57 ` Jason Xing
2024-12-07 17:37 ` [PATCH net-next v4 04/11] net-timestamp: support SCM_TSTAMP_SCHED for bpf extension Jason Xing
2024-12-07 17:37 ` [PATCH net-next v4 05/11] net-timestamp: support SCM_TSTAMP_SND " Jason Xing
2024-12-07 17:37 ` [PATCH net-next v4 06/11] net-timestamp: support SCM_TSTAMP_ACK " Jason Xing
2024-12-12 22:36 ` Martin KaFai Lau [this message]
2024-12-13 14:49 ` Jason Xing
2024-12-13 22:46 ` Martin KaFai Lau
2024-12-07 17:37 ` [PATCH net-next v4 07/11] net-timestamp: support hwtstamp print " Jason Xing
2024-12-12 23:25 ` Martin KaFai Lau
2024-12-13 6:28 ` Martin KaFai Lau
2024-12-13 15:13 ` Jason Xing
2024-12-13 23:15 ` Martin KaFai Lau
2024-12-14 0:02 ` Jason Xing
2024-12-14 0:17 ` Martin KaFai Lau
2024-12-14 0:48 ` Jason Xing
2024-12-07 17:38 ` [PATCH net-next v4 08/11] net-timestamp: make TCP tx timestamp bpf extension work Jason Xing
2024-12-07 17:38 ` [PATCH net-next v4 09/11] net-timestamp: introduce cgroup lock to avoid affecting non-bpf cases Jason Xing
2024-12-07 17:38 ` [PATCH net-next v4 10/11] net-timestamp: export the tskey for TCP bpf extension Jason Xing
2024-12-13 0:28 ` Martin KaFai Lau
2024-12-13 15:44 ` Jason Xing
2024-12-13 23:55 ` Martin KaFai Lau
2024-12-14 0:09 ` Jason Xing
2025-01-08 4:21 ` Jason Xing
2025-01-08 12:55 ` Jason Xing
2025-01-10 20:35 ` Martin KaFai Lau
2025-01-10 22:46 ` Jason Xing
2024-12-07 17:38 ` [PATCH net-next v4 11/11] bpf: add simple bpf tests in the tx path for so_timstamping feature Jason Xing
2024-12-09 14:45 ` Willem de Bruijn
2024-12-09 14:58 ` Jason Xing
2024-12-13 1:14 ` Martin KaFai Lau
2024-12-13 16:02 ` Jason Xing
2024-12-14 0:14 ` Martin KaFai Lau
2024-12-14 0:45 ` Jason Xing
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=6ccdc72c-f21c-4b02-aba3-b70363e58982@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=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kerneljasonxing@gmail.com \
--cc=kernelxing@tencent.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox