Re: ip_conntrack_get

[Jesse Peng <jesse@deansoft.com.tw>]

[-- Attachment #1: Type: text/plain, Size: 1233 bytes --]

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


[-- Attachment #2: Type: text/html, Size: 1570 bytes --]