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, Han > > > //Eelco > > > >>>> Signed-off-by: Han Zhou <hz...@ovn.org <mailto:hz...@ovn.org>> > >>>> --- > >>>> ofproto/ofproto-dpif-upcall.c | 4 ++++ > >>>> ofproto/ofproto.c | 2 +- > >>>> vswitchd/vswitch.xml | 2 +- > >>>> 3 files changed, 6 insertions(+), 2 deletions(-) > >>>> > >>>> diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c > >>>> index 57f94df54..23b52ef40 100644 > >>>> --- a/ofproto/ofproto-dpif-upcall.c > >>>> +++ b/ofproto/ofproto-dpif-upcall.c > >>>> @@ -2079,6 +2079,10 @@ should_revalidate(const struct udpif *udpif, uint64_t packets, > >>>> { > >>>> long long int metric, now, duration; > >>>> > >>>> + if (!ofproto_min_revalidate_pps) { > >>>> + return true; > >>>> + } > >>>> + > >>>> if (!used) { > >>>> /* Always revalidate the first time a flow is dumped. */ > >>>> return true; > >>>> diff --git a/ofproto/ofproto.c b/ofproto/ofproto.c > >>>> index 3a527683c..259fad4b5 100644 > >>>> --- a/ofproto/ofproto.c > >>>> +++ b/ofproto/ofproto.c > >>>> @@ -723,7 +723,7 @@ ofproto_set_max_revalidator(unsigned max_revalidator) > >>>> void > >>>> ofproto_set_min_revalidate_pps(unsigned min_revalidate_pps) > >>>> { > >>>> - ofproto_min_revalidate_pps = min_revalidate_pps ? min_revalidate_pps : 1; > >>>> + ofproto_min_revalidate_pps = min_revalidate_pps; > >>>> } > >>>> > >>>> /* If forward_bpdu is true, the NORMAL action will forward frames with > >>>> diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml > >>>> index 4a9284f6b..2222c1296 100644 > >>>> --- a/vswitchd/vswitch.xml > >>>> +++ b/vswitchd/vswitch.xml > >>>> @@ -212,7 +212,7 @@ > >>>> </column> > >>>> > >>>> <column name="other_config" key="min-revalidate-pps" > >>>> - type='{"type": "integer", "minInteger": 1}'> > >>>> + type='{"type": "integer", "minInteger": 0}'> > >>>> <p> > >>>> Set minimum pps that flow must have in order to be revalidated when > >>>> revalidation duration exceeds half of max-revalidator config variable. > >>> > >>> -- > >>> Adrián Moreno > >>> > > > > -- > > Adrián Moreno > > > > _______________________________________________ > > 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