On 6/29/21 8:51 AM, user wrote: > 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?
I guess, there is no other reason to lock something, unless you're protecting yourself form a race. But, I don't think that we can do anything here, because we don't and can't know if other CPU is processing the same packet right now. The problem is that OpenFlow pipeline can completely change almost all the packet headers before pushing it to conntrack and in this case it doesn't matter what was the original RSS hash or what was the original packet at all. The only thing that matters is what are the packet headers now and we can't be sure that other CPU doesn't have exactly the same packet, because it maybe executing same header updates before pushing the packet to conntrack. We also should remember that buggy application in a guest may put packets from the same flow to different Tx queues in a guest VM, and there is no RSS here to re-direct these packets, so they will be, likely, processed on different CPU cores. Best regards, Ilya Maximets. > > Thank you, > Avis > >> 下面是被转发的邮件： >> >> 发件人: Gaëtan Rivet <gr...@u256.net> >> 主题: 回复：[ovs-dev] Openvswitch patch doubts:conntrack: Fix missed 'conn' >> lookup checks. >> 日期: 2021年6月28日 GMT+8 下午5:05:23 >> 收件人: user <avis.w...@ucloud.cn> >> >> 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 >>> d...@openvswitch.org >>> 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 > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
