Re: Conntrack Events Performance - Multipart Messages?

[Patrick McHardy <kaber@trash.net>]

Fabian Hugelshofer wrote:
> Patrick McHardy wrote:
>> Fabian Hugelshofer wrote:
>>> Patrick McHardy wrote:
>>>> The first thing to try would be to use sane allocation sizes
>>>> for the event messages. This patch doesn't implement it properly
>>>> (uses probing), but should be enough to test whether it helps.
>>>
>>> Thanks a lot. This patch already decreased the CPU usage for ctevtest 
>>> from 85% to 44%. Sweet...
>>
>> Nice. Now we just need to do it properly :)
> 
> What do you mean with properly? Put some kind of cap? Or eliminate the 
> guessing by allocating a reasonable small fixed amount?

Yes, ideally it should use exact allocations, but thats probably
not worth it because it depends on too many factors. The next
best thing would be to allocate exactly the maximum thats needed.
The <<= 1 in my patch might still cause reallocations, some (or
all) of them could be avoided.

>>> nf_conntrack_event is now one of the first functions listed. Do you 
>>> see other ways of improving performance?
>>
>> For some members doing in-place message construction instead of
>> copying the data might help, but I couldn only spot few only
>> used rarely.
>>
>> The module reference stuff (module_put/nf_ct_*_find_get etc)
>> is clearly superfluous, this runs in packet processing context
>> and shouldn't use module references but RCU.
> 
> This goes too deep, that I could help you on this.

Its not really hard, all the nf_ct_*_find_get functions on the event
sending path should be replaced by the corresponding __nf_ct_*_find
functions and the _put functions removed. In case dumping functions
are used by both the event handler and userspace triggered dumps,
the userspace path needs to call rcu_read_lock/rcu_read_unlock.