From: John Fastabend <john.fastabend@gmail.com>
To: Cong Wang <xiyou.wangcong@gmail.com>, netdev@vger.kernel.org
Cc: bpf@vger.kernel.org, duanxiongchun@bytedance.com,
wangdongdong.6@bytedance.com, jiang.wang@bytedance.com,
Cong Wang <cong.wang@bytedance.com>,
John Fastabend <john.fastabend@gmail.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Jakub Sitnicki <jakub@cloudflare.com>,
Lorenz Bauer <lmb@cloudflare.com>
Subject: RE: [Patch bpf-next v3 4/5] skmsg: use skb ext instead of TCP_SKB_CB
Date: Mon, 15 Feb 2021 11:20:15 -0800 [thread overview]
Message-ID: <602ac96f9e30f_3ed41208b6@john-XPS-13-9370.notmuch> (raw)
In-Reply-To: <20210213214421.226357-5-xiyou.wangcong@gmail.com>
Cong Wang wrote:
> From: Cong Wang <cong.wang@bytedance.com>
>
> Currently TCP_SKB_CB() is hard-coded in skmsg code, it certainly
> does not work for any other non-TCP protocols. We can move them to
> skb ext instead of playing with skb cb, which is harder to make
> correct.
>
> Cc: John Fastabend <john.fastabend@gmail.com>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Jakub Sitnicki <jakub@cloudflare.com>
> Reviewed-by: Lorenz Bauer <lmb@cloudflare.com>
> Signed-off-by: Cong Wang <cong.wang@bytedance.com>
> ---
I'm not seeing the advantage of doing this at the moment. We can
continue to use cb[] here, which is simpler IMO and use the ext
if needed for the other use cases. This is adding a per packet
alloc cost that we don't have at the moment as I understand it.
[...]
> diff --git a/include/linux/skmsg.h b/include/linux/skmsg.h
> index e3bb712af257..d5c711ef6d4b 100644
> --- a/include/linux/skmsg.h
> +++ b/include/linux/skmsg.h
> @@ -459,4 +459,44 @@ static inline bool sk_psock_strp_enabled(struct sk_psock *psock)
> return false;
> return !!psock->saved_data_ready;
> }
> +
> +struct skb_bpf_ext {
> + __u32 flags;
> + struct sock *sk_redir;
> +};
> +
> +#if IS_ENABLED(CONFIG_NET_SOCK_MSG)
> +static inline
> +bool skb_bpf_ext_ingress(const struct sk_buff *skb)
> +{
> + struct skb_bpf_ext *ext = skb_ext_find(skb, SKB_EXT_BPF);
> +
> + return ext->flags & BPF_F_INGRESS;
> +}
> +
> +static inline
> +void skb_bpf_ext_set_ingress(const struct sk_buff *skb)
> +{
> + struct skb_bpf_ext *ext = skb_ext_find(skb, SKB_EXT_BPF);
> +
> + ext->flags |= BPF_F_INGRESS;
> +}
> +
> +static inline
> +struct sock *skb_bpf_ext_redirect_fetch(struct sk_buff *skb)
> +{
> + struct skb_bpf_ext *ext = skb_ext_find(skb, SKB_EXT_BPF);
> +
> + return ext->sk_redir;
> +}
> +
> +static inline
> +void skb_bpf_ext_redirect_clear(struct sk_buff *skb)
> +{
> + struct skb_bpf_ext *ext = skb_ext_find(skb, SKB_EXT_BPF);
> +
> + ext->flags = 0;
> + ext->sk_redir = NULL;
> +}
> +#endif /* CONFIG_NET_SOCK_MSG */
So we will have some slight duplication for cb[] variant and ext
variant above. I'm OK with that to avoid an allocation.
[...]
> @@ -1003,11 +1008,17 @@ static int sk_psock_verdict_recv(read_descriptor_t *desc, struct sk_buff *skb,
> goto out;
> }
> skb_set_owner_r(skb, sk);
> + if (!skb_ext_add(skb, SKB_EXT_BPF)) {
> + len = 0;
> + kfree_skb(skb);
> + goto out;
> + }
> +
per packet cost here. Perhaps you can argue small alloc will usually not be
noticable in such a large stack, but once we convert over it will be very
hard to go back. And I'm looking at optimizing this path now.
> prog = READ_ONCE(psock->progs.skb_verdict);
> if (likely(prog)) {
> - tcp_skb_bpf_redirect_clear(skb);
> + skb_bpf_ext_redirect_clear(skb);
> ret = sk_psock_bpf_run(psock, prog, skb);
> - ret = sk_psock_map_verd(ret, tcp_skb_bpf_redirect_fetch(skb));
> + ret = sk_psock_map_verd(ret, skb_bpf_ext_redirect_fetch(skb));
> }
> sk_psock_verdict_apply(psock, skb, ret);
Thanks for the series Cong. Drop this patch and resubmit carry ACKs forward
and then lets revisit this later.
Thanks,
John
next prev parent reply other threads:[~2021-02-15 19:21 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-13 21:44 [Patch bpf-next v3 0/5] sock_map: clean up and refactor code for BPF_SK_SKB_VERDICT Cong Wang
2021-02-13 21:44 ` [Patch bpf-next v3 1/5] bpf: clean up sockmap related Kconfigs Cong Wang
2021-02-15 10:34 ` Lorenz Bauer
2021-02-15 18:34 ` John Fastabend
2021-02-13 21:44 ` [Patch bpf-next v3 2/5] skmsg: get rid of struct sk_psock_parser Cong Wang
2021-02-15 18:56 ` John Fastabend
2021-02-15 19:03 ` Jakub Sitnicki
2021-02-13 21:44 ` [Patch bpf-next v3 3/5] bpf: compute data_end dynamically with JIT code Cong Wang
2021-02-15 19:03 ` John Fastabend
2021-02-15 19:06 ` Jakub Sitnicki
2021-02-13 21:44 ` [Patch bpf-next v3 4/5] skmsg: use skb ext instead of TCP_SKB_CB Cong Wang
2021-02-15 19:20 ` John Fastabend [this message]
2021-02-15 22:24 ` Cong Wang
2021-02-15 23:57 ` John Fastabend
2021-02-16 0:28 ` Cong Wang
2021-02-16 0:54 ` John Fastabend
2021-02-16 1:04 ` Cong Wang
2021-02-16 1:50 ` John Fastabend
2021-02-16 4:06 ` Cong Wang
2021-02-16 8:56 ` Lorenz Bauer
2021-02-17 19:19 ` John Fastabend
2021-02-13 21:44 ` [Patch bpf-next v3 5/5] sock_map: rename skb_parser and skb_verdict Cong Wang
2021-02-15 19:09 ` John Fastabend
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=602ac96f9e30f_3ed41208b6@john-XPS-13-9370.notmuch \
--to=john.fastabend@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=cong.wang@bytedance.com \
--cc=daniel@iogearbox.net \
--cc=duanxiongchun@bytedance.com \
--cc=jakub@cloudflare.com \
--cc=jiang.wang@bytedance.com \
--cc=lmb@cloudflare.com \
--cc=netdev@vger.kernel.org \
--cc=wangdongdong.6@bytedance.com \
--cc=xiyou.wangcong@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).