recvmmsg() is Linux-specific.
part of the linked documentation will shed some light?
Maybe create an port driver that implements it and use it as a backend to
gen_udp. From this you will be able to produce some benchmarks showing the benefits?
My guess is that the savings you make by calling
recvmmsg are insignificant when compared to the costs of producing an Erlang message and sending it to a process; especially when pinning processes to cores is officially ‘unsupported’ (much like connected UDP sockets).
Still would be interesting to see as it is all hand waving and guess work at the moment
Creating a separate NIF library with
recvmmsg() would have less of an overhead than a port driver. For completeness of the socket library it would make sense to make that call available on systems that support it (e.g. Linux). In my limited testing in C, the throughput improvement of using
recvmmsg() is around 15-20%. It’s understood that marshaling data to Erlang would add an overhead, but it would still free up the CPU resources spent on extra context switching and should be beneficial for applications handling a lot of network traffic.
Talk talks, code walks