Message ID | 1467815048-2240-7-git-send-email-pablo@netfilter.org |
---|---|
State | Accepted, archived |
Delegated to: | David Miller |
Headers | show |
From: Pablo Neira Ayuso > Sent: 06 July 2016 15:24 > From: Florian Westphal <fw@strlen.de> > > increases struct size by 32 bytes (288 -> 320), but it is the right thing, > else any attempt to (re-)arrange nf_conn members by cacheline won't work. ... > nf_conntrack_cachep = kmem_cache_create("nf_conntrack", > sizeof(struct nf_conn), 0, > - SLAB_DESTROY_BY_RCU, NULL); > + SLAB_DESTROY_BY_RCU | SLAB_HWCACHE_ALIGN, NULL); What happens on systems with cache lines that are longer than 64 bytes? (I'm pretty sure some ppc systems have long cache lines.) David
David Laight <David.Laight@ACULAB.COM> wrote: > From: Pablo Neira Ayuso > > Sent: 06 July 2016 15:24 > > From: Florian Westphal <fw@strlen.de> > > > > increases struct size by 32 bytes (288 -> 320), but it is the right thing, > > else any attempt to (re-)arrange nf_conn members by cacheline won't work. > ... > > nf_conntrack_cachep = kmem_cache_create("nf_conntrack", > > sizeof(struct nf_conn), 0, > > - SLAB_DESTROY_BY_RCU, NULL); > > + SLAB_DESTROY_BY_RCU | SLAB_HWCACHE_ALIGN, NULL); > > What happens on systems with cache lines that are longer than 64 bytes? Sorry, I don't have a secret decoder ring. HWCACHE_ALIGN is used for several other net slab caches, including skbuff, so why is this a problem here?
diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c index db2312e..2903bb4 100644 --- a/net/netfilter/nf_conntrack_core.c +++ b/net/netfilter/nf_conntrack_core.c @@ -1731,7 +1731,7 @@ int nf_conntrack_init_start(void) nf_conntrack_cachep = kmem_cache_create("nf_conntrack", sizeof(struct nf_conn), 0, - SLAB_DESTROY_BY_RCU, NULL); + SLAB_DESTROY_BY_RCU | SLAB_HWCACHE_ALIGN, NULL); if (!nf_conntrack_cachep) goto err_cachep;