[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20191219085722.23e39028@carbon>
Date: Thu, 19 Dec 2019 08:57:22 +0100
From: Jesper Dangaard Brouer <brouer@...hat.com>
To: David Laight <David.Laight@...LAB.COM>
Cc: 'Marek Majkowski' <marek@...udflare.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
network dev <netdev@...r.kernel.org>,
kernel-team <kernel-team@...udflare.com>,
Paolo Abeni <pabeni@...hat.com>, brouer@...hat.com
Subject: Re: epoll_wait() performance
On Thu, 28 Nov 2019 16:37:01 +0000
David Laight <David.Laight@...LAB.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
Powered by blists - more mailing lists