Does FreeBSD have sendmmsg or recvmmsg system calls?

[Luigi Rizzo]

On Thu, Jan 7, 2016 at 2:38 PM, Mark Delany <c2h at romeo.emu.st> wrote:
> On 07Jan16, Luigi Rizzo allegedly wrote:
>> On Thu, Jan 7, 2016 at 11:28 AM, Konstantin Belousov

>> 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?

Actually I'd like to see data that show the performance gain
before going and implementing the new functions.
Of course someone has to experiment with them (and I wish I
had the time, but now I don't), but that does not imply putting
the code in the main FreeBSD tree. Whoever has the time and
expertise to do the necessary implementation and testing
of the proper kernel side (and application restructuring)
will take zero time to also write the libc wrapper.

I don't want to be negative but when (3 years ago) played with
sendmmsg() on linux the benefits were marginal if measurable at all.

Also I want to add one bit of information here.

Restructuring applications so that they use batching
is very complicated, because it has to happen at all
layers. An approach that we used with good results in
the past (back in 2013 when we added netmap support to
Qemu, and then later for bhyve) is add a flag
to the API so a producer can signal that more packets
are coming and each layer can construct a batch.

https://lists.gnu.org/archive/html/qemu-devel/2013-12/msg01091.html

The change was not accepted in qemu "does not help in linux".
Sure enough, one year later linux added a similar thing
with a big fanfare

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=35a9ad8af0b

This is probably the way to go for achieving high tx speeds,
adding support for the flag in the layers of the network
stack and probably also to sendmsg() .

cheers
luigi

>
> 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.
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"



-- 
-----------------------------------------+-------------------------------
 Prof. Luigi RIZZO, rizzo at iet.unipi.it  . Dip. di Ing. dell'Informazione
 http://www.iet.unipi.it/~luigi/        . Universita` di Pisa
 TEL      +39-050-2217533               . via Diotisalvi 2
 Mobile   +39-338-6809875               . 56122 PISA (Italy)
-----------------------------------------+-------------------------------