> On May 26, 2017, at 22:21, Willy Tarreau wrote:
>
> Hi Emeric, Grant,
>
> patch set now merged! Thank you both for this great work!
>
> Willy
Bravo! Really appreciate your and Emeric's help in this effort.
Grant
> On May 15, 2017, at 03:14, Emeric Brun wrote:
>
> What does it look like?
New patches attached.
>
> The issue is very similar:
> https://mta.openssl.org/pipermail/openssl-dev/2016-March/005909.html
Interesting. yeah, it looks similar.
Regards,
Grant
> On May 10, 2017, at 04:51, Emeric Brun wrote:
>
>> It looks like the main process stalls at DH_free(local_dh_1024) (part of
>> __ssl_sock_deinit). Not sure why but I will debug and report back.
>>
>> Thanks,
>
> I experienced the same issue (stalled on a futex) if i run
> On May 9, 2017, at 02:38, Emeric Brun <eb...@haproxy.com> wrote:
>
> Hi Grant,
>
> On 05/06/2017 12:41 AM, Grant Zhang wrote:
>> Hi Emeric,
>>
>> Thanks for your review! Please see the updated patches and let me know if
>> your comment
Hi Emeric,
Thanks for your review! Please see the updated patches and let me know if your
comments have been properly addressed.
Thanks,
Grant
0001-ssl-add-basic-support-for-OpenSSL-crypto-engine.patch
Description: Binary data
0002-ssl-add-openssl-async-mode-support.patch
Description:
Hi Emeric,
> On Apr 25, 2017, at 04:03, Emeric Brun <eb...@haproxy.com> wrote:
>
> Hi Grant,
>
> On 04/10/2017 05:16 PM, Grant Zhang wrote:
>>
>>> On Apr 10, 2017, at 07:42, Emeric Brun <eb...@haproxy.com> wrote:
>>>
>>
> On Apr 10, 2017, at 07:42, Emeric Brun wrote:
>
>> * openssl version (1.1.0b-e?)
> compiled 1.1.0e
>>
>>
> Could you provide patches rebased on current dev master branch?
I am kinda busy with other project but will try to provide rebased patches this
week.
Thanks,
Hi Emeric,
Sorry for my delayed reply.
On 03/28/2017 01:47 AM, Emeric Brun wrote:
This is an atom C2518 and it seems that --disable-prf has cut the performance
in half. We should receive a 8920 soon.
Stopping the injection, the haproxy process continue to steal cpu doing nothing
(top
> On Mar 27, 2017, at 02:21, Emeric Brun wrote:
> Intel's guys told me that the bug is related to prf and asked me to recompile
> the engine using '--disable_qat_prf'. Doing that i can do some tests iwth the
> qat engine but i'm facing stability issues:
>
> [root@centos
> On Mar 21, 2017, at 06:56, Emeric Brun wrote:
>
> Hi Grant,
>
>>>
>>> I'm not sure that the issue is related to your patch, i may reach an issue
>>> int QAT engine
>>>
>>> I've made some test using openssl s_server.
>>>
>>> Doing a curl request shows this error:
>>>
Hi Emeric
> On Mar 15, 2017, at 10:05, Emeric Brun wrote:
>
> Hi John,
>
>>>
>>> There is some inconsistencies between the engine and the used client:
>>>
>>> here the conf:
>>> global
>>> tune.ssl.default-dh-param 2048
>>> ssl-engine qat
>>> ssl-async
>>>
03/15/2017 12:05 PM, Emeric Brun wrote:
>>> Hi Grant,
>>>
>>> On 02/04/2017 12:55 AM, Grant Zhang wrote:
>>>> This patch set adds the basic support for OpenSSL crypto engine and
>>>> async mode.
>>>>
>>>> Changes since
This patch set adds the basic support for OpenSSL crypto engine and
async mode.
Changes since V2:
- support keyword "algo"
- ensure SSL engines are initialized before loading certs.
- limit one async fd per SSL connection
- better integrate with event cache
Changes since V1:
- add multiple
This patch adds the global 'ssl-engine' keyword. First arg is an engine
identifier followed by a list of default_algorithms the engine will
operate.
If the openssl version is too old, an error is reported when the option
is used.
---
doc/configuration.txt | 16 ++
ssl_async is a global configuration parameter which enables asynchronous
processing in OPENSSL for all SSL connections haproxy handles. With
SSL_MODE_ASYNC mode set, TLS I/O operations may indicate a retry with
SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable
engine is used to
> On Jan 30, 2017, at 17:00, Willy Tarreau wrote:
>
> Hi Grant,
>>
>> To work around this, without complicating the init code, do you think it is
>> OK to directly call ssl_init_single_engine inside
>> ssl_parse_glabal_ssl_engine?
>
> I still find this problematic. Normally what
Hi Willy,
> On Jan 30, 2017, at 02:03, Willy Tarreau wrote:
>
> Do you think it would make sense to consider that if no list of algo is
> specified then it defaults to all ? I tend to think probably not from
> a technical perspective but maybe for some users it can make sense.
+1
This patch adds the global 'ssl-engine' keyword. First arg is an engine
identifier followed by a list of default_algorithms the engine will
operate.
If the openssl version is too old, an error is reported when the option
is used.
---
doc/configuration.txt | 15 +++
src/ssl_sock.c|
This patch adds the basic support for OpenSSL crypto engines.
Changes since V1:
- add multiple engine support
- allow default algorithms to be specified for an engine
- remove the support for engine identifier "all" since (a) it is not possible
to specify default algorithms for all engine and
1.5 but you'll see how similar they are to yours so
> you'll easily understand).
>
> Now let's go to the patches below :-)
>
>> From 0961d9807d9af10c841824bc1a5a4d72b02f Mon Sep 17 00:00:00 2001
>> From: Grant Zhang <gzh...@fastly.com>
>> Date: Sat, 14 Jan 2017 01:42:14 +
500 connections per second
Intel QAT engine[1] and async mode on: ~2000 connections per second
Your feedback and comments are greatly appreciated.
Thanks,
Grant
[1] Intel QAT openssl engine: https://github.com/01org/QAT_Engine
Grant Zhang (2):
RFC: add openssl engine support
RFC: add openssl as
ssl_async is a global configuration parameter which enables asynchronous
processing in OPENSSL for all SSL connections haproxy handles. With
SSL_MODE_ASYNC mode set, TLS I/O operations may indicate a retry with
SSL_ERROR_WANT_ASYNC with this mode set if an asynchronous capable
engine is used to
Global configuration parameter "ssl_engine" may be used to specify
openssl engine.
---
include/proto/ssl_sock.h | 2 ++
include/types/global.h | 1 +
src/cfgparse.c | 21 +
src/haproxy.c| 3 +++
src/ssl_sock.c | 38
23 matches
Mail list logo