Does FreeBSD have sendmmsg or recvmmsg system calls?

[Konstantin Belousov]

On Thu, Jan 07, 2016 at 10:31:13AM -0800, Luigi Rizzo wrote:
> While it was good to have the first patch as a reminder of what needs to be done
> (noticeably, discuss the various pieces to be modified and how to deal
> with errors and the comments about DoS and malloc), I think that at
> the moment it is premature to implement either the library functions
> or the syscalls.
> 
> What we need first is experimental data that shows a performance benefit
> compared to looping around the single-packet syscall. Then we can decide
> how to proceed.
This is about performance.

> 
> Implementing the library function now is relatively pointless: its only use
> would be to compile some software that requires *mmsg() , and we can address
> that with a custom patch for the application (which almost surely would
> need to work around another ton of linux-specific functions).
And this is about compatibility.  I agree with the statement above about
the work with the performance motivation, but I do not agree that we should
not ensure compatibility because there is more to do.  We have willing
contributor, who learns, and who is on track to provide a usable
implementation for the compat shims, be it in userspace or kernel (I do
prefer userspace implementation).

I do not understand you point that we can patch application.  IMO it
is not a useful or scalable approach to handle changing app expectations
from the base platform.

> 
> Implementing the syscall that just reflects the libc function, as Kostantin
> rightly commented, may be too limited, and we cannot tell until we know
> what solution permits achieving decent performance improvements,
> especially on the send side -- e.g. some argument to tell the syscall
> "there are more packets coming down so please hold on a bit".
> For receive, there is probably very little room for enhancements,
> the best we can do is grab everything from the socket.

Yes, this is an argument for two things: to make libc wrapper, and to
measure kernel variant, as an option.