lkml.org 
[lkml]   [2019]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: epoll_wait() performance
On Thu, 28 Nov 2019 16:37:01 +0000
David Laight <David.Laight@ACULAB.COM> wrote:

> From: Jesper Dangaard Brouer
> > Sent: 28 November 2019 11:12
> ...
> > > Can you test recv() as well?
> >
> > Sure: https://github.com/netoptimizer/network-testing/commit/9e3c8b86a2d662
> >
> > $ sudo taskset -c 1 ./udp_sink --port 9 --count $((10**6*2))
> > run count ns/pkt pps cycles payload
> > recvMmsg/32 run: 0 2000000 653.29 1530704.29 2351 18 demux:1
> > recvmsg run: 0 2000000 631.01 1584760.06 2271 18 demux:1
> > read run: 0 2000000 582.24 1717518.16 2096 18 demux:1
> > recvfrom run: 0 2000000 547.26 1827269.12 1970 18 demux:1
> > recv run: 0 2000000 547.37 1826930.39 1970 18 demux:1
> >
> > > I think it might be faster than read().
> >
> > Slightly, but same speed as recvfrom.
>
> I notice that you recvfrom() code doesn't request the source address.
> So is probably identical to recv().

Created a GitHub issue/bug on this:
https://github.com/netoptimizer/network-testing/issues/5

Feel free to fix this and send a patch/PR.

--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer

\
 
 \ /
  Last update: 2019-12-19 08:58    [W:0.089 / U:1.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site