<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>It seems absent from the BSDs, but on Linux you can pass the MSG_MORE flag to send() to override TCP_NODELAY for a specific write</div><div><br></div><div>On Wed, 15 May 2024, at 19:40, Job Snijders via Bird-users wrote:<br></div><blockquote type="cite" id="qt" style=""><div dir="auto">Dear Marco,<br></div><div><div><br></div><div class="qt-gmail_quote"><div dir="ltr" class="qt-gmail_attr">On Wed, 15 May 2024 at 19:27, Marco d'Itri <<a href="mailto:md@linux.it">md@linux.it</a>> wrote:<br></div><blockquote class="qt-gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204, 204, 204);"><div>On May 15, Job Snijders via Bird-users <<a href="mailto:bird-users@network.cz" target="_blank">bird-users@network.cz</a>> wrote:<br></div><div> <br></div><div> > But please be very careful in considering this patch, because it does<br></div><div> > introduce some subtle changes in the on-the-wire behaviour of BIRD. For<br></div><div> > example, without this patch an UPDATE for a handful of routes and the<br></div><div> > End-of-RIB marker might end up in the same TCP packet (if this fits);<br></div><div> > but with this patch, the End-of-RIB marker ends up in its own TCP<br></div><div> > packet. As things are today, setting TCP_NODELAY will increase the<br></div></blockquote><div dir="auto"><br></div><blockquote class="qt-gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204, 204, 204);" dir="auto"><div><br></div><div>I think that this can be fixed easily with TCP_CORK.<br></div><div> Basically, with TCP_NODELAY + TCP_CORK you can have the optimal balance <br></div><div> of latency and overhead without using writev.<br></div></blockquote><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Yes, thanks for sharing this suggestion.<br></div><div dir="auto"><br></div><div dir="auto">Note that TCP_CORK is a Linux-only feature (on FreeBSD it seems aliased to TCP_NOPUSH, but I might be misunderstanding that code). There are subtle differences between NOPUSH and CORK: resetting CORK triggers a flush, whereas resetting NOPUSH does not.<br></div><div dir="auto"><br></div><div dir="auto">It is of course reasonable to optimize one platform and not others, we work with the tools that we have - but a portable approach (using writev()?) would seem attractive to me :-)<br></div><div dir="auto"><br></div><div dir="auto">Kind regards,<br></div><div dir="auto"><br></div><div dir="auto">Job<br></div><blockquote class="qt-gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204, 204, 204);" dir="auto"><br></blockquote></div></div></blockquote></body></html>