On 17 Jan 2023, at 4:08, Han Zhou wrote:
> On Mon, Jan 16, 2023 at 7:14 AM Eelco Chaudron <echau...@redhat.com> wrote:
>>
>>
>>
>> On 18 Oct 2022, at 18:08, Adrian Moreno wrote:
>>
>>> On 10/14/22 19:49, Han Zhou wrote:
>>>>
>>>>
>>>> On Thu, Oct 13, 2022 at 11:43 PM Adrian Moreno <amore...@redhat.com
> <mailto:amore...@redhat.com>> wrote:
>>>>>
>>>>> Hi Han.
>>>>>
>>>>> On 8/9/22 03:40, Han Zhou wrote:
>>>>>> Today the minimum value for this setting is 1. This patch allows it
> to
>>>>>> be 0, meaning not checking pps at all, and always do revalidation.
>>>>>>
>>>>>> This is particularly useful for environments where some of the
>>>>>> applications with long-lived connections may have very low traffic
> for
>>>>>> certain period but have high rate of burst periodically. It is
> desirable
>>>>>> to keep the datapath flows instead of periodically deleting them to
>>>>>> avoid burst of packet miss to userspace.
>>>>>>
>>>>>> When setting to 0, there may be more datapath flows to be
> revalidated,
>>>>>> resulting in higher CPU cost of revalidator threads. This is the
>>>>>> downside but in certain cases this is still more desirable than
> packet
>>>>>> misses to user space.
>>>>>>
>>>>> I am trying to quantify this CPU cost. Do you have any numbers so we
> understand
>>>>> the effects of disabling pps-based evictions?
>>>>>
>>>> Hi Adrian,
>>>>
>>>> Thanks for reviewing. First of all, the CPU cost is added to
> revalidator threads only, but saving cost for the handler threads which is
> more critical to the packet processing.
>>>> Now regarding the actual CPU cost of revalidator threads, the extra
> cost really depends on the traffic pattern - how many long lived DP flows
> are there with pps smaller than <min-revalidator-pps>. The more such DP
> flows, the more revalidtor CPU, of course. We don't see a problem when
> there are 10k DP flows when setting min-revalidator-pps to 0, and this is
> on a DPU with small number of less powerful ARM cores. It also depends on
> whether it is a dedicated network node/DPU where it is ok for OVS to take a
> significant portion of the CPU or it is a compute node where more cores are
> supposed to be reserved for applications.
>>>> In any case, this is just an option and totally depends on user
> settings according to their use case, as explained in the commit message.
>>>>
>>>
>>> I agree. There are many factors that come into play. My concern is that
> we have so many knobs that tweak the revalidator/handler load distribution
> that depend on so many external factors that it's quite complicated to
> determine when to recommend their use.
>>>
>>> That's why I wanted to have some ballpark numbers to get an intuition
> of the potential side effects.
>>>
>>> Having said that, I think this particular proposal is beneficial as I
> also have seen drops caused by long-lived connections.
>>
>> I do not see anything wrong with adding this feature, however, the
> documentation needs to be clear on what 0 means, i.e. does it result in
> always revalidate or never revalidate?
>
> Thanks Eelco. I thought that min-revalidate-pps=0 naturally means
> revalidating all flows, because pps > 0 would include all flows. However,
> probably the "disable" in my commit title was confusing, and some may think
> it was trying to disable the revalidation (while I meant disable the
> option).
> So, I updated the title and also updated the document to avoid confusion in
> v2. PTAL:
> https://patchwork.ozlabs.org/project/openvswitch/patch/20230117030129.1447363-1-hz...@ovn.org/
Thanks, quickly tested and ACKed your patch.
//Eelco
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
