Here is what I think. Currently (trunk version as well as my original patch),
1. Without SO_REUSEPORT or when available CPU number < 8, num_bucket = 1 anyway. It duplicates 1 listener and use that for this single bucket. If folks think we should not duplicate in this case, I can modify the code to do that. 2. num_buckets is calculated = available_CPU_num/8. When available CPU is less than 8, num_buckets = 1. It checks if SO_REUSEPORT is enabled in the kernel. If yes, it will enable it. I guess that is opt-in? Maybe I misunderstood you here, Yann. Please correct me if I do. 3. Yes, I did use some extern variables. I can change the name of them to better coordinate with the variable naming conversion. We should do something with ap_prefixed? Is there anything else I should consider when I rename the variable? Thanks, Yingqi -----Original Message----- From: Yann Ylavic [mailto:ylavic....@gmail.com] Sent: Tuesday, October 07, 2014 4:19 PM To: httpd Subject: Listeners buckets and duplication w/ and w/o SO_REUSEPORT on trunk Hi, some notes about the current implementation of this (trunk only). First, whether or not SO_REUSEPORT is available, we do duplicate the listeners. This, I think, is not the intention of Yingqi Lu's original proposal, and probably my fault since I asked for the patch to be splitted in two for a better understanding (finally the SO_REUSEPORT patch only has been commited). The fact is that without SO_REUSEPORT, this serves nothing, and we'd better use one listener per bucket (as originally proposed), or a single bucket with no duplication (as before) if the performance gains do not worth it. WDYT? Also, there is no opt-in/out for this functionalities, nor a way to configure number of buckets ratio wrt number of CPUs (cores). For example, SO_REUSEPORT also exists on *BSD, but I doubt it would work as expected since IFAICT this not the same thing as in Linux (DragonFly's implementation seems to be closed to Linux' one though). Yet, the dynamic setsockopt() check will also succeed on BSD, and the functionality be enabled. So opt in (my preference) or out? Finally, some global variables (not even ap_ prefixed) are used to communicate between listen.c and the MPM. This helps not breaking the API, but this is trunk... I guess we can fix it, this is just a (self or anyone's) reminder :) Regards, Yann.
