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?
-
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
