Hi Gaetan, Thanks for your resolve. It is indeed possible for tunneled packets to be allocated to different CPUs by RSS, in which case a check before adding connTrack is necessary. And I didn't made it clear that the two packets belong to the same conntrack. What I mean is that the two packets are both from the direction of origin with ct_state of +new(and both of them are not tunnneled pkts). They have the same header and try to generate the same conntrack. Such packets are unlikely to be distributed by RSS to different CPUs. So can I say that in certain situations, such as the header of pkts in the same direction of a conntrack to be created are the same, we can skip the check before inserting a 'conn' entry? Is there any reason other than CPU contention for us to do this?
Thank you, Avis > 下面是被转发的邮件： > > 发件人: Gaëtan Rivet <[email protected]> > 主题: 回复：[ovs-dev] Openvswitch patch doubts:conntrack: Fix missed 'conn' lookup > checks. > 日期: 2021年6月28日 GMT+8 下午5:05:23 > 收件人: user <[email protected]> > > On Mon, Jun 28, 2021, at 05:45, user wrote: >> Hi Ben, >> I think this situation may not happen, because if there are two >> pkts are going to create the same conntrack, their headers will be >> roughly the same, the rss of the hardware will assign the packets to >> the same cpu, so there is no chance for two threads to try to insert >> the same conntrack at the same time, so I am confused about the reason >> for doing this and what are the missing cases. >> >> Avis >> _______________________________________________ >> dev mailing list >> [email protected] >> https://mail.openvswitch.org/mailman/listinfo/ovs-dev >> > > Hello Avis, > > It would be easier to follow if you replied to the previous thread instead of > sending > a separate email. > >> their headers will be roughly the same, the rss of the hardware will assign >> the packets to the same cpu > > No, the headers won't be roughly the same. Either the 5-tuple is the > symmetrical inverse > for regular CT, or mostly different for NAT or in case of tunneling (RSS is > done > on the outer packet). Even with a clean symmetrical inverse, the RSS will be > completely > different unless symmetric RSS is used (needs explicit conf on some hardware, > implicit > support or no support at all on some others). > > With symmetric RSS (assuming the hardware exposes a capability to detect > support, which > it does not currently), NAT or tunneling will then break symmetry. For NAT > you can tweak > the tuple generation such that the resulting RSS will fall on the proper CPU. > For tunneling > however I don't see how you could tweak anything, as we don't control how the > outer packet > is created. In VXLAN for example, some sender will modulate the UDP src port > to get 16 bits > of entropy, but as the middlebox we cannot influence it. > > Without symmetry, we have a potential race between cores to process a > connection, > so locks are needed for insertion or state update. > > -- > Gaetan Rivet > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
