netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.
>   *

  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).