Is there any reason why the socket 1 API doesn’t implement/expose recvmmsg 4?

Is there any reason why the socket API doesn’t implement/expose recvmmsg?



recvmmsg() is Linux-specific.

part of the linked documentation will shed some light?

1 Like

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 :slight_smile:

1 Like

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 sendmmsg() and 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 :slight_smile: