netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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!

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