Does FreeBSD have sendmmsg or recvmmsg system calls?

[Mark Delany]

On 07Jan16, Luigi Rizzo allegedly wrote:
> On Thu, Jan 7, 2016 at 11:28 AM, Konstantin Belousov

> Regarding patching the application(s): of course it is not scalable
> if there are many applications that will refuse to compile if
> the *mmsg() functions are absent. However I expect this set of
> application to be minuscule if not empty, and if they exist they
> are probably plagued by other portability issues.

The most common use I've seen is in DNS servers - all of which compile
on the dominant *nix platforms already. Some have also done their own
variant of a *mmsg() wrapper. nsd is one public example - though I
believe they found problems with the linux implementation.

My guess is that people stumble across the *mmsg() calls and consider
adding them to an already-portable piece of code before finding they
don't exist on FBSD. Leastwise that's my experience.

> So (and using *mmsg() vs *msg() is about performance) I think that
> until we have an underlying performant implementation of the *mmsg()
> calls, there is no urgency in implementing the libc functions,
> because we might later have to change then libc->syscall wrapper
> anyways.

Doesn't this present a bit of a chicken-and-egg problem?

In two ways. First, there is pretty low visibility (and credibility
since they are Linux-only) for these calls so programmers may not even
be structuring their code with batching in mind.

Second and more serious is that a libc implementation doesn't really
get any closer to a code-base that can be used to experiment with
performance whereas a kernel-based implementation does.

I agree with your assessment that real gains require much more than
just a kernel-side loop but my experience is that very real gains
should be possible in the long run based on a) observed significant
kernel serialization in UDP and b) comparisons with an *mmsg() wrapper
implemented on top of netmap.

I also observe that there are modest gains to be had even in
kernel-side wrappers so adoption seems probably.

I also completely understand your caution as there is a general case
for a batching I/O mechanism that is better suited to threaded
programs (one big problem being the disconnect between event detection
and data transfer.)

But that's a much bigger discussion so it's hard to know whether
tinkering with the libc/kernel interface of *mmsg() will realistically
get us closer to that or whether it's more pragmatic to treat *mmsg()
as yet another specialized interface.


Mark.