[ovs-dev] Fwd: Openvswitch patch doubts:conntrack: Fix missed 'conn' lookup checks.
i.maximets at ovn.org
Tue Jun 29 11:54:31 UTC 2021
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,
>> 发件人: 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
> dev mailing list
> dev at openvswitch.org
More information about the dev