From: Edward Cree <ecree@solarflare.com>
To: <netdev@vger.kernel.org>, Shawn Bohrer <sbohrer@rgmadvisors.com>
Cc: Jonathan Cooper <jcooper@solarflare.com>
Subject: udp: Question about busy_poll change
Date: Wed, 9 Apr 2014 15:13:21 +0100 [thread overview]
Message-ID: <53455581.7060209@solarflare.com> (raw)
Commit 005ec9743394010cd37d86c3fd2e81978231cdbf, "udp: Only allow busy
read/poll on connected sockets",
causes a performance regression (increased latency) on some
micro-benchmarks which don't connect() their UDP socket, and might well
have a similar effect on real applications that do the same thing.
As far as I can tell, the change is only needed in the case where the
UDP socket is bound to INADDR_ANY, _and_ traffic on the chosen UDP port
is received through more than one NIC (or perhaps through a NIC with
separate NAPI contexts per receive queue?)
In particular, busy polling makes sense for a client (which will only be
receiving packets from one remote address even though the socket is
unconnected), or for a socket which has been bound to an interface's
address (at least in the case of sfc, where we have one NAPI context for
all the receive queues on an interface).
So, what was the deeper rationale for this change? Is there a
correctness issue or does the old behaviour just affect performance
through unnecessary busy_polling? Or have I just misunderstood things
completely?
next reply other threads:[~2014-04-09 14:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-09 14:13 Edward Cree [this message]
2014-04-09 14:51 ` udp: Question about busy_poll change Shawn Bohrer
2014-04-09 16:20 ` Edward Cree
2014-04-10 18:04 ` [RFC PATCH] udp: allow busy_poll on some unconnected sockets Edward Cree
2014-04-10 18:32 ` Eric Dumazet
2014-04-10 18:38 ` Edward Cree
2014-04-10 19:04 ` Eric Dumazet
2014-04-11 10:44 ` Jonathan Cooper
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=53455581.7060209@solarflare.com \
--to=ecree@solarflare.com \
--cc=jcooper@solarflare.com \
--cc=netdev@vger.kernel.org \
--cc=sbohrer@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.