Does FreeBSD have sendmmsg or recvmmsg system calls?

[Luigi Rizzo]

On Sun, Jan 3, 2016 at 6:46 PM, Robert Watson <rwatson at freebsd.org> wrote:
> On Sun, 3 Jan 2016, Rui Paulo wrote:
>
>>> NetBSD 7.0 has just introduced these two syscalls. And Linux also has
>>> them.
>>>
>>> Does FreeBSD have them? Or plan to support them in the future?
>>
>>
>> FreeBSD does not have them.  It doesn't seem especially hard to implement,
>> though.  Do you know any major application already using them?
>
>
> I see no harm in having the system calls.  When I chatted with the authors
> of nsd a couple of years ago (they had originally promoted the approach),
> they told me they felt it only offered incremental benefit and didn't
> particularly recommend that FreeBSD adopt it.  However, it would undoubtably
> see use and does offer some opportunities for future batching-related
> performance operations, so if someone wants to pursue introducing it, do go
> ahead.  Or just introduce a libc implementation that can be converted to a
> kernel implementation later if that is determined to be beneficial.  But the
> nsd observations don't (currently) lead me to believe that it is critical to
> do so.

Do not expect great speedups unless you are willing to put a ton of
work in the network stack.

When I looked at it (about 2012), the linux implementation for sendmmsg() just
looped inside the kernel on the body of sendmsg(), so the advantage was just
in the syscall enter/exit call, which on linux again was relatively cheap
anyways. So think of some 10% gain for unconnected sockets on
every msg after the first one, and maybe slightly larger on connected
sockets.
It is not easy to do better, especially for unconnected sockets,
because you have to lookup addresses for each message, possibly
going to different interfaces, so unless you are willing to implement
batching throughout the entire stack you won't see
much gain.

On the receive side, the syscall is probably another story (one can
grab a full batch of packets in one shot), though the expensive part
of the work -- dispatching packets to the socket -- was already
done on the receive interrupt handler. Same problems as in the tx
path to be solved.

cheers
luigi