Re: recvmmsg() behaviour with MSG_PEEK flag

Thanks for the prompt reply!

On Fri, Jul 15, 2022 at 14:21, Eric Dumazet [off-list ref]:

...

MSG_PEEK is a mistake really, it considerably increases the cost of
receiving packets,
because you need twice more system calls.

Sure, but I don't know the size of packets in advance, and I don't
control the sending side. So for me it's the choice between multiple
bad options -- either allocate some reasonable sized buffers and
truncate/drop packets that do not fit, or allocate 64k buffer for each
packet (UDP max packet size), or do two syscalls at a time. I thought
I could compensate for the cost of doing two syscalls by reading
multiple packets by syscall, but it seems that it's not possible with
the current implementation. Maybe I'm missing something and there are
other options?

It also increases costs in the kernel, having to deal with it, even if
not used by fast applications.

Adding proper MSG_PEEK support to recvmmsg() is tricky, do_recvmmsg()
would probably have
to be completely reimplemented to not call ___sys_recvmsg(), or risk
some quadratic behavior
if each ___sys_recvmsg() has to skip over N datagrams

If there is no intention to fix the current behaviour, will it be OK
to submit a patch to man-pages with a note about it to the BUGS
section?

-- 
Regards,
Alexander Babayants.