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