On Wed, Oct 8, 2014 at 2:26 AM, Yann Ylavic <ylavic....@gmail.com> wrote: > On Wed, Oct 8, 2014 at 2:03 AM, Yann Ylavic <ylavic....@gmail.com> wrote: >> On Wed, Oct 8, 2014 at 1:50 AM, Lu, Yingqi <yingqi...@intel.com> wrote: >>> 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. > > For example, ap_duplicate_listeners could be modified to provide > mpm_listen and even do the computation of num_buckets and provide it > (this is not an API change since it is trunk only for now). > > ap_close_listeners() could be then restored as before (work on > ap_listeners only) and ap_close_duplicated_listeners(mpm_listen) be > introduced and used in the MPMs instead. > > Hence ap_listen_rec *mpm_listeners could be MPM local, which would > then call ap_duplicate_listeners(..., &mpm_listeners, &num_buckets) > and ap_close_duplicated_listeners(mpm_listeners)
All these (new) fields could also be in a struct so that future changes won't require a new function. > > That's just a quick thought... > >> >> 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.
