[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180926115821.7cd9fed8@epycfail>
Date: Wed, 26 Sep 2018 11:58:21 +0200
From: Stefano Brivio <sbrivio@...hat.com>
To: Pravin Shelar <pshelar@....org>
Cc: Matteo Croce <mcroce@...hat.com>,
Justin Pettit <jpettit@...are.com>,
Greg Rose <gvrose8192@...il.com>, Ben Pfaff <blp@....org>,
netdev <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
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.
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/
--
Stefano
Powered by blists - more mailing lists