From: Martin KaFai Lau <martin.lau@linux.dev>
To: Martynas <m@lambda.lt>
Cc: Daniel Borkmann <daniel@iogearbox.net>,
netdev <netdev@vger.kernel.org>,
Nikolay Aleksandrov <razor@blackwall.org>,
bpf@vger.kernel.org
Subject: Re: [PATCH bpf v2 1/2] bpf: Derive source IP addr via bpf_*_fib_lookup()
Date: Thu, 5 Oct 2023 23:29:50 -0700 [thread overview]
Message-ID: <47294480-506a-e22e-7466-3cdc106c395e@linux.dev> (raw)
In-Reply-To: <e7b992e3-8059-4058-8561-cb017c200c8d@app.fastmail.com>
On 10/5/23 1:16 PM, Martynas wrote:
>>> @@ -5992,6 +5995,19 @@ static int bpf_ipv6_fib_lookup(struct net *net, struct bpf_fib_lookup *params,
>>> params->rt_metric = res.f6i->fib6_metric;
>>> params->ifindex = dev->ifindex;
>>>
>>> + if (flags & BPF_FIB_LOOKUP_SET_SRC) {
>>> + if (res.f6i->fib6_prefsrc.plen) {
>>> + *(struct in6_addr *)params->ipv6_src = res.f6i->fib6_prefsrc.addr;
A nit. just noticed. Similar to the "*dst" assignment a few lines above:
*src = res.f6i->fib6_prefsrc.addr;
>>> + } else {
>>> + err = ipv6_bpf_stub->ipv6_dev_get_saddr(net, dev,
>>> + &fl6.daddr, 0,
>>> + (struct in6_addr *)
>>> + params->ipv6_src);
Same here. Use the "src".
>>> + if (err)
>>> + return BPF_FIB_LKUP_RET_NO_SRC_ADDR;
>>
>> This error also implies BPF_FIB_LKUP_RET_NO_NEIGH. I don't have a clean way of
>> improving the API. May be others have some ideas.
>>
>> Considering dev has no saddr is probably (?) an unlikely case, it should be ok
>> to leave it as is but at least a comment in the uapi will be needed. Otherwise,
>> the bpf prog may use the 0 dmac as-is.
>
> I expect that a user of the helper checks that err == 0 before using any of the output params.
For example, the bpf prog gets BPF_FIB_LKUP_RET_NO_NEIGH and learns neigh is not
available but ipv6_dst (and the optional ipv6_src) is still valid.
If the bpf prog gets BPF_FIB_LKUP_RET_NO_SRC_ADDR, intuitively, only ipv6_src is
not available. The bpf prog will continue to use the ipv6_dst and dmac (which is
actually 0).
>
>>
>> I feel the current bpf_ipv[46]_fib_lookup helper is doing many things
>> in one
>> function and then requires different BPF_FIB_LOOKUP_* bits to select
>> what/how to
>> do. In the future, it may be worth to consider breaking it into smaller
>> kfunc(s). e.g. the __ipv[46]_neigh_lookup could be in its own kfunc.
>>
>
> Yep, good idea. At least it seems that the neigh lookup could live in its own function.
To be clear, it could be independent of this set.
Thanks.
next prev parent reply other threads:[~2023-10-06 6:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-03 7:10 [PATCH bpf v2 0/2] bpf: Fix src IP addr related limitation in bpf_*_fib_lookup() Martynas Pumputis
2023-10-03 7:10 ` [PATCH bpf v2 1/2] bpf: Derive source IP addr via bpf_*_fib_lookup() Martynas Pumputis
2023-10-04 20:09 ` Martin KaFai Lau
2023-10-05 20:16 ` Martynas
2023-10-06 6:29 ` Martin KaFai Lau [this message]
2023-10-06 7:03 ` Martynas
2023-10-03 7:10 ` [PATCH bpf v2 2/2] selftests/bpf: Add BPF_FIB_LOOKUP_SET_SRC tests Martynas Pumputis
2023-10-04 22:02 ` Martin KaFai Lau
2023-10-05 20:19 ` Martynas
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=47294480-506a-e22e-7466-3cdc106c395e@linux.dev \
--to=martin.lau@linux.dev \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=m@lambda.lt \
--cc=netdev@vger.kernel.org \
--cc=razor@blackwall.org \
/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).