Re: Conntrack Events Performance - Multipart Messages?

[Patrick McHardy <kaber@trash.net>]

Fabian Hugelshofer wrote:
> Patrick McHardy wrote:
>> Patrick McHardy wrote:
>>> Fabian Hugelshofer wrote:
>>>> Is the zeroing of the inverted tuple in nf_ct_invert_tuple really 
>>>> required? As far as I can see all fields are set by the subsequent 
>>>> code.
>>>
>>> It dependfs on the protocol family. For IPv6 its completely
>>> unnecessary, for IPv4 the last 12 bytes of each address need
>>> to be zeroes. We could push this down to the protocols to
>>> behave more optimally (actually something I started and didn't
>>> finish some time ago).
>>
>> Actually that really is necessary because we have padding in the
>> tuple on at least ARM.
> 
> As you write the remaining 12 bytes for IPv4 can easily be handled in 
> the l3protocol. The original tuple is already initialised properly and 
> one would just have to replace things like
> tuple->src.u3.ip = orig->dst.u3.ip;
> with
> tuple->src.u3.all = orig->dst.u3.all;
> in nf_conntrack_l3proto_ipv4.c.

Correct.

> Why do you think the padding causes problems? For hashing e.g. src/dst 
> .u3 and .u are referenced independently of potential padding. Where does 
> access to the padding data occur?

The hash function hashes the entire tuple in one go.
The padding needs to have deterministic content for
that.