From: Rick Jones <rick.jones2@hp.com>
To: Shawn Bohrer <sbohrer@rgmadvisors.com>
Cc: David Miller <davem@davemloft.net>,
Eric Dumazet <eric.dumazet@gmail.com>,
tomk@rgmadvisors.com, netdev <netdev@vger.kernel.org>
Subject: Re: [net-next 2/3] udp: Add udp early demux
Date: Tue, 01 Oct 2013 13:12:18 -0700 [thread overview]
Message-ID: <524B2CA2.4090807@hp.com> (raw)
In-Reply-To: <1380656025-8847-3-git-send-email-sbohrer@rgmadvisors.com>
On 10/01/2013 12:33 PM, Shawn Bohrer wrote:
> The removal of the routing cache introduced a performance regression for
> some UDP workloads since a dst lookup must be done for each packet.
> This change caches the dst per socket in a similar manner to what we do
> for TCP by implementing early_demux.
>
> For UDP multicast we can only cache the dst if there is only one
> receiving socket on the host. Since caching only works when there is
> one receiving socket we do the multicast socket lookup using RCU.
>
> Benchmark results from a netperf UDP_RR test:
> Before 90596.44 transactions/s
> After 91296.97 transactions/s
Were those measured with confidence intervals enabled? It would be a
Good Idea (tm) to either use that - I would suggest -I 99,1 -i 30,3
added to the global portion of the netperf command line - or take
several runs. (If you've not already done so since those look more like
"raw" netperf numbers rather than theaverage of several runs)
happy benchmarking,
rick jones
> Benchmark results from a fio 1 byte UDP multicast pingpong test
> (Multicast one way unicast response):
> Before 12.647us RTT
> After 12.497us RTT
next prev parent reply other threads:[~2013-10-01 20:12 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-01 19:33 [net-next 0/3] Improve UDP multicast receive latency Shawn Bohrer
2013-10-01 19:33 ` [net-next 1/3] udp: Only allow busy read/poll on connected sockets Shawn Bohrer
2013-10-01 20:44 ` Eric Dumazet
2013-10-01 19:33 ` [net-next 2/3] udp: Add udp early demux Shawn Bohrer
2013-10-01 20:12 ` Rick Jones [this message]
2013-10-01 22:26 ` Shawn Bohrer
2013-10-01 20:52 ` Eric Dumazet
2013-10-02 17:34 ` Shawn Bohrer
2013-10-02 18:09 ` Eric Dumazet
2013-10-02 20:35 ` Shawn Bohrer
2013-10-02 21:08 ` Eric Dumazet
2013-10-02 21:24 ` Shawn Bohrer
2013-10-02 21:38 ` Eric Dumazet
2013-10-03 17:39 ` Shawn Bohrer
2013-10-03 18:06 ` Eric Dumazet
2013-10-01 19:33 ` [net-next 3/3] net: ipv4 only populate IP_PKTINFO when needed Shawn Bohrer
2013-10-01 20:42 ` Eric Dumazet
2013-10-01 22:29 ` Shawn Bohrer
2013-10-01 20:21 ` [net-next 0/3] Improve UDP multicast receive latency Veaceslav Falico
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=524B2CA2.4090807@hp.com \
--to=rick.jones2@hp.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=sbohrer@rgmadvisors.com \
--cc=tomk@rgmadvisors.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.