Actually use sendmmsg when using UDP?
Hi all,
I hope you're all staying safe and keeping your sanity in these troubling times -- I know they are taking a toll on me
I was starting to look into sendmmsg
to optimize the performance in Janus. In fact, from some profiling we did, it turned out most of the execution time is taken by system calls to send data, which can be a problem with so many packets to send in real-time (each outgoing packet is a different system call, and that adds up). Being able to use a single system call to actually push out more than one packet at a time could actually greatly increase performance, as demonstrate by a couple of other SFU developers. This is exactly what sendmmsg
is supposed to facilitate.
Looking at the libnice documentation, there is indeed a method called nice_agent_send_messages_nonblocking that allows applications to pass a bulk of messages to the library, but while the documentation states that
In this manner, nice_agent_send_messages_nonblocking() is analogous to sendmmsg(); and NiceOutputMessage to struct mmsghdr
digging in the code a bit this doesn't seem to be 100% correct. For UDP in particular (udp-bsd.c
), it triggers socket_send_messages()
, which internally though simply iterates on each message to invoke socket_send_message()
multiple times. As a result, each socket_send_message()
performs a separate g_socket_send_message()
call, which means each message has its own system call anyway.
From what I could understand, it should be relatively easy to modify socket_send_messages()
so that it does pretty much what socket_send_message()
does, but using g_socket_send_messages()
instead: I was looking at how it's implemented in Glib, and it does seem to actually make use of sendmmsg
in case the HAVE_SENDMMSG
define is set. I plan to start tinkering a bit with this in the next few days, and possibly make have my colleagues perform some additional tests (and possibly some additional profiling) to see if it actually brings any benefit.
Would you consider a pull request that implements this behaviour, in case, or are there any reason why it may be a bad idea? I'm thinking in particular about potential implications my patch might have on other parts of the libnice core that I may not be taking into account now.
Thanks!