From: "Ziyang Xuan (William)" <william.xuanziyang@huawei.com>
To: Martin KaFai Lau <martin.lau@linux.dev>
Cc: <daniel@iogearbox.net>, <john.fastabend@gmail.com>,
<ast@kernel.org>, <andrii@kernel.org>, <song@kernel.org>,
<yonghong.song@linux.dev>, <kpsingh@kernel.org>, <sdf@google.com>,
<haoluo@google.com>, <jolsa@kernel.org>, <bpf@vger.kernel.org>
Subject: Re: [PATCH bpf-next 1/2] bpf: Update h_proto of ethhdr when the outer protocol changed
Date: Fri, 11 Aug 2023 18:22:28 +0800 [thread overview]
Message-ID: <ec0b5707-d409-daa7-7700-dc620263967f@huawei.com> (raw)
In-Reply-To: <0e342304-7e2f-fc84-c16b-8b1bdfd5487f@linux.dev>
> On 8/9/23 11:25 PM, Ziyang Xuan wrote:
>> When use bpf_skb_adjust_room() to encapsulate or decapsulate packet,
>> and outer protocol changed, we can update h_proto of ethhdr directly.
>
> This could break some existing bpf programs. e.g what if the existing prog is testing the h_proto after bpf_skb_adjust_room() and expect it hasn't changed yet?
>
I think some new modifications break some existing things are not unacceptable.
Maybe my modification is inappropriate because its benefits are small and
some kind of principle is broken, such as Yonghong Song pointed:
"bpf_skb_adjust_room() only changes skb meta data and tries not to modify the packet."
If it is, the modification should be rejected.
Thank you!
William Xuan
>
> .
next prev parent reply other threads:[~2023-08-11 10:22 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-10 6:25 [PATCH bpf-next 0/2] bpf: Update h_proto of ethhdr when the outer protocol changed Ziyang Xuan
2023-08-10 6:25 ` [PATCH bpf-next 1/2] " Ziyang Xuan
2023-08-10 18:27 ` Martin KaFai Lau
2023-08-11 10:22 ` Ziyang Xuan (William) [this message]
2023-08-10 6:25 ` [PATCH bpf-next 2/2] selftests/bpf: Remove unnecessary codes for updating h_proto of ethhdr Ziyang Xuan
2023-08-10 15:54 ` [PATCH bpf-next 0/2] bpf: Update h_proto of ethhdr when the outer protocol changed Yonghong Song
2023-08-11 9:44 ` Ziyang Xuan (William)
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=ec0b5707-d409-daa7-7700-dc620263967f@huawei.com \
--to=william.xuanziyang@huawei.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=martin.lau@linux.dev \
--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