[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAOrHB_DU4YtPqdrReW5Mc555axcgM_L+7tN31kgpYW+uw+ZYMw@mail.gmail.com>
Date: Fri, 28 Sep 2018 10:15:29 -0700
From: Pravin Shelar <pshelar@....org>
To: Stefano Brivio <sbrivio@...hat.com>
Cc: Matteo Croce <mcroce@...hat.com>,
Justin Pettit <jpettit@...are.com>,
Greg Rose <gvrose8192@...il.com>, Ben Pfaff <blp@....org>,
Linux Kernel Network Developers <netdev@...r.kernel.org>,
ovs dev <dev@...nvswitch.org>, Jiri Benc <jbenc@...hat.com>,
Aaron Conole <aconole@...hat.com>,
William Tu <u9012063@...il.com>
Subject: Re: [PATCH RFC net-next] openvswitch: Queue upcalls to userspace in
per-port round-robin order
On Wed, Sep 26, 2018 at 2:58 AM Stefano Brivio <sbrivio@...hat.com> wrote:
>
> Hi Pravin,
>
> On Wed, 15 Aug 2018 00:19:39 -0700
> Pravin Shelar <pshelar@....org> wrote:
>
> > I understand fairness has cost, but we need to find right balance
> > between performance and fairness. Current fairness scheme is a
> > lockless algorithm without much computational overhead, did you try to
> > improve current algorithm so that it uses less number of ports.
>
> In the end, we tried harder as you suggested, and found out a way to
> avoid the need for per-thread sets of per-vport sockets: with a few
> changes, a process-wide set of per-vport sockets is actually enough to
> maintain the current fairness behaviour.
>
> Further, we can get rid of duplicate fd events if the EPOLLEXCLUSIVE
> epoll() flag is available, which improves performance noticeably. This
> is explained in more detail in the commit message of the ovs-vswitchd
> patch Matteo wrote [1], now merged.
>
> This approach solves the biggest issue (i.e. huge amount of netlink
> sockets) in ovs-vswitchd itself, without the need for kernel changes.
>
Thanks for working on this issue.
> It doesn't address some proposed improvements though, that is, it does
> nothing to improve the current fairness scheme, it won't allow neither
> the configurable fairness criteria proposed by Ben, nor usage of BPF
> maps for extensibility as suggested by William.
>
> I would however say that those topics bear definitely lower priority,
> and perhaps addressing them at all becomes overkill now that we don't
> any longer have a serious issue.
>
> [1] https://patchwork.ozlabs.org/patch/974304/
Nice!
Thanks,
Pravin.
Powered by blists - more mailing lists