Does FreeBSD have sendmmsg or recvmmsg system calls?

[Luigi Rizzo]

On Thu, Jan 7, 2016 at 8:12 AM, Konstantin Belousov <kostikbel at gmail.com> wrote:
> On Thu, Jan 07, 2016 at 03:29:23PM +0200, Boris Astardzhiev wrote:

>> >What are the reasons to go with the trivial kernel implementation
>> >right now, instead of trivial and simpler libc wrapper ?  I think the
>> >speed would be same, but the code _much_ simpler.
>>
>> My initial idea was such that with the kernel approach we get closer to the
>> driver itself and if it has mm optimizations we may have a benefit in
>> future.
>> And thus one day we won't need to redo the work scrubbing the libc-only
>> implementation.
>
> I suspect that the actual syscall interface would be more rich than the
> direct translation of the function signature into the syscall.  IMO it
> would be easier for you to get the pure libc implementation correct
> for the first step.
>
> With such changes, I alway much prefer to have the hard part prototyped
> before making the bound changes in the API/ABI, which in this case means
> that some protocol should be enchanced to the multi-message interface.


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.

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).

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.

cheers
luigi


-----------------------------------------+-------------------------------
 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)
-----------------------------------------+-------------------------------