On Wed, Oct 8, 2014 at 1:50 AM, Lu, Yingqi <yingqi...@intel.com> wrote: > 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.
Yes I think the duplication should be avoided. But is one listener per bucket an interesting alternative to num_buckets = 1? > > 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. Why fixed 8, wouldn't one with less than 16 cores want the feature? > > 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? Maybe defining new functions with more arguments (to be used by the existing ones with NULL or default values) is a better alternative. Please be aware that existing AP_DECLAREd functions API must not change though. Regards, Yann. > > 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.
