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

Reply via email to