[ovs-dev] bounce for Tao YunXiang

Ben Pfaff blp at ovn.org
Tue May 11 20:20:20 UTC 2021


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-DAEMON at relay12.mail.gandi.net> -----

Date: Tue, 11 May 2021 20:00:42 +0000 (UTC)
From: Mail Delivery System <MAILER-DAEMON at relay12.mail.gandi.net>
To: blp at ovn.org
Subject: Undelivered Mail Returned to Sender
Message-Id: <20210511200042.99D1F20000B at 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

<taoyunxiang at 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; blp at ovn.org
Arrival-Date: Tue, 11 May 2021 20:00:34 +0000 (UTC)

Final-Recipient: rfc822; taoyunxiang at cmss.chinamobile.com
Original-Recipient: rfc822;taoyunxiang at 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 <blp at ovn.org>
To: Tao YunXiang <taoyunxiang at cmss.chinamobile.com>
Cc: dev at openvswitch.org
Subject: Re: [ovs-dev] [PATCH] ofproto-dpif-upcall: Improve concurrency by
 adjust flow-limit
Message-ID: <YJriXgzg+Dm7bl43 at ovn.org>

On Tue, May 11, 2021 at 03:52:00PM +0800, Tao YunXiang wrote:
> Author: Tao YunXiang <taoyunxiang at 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 -----


More information about the dev mailing list