Thanks for the prompt reply! On Fri, Jul 15, 2022 at 14:21, Eric Dumazet <edumazet@xxxxxxxxxx>: > ... > 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.
