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@xxxxxxxxx> 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
