From: Florian Westphal <fw@strlen.de>
To: Stefano Brivio <sbrivio@redhat.com>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>, netfilter-devel@vger.kernel.org
Subject: Re: [PATCH nf-next 3/5] nft_set_pipapo: Prepare for vectorised implementation: alignment
Date: Sun, 23 Feb 2020 23:14:35 +0100 [thread overview]
Message-ID: <20200223221435.GX19559@breakpoint.cc> (raw)
In-Reply-To: <2723f85da2cd9d6b7158c7a2514c6b22f044b1b6.1582488826.git.sbrivio@redhat.com>
Stefano Brivio <sbrivio@redhat.com> wrote:
> struct nft_pipapo_field {
> @@ -439,6 +456,9 @@ struct nft_pipapo_field {
> unsigned long rules;
> size_t bsize;
> int bb;
> +#ifdef NFT_PIPAPO_ALIGN
> + unsigned long *lt_aligned;
> +#endif
> unsigned long *lt;
> union nft_pipapo_map_bucket *mt;
> };
I wonder if these structs can be compressed.
AFAICS bsize is in sizes of longs, so when this number is
large then we also need to kvmalloc a large blob of memory.
I think u32 would be enough?
nft_pipapo_field is probably the most relevant one wrt. to size.
> struct nft_pipapo_match {
> int field_count;
> +#ifdef NFT_PIPAPO_ALIGN
> + unsigned long * __percpu *scratch_aligned;
> +#endif
> unsigned long * __percpu *scratch;
> size_t bsize_max;
Same here (bsize_max -- could fit with hole after field_count)?
Also, since you know the size of nft_pipapo_match (including the
dynamically allocated array at the end), you could store the
original memory (*scratch) and the rcu_head at the end, since
they are not needed at lookup time and a little overhead to calculate
their storage offset is fine.
Not sure its worth it, just an idea.
next prev parent reply other threads:[~2020-02-23 22:14 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-23 21:23 [PATCH nf-next 0/5] nft_set_pipapo: Performance improvements: Season 1 Stefano Brivio
2020-02-23 21:23 ` [PATCH nf-next 1/5] nft_set_pipapo: Generalise group size for buckets Stefano Brivio
2020-02-23 21:23 ` [PATCH nf-next 2/5] nft_set_pipapo: Add support for 8-bit lookup groups and dynamic switch Stefano Brivio
2020-02-23 21:23 ` [PATCH nf-next 3/5] nft_set_pipapo: Prepare for vectorised implementation: alignment Stefano Brivio
2020-02-23 22:14 ` Florian Westphal [this message]
2020-02-23 23:04 ` Stefano Brivio
2020-02-23 23:15 ` Florian Westphal
2020-03-05 20:35 ` Stefano Brivio
2020-02-23 21:23 ` [PATCH nf-next 4/5] nft_set_pipapo: Prepare for vectorised implementation: helpers Stefano Brivio
2020-02-23 21:23 ` [PATCH nf-next 5/5] nft_set_pipapo: Introduce AVX2-based lookup implementation Stefano Brivio
2020-02-23 22:16 ` Florian Westphal
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=20200223221435.GX19559@breakpoint.cc \
--to=fw@strlen.de \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.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.