On 2/3/20 7:00 AM, Michael Wojcik wrote:
>> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
>> Viktor Dukhovni
>> Sent: Sunday, February 02, 2020 11:10
>>
>> On Sun, Feb 02, 2020 at 05:28:19PM +, Salz, Rich via openssl-users wrote:
>>
>>> TLS/TLS will take your data
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> Viktor Dukhovni
> Sent: Sunday, February 02, 2020 11:10
>
> On Sun, Feb 02, 2020 at 05:28:19PM +, Salz, Rich via openssl-users wrote:
>
> > TLS/TLS will take your data and wrap it inside it’s own record
> > structur
I truly appreciate all the answers. Makes sense!!
Most of my background is from systems where reducing (or even eliminating)
memory copy by the CPU was the holy grail (using RDMA and other such
techniques). I do realize that compared to all the other overheads in the
network and OpenSSL path, we ca
On Sun, Feb 02, 2020 at 05:28:19PM +, Salz, Rich via openssl-users wrote:
> TLS/TLS will take your data and wrap it inside it’s own record
> structure. It has to, that’s the nature of the protocol. Thinking
> that a single writev() is “encrypt buffers and then do analogous
> syscall” is wron
TLS/TLS will take your data and wrap it inside it’s own record structure. It
has to, that’s the nature of the protocol. Thinking that a single writev() is
“encrypt buffers and then do analogous syscall” is wrong.
So if I understand correctly, the desirable advantages with writev(2)
are atomicity across the set of buffers passed as well as minimum
system call overhead.
I can't see that we have support for this kind of construct. We
*could* simulate something like that with smartly written BIOs, but
it woul
This has of course come up before - there was an energetic discussion on this
list back in May 2001, and then again in August of that year. Eric Rescorla was
one of the participants (as was I).
And the answer has always been that given the miniscule performance gain,[1]
and portability issues f
Hi Marian,
Thank you for the prompt response. I do understand that the overhead of
encryption actually shadows the memory overhead involved, but still lost
cycles are lost cycles. And these cycles might have been used by other
logic (in the end of the day, the application does much more than send a
> Creating a temporary buffer and then consolidating the
> vector is a problem because of the performance cost associated with
> memory copy.
Did you actually benchmark this or do you just think this is the case?
Consider that SSL_write/read will normally do something like AES or
Chapoly on your C
