Does Linux handle un'accepted(2)' sockets inheritance between
SO_REUSEPORT sockets, if one of the SO_REUSEPORT socket is closed?
It's one of the concern that nginx folks have about SO_REUSEPORT. I
am not following Linux, so I am not sure about it at all. That's also
why I wanted to keep one SO_REUSEPORT socket opened.

BTW, DragonFly had my patch enabled by default in the dports system
for a long time.

And many systems have the symbol of SO_REUSEPORT and the setsockopt
works too, e.g. FreeBSD and probably other BSDs, but on kernel side,
SO_REUSEPORT does not work in the fashion like Linux or DragonFly. So
even simple run-time test would not be able detect the "new"
SO_REUSEPORT support.

Best Regards,
sephe


On Sat, Aug 23, 2014 at 12:55 AM, Lu, Yingqi <yingqi.lu@intel.com> wrote:
> Dear All,
>
>
>
> The “SO_REUSEPORT support for listen sockets support” patches submitted by
> Sepherosa Ziehau are posted and discussed in [1] and [2]. Last update on the
> threads was 09/05/2013 and the patch is not included in the current Nginx
> code. Reading from the discussion, my understanding is that his patch makes
> a dedicated listen socket for each of the child process. In order to make
> sure at any given time there is always a listen socket available, the patch
> makes the first worker process different/special than the rest.
>
>
>
> Here, I am proposing a simpler way to enable the SO_REUSEPORT support. It is
> just to create and configure certain number of listen sockets in the master
> process with SO_REUSEPORT enabled. All the children processes can inherit.
> In this case, we do not need to worry about ensuring 1 available listen
> socket at the run time. The number of the listen sockets to be created is
> calculated based on the number of active CPU threads. With big system that
> has more CPU threads (where we have the scalability issue), there are more
> duplicated listen sockets created to improve the throughput and scalability.
> With system that has only 8 or less CPU threads, there will be only 1 listen
> socket. This makes sure duplicated listen sockets only being created when
> necessary. In case that SO_REUSEPORT is not supported by the OS, it will
> fall back to the default/original behavior (this is tested on Linux kernel
> 3.8.8 where SO_REUSEPORT is not supported).
>
>
>
> This prototype patch has been tested on an Intel modern dual socket platform
> with a three tier open source web server workload
> (PHP+Nginx/memcached/MySQL). The web server has 2 IP network interfaces
> configured for testing. The Linux kernel used for testing is 3.13.9. Data
> show:
>
>
>
> Case 1: with single listen statement (Listen 80) specified in the
> configuration file, there is 46.3% throughout increase.
>
> Case 2: with dual listen statements (for example, Listen 192.168.1.1:80 and
> Listen 192.168.1.2:80), there is 10% throughput increase.
>
>
>
> Both testing cases keep everything the same except the patch itself to get
> above result.
>
>
>
> The reason that Case1 has bigger performance gains is that Case1 by default
> only has 1 listen socket while Case2 by default already has 2.
>
>
>
> Please review it and let me know your questions and comments.
>
>
>
> [1] http://forum.nginx.org/read.php?29,241283,241283
>
> [2] http://forum.nginx.org/read.php?29,241470,241470
>
>
>
> 1. Software and workloads used in performance tests may have been optimized
> for performance only on Intel microprocessors. Performance tests, such as
> SYSmark and MobileMark, are measured using specific computer systems,
> components, software, operations and functions. Any change to any of those
> factors may cause the results to vary. You should consult other information
> and performance tests to assist you in fully evaluating your contemplated
> purchases, including the performance of that product when combined with
> other products.
>
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel



--
Tomorrow Will Never Die

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel