<div dir="ltr">Hi guys,<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 3, 2017 at 11:02 AM, Rhys Weatherley <span dir="ltr"><<a href="mailto:rhys.weatherley@gmail.com" target="_blank">rhys.weatherley@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class="gmail-"><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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><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></div></div></div></blockquote><div><br></div><div>Absolutely! The minimization of "memcpy" especially in NUMA case is one of intention. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><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></div></div></div></blockquote><div><br>Sure, such workaround is possible. But I think the life could be much easier if Noise protocol permits to have "jumbo" messages by itself.<br></div><div>I.e. less coding at application protocol level.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><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></div></blockquote><div><br></div><div>I understand the reasoning why 16-bit length was specified initially. E.g. 32-bit is definitely overhead for IoT. But it could be nice to have some possibility (probably at handshake phase) to negotiate the message length size. As a result IoT application could reject any connections with "jambo"-sized messages. Currently our hi-speed application works only with our application connections only in any case, so we could use MB-sized messages always in simple way:)<br><br></div><div>BTW, is anybody working now on the Noise implementation over the boost.asio?<br></div><div><br></div><div>Regards,<br></div><div>Igor.<br></div><div> </div></div></div></div>