writev over OpenSSL

[Eran Borovik]

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 and
receive). After-all, writev was invented for a specific reason.
Anyhow, even the temporary buffer solution is problematic. My
application might use thousands of sockets. And since I don't want to
allocate a buffer per socket, I will have no recourse but to re-use a small
amount of buffers (perhaps one per thread), and to re-create the buffer
content after every socket blocking condition. You might argue that this is
negligible as well as blocking condition is relatively rare, but still
these are extra wasted cycles.
Anyhow, if there isn't any other viable solution,  temporary buffer it is.

Regards,
Eran

On Sun, Feb 2, 2020 at 5:47 PM Marian Beermann <public at enkore.de> wrote:

> > 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 CPU at a throughput of 2-4 GB/s, which is about an order
> of magnitude slower than streaming memory throughput.
>
> -Marian
>
> Am 02.02.20 um 15:27 schrieb Eran Borovik:
> > Hi all,
> > I am in the process of integrating OpenSSL with my application. My
> > application uses scatter-gather unencrypted buffers. Without OpenSSL, I
> > would use writev with no issues. Is there a way to do the equivalent
> > over OpenSSL? I understand that I can split the vector into multiple
> > SSL_write/SSL_read operations but that defeats the purpose and has a
> > large overhead. Creating a temporary buffer and then consolidating the
> > vector is a problem because of the performance cost associated with
> > memory copy.
> > Is there a clean way to achieve this without the performance overhead.
> > Perhaps dealing with BIOs directly?
> >
> > Many thanks,
> > Eran
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20200202/20a17d84/attachment.html>