Henrik Nordstrom wrote:
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

Thanks
Jesse