[ovs-dev] Fwd: Openvswitch patch doubts:conntrack: Fix missed 'conn' lookup checks.
avis.wang at ucloud.cn
Tue Jun 29 06:51:44 UTC 2021
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?
> 发件人: Gaëtan Rivet <grive at u256.net>
> 主题: 回复：[ovs-dev] Openvswitch patch doubts:conntrack: Fix missed 'conn' lookup checks.
> 日期: 2021年6月28日 GMT+8 下午5:05:23
> 收件人: user <avis.wang at 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.
>> dev mailing list
>> dev at openvswitch.org
> 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
More information about the dev