On Sun, Jan 3, 2016 at 6:46 PM, Robert Watson <rwat...@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 _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
