On Tue, 9 Dec 2003, Jesse Peng wrote:
while a new ip_conntrack cache initiates, every member
infos[i](nf_ct_info structure) then be charged with the same address
value pointing to the ip_conntrack cache's begining address(it's the
address of its first member nf_conntrack structure naming ct_general also).
Right.. now I get why this construct is looking like it does. It is a
tradeoff "wasting" some space per conntrack to limit the mount of fields
needed in the skb.
By using this construct both the ctinfo and conntrack can be derived from
a single pointer in the skb.
For systems using conntrack a lot it would be more efficient to extend the
skb with one more field for ctinfo, but as it is good if the skb is the
same regardless if conntrack is enabled or not and this construct is a
good tradeoff.
It is however possible to reduce the size of this construct considerably
to just one byte per ctinfo.
Thanks
Henrik
As I never deeply think how this construct can be redesigned, after read
your insight.. now I begin to figure out why the skbuff.h prevent including
ip_conntrack.h, and why nf_conntrack defined in skbuff.h