On Tue, Feb 2, 2021 at 6:18 PM Paolo Abeni <pab...@redhat.com> wrote: > > On Mon, 2021-02-01 at 20:07 -0800, Jakub Kicinski wrote: > [...] > > https://marc.info/?l=linux-netdev&m=148010858826712&w=2 > > perf tests in lab with recvmmsg/sendmmsg could be great, but > performance with real workload much less. You could try fine-tuning the > bulk size (mmsg nr) for your workload and H/W. Likely a burst size > above 8 is a no go. > > For the TX path there is already a better option - for some specific > workload - using UDP_SEGMENT. > > In the RX path, for bulk transfer, you could try enabling UDP_GRO. > > As far as I can see, the idea you are proposing will be quite > alike recvmmsg(), with the possible additional benefit of bulk dequeue > from the UDP receive queue. Note that this latter optimization, since > commmit 2276f58ac5890, will give very little perfomance gain. > > In the TX path there is no lock at all for the uncorking case, so the > performance gain should come only from the bulk syscall. > > You will probably also need to cope with cmsg and msgname, so overall I > don't see much differences from recvmmsg()/sendmmsg(), did I misread > something? > > Thanks! > > Paolo >
Wow, thanks for your professional explanation. In fact, "recvmmsg/sendmmsg" is exactly what I want. (Haha... I didn't know their exists before, so embarrassing ~) By the way, I think my idea do have some benefit(maybe). For example, it doesn't need to call __sys_recvmsg() for every skb, which avoids unnecessary path. And it doesn't need to prepare msghdr for every skb, which is possible to reduce memory copy between kernel and user space. As for msgname, we can dequeue skbs that have the same source until we meet a different one, in one cycle. However, in view of the exist of "recvmmsg/sendmmsg", my idea seems unnecessary~~~ Thanks~ Menglong Dong
