<div dir="ltr">> 
I urge you to run an experient yourself, if these observations are not<br><div>
> what you expect. I was surprised, as well.</div><div>Very interesting. I'll run some tests.<br></div><div><br></div><div>We do agree that IP_BIND_ADDRESS_NO_PORT should fix OPs' problem, right? With it enabled, there's no path to inet_csk_bind_conflict which is where OPs CPU spend too much time.</div><div><br></div><div>- Anders<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Dec 10, 2022 at 4:23 PM David Fifield <<a href="mailto:david@bamsoftware.com">david@bamsoftware.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, Dec 10, 2022 at 09:59:14AM +0100, Anders Trier Olesen wrote:<br>
> IP_BIND_ADDRESS_NO_PORT did not fix your somewhat similar problem in your<br>
> Haproxy setup, because all the connections are to the same dst tuple <ip, port><br>
> (i.e 127.0.0.1:ExtORPort).<br>
> The connect() system call is looking for a unique 5-tuple <protocol, srcip,<br>
> srcport, dstip, dstport>. In the Haproxy setup, the only free variable is<br>
> srcport <tcp, 127.0.0.1, srcport, 127.0.0.1, ExtORPort>, so toggling<br>
> IP_BIND_ADDRESS_NO_PORT makes no difference.<br>
<br>
No—that is what I thought too, at first, but experimentally it is not<br>
the case. Removing the IP_BIND_ADDRESS_NO_PORT option from Haproxy and<br>
*doing nothing else* is sufficient to resolve the problem. Haproxy ends<br>
up binding to the same address it would have bound to with<br>
IP_BIND_ADDRESS_NO_PORT, and there are the same number of 5-tuples to<br>
the same endpoints, but the EADDRNOTAVAIL errors stop. It is<br>
counterintuitive and unexpected, which why I took the trouble to write<br>
it up.<br>
<br>
As I wrote at #40201, there are divergent code paths for connect in the<br>
kernel when the port is already bound versus when it is not bound. It's<br>
not as simple as filling in blanks in a 5-tuple in otherwise identical<br>
code paths.<br>
<br>
Anyway, it is not true that all connections go to the same (IP, port).<br>
(There would be no need to use a load balancer if that were the case.)<br>
At the time, we were running 12 tor processes with 12 different<br>
ExtORPorts (each ExtORPort on a different IP address, even: 127.0.3.1,<br>
127.0.3.2, etc.). We started to have EADDRNOTAVAIL problems at around<br>
3000 connections per ExtORPort, which is far too few to have exhausted<br>
the 5-tuple space. Please check the discussion at #40201 again, because<br>
I documented this detail there.<br>
<br>
I urge you to run an experient yourself, if these observations are not<br>
what you expect. I was surprised, as well.<br>
_______________________________________________<br>
tor-relays mailing list<br>
<a href="mailto:tor-relays@lists.torproject.org" target="_blank">tor-relays@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays" rel="noreferrer" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays</a><br>
</blockquote></div>