From: Florian Westphal <fw@strlen.de>
To: Stefano Brivio <sbrivio@redhat.com>
Cc: Florian Westphal <fw@strlen.de>, netfilter-devel@vger.kernel.org
Subject: Re: [PATCH nf-next 4/4] netfilter: nft_set_pipapo: speed up bulk element insertions
Date: Tue, 13 Feb 2024 14:29:00 +0100 [thread overview]
Message-ID: <20240213132900.GE5775@breakpoint.cc> (raw)
In-Reply-To: <20240213141753.17ef27a6@elisabeth>
Stefano Brivio <sbrivio@redhat.com> wrote:
> /* pipapo_realloc_mt() - Reallocate mapping table if needed upon resize
> * @f: Field containing mapping table
> * @old_rules: Amount of existing mapped rules
> * @rules: Amount of new rules to map
> *
> * Return: 0 on success, negative error code on failure.
> */
Thanks, I'll steal this for v2.
> static int pipapo_realloc_mt(struct nft_pipapo_field *f,
> unsigned int old_rules, unsigned int rules)
>
> > +{
> > + union nft_pipapo_map_bucket *new_mt = NULL, *old_mt = f->mt;
> > + unsigned int extra = 4096 / sizeof(*new_mt);
>
> Shouldn't we actually use PAGE_SIZE? I think the one-page limit is
> somewhat arbitrary but makes sense, so it should be 64k on e.g.
> CONFIG_PPC_64K_PAGES=y.
I wasn't sure if it would make sense to to use 64k for this batching,
I guess kvmalloc will use vmalloc anyway for such huge sets so I'll
change it back to PAGE_SIZE.
> > + BUILD_BUG_ON(extra < 32);
>
> I'm not entirely sure why this would be a problem. I mean, 'extra' at
> this point is the number of extra rules, not the amount of extra
> bytes, right?
Its a leftover from a version where this was bytes. I'll remove it.
> > + /* small sets get precise count, else add extra slack
> > + * to avoid frequent reallocations. Extra slack is
> > + * currently one 4k page worth of rules.
> > + *
> > + * Use no slack if the set only has a small number
> > + * of rules.
>
> This isn't always true: if we slightly decrease the size of a small
> mapping table, we might leave some slack, because we might hit the
> (remove < (2u * extra)) condition above. Is that intended? It doesn't
> look problematic to me, by the way.
Ok. I'll ammend the comment then.
> > + if (old_mt)
> > + memcpy(new_mt, old_mt, min(old_rules, rules) * sizeof(*new_mt));
> > +
> > + if (rules > old_rules)
>
> Nit: curly braces around multi-line block (for consistency).
Oh? Guess I'll see if checkpatch complains...
> > if (src->rules > 0) {
> > - dst->mt = kvmalloc_array(src->rules, sizeof(*src->mt), GFP_KERNEL);
> > + dst->mt = kvmalloc_array(src->rules_alloc, sizeof(*src->mt), GFP_KERNEL);
> > if (!dst->mt)
> > goto out_mt;
> >
> > memcpy(dst->mt, src->mt, src->rules * sizeof(*src->mt));
> > + dst->rules_alloc = src->rules_alloc;
> > + dst->rules = src->rules;
>
> These two, and setting rules_alloc below, shouldn't be needed, because we
> already copy everything in the source field before the lookup table, above.
Ah you mean:
memcpy(dst, src, offsetof(struct nft_pipapo_field, lt));
.. above. Ok, I'll remove those lines then.
Thanks for reviewing!
prev parent reply other threads:[~2024-02-13 13:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-12 10:01 [PATCH nf-next 0/4] netfilter: nft_set_pipapo: speed up bulk element insertions Florian Westphal
2024-02-12 10:01 ` [PATCH nf-next 1/4] netfilter: nft_set_pipapo: constify lookup fn args where possible Florian Westphal
2024-02-13 7:19 ` Stefano Brivio
2024-02-12 10:01 ` [PATCH nf-next 2/4] netfilter: nft_set_pipapo: do not rely on ZERO_SIZE_PTR Florian Westphal
2024-02-13 7:20 ` Stefano Brivio
2024-02-13 11:09 ` Florian Westphal
2024-02-12 10:01 ` [PATCH nf-next 3/4] netfilter: nft_set_pipapo: shrink data structures Florian Westphal
2024-02-13 13:17 ` Stefano Brivio
2024-02-12 10:01 ` [PATCH nf-next 4/4] netfilter: nft_set_pipapo: speed up bulk element insertions Florian Westphal
2024-02-13 13:17 ` Stefano Brivio
2024-02-13 13:29 ` Florian Westphal [this message]
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=20240213132900.GE5775@breakpoint.cc \
--to=fw@strlen.de \
--cc=netfilter-devel@vger.kernel.org \
--cc=sbrivio@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.