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. _______________________________________________ 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"