netdev - Re: Performance decrease in ipt_do

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Tue, 18 Apr 2023 18:27:56 +0200
From:   Nicolas Dichtel <nicolas.dichtel@...nd.com>
To:     "pengyi (M)" <pengyi37@...wei.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "dsahern@...nel.org" <dsahern@...nel.org>,
        "pablo@...filter.org" <pablo@...filter.org>
Cc:     Caowangbao <caowangbao@...wei.com>, liaichun <liaichun@...wei.com>,
        "Yanan (Euler)" <yanan@...wei.com>
Subject: Re: Performance decrease in ipt_do_table

Le 18/04/2023 à 16:37, pengyi (M) a écrit :
> Hi, I found after the commit d43b75fbc23f [vrf: don't run conntrack on vrf with !dflt qdisc] in vrf.c , the performance of ipt_do_table decreased. In vrf.c, the locally generated packet was marked as "untracked" in vrf_ip_out, because it won't be processed by the router(also mentioned in commit. d43b75fbc23f). And it will also made the statebit was set to XT_CONNTRACK_STATE_UNTRACKED in conntrack_mt, which means we didn't had the information about in conntrack so we had to re-analysize the packet by calling tcp_mt().
> 
> However, after the commit d43b75fbc23f , all packets in vrf_ip_out was marked as "untracked", which made more times of calling tcp_mt(). Hence the time of processing all packets became longer and it affected the performance of ipt_do_table() in total. I wonder is it an expected behavior to see the performance decrease after the commit d43b75fbc23f ?
It was not the goal of this commit :)
The performance regression seems to be specific to your rule set.
As explained in the commit log, the goal was to have the same packet processing,
whatever qdisc is configured on the vrf interface.
Before this patch, you should have the same performance level (as now) if a
qdisc is configured.


Regards,
Nicolas