From: John Fastabend <john.fastabend@gmail.com>
To: Liu Jian <liujian56@huawei.com>,
john.fastabend@gmail.com, jakub@cloudflare.com,
ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
martin.lau@linux.dev, song@kernel.org,
yonghong.song@linux.dev, kpsingh@kernel.org, sdf@google.com,
haoluo@google.com, jolsa@kernel.org, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
dsahern@kernel.org
Cc: netdev@vger.kernel.org, bpf@vger.kernel.org, liujian56@huawei.com
Subject: RE: [PATCH bpf-next v2 1/7] bpf, sockmap: add BPF_F_PERMANENTLY flag for skmsg redirect
Date: Wed, 16 Aug 2023 23:13:50 -0700 [thread overview]
Message-ID: <64ddba9e1df57_32c0720898@john.notmuch> (raw)
In-Reply-To: <20230811093237.3024459-2-liujian56@huawei.com>
Liu Jian wrote:
> If the sockmap msg redirection function is used only to forward packets
> and no other operation, the execution result of the BPF_SK_MSG_VERDICT
> program is the same each time. In this case, the BPF program only needs to
> be run once. Add BPF_F_PERMANENTLY flag to bpf_msg_redirect_map() and
> bpf_msg_redirect_hash() to implement this ability.
>
I like the use case. Did you consider using
long bpf_msg_apply_bytes(struct sk_msg_buff *msg, u32 bytes)
This could be set to UINT32_MAX and then the BPF prog would only be run
every 0xfffffff bytes.
> Then we can enable this function in the bpf program as follows:
> bpf_msg_redirect_hash(xx, xx, xx, BPF_F_INGRESS | BPF_F_PERMANENTLY);
>
> Test results using netperf TCP_STREAM mode:
> for i in 1 64 128 512 1k 2k 32k 64k 100k 500k 1m;then
> netperf -T 1,2 -t TCP_STREAM -H 127.0.0.1 -l 20 -- -m $i -s 100m,100m -S 100m,100m
> done
>
> before:
> 3.84 246.52 496.89 1885.03 3415.29 6375.03 40749.09 48764.40 51611.34 55678.26 55992.78
> after:
> 4.43 279.20 555.82 2080.79 3870.70 7105.44 41836.41 49709.75 51861.56 55211.00 54566.85
I suspect comparing against
bpf_msg_redirect_hash(...)
bpf_msg_apply_bytes(msg, UINT32_MAX)
the diff will be rather small. I agree the API is nicer though to simply
set the flag. Its too bad we didn't think to add a forever to apply_bytes.
I would prefer this API for example,
bpf_msg_redirect_hash(...)
bpf_msg_apply_bytes(msg, 0, PERMANENT);
Given we have apply_bytes is it still useful to have a PERMANENT flag
in your use case? Here we would just reset to UNINT32_MAX if we reached
max bytes.
>
> Signed-off-by: Liu Jian <liujian56@huawei.com>
> ---
> include/linux/skmsg.h | 1 +
> include/uapi/linux/bpf.h | 7 +++++--
> net/core/skmsg.c | 1 +
> net/core/sock_map.c | 4 ++--
> net/ipv4/tcp_bpf.c | 21 +++++++++++++++------
> tools/include/uapi/linux/bpf.h | 7 +++++--
> 6 files changed, 29 insertions(+), 12 deletions(-)
[...]
>
> diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
> index 70da85200695..cf622ea4f018 100644
> --- a/tools/include/uapi/linux/bpf.h
> +++ b/tools/include/uapi/linux/bpf.h
> @@ -3004,7 +3004,8 @@ union bpf_attr {
> * egress interfaces can be used for redirection. The
> * **BPF_F_INGRESS** value in *flags* is used to make the
> * distinction (ingress path is selected if the flag is present,
> - * egress path otherwise). This is the only flag supported for now.
> + * egress path otherwise). The **BPF_F_PERMANENTLY** value in
> + * *flags* is used to indicates whether the eBPF result is permanent.
We at least need to document what happens if PERMANENTLY and apply_bytes are
used together.
> * Return
> * **SK_PASS** on success, or **SK_DROP** on error.
> *
next prev parent reply other threads:[~2023-08-17 6:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-11 9:32 [PATCH bpf-next v2 0/7] add BPF_F_PERMANENTLY flag for sockmap skmsg redirect Liu Jian
2023-08-11 9:32 ` [PATCH bpf-next v2 1/7] bpf, sockmap: add BPF_F_PERMANENTLY flag for " Liu Jian
2023-08-17 6:13 ` John Fastabend [this message]
2023-08-19 9:25 ` liujian (CE)
2023-08-20 18:03 ` Jakub Sitnicki
2023-08-17 12:05 ` Ferenc Fejes
2023-08-19 9:32 ` liujian (CE)
2023-08-20 18:19 ` Jakub Sitnicki
2023-08-21 7:40 ` Jakub Sitnicki
2023-08-11 9:32 ` [PATCH bpf-next v2 2/7] selftests/bpf: Add txmsg ingress permanently test for sockmap Liu Jian
2023-08-11 9:32 ` [PATCH bpf-next v2 3/7] selftests/bpf: Add txmsg redir " Liu Jian
2023-08-11 9:32 ` [PATCH bpf-next v2 4/7] selftests/bpf: add skmsg verdict tests Liu Jian
2023-08-11 9:32 ` [PATCH bpf-next v2 5/7] selftests/bpf: add two skmsg verdict tests for BPF_F_PERMANENTLY flag Liu Jian
2023-08-11 9:32 ` [PATCH bpf-next v2 6/7] selftests/bpf: add tests for verdict skmsg to itself Liu Jian
2023-08-11 9:32 ` [PATCH bpf-next v2 7/7] selftests/bpf: add tests for verdict skmsg to closed socket Liu Jian
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=64ddba9e1df57_32c0720898@john.notmuch \
--to=john.fastabend@gmail.com \
--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=edumazet@google.com \
--cc=haoluo@google.com \
--cc=jakub@cloudflare.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=liujian56@huawei.com \
--cc=martin.lau@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@google.com \
--cc=song@kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).