httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <ylavic....@gmail.com>
Subject Re: Listeners buckets and duplication w/ and w/o SO_REUSEPORT on trunk
Date Wed, 08 Oct 2014 00:03:52 GMT
On Wed, Oct 8, 2014 at 1:50 AM, Lu, Yingqi <yingqi.lu@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.dev@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.

Mime
View raw message