Re: Re: Performance decrease in ipt_do_table

Re: Re: Performance decrease in ipt_do_table

[pengyi (M)]

Thank you for the reply, I have another question about the fixed patch mentioned in commit d43b75fbc23f. The commit 8c9c296adfae(vrf: run conntrack only in context of lower/physdev for locally generated packets) added the function vrf_nf_set_untracked() and was called in vrf_ip_out_direct(), to marking the packets as untrack. I was wondering why we should clear the packets out of the conntrack if the packet would be sent out directly, is it beneficial to the network performance? 

Another issue is that if the packet was marked as "untrack", the ipt_do_table() would spend more time because we didn't record it in the conntrack and had to analysize it. I deleted the "vrf_nf_set_untracked(skb);"and compared the two stacks. We could find the tcp_mt() would be called after the conntrack_mt_v3 and the performance increased. Any thoughts about this commit would be very thankful!

Here attached the stacks before and after the commit:
# Not deleting vrf_nf_set_untracked(skb)
# CPU  DURATION                  FUNCTION CALLS                    
# |     |   |                     |   |   |   |
  0)               |  ipt_do_table [ip_tables]() {
  0)               |    conntrack_mt_v3 [xt_conntrack]() {
  0)   0.360 us    |      conntrack_mt.isra.0 [xt_conntrack]();
  0)   1.090 us    |    }
  0)   0.370 us    |    tcp_mt();
  0)   0.300 us    |    tcp_mt();
  0)   0.300 us    |    tcp_mt();
  0)   0.290 us    |    tcp_mt();
  0)   0.310 us    |    tcp_mt();
  0)   0.300 us    |    tcp_mt();

# Deleting vrf_nf_set_untracked(skb)
# CPU  DURATION                  FUNCTION CALLS
# |     |   |                     |   |   |   |
17)               |  ipt_do_table [ip_tables]() {
17)               |    conntrack_mt_v3 [xt_conntrack]() {
17)   0.820 us    |      conntrack_mt.isra.1 [xt_conntrack]();
17)   1.690 us    |    }
17)   0.340 us    |    __local_bh_enable_ip();
17)   5.460 us    |  }
17)               |  ipt_do_table [ip_tables]() {
17)               |    conntrack_mt_v3 [xt_conntrack]() {
17)   0.720 us    |      conntrack_mt.isra.1 [xt_conntrack]();
17)   1.640 us    |    }
17)   0.330 us    |    __local_bh_enable_ip();
17)   4.470 us    |  }

Best wishes
Yi Peng

-----邮件原件-----
发件人: Nicolas Dichtel <nicolas.dichtel@6wind.com> 
发送时间: 2023年4月19日 0:28
收件人: pengyi (M) <pengyi37@huawei.com>; netdev@vger.kernel.org; davem@davemloft.net; dsahern@kernel.org; pablo@netfilter.org
抄送: Caowangbao <caowangbao@huawei.com>; liaichun <liaichun@huawei.com>; Yanan (Euler) <yanan@huawei.com>
主题: 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