From: Yonghong Song <yonghong.song@linux•dev>
To: Menglong Dong <menglong8.dong@gmail•com>,
Martin KaFai Lau <martin.lau@linux•dev>,
Stanislav Fomichev <sdf@google•com>
Cc: andrii@kernel•org, ast@kernel•org, daniel@iogearbox•net,
song@kernel•org, john.fastabend@gmail•com, kpsingh@kernel•org,
haoluo@google•com, jolsa@kernel•org, davem@davemloft•net,
edumazet@google•com, kuba@kernel•org, pabeni@redhat•com,
mykolal@fb•com, shuah@kernel•org, horms@kernel•org,
dhowells@redhat•com, linyunsheng@huawei•com,
aleksander.lobakin@intel•com, joannelkoong@gmail•com,
laoar.shao@gmail•com, kuifeng@meta•com, bjorn@rivosinc•com,
linux-kernel@vger•kernel.org, bpf@vger•kernel.org,
netdev@vger•kernel.org, linux-kselftest@vger•kernel.org
Subject: Re: [PATCH bpf-next 0/2] bpf: add csum/ip_summed fields to __sk_buff
Date: Tue, 2 Jan 2024 19:55:37 -0800 [thread overview]
Message-ID: <4fa8ae9d-11fd-4728-83bd-848cb22952e7@linux.dev> (raw)
In-Reply-To: <CADxym3bPjdErhZ_wgQNK3BqbeUgvGMtLJRA_rD3pRa+BVcA95A@mail.gmail.com>
On 1/2/24 6:54 PM, Menglong Dong wrote:
> On Wed, Jan 3, 2024 at 8:52 AM Martin KaFai Lau <martin.lau@linux•dev> wrote:
>> On 1/2/24 10:11 AM, Stanislav Fomichev wrote:
>>> On 12/29, Menglong Dong wrote:
>>>> For now, we have to call some helpers when we need to update the csum,
>>>> such as bpf_l4_csum_replace, bpf_l3_csum_replace, etc. These helpers are
>>>> not inlined, which causes poor performance.
>>>>
>>>> In fact, we can define our own csum update functions in BPF program
>>>> instead of bpf_l3_csum_replace, which is totally inlined and efficient.
>>>> However, we can't do this for bpf_l4_csum_replace for now, as we can't
>>>> update skb->csum, which can cause skb->csum invalid in the rx path with
>>>> CHECKSUM_COMPLETE mode.
>>>>
>>>> What's more, we can't use the direct data access and have to use
>>>> skb_store_bytes() with the BPF_F_RECOMPUTE_CSUM flag in some case, such
>>>> as modifing the vni in the vxlan header and the underlay udp header has
>>>> no checksum.
>> There is bpf_csum_update(), does it work?
>> A helper call should be acceptable comparing with the csum calculation itself.
> Yeah, this helper works in this case! Now we miss the last
> piece for the tx path: ip_summed. We need to know if it is
> CHECKSUM_PARTIAL to decide if we should update the
> csum in the packet. In the tx path, the csum in the L4 is the
> pseudo header only if skb->ip_summed is CHECKSUM_PARTIAL.
>
> Maybe we can introduce a lightweight kfunc to get its
> value? Such as bpf_skb_csum_mode(). As we need only call
> it once, there shouldn't be overhead on it.
You don't need kfunc, you can do checking like
struct sk_buff *kskb = bpf_cast_to_kern_ctx(skb);
if (kskb->ip_summed == CHECKSUM_PARTIAL) ...
...
>
> Thanks!
> Menglong Dong
>
>>>> In the first patch, we make skb->csum readable and writable, and we make
>>>> skb->ip_summed readable. For now, for tc only. With these 2 fields, we
>>>> don't need to call bpf helpers for csum update any more.
>>>>
>>>> In the second patch, we add some testcases for the read/write testing for
>>>> skb->csum and skb->ip_summed.
>>>>
>>>> If this series is acceptable, we can define the inlined functions for csum
>>>> update in libbpf in the next step.
>>> One downside of exposing those as __sk_buff fields is that all this
>>> skb internal csum stuff now becomes a UAPI. And I'm not sure we want
>> +1. Please no new __sk_buff extension and no new conversion in
>> bpf_convert_ctx_access().
>>
>>> that :-) Should we add a lightweight kfunc to reset the fields instead?
>>> Or will it still have an unacceptable overhead?
next prev parent reply other threads:[~2024-01-03 3:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-29 8:14 [PATCH bpf-next 0/2] bpf: add csum/ip_summed fields to __sk_buff Menglong Dong
2023-12-29 8:14 ` [PATCH bpf-next 1/2] " Menglong Dong
2023-12-29 8:14 ` [PATCH bpf-next 2/2] testcases/bpf: add testcases for skb->csum to ctx_skb.c Menglong Dong
2024-01-02 18:11 ` [PATCH bpf-next 0/2] bpf: add csum/ip_summed fields to __sk_buff Stanislav Fomichev
2024-01-03 0:52 ` Martin KaFai Lau
2024-01-03 2:54 ` Menglong Dong
2024-01-03 3:55 ` Yonghong Song [this message]
2024-01-03 6:03 ` Menglong Dong
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=4fa8ae9d-11fd-4728-83bd-848cb22952e7@linux.dev \
--to=yonghong.song@linux$(echo .)dev \
--cc=aleksander.lobakin@intel$(echo .)com \
--cc=andrii@kernel$(echo .)org \
--cc=ast@kernel$(echo .)org \
--cc=bjorn@rivosinc$(echo .)com \
--cc=bpf@vger$(echo .)kernel.org \
--cc=daniel@iogearbox$(echo .)net \
--cc=davem@davemloft$(echo .)net \
--cc=dhowells@redhat$(echo .)com \
--cc=edumazet@google$(echo .)com \
--cc=haoluo@google$(echo .)com \
--cc=horms@kernel$(echo .)org \
--cc=joannelkoong@gmail$(echo .)com \
--cc=john.fastabend@gmail$(echo .)com \
--cc=jolsa@kernel$(echo .)org \
--cc=kpsingh@kernel$(echo .)org \
--cc=kuba@kernel$(echo .)org \
--cc=kuifeng@meta$(echo .)com \
--cc=laoar.shao@gmail$(echo .)com \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-kselftest@vger$(echo .)kernel.org \
--cc=linyunsheng@huawei$(echo .)com \
--cc=martin.lau@linux$(echo .)dev \
--cc=menglong8.dong@gmail$(echo .)com \
--cc=mykolal@fb$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=pabeni@redhat$(echo .)com \
--cc=sdf@google$(echo .)com \
--cc=shuah@kernel$(echo .)org \
--cc=song@kernel$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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