It seems that email that I send to Tao YunXiang bounces; at least, this
one did. I hope that he sees my previous email via the list.
----- Forwarded message from Mail Delivery System
<mailer-dae...@relay12.mail.gandi.net> -----
Date: Tue, 11 May 2021 20:00:42 +0000 (UTC)
From: Mail Delivery System <mailer-dae...@relay12.mail.gandi.net>
To: b...@ovn.org
Subject: Undelivered Mail Returned to Sender
Message-Id: <20210511200042.99d1f200...@relay12.mail.gandi.net>
This is the mail system at host relay12.mail.gandi.net.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<taoyunxi...@cmss.chinamobile.com>: host mx.cmss.chinamobile.com[221.176.66.77]
said: 550 2eec609ae26442b-87c46 Mail rejected (in reply to end of DATA
command)
Reporting-MTA: dns; relay12.mail.gandi.net
X-Postfix-Queue-ID: E4E0E200006
X-Postfix-Sender: rfc822; b...@ovn.org
Arrival-Date: Tue, 11 May 2021 20:00:34 +0000 (UTC)
Final-Recipient: rfc822; taoyunxi...@cmss.chinamobile.com
Original-Recipient: rfc822;taoyunxi...@cmss.chinamobile.com
Action: failed
Status: 5.0.0
Remote-MTA: dns; mx.cmss.chinamobile.com
Diagnostic-Code: smtp; 550 2eec609ae26442b-87c46 Mail rejected
Date: Tue, 11 May 2021 13:00:30 -0700
From: Ben Pfaff <b...@ovn.org>
To: Tao YunXiang <taoyunxi...@cmss.chinamobile.com>
Cc: d...@openvswitch.org
Subject: Re: [ovs-dev] [PATCH] ofproto-dpif-upcall: Improve concurrency by
adjust flow-limit
Message-ID: <yjrixgzg+dm7b...@ovn.org>
On Tue, May 11, 2021 at 03:52:00PM +0800, Tao YunXiang wrote:
> Author: Tao YunXiang <taoyunxi...@cmss.chinamobile.com>
You don't need an Author: tag because Git stores the author in a
separate field.
> + /* Use duration as a reference, adjust the number of flow_limit,
> + * when the duration is small, increase the flow-limit, and vice
> versa */
> + if (duration >= 1000) {
> flow_limit /= duration / 1000;
> - } else if (duration > 1300) {
> - flow_limit = flow_limit * 3 / 4;
> - } else if (duration < 1000 &&
> - flow_limit < n_flows * 1000 / duration) {
> - flow_limit += 1000;
> + } else {
> + flow_limit *= 1000 / duration;
> }
> flow_limit = MIN(ofproto_flow_limit, MAX(flow_limit, 1000));
> atomic_store_relaxed(&udpif->flow_limit, flow_limit);
The above is very abrupt. It always tries to adjust the flow limit
upward or downward. I think that this is a bad idea, especially in the
upward direction. If there are only a few flows, which only take a few
milliseconds to revalidate, then it will keep increasing the flow limit
upward until it overflows the range of unsigned int. It will happen
very quickly, in fact: if duration is 1 ms three times in a row, then we
will multiply flow_limit by 1,000,000,000 and overflow 32-bit UINT_MAX;
if it happens six times in a row, we will overflow 64-bit.
Furthermore, it doesn't work well even if we have longer durations. If
revalidation takes 501 ms, then we can adjust the flow_limit upward, but
this won't do it.
On the downward direction, this new code does nothing if the duration is
less than 2 seconds. We want to aim for 1-second revalidation times.
I don't think that this approach has been thought through very well.
----- End forwarded message -----
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
