xt_conntrack structure size

xt_conntrack structure size

[Jan Engelhardt]

Hi,


talking with SiegeX6 on IRC we found consensus that the struct 
xt_conntrack_mtinfo1 is just too fat -- 88 bytes if I counted right. 64 
of that go away for supporting IPv6 masking, which is plenty. We could 
use a uint8_t CIDR field instead of 'union nf_inet_addr origsrc_mask', 
and use a lookup table:
static const struct {
	union nf_inet_addr expanded;
	unsigned char contracted;
} table[] = {
	{IN6_ADDR(0000,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0), 0},
	{IN6_ADDR(8000,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0), 1},
	{IN6_ADDR(c000,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0), 2},
	{IN6_ADDR(e000,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0), 3}, 
	{IN6_ADDR(f000,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0), 4},
	{IN6_ADDR(f800,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0), 5},
	/* and so on */
};
This would cost us 2048 bytes once. Everything that uses IPv6 
CIDR<->mask transformation could use this.

- xt_conntrack: save 60 bytes per struct

- xt_hashlimit: save on some static computation power
  (currently, xt_hashlimit computes the mask from CIDR during
  rule insertion)

- xt_connlimit: save 15 bytes per struct (realistically: 12, due to 
aligned(8) padding)

- xt_policy: save 30 bytes per struct (realistically 24)

- ipt_entry, ip6t_entry: basically, these too, but it would touch
  a non-revisionable structure - can't break it

- probably tons of other code in non-netfilter areas in net/

Are there any objections to having this big table?

Re: xt_conntrack structure size

[Patrick McHardy]

Jan Engelhardt wrote:
> talking with SiegeX6 on IRC we found consensus that the struct 
> xt_conntrack_mtinfo1 is just too fat -- 88 bytes if I counted right. 64 
> of that go away for supporting IPv6 masking, which is plenty. We could 
> use a uint8_t CIDR field instead of 'union nf_inet_addr origsrc_mask', 
> and use a lookup table:
> static const struct {
> 	union nf_inet_addr expanded;
> 	unsigned char contracted;
> } table[] = {
> 	{IN6_ADDR(0000,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0), 0},
> 	{IN6_ADDR(8000,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0), 1},
> 	{IN6_ADDR(c000,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0), 2},
> 	{IN6_ADDR(e000,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0), 3}, 
> 	{IN6_ADDR(f000,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0), 4},
> 	{IN6_ADDR(f800,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0), 5},
> 	/* and so on */
> };
> This would cost us 2048 bytes once. Everything that uses IPv6 
> CIDR<->mask transformation could use this.
> 
> - xt_conntrack: save 60 bytes per struct
> 
> - xt_hashlimit: save on some static computation power
>   (currently, xt_hashlimit computes the mask from CIDR during
>   rule insertion)
> 
> - xt_connlimit: save 15 bytes per struct (realistically: 12, due to 
> aligned(8) padding)
> 
> - xt_policy: save 30 bytes per struct (realistically 24)
> 
> - ipt_entry, ip6t_entry: basically, these too, but it would touch
>   a non-revisionable structure - can't break it
> 
> - probably tons of other code in non-netfilter areas in net/
> 
> Are there any objections to having this big table?


Not against the table itself, but I would like to keep the
different revisions to the necessary minimum.