On 6/4/24 11:54, Alin Serdean wrote: > Does it make sense to make this configurable via automake in order to avoid > future patches if we need to bump the value further?
I'm still not convinced this is an issue worth fixing. The original discussion is here: https://mail.openvswitch.org/pipermail/ovs-discuss/2024-April/053058.html It's not clear if these reconnections actually cause any harm or are even helpful in getting to connect to a less busy server in a general case. The original number 10 was clearly way too low for any reasonable workload. But even with that we lived for a very long time with very large clusters without any issues. The main problem in the original thread was that a lot of neutron clients are having leader-only connections to the database for seemingly no reason. That results in unnecessary mass re-connection on leadership change. So, I'd prefer this fixed in OpenStack instead. Best regards, Ilya Maximets. > > On Tue, Jun 4, 2024 at 11:05 AM Simon Horman <ho...@ovn.org> wrote: > >> + Ihar >> >> On Fri, May 31, 2024 at 03:40:08PM -0400, Brian Haley wrote: >>> An earlier patch [1] increased the size of the listen >>> backlog to 64. While that was a huge improvement over >>> 10, further testing in large deployments showed 128 >>> was even better. >> >> nit: I would slightly prefer if a commit was referenced like this: >> >> commit 2b7efee031c3 ("socket: Increase listen backlog to 64 everywhere.") >> >>> Looking at 'ss -lmt' output over more than one week for >>> port 6641, captured across three different controllers, >>> the average was: >>> >>> listen(s, 10) : 1213 drops/day >>> listen(s, 64) : 791 drops/day >>> listen(s, 128): 657 drops/day >>> >>> Looking at 'netstat -s | egrep -i 'listen|drop|SYN_RECV'' >>> output over one week for port 6641, again captured across >>> three different controllers, the average was: >>> >>> listen(s, 10) : 741 drops/day >>> listen(s, 64) : 200 drops/day >>> listen(s, 128): 22 drops/day >>> >>> While having this value configurable would be the >>> best solution, changing to 128 is a quick fix that >>> should be good for all deployments. A link to the >>> original discussion is at [2]. >>> >>> [1] >> https://github.com/openvswitch/ovs/commit/2b7efee031c3a2205ad2ee999275893edd083c1c >>> [2] >> https://github.com/openvswitch/ovs/commit/2b7efee031c3a2205ad2ee999275893edd083c1c >> >> nit: These two references are the same? >> >>> Signed-off-by: Brian Haley <haleyb....@gmail.com> >> >> I'd value input on this from Ihar (CCed) who worked on the cited commit. >> >>> --- >>> lib/socket-util.c | 2 +- >>> python/ovs/stream.py | 2 +- >>> 2 files changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/lib/socket-util.c b/lib/socket-util.c >>> index c569b7d16..552310266 100644 >>> --- a/lib/socket-util.c >>> +++ b/lib/socket-util.c >>> @@ -769,7 +769,7 @@ inet_open_passive(int style, const char *target, int >> default_port, >>> } >>> >>> /* Listen. */ >>> - if (style == SOCK_STREAM && listen(fd, 64) < 0) { >>> + if (style == SOCK_STREAM && listen(fd, 128) < 0) { >>> error = sock_errno(); >>> VLOG_ERR("%s: listen: %s", target, sock_strerror(error)); >>> goto error; >>> diff --git a/python/ovs/stream.py b/python/ovs/stream.py >>> index dbb6b2e1f..874fe0bd5 100644 >>> --- a/python/ovs/stream.py >>> +++ b/python/ovs/stream.py >>> @@ -620,7 +620,7 @@ class PassiveStream(object): >>> raise Exception('Unknown connection string') >>> >>> try: >>> - sock.listen(64) >>> + sock.listen(128) >>> except socket.error as e: >>> vlog.err("%s: listen: %s" % (name, os.strerror(e.error))) >>> sock.close() >>> -- >>> 2.34.1 >>> >>> _______________________________________________ >>> 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 >> > _______________________________________________ > 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