Re: PATCH: extra conntrack stats

[Patrick Schaaf <bof@bof.de>]

On Thu, May 01, 2003 at 04:46:44PM +1000, Rusty Russell wrote:
> In message <20030501060522.GB15143@oknodo.bof.de> you write:
> > > 	struct nf_ct_info infos[IP_CT_NUMBER];
> > > 7 * 4 bytes.  We could eliminate this by adding an skb field to hold
> > > the state.
> > 
> > Given a guaranteed cacheline alignment of our 'struct ip_conntrack',
> > we could make the current pointer on the skbuffs a tagged pointer,
> > i.e. stuff our 3 info bits into the low 3 bits, without consuming
> > more room in the skbuffs.
> 
> That was my original implementation.  It was fairly ugly, but worse, I
> can imagine an arch where it would break.  None would at the moment,
> though, since kmalloc cacheline aligns

This boils down to the question whether SLAB_HWCACHE_ALIGN is a guarantee,
or a hint. I would have expected it to be a guarantee.

Argh. Are you worried about architectures with 8 byte or less cache lines?

Well, use another field in the skbuff, then. I would recycle nfcache,
but that's just because nobody ever explained to me what it would be
used for... :)

> (although we'd have to be a
> little careful to explicitly align a conntrack if we were to use a
> dummy one for a "notrack" target.

Unless you are after static initializability, what keeps us from
allocating such dummies in the same way as we allocate the rest?

best regards
  Patrick