Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Date: Fri, 24 Feb 2017 13:46:16 +0100 (MET)
From: Niklas Edmundsson <nikke@acc.umu.se>
To: httpd-dev <dev@httpd.apache.org>
Subject: Re: httpd 2.4.25, mpm_event, ssl: segfaults
In-Reply-To: <CAKQ1sVNCKvSYbgtxH-6rLqytz6d2JOGWc48STEpLYE5LP6LA1w@mail.gmail.com>
Message-ID: <alpine.GSO.2.20.1702241326260.18841@hatchepsut.acc.umu.se>
References: <alpine.GSO.2.20.1702011839170.17193@hatchepsut.acc.umu.se> <a0a55e81-f532-0eff-30e5-bd5b197dc672@gmail.com> <CAKQ1sVPfCFXAAPWADzaUp_VhLC8KF=Ub5bCQQBO=hze37iNMww@mail.gmail.com> <CAKQ1sVP0du2cLuxoky4y+HV7rKLM9txpAb4HA8mbwSBMDx7TEA@mail.gmail.com>
 <2B733D2A-F05D-4857-9434-721A9AE78CF8@greenbytes.de> <CAKQ1sVP8njX=HvyS7vc4eC7+_vconLk15mq+2DuUMbej+QY73Q@mail.gmail.com> <CAKQ1sVPJVJq9Z69f-B9C2mnyX1Y7xyY7GYzSxVf17=EzoTKaSQ@mail.gmail.com> <CAKQ1sVP57ALufNgSLng0OhkMe7bgq+3qecw__VYeRhAwVQBvLQ@mail.gmail.com>
 <30d3bd5d-48cf-770f-53c8-b4ec279da2bd@gmail.com> <alpine.GSO.2.20.1702192212351.26208@hatchepsut.acc.umu.se> <712ee78b-179f-1381-7aec-ad9d9ccb9334@gmail.com> <alpine.GSO.2.20.1702221913240.13789@hatchepsut.acc.umu.se> <a9bd24fb-cba1-4aea-2cf1-0f5c5179844e@gmail.com>
 <alpine.GSO.2.20.1702222232240.26700@hatchepsut.acc.umu.se> <6c680741-4c6d-635a-5a2c-c6d54b843b8b@gmail.com> <CAKQ1sVNCKvSYbgtxH-6rLqytz6d2JOGWc48STEpLYE5LP6LA1w@mail.gmail.com>
User-Agent: Alpine 2.20 (GSO 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
archived-at: Fri, 24 Feb 2017 12:47:29 -0000

On Fri, 24 Feb 2017, Yann Ylavic wrote:

> On Thu, Feb 23, 2017 at 8:50 PM, Jacob Champion <champion.p@gmail.com> wrote:
>>> Going off on a tangent here:
>>>
>>> For those of you who actually know how the ssl stuff really works, is it
>>> possible to get multiple threads involved in doing the encryption, or do
>>> you need the results from the previous block in order to do the next
>>> one?
>>
>> I'm not a cryptographer, but I think how parallelizable it is depends on the
>> ciphersuite in use. Like you say, some ciphersuites require one block to be
>> fed into the next as an input; others don't.
>
> Yes, and the cost of scheduling threads for non dedicated cypto device
> is not worth it I think.
> But mainly there is not only one stream involved in a typical HTTP
> server, so probably multiple simulteneous connections already saturate
> the AES-NI...

Actually, the AES-NI capability can be seen as a dedicated crypto 
device of sorts... It's just a bit more versatile with a CPU core 
stuck in there as well ;-)

I would much prefer if httpd could be able to push full bandwidth 
single-stream https using multiple cores instead of enticing users to 
use silly "parallel get" clients, download accelerators and whatnot.

Granted, the use cases are not perhaps the standard 
serve-many-files-to-the-public ones, but they do exist. And depending 
on which way the computing trends blow we might start seeing more 
competing low-power cpus with more cores and less capability requiring 
more threads to perform on single/few-stream workloads.

In any event I don't think the basic idea of multiple-thread-crypto 
should be dismissed lightly, especially if someone (definitely not me) 
figures out a neat way to do it :-)

Personally, it's the angst! of having to wait more than 10 seconds for 
a DVD-sized Linux-distro.iso download when I KNOW that there are 7 
cores idling and knowing that without the single-core bottleneck I 
would have 6 additionals seconds of time to spend on something useful 
8-()


/Nikke - thinking that the Subject is not that accurate anymore...
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se      |     nikke@acc.umu.se
---------------------------------------------------------------------------
  Sattinger's Law:  It works better if you plug it in.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=