From: Eric Dumazet <eric.dumazet@gmail.com>
To: Daniel Borkmann <daniel@iogearbox.net>,
Eric Dumazet <eric.dumazet@gmail.com>,
ast@kernel.org
Cc: john.fastabend@gmail.com, netdev@vger.kernel.org, bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next 2/6] bpf, net: rework cookie generator as per-cpu one
Date: Fri, 25 Sep 2020 09:49:29 +0200 [thread overview]
Message-ID: <b1d5d93a-3846-ae35-7ea6-4bc31e98ef30@gmail.com> (raw)
In-Reply-To: <dc5dd027-256d-598a-2f89-a45bb30208f8@iogearbox.net>
On 9/25/20 12:03 AM, Daniel Borkmann wrote:
> On 9/24/20 8:58 PM, Eric Dumazet wrote:
>> On 9/24/20 8:21 PM, Daniel Borkmann wrote:
> [...]
>>> diff --git a/include/linux/cookie.h b/include/linux/cookie.h
>>> new file mode 100644
>>> index 000000000000..2488203dc004
>>> --- /dev/null
>>> +++ b/include/linux/cookie.h
>>> @@ -0,0 +1,41 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +#ifndef __LINUX_COOKIE_H
>>> +#define __LINUX_COOKIE_H
>>> +
>>> +#include <linux/atomic.h>
>>> +#include <linux/percpu.h>
>>> +
>>> +struct gen_cookie {
>>> + u64 __percpu *local_last;
>>> + atomic64_t shared_last ____cacheline_aligned_in_smp;
>>> +};
>>> +
>>> +#define COOKIE_LOCAL_BATCH 4096
>>> +
>>> +#define DEFINE_COOKIE(name) \
>>> + static DEFINE_PER_CPU(u64, __##name); \
>>> + static struct gen_cookie name = { \
>>> + .local_last = &__##name, \
>>> + .shared_last = ATOMIC64_INIT(0), \
>>> + }
>>> +
>>> +static inline u64 gen_cookie_next(struct gen_cookie *gc)
>>> +{
>>> + u64 *local_last = &get_cpu_var(*gc->local_last);
>>> + u64 val = *local_last;
>>> +
>>> + if (__is_defined(CONFIG_SMP) &&
>>> + unlikely((val & (COOKIE_LOCAL_BATCH - 1)) == 0)) {
>>> + s64 next = atomic64_add_return(COOKIE_LOCAL_BATCH,
>>> + &gc->shared_last);
>>> + val = next - COOKIE_LOCAL_BATCH;
>>> + }
>>> + val++;
>>> + if (unlikely(!val))
>>> + val++;
>>> + *local_last = val;
>>> + put_cpu_var(local_last);
>>> + return val;
>>
>> This is not interrupt safe.
>>
>> I think sock_gen_cookie() can be called from interrupt context.
>>
>> get_next_ino() is only called from process context, that is what I used get_cpu_var()
>> and put_cpu_var()
>
> Hmm, agree, good point. Need to experiment a bit more .. initial thinking
> potentially something like the below could do where we fall back to atomic
> counter iff we encounter nesting (which should be an extremely rare case
> normally).
>
> BPF progs where this can be called from are non-preemptible, so we could
> actually move the temp preempt_disable/enable() from get/put_cpu_var() into
> a wrapper func for slow path non-BPF users as well.
>
> static inline u64 gen_cookie_next(struct gen_cookie *gc)
> {
> u64 val;
>
I presume you would use a single structure to hold level_nesting and local_last
in the same cache line.
struct pcpu_gen_cookie {
int level_nesting;
u64 local_last;
} __aligned(16);
> if (likely(this_cpu_inc_return(*gc->level_nesting) == 1)) {
> u64 *local_last = this_cpu_ptr(gc->local_last);
>
> val = *local_last;
> if (__is_defined(CONFIG_SMP) &&
> unlikely((val & (COOKIE_LOCAL_BATCH - 1)) == 0)) {
> s64 next = atomic64_add_return(COOKIE_LOCAL_BATCH,
> &gc->shared_last);
> val = next - COOKIE_LOCAL_BATCH;
> }
> val++;
> if (unlikely(!val))
> val++;
Note that we really expect this wrapping will never happen, with 64bit value.
(We had to take care of the wrapping in get_next_ino() as it was dealing with 32bit values)
> *local_last = val;
> } else {
> val = atomic64_add_return(COOKIE_LOCAL_BATCH,
> &gc->shared_last);
Or val = atomic64_dec_return(&reverse_counter)
With reverse_counter initial value set to ATOMIC64_INIT(0) ?
This will start sending 'big cookies like 0xFFFFFFFFxxxxxxxx' to make sure applications
are not breaking with them, after few months of uptime.
This would also not consume COOKIE_LOCAL_BATCH units per value,
but this seems minor based on the available space.
> }
> this_cpu_dec(*gc->level_nesting);
> return val;
> }
>
> Thanks,
> Daniel
next prev parent reply other threads:[~2020-09-25 7:49 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-24 18:21 [PATCH bpf-next 0/6] Various BPF helper improvements Daniel Borkmann
2020-09-24 18:21 ` [PATCH bpf-next 1/6] bpf: add classid helper only based on skb->sk Daniel Borkmann
2020-09-25 14:46 ` Jakub Kicinski
2020-09-25 15:35 ` Daniel Borkmann
2020-09-24 18:21 ` [PATCH bpf-next 2/6] bpf, net: rework cookie generator as per-cpu one Daniel Borkmann
2020-09-24 18:58 ` Eric Dumazet
2020-09-24 22:03 ` Daniel Borkmann
2020-09-25 7:49 ` Eric Dumazet [this message]
2020-09-25 9:26 ` Daniel Borkmann
2020-09-25 15:00 ` Jakub Kicinski
2020-09-25 15:15 ` Eric Dumazet
2020-09-25 15:31 ` Jakub Kicinski
2020-09-25 15:45 ` Eric Dumazet
2020-09-24 18:21 ` [PATCH bpf-next 3/6] bpf: add redirect_neigh helper as redirect drop-in Daniel Borkmann
2020-09-24 22:12 ` David Ahern
2020-09-24 22:19 ` Daniel Borkmann
2020-09-24 18:21 ` [PATCH bpf-next 4/6] bpf, libbpf: add bpf_tail_call_static helper for bpf programs Daniel Borkmann
2020-09-24 20:53 ` Andrii Nakryiko
2020-09-24 22:17 ` Daniel Borkmann
2020-09-25 15:42 ` Daniel Borkmann
2020-09-25 15:52 ` Daniel Borkmann
2020-09-25 16:50 ` Andrii Nakryiko
2020-09-25 19:52 ` Daniel Borkmann
2020-09-25 6:13 ` Yonghong Song
2020-09-24 18:21 ` [PATCH bpf-next 5/6] bpf, selftests: use bpf_tail_call_static where appropriate Daniel Borkmann
2020-09-24 19:25 ` Maciej Fijalkowski
2020-09-24 22:03 ` Daniel Borkmann
2020-09-24 18:21 ` [PATCH bpf-next 6/6] bpf, selftests: add redirect_neigh selftest Daniel Borkmann
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=b1d5d93a-3846-ae35-7ea6-4bc31e98ef30@gmail.com \
--to=eric.dumazet@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=john.fastabend@gmail.com \
--cc=netdev@vger.kernel.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).