<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Aug 3, 2017 at 4:30 PM, Alexey Ermishkin <span dir="ltr"><<a href="mailto:scratch.net@gmail.com" target="_blank">scratch.net@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I talked to guys who use TLS at >10gbps speeds and would like to reduce the amount of memcpy calls per packet which is why they want ~2mb packets.<br>
<br>
So maybe for ones who know what they are doing this may be an option.<br></blockquote><br></div><div class="gmail_quote">I assume they want to encrypt-in-place, which means minimising buffer rearrangements for inserting packet length headers and trailing MAC's.<br><br></div><div class="gmail_quote">However, using a system call like writev()/sendmsg() and a scatter/gather array, the two-byte header and 16-byte MAC's don't have to be stored in the same memory array as the payload.  Those can be stored in a separate buffer with scatter/gather stitching things back together inside the network stack.  A little trickier to pull off on the receive side.<br><br></div><div class="gmail_quote">I suppose theoretically NoiseSocket could allow for 32-bit header lengths, but internally chop things into fixed-size sub-64K chunks with MAC's along the way.  That would make it easier to use readv()/recvmsg() on the receive side as the position of the MAC's in the input stream would be predictable.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Just an idea.  I haven't profiled such a solution to see if the in-kernel stitching overhead is better or worse than user space rearrangement.<br><br></div><div class="gmail_quote">Cheers,<br><br></div><div class="gmail_quote">Rhys.<br></div></div></div>