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 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).